À retenir
- Le but n’est pas de prompter l’agent plus fort. C’est de concevoir la boucle dans laquelle l’agent travaille.
- Une bonne boucle définit le contexte, les outils, les critères de réussite, la gestion des échecs, le budget et le moment où elle doit s’arrêter.
- Le loop engineering laisse le jugement à l’humain tout en permettant à l’agent de prendre en charge l’exécution répétée.
Si vous codez avec Claude ou Codex aujourd’hui, il existe un nouveau paradigme que vous allez adorer. Il réduit de moitié le nombre d’étapes nécessaires pour arriver au résultat final. Votre workflow actuel ressemble probablement à ça : vous écrivez un prompt. Vous donnez aux agents accès aux fichiers ; l’agent modifie les fichiers. Vous acceptez toutes les permissions. Vous lancez les tests. Quelque chose casse. Vous lui demandez de le réparer. Parfois ça fonctionne du premier coup, parfois vous devez recoller l’erreur ou prendre une capture d’écran. Il réessaie. Et après vingt minutes, vous réalisez que vous supervisez exactement le processus que vous vouliez justement déléguer et que c’est vous qui faites le travail stupide, pas la réflexion.
Mais si les agents sont déjà assez bons, pourquoi devez-vous continuer à répéter ce processus? Ce nouveau paradigme que j’ai mentionné, appelé loop engineering, est l’idée qui vous permet de cesser de les surveiller constamment. Plus besoin de les « micro-prompter ». Vous pouvez plutôt laisser l’agent travailler, ou boucler, avec lui-même.
Nous sommes passés du prompt engineering au context engineering, puis aux harnesses, et maintenant au loop engineering. Et honnêtement, ils parlent tous de la même chose : orienter le modèle du mieux possible, ce qui n’est possible que grâce au contexte ou au prompt que nous lui donnons. Ce nouveau terme vaut la peine d’être compris parce qu’il décrit un véritable changement dans la manière dont les développeurs utilisent les agents de code en 2026.
En passant, avant de continuer, vous voudrez peut-être regarder la suite de cet article. Je paie un excellent monteur pour créer de superbes visuels qui rendront le contenu dix fois meilleur pour vous ;) Regardez ici : https://youtu.be/NjXIIH9vcv0
Le terme loop engineering a explosé après que Peter Steinberger, le créateur d’OpenClaw, a écrit que vous ne devriez plus prompter les agents de code. Vous devriez concevoir des boucles qui promptent vos agents. Et ce n’était pas une opinion choc isolée. Boris Cherny, qui dirige Claude Code chez Anthropic, a dit la même chose : il ne prompte plus Claude. Selon ses propres mots, son « travail consiste à écrire des boucles ». Lorsque les personnes qui créent à la fois Codex et Claude Code arrivent à la même idée, ça vaut peut-être la peine de la prendre au sérieux. La réponse la plus incisive était essentiellement : « d’accord, mais à quoi est-ce que ça ressemble réellement en pratique? »
Parce que si une boucle signifie seulement exécuter le même prompt toutes les heures, nous avons déjà ça. Ça s’appelle une tâche cron. Et c’est plus vieux que plusieurs d’entre nous.
Avec le loop engineering, la différence est le décideur à l’intérieur de la boucle. Une tâche cron exécute un script fixe. Une boucle exécute un agent qui examine l’état actuel, choisit la prochaine action, l’effectue, vérifie le résultat et décide quoi faire ensuite. Continuer, réessayer, revenir en arrière ou arrêter. Ici, l’agent contrôle la boucle, et ça fonctionne parce que les LLMs sont maintenant suffisamment capables de comprendre de bons objectifs et de bons signaux de récompense.
Mais pour qu’une boucle puisse fonctionner, elle a besoin de deux choses avant tout le reste : un déclencheur et un objectif vérifiable.
Le déclencheur est ce qui démarre la boucle. Ça peut être l’ouverture d’une pull request, un run de CI qui échoue, un horaire quotidien, un message Slack ou vous qui tapez manuellement une commande ou envoyez le premier prompt. L’objectif vérifiable est ce qui indique à la boucle qu’elle peut s’arrêter. Il peut être déterministe, comme tous les tests réussissent et la CI est verte, ou plus souple, comme un modèle évaluateur qui vérifie si l’interface correspond aux spécifications. Mais il doit y avoir une vérification. Sinon, vous n’avez pas créé une boucle. Vous avez créé une fournaise à tokens très confiante.
Codex fait déjà ça automatiquement jusqu’à ce que la tâche demandée soit terminée, mais vous pouvez aussi mettre ça en place vous-même avec une boucle qui exploite ces nouveaux modèles, par exemple au moyen d’une automatisation dans Cursor.
Le prompt engineering optimise une seule interaction. Le loop engineering la transforme en un processus reproductible autour de nombreuses interactions. Le prompt devient alors un composant du système plus large.
J’aime cette façon de présenter les choses parce qu’elle correspond à ce que je ressens dernièrement avec les agents de code. Le prompt est rarement la partie difficile maintenant. Surtout depuis la fin de 2025. La partie difficile est tout ce qui l’entoure. Quel contexte l’agent devrait-il voir, quels outils peut-il utiliser, qu’est-ce qui compte comme terminé, qu’arrive-t-il lorsqu’il échoue et combien a-t-il le droit de coûter avant qu’on l’arrête? C’est pourquoi la plupart de mes conférences récentes portaient sur la compaction et la mémoire. Maintenant que les modèles sont beaucoup plus intelligents, mais aussi plus chers, nous devons contrôler ce à quoi ils ont accès pour réduire les coûts et la latence, améliorer les longues discussions et améliorer les résultats. Ça se fait en gérant le contexte intelligemment. Et finalement, nous avons un terme qui intègre ce processus au système et l’incorpore dans ces mêmes boucles pour les rendre viables.
Si vous vous demandez en quoi c’est différent de React ou des boucles d’agents comme la boucle Ralph, voici ce qui est nouveau. Les anciens systèmes laissaient le LLM s’exécuter de nouveau ; avec cette approche, la boucle devient une unité de travail.
Elle peut s’exécuter selon un horaire. Elle peut ouvrir des worktrees. Elle peut créer des sous-agents. Elle peut écrire un état dans un fichier ou sur un tableau Linear. Elle peut continuer à fonctionner lorsque vous fermez votre laptop. Ce qui signifie aussi qu’elle peut survivre sans vous. Elle devrait donc être capable de travailler sans vous, ce qui signifie ensuite qu’elle ne devrait pas avoir besoin que vous la promptiez chaque fois.
Dans un excellent article sur Twitter, Addy Osmani décompose une boucle en cinq parties, plus la mémoire, et je pense que c’est l’explication pratique la plus claire. Premièrement, les automatisations, pour que la boucle se réveille toute seule, ou que vous puissiez la démarrer si vous le voulez. Deuxièmement, les worktrees, pour que les agents en parallèle ne s’écrasent pas les uns les autres. Particulièrement lorsqu’ils codent. Je fais souvent ça avec Codex. Lorsque je veux faire partir une conversation dans deux directions complètement différentes, je la divise simplement en deux worktrees et je laisse les deux diverger. Troisièmement, les skills, pour que l’agent n’ait pas à deviner les règles de votre projet, ni même les règles que vous voulez lui donner sur vous, votre façon de travailler, etc., chaque fois que vous le lancez. Quatrièmement, les plugins ou connecteurs, pour que l’agent puisse utiliser des outils comme GitHub, Linear, Slack ou votre base de données. Cinquièmement, les sous-agents, pour que celui qui écrit le code ne soit pas le même que celui qui juge le code. Puis la mémoire, parce que le modèle oublie, mais pas le repo.
Je dois insister sur les skills parce que, même si elles existent depuis un certain temps, la grande majorité des gens que je vois ne les utilisent toujours pas assez. Une boucle sans skills réutilisables redécouvre votre projet à partir de zéro à chaque exécution. Elle brûle des tokens à réapprendre ce que vous savez déjà. Une boucle avec de bonnes skills commence à s’enrichir. La skill est l’endroit où vous écrivez la convention, les exemples, la commande de test et les choses que vous ne voulez jamais devoir répéter. Ce n’est qu’une grande liste de fichiers Markdown. Rendez-les aussi denses que possible. Une skill par tâche. Vous ne voulez pas qu’elles remplissent le contexte. Ensuite, demandez à Codex ou à n’importe quel agent de les organiser et de créer un index. Ainsi, votre agent de code aura simplement à utiliser cet index pour savoir quelle skill ouvrir et à quelles skills il a accès. Vous n’aurez donc plus jamais besoin de lui dire par prompt d’ouvrir les skills X et Y, seulement de consulter la liste des skills.
Alors, à quoi ressemble une boucle?
Une version simple pourrait s’exécuter chaque matin. Elle lit les échecs de CI de la veille, les issues ouvertes et les commits récents. Elle écrit un court fichier d’état avec ce qui semble valoir la peine d’être fait. Pour une issue, elle ouvre un worktree séparé et envoie un agent préparer un correctif. Un autre agent l’évalue selon la skill de votre projet et les tests. Si les tests passent, elle ouvre une PR et met à jour le ticket. Si les tests échouent, elle redonne l’erreur à l’agent une ou deux fois. Si elle reste bloquée, elle s’arrête et place le problème dans votre boîte de réception.
C’est aussi la différence entre l’automatisation et les boucles. Une automatisation dit : faire la première étape, puis la deuxième, puis la troisième. Une boucle dit : examiner l’état, décider de la prochaine étape, l’exécuter, la vérifier, puis décider si une autre itération est nécessaire. Elle ressemble davantage à un minuscule processus d’ingénierie qu’à un script.
Mais c’est aussi ici que le hype devient dangereux. En ce moment, il existe deux gros problèmes avec le loop engineering :
Premièrement, définir l’objectif est difficile. Il doit être précis, mais aussi vérifiable. Le développement logiciel est souvent exploratoire. Vous ne connaissez pas toujours la forme finale d’une fonctionnalité dès le début. Si l’état final est flou, la boucle optimisera selon la phrase vague que vous lui avez donnée, et ça peut être pire qu’une seule passe manuelle faite avec soin. Et le code est la tâche la plus facile. Si vous essayez d’automatiser une tâche plus subjective ou créative, comme écrire un script YouTube sur le loop engineering en lui disant de le rendre « bon », elle pourrait simplement le réécrire à l’infini. Maintenant que j’y pense, ça ressemble à un trait humain que certains d’entre nous ont aussi. Mes dizaines de scripts inachevés peuvent en témoigner 😅
Bref, la récompense, ou simplement l’objectif global, demande beaucoup de réflexion, d’attention et d’expérimentation.
Le deuxième problème est le coût. Ça peut devenir ridicule, rapidement. Si vous laissez un agent se prompter continuellement, s’évaluer lui-même, créer des assistants et continuer à réessayer, vous pouvez brûler des millions de tokens très vite. Particulièrement s’ils travaillent pendant que vous dormez ou que vous ne pouvez pas vérifier. C’est pourquoi il est plus facile de survendre le loop engineering sur Twitter lorsqu’on travaille dans un endroit avec un énorme budget de tokens, comme les grands laboratoires. Pour le reste d’entre nous, le budget fait partie de l’architecture. Personnellement, je veux démarrer mes boucles manuellement et les vérifier pour m’assurer que tout se déroule bien.
C’est pourquoi chaque boucle sérieuse a besoin de freins clairs : un nombre maximal d’itérations, la détection de l’absence de progrès et un budget quotidien en tokens ou en dollars. Et elle a besoin d’une vérification plus solide que l’agent qui dit avoir terminé. Exécutez les tests. Faites le typecheck. Utilisez un agent évaluateur. Comparez le diff aux spécifications. En production, rien n’est terminé tant qu’un mécanisme ne l’a pas vérifié.
Ma position ici est la même que pour les agents en général chez Towards AI : commencez par quelque chose de simple, puis ajoutez de l’autonomie seulement lorsqu’elle paie pour elle-même. Si le workflow est ponctuel, promptez simplement le modèle. Si le travail se répète et possède un signal clair de réussite ou d’échec, ou en d’autres mots, si vous avez l’impression de seulement faire les actions stupides et répétitives, créez une boucle. Si la tâche est vague, comme imaginer une meilleure stratégie de produit, ne la confiez peut-être pas à une boucle while avant d’aller prendre un café avec d’autres humains pour d’abord définir un meilleur objectif. S’il vous plaît.
Donc, le point à retenir n’est pas que le prompt engineering est mort. C’est que le levier principal a changé. Il y a cinq ans, vous écriviez vous-même le code. Il y a deux ans, vous promptiez un modèle pour qu’il écrive du code. L’an dernier, vous regardiez Claude coder pour vous et vous acceptiez simplement les tâches une par une au cas où il foirait. Aujourd’hui, pour les bonnes tâches, vous concevez la boucle qui prompte, vérifie, réessaie et s’arrête.
Peu importe ce que vous faites, que vous ne changiez rien à votre workflow ou que vous vous lanciez à fond dans les boucles, assurez-vous simplement de rester l’ingénieur. Lisez ce qu’elles livrent. Soyez responsable de la qualité. Écrivez les skills, ou au moins contrôlez-les. Définissez les conditions d’arrêt, l’objectif précis et les sous-objectifs. Vous pouvez utiliser les boucles pour avancer plus vite sur un travail que vous comprenez ou pour éviter complètement de comprendre le travail. Faites le bon choix pour votre futur vous!
Et vous? Utilisez-vous déjà des boucles? J’aimerais connaître votre setup actuel d’agents. Dites-le-moi!
FAQ
Qu’est-ce que le loop engineering?
Le loop engineering consiste à concevoir le processus reproductible autour d’un agent : ce qu’il voit, ce qu’il peut faire, comment il vérifie son travail et quand il s’arrête.
En quoi est-ce différent du prompting?
Le prompting donne une instruction. Une boucle définit un système d’exploitation pour les tentatives répétées, le feedback, la vérification et la récupération.
Qu’est-ce qui peut mal tourner avec les boucles?
Une mauvaise boucle peut gaspiller des tokens, répéter des échecs ou optimiser le mauvais objectif. Les conditions d’arrêt et les vérifications comptent donc énormément.
Qu’est-ce qui devrait arrêter la boucle d’un agent?
Une boucle a besoin d’une condition d’achèvement mesurable, d’un seuil d’échec, d’une limite de temps ou d’un budget de tokens ou d’argent défini avant son exécution.
Pourquoi conserver la mémoire d’un agent dans le repo ou dans un stockage externe?
Les artefacts externes survivent aux limites du contexte du modèle et permettent aux itérations suivantes d’inspecter les décisions, les outputs et les preuves antérieures.
Pourquoi utiliser des worktrees avec des agents de code en parallèle?
Chaque agent obtient un répertoire de travail isolé pour le repo, ce qui empêche les modifications simultanées de s’écraser les unes les autres.