Une affirmation circule dans les cercles de codage IA : arrêtez de faire du prompting à vos agents de codage et commencez à concevoir des boucles qui font le prompting à votre place. Comme pour toute nouveauté, cette idée est souvent répétée et rarement expliquée. Voici la version pratique : ce qu'est une boucle d'agent, pourquoi elle compte et à quoi elle ressemble en production.
Ci-dessous, vous pouvez lire quelques-unes de mes réflexions (rédigées avec l'aide de Claude) issues des expériences, recherches et conversations que j'ai eues avec certains de nos étudiants, fondateurs techniques, ingénieurs IA et startups.
Vous trouverez peut-être aussi notre récent live intitulé « Agents de codage autonomes longue durée » comme un bon point de départ pour tout cela.
D'où vient cette affirmation
« Vous ne devriez plus faire de prompting à des agents de codage. Vous devriez concevoir des boucles qui font du prompting à vos agents. »Peter Steinberger (
@steipete), 7 juin 2026. 2,2 millions de vues.
Boris Cherny, le créateur de Claude Code, fait le même point de l'autre côté.
« Je ne fais plus de prompting à Claude. J'ai des boucles qui tournent. Ce sont elles qui font le prompting à Claude et déterminent quoi faire. Mon travail est d'écrire des boucles. »Boris Cherny (
@bcherny).
Le propos n'est pas que l'ingénierie des prompts est morte. Avec l'ingénierie des boucles, le travail monte d'un cran : on passe de l'écriture du code à l'écriture du système qui écrit le code. Les développeurs les plus avancés sur cette voie rapportent des mois où ils ont livré des centaines de PR sans ouvrir un IDE, chaque ligne étant écrite par l'agent.
Ce qu'est réellement une boucle
Une boucle est un petit programme que vous écrivez et qui fait quatre choses :
- fait le prompting de l'agent de codage pour vous,
- lit ce qu'il a produit,
- décide si c'est terminé,
- et si ce n'est pas le cas, refait un prompting avec l'erreur ou l'étape suivante.
Vous cessez d'être assis dans la boucle à taper des prompts ; vous écrivez la boucle, et le modèle devient une sous-routine qu'elle appelle.
La forme est toujours la même : fixer un objectif, agir, vérifier, renvoyer l'erreur, et répéter jusqu'à ce que la vérification réussisse ou que la boucle s'arrête d'elle-même.
« Boucle » signifie au moins cinq choses
Une grande partie du désaccord vient du fait que les gens utilisent un seul mot pour cinq idées différentes. Voici la progression, de la plus ancienne à la plus récente.
- ReAct (2022). Le schéma de recherche original : raisonner, agir, observer, répéter.
- AutoGPT (2023). Une boucle d'objectifs auto-promptée, célèbre pour ne pas savoir quand s'arrêter.
- Boucle ralph. Une réinitialisation délibérée du contexte entre les itérations pour que l'agent ne se noie pas dans son propre historique.
- /loop et /goal. Les conditions de cadence et d'achèvement sont intégrées à l'agent, qui conserve l'état entre les tours.
- Orchestration. Un auteur répartit le travail entre plusieurs agents qui lisent votre GitHub, Slack et chat, et décident quoi construire ensuite.
Les pièces que vous assemblez réellement
La progression explique ce que les gens veulent dire par boucle ; voici de quoi une boucle est construite. Les six mêmes pièces apparaissent à chaque fois, et la plupart sont désormais intégrées dans les outils de codage plutôt que dans des scripts personnalisés que vous maintenez vous-même.
- Un déclencheur. Quelque chose qui démarre la boucle sans que vous ayez à appuyer sur « go » : un planning, un webhook, un changement de fichier, un label apposé sur une PR. C'est ce qui distingue une vraie boucle d'une exécution unique que vous répétez à la main.
- L'isolation. Un checkout privé par agent, généralement un git worktree, afin que deux agents fonctionnant en même temps ne puissent pas écraser les fichiers l'un de l'autre. Dès que vous en exécutez plus d'un, cela cesse d'être optionnel.
- Le contexte écrit. Les conventions, les étapes de construction et les règles spécifiques au projet sont conservées là où l'agent les lit à chaque exécution. Si vous sautez cette étape, la boucle redérive votre projet à partir de zéro à chaque passage et devine les lacunes.
- L'accès à vos outils. Des connecteurs vers le suivi des tickets, l'IC, la base de données et le chat, afin que la boucle puisse ouvrir la PR, lier le ticket et publier le résultat au lieu d'imprimer un correctif et d'attendre que vous le preniez en charge.
- Un second agent vérifie. Un travailleur séparé qui évalue la production est tenu à l'écart de celui qui l'a produite, car un modèle qui révise son propre travail approuve presque tout.
- L'état sur le disque. Un fichier Markdown, un tableau ou une file d'attente : tout ce qui est en dehors de la conversation et qui enregistre ce qui est terminé et ce qui est à faire. Le modèle oublie entre les exécutions ; le fichier, non.
Assemblez ces six éléments, et vous obtenez un bon point de départ pour l'ingénierie des boucles. Avant, vous deviez tout construire à la main ; désormais, la plupart sont livrés comme des fonctionnalités intégrées, ce qui explique pourquoi ce modèle est passé d'une technique marginale à un usage courant.
Une boucle concrète, la nounou de PR
Un exemple concret que vous pouvez construire aujourd'hui :
- Déclencheur. Toutes les 15 minutes.
- Périmètre. Les PR ouvertes étiquetées agent-watch.
- Action. Si l'IC est rouge pour une raison déterministe, tenter un correctif. Si la branche principale a bougé, faire un rebase une fois.
- Budget. Une tentative de correctif par PR, cinq minutes, dix fichiers modifiés.
- Condition d'arrêt. IC verte, ou budget épuisé, puis s'arrêter et notifier un humain.
Vous revenez à des PR fusionnées au lieu d'un arriéré de builds cassés. La même forme couvre la plupart des tâches d'exploitation :
- Santé de l'IC. Toutes les 30 minutes, récupérer les exécutions en échec et les regrouper par signature, de sorte que dix PR rouges avec une seule cause racine deviennent une seule chose à examiner.
- Vérification de déploiement. Après un push, interroger vos endpoints, confirmer les 200 et le contenu attendu, et signaler les régressions avant les utilisateurs.
- Regroupement des retours. Toutes les 30 minutes, récupérer les commentaires de vos canaux, les regrouper par thèmes, et associer chaque groupe au fichier ou document qui le concerne.
Une boucle concrète avec Claude Code et /goal
La nounou est une boucle que vous câblez vous-même ; il est également utile d'en voir une qui est intégrée dans l'agent. Dans Claude Code, la plus petite boucle complète est /goal : vous lui donnez un état final vérifiable, et elle continue de prendre des tours jusqu'à ce que cet état soit vrai.
Voici un exemple d'utilisation de /goal comme commande en session dans Claude Code. Vous lancez la session, puis vous définissez l'objectif à l'intérieur :
1$ claude # lancement de Claude Code2$ /goal tests in test/auth pass # définition de l'objectif dans la session
C'est la même forme « agir, vérifier, répéter » vue précédemment, avec le vérificateur intégré.
À ce stade, il est clair qu'un bon /goal ressemble moins à un prompt qu'à un contrat. Les bons spécifient quatre choses : l'état final souhaité, la preuve que vous l'avez atteint, les contraintes que l'agent ne doit pas enfreindre pour y parvenir, et le budget de travail qu'il est autorisé à dépenser. Si l'un d'eux reste vague, le modèle comble le vide avec l'interprétation la plus facile : il s'arrête tôt, prend un raccourci, ou redéfinit la réussite pour que le transcript semble terminé alors que le système réel est cassé.
- Définissez la condition. Tapez /goal suivi d'un état final vérifiable, par exemple,/goal tests in test/auth pass. Le premier tour commence immédiatement.
- L'agent travaille un tour. Il édite, exécute les tests et affiche les résultats dans la session.
- Un évaluateur vérifie. Un modèle rapide lit le transcript et décide si la condition est remplie ou non, ce qui évite que l'agent évalue son propre travail.
- Boucle ou fin. Si non rempli, un autre tour avec des instructions ; si rempli, l'objectif s'efface et l'exécution s'arrête.
L'état est conservé entre les tours, donc l'agent ne s'arrête pas tôt et n'abandonne pas une contrainte en cours de route. Quelques contrôles assurent sa fiabilité :
- Rendez la vérification mesurable. Un résultat de test, un code de sortie, un nombre de fichiers ou une file d'attente vide. npm test exits 0 est un objectif ; « améliore-le » n'en est pas un.
- Limitez l'exécution. Ajoutez par exemple « ou arrête après 20 tours » pour qu'une boucle bloquée s'interrompe au lieu de brûler des tours.
- Associez-la au mode automatique pour que les tours s'exécutent sans surveillance, et utilisez /goal clear pour l'abandonner prématurément.
L'étape de l'évaluateur cache une subtilité utile : le vérificateur ne doit pas être le même modèle que le codeur. Une fois que la boucle a des rôles distincts (planificateur, exécuteur, évaluateur, réviseur visuel), chacun peut fonctionner sur un modèle différent, et choisir quel modèle remplit quel rôle devient une décision d'architecture plutôt qu'un pari unique sur un « meilleur » agent de codage. Certains modèles planifient mieux, d'autres exécutent à moindre coût, d'autres jugent une capture d'écran plus précisément, et un bon orchestrateur vous permet de les permuter par rôle au lieu d'attendre qu'un seul fournisseur gagne dans toutes les catégories.
Cela fonctionne bien pour les migrations d'API (déplacer chaque site d'appel jusqu'à ce que tout compile et que les tests passent), les refactorisations (diviser un fichier jusqu'à ce que chaque module soit dans le budget), les arriérés de tickets (traiter une file d'attente étiquetée jusqu'à ce qu'elle soit vide) et les boucles d'évaluation (ajuster un prompt jusqu'à ce que le score franchisse un seuil). /loop est l'équivalent pour les travaux sans ligne d'arrivée unique : au lieu d'une condition d'achèvement, il refait un prompting selon un planning, ce qui permet à une boucle comme la nounou de PR de continuer à fonctionner.
Exécuter plusieurs boucles sans surveillance
Une boucle /goal unique est un agent qui travaille vers une seule ligne d'arrivée. Exécuter plusieurs processus sans surveillance augmente les enjeux, car une boucle n'est aussi fiable que sa capacité à vérifier son propre travail. La configuration de Cherny pour faire fonctionner Opus de manière autonome pendant des heures se résume à cinq étapes :
- Approbation automatique des permissions pour que l'agent ne s'arrête pas pour demander à chaque appel d'outil.
- Utiliser des workflows dynamiques (insérer Ultracode dans le prompt) pour répartir le travail entre plusieurs agents au lieu d'un seul thread séquentiel.
- Utiliser /goal ou /loop pour le maintenir actif. /goal définit une condition d'achèvement, /loop refait un prompting selon un planning, et les deux conservent l'état, donc il ne s'arrête pas tôt.
- L'exécuter dans le cloud (application de bureau ou mobile) pour que la session survive lorsque vous fermez l'ordinateur portable.
- Lui donner un moyen de s'auto-vérifier de bout en bout. Claude dans Chrome pour le web, un MCP simulateur pour le mobile, et un serveur live pour le backend. C'est l'étape qui rend les quatre autres sûres.
La séquence complète :
1claude --permission-mode auto # 1 · pas de demandes d'approbation2ultracode orchestrer des sous-agents pour livrer la fonctionnalité # 2 · répartir3/goal all tests pass and the demo loads clean # 3 · continuer4→ cloud · app de bureau # 4 · fermer le portable5→ extension chrome · MCP sim · serveur live # 5 · s'auto-vérifier, puis s'arrêter
crabfleet : l'orchestration en tant que produit
L'orchestration est plus facile à visualiser avec un outil concret. crabfleet de Peter Steinberger, un projet OpenClaw présenté comme « le centre de contrôle pour les exécutions d'agents », est une boucle commercialisée comme un produit, et sa forme correspond à tout ce qui précède.
- Des tâches comme des cartes sur un tableau. Les tâches sont saisies sous forme de cartes construites à partir d'un prompt, d'un ticket GitHub ou d'une PR, puis passent par les étapes « à faire », « en cours », « révision humaine » et « terminé ». Ce tableau est la file d'attente de la boucle et son étape d'arrêt et de rapport, rendue visible.
- Des exécutions durables, pas du « fire-and-forget ». Chaque exécution est une tentative suivie avec des battements de cœur, donc elle continue quand vous regardez ailleurs et survit à la fermeture de l'ordinateur portable. Vous ne reprenez la main que lorsque l'environnement d'exécution indique qu'il prend en charge le transfert.
- Des agents qui engendrent des agents. Une exécution peut lancer des sessions enfants, envoyer des messages, lire des transcripts et mettre à jour son propre résumé depuis un bac à sable : mémoire sur disque et répartition en un seul endroit, un auteur et plusieurs agents.
Il fonctionne sur des bacs à sable cloud jetables avec des terminaux basés sur le navigateur, ce qui rend sûr le fait de s'éloigner d'une exécution sans surveillance. Le point n'est pas l'outil spécifique, mais le fait que la boucle s'est solidifiée en infrastructure : une file d'attente, une exécution durable, une répartition et une porte de révision humaine sont désormais des éléments que vous configurez plutôt que de les script manuellement à chaque fois.
Où va le coût maintenant
Pendant deux ans, la question du coût dans le codage IA était simple : quel modèle et combien de tokens. À l'intérieur d'une boucle, cet instinct vise la mauvaise couche. La dépense n'est plus un seul appel, mais le nombre de fois que la boucle tourne, donc une boucle qui réessaie six fois avant de converger coûte six fois plus qu'une boucle qui réussit au premier passage, sur le même modèle.
Cela change ce qui vaut la peine d'être optimisé :
- Les itérations sont la ligne budgétaire, pas les tokens. Un modèle moins cher qui boucle deux fois plus souvent n'est pas moins cher, donc suivez le coût par tâche terminée, pas le coût par appel.
- Un vérificateur faible est le bug le plus coûteux que vous puissiez livrer. Si la vérification qui décide de la « fin » est laxiste, la boucle s'arrête tôt sur un travail cassé ou continue sur un travail déjà bon, et les deux gaspillent des itérations entières. Ressercez cela avant toute autre chose.
- Échouer rapidement est un contrôle des coûts. Une boucle sans limite d'échecs consécutifs ne finit pas par réussir ; elle finit par vider le compte, donc la condition d'arrêt protège la facture autant que la base de code.
Avant, vous régliez le prompt ; maintenant, vous réglez la boucle, car c'est là que le coût s'accumule.
Quand ne pas faire de boucle
Les boucles sont rentables lorsqu'une tâche se répète et qu'une machine peut dire quand elle est terminée. En dehors de cela, une boucle ne fait qu'automatiser l'agitation. Évitez-la dans ces cas :
- Modifications ponctuelles. Si vous pouvez la terminer en un seul passage, une boucle est une surcharge pure.
- Travail non cadré ou exploratoire. « Trouver pourquoi les utilisateurs se désabonnent » n'a pas de condition de réussite, donc la boucle ne converge jamais.
- Tout ce qui n'a pas de vérification automatisée bon marché. Si le seul vérificateur est vos propres yeux, vous êtes toujours dans la boucle. Construisez d'abord la vérification, ou effectuez la tâche manuellement.
Ce qui peut mal tourner
Une boucle qui tourne pendant que vous dormez fait aussi des erreurs pendant que vous dormez, et les modes de défaillance sont prévisibles.
- La charge de vérification reste humaine. La boucle écrit plus vite que vous ne pouvez relire, donc si vous arrêtez de lire les diffs, vous n'avez pas supprimé le travail, vous l'avez seulement différé.
- Les lacunes de compréhension se creusent. Livrer du code que vous n'avez pas écrit, plus vite que vous ne pouvez l'assimiler, érode la connaissance de votre propre système, et cette dette se manifeste lors du prochain incident.
- Dérive silencieuse avec une vérification laxiste. Un vérificateur faible laisse passer un travail erroné mais « réussi » à chaque itération, donc la boucle semble productive tout en creusant un trou.
Rien de tout cela n'est un argument contre les boucles ; c'est pourquoi l'ingénieur qui conçoit la boucle compte plus, pas moins.
Comment construire la vôtre
- Choisissez une tâche répétable. Surveiller les PR, réparer l'IC, vérifier les déploiements : commencez par un travail de routine.
- Délimitez le périmètre avec précision. « Corriger la validation du webhook de facturation, toucher uniquement app/api/billing et lib/billing » vaut mieux que « corriger le bug ». Une boucle trop vague s'égare.
- Donnez-lui un budget et une condition d'arrêt. Nombre maximum de tentatives, temps d'exécution, fichiers, dépenses, échecs consécutifs. Une boucle qui tourne sans surveillance est aussi une boucle qui fait des erreurs sans surveillance.
- Ajoutez un vérificateur indépendant. Un sous-agent séparé évalue le travail, car l'agent qui a écrit le code est le pire juge pour savoir si c'est terminé.
- Exécutez-la selon une cadence. /loop pour un intervalle, cron pour un planning, des hooks à des points du cycle de vie, ou GitHub Actions pour qu'elle survive à la fermeture de l'ordinateur portable.
- Gardez la mémoire sur le disque. Le modèle oublie entre les exécutions, donc l'état réside dans un fichier Markdown ou un tableau, pas dans la fenêtre de contexte.
Le message à retenir : la boucle, et non le modèle, est désormais la partie coûteuse et sujette aux pannes. Construisez-la comme quelqu'un qui a l'intention de rester l'ingénieur responsable du résultat, pas seulement la personne qui lance l'exécution.
Si vous voyez des erreurs ou des points nécessitant des éclaircissements, n'hésitez pas à me contacter.
