Accueil / Insights / OMS, caisse, WMS : qui fait foi sur le stock ?
Digital ·
OMS, caisse, WMS : qui fait foi sur le stock ?
En omnicanal, le site e-commerce, l'OMS, la caisse, le WMS et l'ERP connaissent tous le stock, chacun à sa façon. Sans règle claire sur qui fait foi, la promesse client se dégrade, surtout pendant les pics.
Cinq systèmes, cinq versions du stock
Le WMS connaît le stock physique de l'entrepôt, emplacement par emplacement. La caisse connaît les ventes du magasin. L'ERP porte le stock comptable. L'OMS calcule le stock disponible à la vente, tous canaux confondus. Le site e-commerce affiche ce que l'OMS, ou parfois l'ERP, lui transmet.
Chacun a raison dans son périmètre. Le problème commence quand ces versions divergent et que personne n'a décidé laquelle fait foi pour quelle décision.
Trois questions à trancher
- Qui fait foi sur le stock physique ? Pour l'entrepôt, c'est le WMS. Pour le magasin, c'est le système qui enregistre les mouvements : caisse, outil de stock magasin ou WMS de point de vente.
- Qui calcule le stock disponible à la vente ? C'est le rôle de l'OMS quand il existe : stock physique, moins les réservations, moins les marges de sécurité, par canal et par point d'expédition.
- À quelle fréquence les systèmes se synchronisent-ils ? Une synchronisation toutes les heures suffit pour un catalogue calme. Elle devient insuffisante pour une promotion ou un Black Friday.
Ce que les pics révèlent
Pendant un pic, les écarts de quelques minutes deviennent des commandes promises sans stock, des annulations et des clients déçus. Les causes sont presque toujours les mêmes : une interface qui ralentit sous la charge, une file de messages qui s'allonge, une règle de réservation pensée pour le volume habituel.
Ce que nous recommandons
- Écrire, pour chaque décision (afficher, promettre, allouer, réserver), quel système fait foi.
- Superviser les interfaces qui transportent le stock, avec des alertes sur les retards.
- Tester toute la chaîne à la volumétrie du pic, avant le pic.
- Prévoir les marges de sécurité et les règles de repli quand une interface s'arrête.
Pour aller plus loin : notre offre Retail omnicanal, le diagnostic omnicanal en 8 questions, et notre guide Omnicanal : préparer vos systèmes avant le prochain pic.
À lire aussi
Sur le même blog
SAP WM dans S/4HANA : pourquoi l'entrepôt doit entrer dans le cadrage
Un programme S/4HANA démarre souvent par la finance et les achats. L'entrepôt arrive plus tard, parfois trop tard. Or SAP WM n'est plus la cible : la question doit être tranchée dès le cadrage.
Lire l'articleRun · 2 octobre 2026Reprendre le Run d'un WMS : cinq vérifications avant de signer
L'intégrateur part après l'hypercare, ou la TMA en place ne connaît pas la solution : changer d'équipe de Run est fréquent. La transition, elle, est rarement préparée. Cinq points à vérifier avant de signer.
Lire l'articleBuild to Run · 28 septembre 2026Build to Run : pourquoi l'équipe qui construit doit aussi exploiter
Dans le modèle classique, l'intégrateur livre, puis une autre équipe découvre la solution au moment où elle devient critique. Le Build to Run supprime cette rupture.
Lire l'articleUn projet, une question sur ce sujet ?
Nous commençons par un atelier exécutif d'une demi-journée, et vous pouvez parler directement à l'un de nos clients.