Personne n'a mesuré les 2 % où le modèle réécrit votre numéro de facture

Les 2 % que personne ne consigne

Voici le scénario au cœur d'un article publié cette semaine sur DEV.to par Dimitris Kyrkos, analyste de marché chez Cyclopt à Thessalonique. Une équipe doit extraire des numéros de facture d'e-mails entrants. Les numéros suivent un format fixe : INV- suivi de huit chiffres. L'équipe envoie chaque e-mail à un grand modèle de langage avec une consigne lui demandant d'extraire le numéro.

Cela fonctionne dans 98 % des cas. Dans les 2 % restants, écrit Kyrkos, le modèle reformate « obligeamment » le numéro, ou récupère à la place un numéro de bon de commande. Chaque appel coûte de l'argent et ajoute quelques centaines de millisecondes. Une expression régulière de quatre lignes fait le même travail de façon déterministe, en microsecondes, pour un coût quasi nul.

Soyons clairs sur la nature de ce scénario : Kyrkos précise lui-même que ses scénarios sont illustratifs, et non des études de cas. Les 98 % sont une valeur de substitution, pas une mesure. Ce qui rend l'article intéressant, ce n'est pas ce chiffre, mais ce qui s'est passé dans les commentaires.

Trois erreurs de catégorie, expliquées

L'argument repose sur une distinction qui se perd dans les discussions d'achat de solutions d'IA : la différence entre les questions portant sur des faits et celles portant sur le sens.

Une expression régulière est une règle de recherche de motif. Face à « INV- puis huit chiffres », elle trouve une correspondance ou n'en trouve pas. Il n'y a aucune probabilité en jeu, aucun réglage de température, aucune exécution où elle déciderait de faire preuve de créativité. C'est le compromis : aucune souplesse, une prévisibilité totale.

La recherche vectorielle fonctionne à l'inverse. Le texte est converti en une liste de nombres, un plongement (embedding), qui le positionne dans un espace où les significations proches se retrouvent côte à côte. On récupère ensuite les quelques résultats les plus proches, le « top-k ». C'est très efficace pour « trouver les tickets qui ressemblent à cette réclamation ». C'est le mauvais outil pour « montrer toutes les commandes impayées du client 4417 sur les 30 derniers jours », question à laquelle Kyrkos répond par une requête SQL de quatre lignes. Igor Eduardo, ingénieur en IA qui travaille sur l'IA clinique et la pharmacovigilance, a formulé le problème avec netteté dans les commentaires : il ne s'agit pas d'un problème de qualité de récupération, mais d'une erreur de catégorie. Une requête de filtrage a une réponse complète et exacte. Une liste de résultats vectoriels est une présélection probabiliste à laquelle on n'a jamais demandé d'être exhaustive.

Le troisième cas est l'exemple du routage : forfait entreprise plus facturation, vers la gestion de comptes ; bogues, ouverture d'un ticket ; tout le reste, lien vers la FAQ. Quatre branches. Si vous en faites un agent autonome, c'est-à-dire un modèle doté d'un accès à des outils, d'une boucle de planification et d'une mémoire, le routage devient probabiliste, entre parfois dans des boucles, et personne ne peut reconstituer pourquoi tel ticket est arrivé à la mauvaise équipe.

Ce qui est réellement démontré ici

Aucun benchmark, aucune donnée de dépenses, aucune entreprise nommée. Ce que le fil de discussion contient, en revanche, c'est un accord de praticiens d'une précision inhabituelle. Eduardo dit voir sans cesse le mode de défaillance n° 2 à l'intérieur de bots « de connaissance ». Brian, qui tient un compte d'actualités sur l'IA, affirme que les équipes jugent une extraction à 98 % suffisante et ne mesurent jamais les 2 % qui réécrivent discrètement le numéro. Il ajoute une solution concrète : consigner les échecs dans un jeu de données étiqueté, et au bout d'un mois, vous saurez si le résidu est réellement désordonné ou s'il s'agit simplement d'un second motif que vous n'avez jamais écrit.

Le fil contient aussi son propre contrepoids, que la plupart des résumés passeront sous silence. Michael Hairetis, ingénieur full-stack avec 25 ans de production derrière lui, dit que ses instructions if sont devenues des « instructions if IA » et en fait une astuce utile. Kyrkos en convient : lorsque la condition elle-même est floue, un routeur souple à base de LLM est un bon schéma, à condition que cette étape reste isolée afin que le reste du système demeure prévisible.

Pierre-Laurent Medori, responsable de l'ingénierie backend chez GoodBarber, a proposé la formulation la plus transposable. Il la compare à la position de Python sur les classes face à celle de Java, et cite la conférence de Jack Diederich à PyCon en 2012, « Stop Writing Classes » : si une classe a deux méthodes dont l'une est init, c'est une fonction. Transposé : si votre agent n'a qu'un seul outil et que le planificateur le choisit à chaque fois, c'est un appel de fonction avec une facture de jetons. Son vrai propos est architectural : gardez l'étape derrière une signature de fonction ordinaire, et passer de l'instruction if à l'appel de modèle reste une modification locale. Faites du cadre d'agents le paradigme dès le premier jour, et chaque appelant hérite de la dépendance.

Les questions à vous poser

• Pour chaque classe de questions auxquelles répond votre système, s'agit-il d'une question exacte, d'un filtre ou d'une question sémantique ? Si elle est exacte ou de type filtre et que le chemin passe tout de même par des plongements et une boucle d'agent, qu'achète la dépense en GPU ?
• Consignez-vous les cas où la sortie du modèle diverge d'un contrôle déterministe, et quelqu'un a-t-il examiné cet ensemble ?
• Quand une décision de routage est erronée, quelqu'un peut-il en reconstituer la raison en moins d'une heure, ou la réponse contient-elle l'expression « c'est le planificateur qui a décidé » ?
• Si le mode de défaillance est une donnée erronée silencieuse plutôt qu'une erreur visible, pourquoi un composant non déterministe figure-t-il sur ce chemin ?
• Qui mettra à jour, comprendra et déboguera chaque cadre logiciel de la pile dans douze mois, et ces personnes en ont-elles convenu ?

Ce qu'il faut surveiller ensuite

Surveillez si quelqu'un publie la mesure qui manque à ce fil : une équipe en production chiffrant le résidu réel, c'est-à-dire combien d'entrées passent à travers un chemin déterministe, ce que le modèle récupère, et ce qu'il corrompt en silence. La suggestion de Brian est la version la moins coûteuse de cette expérience, et elle prend un mois. Tant que personne ne l'aura menée et n'aura montré les données, « la moitié des agents en production sont des instructions if » restera une intuition bien argumentée et solidement soutenue par les praticiens, ce qui est plus que ce dont disposent la plupart des conseils d'architecture en IA, et reste moins que ce sur quoi une décision devrait reposer.