Recette WMS : pourquoi votre go-live se joue pendant l’UAT, pas le jour J
Un go-live WMS raté ne meurt jamais le jour J. Il meurt des semaines avant, dans une salle de réunion, quand quelqu’un décide que la recette WMS peut être « resserrée » pour tenir la date de démarrage. Sur le papier, l’arbitrage semble raisonnable : le paramétrage a débordé, la date est annoncée aux clients, et il reste l’hypercare pour rattraper le tir. Dans la réalité, c’est exactement là que les problèmes commencent. La phase de tests utilisateurs, l’UAT, est le seul moment du projet où les anomalies coûtent encore peu cher à corriger. L’amputer, c’est transférer le risque en production, au pire moment, avec les flux réels et les clients en bout de chaîne. Cet article détaille ce qu’une recette sérieuse exige vraiment : un référentiel de scénarios vivant, un formalisme de test minimal mais non négociable, une équipe dédiée, et surtout du temps.
Table des matières
La recette WMS, variable d’ajustement des plannings
Le schéma est toujours le même. Les phases amont glissent : spécifications qui s’éternisent, interfaces ERP ou WCS livrées en retard, paramétrage plus lourd que prévu. La date de go-live, elle, ne bouge pas. Elle a été annoncée à la direction, parfois au client. La seule phase compressible qui reste entre les deux, c’est la recette.
L’exploitation pousse dans le même sens, et on la comprend : chaque semaine de recette WMS est une semaine où des équipes tournent en double, où l’ancien système vit en sursis. Le réflexe de raccourcir l’UAT pour démarrer vite est humain. Il est aussi dangereux, parce qu’il inverse la logique économique du projet.
Un projet WMS complet représente entre 80 000 et 350 000 euros la première année pour une PME logistique, selon le comparatif du cabinet Amalo — et bien davantage sur un grand site automatisé. Gagner deux semaines de planning en sacrifiant la phase qui valide cet investissement, c’est jouer plusieurs centaines de milliers d’euros à pile ou face.
Un référentiel de scénarios vivant, pas un plan de test figé
Première idée reçue à abattre : le plan de test ne s’écrit pas une fois pour toutes avant la recette WMS. Les scénarios viennent de l’expérience et du vécu terrain. Et même en déroulant les premiers cas de test, vous tomberez sur des situations nouvelles, des idées qui surgissent au hasard d’une manipulation. Celles-là aussi doivent être répertoriées et ajoutées au référentiel, au fil de l’eau.
Soyons honnêtes : on ne teste jamais tout. Un WMS sur un site multi-flux génère des combinaisons de cas qu’aucun cahier de recette n’épuisera. L’objectif n’est pas l’exhaustivité, c’est la couverture maximale du risque : lister un maximum de scénarios plausibles pour réduire au minimum la probabilité d’un démarrage raté.
Et le vrai gisement de risque n’est pas dans les cas nominaux. Une réception standard qui fonctionne, tout le monde sait la tester. Ce qui fait mal en production, ce sont les cas dégradés : le colis sans étiquette, l’écart de stock inexpliqué, la reprise d’activité après une panne, l’annulation en plein milieu d’un flux. Une recette WMS qui ne teste que le chemin heureux est une recette Potemkine.
OK, KO, attendu, réel : le formalisme qui sauve une recette WMS
Deuxième exigence : la traçabilité. Chaque cas de test doit être consigné avec un statut OK ou KO, le comportement attendu, le comportement réellement observé, et un commentaire. Rien de plus, rien de moins.
Ce formalisme paraît bureaucratique. Il est en réalité ce qui rend les arbitrages possibles. Sans lui, la réunion go/no-go se résume à des impressions : « globalement ça marche ». Avec lui, on sait précisément combien de scénarios sont KO, sur quels flux, avec quelle gravité, et on décide en connaissance de cause — y compris de démarrer avec des réserves documentées.
| Scénario | Comportement attendu | Comportement réel | Statut | Commentaire |
|---|---|---|---|---|
| Réception d’un support sans étiquette porteur | Blocage en zone d’anomalie, création d’une tâche de reprise | Conforme | OK | — |
| Annulation d’une commande déjà lancée en préparation | Tâches de picking annulées, stock réaffecté | Les tâches restent actives sur les terminaux | KO | Anomalie bloquante, ticket éditeur n°142 |
| Reprise de flux après arrêt convoyeur > 30 min | Reprise séquencée sans perte de colis | 3 colis perdus de vue par le système | KO | À retester après correctif WCS |
Un point que les éditeurs et intégrateurs mettent rarement en avant, et pour cause : ces cahiers de tests doivent être rédigés et exécutés par le client, pas par eux. Comme le rappelle GPO Magazine, un intégrateur ne peut pas être juge et partie sur la validation de son propre travail. C’est votre exploitation qui vivra avec le système ; c’est à vos équipes de le recetter.
Entrepôt automatisé : une recette qui se joue aussi sur le terrain
Sur un petit site, une recette WMS peut presque se dérouler depuis un bureau. Sur un grand entrepôt avec intégration mécanisée — convoyeurs, trieurs, systèmes de stockage automatisés — c’est une autre histoire. Les flux sont nombreux, les process sont longs, et beaucoup de scénarios exigent des déplacements physiques : injecter un support en tête de ligne, aller constater son comportement à l’autre bout du bâtiment, vérifier ce que le système a tracé à chaque étape.
Tester un flux de bout en bout peut mobiliser plusieurs personnes pendant des heures, pour un seul scénario. Cette dimension physique est systématiquement sous-estimée dans les plannings : on chiffre la recette en nombre de cas de test, pas en kilomètres parcourus ni en coordination entre le système d’information et la mécanique. C’est pourtant sur ces flux transverses WMS-WCS que se nichent les anomalies les plus coûteuses.
Une petite équipe, un UAT Lead, et du temps
Côté organisation, le piège classique consiste à confier les tests à des opérationnels « prêtés quand ils ont le temps ». Résultat : une recette WMS en pointillé, sans mémoire, où personne ne sait ce qui a déjà été testé. Le bon format est une petite équipe dédiée, avec un UAT Lead identifié qui tient le référentiel de scénarios, arbitre les priorités de test et consolide les résultats pour le go/no-go.
Reste la question qui fâche : combien de temps ? Il n’existe pas de règle universelle, et méfiez-vous de quiconque vous en vend une. Un ordre de grandeur constaté sur le terrain : comptez un à deux mois de recette WMS par process, selon sa complexité. Et précisément parce que c’est long, on ne démarre pas tout en même temps.
La pratique la plus saine sur les sites complexes est le go-live par vagues : on recette un process, on le démarre, on le stabilise, puis on passe au suivant. Lancer plusieurs process de front reste possible quand ils sont indépendants, mais c’est l’exception, pas la règle. Cette logique rejoint d’ailleurs le phasage 80/20 défendu par les praticiens du déploiement WMS : ce qui n’est pas validé dans une première vague est repris dans la suivante, sans compromettre l’exploitation.
Non, l’hypercare ne rattrapera pas une recette bâclée
L’objection arrive toujours : « il y a l’hypercare pour ça ». C’est vrai qu’une phase d’hypercare suit tout démarrage, avec un support renforcé et des correctifs rapides. Mais l’hypercare est conçu pour absorber le résiduel — les anomalies fines qu’aucune recette n’aurait attrapées — pas le structurel.
Un flux entier qui dysfonctionne parce qu’il n’a jamais été testé de bout en bout, ce n’est pas un sujet d’hypercare : c’est une recette faite en production, au rythme de l’exploitation, avec des commandes clients réelles en guise de jeux d’essai. La différence de coût est brutale. En UAT, une anomalie se corrige tranquillement, se reteste, se referme. En production, la même anomalie génère des colis bloqués, des équipes en mode dégradé et des pénalités de service.
La recette WMS et l’hypercare ne sont pas interchangeables. L’un valide avant, l’autre stabilise après. Il faut laisser son temps à chacun.
Ce qu’il faut retenir
Une recette WMS réussie tient en quatre décisions : un référentiel de scénarios vivant, enrichi en continu et orienté cas dégradés ; un formalisme OK/KO systématique avec comportement attendu et réel ; une équipe dédiée pilotée par un UAT Lead côté client ; et un délai sanctuarisé, défendu face à la pression du planning. Si vous ne devez retenir qu’une chose : la date de go-live se négocie, la qualité de la recette non. Un démarrage décalé de trois semaines s’oublie en trois mois. Un démarrage raté se paie pendant un an.
La recette n’est d’ailleurs qu’un maillon : elle valide un système qu’il faut d’abord avoir bien choisi. Sur ce point, notre analyse des critères de choix d’un WMS pour un 3PL pose le cadre en amont du projet.
FAQ — Recette WMS et go-live
Qu’est-ce que la recette (UAT) dans un projet WMS ?
La recette WMS, ou UAT (User Acceptance Testing), est la phase où les équipes du client testent le système paramétré, scénario par scénario, avant le go-live. Elle valide que le WMS se comporte comme attendu sur les flux réels du site, cas nominaux comme cas dégradés.
Combien de temps dure une recette WMS ?
Il n’y a pas de durée universelle. Un ordre de grandeur constaté sur le terrain : un à deux mois par process, selon sa complexité et le niveau d’automatisation du site. Sur les sites complexes, les process sont recettés et démarrés par vagues successives plutôt que tous en même temps.
Qui doit rédiger et exécuter les cas de test ?
Le client, pas l’éditeur ni l’intégrateur, qui ne peuvent être juge et partie. Le bon format : une petite équipe dédiée, pilotée par un UAT Lead qui tient le référentiel de scénarios et consolide les résultats pour la décision go/no-go.
L’hypercare peut-il compenser une phase de tests écourtée ?
Non. L’hypercare est conçu pour traiter les anomalies résiduelles après le démarrage, pas pour découvrir en production des flux jamais testés. Compresser la recette revient à transférer les tests en conditions réelles, avec des commandes clients comme jeux d’essai — le scénario le plus coûteux qui soit.
