La question avant la conclusion.
- Angle
- warehouse
- Parcours
- 3 points de décision
- Lecture
- 7 min
Il y a une conversation qui revient presque à chaque premier rendez-vous. Le directeur des opérations décrit ses problèmes — les écarts d'inventaire, les préparateurs qui tournent en rond, les camions qui attendent — puis conclut par la phrase qui nous met mal à l'aise: « donc il nous faut un WMS ».
Parfois oui. Souvent, pas encore.
Voici les cinq choses qu'un WMS ne réparera pas. Elles se décident avant, elles se décident sans nous, et elles coûtent infiniment moins cher que le projet informatique qu'on envisage pour les contourner.
1. Un adressage qui n'existe pas
C'est le sujet numéro un, et de loin.
Un WMS ne sait faire qu'une chose fondamentalement: dire à quelqu'un où aller chercher quoi. Si vos emplacements ne portent pas de nom stable, physiquement lisible, unique et cohérent — le logiciel n'a rien à dire. Il enregistrera des mouvements vers des adresses fictives, et vos équipes continueront à chercher au jugé, avec en plus une saisie à faire.
Ce chantier ne demande pas de budget informatique. Il demande une décision de nomenclature (allée–travée–niveau–position, ou ce que vous voulez, mais une seule fois), des étiquettes lisibles depuis la position de conduite d'un chariot, et quelqu'un dont c'est la responsabilité de les maintenir. C'est un travail de quelques semaines. Il conditionne tout le reste.
2. Une unité de charge que personne n'a définie
Question simple, réponse rarement immédiate: quand vous dites « une palette », de quoi parlez-vous exactement?
Une palette-support? Une palette homogène d'un seul article? Une quantité contractuelle avec un client? Un contenant que vous suivez individuellement, ou un simple regroupement logique?
Tant que ce vocabulaire n'est pas tranché, chaque interlocuteur du projet parle d'autre chose sans le savoir. Le commercial promet des délais à la palette, l'entrepôt raisonne au colis, la facturation compte des lignes, et le système hérite de l'ambiguïté — qu'il transforme en règles de gestion contradictoires.
3. Des quais dimensionnés pour l'activité d'il y a cinq ans
Un logiciel ordonnance des files d'attente. Il ne crée pas de place.
Si vos réceptions et vos expéditions se disputent les mêmes quais aux mêmes heures, si vos camions attendent parce qu'il n'y a physiquement pas où décharger, aucun paramétrage n'y changera quoi que ce soit. Le WMS vous donnera une belle visibilité sur l'embouteillage — ce qui a une valeur, mais pas celle qu'on espérait.
Avant le projet système, faites un relevé bête pendant deux semaines: heure d'arrivée, heure de mise à quai, heure de départ, par transporteur. La distribution des attentes vous dira si votre problème est informatique ou immobilier.
4. Des procédures que personne n'a écrites
Une procédure orale n'est pas une procédure: c'est une habitude, portée par les personnes qui l'ont apprise sur le tas.
Le paramétrage d'un WMS consiste précisément à figer des règles: qui contrôle quoi à la réception, dans quel cas on refuse une livraison, comment on traite un écart, qui autorise une sortie exceptionnelle. Si ces règles n'existent nulle part par écrit, elles vont être inventées pendant le projet — par l'intégrateur, dans l'urgence, avec les personnes disponibles ce jour-là.
C'est ainsi que des entreprises se retrouvent avec un système qui applique rigoureusement des règles auxquelles personne n'a jamais réfléchi.
Écrire une procédure d'entrepôt tient en une à deux pages. Réception, mise en stock, préparation, contrôle, expédition, inventaire, retours, gestion des non-conformités: huit documents courts, relus par ceux qui font le travail. Ce n'est pas un chantier documentaire, c'est la matière première du paramétrage.
5. Un stock dont l'inventaire est faux
Celui-ci est le plus douloureux, parce qu'il se découvre tard.
Un WMS démarre avec le stock que vous lui donnez. Si l'écart de départ est important — et il l'est presque toujours quand le stock était tenu sur tableur — le système passe ses premières semaines à produire des ruptures inexpliquées et des préparations impossibles. Les équipes concluent que « le nouveau logiciel ne marche pas », et la confiance ne revient jamais complètement.
La reprise d'inventaire n'est pas une formalité de fin de projet. C'est un chantier à part entière, à mener avant, avec des comptages contradictoires et une décision explicite sur ce qu'on fait des écarts. Nous recommandons de traiter la reprise comme un livrable indépendant, avec sa propre date et sa propre validation — pas comme une case à cocher la veille du démarrage.
Alors, quand un WMS devient-il la bonne réponse?
Quand les cinq points ci-dessus sont traités — ou au moins engagés — et que la difficulté restante est une difficulté d'information: vous ne savez pas où est le stock en temps réel, vous ne pouvez pas tracer un lot, vous ne pouvez pas prouver une prestation, vous ne pouvez pas piloter la productivité, vous ne pouvez pas absorber plus de volume sans ajouter du monde.
Ce sont de vraies raisons. Elles justifient un projet, et le retour sur investissement se constate.
À l'inverse, si votre difficulté est une difficulté d'organisation physique, le logiciel viendra la documenter avec précision — sans la résoudre.
Une manière simple de trancher
Prenez une commande client qui s'est mal passée le mois dernier. Remontez-la étape par étape, jusqu'à identifier le moment exact où l'information ou la marchandise a dévié. Faites-le sur cinq commandes.
Si les cinq déviations se produisent au même endroit et que cet endroit est une décision physique — un emplacement introuvable, un quai saturé, une règle que personne ne connaît — commencez par là.
Si les déviations sont dispersées et qu'elles ont un point commun — personne ne savait, au bon moment, ce que le système d'à côté savait déjà — alors oui, votre problème est un problème de système.
