Voici la vérité qui dérange sur les démos WMS : ce sont du théâtre. Du théâtre répété, scénarisé, chorégraphié. Et la plupart des acheteurs sortent du théâtre, signent un contrat, puis passent l'année suivante à se demander pourquoi le logiciel qui semblait si simple sur un écran de projection s'effondre dans leur entrepôt.
Je l'ai vu en 2019 chez un distributeur d'articles pour la maison près de Los Angeles. La démo était parfaite — scanner un code-barres, vagues libérées instantanément, parcours de picking optimisés comme un schéma de manuel. Le patron a signé sur place. Neuf mois plus tard, la semaine du go-live, l'entrepôt croulait sous 6,000 commandes en retard et le patron me criait depuis le quai : "En démo, ça marchait bien !"
Évidemment. C'était le but.
Trois tours de passe-passe des démos à surveiller
Premier, des données aseptisées. La base de la démo contient peut-être 500 SKU parfaits — chaque article codé-barres, chaque lot propre, chaque emplacement attribué. Votre entrepôt a 20,000 SKU, y compris ceux dont les codes-barres manquent, les cartons écrasés et trois lots mélangés sur une même palette. Le logiciel semble rapide parce qu'il n'a jamais rencontré de données sales.
Deuxième, le chemin tout tracé. Les démos commerciales suivent toujours la voie royale : réception, mise en stock, picking, emballage, expédition. Posez une question sur le traitement des retours et on vous répond "c'est configurable." Interrogez sur la traçabilité par numéro de série et on vous répond "nous le supportons." Ces deux mots — configurable, supporté — se traduisent régulièrement par une seconde facture de développement spécifique pendant l'implémentation. Demandez-leur de faire tourner votre vrai flux de retours en direct, sur le moment. La plupart ne le feront pas.
Troisième, le mauvais opérateur. La personne qui fait la démo est généralement un ingénieur avant-vente ou un consultant senior d'implémentation capable de piloter le système les yeux bandés. L'équipe qui implémentera votre projet sera différente — peut-être des consultants formés depuis trois mois. La fluidité de la démo n'a presque rien à voir avec la qualité de votre implémentation.
Reprenez le scénario au vendeur
Une vraie POC n'a qu'un seul principe : c'est l'acheteur qui écrit le scénario.
Écrivez le vôtre avant que l'éditeur ne touche à quoi que ce soit. Limitez-le à une dizaine de scénarios, tous tirés de commandes réellement traitées par votre entrepôt au cours des trois derniers mois. Ma liste recommandée : réception et mise en stock standard, réception palette complète avec casse, insertion d'une commande urgente dans une vague, réallocation après picking incomplet, retours d'articles sérialisés, réassort depuis une palette cassée, ajustement d'écart d'inventaire tournant, réétiquetage. Joignez des données réelles — au moins 2,000 de vos vrais SKU, y compris les moches — plus une vraie semaine de volume de commandes.
Puis fixez les règles du jeu : aucune donnée préchargée de l'éditeur, ils importent les vôtres sur place ; l'opérateur doit être votre superviseur d'entrepôt, pas leur consultant qui tient la souris ; chaque scénario est chronométré.
Cette règle du "sans aide" est la plus importante. J'ai assisté à des POC où le consultant de l'éditeur se tenait derrière l'opérateur en commentant chaque clic, tenant pratiquement la souris à sa place. Cela teste le consultant, pas le logiciel. Mettez votre superviseur le moins technophile aux commandes. S'il apprend pendant la session, le système est utilisable.
Quantifiez la barre de réussite ou n'y allez pas
Quand la POC se termine, ne demandez jamais à la salle "comment c'était ?" Les impressions sont les pires critères d'acceptation jamais inventés.
Écrivez les critères de réussite en page un de votre scénario de POC et faites-les signer par l'éditeur. Par exemple : au moins sept scénarios sur huit réalisés de bout en bout sans aucune aide de l'éditeur ; libération d'une vague de 500 commandes en moins de deux minutes ; un ajustement d'inventaire tournant en cinq clics maximum ; votre superviseur opère en autonomie pendant deux heures sans erreur.
Barre manquée ? Deux options : l'éditeur admet qu'il faut un développement spécifique et met le périmètre et le prix par écrit, ou il est écarté. La phrase à craindre est "on va regarder ça" — elle signifie "ça ne marche pas aujourd'hui."
Un piège que je dois signaler en particulier : la visite guidée. Certains éditeurs vont dérouler vos scénarios à votre place — leur consultant conduit, vos gens regardent — et appelleront cela une POC. C'est une démo avec votre logo dessus, pas une preuve de concept. Si les mains de l'éditeur sont sur le clavier plus que celles de votre équipe, arrêtez la session et réinitialisez les règles. Une POC où l'acheteur ne touche jamais le logiciel ne prouve rien, sauf que l'éditeur sait piloter son propre produit, ce qui n'a jamais fait débat.
Un dernier conseil : amenez votre responsable informatique à la POC et faites-lui évaluer la couche d'intégration. Votre WMS va dialoguer avec votre ERP, votre TMS, vos plateformes e-commerce. Une demi-journée suffit pour savoir si la documentation de l'API est réelle et si un environnement sandbox existe. Demandez aussi les limites de débit de l'API — un système qui vous bride à quelques centaines d'appels par heure s'étouffera dès que votre volume de commandes explosera. Un système aux interfaces pourries traînera votre implémentation par le fond.
Trois questions avant de signer
La POC est passée. Avant le contrat, obtenez par écrit ces trois réponses en annexe du contrat.
Un : pour chaque scénario validé par la POC, qui paie le développement spécifique si ça ne marche pas au go-live ? Beaucoup de contrats chiffrent l'implémentation comme une "estimation" avec des dépassements facturés à part. Joignez la liste des scénarios validés comme critères d'acceptation — si ça ne marche pas, c'est le problème de l'éditeur.
Deux : qui est exactement dans l'équipe d'implémentation ? Obtenez les noms des consultants responsables dans le contrat, avec une clause selon laquelle les remplacements nécessitent votre approbation. Les promesses verbales de "notre meilleure équipe" ne valent rien.
Trois : les délais de réponse pour les 90 premiers jours après le go-live. Quelque chose va casser — la question est à quelle vitesse ils interviennent. Écrivez-le : intervention à distance sous quatre heures pour les incidents critiques, sur site sous 24 heures.
Ce client d'articles pour la maison ? Ils ont changé de système. Au deuxième tour de sélection, je les ai fait tourner une POC de trois semaines avec des données réelles et plus de 200 commandes réelles. Le jour du go-live sur le nouveau système, l'entrepôt a bouclé avec deux heures d'heures supplémentaires. Le patron m'a dit plus tard qu'il aurait aimé s'y prendre comme ça dès la première fois.
Une POC est le seul moment avant la signature où vous pouvez faire faire au vendeur du vrai travail. Ne le gâchez pas.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
