Voici ce que personne ne vous dit sur les mises en production d'un WMS : le logiciel est rarement le problème. C'est la première semaine qui l'est.
J'ai vu des go-lives où le système a passé tous les tests, où toutes les interfaces étaient au vert et où le plan de bascule faisait 40 pages — et pourtant, à 9h du matin le premier jour, l'entrepôt était en feu. Nouveaux processus, nouveaux codes d'emplacements, nouveaux terminaux, tout arrive le même matin, sur des gens qui ont appris le nouveau flux pendant une session de formation de deux heures trois semaines plus tôt. La war room est la seule chose qui se tient entre ce chaos et un cut-off transporteur manqué. Mais la plupart des war rooms que j'ai vues, c'est juste quelques personnes assises autour à répondre au téléphone. Le feu brûle quand même, parce que personne n'a décidé à l'avance à quoi la première semaine allait réellement ressembler.
Les trois feux que vous allez combattre, garanti
Le premier feu, c'est la donnée de référence. Des codes-barres qui ne se scannent pas, des codes d'emplacements qui ne correspondent pas, des conversions d'unités de mesure erronées. En 2023, j'ai accompagné un go-live dans un entrepôt 3PL de 120 000 pieds carrés à Ontario, en Californie. Pour tenir la date limite, l'équipe avait reporté le chargement des codes-barres de plus de 200 références à faible rotation à « après le go-live ». Chaque matin de la première semaine, une douzaine d'ordres de vague restaient bloqués à la station d'audit parce qu'il n'y avait aucun code-barres à scanner, et les auditeurs devaient fouiller les cartons à la main. Zéro difficulté technique, pur travail de préparation incomplet — et le feu le plus usant de la semaine. Il ne vous tue jamais, il brûle juste chaque jour.
Le deuxième feu, ce sont les interfaces. Du WMS vers l'OMS, vers les transporteurs, vers l'EDI — quelque chose dysfonctionnera pendant la première semaine. Les commandes ne descendent pas, les mises à jour de statut se perdent, un lancement de vague meurt à mi-chemin. Le problème, c'est que l'entrepôt ne peut pas voir ce genre de problème : les préparateurs savent juste qu'« il n'y a pas de commandes à préparer ». Si la war room ne surveille pas les files d'interface, vous le découvrez deux heures plus tard quand l'arriéré est déjà en milliers. Et voici le plus fort — souvent, ce n'est pas du tout la faute du WMS. L'autre partie a changé un champ et a oublié de vous le dire. La war room a donc besoin de quelqu'un qui sait lire les logs et obtenir l'ingénieur de l'autre partie au téléphone en un seul appel.
Le troisième feu, c'est l'humain. Le nouveau flux semble maladroit, alors les opérateurs contournent discrètement le système : préparer sur papier d'abord, saisir après ; sauter le terminal RF parce qu'écrire à la main est plus rapide. Si vous ne tuez pas ces processus fantômes pendant la première semaine, vous ne les tuerez jamais. Une fois la donnée sale, l'exactitude des stocks ne se rétablit jamais. Parmi les projets que j'ai vus encore en train de réconcilier les stocks trois mois après le go-live, neuf sur dix avaient enterré le problème pendant la première semaine. Ma règle de war room : la première fois que quelqu'un contourne le système, c'est une conversation le jour même. La deuxième fois, ça va directement au responsable d'entrepôt. Ça paraît dur. C'est le seul moyen de protéger la donnée.
Qui siège dans la war room compte plus que son emplacement
La configuration qui marche le mieux, c'est une ou deux personnes de chacun des trois côtés. Les opérations envoient un superviseur d'entrepôt — quelqu'un qui connaît le processus et peut trancher des questions comme « cette commande peut partir en manuel ». L'informatique envoie la personne interfaces et infrastructure — quelqu'un qui sait lire les logs et redémarrer un service sans ouvrir un ticket. L'intégrateur envoie un consultant qui connaît le paramétrage — quelqu'un capable de corriger un mauvais paramètre sur-le-champ. Les trois sont non négociables. Sans les opérations, les incidents ne peuvent pas être qualifiés. Sans l'informatique, les problèmes d'interface ne rencontrent que des regards vides. Sans l'intégrateur, un seul élément de paramétrage peut vous bloquer pendant une demi-journée.
Travaillez en deux équipes, pas trois. L'équipe du matin couvre le lancement des vagues jusqu'au pic du soir ; l'équipe de nuit couvre la clôture, avec deux heures de chevauchement pour la passation. Figez le planning trois jours avant le go-live, imprimez-le, affichez-le au mur. Si quelqu'un a besoin de congés, il trouve son propre remplaçant. Le « support par téléphone » ne compte pas. Pendant la première semaine, une personne dans la salle et une personne au téléphone, ce sont deux niveaux de puissance de feu complètement différents.
Le plus important : nommez un décideur unique, généralement le chef de projet côté métier. La maladie la plus mortelle de la war room, c'est trois personnes et aucune décision. Quand un P1 arrive, le décideur dit une phrase — on arrête la ligne et on répare, ou on contourne et on protège les expéditions. Cette personne doit avoir l'autorité pour arrêter les expéditions et l'autorité pour dire « on passe en manuel pendant deux heures ». Une war room à l'autorité floue débattra deux heures de ce qu'un décideur clair règle en une phrase.
Six chiffres au tableau de bord. Pas un de plus.
Un tableau de bord de première semaine doit être maigre. Je surveille six chiffres : l'arriéré de commandes non lancées, le taux de réussite des lancements de vague, les terminaux RF en ligne, la profondeur des files d'interface et le temps d'attente le plus long, le taux d'exceptions d'audit et le taux d'expéditions à l'heure le jour même. Chacun a une ligne rouge — par exemple, une file d'interface de plus de 200 commandes sans mouvement pendant 15 minutes est automatiquement escaladée en P1, sans rapport nécessaire. Les trois côtés se mettent d'accord sur les lignes rouges avant le go-live, les écrivent sur papier, les affichent au mur et n'y touchent plus de toute la semaine. Une ligne rouge qui change chaque jour n'est pas une ligne rouge.
Les niveaux de sévérité P1/P2/P3 doivent exister dès le jour un, et les définitions doivent être simples et concrètes. P1 : on ne peut pas expédier, ou la donnée va se corrompre. P2 : le débit chute de plus de moitié, mais on peut encore expédier. P3 : problèmes d'ergonomie qui n'affectent pas les expéditions. Une war room sans sévérité claire a tout « à peu près urgent », ce qui signifie que rien n'est priorisé. Une autre règle de fer : du moment où un P1 est repéré au moment où quelqu'un en prend la responsabilité, pas plus de 15 minutes. Si le délai est dépassé, le téléphone du décideur sonne directement.
Un plan de rollback n'est pas une honte. C'est une assurance.
Deux choses doivent être prêtes avant le go-live. D'abord, des bons de commande papier de secours et un processus manuel. Si le système tombe vraiment en panne, l'entrepôt ne s'arrête pas : on prépare sur papier, on enregistre à la main, on saisit après. Imprimez les formulaires à l'avance et laissez-les sur le terrain — n'allez pas chercher une imprimante quand tout est déjà cassé. Et répétez le flux manuel au moins une fois. Les chefs d'équipe doivent parcourir tout le processus papier de leurs propres mains, sinon le mauvais jour ils ne sauront même pas comment utiliser le papier qu'ils ont entre les mains.
Ensuite, des points de restauration des données. Une sauvegarde complète chaque nuit, plus une sauvegarde séparée avant tout changement majeur de donnée de référence. Rollback ne veut pas dire désinstaller le système — ça veut dire « le changement de paramétrage d'aujourd'hui a cassé quelque chose, et on peut revenir à l'état d'hier soir ». Honnêtement, peu de projets utilisent réellement le plan de rollback pendant la première semaine. Mais en avoir un change complètement la psychologie de l'équipe. Une équipe avec un plan touchera au paramétrage. Une équipe sans plan ne changera pas un seul paramètre, et un problème P2 traînera jusqu'à devenir un P1.
Donc : avant la semaine du go-live, imprimez les définitions P1/P2/P3 et la liste des téléphones d'escalade, affichez-les au mur de la war room et posez à côté une pile de formulaires papier de secours. Le dernier jour de la première semaine, organisez une rétrospective avec trois questions : quel feu a brûlé le plus fort, quel indicateur a alerté en premier, et quel contournement manuel devrait devenir un processus système permanent. Puis dissolvez la war room — la garder ouverte signifie que vous ne faites pas encore confiance au système.
Une dernière question pour vous. Si vous deviez arrêter vous-même l'ancien système le matin du premier jour — oseriez-vous ? Si non, votre plan de rollback n'est pas prêt. Corrigez ça maintenant, tant qu'il est encore temps.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
