Chaque commande suivie sur un seul fil, de la prise d’ordre à la facture payée.
Une vente, un achat ou une intervention passe par une demi-douzaine d’outils : ERP, CRM, site marchand, gestion d’entrepôt, transporteurs, comptabilité. Nous les relions par des API et des événements décrits par contrat, attribuons à chaque commande un statut que tous partagent, et remettons chaque écart à un agent chargé de préparer une solution soumise à une personne.
Pour les entreprises luxembourgeoises qui vendent, achètent et facturent au Grand-Duché, en France, en Belgique et en Allemagne, chaque pays avec ses applications, ses transporteurs et ses règles de facturation électronique.
Une commande client, un achat ou une demande d’intervention n’est saisi qu’une fois, là où il fait foi, puis transmis aux autres outils par contrat d’API ou d’événement. Les statuts successifs composent la chronologie de chaque commande. Si un jalon échoue ou dépasse la tolérance, un agent rassemble les éléments et suggère une correction ; une personne la valide avant qu’elle soit appliquée dans l’outil de référence. Les factures s’échangent et se rapprochent en format électronique structuré, et les responsables de processus surveillent les flux et l’état des interfaces.
Avant et après
Ce qui change dans les opérations
Aujourd’hui
Avec le système
Aujourd’hui
Aujourd’hui : Ressaisie à chaque passage de relais
Prise sur le site marchand ou par un commercial, la commande est retapée dans l’ERP ; adresse de livraison et données de facture sont recopiées pour l’entrepôt, le transporteur et la comptabilité.
Avec le système
Avec le système : Saisi une fois, réutilisé partout
Commande, livraison et facture naissent dans l’application qui en est propriétaire et sont publiées sous forme d’événement. Les autres applications s’y abonnent au lieu de les ressaisir.
Aujourd’hui
Aujourd’hui : Un statut qui date d’hier
Les échanges entre outils ne tournent qu’une fois par nuit : ventes, planning et comptabilité consultent chacun une version différente, et périmée, de la même commande. Un client qui s’inquiète de sa livraison obtient la promesse d’un rappel.
Avec le système
Avec le système : Un statut unique et à jour
Pour chaque commande ou demande, une chronologie se construit à partir des événements de tous les outils traversés. Ventes, planning et comptabilité voient les mêmes faits, comme le ferait un assistant de relation client chargé de répondre aux questions de suivi.
Aujourd’hui
Aujourd’hui : Les anomalies se règlent par e-mail
Rupture de stock, prix discordant, livraison manquée, facture électronique rejetée : tout se traite par messagerie et tableur, et plus personne ne sait ensuite qui a décidé quoi.
Avec le système
Avec le système : L’anomalie arrive avec une proposition
Un agent rassemble les données derrière chaque anomalie et suggère une correction. Une personne l’accepte, la modifie ou la refuse sur un poste unique de gestion des anomalies, et sa décision est enregistrée.
Aujourd’hui
Aujourd’hui : Des données de référence contradictoires
Un même client, fournisseur, article ou prix figure dans plusieurs applications avec des valeurs différentes, sans que personne ne soit chargé de dire laquelle est juste.
Avec le système
Avec le système : Un responsable par type de donnée
Clients, fournisseurs, articles et prix ont chacun une application de référence convenue et un responsable nommé. Doublons et contradictions lui sont signalés, au lieu d’être corrigés en silence plus loin dans la chaîne.
Aujourd’hui
Aujourd’hui : Chaque évolution ajoute une interface
Nouveau canal de vente, place de marché ou société du groupe : à chaque fois une liaison directe de plus. Chaque obligation nationale de facturation électronique y ajoute encore un format structuré et un réseau.
Avec le système
Avec le système : Les nouveaux raccordements réutilisent les mêmes contrats
Un nouveau canal, une nouvelle société ou un nouveau réseau de facturation électronique se raccorde une seule fois aux API et événements documentés, et non à chaque application séparément.
Workflow
Le parcours, étape par étape
Quand les données sont saines, le chemin principal tourne sans saisie manuelle. Dès qu’une commande, un envoi ou une facture s’écarte de la norme, la boucle des anomalies le soumet à une personne, éléments et suggestion à l’appui, et la correction validée repasse par la même couche d’intégration.
Workflow illustratif
7 étapes · 1 contrôle humain
Légende
Système
Agent
Personne
Contrôle humain
Circuit d’exception
Opérations connectées : parcours illustratif et boucle des anomalies
Lire le schéma sous forme de texte
Sur le chemin principal : un événement métier saisi une fois dans l’outil qui fait foi, sa transmission aux autres outils par API et événements, la chronologie de chaque commande, puis la facture, le rapprochement et le paiement. La revue des flux et des causes d’écarts par les responsables de processus vient en dernier.
Une étape en échec, en retard ou hors tolérance fait sortir l’écart du chemin principal juste après la chronologie. L’agent réunit les éléments et suggère une correction ; une personne la valide, l’ajuste ou la rejette. Appliquée dans l’outil de référence, l’action revient sous forme de nouvel événement à l’étape de transmission.
Point de contrôle humain : la validation. Ni écriture comptable, ni changement de prix ou de plafond de crédit, ni promesse faite à un client sans l’accord d’une personne.
01
Étape 1 : Enregistrer l’événement une foisSystème
La commande (site marchand, place de marché, EDI ou commercial), le bon d’achat ou la demande d’intervention naît dans l’outil qui le gère. Cet outil émet alors un événement métier au format CloudEvents, dont le contrat est rédigé en AsyncAPI. Les commandes sur papier ou en PDF et les factures d’achat passent d’abord par le traitement intelligent des documents.
02
Étape 2 : Diffuser par API et événementsSystème
Via la couche d’intégration, l’événement atteint l’entrepôt, le transport, la comptabilité et le CRM, chacun par son API décrite en OpenAPI. Un message reçu deux fois ne produit ni deuxième envoi ni deuxième facture, car chaque destinataire est idempotent ; un message impossible à livrer est mis de côté dans une file d’erreurs, en attente de rejeu.
03
Étape 3 : Construire un fil par commandeSystème
Les statuts transmis par les outils (confirmée, préparée, expédiée, livrée, facturée, payée) sont rattachés à la référence de la commande et forment une seule chronologie. Des jalons et des tolérances déclenchent un écart dès qu’une étape échoue, traîne ou ne colle pas : stock insuffisant, prix hors marge, livraison ratée, facture électronique refusée.
04
Étape 4 : Réunir le contexte et proposerAgent
Face à un écart, l’agent va chercher les informations utiles dans les outils concernés : commande, stock disponible, conditions tarifaires, position du colis chez le transporteur, conditions du client. Il soumet une correction motivée, données à l’appui : article équivalent, prix rectifié, livraison replanifiée ou facture refaite.
Circuit d’exception : Étape en échec ou hors tolérance
05
Étape 5 : Approuver selon les seuilsPersonne
Selon le cas, une personne des ventes, de la logistique ou de la comptabilité examine l’écart, les pièces et la suggestion sur le poste des anomalies, puis valide, ajuste ou rejette. L’action validée passe par l’API de l’outil de référence, qui diffuse la modification comme un nouvel événement.
Circuit d’exception : Étape en échec ou hors tolérance· Retour à l’étape 2
Contrôle humain
Sans approbation, un agent ne passe aucune écriture comptable, ne modifie ni prix ni plafond de crédit et ne prend aucun engagement envers un client. Des seuils par type d’action désignent l’approbateur, et chaque proposition comme chaque décision est journalisée.
06
Étape 6 : Facturer, rapprocher, encaisserSystème
L’ERP émet les factures de vente en format électronique structuré (Peppol BIS Billing 3.0, EN 16931) par un point d’accès ; un pouvoir adjudicateur luxembourgeois ne les reçoit que par Peppol ou MyGuichet.lu. À l’inverse, chaque facture d’achat est confrontée au bon de commande et à la réception, et l’avis de paiement de la banque ou du prestataire clôt la chronologie.
07
Étape 7 : Analyser les flux et traiter les causesPersonne
Selon un rythme convenu, responsables de processus et intégrateurs examinent les écarts par motif, les pannes d’interface et les données de référence contradictoires. Ils traitent la cause à sa source (fiche article ou client, règle de tolérance, table de correspondance) plutôt que de corriger encore et encore le même écart.
Composants
Les briques que nous réaliserions
01
Couche d’intégration événementielle
Contrats d’API et d’événements rédigés avant le code (OpenAPI, AsyncAPI, enveloppes CloudEvents) pour relier ERP, CRM, site marchand, entrepôt, transport et comptabilité, sur votre plateforme d’intégration actuelle ou en cloud natif.
Une application de référence et un responsable convenus par type de donnée, des règles de rapprochement pour clients, fournisseurs et articles, et des rapports de doublons et de conflits adressés à leurs responsables.
Un service qui relie les événements en un fil par commande ou demande, applique les règles de jalons et de tolérance, et montre aux responsables de processus les flux et les anomalies.
Une file d’anomalies affichant le contexte réuni et la proposition de l’agent, avec les actions accepter, modifier et refuser, et des seuils d’approbation imposés par type d’action à l’endroit même où l’action s’exécute.
Factures au format UBL selon Peppol BIS Billing 3.0 et EN 16931, échangées par un point d’accès et contrôlées avant envoi ; un refus atterrit sur le poste des anomalies.
Surveillance de chaque interface avec alertes, procédures écrites pour l’exploitation et rejeu contrôlé des messages bloqués, le tout déployé par code d’infrastructure dans votre cloud.
Commandes de la boutique en ligne et des places de marché
EDI et autres messages de commande entre entreprises
Bons de commande et confirmations fournisseurs
Demandes d’intervention et rapports de techniciens
Suivi des transporteurs et événements de livraison
Factures électroniques Peppol et accusés de statut
Relevés bancaires et avis de paiement
Cœur de la solution
Opérations connectées
Systèmes connectés
SAP S/4HANA ventes, achats et financePlateformeSAP
Salesforce Sales, Service et Commerce CloudPlateformeSalesforce
Odoo ventes, stock, achats et comptabilitéPlateformeOdoo
Plateformes de commerce en ligne, places de marché et API des transporteurs
Applications de gestion d’entrepôt et de transport
Point d’accès Peppol, banques et prestataires de paiement
Gestion des informations produit et plateforme de données
Contrôles
Contrôles prévus dès la conception
Périmètres d’accès
Les intégrations et l’agent utilisent chacun une identité technique propre à chaque outil, réduite aux appels d’API indispensables. L’agent a le droit de consulter plusieurs outils, mais pour écrire il ne dispose que de quelques actions validées, passant par l’API de l’outil de référence, jamais par un accès direct à la base.
Revue humaine
Avec le responsable du processus, nous décidons pour chaque type d’action ce que l’agent se contente de suggérer, ce qu’un collaborateur valide et ce qui demande deux signatures. Une écriture comptable, une modification de prix ou de plafond de crédit, une promesse faite à un client attendent toujours l’accord d’une personne. Seules des actions mineures et réversibles, comme relancer un message bloqué, peuvent se passer de validation, si le responsable y consent.
Traçabilité
Le journal rattache à la référence de chaque commande ou demande tous les événements, suggestions, validations, refus et actions, avec les données consultées par l’agent, les versions du modèle et du prompt, et l’identité de l’approbateur. Une facture contestée ou une réclamation peut ainsi être reconstituée pas à pas.
Protection des données
Les coordonnées de vos clients et fournisseurs ne circulent que vers les outils qui s’en servent. La chronologie garde des références et des statuts, pas des fiches entières, et la conservation des journaux suit la durée que vous fixez. Les traitements restent dans la région de l’UE convenue.
Transparence de l’IA
Sur le poste des anomalies, chaque suggestion de l’agent est identifiée comme telle et présentée avec ses éléments et son raisonnement. Les outils de référence gardent le dernier mot : la chronologie reflète ce qu’ils disent, sans jamais les corriger.
Indicateurs
Ce que nous mesurerions
Ces indicateurs sont fixés avec vous pendant la phase d’analyse, et la situation de départ est tirée des journaux actuels de vos applications et interfaces.
Ce que nous mesurerions
Indicateur
Pourquoi c’est important
Comment nous le mesurerions
01Durée du cycle de commande
Pourquoi c’est importantCe que le client remarque d’abord, et ce qui montre où les commandes attendent.
Comment nous le mesurerionsTemps entre la réception de la commande, la livraison et le paiement, par canal et par société, d’après les événements du fil.
02Commandes sans intervention manuelle
Pourquoi c’est importantMontre quelle part du flux tourne sur des données propres et des règles convenues.
Comment nous le mesurerionsPart des commandes et demandes qui arrivent au paiement sans étape manuelle ni anomalie, d’après le fil.
03Anomalies par motif et délai de résolution
Pourquoi c’est importantIndique les causes à traiter en premier et si le poste des anomalies suit le rythme.
Comment nous le mesurerionsVolume d’anomalies par code de motif, et temps entre la détection et la correction exécutée, d’après les journaux du poste.
04Taux de rejet des factures électroniques
Pourquoi c’est importantUne facture rejetée retarde le paiement et trahit le plus souvent une erreur de données de référence ou de correspondance.
Comment nous le mesurerionsPart des factures électroniques envoyées ou reçues qui reviennent en rejet, classée par motif, selon les retours du point d’accès.
05Incidents d’interface et délai de reprise
Pourquoi c’est importantDit si la couche d’intégration tient et si une panne est vite vue et réparée.
Comment nous le mesurerionsNombre de messages bloqués par interface et délai jusqu’au rejeu réussi, selon la surveillance de l’intégration.
06Doublons et conflits de données de référence
Pourquoi c’est importantLa plupart des anomalies viennent de données qui diffèrent d’une application à l’autre.
Comment nous le mesurerionsDoublons ouverts et valeurs contradictoires par type de donnée et par application, d’après les rapports de rapprochement.
Aucun objectif n’est fixé avant une mesure de référence.
Déploiement
La mise en service, par étapes
Phase 01
Phase d’analyse et carte du processus
Un seul processus, comme la vente sur un canal donné jusqu’à l’encaissement, et un seul type d’écart. Nous recensons outils, interfaces et responsables de données, et observons comment les écarts sont gérés aujourd’hui.
Critères de sortie
Processus, applications et responsables de données cartographiés
Premier type d’anomalie et seuils d’approbation arrêtés
Situation de départ tirée des journaux actuels
Phase 02
Intégration et fil
Contrats d’API et d’événements pour les outils retenus, et une chronologie qui fonctionne en parallèle des interfaces actuelles, sans les toucher.
Critères de sortie
Contrats d’événements publiés et versionnés
Fil conforme aux applications de référence sur un échantillon de commandes
Rejeu et procédures testés
Phase 03
Pilote du poste des anomalies
Pour le type d’écart retenu, l’agent suggère des corrections et une personne valide chacune d’elles. Nous confrontons les suggestions à ce que l’équipe aurait décidé.
Critères de sortie
Qualité des propositions conforme aux critères convenus
Seuils et approbateurs fixés par type d’action
Piste d’audit revue par la finance et le contrôle interne
Phase 04
Étendre et retirer
Nouveaux types d’écart, canaux, sociétés et processus, par exemple les achats jusqu’au paiement, tous branchés sur les mêmes contrats. Les anciennes liaisons point à point sont coupées l’une après l’autre.
Critères de sortie
Chaque nouveau flux sur les mêmes contrats et la même supervision
Pièces détachées et commandes sur mesure d’un sous-traitant industriel, suivies de l’ERP jusqu’au quai d’expédition et au transporteur, confirmations fournisseurs et factures électroniques confrontées aux bons d’achat.
Demandes d’installation chez un fournisseur d’énergie suivies de l’ordre de travail à l’intervention puis à la facture, et matériel acheté dans le cadre de contrats-cadres avec des fournisseurs.
Ordres de maintenance d’un exploitant de bus régional, bons de commande aux sous-traitants et factures correspondantes, suivis de la demande au paiement.
De l’achat au paiement dans une commune ou une administration, avec des factures électroniques reçues par Peppol ou MyGuichet.lu et rapprochées des commandes et des réceptions avant paiement.
Exemple illustratif
Un distributeur luxembourgeois et ses clients de la Grande Région
Situation
Établi au Luxembourg, un distributeur de fournitures techniques vend en ligne et par ses commerciaux à des entreprises luxembourgeoises, françaises et belges, ainsi qu’à des communes. Chaque commande est retapée dans l’ERP, les problèmes de livraison arrivent par e-mail des transporteurs, et les factures aux acheteurs publics sont montées séparément.
Système
Commandes, niveaux de stock, envois et factures s’échangent en événements entre le site marchand, l’ERP, l’entrepôt et les transporteurs ; chaque commande a sa chronologie. Les factures sortent en format structuré par un point d’accès Peppol, communes et administrations comprises.
Contrôle humain
Ruptures de stock et livraisons manquées arrivent sur un seul poste des anomalies, où un agent propose un article de remplacement ou une nouvelle date. Le service client approuve chaque proposition ; les changements de prix et les notes de crédit exigent l’accord de la comptabilité.
Ce que nous mesurerions
Part des commandes traitées sans saisie manuelle, par pays et par canal, écarts par motif et délai de traitement, et taux de rejet des factures électroniques.
Luxembourg
Un processus, plusieurs pays, plusieurs obligations
Une entreprise établie au Luxembourg fait souvent tourner les mêmes processus de vente et d’achat avec des clients et des filiales en France, en Belgique et en Allemagne, sur des instances d’ERP, des transporteurs et des banques différents. Côté marchés publics luxembourgeois, tous les opérateurs économiques doivent depuis le 18 mars 2023 envoyer des factures électroniques structurées, exclusivement par Peppol ou MyGuichet.lu, dans des formats tels que Peppol BIS Billing 3.0 ou XRechnung. Les pays voisins avancent selon leur propre calendrier, et le paquet européen sur la TVA à l’ère numérique étend la facture structurée aux livraisons B2B intra-UE à partir du 1er juillet 2030. Nous concevons une seule couche d’intégration où le format et le réseau de chaque pays se trouvent derrière les mêmes événements : une nouvelle obligation devient un nouveau connecteur, pas un nouveau processus.
Le règlement sur les données, applicable depuis le 12 septembre 2025, encadre le changement de fournisseur de services de traitement de données ; nous gardons donc les contrats d’événements et les exports portables. Les agents du poste des anomalies sont conçus au regard du règlement sur l’IA, et les intégrations sont livrées avec des accès journalisés et des composants documentés pour les clients qui doivent démontrer la sécurité de leur chaîne d’approvisionnement au titre de la loi du 5 mai 2026 transposant NIS2, sous la supervision de l’ILR pour la plupart des secteurs.
Non. ERP, CRM, site marchand et gestion d’entrepôt continuent chacun leur travail. Nous intégrons autour de ces outils de référence, fixons qui détient quelle donnée et donnons au processus une chronologie commune. Si un ERP vieillissant ou une ancienne application de commandes bloque l’évolution, la modernisation des applications historiques commence par la placer derrière des API.
02Remplacez-vous notre middleware d’intégration ?
S’il fonctionne, non. Nous construisons sur l’outil d’intégration ou le courtier de messages que vous exploitez déjà, en ajoutant contrats, surveillance et rejeu s’ils font défaut. Sans outil existant, nous partons sur du cloud natif. Plus de détails dans nos intégrations et API.
03Les agents peuvent-ils agir seuls ?
Uniquement à l’intérieur des seuils convenus pour chaque type d’action, et pour des gestes mineurs et réversibles, comme relancer un message bloqué. Écritures comptables, prix, plafonds de crédit et promesses aux clients exigent toujours une personne. À lire : où les agents IA ont besoin d’une approbation humaine.
04Comment intégrer les obligations de facturation électronique ?
Au Luxembourg, toute facture destinée à un pouvoir adjudicateur doit être électronique et structurée depuis le 18 mars 2023, sans seuil de montant, et passer par Peppol ou MyGuichet.lu ; un envoi par e-mail n’est pas admis. Chez vos clients en France, en Belgique ou en Allemagne, les obligations nationales suivent leur propre calendrier ; quant au paquet « TVA à l’ère numérique », il rendra la facture structurée obligatoire par défaut pour les livraisons B2B entre États membres à compter du 1er juillet 2030. Pour nous, la facture électronique n’est qu’un événement de plus : produite par l’ERP, transmise par un point d’accès, renvoyée au poste des anomalies si elle est refusée. Voir notre guide de la facturation électronique Peppol.
05Comment éviter un nouveau réseau fragile de liaisons directes ?
Tous les outils passent par une même couche, où ils émettent et reçoivent des événements et des API documentés, sans liaison directe entre eux. Les contrats ont des versions, les destinataires sont idempotents, un message bloqué se rejoue et chaque flux a un responsable désigné. Pour un nouveau canal, il suffit de s’abonner aux événements existants, au lieu de tirer un lien vers chaque outil.
06À quoi ressemble un premier périmètre ?
Un processus, un type d’écart : par exemple la vente sur un canal jusqu’à l’encaissement, en commençant par les ruptures de stock. On éprouve ainsi les événements, la chronologie et le circuit de validation avant d’élargir. Découvrez notre méthode de travail.
Parlons de vos flux de commandes et de factures
Choisissez un processus et les pays où il s’exécute. Nous cartographions avec vous applications, interfaces et anomalies, puis proposons une première version qui fonctionne pour toutes vos sociétés.