La conclusion d'abord : les requêtes de stock en langage naturel fonctionnent aujourd'hui — mais seulement dans un couloir étroit : un vocabulaire contrôlé plus une étape de confirmation. S'attendre à ce que le système comprenne tout ce que vous dites à l'improviste, à chaque fois ? Testez-le d'abord dans votre propre entrepôt. La plupart des opérations que j'ai vues n'en sont pas encore là.
J'ai vu cet échec exact trois fois. La première fois, c'était chez un 3PL dans l'est de la Chine, à l'automne 2025. Ils voulaient que les superviseurs d'atelier se contentent de « demander » les chiffres de stock : un superviseur disait dans une tablette « Quel est le stock disponible des produits 3C dans la zone A ? » et le système répondait instantanément. Doux comme du beurre. La troisième semaine, tout a explosé : ils ont préparé une expédition promotionnelle sur la base du chiffre donné par le système, il manquait deux palettes, et il a fallu organiser un transport express. Un seul transport routier express a effacé trois mois d'économies de main-d'œuvre. L'autopsie a révélé deux problèmes fatals. D'abord, il n'existait aucune catégorie « produits 3C » dans leur WMS — le modèle l'avait hallucinée en « électronique grand public », en y intégrant coques de téléphone et câbles tout en ratant la moitié des vrais accessoires 3C. Ensuite, le « modèle A » existait sous forme de deux SKU (variantes rouge et bleue), et le système n'en avait interrogé qu'un seul. Il ignorait que le « modèle A » était, dans l'argot de cet entrepôt, une famille de deux.
La deuxième fois, un entrepôt e-commerce s'y est bien pris. Trois phrases pour expliquer pourquoi : le vocabulaire a été défini par des humains, pas deviné par le modèle ; chaque réponse commençait par « voici ce que j'ai compris » et attendait un tap pour confirmer ; chaque chiffre portait sa source. Ils ont mis en liste blanche les dimensions interrogeables — entrepôt, zone, catégorie, SKU, lot, statut de stock — six dimensions, avec pour chacune une table de synonymes maintenue par des humains. « Produits 3C » pas sur la liste ? Le système répondait : « produits 3C n'est pas une catégorie interrogeable. Vouliez-vous dire accessoires numériques ou électronique grand public ? » L'opérateur tapait une fois. Dix secondes. Cette étape de confirmation semble maladroite. C'est le fusible qui protège la précision.
La troisième fois était plus retorse : un entrepôt cosmétique l'an dernier où chaque nom de SKU était une teinte — « rose cerise », « rose pêche », « rose pâte de haricots ». Le modèle a décidé que les trois se ressemblaient et les a fusionnés comme synonymes, si bien que demander « combien de rose nous reste-t-il » renvoyait les stocks des trois SKU additionnés en un seul chiffre. L'inventaire tournant ne concordait pas, et l'équipe de l'entrepôt a fini par hurler avec les opérations e-commerce. Leçon : les teintes, les spécifications, les versions — des choses qui ressemblent à des synonymes mais ne doivent jamais être fusionnées — ont besoin d'un drapeau explicite « ne pas fusionner » dans la table de correspondance. Une table de synonymes n'est pas un cas de « plus c'est gros, mieux c'est » ; une entrée fausse fait plus de mal qu'une entrée manquante.
Comment le premier 3PL s'en est-il remis ? Trois étapes. D'abord, ils ont supprimé les questions en texte libre et sont passés à « choisissez les dimensions, puis demandez », en mettant tout ce qui est interrogeable dans une cage. Ensuite, ils ont fait asseoir deux superviseurs chevronnés pendant deux semaines et ont construit la table de synonymes jusqu'à plus de 200 entrées. Les superviseurs ont d'abord grogné, puis découvert que c'était trois fois plus rapide que de feuilleter les registres, et ont commencé à l'utiliser volontairement. Troisièmement, chaque réponse a été forcée de porter sa source et son horodatage. Deux mois plus tard, leurs mauvaises réponses avaient pratiquement disparu — et notez que le modèle n'était pas devenu plus intelligent. La cage s'était resserrée.
Pourquoi je dis que le goulot d'étranglement n'est pas le modèle ? Voici le pipeline, quatre étapes, et je suis tombé sur chacune.
Comment fonctionnent vraiment les requêtes de stock en langage naturel : quatre étapes, quatre pièges
- Reconnaissance de l'intention : traduire « combien en reste-t-il » en « interroger le stock disponible ». C'est ce que le modèle fait le mieux. Le cadet de vos soucis.
- Mappage des entités : mapper la « zone A » et les « produits 3C » sur les données de référence réelles du WMS. C'est la zone de catastrophe. Un produit avec trois noms, la moitié de vos champs de catégorie vides, d'anciens et de nouveaux codes de zone mélangés — la table de correspondance meurt ici. Une règle : un modèle ne peut mapper que des choses qui existent et sont uniques. Ce qui n'est pas dans vos données de référence, il le devine. Les devinettes tournent mal.
- Appel à l'API du WMS : transformer le mappage en une vraie requête contre l'API. Cela exige une API de requête propre et en lecture seule. Beaucoup de points de terminaison de requête des WMS hérités ont été conçus pour des rapports lisibles par des humains ; leurs définitions de champs ne correspondent pas au grand livre de stock, si bien que deux chiffres se contredisent et que l'opérateur doit en choisir un.
- Validation du résultat : vérifier la réponse avant de l'afficher. L'entrepôt e-commerce qui s'y est bien pris a ajouté ici une règle stricte : chaque réponse doit porter sa provenance — « Source : grand livre de stock disponible de la zone A. Filtres : zone = A ET catégorie = accessoires numériques. Mis à jour il y a 10 minutes. » Pas de provenance, pas d'affichage.

