Le Distributed Order Management, ou DOM, est un élément central du commerce unifié. Il ne doit pas se contenter de traiter les commandes : il doit agir comme une couche d'intelligence centrale, qui synchronise les stocks, l'exécution des commandes et la logistique sur tous les canaux de vente.
Sans lui, les enseignes et les marques B2B restent prisonnières d'opérations fragmentées, d'une visibilité incohérente sur les stocks et de workflows d'exécution inefficaces.
Voici comment un DOM rend possible une stratégie de commerce unifié évolutive, efficace et rentable.
Omnicanal et commerce unifié : où se situe la différence ?
Les deux termes sont souvent employés l'un pour l'autre, mais ils ne désignent pas la même chose. L'omnicanal est une ambition côté front-end : être présent et cohérent sur chaque canal utilisé par le client. Le commerce unifié est la réalité côté back-end qui rend cette ambition possible : stocks, commandes, exécution et données clients fonctionnent à partir d'une seule source de données partagée, plutôt que de plusieurs systèmes réconciliés après coup.
Cette distinction compte, car la plupart des programmes omnicanaux échouent côté back-end, et non côté front-end. Le site, l'application et les systèmes des magasins conservent chacun leur propre vue des stocks et des commandes, synchronisée à intervalles réguliers plutôt qu'en temps réel. Le client perçoit cet écart sous la forme d'une survente, d'une commande annulée ou d'un retour que le magasin ne retrouve pas.
Le commerce unifié comble cet écart en confiant à un seul système la responsabilité de la vérité opérationnelle ; dans la pratique, ce système, c'est le DOM.
Là où la stratégie de commerce unifié dépend du DOM
Gérer des workflows de commandes distincts pour le D2C, le B2B et les marketplaces n'est plus tenable. Les marques ont besoin d'un moteur unique d'orchestration des commandes, qui intègre toutes les sources de demande dans un système central.
Un DOM moderne permet :
- Un traitement consolidé des commandes issues de l'e-commerce, des marketplaces, des distributeurs et des forces de vente terrain.
- Un routage automatisé de l'exécution, ajusté en continu selon la disponibilité des stocks et la priorité des commandes.
- Une réconciliation fluide des stocks, pour éviter que le stock reste bloqué sur un canal pendant qu'un autre est en rupture.
Ce qui en fait un système unique, et non trois systèmes connectés, c'est que le même enregistrement de commande passe par la prise de commande, l'allocation et l'exécution sans jamais être transféré. Une commande marketplace et une commande en magasin ne sont pas deux workflows qui aboutissent à des résultats similaires.
C'est le même workflow, avec des points d'entrée différents ; c'est pourquoi l'ajout d'un canal devient un simple changement de configuration, et non un projet.
Visibilité unifiée des stocks : en finir avec les silos
L'approche traditionnelle de la gestion des stocks est dépassée. Le stock se trouve dans les entrepôts, les magasins, les centres de distribution régionaux, chez les prestataires logistiques 3PL et même chez les fournisseurs, mais la plupart des marques manquent encore de visibilité en temps réel sur ces pools de stocks dispersés. Conséquences :
- Du surstock sur un site pendant qu'un autre est en rupture.
- Du stock immobilisé, qui pourrait être vendu mais reste bloqué sur le mauvais canal.
- Des transferts de stock coûteux, de dernière minute, faute de synchronisation.
Une approche de commerce unifié fondée sur le DOM élimine ces inefficacités :
- En créant une vue unique et en temps réel des stocks, accessible sur l'ensemble des canaux de vente et de traitement des commandes.
- En synchronisant les données de stock entre l'ERP, le WMS et le PIM, pour des mises à jour instantanées.
- En allouant le stock de façon dynamique selon l'évolution de la demande, en privilégiant le meilleur point d'exécution pour chaque commande.
Available-to-Promise : ce que calcule un DOM
L'inventaire en temps réel n'est pas la même chose que l'Available-to-Promise (ATP), et c'est précisément sur cette différence que la plupart des promesses de livraison échouent.
Une position de stock indique ce qui existe physiquement. Une position ATP indique ce qui peut être promis à un client à l'instant présent : un chiffre plus petit, mais plus utile. Elle tient compte du stock déjà alloué aux commandes en cours, des unités en transit entre sites, des stocks de sécurité réservés à la vente en magasin, des limites de capacité de chaque nœud logistique et des heures limites qui déterminent si la promesse du jour est encore tenable.
Un DOM tient cette position à jour en continu, au lieu de la calculer au moment du checkout. La différence devient évidente lors des pics d'activité : le même article peut être consulté par des centaines de clients entre le chargement de la page et la confirmation du paiement. Sans position ATP engagée, deux d'entre eux l'achèteront.
Sur le plan commercial, la fiabilité de la promesse cesse d'être une prévision pour devenir un calcul. Les enseignes qui s'appuient sur le stock brut promettent soit de façon trop agressive, puis annulent, soit se protègent avec des stocks de sécurité si importants que du stock vendable reste invisible.
Allocation provisoire et allocation ferme : pourquoi la même unité est vendue deux fois
Dans la plupart des cas, la survente multicanale vient d'un décalage entre allocation provisoire et allocation ferme. Une allocation provisoire réserve du stock pour un panier ou un checkout qui n'est pas encore finalisé. Une allocation ferme, elle, engage le stock sur une commande confirmée.
Lorsque chaque canal gère ses propres réservations, le même article peut être réservé provisoirement, au même moment, par un panier web, un vendeur en magasin et une annonce marketplace ; une seule de ces réservations peut aboutir à une vente.
Un DOM lève toute ambiguïté en centralisant ces deux états. Chaque canal réserve du stock sur la même position ; les réservations expirent après un délai défini au lieu de durer indéfiniment, et l'engagement n'a lieu qu'une seule fois. Ainsi, une promesse affichée sur un canal est vraie sur tous les canaux : c'est le test concret pour savoir si une organisation commerciale est réellement unifiée.
Fiabilité de la promesse client : fixer les attentes et les tenir
Le commerce à l'échelle de l'entreprise ne consiste pas seulement à faire circuler des produits ; il s'agit de répondre aux attentes des clients.
Les acheteurs B2B ont besoin d'informations fiables sur la disponibilité des stocks, les délais et les options d'exécution avant de s'engager sur des commandes importantes. Les acheteurs D2C, eux, n'acceptent pas des délais de livraison vagues ou inexacts : la moindre incertitude coûte des conversions.
Une stratégie de commerce unifié reposant sur le DOM permet aux marques de faire des promesses d'exécution fiables, et de les tenir :
- Une validation des stocks en temps réel au checkout, pour éviter la survente.
- Optimisation de l'exécution pilotée par l'IA, qui sélectionne la meilleure option d'exécution selon le coût, la rapidité et la proximité.
- Une réallocation proactive en cas d'incident (par exemple un retard en entrepôt) : les commandes sont réaffectées dynamiquement à d'autres points d'exécution.
Ce qui change pour le B2B
La gestion des commandes B2B a des contraintes que le D2C n'a pas. Les prix négociés dans les contrats doivent être respectés sur tous les canaux. Les délais comptent davantage que la rapidité de livraison : un acheteur qui prépare un aménagement a besoin d'une date pour bâtir son planning. Les commandes sont déclenchées selon un calendrier, dans le cadre d'un engagement plus large, plutôt que sous forme de transactions isolées.
Un DOM traite ces cas comme des variantes de la même logique d'orchestration, et non comme un système à part ; la question de l'allocation reste d'ailleurs la même : quel stock, depuis quel site, et pour quelle promesse. Seule la pondération change : un acheteur B2B accepte généralement une date plus tardive en échange d'une expédition complète, ce que n'accepte pas un client D2C.
DOM, ERP et WMS : quel système fait quoi
Les enseignes disposent généralement déjà de systèmes qui gèrent les commandes ; c'est pourquoi l'investissement dans un DOM bute souvent sur la question du chevauchement. L'ERP détient l'enregistrement financier, le WMS pilote l'exécution à l'intérieur d'un entrepôt. Aucun des deux ne décide depuis quel site, sur l'ensemble du réseau, une commande doit être expédiée.
Cette décision revient au DOM. Il détient la position ATP sur tous les sites et engage le stock avant même que l'ERP ou le WMS n'interviennent ; c'est pour cela que le commerce unifié en dépend. La distinction entre la gestion des commandes et architecture ERP est à l'origine de l'essentiel de la confusion.
Le commerce unifié comprend aussi des systèmes qui ne relèvent pas du DOM : le logiciel de caisse (POS) conserve la transaction en magasin, la plateforme de paiement conserve l'enregistrement du règlement.
L'essentiel est que ces deux systèmes soient liés au même enregistrement de commande, au lieu de tenir chacun leur propre version. Un remboursement en magasin fonctionne parce que le DOM peut indiquer à la plateforme de paiement à quelle commande il se rattache, et non parce que le DOM gère lui-même le paiement.
Exécution intelligente et logistique : réduire les coûts, gagner en rapidité
L'exécution des commandes n'est plus une opération monocanal. Les grandes marques doivent s'appuyer sur des réseaux d'exécution multi-nœuds pour optimiser leurs coûts et leurs délais de livraison.
C'est dans le routage que se joue le coût : chaque commande impose un choix entre plusieurs sites capables, techniquement, de l'exécuter, et l'écart entre l'option la moins chère et la plus chère se cumule sur des millions de commandes.
Un DOM prend cette décision en arbitrant plusieurs objectifs concurrents à la fois. Le coût d'expédition et la zone du transporteur. Fractionner la commande entre deux sites coûte-t-il plus en transport que ce qu'il fait gagner en rapidité ? Un magasin dont le stock tourne lentement doit-il prendre la commande, pour écouler une marchandise qui serait sinon démarquée ? Le site le plus proche a-t-il les ressources nécessaires pour la préparer aujourd'hui ?
Ces objectifs se contredisent ; c'est pourquoi les règles doivent être configurables, et non figées. Une enseigne qui protège sa marge en janvier ne pondère pas la décision comme une enseigne qui protège ses délais de livraison en décembre.
Les décisions de routage doivent aussi résister à la réalité du magasin. Un magasin peut refuser une préparation parce que l'article est abîmé, vendu par erreur ou tout simplement absent du rayon alors que le système l'affiche, et des taux de refus de quelques pourcents sont la norme, pas l'exception.
Que le client s'en aperçoive ou non dépend de la suite. Le DOM redirige automatiquement la commande vers le site disponible suivant et maintient la promesse initiale auprès de cette nouvelle source, où elle peut encore être tenue.
Sinon, le refus se traduit par une annulation : exactement le type d'échec que le client aurait constaté avec une architecture fragmentée. Le commerce unifié ne signifie pas l'absence de problèmes opérationnels ; il signifie que ces problèmes peuvent être absorbés avant d'atteindre le client.
Retours : là où le commerce unifié échoue le plus visiblement
La plupart des programmes de commerce unifié sont pensés pour le flux aller et s'arrêtent à la livraison. C'est pourtant au moment des retours que les clients remarquent les failles.
Lorsqu'un article acheté en ligne est retourné en magasin, il franchit d'un coup toutes les frontières entre systèmes. Le magasin doit identifier une commande qu'il n'a pas lui-même passée, appliquer le bon remboursement sur le paiement d'origine et remettre l'article dans un stock que le canal e-commerce peut vendre. Si l'une de ces étapes échoue, le client doit attendre, le vendeur doit gérer la situation sur-le-champ, et l'article reste invendable pendant plusieurs jours.
Un DOM boucle la boucle en traitant le retour comme une partie du même enregistrement de commande, et non comme une transaction séparée. Concrètement : rattacher le retour à la commande d'origine, quel que soit le canal ; décider si l'article doit être remis en stock localement ou envoyé vers un point de consolidation ; puis le remettre en vente dès qu'il est vendable.
L'enjeu sur la marge est évident. Un vêtement retourné qui redevient vendable en deux jours plutôt qu'en quatorze vaut nettement plus, surtout dans les catégories où les démarques sont saisonnières plutôt que progressives.
Interopérabilité technologique : une intégration fluide des systèmes
Pour que le commerce unifié fonctionne à grande échelle, le DOM doit s'intégrer de façon fluide à l'ensemble de l'écosystème technologique de l'entreprise. Cela suppose une synchronisation en temps réel avec :
- ERP : finances centralisées, gestion des fournisseurs et réconciliation des stocks.
- WMS : suivi de l'exécution et mises à jour des stocks en temps réel.
- PIM : fiabilité des données produit sur tous les canaux de vente.
- Prestataires logistiques 3PL et réseaux de transporteurs : automatisation de l'exécution par des tiers et optimisation de la livraison du dernier kilomètre.
Un DOM API-first complète les systèmes existants au lieu de les remplacer, ce qui permet de l'adopter par étapes. L'ERP tient les registres financiers ; le WMS gère les opérations d'entrepôt ; le DOM prend les décisions pour lesquelles aucun des deux n'a été conçu.
Lorsqu'on ajoute une marketplace ou un nouveau site d'exécution, il suffit de le connecter à la couche d'orchestration, sans reconstruire toute l'architecture autour.
Comment savoir si votre gestion des commandes freine le commerce unifié
Les symptômes sont opérationnels plutôt qu'architecturaux, et ils apparaissent généralement bien avant que quiconque n'identifie la gestion des commandes comme la cause :
- La disponibilité affichée au checkout ne correspond pas à ce que l'entrepôt ou le magasin peut réellement expédier.
- Des commandes sont annulées après validation, parce que le même stock a été engagé deux fois.
- Un retour effectué en magasin ne peut pas être rattaché à la commande en ligne d'origine.
- Ajouter un canal ou un site d'exécution exige un projet de développement au lieu d'une simple configuration.
- Seule la DSI peut modifier les règles de routage, alors les équipes commerciales ne demandent plus rien.
- Du stock reste invendu sur un site pendant qu'un autre est en rupture.
Tous ces symptômes ont la même cause : plusieurs systèmes détiennent chacun leur version de la commande ou de la position de stock, sans point de décision unique entre eux.
Pourquoi les grandes marques et le B2B ne peuvent plus attendre
L'argument en faveur d'un DOM n'est pas que la gestion fragmentée des commandes échoue complètement. En réalité, la plupart des enseignes s'en passent pendant des années. Si la décision est sans cesse repoussée, c'est parce que le coût de fonctionner sans DOM est dispersé dans des domaines que personne ne suit.
Les commandes annulées sont traitées comme des échecs d'exécution, et non comme des problèmes de disponibilité ; la position de stock qui les a causées n'est donc jamais examinée. Le stock qui reste invendu sur un site pendant qu'un autre est en rupture est comptabilisé comme une démarque en fin de saison, et non comme un problème de routage en semaine six. Les commandes qui auraient pu être expédiées à moindre coût se perdent dans une ligne de frais d'expédition que personne ne ventile décision par décision.
Tous ces cas représentent des montants réels, et aucun n'apparaît sous une rubrique qui pousserait quelqu'un à agir.
Le problème s'aggrave aussi avec le temps. Chaque canal supplémentaire sans couche commune de gestion des commandes, c'est une intégration de plus à maintenir, un nouvel ensemble de règles à synchroniser et une version de plus de la position de stock à réconcilier. Le travail ne disparaît pas parce qu'on le reporte : il augmente.
Ce qu'un DOM change, c'est l'endroit où ces décisions sont prises. Un seul système détient la position ATP, détermine depuis quel site chaque commande est expédiée et garantit la cohérence de l'enregistrement de commande, de sa saisie jusqu'à son éventuel retour.
C'est grâce à cela que la disponibilité affichée au client est exacte, que le routage reflète les priorités commerciales plutôt que des règles par défaut, et qu'un retour initié sur un canal peut être rapproché d'une commande passée sur un autre.
Cela change aussi qui a la main. Lorsque les règles de routage et de sourcing sont configurables, les équipes commerciales peuvent les ajuster à mesure que les conditions évoluent, sans soumettre de demande de développement ni attendre une mise en production.
Le commerce unifié ne se construit pas en connectant davantage de systèmes. Il se construit en rendant l'un d'eux responsable des décisions que les autres ne peuvent pas prendre. Ce système, c'est le DOM.
