Gauntlet Loop : ce prompt peut faire travailler une IA pendant des heures… et engloutir vos tokens

Un prompt court peut désormais déclencher des heures de travail autonome dans Codex ou Claude Code. L’agent construit, lance le projet, inspecte le résultat, demande à un autre agent de le critiquer, corrige le plus gros défaut et recommence. Cette méthode, popularisée sous le nom de Gauntlet Loop, produit parfois des résultats ahurissants. Elle peut aussi consommer énormément de temps, de tokens et d’argent si personne ne lui impose de limite.

Le point à retenir est simple : ce n’est pas un « prompt magique » qui fabrique un jeu ou un logiciel en une réponse. C’est un prompt qui met en marche une boucle de production et de contrôle. Et plus la barre fixée est haute, plus la boucle peut durer.

Qu’est-ce qu’un Gauntlet Loop ?

Le Gauntlet Loop est une méthode de travail multi-agent. Un agent principal reçoit un objectif et une référence de qualité. Il découpe ensuite le projet en éléments qui peuvent être construits et évalués séparément. Pour chaque élément, un agent produit le travail et un autre, placé dans un contexte neuf, le juge.

La boucle suit quatre mouvements :

1. Construire : produire une version réellement utilisable ou testable.
2. Mesurer : exécuter les tests, afficher la page, prendre des captures ou comparer des performances.
3. Critiquer : confier le résultat à un agent indépendant qui n’a pas participé à sa création.
4. Corriger : traiter le plus gros écart détecté, puis repasser dans la boucle.

Matt Shumer, qui a popularisé le terme avec le projet « Claude of Duty », insiste sur un point : le critique doit examiner l’objet réel — pixels, application en fonctionnement, tests, mesures — et non le résumé flatteur rédigé par l’agent constructeur.

Cette évolution prolonge la course aux agents capables de travailler longtemps. Meta vient par exemple de présenter Muse Code, un agent qui peut reprendre son travail après une interruption. Le Gauntlet Loop ajoute une méthode : il ne demande pas seulement de continuer, mais de continuer jusqu’à franchir une barre mesurable.

Pourquoi les résultats peuvent être spectaculaires

Un agent classique s’arrête souvent lorsque son résultat semble acceptable. Il peut annoncer que le site est « moderne », que le code est « propre » ou que le jeu est « immersif » sans avoir confronté ces affirmations à quoi que ce soit. Le Gauntlet Loop lui retire cette porte de sortie.

Dire « fais un beau site » ne fournit aucune mesure. Donner trois références, demander une comparaison à largeur mobile et desktop, puis exiger que le critique désigne le plus gros écart visuel crée un véritable mécanisme d’amélioration. Pour du code backend, la barre peut être une suite de tests, une latence maximale, un scénario de reprise après panne ou une implémentation de référence.

Les modèles récents sont également plus capables de tenir des tâches longues, d’utiliser des outils et de coordonner des sous-agents. C’est ce qui rend cette méthode crédible dans un environnement agentique comme Codex ou Claude Code. Ce n’est pas la même chose qu’un chat IA classique : l’agent doit pouvoir ouvrir les fichiers, lancer le code, utiliser un navigateur, lire les erreurs et modifier le projet.

Cette capacité explique aussi pourquoi le choix du modèle compte. Notre comparatif sur les prix de GPT‑5.6 Sol, Terra et Luna montre qu’un même volume de travail peut produire une facture très différente selon le niveau utilisé. Dans une boucle longue, chaque critique, nouvelle tentative et capture analysée s’additionne.

L’erreur la plus coûteuse : partir de rien

Il est tentant de donner une grande idée à l’agent et de le laisser travailler seul pendant toute une nuit. C’est précisément le cas où la boucle risque de s’éloigner de vos attentes. Un objectif ambitieux ne remplace pas une direction produit.

Le meilleur démarrage est souvent un MVP déjà visible : une première page, une maquette, un prototype, un gameplay rudimentaire, une liste de parcours critiques ou même un dépôt dont l’architecture est fixée. L’agent conserve une marge de décision sur la manière d’améliorer le résultat, mais il ne doit pas inventer à la fois le produit, la direction artistique, l’architecture et le critère de réussite.

La différence est énorme :

