De la prise de commande à l’encaissement, un seul fil pour chaque commande.
Du devis au règlement client (order-to-cash), de la demande d’achat au paiement du fournisseur (procure-to-pay), de la demande d’intervention à la facture : ces cycles traversent l’ERP, le CRM, le site marchand, la gestion d’entrepôt (WMS) et de transport (TMS) et la comptabilité. Nous les relions par des API et des événements documentés, donnons à chaque commande un statut qui fait foi dans toutes ces applications, et confions chaque anomalie à un agent IA qui prépare une correction soumise à validation humaine.
Pour les ETI, distributeurs et industriels qui relient ERP, e-commerce, entrepôt et comptabilité pendant que la réforme de la facturation électronique se déploie.
04Réunir le contexte et suggérer une correctionAgent
05Valider selon les seuilsPersonne
06Facturer, rapprocher, encaisserSystème
07Analyser les flux et corriger les causesPersonne
Commande client, commande fournisseur ou demande d’intervention : chacune est saisie une fois dans son système maître, puis transmise aux autres applications par des API et des événements documentés. Les changements de statut alimentent un fil chronologique par commande. Si une étape échoue ou sort des tolérances, un agent IA réunit le contexte et suggère une correction, validée par une personne avant d’être exécutée dans le système maître. Les factures circulent et sont rapprochées au format électronique structuré, et les responsables de processus suivent les flux et la santé des interfaces.
Avant et après
Ce qui change au quotidien
Aujourd’hui
Avec le système
Aujourd’hui
Aujourd’hui : La même commande tapée trois fois
Une commande reçue sur le site marchand ou prise par un commercial est retapée dans l’ERP, puis adresse de livraison et données de facturation sont recopiées dans le WMS, le TMS et la comptabilité.
Avec le système
Avec le système : Saisie une fois, partagée partout
Commandes, livraisons et factures naissent dans l’application qui en a la charge, laquelle publie un événement. Les autres applications s’y abonnent au lieu de ressaisir.
Aujourd’hui
Aujourd’hui : Un statut qui date de la veille
Les interfaces tournent en traitement de nuit : ADV, planification et comptabilité voient chacune une version différente et périmée de la même commande. Au client qui demande où en est sa livraison, on promet de rappeler.
Avec le système
Avec le système : Un statut à jour, le même pour tous
Chaque commande ou demande dispose d’un fil chronologique unique, construit à partir des événements de toutes les applications qu’elle traverse. ADV, planification et comptabilité partagent les mêmes faits, tout comme l’assistant conversationnel de relation client quand il répond aux questions de suivi.
Aujourd’hui
Aujourd’hui : Les anomalies traitées par e-mail
Rupture de stock, écart de prix, livraison non aboutie ou facture électronique rejetée : tout se règle par e-mail et sur tableur, sans trace de qui a décidé quoi.
Avec le système
Avec le système : Chaque anomalie arrive avec une proposition
Un agent IA rassemble les données qui expliquent l’anomalie et suggère une correction. Dans la file des anomalies, une personne l’accepte, l’ajuste ou la refuse, et sa décision est tracée.
Aujourd’hui
Aujourd’hui : Des données de référence contradictoires
Un même client, fournisseur, article ou tarif figure dans plusieurs applications avec des valeurs différentes, sans que personne soit chargé de trancher entre elles.
Avec le système
Avec le système : Un propriétaire pour chaque donnée
Clients, fournisseurs, articles et tarifs ont chacun un système maître convenu et un responsable nommé. Doublons et incohérences lui sont remontés, au lieu d’être corrigés discrètement en aval.
Aujourd’hui
Aujourd’hui : Une interface de plus à chaque évolution
Nouveau canal de vente, place de marché ou filiale : à chaque fois, une liaison point à point supplémentaire. La réforme de la facturation électronique ajoute encore, dans chaque processus, un format structuré et le passage par une plateforme agréée.
Avec le système
Avec le système : De nouveaux raccordements sur les mêmes contrats
Qu’il s’agisse d’un canal, d’une filiale ou d’une plateforme de facturation supplémentaire, le raccordement se fait une fois sur les API et événements documentés, et non application par application.
Workflow
Le parcours d’une commande, étape par étape
Avec des données fiables, le parcours nominal se déroule sans intervention manuelle. Dès qu’une commande, une livraison ou une facture dévie, la boucle d’anomalie la présente à une personne avec les justificatifs et une proposition, et la correction validée emprunte à nouveau la couche d’intégration.
Workflow illustratif
7 étapes · 1 contrôle humain
Légende
Système
Agent
Personne
Contrôle humain
Circuit d’exception
Flux de commande et de facturation : parcours illustratif et boucle d’anomalie
Lire le schéma sous forme de texte
Le parcours nominal commence par la saisie unique d’un événement métier dans son système maître, se poursuit par sa transmission aux autres applications via API et événements puis par la constitution d’un fil chronologique par commande, et mène à la facturation, au rapprochement et à l’encaissement. Il se conclut par l’analyse des flux, qui permet aux responsables de processus de corriger les causes des anomalies.
Quand une étape échoue, prend du retard ou dépasse une tolérance, l’anomalie quitte le parcours nominal après l’étape du fil chronologique. Un agent IA réunit le contexte et suggère une correction, qu’une personne accepte, ajuste ou refuse. L’action retenue est exécutée dans le système maître et rejoint l’étape de transmission sous la forme d’un nouvel événement.
La validation est le point de contrôle humain : ni écriture comptable, ni modification de prix ou d’encours autorisé, ni engagement envers un client sans l’accord d’une personne.
01
Étape 1 : Saisir l’événement à la sourceSystème
Commande client venue du site marchand, d’une place de marché, de l’EDI ou d’un commercial, commande fournisseur ou demande d’intervention : elle est créée dans l’application qui en est maîtresse. Celle-ci émet un événement métier au format CloudEvents, décrit par un contrat AsyncAPI. Les bons de commande papier ou PDF et les factures fournisseurs encore reçues en PDF passent d’abord par la lecture automatique des documents.
02
Étape 2 : Transmettre aux autres applicationsSystème
La couche d’intégration achemine l’événement vers le WMS, le TMS, la comptabilité et le CRM, au travers de leurs API documentées (OpenAPI). Les applications destinataires sont idempotentes : un message reçu deux fois ne déclenche jamais une deuxième expédition ou une deuxième facture, et un message non distribuable est placé en file d’erreurs, prêt à être rejoué.
03
Étape 3 : Reconstituer le fil de chaque commandeSystème
Les statuts émis par chaque application (commande confirmée, colis préparé puis expédié, livraison effectuée, facture émise, paiement reçu) sont rattachés à la référence métier pour former un fil chronologique unique. Des règles de jalons et de tolérance lèvent une anomalie quand une étape échoue, prend du retard ou ne concorde pas : rupture de stock, prix au-delà de la tolérance convenue, livraison non aboutie, facture électronique rejetée par la plateforme.
04
Étape 4 : Réunir le contexte et suggérer une correctionAgent
Pour chaque anomalie, un agent IA consulte dans les applications concernées ce qui lui est utile : la commande, l’état des stocks, l’accord tarifaire, le suivi du transporteur, les conditions commerciales du client. Il suggère une correction en exposant son raisonnement et les données employées : article de remplacement, prix rectifié, nouvelle date de livraison ou avoir.
Circuit d’exception : Échec, retard ou écart hors tolérance
05
Étape 5 : Valider selon les seuilsPersonne
Un collaborateur de l’ADV, de la logistique ou de la comptabilité consulte dans la file des anomalies le problème, les justificatifs et la proposition, puis l’accepte, l’ajuste ou la refuse. L’action retenue passe par l’API du système maître, qui publie la modification sous la forme d’un nouvel événement.
Circuit d’exception : Échec, retard ou écart hors tolérance· Retour à l’étape 2
Contrôle humain
Sans validation, un agent IA ne comptabilise rien, ne touche ni aux prix ni aux encours autorisés et ne prend aucun engagement envers un client. Les seuils fixés par type d’action désignent le valideur, et toutes les propositions et décisions sont tracées.
06
Étape 6 : Facturer, rapprocher, encaisserSystème
Les factures clients partent de l’ERP au format électronique structuré conforme à la norme EN 16931, via votre plateforme agréée, via Chorus Pro pour les acheteurs publics, ou via un point d’accès Peppol pour les clients établis dans un pays qui utilise ce réseau. Les factures fournisseurs reçues sont rapprochées des commandes et des bons de réception (rapprochement à trois voies), et le statut de paiement transmis par la banque ou le prestataire de paiement clôt le fil.
07
Étape 7 : Analyser les flux et corriger les causesPersonne
À un rythme convenu, les responsables de processus et l’équipe d’intégration passent en revue les anomalies par motif, les incidents d’interface et les incohérences de données de référence. Ils traitent la cause à sa source, qu’il s’agisse d’une fiche article ou tiers, d’une règle de tolérance ou d’une table de correspondance, plutôt que de corriger une fois de plus la même anomalie.
Composants
Ce que nous réaliserions
01
Couche d’intégration orientée événements
API et événements définis d’abord par leur contrat (OpenAPI, AsyncAPI, enveloppe CloudEvents) entre ERP, CRM, site marchand, WMS, TMS et comptabilité, sur votre plateforme d’intégration actuelle ou en services cloud natifs.
Pour chaque objet de données, un système maître et un responsable convenus, des règles de dédoublonnage des tiers et des articles, et des états des doublons et incohérences transmis à ceux qui en ont la charge.
Un service qui rattache les événements à chaque commande ou demande pour en former le fil, applique jalons et tolérances, et donne aux responsables de processus une vue des flux et des anomalies.
Une file de travail qui présente, pour chaque anomalie, le contexte réuni et la suggestion de l’agent, avec les actions accepter, ajuster et refuser ; les seuils de validation par type d’action sont appliqués là où l’action s’exécute.
Factures structurées conformes à l’EN 16931, contrôlées avant émission et échangées via votre plateforme agréée, Chorus Pro ou un point d’accès Peppol selon le destinataire, avec les données d’e-reporting préparées depuis l’ERP ; toute facture rejetée rejoint la file des anomalies.
Supervision et alertes par interface, consignes d’exploitation pour les équipes de MCO et rejeu contrôlé des messages en échec, le tout déployé dans votre tenant cloud sous forme d’infrastructure as code.
Commandes passées en ligne ou sur une place de marché
Messages EDI et autres échanges B2B de commandes
Commandes fournisseurs et accusés de réception de commande
Demandes d’intervention et comptes rendus des techniciens
Suivi des transporteurs et preuves de livraison
Factures électroniques et statuts retournés par la plateforme agréée
Relevés bancaires et avis de paiement
Cœur de la solution
Flux de commande et de facturation
Systèmes connectés
SAP S/4HANA : ventes, achats et financePlateformeSAP
Salesforce : Sales, Service et Commerce CloudPlateformeSalesforce
Odoo : ventes, stock, achats et comptabilitéPlateformeOdoo
API des transporteurs, sites marchands et places de marché
WMS et TMS (gestion d’entrepôt et de transport)
Plateforme agréée, Chorus Pro, banques et prestataires de paiement
PIM (référentiel produit) et plateforme de données
Contrôles
Contrôles et garde-fous intégrés
Périmètres d’accès
Chaque intégration, comme l’agent IA, dispose dans chaque application d’un compte de service qui lui est propre, restreint aux opérations d’API nécessaires. L’agent peut lire dans plusieurs applications pour réunir le contexte, mais n’agit qu’au travers d’une courte liste d’actions autorisées, exécutées par l’API du système maître, sans jamais écrire directement dans une base de données.
Revue humaine
Les seuils de validation se définissent par type d’action avec le responsable du processus : ce que l’agent peut seulement suggérer, ce qu’un membre de l’équipe valide, ce qui requiert un second valideur. Écritures comptables, changements de prix ou d’encours autorisé et engagements envers les clients attendent toujours une décision humaine. Les actions à faible enjeu et réversibles, comme relancer l’envoi d’un message en échec, peuvent s’exécuter seules si le responsable y consent.
Traçabilité
Événements, propositions, validations, refus et actions exécutées sont tous tracés sous la référence de la commande ou de la demande, avec les données consultées par l’agent, les versions du modèle et des consignes, et l’identité du valideur. Une facture contestée ou une réclamation client se reconstitue ainsi pas à pas.
Protection des données
Nom, adresse et contacts des clients et fournisseurs ne parviennent qu’aux applications qui en ont l’usage. Le fil chronologique ne garde que des références métier et des statuts, pas les fiches complètes, et les journaux respectent la durée de conservation que vous fixez. Les traitements restent dans la région convenue.
Transparence de l’IA
Dans la file des anomalies, chaque suggestion de l’agent IA est identifiée comme telle et affichée avec ses justificatifs et son raisonnement. Les systèmes maîtres font foi : le fil chronologique reflète ce qu’ils publient et ne les contredit jamais.
Indicateurs
Les indicateurs que nous proposerions
Ces indicateurs sont arrêtés avec vous pendant le cadrage, et leur niveau de départ est mesuré dans les journaux actuels de vos applications et interfaces, avant toute modification.
Les indicateurs que nous proposerions
Indicateur
Pourquoi c’est important
Comment nous le mesurerions
01Délai de traitement des commandes
Pourquoi c’est importantLe premier délai que perçoit le client, et celui qui révèle où les commandes stagnent.
Comment nous le mesurerionsDurée entre la réception de la commande et la livraison, puis l’encaissement, par canal et par filiale, d’après le fil chronologique.
02Commandes traitées sans intervention
Pourquoi c’est importantMesure la part du flux qui s’appuie sur des données fiables et des règles convenues.
Comment nous le mesurerionsProportion des commandes et demandes menées jusqu’à l’encaissement sans étape manuelle ni anomalie, d’après le fil chronologique.
03Volume d’anomalies par motif et temps de résolution
Pourquoi c’est importantIndique les causes à traiter en priorité et si la file des anomalies est absorbée à temps.
Comment nous le mesurerionsNombre d’anomalies par code motif et temps écoulé entre la détection et la correction exécutée, d’après l’historique de la file.
04Factures électroniques rejetées
Pourquoi c’est importantUn rejet retarde l’encaissement et trahit le plus souvent une donnée de référence ou une correspondance erronée.
Comment nous le mesurerionsPart des factures émises et reçues qui sont rejetées, par motif, d’après les statuts renvoyés par la plateforme agréée.
05Incidents d’interface et temps de rétablissement
Pourquoi c’est importantMontre si la couche d’intégration est fiable et si les incidents sont détectés et résolus rapidement.
Comment nous le mesurerionsMessages en échec par interface et temps écoulé entre l’incident et le rejeu réussi, d’après la supervision.
06Doublons et incohérences de données de référence
Pourquoi c’est importantLa plupart des anomalies trouvent leur origine dans des données qui divergent d’une application à l’autre.
Comment nous le mesurerionsDoublons non résolus et valeurs contradictoires par objet de données et par application, d’après les états de dédoublonnage.
Aucun objectif n’est fixé avant une mesure de référence.
Déploiement
Un déploiement en quatre temps
Phase 01
Cadrage et cartographie
Un processus, par exemple le cycle de vente d’un canal, et un type d’anomalie. Nous recensons les applications, les interfaces, les responsables de données et la manière dont les anomalies sont traitées aujourd’hui.
Critères de sortie
Processus, applications et responsables de données recensés
Premier type d’anomalie et seuils de validation arrêtés
Niveau de départ mesuré dans les journaux existants
Phase 02
Intégration et fil chronologique
API et événements documentés pour les applications du périmètre, et fil chronologique alimenté en parallèle des interfaces existantes, sans les modifier.
Critères de sortie
Contrats d’événements versionnés et publiés
Fil chronologique conforme aux systèmes maîtres sur un échantillon de commandes
Rejeu et consignes d’exploitation éprouvés en recette
Phase 03
Pilote de la file des anomalies
L’agent IA suggère des corrections pour le type d’anomalie retenu, et chaque suggestion est validée par une personne. Nous comparons ces suggestions avec ce qu’auraient fait vos équipes.
Critères de sortie
Qualité des suggestions conforme aux critères arrêtés
Seuils et valideurs définis par type d’action
Piste d’audit relue par la direction financière et le contrôle interne
Phase 04
Généralisation et arrêt des anciennes interfaces
Nouveaux types d’anomalies, canaux, filiales et processus, comme le cycle achats, tous sur les mêmes contrats. Les liaisons point à point historiques sont arrêtées l’une après l’autre.
Critères de sortie
Tout nouveau flux raccordé aux contrats et à la supervision communs
Fabrication à la commande et ventes de pièces détachées, de l’ERP jusqu’à l’entrepôt et aux transporteurs, avec accusés de réception fournisseurs et factures rapprochés des commandes.
Raccordements et mises en service suivis de l’ordre de travail jusqu’à la facturation, en passant par la visite du technicien, et achats de matériel passés sur accords-cadres.
Ordres de travaux de maintenance, commandes passées aux entreprises de travaux et factures correspondantes, suivis jusqu’au paiement pour un gestionnaire d’infrastructure.
Chaîne de la dépense publique : factures fournisseurs reçues via Chorus Pro, rapprochées des engagements et du service fait avant mise en paiement.
Exemple illustratif
Les factures fournisseurs d’une ETI industrielle
Situation
Une ETI industrielle reçoit une part croissante de ses factures fournisseurs au format structuré via sa plateforme agréée, mais les rapproche encore à la main des commandes et des réceptions saisies dans l’ERP. Les écarts de prix et de quantité se règlent par e-mail avec les acheteurs.
Système
Commandes fournisseurs, accusés de réception de commande, bons de réception et factures sont publiés comme événements par l’ERP, l’entrepôt et la plateforme agréée, et chaque commande d’achat a son fil chronologique. Le rapprochement facture, commande et réception se fait sans intervention tant que les écarts restent dans les tolérances convenues.
Contrôle humain
Au-delà des tolérances, l’écart arrive dans la file des anomalies avec une suggestion de l’agent IA : avoir à demander, réception à corriger ou prix à confirmer. L’acheteur ou le comptable fournisseurs valide, et aucun paiement n’est libéré sans cette validation.
Ce que nous mesurerions
Part des factures rapprochées sans intervention, écarts par motif et temps de résolution, et part des factures électroniques rejetées.
France
La réforme de la facturation électronique dans le flux
En France, depuis le 1er septembre 2026, toutes les entreprises assujetties à la TVA doivent pouvoir recevoir des factures électroniques, et les grandes entreprises comme les entreprises de taille intermédiaire doivent les émettre et transmettre leurs données de transaction (e-reporting). Les PME et les microentreprises suivent le 1er septembre 2027. Les factures passent par des plateformes agréées, et celles adressées au secteur public par Chorus Pro.
Nous raccordons l’ERP à la plateforme agréée par la même couche d’événements que le reste du processus : les statuts de facture alimentent le fil chronologique de chaque commande, et une facture rejetée arrive dans la file des anomalies avec ses données et une proposition de correction.
Vos questions sur les flux de commande et de facturation
01Faut-il tout regrouper dans une seule plateforme ?
Non. ERP, CRM, site marchand et WMS gardent chacun leur rôle. Nous intégrons autour de ces systèmes maîtres, convenons de l’application qui fait foi pour chaque donnée et donnons au processus un fil chronologique commun. Si un ERP ou un outil de gestion des commandes vieillissant freine les évolutions, la modernisation des applications patrimoniales commence par l’exposer derrière des API.
Pas s’il fonctionne. Nous nous appuyons sur la plateforme d’intégration ou le bus de messages déjà en place, et ajoutons contrats, supervision et rejeu là où ils font défaut. À défaut de plateforme, nous construisons en services cloud natifs. Voir nos services d’intégration et d’API.
03Les agents IA peuvent-ils agir sans validation ?
Seulement dans les seuils que vous fixez par type d’action, et pour des actions à faible enjeu et réversibles, comme relancer l’envoi d’un message. Écritures comptables, prix, encours autorisés et engagements envers les clients passent toujours par une personne. Voir notre analyse : agents IA, où placer la validation humaine.
04Où s’inscrit la réforme de la facturation électronique ?
Depuis le 1er septembre 2026, toute entreprise assujettie à la TVA doit pouvoir recevoir des factures électroniques, et les grandes entreprises comme les ETI doivent aussi en émettre et transmettre leurs données de transaction (e-reporting) ; ces obligations s’étendent aux PME et microentreprises le 1er septembre 2027. À l’échelle européenne, le paquet « TVA à l’ère numérique » (ViDA) étendra la facture électronique structurée aux échanges intra-UE entre entreprises. Dans notre architecture, la facture est un événement du processus parmi d’autres : émise par l’ERP, transmise par votre plateforme agréée ou par Chorus Pro, et orientée vers la file des anomalies en cas de rejet. Pour aller plus loin, lisez notre article sur la réforme de la facturation électronique.
05Comment éviter de recréer un enchevêtrement de liaisons point à point ?
Les applications publient et consomment des événements et des API documentés au travers d’une couche unique, sans liaison directe entre elles. Les contrats sont versionnés, les destinataires idempotents, les messages en échec rejouables, et chaque flux a un responsable nommé. Un canal supplémentaire s’abonne aux événements existants au lieu de multiplier les liaisons.
06Par où commencer ?
Par un processus et un type d’anomalie, par exemple le cycle de vente d’un canal, avec les ruptures de stock comme première anomalie traitée. Ce périmètre éprouve les événements, le fil chronologique et le circuit de validation avant toute extension. Notre démarche, du cadrage à l’exploitation, détaille la suite.
Parlons de vos cycles de vente et d’achat
Prenez un processus, cycle de vente ou cycle achats, et les applications par lesquelles il passe. Nous en cartographierons avec vous les interfaces, les anomalies et le raccordement à votre plateforme agréée.