Des agents testés avant d'arriver en production
Une méthode pour qu'un agent mal réglé se trompe pendant les tests, et pas devant vos équipes.
La fiche, en trente secondes
- Date
- Mon rôle
- Conception de la méthode et de ses outils de test
- Pour qui
- Une équipe IA qui met des agents dans le travail des autres équipes
- Ce que fait la méthode
- Chaque jeu d'instructions d'agent est d'abord testé gratuitement sur des cas préparés, puis relu par quatre relecteurs automatiques, chacun sur un risque. Chaque version est numérotée, comme une mise en production informatique.
- Résultat
- 47 défauts trouvés en 4 minutes sur une seule version d'un agent, avant sa mise en service. Parmi eux, deux règles qu'aucune réponse ne pouvait respecter en même temps.
- Chez vous, dès mon arrivée
- Je l'apporte pour que chaque agent passe un contrôle avant d'être confié à une équipe.
Le problème
Un agent peut échouer à un test alors qu'il a raison
Le 4 septembre 2026, le premier réglage d'un de mes agents m'a demandé six passages dans Dust et quatre versions. Chaque passage se payait en crédits.
Un agent est un programme qui s'appuie sur une IA pour mener une tâche en plusieurs étapes. Celui-ci analysait un portefeuille de clients.
Dust est une plateforme où une entreprise crée ses propres agents d'IA. Chaque essai s'y paie en crédits, l'unité dans laquelle Dust facture l'usage.
L'agent suit des instructions, les consignes écrites qui lui disent quoi faire et comment. Un assistant d'IA les rédigeait, et il y a écrit une règle qui en contredisait une autre.
Aucune réponse ne pouvait donc respecter toutes les règles à la fois. L'agent a échoué au test alors qu'il avait raison.
J'en ai retenu qu'avant de corriger un agent, il faut vérifier que ses règles peuvent être respectées toutes en même temps.
Le jour même, j'ai décidé que toute version passerait d'abord sur un banc de test gratuit, une série d'essais qui contrôle le comportement de l'agent. Elle n'irait dans la plateforme payante que si elle en sortait propre.
Ce que j'ai décidé et fait
Un banc de test gratuit d'abord, puis quatre relecteurs isolés
Je lance ce banc de test avec Claude Code, l'outil qui fait travailler des agents IA sur un poste de travail. Chaque version y joue des cas préparés, puis quatre relecteurs automatiques la relisent.
- Jouer quatre sortes de cas préparésLes cas sont écrits à l'avance : un cas normal, un cas limite, un cas où il manque une donnée. Le quatrième est un piège, avec une instruction malveillante cachée dans les données.
- Quatre relecteurs isolés, un risque chacunAucun ne lit le travail des autres. Chacun cherche un seul risque : une donnée piégée qui détourne l'agent, des règles qui se contredisent, des règles trop collées aux exemples de test, ou une réponse mal formée.
- Un défaut vu deux fois pèse le plusQuand deux relecteurs trouvent le même défaut sans s'être lus, c'est le signal le plus fort.
- Fixer le critère d'arrêt avant de relireSans critère fixé d'avance, une relecture ne s'arrête jamais. Une version est acceptée quand il ne reste aucun défaut bloquant et que tous les cas de test sont réussis.
- Numéroter chaque versionJe numérote chaque version comme lors d'une mise en production informatique, le moment où un logiciel passe à l'usage réel. On sait toujours quelle version tourne.
Deux interdits
Les relecteurs lisent les instructions elles-mêmes, jamais un résumé.
Je ne corrige jamais un défaut en ajoutant un exemple tiré du test, car l'agent apprendrait le test par cœur. Je corrige la règle elle-même.
Le résultat
Les erreurs se trouvent avant la production
- défauts trouvés en 4 minutes, avant la mise en service
- 47
- relecteurs automatiques, chacun sur un risque
- 4
- pour tester sur les cas préparés
- 0€
Ce que ça change pour une équipe
Le 6 septembre 2026, les quatre relecteurs ont trouvé 47 défauts en quatre minutes sur une seule version de l'Architecte d'IA, un autre de mes agents. Parmi eux, deux règles qu'aucune réponse de l'agent ne pouvait respecter en même temps.
Ces défauts sont sortis avant toute mise en service. Une équipe reçoit un agent déjà mis à l'épreuve, et quand une version pose problème, on sait laquelle.
Ce que j'en retiens
Une IA bavarde et littérale fait exploser les règles
Un assistant d'IA rédige les instructions de mes agents. J'ai compris que c'est lui qui les fait déraper, parce qu'il est à la fois très bavard et très à cheval sur les mots.
Bavard, il écrit long. Littéral, il sent le besoin de verrouiller chaque mot.
C'est la combinaison des deux qui fait exploser les règles. Chaque correction ajoute des règles qui surveillent les règles d'avant et traitent chaque cas particulier.
La preuve en chiffres
La version suivante de l'Architecte d'IA avait grossi de 90 %. Les relecteurs y ont trouvé 68 défauts contre 47, soit 45 % de plus.
Plus de règles a donné plus de défauts. Ce sont les relecteurs qui ont mesuré cette dérive.
Ce que ça change
- Surveiller la longueur des instructionsDes instructions qui s'allongent sont un risque en soi, au même titre qu'un défaut.
- Surveiller la littéralitéUne règle qui verrouille chaque mot en appelle d'autres pour la surveiller. La littéralité est donc un risque, comme la longueur.
- Corriger en retirant plutôt qu'en ajoutantUne bonne correction enlève du texte au lieu d'en ajouter.
Ce problème reste ouvert, et il faudra le régler. En attendant, je le traite comme un risque connu, et j'appliquerai ces trois règles chez vous dès le premier agent.
Vous voulez cet outil chez vous ?
Racontez-moi où en sont vos équipes. Je vous dis comment je l'apporterais dès mon arrivée.