Un agent IA doit-il demander confirmation avant d'écrire ?

Tout dépend de la capacité de l'humain à juger le résultat sur la seule foi de la demande. Sur un enregistrement métier bien délimité, oui : un dry run qui renvoie l'objet tel qu'il serait créé montre exactement ce que la personne valide, et cette étape est ce qui empêche une écriture hallucinée d'atterrir. Sur un document que quelqu'un façonne au fil de l'eau, non : demander confirmation à chaque retouche revient à exiger qu'on prédise un résultat visuel à partir de la description d'une modification, ce dont personne n'est capable. La personne valide alors sans lire et le garde-fou devient décoratif. Mieux vaut laisser l'agent écrire et investir dans la visibilité du résultat et la réversibilité de l'écriture.

De quels garde-fous un agent IA a-t-il besoin pour écrire en production ?

Trois, dans cet ordre. D'abord, chaque écriture renvoie ce qu'elle a modifié plutôt qu'un simple accusé de réception, pour que l'agent connaisse l'état courant sans relecture. Ensuite, l'agent peut observer le résultat réel, ce qui suppose une véritable image rendue dès qu'il s'agit de visuel, et non du balisage. Enfin, une annulation d'un seul pas, accessible comme un outil que l'agent peut invoquer, et non comme un simple bouton dans votre back-office. Le cadrage et l'authentification soutiennent ces trois points : ils déterminent si un appel est permis, et ne disent rien de la capacité de qui que ce soit à constater ce qui s'est passé.

Pourquoi les agents IA livrent-ils des résultats défectueux qu'ils auraient pu détecter eux-mêmes ?

Le plus souvent parce qu'ils ne les voient pas. Un agent qui modifie un objet visuel à travers des outils renvoyant du texte travaille sur une description de sa propre production : un défaut de mise en page, une police non appliquée, un fond de page erroné ou une ligne mal coupée lui restent invisibles jusqu'à ce qu'un humain regarde. Renvoyer une vraie capture d'écran que le modèle peut examiner referme cette boucle, et le même modèle se met à rattraper ses propres erreurs. Le défaut vient de la surface d'outils, pas du modèle.

Le dry run garde-t-il un intérêt ?

Oui, sur les opérations dont la portée reste invisible à la lecture des arguments. Dans notre éditeur de carte des vins, seuls les deux filtres d'appartenance en masse en proposent un, car un filtre parfaitement sensé sur le papier peut aussi bien vider une section qu'y déverser cent bouteilles, et le décompte reste alors le seul moyen de le savoir avant validation. Les modifications ordinaires n'en ont pas. Généraliser le dry run habitue l'opérateur à cliquer sans lire, et finit par supprimer le garde-fou précisément là où il comptait.

Garde-fous des agents IA : le retour plutôt que la validation

Un panneau d'édition relié par une boucle fermée à sa propre capture d'écran, à côté de deux boutons de validation et de rejet abandonnés

Un agent IA modifie la carte des vins de notre client à partir d'une simple phrase en français : « Sors les blancs de Loire dans leur propre section, et réduis la taille des titres de section. » Il appelle des outils, les modifications s'appliquent, la page change, et tout cela fonctionne.

Pendant un mois, il a aussi livré du CSS cassé avec une belle régularité. Personne ne comprenait pourquoi un modèle par ailleurs compétent commettait des fautes visuelles aussi grossières, ni pourquoi elles revenaient toujours sur le même genre de détail.

L'explication s'est révélée gênante et entièrement de notre fait : l'agent n'avait jamais vu la page. Son outil d'inspection lui renvoyait le HTML rendu sous forme de texte, si bien qu'une bordure en trop, un fond qui ne prenait pas, une police échouant silencieusement ou une ligne mal coupée lui échappaient toutes également. Il modifiait un objet visuel sans jamais y avoir accès, et en décrivait le résultat avec assurance.

Ce défaut résume tout ce qui suit. Il y sera question de ce dont un agent a réellement besoin après avoir écrit, et des raisons pour lesquelles le sas de validation avant application, que la plupart des équipes mettent en place d'abord, se révèle souvent inadapté.

Ce texte complète l'article sur l'autorisation, qui traite d'une tout autre question : l'autorisation détermine si un appel est permis, et ne dit rien à personne de ce que le modèle vient de faire.

