Le moment le plus dangereux d'un remplacement de WMS n'est pas le matin du go-live. C'est cette étendue d'heures silencieuses juste avant — la fenêtre de gel des données — quand l'ancien système est en train de s'éteindre et que le nouveau n'a pas encore gagné la confiance. Si vous placez mal le point de gel, vous passerez votre première semaine à réconcilier les stocks au lieu d'expédier les commandes.
J'ai vu des équipes passer six mois sur le choix du logiciel et quatre mois sur l'implémentation, puis repousser la décision du gel à la semaine précédant la bascule. Le résultat est toujours le même : quelques centaines de waves encore ouvertes dans l'ancien système le jour du go-live, un stock qui ne concorde pas dans le nouveau, et une file de service client en feu. Je l'ai vu de près sur un projet 3PL à Fontana en 2019. Une fois a suffi.
Le gel, ce sont trois listes, pas une ligne
La plupart des gens imaginent le gel comme un instant unique : l'ancien système s'arrête, le nouveau démarre. En pratique, le point de gel, ce sont trois listes, chacune gelée selon son propre calendrier.
La première liste, ce sont les données de référence, et elle gèle en premier. Les référentiels d'articles, d'emplacements, de clients et de fournisseurs doivent être verrouillés deux à trois semaines avant la bascule. La logique est simple : la migration et la validation des données tournent sur un instantané, et si les référentiels continuent de changer, vos scripts de migration sont obsolètes dès qu'ils se terminent. Ma règle : après le gel des référentiels, les ajouts ne passent que par un processus d'exception — un formulaire papier, ma signature, puis saisie dans le système.
La deuxième liste, ce sont les soldes transactionnels, gelés la veille au soir. L'instantané du stock, les commandes de vente ouvertes, les commandes d'achat et réceptions ouvertes, les ajustements de stock en attente, les tâches d'inventaire tournant inachevées — tout cela est « photographié » avant l'ouverture de la fenêtre de bascule. Une fois la photo prise, ces documents peuvent être clôturés dans l'ancien système, mais jamais créés.
La troisième liste, c'est l'encours, et c'est la plus compliquée. Des waves pickées mais non contrôlées, des commandes chargées sur une remorque mais pas encore expédiées, des réceptions restées sur un camion pas encore déchargé — tout cela chevauche les deux systèmes et chacun a besoin d'un responsable et d'une décision. Ma règle dure : clôturez tout ce qui peut l'être. Seules les exceptions passent dans le nouveau système, et chacune porte la validation signée d'un responsable nommé sur la checklist de bascule.
Dimensionnez la fenêtre d'après votre volume de commandes, pas d'après le calendrier
Il n'existe pas de durée standard de gel, mais il existe une façon de la calculer. Partez à rebours de votre volume quotidien de commandes, de votre rythme de waves et de la vitesse à laquelle votre équipe clôture les documents.
Commencez par choisir la fenêtre de bascule, puis déduisez-en les actions de gel. Pour un bâtiment e-commerce qui traite quelques milliers de commandes par jour, je demande généralement une fenêtre complète de faible volume — disons, du samedi 22h au dimanche 6h. Quatre à six heures avant l'ouverture de la fenêtre, arrêtez de créer de nouvelles waves et laissez les waves en cours se terminer naturellement. Deux heures avant, la réception passe aux registres manuels. À l'ouverture de la fenêtre, prenez l'instantané de stock et verrouillez l'accès en écriture de l'ancien système.
Un point non négociable : faites un comptage avant le gel. Pas un inventaire complet mural — mais un comptage cyclique de chaque emplacement à haute rotation touché par la bascule. J'ai vu un projet découvrir un écart de trois points entre le stock système et le stock physique après la prise de l'instantané, et toute la bascule a glissé d'une semaine. Le comptage est une condition préalable du gel, pas une option facultative.
Et ce que les équipes oublient : prévenez vos clients et vos transporteurs de la fenêtre de gel à l'avance. Pour un 3PL en particulier — si un client dépose une commande urgente pendant le gel, il vous faut un script standard expliquant pourquoi ces heures sont noires. Ne l'écrivez pas quand le téléphone sonne.
Exécution en parallèle, brièvement — l'ancien système est un miroir, pas un partenaire
Faut-il faire tourner les deux systèmes en parallèle après la bascule ? Le débat est éternel. Ma position est tranchée : oui, en parallèle — mais l'ancien système reste un rétroviseur en lecture seule, jamais un second point de saisie.
Le miroir signifie que l'ancien système conserve un accès en consultation pendant deux à quatre semaines. Le service client y consulte l'historique des commandes, la finance y réconcilie, les retours d'avant-bascule y sont traités. Mais chaque nouvelle transaction va dans le nouveau système. Saisir les nouvelles commandes dans les deux systèmes est la pire pratique que j'ai vue — les deux jeux de données divergent en trois jours, et la réconciliation devient un cauchemar.
Je limite la période en parallèle à deux semaines, un mois au maximum. Si au bout d'un mois vous ne pouvez toujours pas vous passer de l'ancien système, c'est que quelque chose dans le nouveau n'était pas terminé, et la réponse est de le corriger — pas de prolonger le parallèle indéfiniment. À la fin de la période, l'ancien système est archivé : base de données sauvegardée et scellée.
Écrivez le plan de retour sur papier — puis répétez-le
Enfin, le retour arrière. Nombre de projets ont un plan de retour arrière qui se résume, en entier, à : « En cas de problème, revenir à l'ancien système. » C'est comme n'avoir aucun plan.
Un plan de retour arrière utilisable précise quatre choses : les déclencheurs (par exemple, le flux de sortie principal en panne pendant plus de deux heures, ou les commandes d'un client majeur totalement inexécutables) ; le décideur unique (une personne, généralement le chef de projet — pas un comité) ; le sort des données créées dans le nouveau système pendant le retour arrière (commandes pickées, étiquettes imprimées — annulées ou reprises manuellement) ; et le moment de l'exercice de retour arrière (mon exigence : au moins une répétition complète avant la bascule, incluant une restauration chronométrée).
Voici la vérité honnête sur les plans de retour arrière : leur vraie valeur n'est pas d'être utilisés. C'est de vous obliger à penser à tous les « et si » avant le jour de la bascule. Aucun des projets que j'ai menés avec un plan de retour arrière sérieux et écrit n'a jamais fait marche arrière. Deux de ceux qui n'en avaient pas m'ont appelé à minuit.
Si vous construisez un plan de bascule cette semaine, faites une chose ce soir : sortez votre liste de commandes ouvertes, alignez-la avec votre planning de waves et comptez exactement combien de commandes seront en l'air dans les douze heures de part et d'autre de votre point de gel prévu. Ce nombre est le fondement de tout votre plan de bascule. Construisez sur du sable et tout ce qui est au-dessus devient un danger.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