• sans point de départ, la boucle optimise une interprétation initiale peut-être fausse ;
• avec un MVP, elle améliore quelque chose que vous avez déjà validé ;
• avec une référence concrète, le critique peut mesurer l’écart ;
• avec des contraintes écrites, les agents ne « perfectionnent » pas le projet en ajoutant des fonctions inutiles.

On le voit déjà dans des outils qui transforment une intention en objet visuel. Avec Pascal Editor, une description peut devenir un premier plan 3D manipulable. Dans un Gauntlet Loop, ce premier résultat ne serait pas la fin : il deviendrait la matière que des agents spécialisés comparent, corrigent et testent.

La méthode la plus simple : faire transformer son idée en prompt Gauntlet Loop

Tout le monde ne sait pas définir immédiatement une bonne barre de qualité, découper un projet ou écrire les règles d’un critique indépendant. Le plus simple consiste donc à utiliser une première IA comme générateur de prompt Gauntlet Loop. Elle ne réalise pas encore le projet : elle vous aide à fabriquer l’instruction qui pilotera ensuite l’agent.

Le parcours tient en cinq étapes :

1. ouvrez une conversation avec une IA et collez le prompt générateur ci-dessous ;
2. l’IA vous demande votre objectif ou votre prompt de départ ;
3. vous décrivez librement ce que vous voulez construire et vous fournissez, si possible, votre MVP ou vos références ;
4. l’IA reformule l’objectif, propose deux ou trois barres de qualité réellement vérifiables et attend votre choix ;
5. elle renvoie un seul prompt Gauntlet Loop, prêt à coller dans une nouvelle session Codex ou Claude Code.

Le prompt générateur à coller en premier

Copiez ce texte dans une première conversation. Il oblige l’IA à dialoguer avec vous avant de produire le prompt final et l’empêche d’inventer silencieusement une barre de qualité.

Tu es un générateur de prompt Gauntlet Loop.

Ton rôle n’est pas de réaliser le projet. Tu dois transformer l’idée ou le prompt initial de l’utilisateur en UN prompt court, autonome et prêt à coller dans une nouvelle session d’agent comme Codex ou Claude Code.

Déroulement obligatoire :

1. Commence uniquement par demander :
« Quel projet, résultat ou prompt de départ veux-tu transformer en Gauntlet Loop ? Tu peux aussi joindre un MVP, un dépôt, une maquette, des captures ou des références. »

2. Lorsque l’utilisateur répond, reformule son objectif en une phrase pour vérifier que tu l’as compris.

3. Cherche ensuite la meilleure barre de qualité que l’agent pourra réellement inspecter : captures de référence, site existant, tests, métriques, temps de réponse, scénario utilisateur, livrable modèle ou autre preuve concrète.

4. Si l’utilisateur a fourni une référence exploitable, explique en une phrase pourquoi elle constitue une bonne barre. Sinon, propose exactement 2 ou 3 barres de qualité nommées et concrètes. Pour chacune, indique en une phrase ce que l’agent comparera ou mesurera. Arrête-toi et attends que l’utilisateur en choisisse une. Ne rédige pas encore le prompt final.

5. Après son choix, rédige UN seul prompt Gauntlet Loop dans un bloc de code, sans titre à l’intérieur, sans préambule et sans explication annexe.

Le prompt final doit :
- donner l’objectif et la barre choisie, sans imposer inutilement l’architecture ;
- utiliser le MVP ou le projet existant comme point de départ lorsqu’il existe ;
- demander à l’agent principal de découper le travail en éléments vérifiables ;
- séparer les agents constructeurs des agents critiques avec un contexte neuf ;
- obliger chaque critique à examiner le résultat réel et non le résumé du constructeur ;
- comparer chaque résultat à la barre choisie et corriger en priorité le plus grand écart utile ;
- prévoir une passe d’intégration pour détecter incohérences, régressions et problèmes de performance ;
- inclure des limites explicites de temps, de tokens ou de budget, de vagues et de gain minimal ;
- maintenir un journal court des tests, progrès, coûts et décisions ;
- s’arrêter dès qu’une limite est atteinte ou que le gain devient négligeable.

Après le bloc, ajoute uniquement sur une nouvelle ligne :
« Je peux aussi lancer ce prompt ici si cet environnement dispose des outils nécessaires. »

Si l’utilisateur répond qu’il veut le lancer ici, deviens l’agent principal et exécute exactement le prompt produit.

Exemple de conversation

Vous : « Je veux transformer mon SaaS existant en application plus rapide et plus claire sur mobile. Voici le dépôt et trois captures de concurrents. »

