Imaginez un propriétaire d'entreprise qui demande à un agent IA de rédiger le jeu de tests de l'automatisation qui lit les factures de ses fournisseurs. La consigne tient en une phrase : « écris des tests qui vérifient notre lecteur de factures. » Les tests reviennent, l'automatisation en réussit presque tous, et le projet avance. Un billet de septembre 2026 du laboratoire de recherche de Meta suggère que ce taux de réussite en dit plus sur la phrase que sur l'automatisation. Quand l'agent du laboratoire a bâti des tests tout seul, ils sont sortis si faciles qu'un modèle puissant a obtenu 98 sur 100. Une phrase décrivant ce qu'il fallait mesurer n'a presque rien changé au résultat. Un cahier des charges détaillé, accompagné d'une liste de sources choisies à la main, l'a changé.
Ce qu'on a demandé à l'agent de bâtir.
Un banc d'essai (benchmark en anglais) est un jeu de tests pour l'IA : une liste fixe de tâches, le matériel qui accompagne chacune, une bonne réponse connue et un correcteur. Les auteurs ont demandé à un agent de recherche IA d'en bâtir un de bout en bout et de continuer à l'améliorer. À chaque tour, l'agent rédige les tâches, le correcteur et sa propre réponse de référence. Des modèles solveurs tentent ensuite les tâches, et leurs notes indiquent à l'agent le degré de difficulté du test. Un réviseur IA examine alors le test lui-même, et non les solveurs. L'agent lit le tout et révise.[1]
Trois bancs d'essai en sont sortis, tous destinés à tester d'autres agents de recherche. Graveyard Bench demande si un agent évite de proposer des pistes de recherche que la littérature a déjà enterrées. SilentTrain Bench lui demande de corriger un bogue de code d'entraînement qui dégrade les résultats sans produire d'erreur. Rebuttal Bench demande si la réponse d'un auteur à un évaluateur répond réellement à l'objection de celui-ci. Dans ce dispositif, une note plus basse signifie un banc d'essai plus difficile, et les auteurs tiennent pour meilleur un banc plus difficile qui réussit la révision.
L'expérience ne faisait varier qu'une chose : la quantité d'indications qu'une personne donnait à l'agent avant et pendant le travail.
| réglage | ce que la personne fournit |
|---|---|
| sans rétroaction | Rien. L'agent choisit le sujet, ce qu'il faut mesurer et comment. |
| sommaire | Une phrase d'intention, avant le début du travail. Elle fixe ce qu'il faut mesurer et laisse tout le comment à l'agent. |
| détaillé | Un cahier des charges détaillé de la tâche et une liste de documents sources sélectionnés, avant le début du travail. Il fixe ce qu'il faut mesurer et une bonne part du comment. |
| détaillé + en cours de route | La consigne détaillée, plus une personne qui lit les résultats d'un tour et écrit ce que l'agent doit faire ensuite. |
Ce que valait la consigne.
Sans aide, l'agent a bâti un test presque saturé : tous les solveurs ont obtenu 80 ou plus. Au tour que la boucle a retenu, les solveurs de la boucle ont obtenu 90 (Muse Spark, le modèle même qui a bâti le test) et 84 (Muse Glimmer) ; Nemotron, un modèle hors boucle dont l'agent n'a jamais vu les notes, a obtenu 80, et Claude Opus-5, lui aussi hors boucle, 98,0. Les trois premiers tours de cette exécution ont donné une note parfaite de 100,0 à Muse Spark.[1]
Une phrase d'intention n'a presque rien changé, mais ce constat s'appuie sur la référence sans rétroaction, qui porte sur un autre banc d'essai (nous y revenons plus bas). Sur Rebuttal Bench, la consigne sommaire a donné 84,4, 83,7 et 81 aux trois mêmes solveurs : Muse Spark a perdu 5,6 points (notre soustraction), Glimmer a bougé de 0,3 point, et Nemotron a obtenu un point de plus (un test un peu plus facile) que sans aucune consigne. Sur Graveyard Bench, la phrase a bel et bien aidé, jusqu'à 13,8 points, mais sur un test de dix tâches, cela représente environ une ou deux tâches de note (notre arithmétique : chaque tâche vaut un dixième de la moyenne).
Le changement est venu de la consigne détaillée. Sur Rebuttal Bench, le réglage détaillé a atteint 43,5, 51,2 et 39,1, et chacun des cinq critères de révision des auteurs a été réussi. Claude Opus-5, qui n'a jamais alimenté la boucle, est passé de 83,1 avec la consigne d'une phrase à 65,9 avec la consigne détaillée.[1]
Lire la comparaison de près.
Les auteurs résument en disant que la direction détaillée « halves the score of the solvers » (en anglais dans l'original ; réduit de moitié la note des solveurs). Deux choses en limitent la portée.
La référence sans rétroaction est un autre test. Laissé seul, l'agent a choisi son propre sujet, et les auteurs réutilisent cette unique exécution comme référence dans chaque comparaison. 90 contre 43,5 compare donc Rebuttal Bench à autre chose, et l'affirmation de la réduction de moitié en hérite. La comparaison qui tient est celle de la consigne d'une phrase contre la consigne détaillée, sur le même banc d'essai : sur Rebuttal Bench, Muse Spark passe de 84,4 à 43,5, Glimmer de 83,7 à 51,2, Nemotron de 81 à 39,1 et Opus-5 de 83,1 à 65,9 ; sur Graveyard Bench, Opus-5 passe de 90,7 à 84,4 et Nemotron de 75,4 à 52.[1] La baisse se confirme dans cette comparaison, bien que chaque réglage ne représente qu'une seule exécution. Parmi les chiffres que donne le texte, elle est la plus petite chez Claude Opus-5, le modèle hors boucle qui a obtenu les notes les plus élevées de bout en bout : 17,2 points sur Rebuttal et 6,3 sur Graveyard (notre soustraction).
La consigne détaillée regroupe deux choses. Le réglage détaillé donnait à l'agent un cahier des charges et une liste de sources sélectionnées. Le réglage d'une phrase n'en avait aucune. Le billet ne peut pas dire si c'est le cahier des charges ou les sources qui ont fait le travail. Pour qui donne ses consignes à un agent, la réponse pratique est de fournir les deux, puisque personne n'a montré qu'on pouvait se passer de l'un ou de l'autre.
Cela rejoint la prépublication de juillet 2026 dont nous avons rendu compte dans une note précédente : la qualité du contexte remis à un agent explique une bonne part de ce qu'on reproche au modèle. Ici, ce que l'agent a produit est un test, et une phrase d'intention ne donnait pas assez de contexte pour en faire un test difficile.
Quand la boucle plafonne, changez le comment.
L'exécution SilentTrain est le seul essai du billet où une personne oriente l'agent en cours de route, et elle disposait déjà du cahier des charges détaillé et des sources. Jusqu'au tour 5, la note de Muse Spark est restée au-dessus de 92 : l'agent continuait de réviser et le test restait facile. Les auteurs ont scindé l'exécution au tour 6. Une branche a poursuivi seule. L'autre a reçu trois instructions, toutes sur la façon de bâtir le test et aucune sur ce qu'il mesure : donner au solveur une tâche de plusieurs heures, bâtir l'environnement à partir des fichiers sources complets plutôt que d'extraits, et noter au moyen de tests de comportement contre le comportement fautif d'origine plutôt qu'avec un vérificateur à réponse fixe.[1]
| solveur | branche laissée seule | branche avec trois instructions sur le « comment » |
|---|---|---|
| Muse Spark | 88,1 | 64,2 |
| Muse Glimmer | 85,6 | 54,2 |
| Nemotron (hors boucle) | 83,8 | 48,8 |
Lisez cela avec prudence : il s'agit d'une seule scission, et une partie du gain peut venir de la demande d'une tâche de plusieurs heures, qui ajoute de la difficulté par la durée et la puissance de calcul plutôt que par une meilleure question. Ce qui se transpose, c'est le genre d'instruction. Quand une boucle d'agent que vous exploitez cesse de s'améliorer (un agent qui réécrit un prompt ou un jeu de règles tour après tour sans que rien ne bouge), la première question n'est pas « que doit-il mesurer ? » C'est la façon dont le travail est monté : l'agent voit-il un extrait là où il lui faut le fichier complet, et la vérification est-elle un corrigé fixe là où il faudrait tester un comportement ?
Trois garde-fous pour les vérifications rédigées par une IA.
La seconde moitié du billet intéresse quiconque laisse une IA rédiger un test, une grille ou une liste de vérification, puis s'y fie. Les auteurs posent le problème sans détour : « A low solver score on its own is weak evidence, because a broken task, an unsatisfiable requirement, a mis-specified grader, and fabricated grounding all produce the same number. » (en anglais dans l'original ; une faible note de solveur est à elle seule une preuve fragile, car une tâche défaillante, une exigence impossible à satisfaire, un correcteur mal spécifié et un ancrage fabriqué produisent tous le même nombre).[1] Un agent récompensé pour avoir rendu un test difficile a une échappatoire facile : rendre les tâches impossibles. Leur boucle s'en protège par des mesures que nous regroupons en trois contrôles et une quatrième précaution.
Contrôle A : la bonne réponse de la vérification doit d'abord réussir. Avant qu'un solveur ne s'exécute, le harnais d'évaluation fait passer la réponse de référence de l'agent par le vrai correcteur. Le tour n'est admis que si cette réponse obtient au moins 0,9 ; sinon il repart en réparation, jusqu'à dix essais.[1] C'est le garde-fou le moins coûteux de la boucle, et il ferme l'issue du test rendu impossible. Il correspond aussi, pour la rédaction de tests, au test à réponse connue de notre note sur les réviseurs IA, qui portait sur un billet du même laboratoire : avant qu'un juge ou un test évalue quoi que ce soit, vérifiez-le sur un cas dont vous connaissez déjà la réponse.
Contrôle B : autre chose que la note examine la vérification. Un réviseur lit le test lui-même selon cinq critères (validité de construit, exactitude, faisabilité, utilité et verdict global), et un tour qui échoue à un seul d'entre eux ne peut devenir la base du suivant. Le billet nomme trois défauts que la note ne peut pas voir : des réponses qui fuient dans des fichiers que le solveur peut lire, un sujet trop superficiel ou trop bien mémorisé pour départager les bons solveurs des faibles, et des documents sources que l'agent dit utiliser mais qu'il ne place jamais dans le test. Un corrigé qui a fuité ressemble exactement à un test facile, et des sources manquantes s'accommodent de n'importe quelle note.
| ce qui s'est passé | ce que disait la note | ce que disait la révision |
|---|---|---|
| exécution autonome, tours 1–3 | 100,0 pour Muse Spark, aux trois tours | le tour 1 a échoué aux cinq critères et le tour 3 à deux ; le tour 4 a été le premier à réussir les cinq |
| consigne détaillée, Rebuttal Bench, tour 5 | 47,4, la version la plus difficile jusque-là | a échoué à la faisabilité, donc ne pouvait pas servir de base au tour 6 ; la boucle est retournée au tour 3 et a atteint 43,5 au tour 8, les cinq critères réussis |
Choisir à partir de la seule note, soulignent les auteurs, « would have kept iterations the verifier rejects » (en anglais dans l'original ; aurait conservé des itérations que le vérificateur rejette).[1]
Contrôle C : chaque révision repart de la meilleure version acceptée. Le parent de chaque tour est le tour à la plus basse note ayant réussi la révision jusqu'ici, et non le plus récent. Une révision que le réviseur rejette, ou qui rend le test plus facile, ne devient pas le point de départ du suivant. C'est la même discipline que de garder une version éprouvée d'un prompt et de ne la remplacer que lorsqu'un candidat la bat aux vérifications.
La quatrième précaution : un solveur qui n'alimente jamais la boucle. Nemotron s'est exécuté après chaque tour et Claude Opus-5 au tour retenu, et aucun des deux résultats n'est revenu à l'agent. Le but déclaré des auteurs est de déceler un test qui n'est difficile que pour les modèles contre lesquels il a été réglé. Les notes de Nemotron ont aussi chuté avec la consigne détaillée (de 81 à 39,1 sur Rebuttal Bench, de 75,4 à 52 sur Graveyard), si bien que la difficulté n'était pas réglée seulement pour les solveurs de la boucle.
Une mise en garde que le billet ne formule pas lui-même : le réviseur derrière le contrôle B est le modèle même qui a bâti le test. Muse-Spark-1.1 propose, résout, note les réponses et applique les cinq critères de révision, de sorte que chaque « a réussi les cinq » est le modèle qui approuve son propre travail. Les solveurs hors boucle vérifient la difficulté, pas la validité, et aucun audit humain des tests acceptés n'est rapporté. L'autoévaluation est un point faible connu, et dans votre propre boucle, le réviseur du contrôle B devrait être un autre modèle ou une personne.
Rédiger les consignes de votre propre agent.
Acceleratech ne bâtit pas de bancs d'essai pour les modèles de pointe. De petites entreprises confient bel et bien à des agents des tâches où l'agent rédige son propre étalon : des cas de test pour une automatisation, une liste de vérification pour revoir des données de factures extraites, une grille pour noter des brouillons de réponses aux clients. Voici comment nous appliquerions le billet à ce genre de travail. Les étapes sont notre lecture, non les conseils des auteurs.
- Rédigez le cahier des charges, pas la phrase.
« Écris des tests pour notre lecteur de factures » est la consigne d'une phrase. Un cahier des charges dit à quoi servent les tests, quels cas comptent (notes de crédit, factures de deux pages, un fournisseur qui met les taxes TPS et TVQ sur des lignes distinctes), ce que contient un résultat correct champ par champ, ce qui donne droit à une note partielle et ce que les tests ne doivent pas faire. C'est là que va le temps de la personne, et non dans une révision à la fin.
→ l'agent sait quoi mesurer et une bonne part du comment - Remettez-lui les sources.
Donnez-lui une sélection de documents réels : vingt vraies factures avec leurs bonnes saisies, et les trois qui ont fait planter la dernière version. Pas « trouve des exemples ». Le billet ne peut pas départager le cahier des charges des sources : fournissez les deux. Retirez d'abord les renseignements personnels et ceux des clients, ou faites le travail là où les données ont le droit d'aller.
→ des tests fondés sur vos cas, pas des tests génériques - Faites d'abord réussir sa propre bonne réponse.
Avant qu'un test ou une grille rédigés par un agent note quoi que ce soit, faites-les passer sur une réponse dont vous savez qu'elle est bonne : les saisies correctes de ces vingt factures. Si la réponse connue échoue, le test est défaillant. Corrigez le test avant de toucher à l'automatisation. Faites ensuite passer une réponse que vous savez fausse (une facture au total interverti). Si le test la laisse passer, il est trop facile. Cette seconde vérification est de nous, pas du billet.
→ contrôle A : une vérification qui fait échouer une bonne réponse ne sert jamais à noter - Faites réviser la vérification par autre chose que sa note.
Posez quatre questions au test lui-même : teste-t-il ce qu'il dit tester, une bonne réponse peut-elle le réussir, utilise-t-il les sources qu'il prétend utiliser, et la réponse est-elle visible quelque part où le système testé peut la lire ? Faites appel à un autre modèle ou à une personne, pas à l'agent qui l'a rédigé.
→ contrôle B : un faible taux de réussite met plus probablement en cause l'automatisation que le test - Gardez la meilleure version acceptée, et changez le comment quand la boucle plafonne.
Quand l'agent révise le test, gardez comme base la dernière version qui a réussi la révision, jusqu'à ce qu'une nouvelle la réussisse et fasse mieux. Si les révisions cessent d'aider, regardez le montage avant l'objectif : fichiers complets plutôt qu'extraits, vérifications de comportement plutôt qu'un corrigé fixe.
→ contrôle C : aucun recul, et une sortie de plateau
La suite d'évaluation en six lignes que nous livrons avec nos agents est rédigée par une personne. Ces étapes visent le cas où un agent rédige les vérifications.
Ce que cette note ne prétend pas.
Un seul billet de blogue, de petites exécutions. Dix tâches par banc d'essai, dix tours, une tentative par solveur, par tâche et par tour, une exécution par réglage, aucune variance, et une seule scission pour l'exécution qui plafonnait. Un écart de quelques points sur dix tâches peut n'être qu'une seule tâche. Les courbes du billet sont des images que nous n'avons pas pu lire, et nous n'avons donc utilisé que les chiffres donnés dans son texte, son tableau et ses légendes.
L'affirmation vedette compare des choses différentes. La réduction de moitié annoncée se mesure contre un banc d'essai que l'agent a choisi lui-même. Seule la comparaison entre la consigne d'une phrase et la consigne détaillée porte sur un même banc d'essai, et elle regroupe le cahier des charges et les sources.
Un modèle révise son propre travail. Le même modèle bâtit les tests, les résout, note les réponses et applique chaque critère de révision. « A réussi les cinq » est le jugement de ce modèle lui-même, sans audit par une personne.
Plus difficile ne veut pas dire meilleur. Le billet note un banc d'essai selon une faible note de solveur plus une révision réussie. Pour vos propres tests, un jeu que votre automatisation rate plus souvent n'est pas automatiquement un meilleur jeu ; un bon test échoue quand l'automatisation a tort et réussit quand elle a raison, ce qui explique que le contrôle A compte plus que la difficulté.
Les auteurs s'attendent à ce que le constat change. « We note that as models get more powerful, we expect these trends to change. » (en anglais dans l'original ; nous notons qu'à mesure que les modèles gagnent en puissance, nous nous attendons à ce que ces tendances changent).[1] Ils présentent la méthode comme un moyen de suivre cette évolution, et non comme un résultat figé. Leur conclusion sur le plan humain est la phrase à retenir : décider quels problèmes sont pertinents et méritent d'être rendus difficiles « is a judgment we do not yet know how to delegate » (en anglais dans l'original ; est un jugement que nous ne savons pas encore déléguer).
Si un agent rédige des tests, des listes de vérification ou des grilles dans l'un de vos flux de travail et que vous voulez savoir ce que vaut son taux de réussite, décrivez-nous le flux de travail (ni identifiants ni données de clients) par le formulaire de contact. Nous vous répondrons par écrit, gratuitement, en vous indiquant la consigne et les trois contrôles que nous y ajouterions. Bâtir des flux de travail d'agents dont les vérifications sont dignes de confiance fait partie de nos services d'automatisation de flux de travail.