Un week-end de bascule était planifié depuis des mois. Un WMS vieux de vingt ans devait être remplacé, l'inventaire complet était organisé, les équipes étaient prêtes. La veille, un module critique ne fonctionnait pas dans le scénario de migration. Les équipes métier ont décidé de reporter. Ce retour d'expérience raconte ce NO GO, puis en tire une méthode : les critères de go / no go d'un projet informatique industriel, la check-list à passer avant toute bascule, qui doit décider, et comment annoncer un report sans casser la confiance.
Car c'est la décision la plus difficile en gestion de projet : après des mois d'efforts, avec une direction qui attend et des équipes mobilisées, dire « pas maintenant ». Elle est pourtant souvent la bonne, et elle se prépare.
Le contexte : une migration WMS à haut risque
Le WMS (Warehouse Management System) en place chez cet industriel avait vingt années de service et aucune maintenance récente, mais il restait au centre des opérations quotidiennes : réception, emplacements, préparation, expédition. Le remplacer n'était pas un changement d'outil, c'était une opération à cœur ouvert, avec quatre enjeux :
- la continuité opérationnelle : aucune interruption des flux logistiques, les clients attendent leurs commandes le lundi ;
- l'intégrité des données : vingt ans d'historique de colis, d'emplacements et de palettes à préserver ;
- la formation des équipes à de nouveaux processus et à de nouveaux écrans ;
- la fiabilité : en environnement industriel, une expédition ratée se voit tout de suite.
Le plan de bascule prévu
La stratégie de déploiement était méthodique, en trois phases :
- Migration des données. Extraction des tables SQL du système existant et conversion vers la base NoSQL du nouveau WMS, avec rapprochement des deux côtés.
- Inventaire complet. Le moment de vérité : scan exhaustif des colis, des emplacements et des palettes ; typologie détaillée (vrac, mono-client, statuts multiples) ; triple comptage pour détecter les écarts ; clôture avec suppression des colis fantômes et réattribution des emplacements. L'outil développé pour cette étape est décrit dans le cas client sur le module d'inventaire.
- Tests de validation. Préparations et expéditions en conditions réelles sur le nouveau système, avant d'ouvrir à tout l'entrepôt.
Le grain de sable : un module d'expédition qui ne fonctionne pas
La veille de l'inventaire, l'équipe a découvert que le module d'expédition ne fonctionnait pas dans le scénario de migration. Sans expédition, pas de bascule possible : c'est le flux qui touche directement le client. La découverte était tardive, et c'est ce retard qui révélait le vrai problème.
Avec le recul, les signaux d'alerte étaient là depuis plusieurs semaines :
- des tests incomplets sur les modules critiques, l'expédition en premier ;
- une équipe technique sans vision globale de l'enchaînement des flux ;
- une communication insuffisante entre développeurs et métiers ;
- une pression temporelle qui faisait passer la date avant la qualité.
Face à ces constats, les équipes métier ont pris une décision unanime : reporter le déploiement. Un NO GO assumé, la veille d'un week-end préparé depuis des mois.
Go / no go d'un projet informatique industriel : les critères à fixer avant la bascule
La leçon principale est celle-ci : les critères de go / no go doivent être écrits avant que la pression ne monte. Le jour J, on ne décide plus, on constate. Voici la grille que nous utilisons désormais sur nos projets ERP et WMS :
| Critère | GO | NO GO |
|---|---|---|
| Modules critiques (réception, préparation, expédition, facturation) | Testés de bout en bout sur des données réelles, résultats signés par le métier | Un module testé « en partie » ou uniquement par les développeurs |
| Données migrées | Rapprochées : mêmes totaux de stock, de commandes ouvertes et d'emplacements des deux côtés | Écarts inexpliqués, même « petits » |
| Interfaces (ERP, étiquetage, transporteurs) | Un flux complet passé en test, du bon de commande à l'étiquette | Une interface jamais exécutée en conditions réelles |
| Équipes | Formées sur leur poste, référents identifiés par équipe | Formation prévue « après la bascule » |
| Plan de retour arrière | Écrit, chiffré en heures, testé au moins une fois | « On verra si ça se passe mal » |
| Fenêtre de bascule | Marge d'au moins une journée avant la reprise des expéditions | Bascule calée sur la dernière heure du week-end |
| Support | Développeurs et éditeur joignables, présence sur site les premiers jours | Support « par e-mail » à la reprise |
Un seul NO GO sur un module critique suffit : une migration de données parfaite ne compense pas un module d'expédition absent.
La check-list de la réunion de go / no go
- Fixer la réunion au moins une semaine avant la bascule, pas la veille.
- Passer chaque critère de la grille, avec les preuves : comptes rendus de tests, rapprochements chiffrés, feuilles de présence aux formations.
- Lister les anomalies ouvertes et les classer : bloquante, contournable, cosmétique.
- Vérifier que la procédure de repli est connue de ceux qui devront l'exécuter.
- Prendre la décision, la consigner par écrit, et désigner qui l'annonce et à qui.
Qui décide ?
Le métier. L'équipe technique informe, documente et alerte, mais c'est le responsable logistique ou le responsable de production qui porte le risque opérationnel ; c'est donc lui qui dit GO ou NO GO, avec la direction. Sur ce projet, c'est précisément parce que la décision a été prise collégialement, par les équipes métier et non par les seuls développeurs, qu'elle a été acceptée sans discussion.
Comment annoncer une décision de report
Un report mal annoncé coûte presque aussi cher qu'une bascule ratée. Ce qui fonctionne :
- Dire les faits, pas les responsables. « Le module d'expédition ne passe pas le scénario de migration ; nous ne basculons pas tant qu'il n'est pas validé. »
- Donner la suite en même temps que le report. Ce qui sera corrigé, par qui, et la date de la prochaine réunion de go / no go. Une nouvelle date de bascule ne s'annonce que lorsqu'elle est crédible.
- Remercier les équipes mobilisées et préciser que le travail de préparation n'est pas perdu : la méthode d'inventaire et les outils serviront à la prochaine tentative.
- Prévenir les clients ou les transporteurs uniquement si le report change quelque chose pour eux. Un report invisible de l'extérieur est un succès.
Ce que nous voyons sur le terrain
Annuler un déploiement n'est jamais un échec lorsque cela évite une catastrophe opérationnelle avec impact client direct, des coûts de retour arrière qui explosent, une perte de confiance durable des utilisateurs et un stress organisationnel dont l'entreprise met des mois à se remettre. Les projets de remplacement de systèmes anciens échouent fréquemment : AvenDATA avance le chiffre de 75 % de projets de remplacement de legacy en échec. Un report assumé en fait rarement partie ; un GO mal préparé, souvent.
Trois leçons reviennent sur tous nos projets. La compétence technique ne suffit pas : un excellent développeur n'est pas forcément un bon chef de projet, et il faut dans l'équipe une vision globale des interdépendances, un sens métier et quelqu'un capable d'anticiper les blocages. L'encadrement métier est indispensable pour que l'équipe ne s'enferme pas dans les détails techniques au détriment des flux essentiels. Enfin, un NO GO assumé vaut mieux qu'un GO mal préparé : la phrase est simple, elle est difficile à appliquer un vendredi soir.
Le courage, en projet informatique industriel, ne consiste pas toujours à foncer. Il consiste parfois à dire « stop » quand les conditions ne sont pas réunies, puis à revenir avec un plan solide. C'est la différence entre une migration réussie et un parcours du combattant aux conséquences imprévisibles.
Chez Planitools, nous menons les projets ERP avec cette discipline : des critères de go / no go écrits dès le cadrage, des tests de bout en bout sur les flux critiques et une bascule que le métier valide. Nous accompagnons les PME industrielles sur l'intégration d'Odoo pour l'industrie, et nos réalisations montrent comment cela se passe concrètement. Vous préparez une bascule ? Parlons de votre plan de déploiement.