L’IA : elle reformule l’objectif puis peut proposer : A) comparaison visuelle avec les trois références sur cinq écrans clés ; B) parcours d’inscription chronométré et testé sur mobile ; C) combinaison de scores de performance, accessibilité et réussite du parcours. Elle attend votre choix.

Vous : « Je choisis C. Limite la boucle à six heures, huit vagues et un million de tokens. »

L’IA : elle renvoie alors un prompt autonome qui contient le projet, la barre C, les constructeurs, les critiques, les contrôles d’intégration et vos limites. Ce second prompt peut être lancé dans une nouvelle session agentique.

Cette séparation évite une confusion fréquente : l’IA qui rédige le prompt n’est pas encore celle qui doit travailler pendant des heures. Vous pouvez relire l’instruction, corriger la barre et réduire les limites avant d’engager une session coûteuse.

Un prompt Gauntlet Loop prêt à adapter directement

Le prompt ci-dessous conserve l’idée originale — objectif, barre de qualité, constructeurs et critiques séparés — mais ajoute les garde-fous absents de nombreux exemples viraux. Remplacez les éléments entre crochets avant de le lancer.

Tu dois améliorer ce projet jusqu’à atteindre l’objectif suivant :
[OBJECTIF PRÉCIS ET RÉSULTAT ATTENDU]

Point de départ obligatoire :
[CHEMIN DU MVP, DÉPÔT, MAQUETTE OU VERSION ACTUELLE]
Ne repars pas de zéro et ne remplace pas l’architecture sans démontrer qu’elle bloque l’objectif.

Barre de qualité vérifiable :
[TESTS, CAPTURES DE RÉFÉRENCE, MESURES, PARCOURS UTILISATEUR OU EXEMPLE]

Commence par inspecter le projet réel. Découpe ensuite le travail en éléments qui peuvent être améliorés et jugés séparément. Pour chaque élément important, utilise un agent constructeur et un agent critique distinct, avec un contexte neuf.

Chaque critique doit examiner le résultat réel : application lancée, captures, tests, mesures ou livrable final. Il ne doit pas noter un résumé produit par le constructeur. Il compare le résultat à la barre de qualité, désigne le plus grand écart encore utile et renvoie une correction prioritaire au constructeur.

Boucle : construire → exécuter → mesurer → critiquer → corriger. Après chaque vague, vérifie aussi la cohérence globale, les régressions, la performance et la maintenabilité.

Limites impératives :
- budget maximal : [NOMBRE DE TOKENS OU MONTANT] ;
- durée maximale : [DURÉE] ;
- nombre maximal de vagues : [NOMBRE] ;
- point de contrôle humain après : [NOMBRE] vagues ;
- arrêt si l’amélioration mesurée reste inférieure à [SEUIL] pendant deux vagues ;
- aucun ajout hors périmètre sans validation.

Maintiens un journal court : résultat de chaque test, modification retenue, coût ou tokens consommés, temps écoulé et prochain écart prioritaire. Arrête-toi dès qu’une limite est atteinte, même si la barre de qualité ne l’est pas.

Pourquoi ce prompt est volontairement moins « infini »

La version la plus radicale du Gauntlet Loop demande de continuer jusqu’à battre la référence ou jusqu’à ce que l’humain arrête manuellement la session. C’est efficace pour pousser un modèle, mais dangereux pour un usage quotidien. Une référence impossible à battre — un jeu AAA avec des centaines de développeurs, par exemple — ne produit jamais naturellement de condition de fin.

Il faut donc distinguer deux expériences :

• le défi de démonstration, où l’on accepte volontairement une longue exécution pour voir jusqu’où l’agent peut aller ;
• le projet rentable, où chaque nouvelle itération doit justifier son coût et réduire un écart utile.

Combien peut coûter un Gauntlet Loop ?

Il n’existe pas de prix universel. Le coût dépend du modèle, de l’abonnement, du nombre de sous-agents, de la quantité de contexte relue, des images analysées, des commandes exécutées et du nombre d’itérations. Une session incluse dans un forfait peut également atteindre une limite d’usage au lieu de produire une facture API directe.

Ce qui est certain, c’est que la consommation se multiplie vite. Si huit composants possèdent chacun un constructeur et un critique, une seule vague peut déjà déclencher seize travaux d’agent, auxquels s’ajoutent l’orchestration, les tests et l’analyse finale. Recommencer dix fois n’équivaut pas à « dix prompts » au sens habituel.