Sommaire

Le bouton Valider que nous avons supprimé
Ce qui l'a remplacé : trois niveaux de retour
Là où le dry run garde sa place
Deux pièges rencontrés
Quelle approche pour quel système

Le bouton Valider que nous avons supprimé

La première conception était la plus évidente, et si nous l'avons retenue, c'est parce que c'est celle que tout le monde retient.

L'agent lisait l'instruction, puis proposait une liste d'opérations que l'application validait avant d'en afficher le différentiel, sous la forme d'un aperçu assorti de deux boutons : Valider et Rejeter. Rien ne touchait au document vivant avant un clic humain.

Sur le papier, c'est imparable. À l'usage, cela a échoué pour une raison qui n'apparaît qu'avec un vrai opérateur devant l'écran : la personne ne savait pas ce qu'elle validait.

Le différentiel affichait des lignes du genre set_section_filter(section: "Blancs", conditions: [region=Loire], exclusive: true). Valider cela honnêtement supposerait de prédire l'allure de la carte imprimée qui en sortira, exercice dont personne n'est capable. L'opérateur a donc fait ce que l'on fait toujours devant un garde-fou qu'on ne sait pas évaluer : il a cliqué sur Valider, regardé le résultat, et corrigé quand il le fallait.

Autrement dit une boucle de retour, précédée d'un clic superflu et trompeur, puisque ce clic laisse croire à une relecture qui n'a pas eu lieu.

Nous l'avons donc supprimé en juillet. L'agent mène désormais l'instruction jusqu'au bout en appliquant chaque modification directement, et la console affiche un compte rendu de ce qu'il a fait plutôt qu'une demande d'autorisation. Le commit qui a opéré ce changement précise que le filet de sécurité est l'annulation et le panneau de révisions, et non un aperçu avant application. Retirer l'étape de validation a rendu le système plus sûr, parce que l'attention de l'humain s'est déplacée d'une prédiction hors de sa portée vers un résultat qu'il pouvait constater.

Ce qui l'a remplacé : trois niveaux de retour

Chacun de ces trois éléments est né d'une panne précise survenue en son absence.

Ce dont un agent a besoin après avoir écrit

1
L'écriture annonce ce qu'elle a changé : Les setters renvoient la valeur affectée, pas un accusé de réception. Définir une palette renvoie la palette résolue. Auparavant, chaque écriture appelait une relecture de confirmation, que l'agent sautait souvent avant de raisonner sur une image périmée.
2
L'agent voit le résultat : L'outil d'inspection produit une véritable capture PNG du brouillon de travail, et le modèle la regarde. Du texte ne constitue pas un retour sur un objet visuel. C'est le correctif de l'aveuglement décrit plus haut, et le même modèle s'est aussitôt mis à rattraper ses propres défauts de mise en page.
3
L'annulation d'un pas : Annuler et rétablir existent comme outils appelables par l'agent, alors qu'ils dormaient depuis un an sous forme de boutons dans la console. Côté outils, son seul recours restait la remise à zéro complète : une solution si radicale qu'il s'abstenait de l'employer, et vivait donc avec l'erreur.

Le troisième mérite qu'on s'y arrête, car c'est le plus souvent oublié : une possibilité qu'offre votre back-office n'existe pas pour l'agent tant qu'elle ne lui est pas exposée. Nous disposions d'une pile de révisions parfaitement fonctionnelle alors que, de son côté, le choix se réduisait à vivre avec l'erreur ou à jeter tout le document. Il vivait avec l'erreur.

Exposer une annulation d'un seul pas est donc ce qui rend possible une boucle de relecture et d'autocorrection, car un agent capable de regarder son travail sans pouvoir en défaire une étape se contentera de rationaliser ce qu'il voit.

Réunis, ces trois niveaux transforment un agent qui tire des instructions dans le noir en un agent qui écrit, regarde et corrige. La consigne de faire exactement cela figure désormais dans la documentation des outils que le modèle lit : regarder avant de publier, comparer à la référence, corriger.

Là où le dry run garde sa place

Nous n'avons pas aboli l'aperçu. Nous l'avons restreint aux deux opérations dont la portée est réellement indéchiffrable à la lecture des arguments.

