En bref
L’OMS décide quoi faire de chaque commande, le WMS exécute la préparation en entrepôt, le TMS organise l’expédition. Ces trois briques peuvent être assemblées selon trois architectures : des outils spécialisés reliés entre eux, des outils spécialisés reliés par un hub d’intégration, ou une plateforme centralisée qui les réunit.
La plateforme centralisée devient plus efficace dès que les jonctions entre outils coûtent plus cher que les fonctions qu’ils apportent : plusieurs systèmes qui modifient le stock, des commandes qu’il faut suivre dans trois écrans, chaque nouveau canal qui devient un projet. À cinq semaines du Black Friday, on ne change pas d’architecture : on la cartographie, on la sécurise, et on décide en janvier.
Un pic de ventes ne crée pas de nouveaux problèmes techniques. Il fait apparaître, en quelques jours, toutes les faiblesses de l’architecture qui relie vos commandes, votre entrepôt et vos transporteurs. Un stock qui se met à jour avec vingt minutes de retard passe inaperçu à 200 commandes par jour. À 2 000, il produit des surventes.
Notre article sur le trio OMS, TMS, WMS et la rentabilité e-commerce explique pourquoi ces trois briques pèsent sur la marge. Ce guide s’adresse aux décideurs qui doivent trancher une question d’architecture : qui décide quoi entre les trois briques, comment les assembler, et à partir de quand une plateforme centralisée l’emporte sur l’empilement d’outils spécialisés.
OMS, WMS, TMS : qui décide quoi ?
Les définitions courtes suffisent à situer chaque brique :
- OMS (Order Management System) : le système qui centralise les commandes de tous les canaux et décide de leur traitement (réservation du stock, choix de l’entrepôt, priorité, statut).
- WMS (Warehouse Management System) : le système qui pilote l’exécution physique en entrepôt (réception, emplacements, préparation, emballage, inventaire, retours).
- TMS (Transport Management System) : le système qui organise l’expédition (choix du transporteur et du service, étiquettes, suivi transmis au client et au canal de vente).
Le vrai sujet d’architecture n’est pas la définition, c’est la frontière. Dans beaucoup d’organisations, une même décision est prise à deux endroits, ou à aucun. Le tableau ci-dessous attribue chaque décision clé à sa brique de référence.
| Décision | Brique responsable | Ce qui se passe si elle est mal placée pendant un pic |
|---|---|---|
| Réserver le stock à la commande | OMS | Deux canaux vendent la même unité avant que le stock ne soit décrémenté |
| Choisir l’entrepôt qui expédie | OMS | Commandes envoyées vers un site saturé ou en rupture, colis scindés inutilement |
| Prioriser les commandes (express, anciennes, marketplaces à délai imposé) | OMS, appliqué par le WMS | Les commandes express attendent derrière les commandes standard |
| Organiser la préparation (vagues, itinéraire, emplacements) | WMS | Déplacements inutiles, cadence de préparation qui plafonne |
| Contrôler le colis (contenu, poids, dimensions) | WMS | Erreurs de contenu, poids déclaré faux, surfacturation transport |
| Choisir le transporteur et le service | TMS | Choix manuel au poste d’emballage, promesse de livraison non tenue |
| Transmettre le suivi au client et au canal | TMS, relayé par l’OMS | Pénalités marketplace, afflux de demandes « où est mon colis » |
| Décider du sort d’un retour (remise en stock, rebut) | WMS, puis OMS pour le remboursement | Produits retournés invendables pendant des semaines, stock faux en décembre |
Deux systèmes complètent souvent ce trio sans en faire partie : le PIM, référence de la donnée produit, et l’ERP, référence des achats, de la comptabilité et de la facturation. Ils alimentent les trois briques mais ne doivent pas prendre leurs décisions à leur place.
À retenir
Une donnée, un maître. Pour chaque information (stock disponible, statut de commande, numéro de suivi), un seul système est autorisé à l’écrire ; les autres la lisent. Quand deux outils peuvent modifier le stock, l’architecture produit des écarts, quelle que soit la qualité de chaque outil.
Les jonctions : là où une architecture casse sous le volume
Chaque brique peut fonctionner parfaitement et l’ensemble échouer quand même. Les incidents de pic se concentrent sur les passages de relais, là où une information quitte un système pour entrer dans un autre. Une commande en traverse trois avant d’arriver chez le client.
- Jonction 1, OMS vers WMS. La commande doit arriver en entrepôt avec sa priorité et son stock déjà réservé. Si l’échange se fait par lots toutes les quinze ou trente minutes, la préparation démarre en retard et le stock affiché sur les canaux reste faux pendant ce délai.
- Jonction 2, WMS vers TMS. Le transporteur doit être choisi sur le colis réel, pas sur une estimation. Un poids théorique erroné fait basculer le colis dans la mauvaise tranche tarifaire, sur chaque envoi.
- Jonction 3, TMS vers OMS puis vers le canal. Le numéro de suivi doit remonter jusqu’à la marketplace dans le délai qu’elle impose. C’est la jonction la plus souvent oubliée, et celle qui coûte le plus cher en note vendeur.
Le volume aggrave ces jonctions de façon mécanique. Selon la Fevad, les ventes en ligne en France ont atteint 874 millions de transactions au deuxième trimestre 2026, en hausse de 13,5 %, avec un panier moyen en baisse : il y a plus de commandes à faire passer par chaque jonction pour un même chiffre d’affaires. Et selon Effigy Consulting (2025), le dernier trimestre concentre environ 30 % des colis annuels en Europe, avec des pics quotidiens jusqu’à trois fois le volume moyen.
Trois architectures possibles, et une variante hybride
Il n’existe pas une seule bonne façon d’assembler OMS, WMS et TMS. Il existe trois grands modèles, chacun avec ses forces et son coût.
Modèle A : outils spécialisés reliés directement entre eux
Chaque fonction a son logiciel (un OMS, un WMS, un outil d’expédition, des connecteurs marketplaces), et chaque outil est relié aux autres par une intégration dédiée. C’est l’architecture la plus fréquente, parce qu’elle se construit naturellement : on ajoute un outil à chaque nouveau besoin.
Modèle B : outils spécialisés reliés par un hub d’intégration
Les mêmes outils spécialisés, mais connectés à une couche d’intégration centrale (middleware, iPaaS) plutôt qu’entre eux. Le nombre d’interfaces diminue et la supervision est centralisée, mais la logique métier reste répartie entre les outils, et le hub devient lui-même un système à maintenir.
Modèle C : plateforme centralisée
Une seule plateforme porte nativement le catalogue, les commandes, l’entrepôt et l’expédition, et se connecte aux canaux de vente, aux transporteurs et à l’ERP. Les données partagent un même référentiel : le stock réservé par la commande est celui que voit le préparateur, et le colis expédié est celui dont le statut remonte au canal.
Variante hybride : la plateforme orchestre, le spécialiste exécute
La plateforme centralisée joue le rôle d’OMS et de hub, et confie une partie de l’exécution à un outil spécialisé : le WMS d’un prestataire logistique (3PL), un ERP existant, un entrepôt automatisé. C’est souvent le bon compromis quand une brique a des exigences très spécifiques.
| Critère | A. Spécialisés reliés entre eux | B. Spécialisés + hub | C. Plateforme centralisée |
|---|---|---|---|
| Nombre d’interfaces | Élevé, croît avec chaque outil | Un connecteur par outil | Connecteurs vers l’extérieur seulement (canaux, transporteurs, ERP) |
| Fraîcheur du stock | Dépend du plus lent des échanges | Dépend du rythme du hub et des outils | Référentiel unique, mis à jour à chaque mouvement |
| Suivre une commande | Plusieurs écrans, plusieurs identifiants | Plusieurs écrans, journal central des échanges | Un seul écran, de la vente à la livraison |
| Ajouter un canal ou un transporteur | Projet d’intégration, parfois plusieurs | Un connecteur à développer ou configurer | Activation d’une intégration existante, si disponible |
| Profondeur fonctionnelle | Maximale sur chaque brique | Maximale sur chaque brique | Large, parfois moins poussée sur des cas très spécifiques |
| Diagnostic d’un incident en pic | Long : il faut identifier quelle interface a cédé | Plus rapide grâce aux journaux du hub | Rapide : statuts et erreurs au même endroit |
| Compétences nécessaires | Équipe technique pour maintenir les intégrations | Équipe ou prestataire dédié au hub | Équipe opérationnelle qui paramètre des règles |
La taxe d’interface
Si n outils doivent tous échanger entre eux, le nombre d’interfaces possibles est n × (n − 1) / 2. Avec 4 outils, jusqu’à 6 interfaces ; avec 6 outils, jusqu’à 15 ; avec 8 outils, jusqu’à 28. Toutes ne sont pas nécessaires, mais chacune de celles qui existent doit être maintenue, surveillée et testée avant chaque pic. Un hub ramène ce nombre à n ; une plateforme centralisée le ramène aux seuls échanges avec l’extérieur.
Quand une plateforme centralisée devient plus efficace que l’empilement
La question n’est pas « faut-il centraliser ? » en général. Notre article Centraliser ses outils e-commerce : quand est-ce vraiment utile ? traite le bon moment selon la maturité de l’entreprise. Ici, la question est architecturale : dans votre configuration, les jonctions coûtent-elles plus cher que la profondeur fonctionnelle apportée par chaque outil ? La grille suivante aide à trancher.
| Votre situation | Plutôt outils spécialisés (A ou B) | Plutôt plateforme centralisée (C ou hybride) |
|---|---|---|
| Canaux de vente | Un ou deux canaux stables | Plusieurs marketplaces, ajouts fréquents, international |
| Entrepôt | Automatisé, robotisé ou multi-sites à très gros volume | Un ou plusieurs entrepôts à préparation manuelle ou semi-assistée |
| Transport | Messagerie palettes, affrètement, flotte propre | Colis via plusieurs transporteurs et points relais |
| Équipe technique | Équipe interne capable de maintenir des intégrations | Équipe opérationnelle, peu ou pas de développeurs |
| Qui modifie le stock aujourd’hui ? | Un seul système, clairement désigné | Plusieurs outils, avec des réconciliations régulières |
| Saisonnalité | Activité régulière | Pics marqués (Black Friday, Noël, soldes, French Days) |
Si la majorité de vos réponses tombe dans la colonne de droite, l’empilement vous coûte probablement plus qu’il ne vous rapporte. Pour le vérifier, comparez le coût complet des deux options, et pas seulement le prix des licences :
- Coûts visibles : abonnements et licences de chaque outil, connecteurs, hub d’intégration le cas échéant.
- Coûts de maintenance : mises à jour des API des marketplaces et des transporteurs, tests avant chaque pic, supervision des échanges.
- Coûts opérationnels : temps passé à réconcilier stocks et statuts, ressaisies, formation sur plusieurs interfaces.
- Coûts d’incident : surventes, annulations, pénalités marketplace et commandes bloquées pendant les jours où chaque heure compte.
Les deux dernières lignes sont rarement chiffrées, et ce sont souvent elles qui font pencher la balance. Notre article sur les nouveaux standards du back-office e-commerce en 2026 détaille pourquoi l’empilement atteint ses limites quand les canaux se multiplient.
Quand garder un outil spécialisé
Centraliser n’est pas toujours la bonne réponse pour toutes les briques. Un outil spécialisé reste pertinent quand une brique porte des exigences que peu de plateformes couvrent en profondeur :
- Entrepôt automatisé (convoyeurs, trieurs, robots) piloté par un WMS dédié ou un système de contrôle des équipements.
- Prestataire logistique qui impose son propre WMS à ses clients.
- Transport hors colis : palettes, affrètement, tournées en propre, avec planification de chargement.
- ERP structurant déjà en place pour la production, les achats ou la finance, qu’il serait coûteux de déplacer.
Dans ces cas, la variante hybride limite le nombre de jonctions sans sacrifier la profondeur : la plateforme reste maître des commandes, du stock disponible à la vente et des canaux, et transmet l’exécution à l’outil spécialisé. Pour la partie ERP, notre article sur les défis de l’intégration ERP liste les risques à maîtriser avant de connecter les deux.
Avant le Black Friday 2026 : décider sans migrer
Le Black Friday tombe le vendredi 27 novembre 2026. Changer d’architecture d’ici là ferait courir plus de risques que l’architecture actuelle. La bonne séquence consiste à sécuriser maintenant et à décider après le pic.
D’ici mi-novembre, cartographier et sécuriser. Listez vos outils et les échanges entre eux, désignez le système maître de chaque donnée, mesurez le délai de chaque jonction et prévoyez une procédure de secours si une interface tombe.
Pendant le pic, geler et observer. Aucune modification d’intégration à partir de la semaine du 23 novembre. Notez chaque incident : la jonction en cause, sa durée, le nombre de commandes touchées. Ce relevé sera, plus que n’importe quelle démonstration commerciale, la meilleure base pour choisir votre architecture.
De janvier à mars 2027, décider et déployer. Choisissez le modèle à partir des incidents réels, migrez par étapes (un canal, puis un entrepôt) et stabilisez avant les prochains temps forts.
Pour la préparation opérationnelle du pic lui-même, voir notre checklist Black Friday 2026 et les 5 contrôles omnicanaux à faire avant la Peak Season.
Comment Base s’inscrit dans ces architectures
Base réunit nativement les briques d’une architecture centralisée et peut aussi jouer le rôle d’orchestrateur dans une architecture hybride :
- OMS : la gestion des commandes regroupe tous les canaux dans une file unique, avec des statuts personnalisables et des actions automatiques qui changent les statuts, créent les expéditions, génèrent les factures et informent les clients.
- WMS : le WMS de Base couvre la réception, les emplacements, la préparation avec itinéraire optimisé, l’assistant d’emballage, les inventaires, les retours, les lots et dates d’expiration, avec une application mobile pour scanner.
- TMS : la gestion logistique connecte plusieurs dizaines de transporteurs, crée des centaines d’envois en une fois, imprime étiquettes et bordereaux automatiquement et transmet le suivi aux boutiques et marketplaces.
- Socle commun : un catalogue central dont le PIM est reconnu dans le Gartner Magic Quadrant 2026 pour les solutions PIM, la réservation du stock dès l’import de la commande, la gestion multi-entrepôts et plus de 1 700 intégrations (marketplaces, CMS, transporteurs, ERP), complétées par une API.
FAQ : architecture OMS, WMS, TMS
Quelle est la différence entre un OMS, un WMS et un TMS ?
L’OMS décide du traitement de chaque commande (stock réservé, entrepôt, priorité, statut). Le WMS exécute la préparation physique en entrepôt (réception, emplacements, picking, emballage, inventaire). Le TMS organise l’expédition (choix du transporteur, étiquette, suivi transmis au client et au canal).
Faut-il un OMS, un WMS et un TMS pour vendre en ligne ?
Pas forcément trois outils, mais les trois fonctions existent dès qu’on vend sur plusieurs canaux : quelqu’un ou quelque chose décide, prépare et expédie. Un vendeur sur un seul canal peut s’en tenir à sa boutique et à un outil d’expédition. Dès que plusieurs canaux partagent le même stock, une fonction OMS devient nécessaire ; dès que l’entrepôt traite un volume important, une fonction WMS fait gagner en cadence et en fiabilité.
Plateforme centralisée ou outils spécialisés : comment choisir ?
Comparez le coût des jonctions avec la profondeur fonctionnelle apportée par chaque outil. Avec plusieurs canaux, plusieurs transporteurs, des pics marqués et une équipe sans développeurs, une plateforme centralisée est généralement plus efficace. Avec un entrepôt automatisé, un transport hors colis ou un 3PL imposant son WMS, une architecture hybride est souvent préférable.
Peut-on changer d’architecture logistique avant le Black Friday ?
C’est déconseillé à quelques semaines du pic. Mieux vaut cartographier les flux, désigner le système maître de chaque donnée, prévoir une procédure de secours et geler les intégrations, puis décider de l’architecture en janvier à partir des incidents observés.
Un ERP peut-il remplacer un OMS ?
Rarement en e-commerce multicanal. L’ERP est conçu pour la finance, les achats et la gestion d’entreprise, avec des échanges souvent traités par lots. L’OMS est conçu pour orchestrer en continu des commandes venues de nombreux canaux. Les deux se complètent : l’OMS gère le flux de commandes et transmet commandes, stocks et factures à l’ERP.
Comment fonctionne une architecture hybride avec un prestataire logistique ?
La plateforme centrale reste maître des commandes, du stock disponible à la vente et des canaux. Elle transmet les commandes à préparer au prestataire, qui utilise son propre WMS, puis récupère les numéros de suivi et les mouvements de stock pour les répercuter sur tous les canaux.
Pour aller plus loin
- OMS, TMS, WMS : le tiercé gagnant qui conditionne la rentabilité e-commerce
- Order Management System (OMS) : pourquoi c’est essentiel à votre croissance e-commerce
- Gestion d’entrepôt : comprendre le WMS simplement
- Audit logistique e-commerce : 7 signaux que votre logistique ne suit plus la croissance
- Comment choisir un outil quand son e-commerce grandit
