Le pire go-live WMS que j'aie jamais vu s'est passé comme ça : à midi le jour du lancement, les terminaux RF des préparateurs ne pouvaient pas récupérer les listes de tâches, et 40 personnes restaient plantées devant les racks sans rien faire. Le patron tapait du poing sur son bureau, les informaticiens s'accusaient mutuellement dans une salle de réunion — parce que personne n'avait décidé qui tranche quand ça casse.
Après ça, j'ai retenu la leçon : pour la première semaine de tout lancement de système, l'entrepôt a besoin d'une war room. Pas d'une salle de réunion — d'un poste de commandement. Qui s'y assoit, quels outils chacun apporte et quel rythme on suit, tout se décide avant le go-live. Voici le playbook que j'ai affiné au fil de plusieurs lancements. Servez-vous.
Trois lancements que j'ai vus échouer — tous sur « personne ne pouvait décider »
D'abord trois vraies leçons, et vous comprendrez pourquoi la war room est non négociable.
Le papier d'étiquettes. Le deuxième jour, toutes les imprimantes se sont arrêtées — pas un bug système. Le papier d'étiquettes était épuisé. L'administration l'avait stocké d'après la consommation de l'ancien système, mais le nouveau format d'impression doublait la consommation. Trente opérateurs d'entrepôt ont attendu toute la matinée la livraison d'un coursier. Depuis, la checklist de la war room comporte cette ligne : stocker trois jours de consommables.
L'interface est morte à 2 h du matin. Le flux de commandes de l'ERP est tombé à 2 heures du matin et le WMS a cessé de recevoir les commandes. L'informaticien d'astreinte était nouveau et ne savait pas qui détenait les droits de redémarrage de l'interface ; il a mentionné @everyone dans le chat de groupe et il a fallu 40 minutes pour trouver la bonne personne. En 40 minutes, le plan de vagues de 6 h du matin est tombé à l'eau. Depuis, le planning nomme noms et numéros de téléphone, épinglé au mur de la war room.
Le patron a pris les commandes lui-même. Le troisième jour, un S2 : l'informatique avait besoin de 4 heures pour réparer, les opérations ne pouvaient pas attendre. Le patron a débarqué sur le terrain, contourné la war room et commencé à rediriger le flux de travail lui-même — ce qui est entré en conflit avec la logique du système et a créé 200 exceptions ce jour-là. Après ça, j'ai instauré une règle de fer : la première semaine, le terrain n'obéit qu'à une seule voix — la war room. Les patrons qui ont un avis le disent à l'intérieur de la war room.
Trois échecs, trois façons de mourir, une cause racine : au moment critique, personne ne pouvait décider — ou la mauvaise personne l'a fait.
Les 5 personnes qui doivent être dans la pièce
Avec les mauvaises personnes, la war room n'est qu'un lieu pour se disputer. Ces cinq rôles sont non négociables :
Le commandant du terrain (une personne, dernier mot). Ce doit être un responsable des opérations qui connaît le métier — pas l'informatique. Il a exactement un pouvoir : dans les 5 minutes suivant un incident, décider « on continue » ou « on arrête ». La première semaine ne survit pas aux décisions de comité.
L'intégrateur WMS, sur site. Quand un bug de configuration survient, seuls eux peuvent le corriger sur place. Inscrivez le support sur site dans le contrat pour la semaine du go-live — j'ai vu échouer le support à distance seul.
Le responsable IT / intégration. Un WMS n'est jamais une île : le flux de commandes de l'ERP, l'API d'étiquettes du transporteur et les interfaces de facturation peuvent chacun paralyser l'entrepôt s'ils tombent. Cette personne détient les droits de supervision et de redémarrage de chaque interface.
Les chefs d'équipe du terrain. Un de la préparation, un de la réception et un de l'audit. Ce sont les capteurs humains du système — les premiers à sentir un écran lent ou un flux de travail maladroit. Donnez-leur un canal direct pour signaler, pas seulement un rôle de relais.
Le secrétaire et responsable des escalades. Chaque incident est ticketé, coté en sévérité et suivi jusqu'à la clôture. C'est cette personne qui décide ce qui attend demain et ce qui s'escalade maintenant — l'ordre de la pièce dépend d'elle.
En une phrase : si la war room est pleine, le terrain reste calme.
La checklist des 48 heures avant le lancement
La war room se monte deux jours avant le lancement, pas le matin même. Cochez-les une par une :
- Gel des données : le moment exact où l'ancien système cesse de recevoir des écritures, synchronisé dans toute l'entreprise. Avant le gel, validez trois choses : les données de référence des SKU, les emplacements et les soldes de stock. Si l'un des trois ne se réconcilie pas, on ne lance pas.
- Consommables d'impression : étiquettes d'expédition, étiquettes de codes-barres, rubans — stocker pour trois jours. Riez si vous voulez ; j'ai vu un entrepôt à l'arrêt le deuxième jour en attendant une livraison de papier d'étiquettes.
- Exercice de retour en arrière : le retour en arrière, ce n'est pas « on reviendra à l'ancien système si ça tourne mal ». Écrivez-le : conditions de déclenchement, qui donne l'ordre, comment les données reviennent, combien d'heures l'ancien système met à se rétablir. Parcourez-le au moins une fois sur papier avant le lancement.
- Planning des équipes : la première semaine fonctionne en deux équipes de 12 heures par jour (jour et nuit, en continu), sept jours d'affilée. Noms et numéros de téléphone sur papier. À 3 h du matin, vous devez savoir exactement qui appeler — pas @everyone dans un chat de groupe.
- La pièce elle-même : un grand écran affichant le taux de traitement des commandes en direct, le volume du retard et l'état des interfaces ; un tableau blanc avec les 3 principaux risques du jour ; snacks et eau stockés. Personne ne mange bien la première semaine.
Le rythme de la première semaine : trois standups + niveaux de sévérité
Trois standups par jour, sans exception. Matin (30 min avant le début de l'équipe) : solder les restes d'hier, confirmer le plan de vagues du jour. Point de midi : revoir le retard et les exceptions du matin, décider s'il faut ajouter des bras l'après-midi. Rétro du soir (après la fermeture) : passer en revue la liste des incidents du jour, coter la sévérité, attribuer responsables et échéances. Trente minutes maximum chacun. Debout.
Matrice de sévérité et d'escalade — imprimez-la au mur :
| Niveau | Définition | Réponse |
|---|---|---|
| S1 | Système en panne / entrepôt entier arrêté | Escalader au commandant du terrain en 15 min ; contournement en 1 heure |
| S2 | Flux principal bloqué (p. ex. les étiquettes n'impriment pas) | Répondre en 30 min ; résoudre ou dégrader en 4 heures |
| S3 | Anomalie locale (un emplacement, un document) | Résoudre le jour même |
| S4 | Polissage / améliorations UX | Enregistrer dans le retard ; traiter la deuxième semaine |
Quand siffler la fin : les lignes rouges du retour en arrière
L'appel le plus difficile n'est pas de corriger un bug — c'est d'admettre « on ne peut pas lancer aujourd'hui ». Écrivez les lignes rouges à l'avance, dans le plan de lancement, avec la signature du patron :
- Le taux de traitement des commandes tombe sous 80% sans tendance d'amélioration pendant 2 heures ;
- Le retard dépasse 1.5× la capacité quotidienne et continue de grimper ;
- Une interface principale (commandes ERP / étiquettes du transporteur) est en panne depuis plus de 4 heures sans voie de rétablissement ;
- Les écarts d'inventaire s'étendent largement et les comptages ne convergent pas.
Chacune déclenche le processus : le commandant du terrain ordonne l'arrêt et lance le retour en arrière. Rappelez-vous : le retour en arrière n'est pas un échec — c'est du contrôle des pertes. Perdre tous ses clients en s'acharnant pendant trois jours, voilà le vrai échec. Parmi les lancements que j'ai dirigés, celui que nous avons ramené en arrière avec décision est reparti proprement deux semaines plus tard ; celui que nous avons fait passer en force a coûté un mois de souffrance.
Quand démobiliser la war room
Il y a aussi un standard pour ça — pas « ça a l'air d'aller maintenant » : trois jours d'affilée sans incidents S1/S2, taux de traitement revenu au niveau de référence d'avant lancement, retard à zéro. Puis une dernière rétro : archiver le journal des incidents, transmettre le retard aux opérations quotidiennes, réduire le planning à l'astreinte. Effacer le tableau blanc. Démobiliser.
La première semaine d'un lancement se gagne sur l'organisation, pas sur la technologie. Le système le plus stable ne survit pas à 40 personnes qui ne savent pas qui écouter. Montez la war room, posez les règles, et la première semaine se passe bien — une leçon que j'ai payée avec plusieurs nuits blanches.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