Ce sont les deux filtres d'appartenance en masse, ceux qui décident quelles bouteilles paraissent dans quelle section sur l'ensemble de la carte. Un filtre qui se lit très bien comme une phrase peut aussi bien vider une section que d'y faire entrer cent bouteilles, sans que rien dans l'appel ne permette de trancher. Ces deux-là, et eux seuls, acceptent donc un paramètre dryRun renvoyant le nombre de vins obtenu sans rien appliquer.

C'est la règle que nous appliquerions désormais partout : prévisualiser les opérations dont on ne peut pas déduire les conséquences des arguments, et pas les autres. Mettre une confirmation sur tout habitue l'opérateur à cliquer sans lire, ce qui vous coûte le garde-fou exactement là où il servait.

Deux pièges rencontrés

Une description d'outil ambiguë est un bug. L'outil d'inspection produisait le brouillon non publié, que sa description présentait comme « la page exacte qu'une publication servirait ». La formule était exacte, mais l'agent la lisait comme « identique à ce qui est en ligne en ce moment ». Dès que le brouillon s'écartait de la page publiée, il en concluait que celle-ci était cassée, et entreprenait de réparer une page qui allait très bien.

Le correctif a consisté à désigner explicitement le brouillon comme tel, et à ajouter un argument produisant la version publiée pour que la comparaison devienne délibérée. Vos descriptions d'outils sont du prompt : imprécises, elles engendrent un comportement faux et assuré qui ressemble à s'y méprendre à une défaillance du modèle.

Ne faites pas transiter d'octets par le modèle. Deux outils acceptaient un logo ou une police en base64, ce qui revenait à inviter le modèle à y intégrer un vrai fichier. Or un modèle ne sait pas produire de gros bloc base64 de façon fiable : l'opération dure des minutes et le résultat arrive corrompu, si bien que l'agent échouait sur un laconique « base64 invalide » au terme d'une longue attente.

Nous avons plafonné l'envoi en ligne à 24 Ko, ce qui suffit pour une petite icône, et fait pointer l'erreur de dépassement vers la page d'envoi de la console : une étape humaine où les octets ne transitent jamais par le modèle. Quand une tâche se prête mal à un flux de jetons, la bonne conception consiste à passer clairement la main à la surface qui sait la traiter.

Quelle approche pour quel système

Les deux schémas sont justes. Ils conviennent à des objets différents.

Le dry run avec validation convient aux enregistrements métier bien délimités, comme un contact, une affaire ou une ligne de facture : l'objet est petit, la personne le lit intégralement dans l'aperçu, et l'approbation constitue alors une vraie décision. Notre CRM fonctionne ainsi, son outil d'écriture renvoyant l'objet tel qu'il serait créé, et cette étape de validation est ce qui empêche une écriture hallucinée d'atterrir. Nous avons détaillé cette conception dans ce qui sépare une démonstration MCP d'un service qui tient en production.

Écrire, observer, annuler convient à un objet que l'on façonne au fil de nombreuses retouches, où la valeur d'une modification isolée ne se juge que dans l'ensemble. Une carte des vins, une mise en page, un document. Le sas de validation y réclame une prédiction là où l'annulation répond honnêtement à la même question.

Le test que nous employons désormais : l'opérateur peut-il dire, sur le seul aperçu, s'il veut cela ? Si oui, posez un garde-fou. Si non, le garde-fou relève du décor, et l'effort d'ingénierie appartient à la visibilité du résultat et à la réversibilité de la modification.

Tout cela vient de la carte des vins interactive que nous construisons et exploitons pour GoStan, une société bordelaise de gestion de cave dont les clients sont des restaurants et des bars à vin. Si cette boucle d'écriture a reçu autant d'attention, c'est que l'édition de la carte en langage naturel est la fonction dont leurs sommeliers se servent vraiment, tous les jours.

Si vous placez un agent IA devant un système qui écrit, cette question, celle de l'après-écriture, est la première que nous aurions envie d'examiner avec vous : ce que nous construisons, ou dites-nous ce que vous exploitez.

Nous avons supprimé le bouton Valider, et l'éditeur IA est devenu plus sûr

Une demande de confirmation n'est pas une boucle de retour. Elle demande à un humain de prédire le résultat d'une modification qu'il ne voit pas. Voici ce qui l'a remplacée, et le jour où nous avons compris que l'agent travaillait à l'aveugle depuis le début.