- ▸ Le formulaire qui ne sait pas qu'il ment
- ▸ De cinq gestes de contrôle à une seule signature
- ▸ Valeur, condition, intention : l'anatomie de la panne
- ▸ Réécrire le brouillon, pas seulement le relire
Un formulaire rempli par une IA a toujours la même allure : propre, complet, aligné. Rien n’indique si une case vient d’une donnée vérifiée ou d’une pure supposition. Un document publié le 5 août 2026 sur GitHub par Jang-woo-AnnaSoft démontre que ce silence visuel cache trois pannes distinctes — valeur, condition, intention — indiscernables à l’œil humain.
Je le dis d’emblée, parce que c’est la thèse de cette tribune : nous avons cru concevoir des assistants qui exécutent nos instructions. Nous avons en réalité construit des rédacteurs de premier jet, et nous nous sommes nommés, sans le vouloir, correcteurs d’orthographe d’un texte dont nous ne connaissons plus l’origine.
Le formulaire qui ne sait pas qu’il ment
Prenez l’exemple le plus trivial cité par le document : « turn off the living room light ». Cinq mots, une intention limpide. Le modèle doit remplir un formulaire d’action — quelle pièce, quel appareil, quelle heure d’exécution éventuelle. S’il lui manque une information, la consigne est simple, presque universelle dans les prompts système : demander. Et le modèle demande, effectivement, lorsqu’il perçoit un vide.
Le problème n’est pas là. Il est en amont. Selon le document technique de Jang-woo-AnnaSoft, c’est le modèle lui-même qui décide de ce qui mérite une question — « search, but leave out what you inferred » illustre l’inverse du geste attendu : au lieu de signaler ce qu’il a déduit, le système le dissimule dans une case déjà remplie. Un champ vide appelle une question. Un champ rempli, même par une supposition, n’en appelle aucune. Voilà le mécanisme entier de la panne : « don’t omit anything you need to confirm, » demande-t-on au modèle. Mais il ne sait pas toujours ce qu’il devrait confirmer.
De cinq gestes de contrôle à une seule signature
Il faut mesurer ce qui a changé dans le geste humain lui-même, parce que c’est là, je crois, que se joue vraiment l’affaire. Le document décrit un ancien formulaire, celui qu’un opérateur remplissait à la main, comme une séquence de cinq décisions distinctes :
- décider quand et sous quelles conditions agir ;
- sélectionner le bon formulaire pour la tâche ;
- saisir chaque valeur requise ;
- vérifier d’où provient chaque valeur saisie ;
- confirmer que tous les champs obligatoires sont bien renseignés.
Cinq étapes, cinq points de friction, cinq occasions de repérer une anomalie. Aujourd’hui, comme le décrit le document, l’utilisateur « looks at the form presented to them and signs it » — il regarde le formulaire déjà rempli, et il signe. Une étape a remplacé les cinq autres. Le contrôle n’a pas disparu du vocabulaire de la revue humaine ; il a disparu de sa pratique.
Je ne dis pas que c’était mieux avant, par nostalgie d’un artisanat perdu. Je dis que la délégation d’une tâche n’est acceptable que si elle s’accompagne d’un déplacement équivalent de la vigilance. Or ce déplacement n’a pas eu lieu. Nous avons gardé le mot « vérification » en abandonnant le geste qui allait avec.
Valeur, condition, intention : l’anatomie de la panne
C’est le cœur de l’analyse, et c’est aussi ce qui donne son titre au document original — Only 3 Root Causes. Trois familles d’erreurs, trois symptômes différents, mais un point commun implacable : rien, sur le formulaire final, ne permet de les distinguer d’une exécution correcte.
| Type de panne | Ce qui échoue réellement | Ce que voit l’humain qui approuve | Conséquence concrète |
|---|---|---|---|
| Valeur | Une donnée vérifiée est remplacée par une donnée inventée, visuellement identique | Un champ rempli, en apparence normal | Approbation d’une hypothèse jamais confirmée |
| Condition | Une règle qui aurait dû bloquer l’action n’apparaît jamais sur le formulaire | Rien — absence totale, donc invisible | Exécution alors même que « the condition was not met » |
| Intention | Le modèle traite une demande légèrement différente de celle formulée | Un résultat cohérent, plausible, fluide | La question « why did the model do that? » posée trop tard, après coup |
Le document, dans son analyse technique, le formule sans détour : « a looked-up value and an invented value look identical, so reading the form tells you nothing, and a missing condition never appears on the form at all. » Autrement dit, deux des trois pannes sont structurellement invisibles à la lecture. Seule la troisième, l’erreur d’intention, laisse une trace repérable — encore faut-il la chercher activement, et non se contenter de parcourir des yeux une page qui semble en ordre.
Réécrire le brouillon, pas seulement le relire
Voici l’endroit précis où j’attends l’objection, et où je veux la formuler moi-même avant qu’on me la fasse. On me dira : il suffit de mieux prompter, d’ajouter des consignes plus strictes, de répéter « vérifie tout » en lettres capitales dans le system prompt. Cette hypothèse s’effondre au premier paragraphe technique du document, qui note : « if it cannot recognize that it does not know something, it does not ask, and if it fills an empty slot itself, there is nothing left to ask about. » Le problème n’est pas le nombre d’instructions. Il est la capacité du modèle à reconnaître, en amont, qu’une case donnée relève de l’incertitude plutôt que du fait établi. Aucune formulation de prompt ne répare un déficit de reconnaissance.
Alors que faire ? Le document propose un déplacement net, presque une inversion de posture : « So what needs to be taken back is not the signature. It is the drafting. » Ce n’est pas la validation finale qu’il faut renforcer — elle arrive de toute façon trop tard, sur un objet déjà lissé. C’est la rédaction elle-même qu’il faut reprendre en main.
Une liste externe plutôt qu’un réflexe interne
La proposition concrète, selon le document de Jang-woo-AnnaSoft, consiste à « treat what happens before execution not as validation, but as a place that asks questions using an external list ». Autrement dit : ne pas compter sur le jugement spontané du modèle pour détecter ses propres angles morts, mais lui opposer une checklist extérieure, indépendante de sa génération, qui force explicitement la vérification de chaque valeur, chaque condition, chaque reformulation d’intention avant l’exécution. Le modèle cesse d’être seul juge de ce qui mérite d’être questionné.
La façade propre qui désarme la vigilance
Il y a une dimension presque perverse dans ce mécanisme, et je pèse le mot. « Worse, the form looks clean. If it looked ragged, you would notice immediately. » Un formulaire mal rempli, avec des champs vides ou des incohérences visibles, déclenche un réflexe de méfiance. Un formulaire propre l’éteint. Et c’est précisément la propreté qui pose problème, puisqu’elle ne dit rien de la provenance des données qu’elle affiche.
« Nothing reveals that you are approving a field you never actually checked », note le document. On signe une confiance, pas un fait. La question qui devrait se poser en amont — « Did you actually run it? » — ne surgit qu’après l’incident, quand l’action déjà exécutée révèle son inadéquation. À ce stade, la vérification a changé de nature : elle n’est plus préventive, elle est diagnostique. On ne corrige plus un brouillon, on répare une conséquence.
Ce que nous déléguons vraiment en déléguant à un modèle
Ce qui se joue ici dépasse la seule mécanique des formulaires d’action, comme le montre aussi notre décryptage des agents IA en production. Le document distingue deux gestes qu’on confond trop souvent sous le même mot de « contrôle » : « the first requires judgment; the second is simply a pass-through. » Vérifier exige un jugement — comparer une valeur à sa source, évaluer si une condition tient, interroger une intention. Approuver, en revanche, n’est qu’un passage : un clic, une signature, un geste qui ne produit aucune connaissance nouvelle sur la validité de ce qui est signé.
Nous avons, sans le décider collectivement, glissé du premier geste vers le second. Ce glissement n’est pas propre à l’intelligence artificielle ; toute automatisation tend à transformer le contrôle en ratification. Mais avec les modèles de langage, la vitesse et la fluidité du résultat rendent ce glissement particulièrement difficile à percevoir — parce que rien, dans l’expérience utilisateur, ne signale qu’on est passé d’un rôle à l’autre. Le sujet rejoint, sur un autre terrain, nos analyses sur la fiabilité des agents autonomes.
Un modèle qui saurait qu’il ne sait pas
Le document conclut sur une piste plutôt que sur une certitude, et je respecte cette prudence : « solve it by making the model more accurate », propose-t-il, en couplant cette exigence à une liste externe qui décide de ce qui doit être demandé. L’idée n’est pas de renoncer à l’automatisation des formulaires, comme l’illustrait déjà notre tribune sur l’agent IA face au logiciel d’entreprise. Elle est de cesser de demander au modèle de juger seul de ses propres lacunes, et de construire, autour de lui, une architecture qui les révèle systématiquement.
À retenir de ce document : – Trois causes, et seulement trois, structurent l’essentiel des échecs d’exécution recensés : valeur inventée, condition absente, intention mal reformulée. – Deux de ces trois pannes sont invisibles à la lecture d’un formulaire déjà rempli — seule une architecture de vérification externe au modèle peut les révéler avant l’exécution. – Le geste humain de contrôle est passé de cinq étapes distinctes à une seule signature, sans que la vigilance se soit redéployée ailleurs.
À suivre : la publication ne fixe pas de calendrier d’implémentation ; la question qui reste ouverte est celle du moment où les outils d’orchestration d’agents intégreront, par défaut, une liste de vérification externe au modèle plutôt qu’un simple champ de confirmation.
Nous parlions, au début de cette tribune, d’un formulaire qui a toujours la même allure, propre et aligné, quelle que soit la fiabilité de son contenu. C’est cette allure qu’il faut apprendre à ne plus croire. Non par défiance envers la machine — elle fait ce qu’on lui a appris à faire — mais parce que la confiance qu’on lui accorde mérite d’être méritée, case par case, et non signée d’un seul geste.
Cet article est une tribune et reflète l’opinion de son auteur.