Liste de contrôle pré-pilote pour les requêtes de stock en langage naturel
- D'abord les données de référence, trois barrières : dédupliquer les SKU, remplir les champs de catégorie, unifier les codes de zone. Sautez-les et tout le reste est du théâtre.
- Mettez en liste blanche les dimensions interrogeables : commencez par trois à cinq. N'ouvrez pas tout le premier jour.
- Construisez la table de synonymes à la main : asseyez-vous avec un superviseur d'atelier et mappez chaque terme d'argot sur un code système, un par un. Un jour de travail. Ça vaut le coup.
- La confirmation est obligatoire : le système énonce « voici ce que j'ai compris » et l'utilisateur confirme avant que le chiffre apparaisse. Si cela semble trop de friction, ne lancez pas la fonctionnalité.
- D'abord en lecture seule : le pilote interroge seulement. Il n'écrit jamais. Laisser le modèle ajuster les soldes ou changer les statuts de stock ? J'ai vu cet échec trois fois. Je n'en veux pas un quatrième.
- Instrumentez tout : journalisez chaque question, l'interprétation du système, si l'utilisateur l'a corrigée et quelle était la correction. Dans trois mois, ce journal sera la mine d'or pour améliorer votre table de correspondance.
- Définissez le plan B de la « mauvaise réponse » : quand une requête se trompe, quel est le processus de remédiation, et qui en est responsable ? Réglez les vilaines questions avant le go-live, pas après.
Voici la partie contre-intuitive : on me demande « peut-on atteindre 99 % de précision ? » Ma réponse : mauvaise question. Le plafond de précision n'est pas fixé par le modèle. Il est fixé par la propreté de vos données de référence. Avec des données de référence en désordre, le modèle est un stagiaire qui invente des réponses assurées ; avec des données de référence propres, c'est un vétéran qui compte vite. Nettoyez d'abord les données de référence, puis parlons langage naturel. C'est un problème de séquencement, pas un problème de technologie.
Pour revenir à la question d'origine : la précision des requêtes de stock en langage naturel est-elle suffisante ? Cela ne dépend pas du modèle. Cela dépend de trois choses : si votre vocabulaire est défini, si la confirmation est en place, et si vos données de référence sont propres. Les trois en place — allez-y. Il en manque une — faites d'abord vos devoirs.
Par Lin Xiao, consultant en mise en œuvre de WMS
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.











