Un opérateur 3PL de Fontana, en Californie, a dépensé au printemps dernier environ $45 000 pour un assistant IA censé répondre à « toutes les questions de SOP sur le terrain ». La démo était impeccable. Le rapport de pilote du fournisseur affichait un taux de satisfaction de 94 %. Trente jours après la mise en production, le responsable sécurité a examiné les journaux : près d'une réponse sur quatre contenait une erreur — une hauteur de gerbage erronée, un seuil de température erroné, une règle d'emballage client erronée. L'assistant livrait chacune avec une confiance totale et une citation parfaitement mise en forme.
C'est la partie que les fournisseurs ne mettent pas dans leur présentation : un assistant d'entrepôt à récupération augmentée ne rate pas parce que le modèle de langage est bête. Il rate parce que l'ingénierie autour n'a jamais été terminée. J'ai vu quatre de ces déploiements déraper cette année, et le schéma de panne est si régulier que je peux presque le réciter.
D'où viennent vraiment les mauvaises réponses
Le premier point de panne, c'est la récupération (retrieval), et il explique la majeure partie des dégâts que j'ai vus. Les documents d'entrepôt — SOP, manuels d'équipement, SLA clients — sont généralement découpés en morceaux de taille fixe, 500 tokens chacun, puis intégrés dans un magasin vectoriel. Un opérateur demande si les chariots élévateurs peuvent charger dans la zone chaîne du froid. Le système récupère une politique de local batterie vieille de trois ans, écrite pour un abri de charge extérieur, et assemble une réponse qui sonne officielle et qui est totalement inapplicable. Le morceau a perdu son contexte ; l'embedding n'a compris que la similarité de surface.
Le deuxième point de panne, c'est le versionnement des documents, et il est plus sournois. Les documents d'entrepôt changent plus vite que l'informatique ne l'imagine. Un SOP passe de v2 à v3 parce qu'un responsable client l'a dit et que quelqu'un a scotché un nouveau formulaire au mur. L'ancien PDF reste dans la base de connaissances sans drapeau « remplacé » ni filtre de date d'effet. Le modèle ne sait pas quelle version est en vigueur — il assemble simplement les fragments les mieux notés. À Fontana, l'assistant a un jour cité « SOP v3.2, section 4 » pour une limite de gerbage. L'entrepôt n'avait jamais produit de v3.2. Le modèle avait fusionné une section de v2 avec une section de v3 et inventé le numéro de version. Les hallucinations sont souvent construites à partir de fragments récupérés à moitié vrais, pas à partir de rien.
Le troisième point de panne, c'est la frontière du savoir. Les employés posent des questions hors base de connaissances : changements du salaire minimum local, tarifs de l'agence d'intérim d'à côté, politiques RH. Un assistant bien conçu devrait dire « je n'ai pas ça — demande à ton chef d'équipe ». Mais un modèle en configuration par défaut déteste dire qu'il ne sait pas. Il fabrique, et les chiffres fabriqués arrivent avec des décimales, ce qui les rend crédibles.
Le jeu golden : 50 à 100 questions avant de parler modèles
Mon conseil aux opérateurs est désormais direct : ne commencez pas par le choix du modèle. Commencez par un jeu d'évaluation.
La recette est simple. Demandez aux chefs d'équipe et au responsable sécurité de lister chacun 20 questions du type « se tromper là-dessus pourrait blesser quelqu'un » : limites de gerbage, dégagements d'allées, distances de ségrégation des matières dangereuses, seuils d'alarme de la chaîne du froid, règles d'emballage spécifiques à chaque client. Puis extrayez trois mois de questions réellement posées par les employés et prenez les 30 à 50 plus fréquentes. Vous obtenez 50 à 100 items, chacun assorti d'une « réponse golden » validée par un opérateur senior et par le responsable conformité — jusqu'au numéro de clause et à la version en vigueur.
Le jeu fait trois choses. Premièrement, lancez-le avant la mise en production ; si la précision de correspondance exacte avec les réponses golden est sous 85 %, ne lancez pas. Deuxièmement, relancez-le après chaque changement de modèle, changement de récupération ou mise à jour de documents, pour qu'en réparant une chose on n'en casse pas une autre. Troisièmement — et c'est celle qui compte — inscrivez-le dans le contrat fournisseur : précision d'acceptation, taux de refus et couverture des citations, liés aux conditions de paiement.
Le contrat le plus sérieux que j'ai vu spécifiait un pilote de 30 jours avec au moins 50 questions par jour, et l'acceptation exigeait ≥90 % de précision sur le jeu golden avec un taux de refus entre 5 % et 15 %. Notez le plancher sur les refus. Un assistant qui ne dit jamais « je ne sais pas » est bien plus dangereux qu'un assistant qui décline parfois. Un refus est un signal de santé, pas un échec.
Corrigez la récupération avant d'accuser le modèle
Quand les réponses déraillent, la plupart des équipes cherchent un modèle plus gros. D'après mon expérience, huit fois sur dix, le problème est la récupération, et le modèle porte le chapeau.
Changez d'abord la stratégie de découpage. Arrêtez de couper par comptes fixes de tokens. Découpez selon la structure naturelle du document : les SOP par section et clause, les manuels d'équipement par procédure complète de dépannage. Une clause coupée en deux ne peut être sauvée par un meilleur embedding. En pratique, le découpage sémantique est le gain de précision le moins cher disponible — il ne coûte presque rien.
Ensuite, ajoutez le filtrage par métadonnées. Étiquetez chaque document à l'ingestion : version, date d'effet, site applicable, zone applicable. Filtrez sur la dernière version en vigueur avant l'appariement sémantique. Ne supprimez pas les anciennes versions — les audits peuvent en avoir besoin — mais marquez-les remplacées et excluez-les par défaut de la récupération. Le site de Fontana a fait exactement ce changement et les numéros de version fantômes ont largement disparu.
Un autre mouvement sous-estimé : donnez aux questions à haute fréquence et haut risque une voie rapide déterministe. Hauteurs de gerbage, largeurs d'allées, seuils d'alarme — il y en a peut-être deux ou trois douzaines. Mettez-les dans des paires Q&R à correspondance exacte qui contournent entièrement la récupération vectorielle. Ce n'est pas de la triche. C'est sortir les questions les plus dangereuses d'un système probabiliste pour les mettre dans un système déterministe.
Trois règles qui forcent l'assistant à admettre l'incertitude
Même avec la récupération corrigée, les modèles confabulent parfois. On ne gouverne pas les hallucinations avec de l'espoir. On les gouverne avec trois règles dures.
Premièrement, les citations obligatoires. Chaque réponse doit nommer son document source et sa clause, et le lien doit mener au texte réel. En évaluation, une réponse sans citation vérifiable est notée fausse, point final. Cette seule règle force les fournisseurs à bien faire la récupération, car il n'y a plus rien à fabriquer.
Deuxièmement, refuser sous un seuil de confiance. Si les documents récupérés notent sous un seuil de pertinence, ou si plusieurs sources se contredisent, l'assistant répond « pas de réponse claire dans la base de connaissances — escaladé à votre chef d'équipe » et route la question vers un humain. Réglez le seuil avec prudence. Sur un sol d'entrepôt, le coût d'une mauvaise réponse est toujours supérieur au coût d'une absence de réponse.
Troisièmement, des contrôles humains ponctuels sur calendrier. Premier mois après la mise en production : 20 Q&R réelles aléatoires vérifiées par un humain chaque jour. Deuxième mois : 30 par semaine. Après trois mois stables : 10 par semaine. Chaque raté retourne dans le pipeline — problème de récupération, corriger le découpage et les étiquettes ; problème de document, mettre à jour la base de connaissances ; problème de frontière, ajouter une règle de refus. Gardez la piste d'audit. Vous en aurez besoin quand la sécurité posera des questions.
Les entrepôts qui ne devraient pas construire ça
Maintenant la partie qui agace les fournisseurs. Tous les entrepôts ne devraient pas construire un assistant Q&R IA.
Une exploitation de moins de 30 personnes ne devrait pas. Les SOP tiennent dans un classeur, les vétérans sont sur le terrain, et crier une question d'un bout à l'autre de l'allée est plus rapide et gratuit. Un entrepôt dont les SOP sont elles-mêmes un fouillis ne devrait pas non plus — des documents erronés, périmés, contradictoires injectés dans l'IA ne produisent qu'une confusion confiante à vitesse machine. Et un site avec moins de 20 questions par jour ne devrait pas s'embêter : le travail de maintenir le jeu d'évaluation, les contrôles ponctuels et la gouvernance documentaire coûtera plus cher que le temps de Q&R économisé.
Le bon cas est réel pour les sites de plus de 100 personnes avec plusieurs équipes et des SOP sensiblement différents par client — fort turnover, équipes de nuit sans personne à qui demander, des piles d'exigences spécifiques aux clients. Même là, positionnez-le honnêtement : c'est un vétéran numérique toujours disponible à consulter, pas un manager qui juge à votre place.
Avant de signer quoi que ce soit, répondez à une question : vos opérateurs seniors peuvent-ils trouver la dernière version en vigueur du SOP sans ouvrir un portable ? S'ils ne peuvent pas, l'IA ne le pourra pas non plus. Elle vous donnera juste la mauvaise réponse plus vite — avec une citation qui a l'air vraie.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
