Partir de l’événement, pas de l’acronyme
Une commande n’avance pas d’un bloc. Elle est créée, contrôlée, payée, allouée, réservée, préparée, expédiée, parfois annulée ou retournée, puis rapprochée avec des pièces financières. Chacune de ces étapes produit un fait différent, avec son responsable, sa preuve et ses conditions d’échec.
Commencer par demander « faut-il un OMS, un ERP ou un WMS ? » inverse donc le raisonnement. Deux entreprises équipées des mêmes catégories de logiciels peuvent répartir les responsabilités autrement. Une plateforme commerce peut créer les objets de fulfillment. Un ERP peut gérer une partie de la commande ou de l’inventaire. Un WMS peut initier un changement lorsque le picking révèle une quantité manquante.
La bonne unité de cartographie est l’événement métier. Pour chacun, écrivez :
- l’owner métier qui répond du résultat ;
- le système maître autorisé à trancher cet état ;
- les systèmes qui consomment et affichent une copie ;
- l’identifiant, la version et la règle de déduplication ;
- la condition d’alerte définie par l’entreprise ;
- la preuve qui confirme l’exécution ;
- la reprise possible lorsque les systèmes divergent.
Cette méthode complète la démarche qui consiste à cartographier la stack e-commerce. Elle évite de transformer un schéma d’outils en architecture opérationnelle imaginaire.
Les rôles typiques de l’OMS, de l’ERP et du WMS
Les trois acronymes restent utiles, à condition de les lire comme des rôles typiques et non comme une norme.
| Système | Responsabilité typique | Objets souvent concernés | Limite à confirmer |
|---|---|---|---|
| OMS | Orchestrer le cycle de commande et les exceptions | validation, allocation, promesse, split, release, annulation | certaines fonctions peuvent rester dans la plateforme, l’ERP ou un moteur spécialisé |
| ERP | Porter des objets de gestion et leur traduction financière | client, commande de gestion, facture, avoir, journal, inventaire selon la stack | il ne connaît pas forcément l’exécution physique en temps réel ni la meilleure décision d’allocation |
| WMS | Piloter et prouver l’exécution dans l’entrepôt | tâches, emplacements, scans, picking, packing, sortie, réception retour | il ne doit pas décider seul de la promesse client ou du remboursement financier sans contrat explicite |
La documentation des flux d’orchestration de Microsoft Dynamics 365 Intelligent Order Management montre, dans ce produit, un enchaînement possible de la capture à la facturation, avec validation, détermination du fulfillment et branches de succès ou d’échec. C’est un exemple d’orchestration, pas la définition universelle d’un OMS.
Côté entrepôt, la documentation SAP EWM sur les livraisons sortantes décrit des confirmations échangées avec l’ERP, des contraintes après création des tâches, des refus de picking et certains splits. Là encore, elle documente SAP EWM 9.5 et non tous les WMS.
Enfin, un ERP peut déclencher une facture selon des règles très différentes. Dans Odoo 19, la facture client peut partir de la commande, du paiement ou de la livraison ; une livraison partielle peut aussi conduire à une facturation partielle. La règle doit donc être écrite dans le processus réel, pas déduite du mot « ERP ».
Les données produit suivent une autre frontière. Pour répartir identité, attributs, médias et droits d’écriture, il faut gouverner les données produit séparément du cycle de commande.
Séparer les états de la commande
Un champ unique order_status donne une vue commode, mais il devient dangereux s’il remplace les états détaillés. Une commande peut être confirmée commercialement, payée, seulement partiellement allouée, pas encore préparée et déjà facturée selon le processus retenu. Réduire cette situation à « en cours » masque l’étape qui bloque.
Séparez au minimum :
- l’état commercial, par exemple créée, confirmée, rejetée ou annulée ;
- l’état de paiement, par exemple en attente, autorisé, capturé, échoué ou remboursé ;
- l’état d’allocation, ligne non allouée, allouée ou réallouée ;
- l’état de réservation, avec quantité, lieu, token et expiration ;
- l’état de fulfillment, depuis la release jusqu’à la sortie et à la livraison ;
- l’état de retour, demande, autorisation, réception, contrôle et décision de stock ;
- l’état financier, facture, avoir, écriture et rapprochement.
Un statut agrégé peut rester utile au service client. Il doit être calculé à partir de ces faits, jamais les écraser. Pour chaque transition, conservez aussi la source, la version, l’horodatage, le motif et l’identité métier corrélée.
Attribuer création, paiement et confirmation
La création établit l’identité de la commande. Son identifiant doit rester stable même si l’OMS, l’ERP ou le WMS utilisent leurs propres identifiants techniques. Le payload source et son journal constituent la première preuve. Si l’événement d’intake manque, la reprise consiste à relire la commande dans la plateforme puis à rejouer la prise en charge de manière contrôlée.
Le paiement ajoute un autre fait. Le PSP est typiquement maître du mouvement financier, tandis que l’OMS ou la plateforme conserve une copie de son état pour décider de la suite. L’identifiant de transaction et la clé d’idempotence empêchent qu’une notification répétée ne produise une seconde capture ou une seconde action métier. Avant un rejeu, il faut relire le PSP, pas seulement faire confiance à la copie locale. Le choix du prestataire et le détail des flux relèvent d’une analyse des solutions de paiement e-commerce.
La confirmation de commande exprime une décision commerciale : accepter, bloquer ou rejeter. Elle peut dépendre du paiement, de contrôles internes, de la disponibilité et des règles de fraude. Son système maître peut être l’OMS ou l’ERP selon l’organisation. L’important est d’enregistrer la transition, son motif et la condition qui autorise ensuite la release vers l’entrepôt.
Cette attribution technique ne résout pas l’expérience vécue par le client. Les libellés, erreurs et étapes visibles doivent être traités dans un chantier distinct pour auditer les frictions du checkout.
Distinguer allocation, réservation, split et promesse
Ces quatre notions sont proches, mais elles ne décrivent pas le même engagement.
- L’allocation choisit une source de fulfillment pour une ligne et une quantité.
- La réservation bloque ou protège une quantité dans un ledger désigné, pour un lieu et parfois une durée.
- Le split crée une lignée entre un parent et plusieurs enfants : lieux, colis, dates ou modes différents.
- La promesse expose une date, un mode et éventuellement un lieu au client ; elle doit pouvoir être recalculée et révisée.
Le split peut apparaître à plusieurs niveaux. La documentation Shopify sur les Fulfillment Orders montre qu’une commande peut être représentée par plusieurs groupes ou ordres de fulfillment et plusieurs modes de livraison. Un WMS peut ensuite produire un autre split à cause d’une contrainte de préparation. Il faut conserver les quantités du parent, l’identité des enfants et la cause de chaque division au lieu d’utiliser un simple booléen « split ».
L’ordre logique dépend du modèle. Une entreprise peut calculer une promesse à partir d’une disponibilité, puis réserver après confirmation. Une autre peut réserver avant de confirmer. Dans les deux cas, la matrice doit préciser quand l’engagement devient ferme, quand il expire et quel système peut le réviser.
Le mot « stock » doit lui aussi être qualifié : physique, disponible à la vente, réservé, en transit ou endommagé. Ces quantités peuvent avoir des maîtres différents. Le guide Stocks multicanaux détaille leur propagation et leur réconciliation ; le guide Logistique e-commerce couvre les preuves physiques et les coûts de la réception au retour. Une copie de stock sans type, lieu, version et horodatage ne suffit pas à arbitrer une divergence.
Prouver la préparation et l’expédition
Une release indique que l’entrepôt peut agir ; elle ne prouve pas que le colis existe. La preuve d’exécution vient des tâches et des scans : prélèvement, refus de picking, substitution autorisée, packing, confirmation de sortie. Le WMS est donc typiquement maître des états physiques qu’il produit.
Une tâche bloquée doit remonter avec son motif. Selon les règles commerciales, l’OMS peut réallouer la ligne, réduire la quantité, réviser la promesse ou demander une intervention. Le WMS ne doit pas inventer la décision client, et l’OMS ne doit pas déclarer une préparation terminée sans preuve physique.
L’expédition exige à son tour une identité propre : colis, transport, tracking et confirmation de sortie. Une étiquette créée n’est pas un départ. À l’inverse, une sortie confirmée sans tracking exploitable crée une exception à rapprocher. La récupération peut consister à relire le transporteur, corriger l’association du colis ou remettre l’état en cohérence, sans créer une seconde expédition.
Séparer annulation, retour, remboursement et avoir
Une demande d’annulation et son résultat sont deux événements. Avant allocation, l’OMS peut parfois arrêter le flux. Après réservation, il faut aussi libérer la quantité. Une fois la tâche de préparation engagée, le WMS doit confirmer si l’arrêt est encore possible. Après expédition, l’annulation bascule généralement vers une logique de retour ou de rappel selon le processus défini.
Le retour physique ne vaut pas remboursement. Il comprend une autorisation éventuelle, une réception, un contrôle de quantité et d’état, puis une décision : remise en stock, quarantaine, réparation ou rebut. Le remboursement est un mouvement opéré par le PSP. L’avoir est une pièce financière portée par l’ERP ou le logiciel comptable.
La documentation Odoo 19 illustre cette séparation : un retour produit génère une opération inverse d’entrepôt, tandis qu’après facturation le remboursement comptable exige aussi une note de crédit. Ce comportement est propre au processus documenté, mais il montre pourquoi « retour remboursé » ne devrait pas être un état indivisible.
Pour chaque dossier, corrélez donc l’ID de retour, la réception physique, l’ID de remboursement PSP et le numéro d’avoir. Une alerte doit révéler l’avoir sans remboursement, le remboursement sans réception attendue ou le colis reçu sans autorisation. La reprise ne rejoue que l’action manquante après lecture du maître concerné.
Rendre les événements idempotents et réconciliables
Un transport d’événements fiable ne garantit ni l’ordre, ni l’unicité, ni même la livraison parfaite. Shopify indique par exemple que l’ordre de ses webhooks n’est pas garanti, recommande d’utiliser les horodatages, de dédupliquer avec un identifiant et de prévoir des tâches de réconciliation lorsqu’une livraison manque ou est mal traitée.
Le contrat minimal d’un événement comprend :
- un identifiant d’événement unique ;
- l’identifiant métier corrélé, commande, ligne, paiement, colis ou retour ;
- le type d’action et le système source ;
- une version ou une date de mise à jour comparable ;
- la charge utile nécessaire à la décision ;
- une clé d’idempotence pour les actions irréversibles ;
- la preuve de traitement ou le motif d’exception.
L’idempotence signifie que rejouer un événement ne crée pas de double réservation, expédition, remboursement ou écriture. Si un événement ancien arrive après un événement récent, le consommateur ne rétrograde pas aveuglément l’état : il compare version et horodatage, puis relit le système maître.
Les tentatives techniques doivent être bornées et observables. Après échec, l’événement passe dans une file d’exception avec un owner, une cause et une procédure de reprise. Enfin, une réconciliation périodique compare les ensembles complets : commandes sans paiement, paiements sans commande, réservations orphelines, expéditions non confirmées, retours non rapprochés et écritures manquantes. Les corrections sensibles prennent la forme d’événements compensatoires historisés, pas d’un écrasement silencieux.
Remplir la matrice de responsabilités
La matrice suivante est un modèle à adapter. « Système maître » désigne celui qui peut trancher l’état concerné, pas celui qui affiche la vue la plus complète. Les seuils d’alerte restent à définir selon les engagements et horaires réels de l’entreprise.
| Événement | Owner métier | Système maître typique | Consommateurs | État et idempotence | Alerte à définir | Preuve et récupération |
|---|---|---|---|---|---|---|
| Commande créée | E-commerce / order operations | Plateforme ou OMS d’intake | OMS, paiement, CRM, analytics | ID immuable, version, déduplication | absence de prise en charge | payload et journal ; relire puis rejouer |
| Commande confirmée | Order operations | OMS ou ERP | WMS, service client, finance | transition et motif | confirmation absente avant release | décision ; corriger puis reprendre |
| Paiement confirmé | Finance / paiement | PSP pour le mouvement, OMS pour la copie | ERP, fulfillment, service client | ID transaction, clé d’idempotence | paiement orphelin ou état absent | statut PSP ; rapprocher avant rejeu |
| Allocation | Order operations / stock | OMS ou moteur d’allocation | WMS, plateforme, service client | ligne, quantité, lieu, version | ligne non allouée | règle et disponibilité ; réallouer |
| Split | Order operations | OMS ou objet de fulfillment | WMS, transport, client, ERP | parent, enfants, quantités, corrélation | somme incohérente | lignée ; annuler les enfants incohérents et recalculer |
| Promesse | E-commerce / service client | OMS ou service de promesse | storefront, CRM, WMS | date, mode, lieu, version | promesse absente ou dépassée | règle et données ; recalculer et notifier |
| Réservation | Inventory operations | Ledger désigné selon le stock | canaux, OMS, WMS | token, quantité, lieu, expiration | expiration ou réservation orpheline | ledger ; libérer, renouveler ou rapprocher |
| Préparation | Responsable entrepôt | WMS | OMS, ERP, transport | tâches et scans versionnés | blocage ou refus de picking | scan ; exception, substitution autorisée ou réallocation |
| Expédition | Logistique | WMS, TMS ou fulfillment | OMS, plateforme, ERP, client | colis, tracking, sortie | étiquette sans départ ou départ sans confirmation | sortie et tracking ; relire puis corriger |
| Annulation | Service client / order operations | OMS avant release, WMS après engagement | ERP, PSP, plateforme | demande et résultat séparés | état incompatible | motif et décision ; stopper, libérer ou basculer en retour |
| Retour | Service retours / entrepôt | OMS/RMA pour l’autorisation, WMS pour la réception | ERP, PSP, qualité | ID, lignes, motif, état physique | réception sans dossier ou inversement | scan et contrôle ; qualifier l’exception |
| Remboursement | Finance / paiement | PSP pour le mouvement, ERP pour l’avoir | OMS, plateforme, service client | ID, clé, partiel ou total | avoir sans remboursement ou inversement | PSP et avoir ; rejouer seulement l’action manquante |
| Mise à jour stock | Inventory control | WMS, ERP ou service d’inventaire selon le type | OMS, canaux, achats | SKU, lieu, type, version | quantité négative ou dérive | mouvement et inventaire ; correction compensatoire |
| Écriture financière | Finance / comptabilité | ERP ou logiciel comptable | BI, fiscalité, trésorerie | pièce unique, extourne ou avoir | fait métier non comptabilisé | journal et rapprochement ; écriture liée |
Cette matrice devient opérable quand chaque ligne reçoit un nom d’équipe, une condition d’alerte locale, un canal d’escalade et une procédure testée. Les événements qu’elle produit peuvent ensuite alimenter des KPI avec source, propriétaire et règle d’action, sans inventer ici de seuil générique.
Cadrer l’architecture avant de choisir les outils
Un atelier de cadrage peut tenir en sept étapes :
- Inventorier le cycle réel. Partir d’une commande récente, y compris un split, une annulation tardive et un retour.
- Séparer les états. Nommer les états commercial, paiement, allocation, réservation, fulfillment, retour, stock et finance.
- Attribuer les maîtres. Choisir un système autorisé à trancher chaque état et documenter les copies.
- Écrire les contrats. Fixer identifiants, versions, ordre attendu, idempotence, preuves et événements compensatoires.
- Définir les exceptions. Nommer l’owner, l’alerte, le canal d’escalade, la reprise et les droits de correction.
- Tester la réconciliation. Simuler doublon, retard, perte, split incohérent, paiement orphelin et retour non rapproché.
- Évaluer la couverture. Seulement ensuite, vérifier quelles responsabilités sont déjà couvertes par la plateforme, l’ERP ou le WMS, et lesquelles justifient un OMS ou un service dédié.
Le livrable n’est pas un dessin de trois boîtes. C’est une matrice versionnée, reliée aux contrats d’événements et aux preuves opérationnelles. Elle peut servir à corriger une intégration existante, préparer un appel d’offres ou décider qu’un outil supplémentaire n’est pas encore nécessaire. Dans tous les cas, la responsabilité reste lisible même lorsque les frontières logicielles changent.
