Au printemps de 2024, un responsable d'exploitation d'un 3PL près de Dallas a signé un contrat pour un système d'inventaire IA embarqué sur drones. La démonstration avait été spectaculaire : un drone glissant au-dessus des racks, des rapports d'écarts générés automatiquement. Il a signé un abonnement annuel. Puis la réalité est arrivée. L'entrepôt tournait sur un WMS vieux d'une décennie, et l'interface de données sur mesure dont l'informatique avait besoin était déjà en file pour deux trimestres. La « précision de reconnaissance » du contrat avait été mesurée sur le jeu de test du fournisseur lui-même — personne ne l'avait testée dans une zone mixte de palettes et de cartons en vrac. Une année entière d'abonnement a été payée avant que le système ne se connecte à la moindre source de données.
La technologie était bonne. Le responsable, non.
J'ai vu ce film depuis l'autre côté aussi. Un projet mené par l'informatique, un système d'IA de vision pour le contrôle à la réception dans un entrepôt de taille moyenne. Le directeur informatique a tout fait selon les règles : il a convoqué trois fournisseurs, comparé les fiches techniques sur la précision, la latence et les protocoles d'API, choisi celui avec les meilleurs chiffres de laboratoire. Ce qu'il n'a jamais fait, c'est marcher sur le quai de réception avec l'équipe. Dans un vrai entrepôt, l'éclairage des racks éblouit, les étiquettes sont collées de travers, et le film étirable capte la lumière. Rien de tout cela ne figure sur une fiche technique. Dès la première semaine, les faux positifs ont doublé le temps de vérification de l'équipe. Le responsable réception m'a dit sans détour que le pistolet scanner était plus rapide. En quelques mois, l'équipe de nuit avait cessé d'allumer le système.
Voici la vérité inconfortable sur l'IA en entrepôt : le plus difficile n'a jamais été le modèle. Ce sont trois questions — d'où viennent les données, qui définit ce qui compte comme « correct », et qui est responsable du résultat. L'informatique ne peut pas répondre seule aux trois. L'exploitation ne peut pas répondre seule aux trois. Un rapport RAND publié en 2024, « The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed », a constaté que plus de 80 pour cent des projets IA ne livrent pas la valeur attendue, et que les racines se trouvent généralement dans l'organisation et les données, pas dans les algorithmes.
Même Amazon, qui peut dépenser plus que tout le monde, refuse de laisser l'algorithme boucler seul. En juin 2024, l'entreprise a annoncé le Project P.I. — « private investigator » — un système combinant IA générative et vision par ordinateur dans des tunnels d'imagerie répartis sur plusieurs centres de fulfillment en Amérique du Nord, pour détecter les produits endommagés et les mauvaises couleurs ou tailles avant expédition. Le détail qui compte : les articles signalés par le système sont examinés par des associés Amazon, qui décident si le produit est soldé, donné ou laissé en circulation. Les humains prennent la décision finale. Si Amazon ne laisse pas la machine gérer seule l'entrepôt, un 3PL de 50 personnes ne devrait certainement pas essayer.
Le piège du projet mené par l'informatique et le piège du projet mené par l'exploitation sont le même piège
Les deux modes d'échec semblent opposés, mais ils échouent pour la même raison : un côté du bâtiment s'approprie une décision qui exige les deux côtés.
Quand l'informatique le porte seule, on obtient un jouet technologique. La démonstration reçoit des applaudissements ; l'atelier le contourne. L'informatique évalue ce qu'elle peut mesurer — la précision sur des données propres, la disponibilité, l'effort d'intégration — et sous-estime ce qui décide de l'adoption : les reflets au troisième niveau d'un rack, un processus que l'équipe suivra réellement à 2 heures du matin, qui réentraîne le modèle quand le mix produits change au quatrième trimestre.
Quand l'exploitation le porte seule, on obtient un bon de commande en quête d'un projet. L'exploitation peut décrire la douleur parfaitement et ne peut pas évaluer le chemin de livraison. Le commercial du fournisseur est payé pour obtenir la signature, pas pour faire fonctionner le système — et l'acheteur côté exploitation est la personne la plus facile à éblouir dans tout le bâtiment avec une démonstration qui ne survivra jamais au contact d'un WMS hérité.
La solution que je recommande désormais à chaque client est un modèle à double direction : un responsable métier et un responsable technologique, pairs, partageant le résultat. Cela sonne comme un cliché jusqu'à ce qu'on l'écrive. Le responsable métier est propriétaire de trois choses : définir le problème (inventaires tournants lents ou écarts élevés — choisissez-en un), engager les personnes et les heures pour le travail sur les données, et valider l'efficacité. Le responsable technologique est propriétaire de trois autres choses : le choix du fournisseur et de l'architecture, l'intégration au WMS et au matériel, et la sécurité des données. Le chevauchement au milieu — la traduction — appartient à un rôle d'analyste métier qu'on ne peut pas sauter.
Cet analyste métier n'est pas un employé de documentation. C'est quelqu'un qui parle les deux langues : il peut passer une demi-journée avec l'équipe d'inventaires tournants, revenir, et expliquer au fournisseur en termes techniques que le troisième niveau d'un rack reflète la lumière ; il peut entendre le fournisseur dire que le modèle a besoin de milliers d'images étiquetées et le traduire en « l'équipe d'inventaire sacrifie trois jours ». Promouvez un superviseur senior à ce poste ou recrutez un conseiller externe — mais ne lancez pas le projet sans lui. Sans traducteur, les réunions entre l'informatique et l'exploitation sont deux monologues. Soit l'informatique cède à une exigence métier déraisonnable, soit l'exploitation se retrouve forcée d'utiliser un outil que personne n'aime.
Comment mener le pilote sans brûler une année
Constituez une équipe pilote légère mais fixe : un analyste métier, à temps plein sur le projet ; un homologue informatique, à temps partiel c'est bien, mais ce doit être la même personne chaque semaine ; deux opérateurs de l'atelier, fixes pour toute la durée, pas de rotation — le moyen le plus rapide de corrompre un pilote est de changer sans cesse qui est mesuré ; et un spécialiste d'implémentation du fournisseur. Cadence : un stand-up de trente minutes chaque semaine couvrant seulement trois choses — ce que les données ont montré, ce qui est bloqué, ce qui sera testé ensuite — et une revue mensuelle d'une heure sur la tendance. Ma règle pratique : un pilote doit rendre son verdict en six à huit semaines. Go/no-go. Les pilotes qui dérivent au-delà de trois mois meurent presque toujours en silence, l'argent et la bonne volonté envolés.
L'acceptation est là où je deviens strict. Une page, deux lignes de signature. Le responsable métier signe pour l'efficacité : deux semaines consécutives dans l'environnement réel, sur de vrais postes, atteignant les chiffres de taux de manqués et de fausses alarmes écrits avant le démarrage du projet. Le responsable technologique signe pour la partie technique : interfaces stables, données renvoyées dans le WMS, contrôles d'accès en place. Une signature manquante signifie que le projet n'est pas terminé. Et les critères d'acceptation doivent exister avant le lancement — des critères écrits le jour de l'acceptation sont des critères que le fournisseur réussira toujours.
L'entrepôt d'une ou deux personnes peut le faire aussi
Les petits exploitants lisent tout cela et pensent : nous avons à peine deux managers, où trouver une double direction ? La réponse est que plus on est petit, plus la structure doit être légère — mais aussi plus littérale.
Réduisez-le à un seul geste : confiez le rôle de traducteur à une personne nommée. Choisissez le superviseur d'entrepôt le moins hostile aux systèmes, ou la personne informatique qui marche réellement sur l'atelier. Donnez-lui un titre pour la durée du pilote — homologue métier pour ce projet IA — et une heure protégée par jour. Cette heure compte plus que la licence du logiciel, car neuf fois sur dix, les projets IA meurent de « personne sur l'atelier n'a coopéré », et non de « le modèle était faux ».
Pour la sélection, résistez au pack. Commencez par exactement un point de douleur : les écarts d'inventaire, la recherche d'emplacements de stockage, ou la vérification en sortie. Quand le fournisseur demande si vous voulez les modules supplémentaires, dites non. Trois clauses vont dans le contrat : paiement lié aux résultats du pilote avec sortie inconditionnelle si le pilote échoue ; le travail d'interface de données et son calendrier joints par écrit ; formation dispensée aux opérateurs de l'atelier, pas seulement à leurs superviseurs. Et trois tests d'acceptation stricts : deux semaines dans l'environnement en production, les chiffres convenus avant le lancement effectivement atteints, et — celui qui compte le plus — les opérateurs allument le système de leur propre initiative. Le système le plus précis au monde ne vaut rien si l'équipe ne veut pas le démarrer.
Voici l'exercice que je ferais demain. Prenez le projet IA que vous menez ou planifiez, et écrivez une page : quel problème il résout, quels sont les critères d'acceptation, et les noms du responsable métier et du responsable technologique — avec deux lignes de signature vierges en bas. Si vous ne pouvez pas écrire cette page, ou si les deux lignes ne peuvent porter que le même nom, vous regardez la même configuration que l'équipement couvert de poussière de mon histoire d'ouverture. Tuez-le tôt. C'est bien plus digne que de brûler d'abord le budget.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
