Tant que vous vendez par une seule boutique, une commande est simple : elle arrive, réserve du stock, part en expédition. Les ennuis commencent quand s’ajoutent une marketplace, une application mobile, la vente B2B et un magasin physique. Soudain, la même commande n’a pas le même visage dans chaque système, et la disponibilité d’un produit cesse d’être un seul chiffre. Pour un directeur des opérations ou de la logistique, cela veut dire de la survente, des expéditions en retard et un service client qui devine ce qui s’est réellement passé.
D’après notre expérience, le difficile sur ces projets n’est pas d’ajouter un canal de plus mais de construire une couche cohérente qui sait tout de chaque commande et sait la piloter. Même là où nous n’apportons pas de produit tout fait, nous pourvoyons les rôles et réunissons les compétences nécessaires pour qu’un système de gestion des commandes soit construit et tenu en production, sans monter une équipe de zéro.
Pourquoi les commandes divergent-elles entre les canaux ?
Parce que chaque canal a son propre modèle de données, son propre rythme et sa propre vérité sur les stocks. La boutique retire un article dès le panier, la marketplace se synchronise toutes les quelques minutes, et l’ERP n’enregistre qu’après paiement. Ces décalages s’additionnent et la même unité peut être vendue deux fois.
S’y ajoute le fait que les mêmes statuts (« payé », « en cours », « emballé ») portent un nom différent dans chaque outil, que les retours empruntent un chemin différent des expéditions, et que les corrections manuelles vivent dans des tableurs. Sans langage commun pour la commande, chaque équipe travaille sur une image différente de la réalité, et les écarts n’apparaissent qu’au moment d’une réclamation.
Qu’est-ce que l’orchestration omnicanale des commandes et le routage vers les entrepôts ?
L’orchestration des commandes est le cœur d’un OMS : la couche qui prend une commande venue de n’importe quel canal, la ramène à un format unique et décide comment l’exécuter. C’est là qu’une commande cesse d’appartenir à un canal pour appartenir à l’entreprise.
La pièce maîtresse est la logique de routage - la réponse à la question « d’où expédions-nous ». Nous concevons des règles qui pèsent :
- la disponibilité dans chaque entrepôt et chaque magasin,
- la distance et le coût d’expédition jusqu’au client,
- les priorités (par exemple écouler un entrepôt saisonnier, le SLA d’un client B2B),
- la capacité d’exécution d’un site donné un jour donné.
Un routage bien conçu sait aussi répartir une seule commande entre plusieurs sources quand aucun site ne détient tout, et le faire de façon à ce que le client reçoive le moins de colis possible à un coût acceptable.
Comment synchroniser les stocks et la disponibilité entre les canaux ?
C’est la question sur laquelle trébuchent le plus de déploiements. Au lieu de tenir un stock séparé par canal, nous construisons une source unique de vérité pour la disponibilité et nous en alimentons chaque point de vente. L’OMS se place entre l’entrepôt et les canaux, pour que tout le monde voie un chiffre cohérent.
En pratique, nous utilisons des mécanismes qui protègent de la survente et des stocks « fantômes » :
- des réservations et des verrous souples sur la marchandise pendant l’exécution d’une commande,
- l’available-to-promise (ATP), qui compte non seulement le stock en main mais aussi la marchandise en transit,
- des tampons de sécurité pour les canaux à synchronisation plus lente,
- des mises à jour événementielles au lieu d’un lourd recalcul nocturne.
Comment traiter les expéditions partielles et les commandes en attente ?
Une commande entière voyage rarement dans un seul colis depuis un seul endroit. Un e-commerce réel doit savoir faire quand une partie de la commande est disponible tout de suite et qu’une autre doit être approvisionnée. Nous modélisons la commande pour que ses lignes puissent vivre leur propre cycle - certaines emballées et expédiées aujourd’hui, d’autres en attente avec une date de livraison estimée.
Cela entraîne des décisions produit et techniques concrètes : comment informer le client d’une expédition partielle, quand débiter le paiement, comment compter la livraison lorsqu’il y a plusieurs colis, et que faire quand une commande en attente ne se referme jamais. Nous concevons ces règles avec l’équipe des opérations, parce que ce sont elles, et non le code seul, qui décident de l’expérience client.
De quels outils de service client avez-vous besoin pour les commandes ?
Le meilleur routage ne servira à rien si le conseiller ne voit pas ce qui arrive à une commande. C’est pourquoi un OMS comprend une couche d’outils pour le support et les opérations - un panneau où une commande a une image complète.
Nous construisons les fonctions réellement utilisées pendant un appel avec un client :
- l’historique complet de la commande (statuts, paiements, expéditions, retours) au même endroit,
- les actions correctives : corriger une adresse, annuler une ligne, réexpédier,
- une vue des réservations et de la source d’exécution, pour répondre au « où est mon colis »,
- le traitement des retours et des réclamations rattaché à la même commande.
Comment brancher les intégrations avec l’ERP, le WMS et les paiements ?
Un OMS ne vit pas en vase clos - sa valeur vient de sa conversation avec le reste du paysage applicatif. Nous le traitons comme une couche d’intégration qui traduit la commande entre le monde de la vente et celui de la logistique et de la finance.
Nous le relions généralement :
- à l’ERP - pour les produits, les prix, les factures et la comptabilisation,
- au WMS - pour la préparation, l’emballage et les mouvements d’entrepôt,
- aux passerelles de paiement - autorisations, débits, remboursements,
- aux transporteurs - étiquettes, suivi, statuts de livraison.
Nous concevons ces intégrations pour qu’elles résistent aux pannes d’en face : avec des files, des nouvelles tentatives et un comportement clair quand l’ERP ou le WMS cesse de répondre un moment. Ainsi, l’indisponibilité d’un système n’arrête pas tout le flux de commandes.
Comment garantir la fiabilité et la cohérence des commandes ?
Une commande, c’est de l’argent et une promesse faite au client : un OMS doit donc être cohérent et idempotent - le même message traité deux fois ne doit pas créer une deuxième expédition ni un deuxième débit. Nous nous appuyons sur une architecture événementielle où chaque étape a un état sans ambiguïté et où l’historique des changements est rejouable.
En pratique, cela veut dire concevoir pour les cas limites : des webhooks de marketplace dupliqués, un paiement confirmé en retard, ou un entrepôt qui signale un manquant alors que le stock était déjà réservé. Nous construisons des mécanismes de réconciliation et un monitoring qui repèrent l’écart avant le client. C’est cette couche qui décide si le système tient pendant un pic de ventes ou s’il engendre le chaos.
Quelles compétences apportons-nous sur un projet OMS ?
Nous composons l’équipe autour des particularités de la gestion des commandes, pas « au cas où ». Sur ce type de projet, nous bâtissons l’équipe avec les rôles qui referment réellement le sujet :
- un architecte / développeur backend qui conçoit le modèle de commande et la logique d’orchestration,
- des ingénieurs intégration qui connaissent la réalité de l’ERP, du WMS, des paiements et des API transporteurs,
- un spécialiste data et cohérence qui veille sur les stocks, les réservations et la réconciliation,
- un spécialiste DevOps qui construit les déploiements, les files et le monitoring pour le trafic de pointe.
Nous nous appuyons sur une expérience réelle des projets e-commerce et des systèmes transactionnels, là où le volume et la justesse des données sont ce qui compte.
Comment procédons-nous chez RITS ?
Nous travaillons en partenaire nearshore depuis la Pologne qui renforce votre équipe avec les compétences nécessaires pour construire et faire tourner un OMS. Plutôt que de vendre un produit fermé, nous entrons dans votre paysage applicatif et concevons la couche de commandes autour de vos canaux et de vos processus.
- nous pourvoyons des rôles de l’architecture aux intégrations et au DevOps, accordés au périmètre du projet,
- nous vérifions les compétences avant le démarrage, et notre recherche aboutit généralement en trois semaines environ,
- en partenaire situé dans un fuseau horaire proche, nous entrons dans vos revues de code et vos réunions sans longue montée en charge,
- nous travaillons dans le modèle qui convient le mieux : logiciel sur mesure construit par notre équipe, ou renfort d’équipe quand il faut compléter vite les compétences.
Par où commencer avec un système de gestion des commandes ?
Commencez par le flux le plus douloureux - le plus souvent la survente ou l’écart de stock entre la boutique et une marketplace. Décrivez comment une commande vit aujourd’hui, de son arrivée à son expédition, et où vous perdez la cohérence. Cela montre si vous avez besoin d’un OMS complet ou, d’abord, seulement de l’orchestration et de la synchronisation des stocks.
Le choix du modèle de collaboration compte ici autant que la technologie. Nous avons exposé les différences entre renfort d’équipe, équipe dédiée et services gérés dans notre article sur les modèles de collaboration IT.
Vous vous battez avec les commandes entre vos canaux ? Parlons-en - nous accorderons l’équipe et l’architecture OMS à votre e-commerce.