« Rends-le parfait » n'est pas une consigne
Demander à un agent de code un résultat « parfait » produit un résultat que l'agent juge parfait. Ce n'est pas la même chose.
Le 25 septembre, j'ai lancé une boucle sur un jeu idle personnel. La consigne tenait en une phrase : atteindre le niveau d'Anti-Idle, un jeu Flash de référence du genre. Des sous-agents construisaient, un critique comparait, la boucle tournait. Trente-neuf heures plus tard, le juge avait préféré notre version dans 61 manches sur 64. Les notes du critique, elles, n'avaient presque pas bougé : autour de 6,5 sur 10 du premier au dernier tour, et zéro pièce validée sur 34.
Le problème ne venait pas des agents. Anti-Idle ne tournait pas dans le bac à sable. Le critique comparait notre jeu à une description écrite de mémoire. Il ne pouvait pas perdre contre un souvenir.
De cet échec est sortie la méthode que j'appelle la gauntlet loop. Le principe tient en une règle : la qualité ne vient que d'une comparaison avec quelque chose de réel. Tout le reste est de l'échafaudage autour de cette comparaison.
La boucle en une image
barre réelle (capturée une fois, épinglée)
|
pièce --> constructeur --> gates chiffrés --> capture de la nôtre
^ |
| paire à l'aveugle, ordre A/B
| paire à l'aveugle, ordre B/A
| |
| critique 1 (A/B) critique 2 (B/A)
| |
+---- plus gros écart <---- perdu gagné ----> critique de confirmation
Le travail est découpé en pièces assez petites pour être jugées seules : un onglet de jeu, un écran, un point d'architecture. Pour chaque pièce, un constructeur travaille. Puis deux critiques au Une session d'agent qui démarre sans l'historique du constructeur : elle ne voit que les artefacts produits, jamais le résumé de celui qui les a faits examinent le résultat réel, jamais le résumé du constructeur.
Chaque critique voit deux artefacts, A et B, étiquettes retirées. L'un est le nôtre, l'autre est la référence. Il répond à des questions fixes par A ou B, puis nomme le plus gros écart. La pièce n'est gagnée que si la nôtre est choisie dans les deux ordres. Sinon, l'écart repart au constructeur, avec les deux écarts précédents pour qu'il ne tourne pas en rond.
Une pièce gagnée passe encore devant un critique de confirmation. Une pièce qui perd encore après six tours est mise de côté pour moi. Les autres continuent. La boucle ne s'arrête pas après N tours : elle s'arrête quand tout est gagné ou quand je l'arrête.
La barre : nommée, récupérable, comparable
La barre est la référence contre laquelle on se bat. Elle doit passer trois tests.
| Test | Ce qui marche | Ce qui échoue |
|---|---|---|
| Nommée | La page tarifs de Stripe | « Les meilleurs sites SaaS » |
| Récupérable | La page en ligne, le binaire épinglé, le dépôt cloné | Une description, un souvenir |
| Comparable | Deux captures côte à côte, mêmes conditions | Un A/B qu'on n'arrive pas à se figurer |
Au second essai sur le jeu, la barre est devenue concrète. Le vrai fichier d'Anti-Idle, épinglé par son empreinte MD5, tournait dans Émulateur Flash open source écrit en Rust, utilisable dans un navigateur headless. Melvor Idle, en ligne, servait de barre de mise en page à trois tailles d'écran : 390x844, 844x390 et 1440x900. S'y ajoutaient des seuils chiffrés : aucun texte sous 12 px sur téléphone, aucune cible tactile sous 44 px.
Une capture vérifiée vaut mieux qu'une capture fraîche. Les premières montraient des menus, des écrans de chargement, le mauvais onglet. Un agent dédié vérifie désormais chaque capture de la barre avant le moindre jugement.
Le juge est le maillon faible
Une boucle de ce type ne vaut que ce que vaut son juge. Or un LLM qui juge a des biais connus et mesurés.
Biais de position. Dans l'étude fondatrice de Zheng et al. (2023), on présente la même paire deux fois en inversant l'ordre. GPT-4 ne garde le même verdict que dans 65 % des cas. Claude-v1 tombe à 23,8 %, et choisit la première position 75 % du temps. Wang et al. montrent qu'en réordonnant simplement les réponses, Vicuna-13B bat ChatGPT sur 66 questions sur 80.
Biais de longueur. Toujours chez Zheng, une attaque qui gonfle une réponse avec des listes répétitives trompe Claude-v1 et GPT-3.5 dans 91,3 % des cas.
Préférence pour soi. Panickssery et al. (2024) montrent que GPT-4 reconnaît ses propres textes avec 73,5 % de précision, et que la préférence pour ses propres productions suit cette capacité de reconnaissance. Un constructeur qui juge son propre travail part donc avec un avantage.
Les notes sur 10 dérivent. C'est ce que j'ai observé au premier run : des notes collées entre 6 et 7,5, qui ne disent rien. Un choix binaire A ou B, question par question, est plus difficile à esquiver.
Les parades viennent de la même littérature. On présente la paire dans les deux ordres et on exige l'accord. On utilise plusieurs juges : Verga et al. (2024) montrent qu'un jury de trois petits modèles atteint un meilleur accord avec les humains que GPT-4 seul (kappa de Cohen 0,763 contre 0,627 sur un des jeux de données), pour un coût 7 à 8 fois moindre. Anthropic, dans Demystifying evals for AI agents, recommande des graders en code chaque fois que possible, un juge isolé par dimension, et une calibration contre des experts humains.
Le même article donne un chiffre qui devrait calmer tout le monde : Opus 4.5 obtenait 42 % sur CORE-Bench jusqu'à ce que des bugs de notation soient corrigés. Score réel : 95 %. Un juge défaillant ne se contente pas de bruiter le résultat. Il le retourne.
Pourquoi un critique séparé
L'auto-critique a eu ses heures de gloire. Self-Refine annonçait environ 20 % de gain moyen. Reflexion atteignait 91 % au premier essai sur HumanEval, contre 80 % pour GPT-4.
Mais Huang et al. ont montré que, sans retour externe, les modèles peinent à corriger leur raisonnement, et le dégradent parfois. La revue critique de Kamoi et al. conclut que l'auto-correction fonctionne surtout avec un retour externe fiable. Anthropic décrit le motif évaluateur-optimiseur : un modèle génère, un autre évalue, en boucle. La condition posée est claire : il faut des critères d'évaluation clairs.
La gauntlet loop pousse cette condition jusqu'au bout. Le retour externe n'est pas un autre avis du même modèle : c'est la référence réelle, posée à côté.
Il reste un risque sérieux. Un constructeur optimisé contre un juge apprend à plaire au juge. METR a observé o3 tricher dans 30,4 % des runs RE-Bench : patch de l'évaluateur, minuteur réécrit. Sur le jeu, les constructeurs ont répondu à « pas assez profond » en ajoutant des sous-systèmes, et à « pas assez vivant » en ajoutant du bruit visuel. D'où des gates en code : nombre de tailles de police plafonné, pas d'animation décorative au-dessus du niveau initial. Une métrique absente fait échouer le gate, sans exception. Lors d'un premier tour, une « victoire » venait justement d'une mesure manquante.
Le round 0 : calibrer avant de construire
Avant le premier constructeur, la boucle juge l'état actuel contre la barre. Si la nôtre gagne déjà la plupart des pièces, ce n'est pas une bonne nouvelle. C'est le critique qui est trop mou.
Sur le jeu, le round 0 a jugé 19 pièces en 104 comparaisons. Notre version en gagnait 65. La profondeur gagnait 15 fois sur 15. Le ressenti, 12 fois sur 17. Personne ne croyait sérieusement que le jeu battait déjà Anti-Idle sur la profondeur. Les questions ont été resserrées.
Au round 1, après le travail des constructeurs : ressenti 5 sur 16, profondeur 12 sur 14, bureau 4 sur 17. Le motif devenait lisible. Sur grand écran, notre version perdait sur 13 pièces sur 18 : des colonnes denses de petits libellés face à la mise en page aérée de Melvor. Les écarts nommés étaient enfin exploitables : « au moins six appels à l'action simultanés font concurrence à l'orbe ; le joueur ne peut pas les hiérarchiser ». Ou encore : « aucun nombre ne jaillit de l'orbe au moment du clic, la récompense est faible ».
Même quand la nôtre gagnait, les critiques nommaient de vrais défauts. Sur presque chaque pièce, la barre d'onglets du téléphone coupait « Quests » en « Qu ». Un défaut que personne n'avait vu en développant.
Quand la barre se tait
Le 9 octobre, j'ai appliqué la boucle à un tout autre objet : la conception haute disponibilité d'une passerelle d'API, point par point. Barre : la documentation HA officielle de Kong et de Gravitee, réduite à des fiches neutres pour le jugement à l'aveugle.
Le juge a choisi notre conception à chaque question, à chaque fois. Ce n'était pas du génie. Ces documentations sont muettes sur une grande partie du sujet. Face à « rotation des clés : la doc ne dit rien », une conception détaillée gagne par forfait.
Le vrai travail est venu du critique, un autre modèle d'un autre laboratoire, qui lisait la conception et le code. Au premier tour, il a trouvé ceci, alors que le juge venait de nous donner raison partout : lors de la première mise à jour progressive, un ancien réplica ne connaît qu'une seule clé, un nouveau émet un cookie signé avec la nouvelle ; la requête suivante tombe sur l'ancien et le cookie est refusé. Au tour suivant : une clé purgée à 24 h alors qu'un cookie émis à 23 h 50 reste valide jusqu'au lendemain.
Deux règles en sont sorties. On ne juge que là où la barre répond : si les deux fiches ne documentent pas au moins trois questions sur cinq, le juge est sauté. Et une conception n'est jamais « gagnée » sur un vote : chaque scénario d'échec du critique devient un test. Sur ce chantier, un seul point a gagné en deux tours ; les neuf autres ont atteint la limite de quatre tours et ont été acceptés avec un correctif. Mais la batterie make test-ha sur le cluster Raspberry Pi, elle, est passée au vert.
Le prix
Une gauntlet loop coûte cher, et il faut le dire avant de la lancer.
| Étape (jeu, 07/10/2026) | Agents | Tokens de sous-agents | Durée |
|---|---|---|---|
| Capture des barres | ~71 | ~9 M | |
| Round 0 (calibration) | 96 | 5,9 M | |
| Round 1 | 73 | 6,2 M | 62 min |
Les constructeurs représentaient environ 87 % de la dépense, surtout en relisant leur propre contexte. Ce n'est pas propre à ma boucle : Anthropic indique que son système de recherche multi-agents consomme environ 15 fois plus de tokens qu'une conversation, pour des résultats supérieurs de 90,2 % à un agent seul sur son évaluation interne.
Les règles d'économie sont simples. Le travail mécanique (construire les paires, mesurer les gates) passe par des scripts, pas par des agents. Les relais de commandes utilisent un petit modèle. Les critiques tournent en effort moyen. Le second critique ne juge que les paires que le premier a données à la nôtre. Un modèle puissant reste réservé aux constructeurs des pièces difficiles et à la confirmation.
Quand ne pas l'utiliser
Le run sur le jeu s'est arrêté après le round 1. Pas par manque de budget. Trois jours plus tard, j'ai écrit ceci :
« The game IS cool, but it needs cleaning and coherence, better layouts overall, and justified depth. »
La boucle répondait à « fais mieux qu'Anti-Idle ». Le vrai besoin était ailleurs : de la cohérence et une profondeur qui se justifie. Une course contre une référence ajoute ce que la référence a. Elle ne retire rien. Les verdicts du round 1 ont été recyclés en liste de défauts pour une passe de consolidation, avec un budget de tokens fixé à l'avance.
La gauntlet loop convient quand trois conditions sont réunies :
- une référence existe, se récupère et se compare côte à côte ;
- le but est réellement de l'égaler ou de la dépasser, et pas de faire autre chose ;
- une partie du résultat se mesure par un script des deux côtés : temps de chargement, taille des cibles, taux de tests verts.
Sans ces trois conditions, un bon brief et une revue humaine coûtent moins cher et disent plus vrai.
Écrire le prompt
La consigne finale tient en 200 mots environ. Les recommandations d'Anthropic pour les modèles récents vont dans le même sens : adoucir le langage agressif (« Use this tool when... » plutôt que « CRITICAL: You MUST... ») et expliquer la raison derrière chaque instruction. « Utterly perfect », répété trois fois dans ma première version, a disparu. À la place : « un critique indulgent fait perdre toute la boucle, donc les critiques sont durs et ne font aucun compliment ».
Le reste est volontairement absent : architecture, découpage, nombre de tours. Chaque instruction en trop retire une décision que l'agent prend mieux une fois qu'il a vu le travail.
Pour conclure
La gauntlet loop n'est pas une technique d'agents. C'est une technique de mesure appliquée à des agents. Le constructeur, les critiques, les tours et les tableaux de bord ne servent qu'à une chose : poser notre travail à côté d'une référence réelle et demander, à l'aveugle et dans les deux sens, lequel est meilleur.
Le reste se déduit des échecs. Une barre de mémoire valide tout. Un juge qui se tait valide tout. Un critique qui juge son propre travail valide tout. Une note sur 10 finit à 7.
Ce qui ne se déduit pas, c'est la question de départ. Une boucle bien réglée qui court après la mauvaise référence produit, très efficacement, la mauvaise chose.
Vous voulez faire travailler des agents IA sur un vrai chantier, avec des garde-fous mesurables ? Parlons-en.