Chaque commande sur une seule chronologie, de la saisie à la facture payée.
Le cycle de la commande à l’encaissement (order-to-cash), le cycle achats (procure-to-pay) et le cycle de la demande d’intervention à la facture traversent l’ERP, le CRM, l’e-commerce, l’entrepôt, le transport et la comptabilité. Nous relions ces systèmes par des API et des événements documentés, donnons à chaque commande un statut unique à travers eux, et confions chaque exception à un agent qui prépare une solution qu’une personne approuve.
Pour les entreprises belges qui vendent, achètent et facturent à travers plusieurs systèmes, et pour qui la facture Peppol fait désormais partie de chaque commande.
Une commande client, une commande d’achat ou une demande d’intervention est enregistrée une seule fois dans son système de référence, puis diffusée aux autres systèmes par des API et des événements documentés. Les événements de statut construisent une chronologie par commande. Quand une étape échoue ou sort des tolérances, un agent rassemble le contexte et propose une solution, qu’une personne approuve avant son exécution dans le système de référence. Les factures sont échangées et rapprochées sous forme de factures électroniques structurées, et les responsables de processus examinent les flux et l’état des interfaces.
Avant et après
Ce qui change dans les opérations au quotidien
Aujourd’hui
Avec le système
Aujourd’hui
Aujourd’hui : Une ressaisie à chaque passage de relais
Une commande prise sur la boutique en ligne ou par l’équipe commerciale est ressaisie dans l’ERP, et les données de livraison et de facturation sont recopiées à la main dans les systèmes d’entrepôt, de transport et de comptabilité.
Avec le système
Avec le système : Une seule saisie, réutilisée partout
Chaque commande, livraison et facture est créée dans le système qui en est propriétaire et publiée sous forme d’événement. Les autres systèmes s’y abonnent au lieu de la ressaisir.
Aujourd’hui
Aujourd’hui : Le statut de la veille
Avec des interfaces en traitement par lots la nuit, le service client, la planification et la comptabilité voient chacun un état différent et dépassé de la même commande. Le client qui demande où en est sa livraison doit attendre qu’on le rappelle.
Avec le système
Avec le système : Un seul statut à jour
Chaque commande ou demande a une chronologie unique, construite à partir des événements de tous les systèmes qu’elle traverse. Service client, planification et comptabilité consultent les mêmes faits, tout comme l’assistance à la relation client qui répond aux questions de suivi.
Aujourd’hui
Aujourd’hui : Des exceptions gérées dans les boîtes mail
Ruptures de stock, écarts de prix, livraisons échouées et factures électroniques rejetées se règlent par e-mail et dans des tableurs, et personne ne peut dire ensuite qui a décidé quoi.
Avec le système
Avec le système : Des exceptions accompagnées d’une proposition
Un agent rassemble les données qui se trouvent derrière chaque exception et propose une solution. Une personne l’approuve, la modifie ou la rejette sur un poste unique de traitement des exceptions, et la décision est enregistrée.
Aujourd’hui
Aujourd’hui : Des données de référence qui divergent
Le même client, fournisseur, article ou prix existe dans plusieurs systèmes avec des valeurs différentes, et personne n’est chargé de dire laquelle est juste.
Avec le système
Avec le système : Un responsable par objet de données
Clients, fournisseurs, articles et prix ont chacun un système de référence convenu et un responsable désigné. Doublons et conflits sont signalés à ce responsable, et non corrigés en silence en aval.
Aujourd’hui
Aujourd’hui : Chaque changement ajoute une interface
Un nouveau canal de vente, une place de marché ou une nouvelle entité juridique signifie une liaison point à point de plus. Les obligations nationales de facturation électronique ajoutent en outre à chaque processus un format structuré et un réseau.
Avec le système
Avec le système : Les nouvelles connexions réutilisent les mêmes contrats
Un nouveau canal, une nouvelle entité ou un nouveau réseau de facturation électronique se connecte une seule fois aux API et aux événements documentés, au lieu de se connecter séparément à chaque système.
Workflow
Le déroulement du processus
Quand les données sont propres, le circuit principal ne demande aucune intervention manuelle. Quand une commande, une livraison ou une facture s’écarte de ce qui est prévu, la boucle d’exception l’amène à une personne avec les éléments de preuve et une proposition, et la correction approuvé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 : processus illustratif avec boucle d’exception
Lire le schéma sous forme de texte
Le circuit principal va de l’enregistrement unique d’un événement métier dans son système de référence à la facturation, au rapprochement et au règlement, en passant par sa diffusion aux autres systèmes par API et événements et par la construction d’une chronologie par commande. Il se termine par l’examen des flux par les responsables de processus, qui traitent les causes des exceptions.
Lorsqu’une étape échoue, prend du retard ou sort des tolérances, l’exception quitte le circuit principal après l’étape de la chronologie. Un agent rassemble le contexte et propose une solution, qu’une personne approuve, modifie ou rejette. L’action approuvée est exécutée dans le système de référence et revient à l’étape de diffusion sous forme de nouvel événement.
L’étape d’approbation est le point de contrôle humain : aucune écriture financière, aucune modification de prix ou de limite de crédit et aucun engagement envers un client n’a lieu sans une personne.
01
Étape 1 : Enregistrer l’événement une seule foisSystème
Une commande client issue de la boutique en ligne, d’une place de marché, de l’EDI ou de l’équipe commerciale, une commande d’achat ou une demande d’intervention est créée dans le système qui en est propriétaire. Ce système publie un événement métier dans une enveloppe CloudEvents, décrit dans un contrat AsyncAPI. Les commandes papier ou PDF et les factures fournisseurs passent d’abord par le traitement intelligent des documents.
02
Étape 2 : Diffuser par API et événementsSystème
La couche d’intégration transmet l’événement aux systèmes d’entrepôt, de transport et de comptabilité ainsi qu’au CRM, via leurs API documentées (OpenAPI). Les consommateurs sont idempotents : un message répété ne crée jamais une seconde expédition ni une seconde facture, et les messages qui ne peuvent pas être remis attendent dans une file d’erreurs pour être rejoués.
03
Étape 3 : Construire une chronologie par commandeSystème
Les événements de statut de chaque système (confirmée, préparée, expédiée, livrée, facturée, payée) sont corrélés sur la référence métier en une chronologie unique. Des règles de jalons et de tolérances déclenchent une exception lorsqu’une étape échoue, prend du retard ou ne concorde pas : une rupture de stock, un prix hors de la tolérance convenue, une livraison échouée, une facture électronique rejetée.
04
Étape 4 : Rassembler le contexte et proposerAgent
Pour chaque exception, un agent lit ce dont il a besoin dans les systèmes concernés : la commande, les niveaux de stock, l’accord de prix, le statut du transporteur et les conditions du client. Il propose une solution, avec son raisonnement et les données utilisées, par exemple un article de substitution, un prix corrigé, une livraison replanifiée ou une facture corrigée.
Circuit d’exception : Étape en échec ou hors tolérance
05
Étape 5 : Approuver dans les limites des seuilsPersonne
Un collaborateur du service client, de la logistique ou de la comptabilité voit l’exception, les éléments de preuve et la proposition sur le poste de traitement des exceptions, puis l’approuve, la modifie ou la rejette. L’action approuvée est exécutée par l’API du système de référence, qui publie la modification sous forme de nouvel événement.
Circuit d’exception : Étape en échec ou hors tolérance· Retour à l’étape 2
Contrôle humain
Les agents ne passent jamais d’écriture financière, ne modifient jamais un prix ni une limite de crédit et ne prennent jamais d’engagement envers un client sans approbation. Des seuils par type d’action déterminent qui approuve, et chaque proposition comme chaque décision est journalisée.
06
Étape 6 : Facturer, rapprocher et réglerSystème
Les factures sortantes quittent l’ERP sous forme de factures électroniques structurées (Peppol BIS Billing 3.0, EN 16931) via un point d’accès. Les factures fournisseurs entrantes sont rapprochées des commandes d’achat et des réceptions de marchandises, et le statut de paiement transmis par la banque ou le prestataire de paiement clôt la chronologie.
07
Étape 7 : Examiner les flux et traiter les causesPersonne
Les responsables de processus et l’équipe d’intégration examinent à intervalles fixes les exceptions par motif, les défaillances d’interface et les conflits de données de référence. Ils corrigent la cause là où elle se trouve, dans une fiche de données de référence, une règle de tolérance ou une règle de correspondance, au lieu de résoudre une nouvelle fois la même exception.
Composants
Ce que nous construirions
01
Couche d’intégration événementielle
Des API et des événements conçus selon une approche contrat d’abord entre ERP, CRM, e-commerce, entrepôt, transport et comptabilité, spécifiés en OpenAPI et AsyncAPI avec des enveloppes CloudEvents, sur votre plateforme d’intégration existante ou en natif cloud.
Un système de référence et un responsable convenus par objet de données, des règles de rapprochement pour les clients, les fournisseurs et les articles, et des rapports sur les doublons et les conflits destinés à leurs responsables.
Chronologie des processus et tableaux de bord des flux
Un service qui corrèle les événements en une chronologie par commande ou par demande, applique les règles de jalons et de tolérances, et présente les flux et les exceptions aux responsables de processus.
Poste de traitement des exceptions avec agent de proposition
Une file d’exceptions qui présente le contexte rassemblé et la proposition de l’agent, avec les actions approuver, modifier et rejeter, et des seuils d’approbation par type d’action appliqués au point où l’action s’exécute.
Factures Peppol BIS Billing 3.0 et EN 16931 en UBL, envoyées et reçues via un point d’accès et validées avant envoi ; les factures rejetées sont orientées vers le poste de traitement des exceptions.
Supervision et alertes par interface, procédures d’exploitation pour l’équipe d’exploitation et rejeu maîtrisé des messages en échec, déployés en infrastructure as code dans votre environnement cloud.
Commandes de la boutique en ligne et des places de marché
EDI et autres messages de commande B2B
Commandes d’achat et confirmations fournisseurs
Demandes d’intervention et rapports d’intervention terrain
Suivi des transporteurs et événements de livraison
Factures électroniques Peppol et réponses de statut
Relevés bancaires et notifications de paiement
Cœur de la solution
Opérations connectées
Systèmes connectés
SAP S/4HANA Ventes, Achats et FinancePlateformeSAP
Salesforce Sales Cloud, Service Cloud et Commerce CloudPlateformeSalesforce
Odoo Ventes, Inventaire, Achats et ComptabilitéPlateformeOdoo
Plateformes e-commerce, places de marché et API des transporteurs
Systèmes de gestion d’entrepôt et de gestion du transport
Point d’accès Peppol, banques et prestataires de paiement
Gestion des informations produit (PIM) et plateforme de données
Contrôles
Des contrôles intégrés dès la conception
Périmètres d’accès
Chaque intégration et l’agent s’exécutent sous leur propre identité de service dans chaque système, limitée aux opérations d’API dont ils ont besoin. L’agent peut lire dans plusieurs systèmes pour rassembler le contexte, mais il ne peut écrire que par une courte liste d’actions approuvées, exécutées par l’API du système de référence et jamais par un accès direct à la base de données.
Revue humaine
Les seuils d’approbation sont fixés par type d’action avec le responsable du processus : ce que l’agent peut seulement proposer, ce qu’un membre de l’équipe approuve et ce qui exige un second approbateur. Les écritures financières, les modifications de prix et de limites de crédit et les engagements envers les clients attendent toujours une personne. Des actions à faible impact et réversibles, comme relancer un message en échec, peuvent s’exécuter sans approbation si le responsable l’accepte.
Traçabilité
Chaque événement, proposition, approbation, rejet et action exécutée est journalisé sous la référence de la commande ou de la demande, avec les données utilisées par l’agent, la version du modèle et du prompt et l’approbateur. Une facture contestée ou une réclamation client peut être retracée étape par étape.
Protection des données
Les coordonnées des clients et des fournisseurs ne circulent que vers les systèmes qui en ont besoin. La chronologie conserve des références métier et des statuts plutôt que des fiches complètes, et les journaux suivent la durée de conservation que vous fixez. Le traitement reste dans la région convenue.
Transparence de l’IA
Les propositions de l’agent sont signalées comme telles sur le poste de traitement des exceptions, avec les éléments de preuve et le raisonnement affichés à côté. Les systèmes de référence restent la source qui fait foi : la chronologie montre ce qu’ils rapportent et ne prévaut jamais sur eux.
Indicateurs
Ce que nous mesurerions
Nous convenons de ces indicateurs avec vous pendant le cadrage et mesurons la situation de référence à partir des journaux actuels de vos systèmes et interfaces, avant tout changement.
Ce que nous mesurerions
Indicateur
Pourquoi c’est important
Comment nous le mesurerions
01Durée du cycle de commande
Pourquoi c’est importantL’indicateur que les clients remarquent en premier, et celui qui montre où les commandes attendent.
Comment nous le mesurerionsTemps entre la réception de la commande et la livraison, puis le paiement, par canal et par entité, d’après les événements de la chronologie.
02Commandes sans intervention manuelle
Pourquoi c’est importantMontre quelle part du flux repose sur des données propres et des règles convenues.
Comment nous le mesurerionsPart des commandes et des demandes qui atteignent le règlement sans étape manuelle ni exception, d’après la chronologie.
03Exceptions par motif et délai de résolution
Pourquoi c’est importantIndique quelles causes traiter en premier et si le poste de traitement des exceptions suit le rythme.
Comment nous le mesurerionsVolume d’exceptions par code motif, et temps entre la détection et l’exécution de la solution, d’après les journaux du poste de traitement des exceptions.
04Taux de rejet des factures électroniques
Pourquoi c’est importantLes factures rejetées retardent le paiement et révèlent le plus souvent des erreurs de données de référence ou de correspondance.
Comment nous le mesurerionsPart des factures électroniques envoyées et reçues qui sont rejetées, par motif, d’après les réponses du point d’accès.
05Défaillances d’interface et délai de reprise
Pourquoi c’est importantMontre si la couche d’intégration est fiable et si les défaillances sont repérées et corrigées rapidement.
Comment nous le mesurerionsMessages en échec par interface, et temps entre l’échec et le rejeu réussi, d’après la supervision de l’intégration.
06Doublons et conflits de données de référence
Pourquoi c’est importantLa plupart des exceptions remontent à des données qui diffèrent d’un système à l’autre.
Comment nous le mesurerionsDoublons ouverts et valeurs contradictoires par objet de données et par système, d’après les rapports de rapprochement.
Aucun objectif n’est fixé avant une mesure de référence.
Déploiement
Notre démarche de déploiement
Phase 01
Cadrage et cartographie du processus
Un processus, par exemple la commande à l’encaissement pour un canal de vente, et un type d’exception. Nous cartographions les systèmes, les interfaces, les responsables des données et la façon dont les exceptions sont traitées aujourd’hui.
Critères de sortie
Processus, systèmes et responsables des données cartographiés
Premier type d’exception et seuils d’approbation convenus
Situation de référence mesurée à partir des journaux actuels
Phase 02
Intégration et chronologie
Des API et des événements documentés pour les systèmes concernés, et la chronologie qui fonctionne à côté des interfaces existantes sans les modifier.
Critères de sortie
Contrats d’événements publiés et versionnés
La chronologie concorde avec les systèmes de référence sur un échantillon de commandes
Rejeu et procédures d’exploitation testés
Phase 03
Pilote du poste de traitement des exceptions
L’agent propose des solutions pour le type d’exception retenu, et des personnes approuvent chaque proposition. Nous comparons les propositions avec ce que les équipes auraient fait.
Critères de sortie
La qualité des propositions satisfait 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
Extension et décommissionnement
D’autres types d’exceptions, canaux, entités et processus, comme l’achat au paiement, chacun sur les mêmes contrats. Les anciennes interfaces point à point sont arrêtées une à une.
Critères de sortie
Chaque nouveau flux sur les mêmes contrats et la même supervision
Commandes de fabrication à la commande et de pièces de rechange, de l’ERP à l’entrepôt et aux transporteurs, avec confirmations fournisseurs et factures électroniques rapprochées des commandes d’achat.
Demandes de raccordement et d’installation suivies de l’ordre de travail à la facture en passant par l’intervention sur site, et matériel acheté dans le cadre d’accords-cadres.
Ordres de travail de maintenance, commandes aux entrepreneurs et leurs factures, suivis de la demande au paiement pour les gestionnaires d’infrastructure.
Cycle de l’achat au paiement avec des factures électroniques structurées vers et depuis les organismes publics, rapprochées des commandes et des réceptions avant paiement.
Exemple illustratif
Un grossiste wallon entre boutique en ligne, ERP et Peppol
Situation
Un grossiste en fournitures techniques établi en Wallonie vend par sa boutique en ligne et ses représentants à des entreprises et à des pouvoirs publics belges. Les commandes sont ressaisies dans l’ERP, les transporteurs signalent les problèmes de livraison par e-mail, et les factures Peppol rejetées se règlent au cas par cas.
Système
Commandes, stocks, expéditions et factures circulent sous forme d’événements entre la boutique en ligne, l’ERP, l’entrepôt et les transporteurs, avec une chronologie par commande. Les factures partent en Peppol BIS Billing 3.0 via un point d’accès, vers les entreprises comme vers les pouvoirs publics via Mercurius.
Contrôle humain
Ruptures de stock, livraisons échouées et factures rejetées arrivent sur un seul poste de traitement des exceptions, où un agent propose une solution. Le service client approuve ; les avoirs et les modifications de prix passent par la comptabilité.
Ce que nous mesurerions
Part des commandes sans intervention manuelle, exceptions par motif et délai de résolution, et taux de rejet des factures Peppol.
Belgique
La facture Peppol, un événement du processus
En Belgique, la facture électronique structurée est obligatoire depuis le 1er janvier 2026 entre entreprises assujetties à la TVA établies en Belgique (loi du 6 février 2024), avec Peppol comme réseau par défaut ; la période de tolérance a pris fin le 31 mars 2026. Les factures adressées aux pouvoirs publics passent par Mercurius. Un e-reporting est prévu à partir du 1er janvier 2028, mais la législation n’est pas encore définitive.
Nous traitons la facture Peppol comme un événement du processus : émise depuis l’ERP, envoyée par un point d’accès, rapprochée de la commande et, en cas de rejet, orientée vers le poste de traitement des exceptions. Les intégrations sont documentées et journalisées pour les clients soumis à la loi NIS2.
Non. Votre ERP, votre CRM, votre boutique en ligne et votre système d’entrepôt font chacun leur travail. Nous intégrons autour de ces systèmes de référence, convenons du système propriétaire de chaque donnée et donnons au processus une chronologie unique qui les traverse. Lorsqu’un ancien système de commande ou un ancien ERP bloque le changement, la modernisation des systèmes hérités le place d’abord derrière des API.
02Remplacez-vous notre middleware d’intégration ?
Pas s’il remplit son rôle. Nous construisons sur la plateforme d’intégration ou le courtier de messages que vous exploitez déjà, et ajoutons contrats, supervision et rejeu là où ils manquent. En l’absence de plateforme, nous construisons en natif cloud. Découvrez nos services d’intégration.
03Les agents peuvent-ils agir seuls ?
Uniquement dans les limites des seuils que vous fixez par type d’action, et uniquement pour des actions à faible impact et réversibles, comme relancer un message en échec. Les écritures financières, les prix, les limites de crédit et les engagements envers les clients exigent toujours une personne. Lisez notre analyse Agents IA : où la validation humaine s’impose.
04Comment les obligations de facturation électronique s’intègrent-elles ?
Les obligations nationales de facturation électronique arrivent à des dates différentes, et le paquet européen « TVA à l’ère numérique » fait de la facturation électronique structurée la règle pour les livraisons B2B intra-UE à partir du 1er juillet 2030. Nous traitons la facture électronique comme un événement de plus dans le processus : émise depuis l’ERP, envoyée via un point d’accès et traitée sur le poste de traitement des exceptions lorsqu’elle est rejetée. Consultez notre guide de la facturation électronique Peppol.
05Comment évitez-vous un nouvel enchevêtrement fragile de liaisons point à point ?
Les systèmes publient et consomment des événements et des API documentés par une seule couche, et non par des liaisons directes entre eux. Les contrats sont versionnés, les consommateurs sont idempotents, les messages en échec peuvent être rejoués et chaque flux a un responsable désigné. Un nouveau canal s’abonne aux événements existants au lieu d’ajouter une liaison vers chaque système.
06À quoi ressemble un premier périmètre ?
Un processus et un type d’exception, par exemple la commande à l’encaissement pour un canal de vente, avec les ruptures de stock comme première exception. Cela valide les événements, la chronologie et le circuit d’approbation avant d’ajouter le reste. Découvrez notre démarche de réalisation.
Parlons de vos flux de commandes et de factures
Choisissez un processus et les systèmes qu’il traverse, de la boutique en ligne à la comptabilité. Nous cartographions avec vous les interfaces et les exceptions, factures Peppol rejetées comprises, et vous proposons une première version.