Les cinq limites que les démonstrations montrent rarement

1. Un mauvais critique industrialise une mauvaise direction

Si le critère est vague, l’agent critique produit une opinion de plus. La boucle devient plus longue sans devenir plus juste. Il faut des tests, des pixels, des performances ou une grille de décision que l’on peut vérifier.

2. Des sous-agents peuvent casser la cohérence globale

Chaque partie peut progresser séparément alors que l’ensemble se dégrade : composants dupliqués, styles différents, interfaces incompatibles ou baisse de performance. Une passe d’intégration est indispensable après chaque grande vague.

3. L’agent peut optimiser ce qui se mesure facilement

Un score Lighthouse, un nombre de tests ou une ressemblance visuelle ne représente jamais tout le produit. L’agent peut gagner sur le chiffre et perdre sur la simplicité, l’accessibilité ou l’utilité réelle.

4. Une barre prestigieuse n’est pas une preuve d’équivalence

Comparer un prototype à Call of Duty peut pousser la qualité visuelle. Cela ne transforme pas un jeu de navigateur en production AAA. Les équipes, les budgets, le contenu, le multijoueur, la sécurité et les années de finition ne disparaissent pas parce qu’un screenshot est convaincant.

5. Plus longtemps ne signifie pas toujours mieux

Une boucle peut finir par modifier des éléments déjà corrects, réintroduire des bugs ou ajouter de la complexité. Le bon arrêt n’est pas « quand l’IA ne trouve plus rien à faire », mais quand le gain attendu devient inférieur au coût et au risque.

Claude Code ou Codex : où lancer cette méthode ?

Le Gauntlet Loop n’est pas attaché à un modèle unique. Il exige surtout un environnement capable d’agir sur un projet, d’exécuter des outils, de vérifier le résultat et de séparer les rôles. Claude Code et Codex peuvent tous deux servir de cadre, selon les modèles, les outils et les limites disponibles sur votre compte.

Dans les deux cas, vérifiez avant le lancement :

• que le projet possède une commande de démarrage et des tests reproductibles ;
• que les agents savent produire des captures ou inspecter l’application ;
• que les références sont accessibles et légalement utilisables comme comparaison ;
• qu’un journal enregistre les décisions et la consommation ;
• qu’une condition d’arrêt technique existe réellement.

Notre verdict : une excellente méthode, un très mauvais pilote automatique

Le Gauntlet Loop est l’une des idées les plus utiles du moment pour obtenir davantage d’un agent de développement. Il remplace les encouragements vagues par une boucle où chaque version doit affronter un test ou une référence. C’est exactement ce qui peut transformer un prototype moyen en résultat impressionnant.

Mais il ne faut pas reproduire aveuglément les démonstrations virales. Donnez un démarrage solide, une barre observable, des critiques indépendants et beaucoup de marge de calcul si le projet le mérite. Donnez surtout un plafond de temps, de tokens et d’itérations. Sans cela, le Gauntlet Loop ne repousse pas seulement les limites de l’IA : il repousse aussi celles de votre budget.

Questions fréquentes sur le Gauntlet Loop

Le Gauntlet Loop fonctionne-t-il dans ChatGPT ou Claude.ai ?

Une conversation classique peut simuler une petite boucle, mais la méthode complète demande un agent capable de modifier des fichiers, d’exécuter le projet, d’utiliser des outils, d’inspecter le résultat et de coordonner des critiques séparés.

Faut-il laisser l’agent tourner toute la nuit ?

Non. Une longue durée peut être utile pour une démonstration encadrée, mais un projet réel doit posséder une limite de temps, un budget, un journal et des points de contrôle humains.

Le Gauntlet Loop peut-il servir ailleurs que pour créer un jeu ?

Oui. La méthode convient aux sites, tests logiciels, optimisations de performance, rapports, présentations ou designs, à condition de pouvoir examiner le livrable et mesurer son amélioration.

Pourquoi séparer l’agent constructeur de l’agent critique ?

Le constructeur connaît toutes ses décisions et tend à les justifier. Un critique neuf reçoit l’objectif, les règles, la référence et le résultat réel, sans hériter du récit du constructeur.

Sources principales : guide de Matt Shumer sur le Gauntlet Loop, présentation officielle de Claude Opus 5 et présentation officielle de GPT‑5.6.