Le risque d’un flux ERP–WMS n’est pas seulement de perdre un message. Il est de publier dix unités disponibles alors que huit sont déjà réservées, de créer deux missions après un timeout ou de considérer une préparation partielle comme une expédition complète. Le stock affiché paraît cohérent jusqu’au moment où l’entrepôt ne peut plus servir la promesse faite au client et où le support doit reconstruire l’histoire à la main.
Ce n’est pas la copie la plus récente qui fait foi, c’est le système autorisé à décider chaque transition. Le vrai sujet consiste donc à répartir les responsabilités : l’ERP porte les documents commerciaux et financiers selon l’organisation, tandis que le WMS observe les opérations physiques, les emplacements et les confirmations. Entre les deux, l’intégration doit préserver le sens des mouvements au lieu d’écraser un chiffre par un autre.
Vous verrez comment définir cette autorité, structurer missions et confirmations, traiter les messages hors ordre et rapprocher les soldes sans masquer les écarts. Une intégration API sur mesure devient fiable lorsque chaque quantité peut être reliée à une opération physique, une décision métier et une procédure de reprise connue.
Attribuer une autorité à chaque état du stock
Demander si l’ERP ou le WMS est « maître du stock » produit une réponse trop grossière. L’ERP peut décider qu’une commande est engageable, tandis que le WMS sait ce qui est réellement présent, bloqué, endommagé ou en cours de préparation dans un dépôt. La responsabilité doit être attribuée par état et par transition : réservation commerciale, allocation à un entrepôt, prélèvement, contrôle, expédition, réception, retour et correction d’inventaire.
Une matrice d’autorité nomme pour chaque décision le producteur autorisé, les consommateurs, le moment où elle devient définitive et le mécanisme de correction. Le middleware n’est jamais désigné comme source de vérité par facilité. Il transporte, transforme et rapproche les faits ; il ne crée pas une nouvelle réalité parallèle lorsqu’un système tarde à répondre.
Cette matrice révèle les conflits avant le développement. Si l’ERP peut annuler une ligne après le début du picking, le WMS doit savoir si la mission est encore révocable, partiellement compensable ou déjà irréversible. Si le WMS classe une unité en quarantaine, l’ERP doit comprendre l’impact sur le disponible commercial. Chaque frontière devient alors un contrat, pas une convention orale entre deux équipes.
Aligner SKU, dépôts, unités et identifiants
Une synchronisation échoue souvent avant le premier mouvement parce que les référentiels ne désignent pas les mêmes objets. Un SKU ERP peut correspondre à plusieurs codes logistiques, à un conditionnement ou à une unité de vente différente. Un dépôt commercial peut regrouper plusieurs sites WMS. Une quantité de « 1 » peut signifier une pièce, un carton ou une palette selon le message.
Le mapping conserve l’identifiant de chaque système, sa période de validité et la règle de conversion. Il refuse les correspondances ambiguës et place en attente un produit inconnu au lieu de l’associer au premier libellé ressemblant. Une modification de SKU ou d’unité produit une nouvelle version ; elle ne réécrit pas l’historique des missions déjà exécutées.
Les clés techniques comprennent au minimum le système source, l’entreprise ou le tenant, le dépôt, l’objet métier et son identifiant externe. Cette composition empêche qu’une mission 12345 provenant d’un site soit confondue avec la même valeur dans un autre. Le dossier de corrélation garde aussi la commande, la ligne, le SKU et la mission afin que le support puisse remonter du mouvement physique au document ERP.
Synchroniser des mouvements plutôt qu’un chiffre isolé
Un solde de stock indique une situation, pas sa cause. Deux systèmes peuvent afficher cent unités tout en racontant des histoires incompatibles : l’un a oublié un retour, l’autre a compensé une casse par une correction manuelle. Synchroniser uniquement le dernier total rend l’écart invisible et empêche de distinguer une erreur de transport d’une opération d’entrepôt légitime.
Le modèle robuste transporte des mouvements identifiés : réception, réservation, libération, prélèvement, remise en stock, quarantaine, ajustement ou expédition. Chaque mouvement précise la quantité signée, l’unité, le dépôt, la date métier, la cause et la référence physique ou commerciale. Le solde reste utile comme contrôle, mais il est rapproché avec la somme des faits plutôt qu’utilisé pour effacer leurs différences.
Le mouvement doit rester immuable après acceptation. Une erreur se corrige par une compensation reliée à l’écriture initiale, pas par la modification silencieuse d’un ancien événement. Cette règle rend l’audit possible et protège les périodes déjà clôturées. Elle permet aussi de rejouer une projection ERP sans réexécuter l’opération physique dans le WMS.
Donner un cycle de vie explicite aux missions
Une mission WMS n’est pas un simple ordre envoyé puis oublié. Elle peut être créée, acceptée, planifiée, commencée, partiellement exécutée, bloquée, annulée ou terminée. Les noms exacts dépendent du produit, mais l’intégration doit traduire ces états vers un cycle interne stable et conserver le statut brut pour le diagnostic.
La création porte une version de la commande et une liste de lignes avec quantité attendue, dépôt et contraintes utiles. Une modification après acceptation n’écrase pas la mission en cours. Elle devient une demande d’amendement ou d’annulation dont la faisabilité dépend de l’état physique. Cette séparation évite qu’une ligne déjà prélevée disparaisse du WMS parce que l’ERP a renvoyé une représentation plus récente de la commande.
Le statut terminal est défini par effet, pas seulement par libellé. Une mission « terminée » peut comporter un reliquat, une substitution ou une unité endommagée. Le flux ne ferme la commande qu’après lecture des confirmations de ligne. Il conserve la différence entre quantité demandée, allouée, prélevée, contrôlée et expédiée afin que la suite du processus sache ce qui peut être facturé, réaffecté ou remboursé.
Traiter les confirmations partielles comme des faits
Une confirmation décrit ce qui s’est produit dans l’entrepôt. Elle ne doit pas être réduite à un booléen « mission réussie ». Une préparation peut être partielle, répartie sur plusieurs colis, exécutée en plusieurs vagues ou interrompue après un contrôle. Chaque confirmation précise sa portée, sa quantité et l’état auquel elle contribue.
Le consommateur cumule les confirmations sans dépasser la quantité autorisée et sans compter deux fois le même effet. Il distingue un complément d’une correction. Si le WMS envoie d’abord trois unités puis deux, le résultat attendu peut être cinq ; s’il remplace une confirmation erronée de trois par une valeur de deux, le contrat doit fournir une version ou une compensation explicite. Sans cette sémantique, le middleware invente une règle et fabrique du stock.
Le refus porte une cause exploitable : article inconnu, quantité indisponible, lot bloqué, adresse logistique invalide ou annulation trop tardive. L’ERP ne transforme pas tous ces cas en « erreur WMS ». Il déclenche la décision adaptée : corriger une donnée, créer un reliquat, changer de dépôt ou demander une intervention physique.
Fermer une mission ne termine pas une vente Shopify
Lorsque le WMS agit dans le parcours d’un service de traitement Shopify, une mission terminée avec un manque laisse une autre décision ouverte. Le relais au marchand après une fin de traitement 3PL distingue les confirmations connues et l’impossibilité de poursuivre. L’acteur qui transmet l’information ne possède pas nécessairement le rôle autorisé à terminer la demande.
Le contrat garde le travail visé, les unités restantes et l’application qui a accepté le parcours. Il qualifie ensuite le résultat et la prochaine responsabilité. Le manque ne devient ni une expédition fictive ni une modification de stock destinée à obtenir un statut complet dans la boutique.
Séparer stock physique, réservé et disponible
Le stock physique, le stock réservé et le stock disponible ne sont pas trois noms pour le même nombre. Le physique répond à la présence constatée ; la réservation représente un engagement ; le disponible dépend d’une politique commerciale qui peut retirer quarantaine, sécurité, commandes prioritaires ou quantités non vendables. Une formule universelle serait trompeuse : chaque composant doit être défini et attribué.
L’intégration publie donc des dimensions nommées plutôt qu’un champ générique quantity. Le front ou l’OMS consomme la disponibilité adaptée à sa promesse, tandis que la finance peut conserver une lecture différente. Si un buffer commercial est calculé hors WMS, il reste identifiable et ne revient jamais dans le WMS comme s’il s’agissait d’une opération physique.
Un stock négatif n’est pas corrigé automatiquement par une valeur nulle. Il signale une dette de réservation, un événement manquant ou une correction tardive. Le masquer préserverait l’affichage au prix d’une perte d’information. Le système bloque la diffusion concernée, ouvre un écart et garde la valeur source jusqu’à l’arbitrage.
Protéger chaque effet métier contre les doublons
Un timeout après l’envoi d’une mission ne prouve pas son absence dans le WMS. Le retry doit d’abord rechercher la mission à partir de la clé fonctionnelle convenue. Une nouvelle tentative qui change d’identifiant technique à chaque appel contourne l’idempotence et peut déclencher deux préparations physiques pour la même ligne de commande.
La clé associe l’intention et son périmètre : source, dépôt, commande, ligne, version et type d’effet. Une correction ou un reliquat reçoit une nouvelle identité liée à la précédente ; une répétition réseau conserve la même. Côté réception, une inbox enregistre les identifiants déjà appliqués et le résultat produit afin de répondre de manière stable à un doublon.
L’idempotence ne se limite pas à l’écriture en base. Une confirmation répétée ne doit ni décrémenter deux fois le stock, ni recréer une facture, ni renvoyer un nouvel email. La transaction locale associe l’enregistrement du message, la mutation métier et l’événement de sortie. Lorsque ces actions traversent plusieurs systèmes, un rapprochement vérifie l’effet final avant de déclarer le dossier terminé.
Résoudre retards, désordre et concurrence
Les événements arrivent rarement dans un ordre parfait. Une confirmation peut dépasser une mise à jour de mission, un retour peut être reçu avant l’avis ERP correspondant ou deux opérateurs peuvent modifier le même dossier. Trier par heure de réception ne rétablit pas l’ordre métier, surtout lorsque les horloges et files diffèrent.
Chaque flux conserve l’heure métier, l’heure d’émission, l’heure de réception et une version ou séquence lorsque la source en fournit une. La règle de conflit dépend de l’objet : une version plus récente peut remplacer un état déclaratif, alors qu’un mouvement historique tardif doit encore être comptabilisé. Le contrat dit quelles transitions sont monotones et lesquelles peuvent être compensées.
Si deux décisions concurrentes ne peuvent pas être ordonnées, le dossier passe en quarantaine. Une écriture automatique fondée sur « le dernier arrivé gagne » serait rapide mais non prouvable. Le support reçoit les deux versions, leur origine et les effets déjà appliqués pour choisir entre rejet, compensation ou nouvelle mission.
Couvrir réceptions, retours et inventaires
Limiter le projet au flux de préparation produit une disponibilité fausse dès la première réception ou le premier retour. Le WMS observe les quantités reçues, acceptées, mises en quarantaine puis rangées. L’ERP peut avoir besoin de ces étapes pour valoriser le stock, libérer une commande fournisseur ou rendre une unité de nouveau vendable.
Un retour client ne redevient pas disponible à son arrivée sur le quai. Il traverse un contrôle qui peut conduire à la remise en stock, au reconditionnement, à la casse ou au retour fournisseur. Chaque issue produit un mouvement distinct et conserve la référence du retour. La décision commerciale de rembourser et la décision physique de remettre en vente restent corrélées sans être confondues.
L’inventaire et le comptage cyclique génèrent des ajustements qui exigent une cause, un opérateur ou une procédure et une période. Une différence ne doit pas être diffusée comme un simple nouveau snapshot. Le mouvement d’ajustement ferme l’écart observé, tandis que le rapprochement vérifie qu’aucune mission en cours n’explique temporairement la quantité manquante.
Conserver lots, séries et dates de péremption
Pour les produits tracés, un total par SKU est insuffisant. Le lot, le numéro de série, la date de péremption, le statut qualité et parfois l’emplacement déterminent ce qui peut être préparé. Une agrégation prématurée peut rendre la quantité globale correcte tout en attribuant au client le mauvais lot ou une unité bloquée.
Le contrat transporte ces dimensions lorsqu’elles influencent la décision. Il vérifie leur format, leur caractère obligatoire et leur unicité dans le périmètre convenu. Une série déjà expédiée, un lot inconnu ou une date incohérente arrête la ligne concernée ; le reste de la mission peut suivre la règle de traitement partiel définie par le métier.
La traçabilité traverse aussi les corrections. Une compensation référence le lot ou la série d’origine afin que l’historique reste exploitable pour une recherche qualité ou un rappel. Le système ne remplace jamais une série par une autre uniquement pour équilibrer la quantité comptable.
Absorber la charge sans perdre les priorités
Une file protège l’ERP et le WMS d’un pic, mais elle peut également retarder silencieusement une réservation critique derrière des milliers de mises à jour peu urgentes. Les flux sont séparés selon leur effet : missions à lancer, confirmations attendues, référentiels et réconciliations ne partagent pas nécessairement la même priorité ni le même budget de retry.
Le monitoring suit la profondeur, le débit et surtout l’âge du plus ancien message par classe. Une file volumineuse de mouvements récents peut être saine, alors que quelques confirmations bloquées au-delà du délai métier peuvent couper une promesse client. Par exemple, si l’âge du plus ancien dossier franchit le seuil convenu pour les expéditions du jour, alors les nouvelles missions de la cohorte sont suspendues pendant que le canal de confirmation est rattrapé.
Le backoff et le circuit breaker évitent d’aggraver une panne du partenaire. La DLQ n’est pas un cimetière : chaque motif possède un propriétaire, un délai de traitement et une procédure de remise en file après correction. Le rejeu conserve l’identifiant et la version du mapping utilisés afin de ne pas transformer un ancien message sans décision explicite.
Rapprocher missions, mouvements et soldes
L’absence d’erreur technique ne prouve pas l’égalité des stocks. Un rapprochement périodique compare les missions demandées et acceptées, les confirmations reçues, les mouvements appliqués et les soldes par SKU et dépôt. Il distingue un retard normal d’un écart durable grâce à une fenêtre définie selon le processus physique.
Le contrôle descend au niveau nécessaire pour expliquer l’écart. Un delta global de cinq unités peut masquer un surplus sur un dépôt et un manque sur un autre. Pour les articles tracés, il descend au lot ou à la série. Chaque anomalie conserve les derniers événements connus, la version de mapping et les opérations encore en cours afin d’éviter une correction pendant une transition légitime.
La correction ne consiste pas systématiquement à pousser le solde du système déclaré maître. L’équipe détermine d’abord la cause : événement perdu, mouvement en double, erreur de référentiel, opération physique non saisie ou projection obsolète. Elle rejoue, compense ou demande un contrôle d’entrepôt selon cette cause, puis vérifie que le prochain rapprochement ferme réellement l’écart.
Cas concret : une mission demande dix unités, le WMS en confirme sept, en classe une comme endommagée et laisse deux unités sans état terminal. Le rapprochement ne publie ni sept ni dix comme solde de remplacement. Il vérifie les mouvements déjà appliqués, ouvre un reliquat pour les deux unités et maintient l’unité endommagée hors du disponible jusqu’à sa décision physique.
Rendre chaque écart explicable au support
Une alerte utile nomme le dépôt, le SKU, la commande ou mission, l’état attendu, l’état observé et la prochaine action. Elle permet de retrouver la chronologie sans requête ad hoc : émission ERP, acceptation WMS, confirmations, mouvements, retries et décisions manuelles. Les payloads sensibles restent protégés, mais leur empreinte et leur version de schéma rendent la preuve comparable.
Les tableaux de bord séparent disponibilité technique et santé métier. Ils suivent missions non acceptées, confirmations en retard, écarts de rapprochement, doublons bloqués, messages en quarantaine et âge de la DLQ. Une API verte peut coexister avec une réserve de stock qui ne baisse plus ; ce signal doit devenir visible avant la survente.
Le journal d’audit associe chaque action manuelle à une identité, une raison et une preuve. Une modification directe dans l’ERP ou le WMS sans corrélation recrée une divergence au prochain cycle. Le support utilise donc une commande de reprise qui journalise la décision, cible l’effet précis et relance le contrôle final.
Définir le mode dégradé avant la panne
Lorsque le WMS est indisponible, l’ERP ne doit pas continuer indéfiniment à promettre le dernier stock connu. Le mode dégradé précise la durée de fraîcheur acceptable, le buffer éventuel et les opérations à suspendre. Selon l’activité, il peut autoriser la consultation, accepter des commandes sans les confirmer ou bloquer les SKU dont la disponibilité n’est plus opposable.
Lorsque l’ERP est indisponible, le WMS peut parfois terminer des missions déjà acceptées, mais il ne doit pas inventer les documents commerciaux suivants. Les confirmations sont conservées dans une file durable, avec leur ordre et leurs identifiants, puis réconciliées à la reprise. Un fichier manuel parallèle n’est admis que s’il possède un format, un responsable et une procédure d’import contrôlée.
La sortie du mode dégradé s’effectue par paliers. Les lectures reviennent d’abord, puis les confirmations en attente sont rapprochées avant l’ouverture de nouvelles missions. Un échantillon contrôlé confirme que les projections se recalent. Le flux nominal ne reprend qu’après fermeture ou attribution explicite des écarts accumulés.
Savoir quand cette intégration est prête
Le chantier devient pertinent lorsque les volumes ou le nombre de dépôts rendent les doubles saisies dangereuses, que le WMS expose des interfaces stables et que l’organisation sait nommer l’autorité de chaque état. Il apporte une forte valeur aux équipes logistiques, commerce et support qui doivent partager la même histoire sans attendre une consolidation manuelle de fin de journée.
Il doit être différé si les SKU et unités ne sont pas alignés, si les corrections physiques ne sont pas enregistrées ou si personne ne décide du traitement d’un reliquat. Dans ce cas, l’automatisation accélérerait les divergences. Un inventaire des référentiels, une matrice d’autorité et un rapprochement en lecture seule constituent une première étape plus sûre.
Il faut refuser une bascule complète tant que l’équipe ne sait pas retrouver une mission, expliquer une confirmation partielle et réconcilier un timeout ambigu. Une interface technique peut être terminée tout en restant inexploitable. La preuve de maturité est une reprise menée par le support, pas une démonstration nominale conduite par les développeurs.
Écrire un contrat technique vérifiable
Enveloppe commune et identité métier
Chaque événement porte un identifiant unique, le type d’intention, la source, le dépôt, la date métier, la date d’émission, la version du schéma et une clé de corrélation. Le payload métier contient ensuite les identifiants de commande, ligne, mission, SKU et quantité utiles à l’effet. Les champs absents, nuls et égaux à zéro possèdent une sémantique distincte.
Le contrat documente les entrées, sorties, responsabilités, seuils de monitoring, règles d’idempotence et stratégie de rollback. Il précise ce qui est obligatoire pour créer, modifier, annuler ou confirmer une mission. Une dépendance non disponible conduit à un statut et une file connus ; elle ne transforme jamais une donnée manquante en ordre de suppression.
{
"eventId": "evt_01…",
"eventType": "wms.pick.confirmed",
"schemaVersion": 2,
"warehouseId": "WH-LYON",
"missionId": "PICK-8472",
"orderLineId": "SO-2048-3",
"sku": "SKU-441",
"quantity": { "value": 4, "unit": "EA" },
"occurredAt": "2026-10-01T08:42:15Z"
}Évolution et compatibilité
Ajouter un champ optionnel peut être compatible sur le plan syntaxique tout en changeant une décision. Une nouvelle unité, un statut ou une cause d’écart doit être testé avec tous les consommateurs. Le producteur tolère la coexistence des versions pendant une fenêtre mesurée et conserve un mapping explicite ; il ne déduit pas la compatibilité du seul fait que le JSON reste valide.
Les contrats sont vérifiés par des fixtures issues de cas réels : mission complète, préparation partielle, annulation tardive, lot bloqué et événement répété. Les inconnues sont journalisées et mises en quarantaine lorsqu’elles touchent la décision. Le décommissionnement d’une version attend l’absence d’émission et de consommation observée, puis un test de rejet explicite.
Construire une recette proche de l’entrepôt réel
Prouver le parcours nominal de bout en bout
La recette part d’une commande identifiée, crée une mission sur un dépôt, confirme plusieurs lignes puis contrôle les mouvements ERP et le disponible publié. Elle conserve les identifiants à chaque étape et vérifie les quantités, unités, horodatages et états terminaux. Un test qui s’arrête à la réponse de création ne prouve pas la synchronisation.
Le scénario nominal inclut au moins une préparation partielle et une ligne non servie. Il confirme que le reliquat suit la règle attendue et que la partie exécutée n’est ni perdue ni répétée. Pour un SKU tracé, il vérifie le lot ou la série jusqu’au document final et au rapprochement de stock.
Provoquer les pannes qui rendent le résultat ambigu
Le test coupe la connexion après l’envoi d’une mission, renvoie deux fois la même confirmation et livre des événements dans le désordre. Il vérifie qu’une seule mission physique et un seul mouvement subsistent. Il sature ensuite une file, invalide un mapping de SKU et bloque une permission afin de contrôler les alertes et le passage en quarantaine.
Enfin, l’équipe simule une indisponibilité prolongée de chaque système, accumule des confirmations puis exerce la reprise. Le runbook, le retry, le backoff, la DLQ et le rapprochement doivent produire un résultat lisible sans correction directe en base. Le support réalise l’exercice avec les accès de production prévus et mesure le délai avant un stock de nouveau opposable.
Erreurs fréquentes : les raccourcis qui créent du stock fantôme
Écraser le stock avec le dernier snapshot reçu
Le dernier message reçu n’est pas nécessairement le plus récent sur le plan métier. L’appliquer sans version peut annuler un mouvement arrivé entre-temps et rendre le stock apparemment stable. Un snapshot sert au rapprochement ou remplace un état uniquement lorsque son périmètre, son horodatage et sa règle de concurrence sont garantis.
Le signal faible apparaît quand les écarts disparaissent après chaque import puis reviennent quelques heures plus tard. Il indique que la cause n’est pas traitée. Le flux doit isoler les mouvements manquants ou dupliqués avant d’autoriser une correction de solde, sinon la prochaine synchronisation recrée la même dette.
Confondre mission acceptée et préparation terminée
Une mission acceptée prouve que le WMS l’a reconnue, pas que les unités ont été prélevées ou expédiées. Déclencher la suite sur cet état peut facturer trop tôt, libérer une réservation ou annoncer un colis inexistant. Le verdict attend les confirmations de ligne et l’état physique convenu.
La mesure utile sépare temps d’acceptation, temps de début, temps de confirmation et temps de réconciliation. Une moyenne unique masque les missions bloquées. Dès qu’une cohorte dépasse son délai, l’ouverture de nouvelles missions sur le périmètre concerné doit être ralentie ou suspendue selon la décision prévue.
Relancer sans rechercher l’effet de la première tentative
Le risque est de croire qu’un timeout annule la demande. En réalité, le WMS peut avoir créé la mission avant la coupure. Le retry commence par une lecture fondée sur la clé fonctionnelle, puis décide de reprendre le suivi ou d’émettre la mutation. En l’absence de preuve, le dossier reste bloqué plutôt que dupliqué.
La même règle s’applique aux confirmations : rejouer un message ne doit pas recréer un mouvement. L’inbox, le journal d’opération et l’idempotence couvrent ensemble l’effet métier. Un identifiant de requête généré à chaque tentative ne protège rien s’il n’est pas relié à la commande, à la ligne et à la mission d’origine.
Décision : le pilote peut-il passer en production ?
La décision repose sur des preuves produites dans le flux réel. Le pilote doit avoir traité une mission complète, une préparation partielle, un SKU inconnu, un message hors ordre, un timeout après envoi et une reprise après indisponibilité. Le rapprochement doit fermer les écarts expliqués et laisser en attente ceux qui exigent une opération physique.
- À valider — autorité : nommer le système qui décide chaque transition et la règle appliquée en cas de conflit.
- À tester — identités : vérifier SKU, dépôt, unité, commande, ligne et mission sur les cas nominaux comme sur les rejets.
- À provoquer — ambiguïté : couper le réseau après l’envoi et démontrer qu’aucune mission ni aucun mouvement n’est dupliqué.
- À rapprocher — quantités : relier missions demandées, confirmations, mouvements et soldes jusqu’au niveau utile.
- À jouer — mode dégradé : suspendre une dépendance, accumuler les messages puis reprendre sans retouche directe.
- À transmettre — exploitation : faire exécuter diagnostic et reprise par le support à partir d’une alerte réelle.
Si l’autorité ou la reprise reste implicite, la mutation automatique doit être différée. Le mode lecture seule peut continuer à calculer les écarts et mesurer la fraîcheur. Cette étape apporte déjà de la valeur et révèle les décisions manquantes sans créer une nouvelle source de stock fantôme.
Plan d’action avant la bascule
Fermer le périmètre et construire le contrat
La première étape choisit un dépôt, une famille de produits et un parcours de préparation représentatif. L’équipe inventorie les états du stock, missions, confirmations, retours et ajustements utilisés dans les deux systèmes. Elle construit la matrice d’autorité, aligne SKU et unités, puis documente les transitions autorisées et les cas qui doivent rester manuels. Chaque objet reçoit une clé fonctionnelle et un propriétaire métier.
La deuxième étape fixe le contrat d’échange. Elle définit l’enveloppe, les versions, les dates, les quantités, les causes de rejet et les règles de compatibilité. Le connecteur implémente une outbox côté émission, une inbox côté réception, des files séparées par priorité et un journal de corrélation. Le monitoring observe latence, âge des messages, DLQ, missions sans confirmation et écarts de solde.
Le flux démarre ensuite en lecture seule. Il récupère les missions et stocks, produit des rapprochements et compare ses décisions à celles des équipes. Les faux écarts corrigent le mapping ou la fenêtre de tolérance ; les vrais écarts révèlent un mouvement oublié ou une responsabilité non définie. Aucun snapshot n’est poussé tant que les causes ne sont pas comprises.
Exercer le pilote et transmettre la reprise
La mutation s’ouvre sur une cohorte bornée. Une commande crée une mission, reçoit une confirmation partielle puis une confirmation finale. L’équipe suit les identifiants jusqu’aux mouvements ERP et à la disponibilité publiée. Elle provoque ensuite doublon, désordre, timeout et indisponibilité. Chaque incident doit conduire à un statut explicite, une alerte actionnable et un contrôle de fin.
Le support exerce la reprise sans assistance du développeur : retrouver le dossier, suspendre la cohorte, corriger le référentiel ou relancer le message, puis vérifier le rapprochement. Les accès et commandes utilisés sont ceux prévus pour la production. Les interventions manuelles restent journalisées et aucune correction directe ne contourne le contrat.
La bascule avance enfin par dépôt, type de mission ou famille de produits, avec une fenêtre d’observation entre deux paliers. Les seuils portent sur confirmations en retard, écarts non attribués, âge de la DLQ et temps de reprise. Si un seuil est franchi, les nouvelles missions du périmètre sont suspendues tandis que les confirmations déjà émises continuent d’être rapprochées. L’ancien flux n’est retiré qu’après preuve de non-usage et exercice du retour au dernier palier sûr.
Ressources complémentaires pour approfondir
L’analyse WMS, OMS, ERP et front : quelle source de vérité pour le stock approfondit la répartition des responsabilités entre systèmes. La méthode sur l’audit trail des intégrations API complète le journal nécessaire aux reprises et corrections sensibles.
Les schémas et comportements réels restent ceux des ERP et WMS retenus. Les capacités de création, d’annulation, de confirmation partielle, de pagination et de limitation sont vérifiées dans leur documentation et dans un environnement contrôlé avant de finaliser le mapping.
Conclusion : synchroniser des décisions, pas seulement des quantités
Un flux ERP–WMS fiable attribue chaque état, conserve les mouvements qui l’expliquent et donne une identité stable aux missions comme aux confirmations. Il ne confond ni présence physique et disponibilité commerciale, ni acceptation technique et préparation terminée.
Cette architecture rend les préparations partielles, retours, lots et corrections compréhensibles. Elle absorbe les doublons et les messages hors ordre sans réécrire l’histoire, puis utilise le rapprochement pour détecter ce qui manque réellement. L’équipe peut alors suspendre une cohorte, reprendre un dossier et vérifier le stock sans improviser une valeur de remplacement.
Pour transformer vos échanges ERP–WMS en service exploitable, notre accompagnement en intégration API cadre l’autorité des données, les contrats, l’idempotence, les contrôles et la transmission au support avec vos équipes commerce et logistique.
