Cette série a commencé avec comment le Model Context Protocol, la norme ouverte publiée par Anthropic en 2024, s'intègre à une API de fret, puis a fait tomber les serveurs MCP de fret qui ont été expédiés en 2026, puis a couvert comment en sécuriser un. Les 3 parties précédentes s'arrêtent au même point : l'agent a réservé un chargement. Cette partie décrit ce qui se passe ensuite, et c'est la partie avec laquelle les entreprises ont réellement du mal. Une réservation qui n'atterrit jamais dans le système d'information officiel n'est pas une réservation à laquelle votre équipe financière fait confiance. La vraie question d'intégration n'est donc pas "l'agent peut-il réserver", mais "l'agent peut-il réécrire cette réservation dans SAP, Oracle ou NetSuite sans casser le grand livre".
J'écris ceci du côté de la place de marché, où nous exposons les réservations via une API et observons comment les clients les intègrent dans leur back-office. L'appel de réservation est la partie facile. Le retour d'écriture est là où le temps d'ingénierie est consacré.
Pourquoi le retour écrit est la partie difficile
La réservation d'une cargaison est une action simple et satisfaisante. La réconciliation est une longue série d'au moins 4 obligations distinctes. L'expédition doit apparaître comme un enregistrement que quelqu'un des finances reconnaît. Son coût doit être imputé au bon compte. Son statut doit être mis à jour au fur et à mesure que le camion avance. Lorsque la facture du transporteur arrive, le chiffre final doit être réglé par rapport à l'estimation initiale. Chacune de ces opérations est une écriture distincte dans un système conçu bien avant que quiconque n'imagine un agent d'IA tenant la plume.
Si vous vous trompez, les dégâts sont discrets mais réels. Une commande de fret en double gonfle les provisions. Une réservation qui ne se synchronise jamais laisse un envoi en mouvement sans coût associé. Un statut qui cesse de se mettre à jour ramène un dispatcher à des appels de contrôle manuels, ce qui est exactement le travail que l'agent était censé supprimer. L'agent fait bonne impression lors de la démo et crée un arriéré de réconciliation en production.
Le flux de référence, de bout en bout
Supprimez les noms de fournisseurs et toute installation fonctionnelle suit le même chemin. L'agent s'exécute dans un assistant tel que Claude ou Copilot. Il appelle la place de marché MCP pour obtenir un devis, puis pour réserver. L'appel de réservation renvoie un identifiant de réservation et un coût structuré. L'agent, ou un service léger derrière lui, écrit ensuite ce résultat dans l'ERP en tant qu'enregistrement de fret, et à partir de là, l'ERP est la source de vérité tandis que la place de marché l'alimente en mises à jour.
- **Citez et réservez** via la place de marché MCP. La réponse de réservation inclut un identifiant de réservation stable et une répartition des coûts, pas seulement un total.
- **Créer l'enregistrement de fret** dans l'ERP, estampillé de cet identifiant de réservation pour que le lien survive.
- État de la synchronisation au fur et à mesure que l'expédition progresse, idéalement à partir d'événements plutôt qu'une boucle de scrutation qui sature l'API.
- **Réglez les coûts** lorsque la facture du transporteur arrive, en faisant correspondre le chiffre final avec l'estimation initiale.
L'identifiant de réservation est la colonne vertébrale de l'ensemble du flux. C'est la valeur qui permet à chaque étape ultérieure de trouver l'enregistrement auquel elle appartient, et c'est la valeur qui rend une nouvelle tentative sûre au lieu d'être dangereuse.
Mappage d’une réservation de fret sur le modèle objet ERP
Les 3 systèmes les plus utilisés par les équipes de fret enregistrent la même réservation sous des formes sensiblement différentes, de sorte que la correspondance est l'endroit où les plans d'intégration réussissent ou échouent. Le tableau croisé ci-dessous est celui que nous remettons aux clients lorsqu'ils demandent quel champ va où.
| Champ de la place de marché | SAP TM | NetSuite / Oracle |
| Identifiant de réservation | Numéro de bon de commande de fret | Clé sur le reçu d'article ou le bon de commande |
| Coût estimé | Coût estimé de la commande de fret | Coût estimé rendu à destination |
| Facture du transporteur | Document de règlement de fret | Coût réel d'acquisition via la comptabilité des reçus |
| Jalons de statut | Événements de commande de fret | Réception et état de la préparation des articles |
Le coût arrive rarement en un seul chiffre, donc la répartition est également cartographiée. Le transport principal et le carburant sont connus à la réservation et apparaissent comme le coût de fret estimé. Les frais accessoires tels que la détention ou les frais de décharge apparaissent généralement uniquement sur la facture du transporteur, ils se retrouvent donc dans le document de règlement du fret au moment du règlement plutôt que dans la commande de fret d'origine.
SAP Transportation Management
SAP TM modélise le trajet comme une commande de fret, et l'argent comme un document de règlement de fret distinct. Cette séparation est utile, car elle permet de créer l'enregistrement opérationnel lors de la réservation et de poster la partie financière plus tard, au moment du règlement de la facture. Un agent saisissant des informations dans SAP TM devrait créer la commande de fret au moment de la réservation et laisser le règlement pour la facture du transporteur, plutôt que d'imposer un coût final à un enregistrement qui n'en a pas encore.
Oracle et NetSuite
Oracle et NetSuite s'appuient sur le cycle d'achat et de réception, où le fret a tendance à apparaître comme un coût d'acquisition réparti sur les marchandises qu'il a transportées. Ici, le travail de l'agent est de rattacher la réservation et son coût au bon bon de commande ou à la bonne réception de marchandise, afin que les frais de fret suivent le stock au lieu de flotter comme une charge orpheline. L'estimation est comptabilisée à la réservation, le réel est mis à jour au règlement, et le coût d'acquisition est recalculé à partir de là.
La leçon à retenir pour les trois est de respecter le modèle dans lequel vous écrivez. Une réservation de marché est un objet de notre côté. Du côté de l'ERP, elle devient 2 enregistrements, un opérationnel et un financier, et les intégrations les plus propres maintiennent ces 2 éléments séparés.
Idempotence : le piège qui double les réservations
Les réseaux tombent en panne en plein appel. Un agent réessaie. Sans protection, cette nouvelle tentative crée une deuxième commande de fret pour un envoi qui en a déjà une, et vos provisions sont alors erronées d'une manière que personne ne remarque avant la fin du mois. L'idempotence est la solution, et elle est obligatoire lorsque de l'argent est en jeu.
Le schéma est simple. Chaque écriture qui crée ou valide un enregistrement porte une clé d'idempotence, et l'identifiant de réservation est celui qui convient. Le service orienté ERP vérifie si un enregistrement existe déjà pour cette clé avant d'écrire. Si c'est le cas, le service met à jour plutôt qu'il n'insère, ou retourne simplement l'enregistrement existant. Une nouvelle tentative devient alors une opération nulle sûre au lieu d'un doublon. Lorsque nous exposons une réservation via notre MCP, nous retournons un identifiant stable pour cette raison exacte, afin que le back-office dispose d'un point d'ancrage fiable sur lequel bâtir des écritures idempotentes. Le schéma consiste à vérifier l'existence d'un enregistrement indexé par l'identifiant de réservation avant d'écrire : s'il en existe un, on le met à jour, sinon on crée la commande de fret. La première exécution crée, chaque nouvelle tentative après un délai d'attente met à jour le même enregistrement, et un réseau instable ne coûte rien de plus qu'une recherche redondante.
Identité au-delà de la frontière
Un agent agissant seul n'est pas une personne, et l'ERP veut savoir qui a changé quoi. L'approche propre consiste en une identité de service dédiée à l'intégration, limitée aux quelques actions qu'elle effectue réellement, plutôt qu'à un agent empruntant les autorisations étendues d'un utilisateur humain. Un compte de service capable de créer des bons de commande de fret et de valider les règlements, et rien d'autre, maintient un rayon d'action limité et une piste d'audit honnête. Il s'agit de la même logique de portée, du moindre privilège, issue de l'partie sécurité de cette série, transposée du côté ERP.
Ce qu'un MCP devrait exposer pour rendre la réécriture propre
Un serveur à porteuse unique peut être vague sur son objet de réservation car il n'y a qu'une seule forme à apprendre. Un serveur de place de marché ne peut pas, car le client se réconcilie auprès de nombreux transporteurs dans un seul grand livre. 3 éléments font la différence.
- Un identifiant de réservation stable qui ne change jamais pendant toute la durée du transport, de sorte que l'enregistrement ERP reste lié à chaque mise à jour.
- Une répartition structurée des coûts, et non un total unique, afin que le transport principal, le carburant et les frais accessoires puissent être associés aux bons comptes et que l'étape de règlement dispose d'éléments pour la réconciliation.
- Statut en tant qu'événements, ainsi l'ERP est informé d'une étape importante lorsqu'elle se produit au lieu de sonder un changement qui pourrait ne pas survenir pendant des heures.
Lorsque ces trois éléments sont présents, le retour d'information de l'ERP est principalement déterministe. Lorsqu'ils sont absents, chaque client reconstruit la même colle fragile, et la réservation de l'agent devient un problème de réconciliation qui prend un déguisement pratique.
Une liste de contrôle de référence avant de connecter un agent au grand livre
- Ancrez chaque écriture ERP à l'identifiant de réservation du marketplace, et faites de cet identifiant la clé d'idempotence.
- Créez l'écriture d'exploitation au moment de la réservation, et enregistrez le règlement financier lorsque la facture est réglée, et non avant.
- Répartissez la ventilation des coûts sur les comptes de manière délibérée, plutôt que de ne reporter qu'un total unique sur une seule ligne.
- Récupérez l'état du disque à partir des événements quand c'est possible, et revenez à l'interrogation avec un intervalle raisonnable uniquement en dernier recours.
- Donnez à l'intégration sa propre identité de service isolée, jamais une connexion humaine générique.
- Rapprocher les estimations des montants réels lors du règlement, et signaler l'écart plutôt que de l'écraser silencieusement.
Rien de tout cela n'est propre aux agents. C'est la discipline dont toute intégration de fret système à système a déjà besoin. L'agent rend simplement la réservation plus rapide, ce qui signifie que la mise à jour doit être tout aussi fiable pour suivre le rythme.
Foire aux questions
Un agent IA peut-il écrire une réservation de fret directement dans SAP ou NetSuite ?
Oui, via l'API de l'ERP lui-même et une identité de service limitée, avec l'ID de réservation du marketplace utilisé comme clé d'idempotence afin que les nouvelles tentatives ne créent pas de doublons. L'agent propose l'écriture, mais un service léger devrait l'effectuer contre l'ERP afin que la logique reste testable et que les permissions restent restreintes.
Qu'est-ce qui échoue le plus souvent dans les écritures de retour d'un ERP ?
Doublons d'enregistrements dus à des tentatives non surveillées, et coûts qui ne s'ajustent jamais car l'intégration publie une estimation sans jamais la rapprocher de la facture du transporteur. Ces deux problèmes sont résolus en ancrant les écritures à un identifiant de réservation stable et en maintenant les étapes opérationnelles et financières séparées.
Pourquoi l'identifiant de réservation est-il si important ?
C'est le lien entre la place de marché et le grand livre. Chaque mise à jour de statut, document et règlement trouve son enregistrement grâce à cet identifiant, et il sert également de clé d'idempotence qui rend une nouvelle tentative sûre. Un objet de réservation sans identifiant stable oblige le back-office à deviner, ce qui est à l'origine des doublons et des coûts orphelins.
Les mises à jour de statut doivent-elles être interrogées ou poussées ?
Poussé là où le marketplace prend en charge les événements, car le sondage retarde soit les jalons réels, soit surcharge l'API pour rester à jour. Une intégration pragmatique utilise les événements pour les moments importants et un intervalle de sondage modeste en guise de solution de secours.
Ceci conclut la série MCP en 4 parties, à jour en 2026. Si vous êtes arrivé ici en premier, commencez par l'catalogue de protocoles, consultez les serveurs expédiés dans l'démontage et sécurisez le tout avec l'Guide de sécurité.