Ingénierie en boucle : pourquoi le créateur de Claude Code affirme ne plus avoir besoin de prompter

Je n'incite plus Claude. J'ai des boucles qui tournent et qui incitent Claude à faire ce qu'il faut. Mon travail, c'est d'écrire des boucles.

— Boris Cherny, créateur et responsable de Claude Code chez Anthropic.

Pendant environ deux ans, la compétence que tout le monde recherchait était l'ingénierie de prompt. Écrire un bon prompt, partager assez de contexte, lire la sortie, écrire le prompt suivant. Vous teniez l'agent comme un outil, un tour à la fois.

Cette époque touche discrètement à sa fin.

À la mi-2026, trois voix ont convergé vers la même idée à quelques jours d'intervalle. Boris Cherny (Claude Code) a dit que son travail consiste désormais à écrire des boucles. Peter Steinberger (créateur d'OpenClaw) a déclaré à des millions de développeurs : « Vous ne devriez plus inciter les agents de codage. Vous devriez concevoir des boucles qui incitent vos agents. » Et Addy Osmani (Google) a donné son nom au modèle dans un article largement partagé : Loop Engineering. Cet article décompose ce qu'est réellement le loop engineering, les problèmes qu'il résout, comment il les résout, une démonstration de code fonctionnel que vous pouvez exécuter dès aujourd'hui, et les compromis honnêtes que personne ne mentionne dans les fils d'actualité.

Qu'est-ce que le Loop Engineering ?

Le loop engineering consiste à vous remplacer en tant que personne qui incite l'agent. Vous concevez un système qui fait l'incitation à votre place.

Une boucle est un objectif récursif : vous définissez un but et une condition d'arrêt vérifiable, et l'IA itère, découvre le travail, l'implémente, le vérifie, enregistre la progression jusqu'à ce que la condition soit vraie. Vous n'êtes plus dans la boucle. Vous êtes au-dessus d'elle.

Pensez à la hiérarchie comme ceci :

1. Ingénierie de prompt : vous écrivez une bonne instruction.
2. Ingénierie de contexte : vous assemblez les bonnes informations autour de l'instruction.
3. Ingénierie de harnais d'agent : vous construisez l'environnement dans lequel un agent s'exécute.
4. Loop engineering : vous construisez le système qui exécute le harnais sur une minuterie, génère des assistants, vérifie son

L'ancien flux de travail : écrire le prompt → lire la sortie → écrire le prompt suivant (vous êtes la boucle).

Le nouveau flux de travail : concevoir la boucle une fois → la boucle découvre le travail → la boucle assigne des agents → la boucle vérifie → la boucle enregistre l'état → répéter (vous examinez et orientez).

Les Problèmes Résolus par le Loop Engineering

Problème 1 : Vous êtes le goulot d'étranglement

Dans l'incitation manuelle, rien ne se passe sauf si vous tapez. Chaque tour attend un humain. Les agents en 2026 peuvent fonctionner de manière autonome pendant des heures, les modèles de classe Claude Opus ont fonctionné sans surveillance pendant près de cinq heures sur des tâches difficiles, mais un chat piloté par un humain les limite à votre vitesse de frappe et à votre capacité d'attention. L'agent est inactif 95 % du temps, à vous attendre.

Problème 2 : Les agents oublient tout entre les sessions

Chaque session démarre à froid. Le modèle redécouvre les conventions de votre projet, les étapes de construction et les leçons durement acquises à partir de zéro — ou pire, comble les lacunes avec des suppositions confiantes. C'est ce qu'Osmani appelle la dette d'intention : une intention non exprimée qui est remboursée (ou devinée) à chaque exécution.

Problème 3 : L'agent note son propre travail

Un agent qui a écrit le code est beaucoup trop indulgent lorsqu'il le révise. « C'est fait » est une affirmation, pas une preuve. Sans vérification indépendante, les exécutions autonomes accumulent les erreurs au lieu de les corriger.

Problème 4 : Les agents parallèles entrent en collision

Dès que vous exécutez plus d'un agent sur un dépôt, ils commencent à écraser les fichiers les uns des autres — le même désastre que deux ingénieurs commitant sur les mêmes lignes sans se parler.

Problème 5 : Le travail récurrent n'est jamais automatisé

Le triage des échecs CI, les mises à jour de dépendances, la chasse aux tests instables, l'étiquetage des problèmes, les nettoyages quotidiens de bugs — ce travail est ennuyeux, sans fin et parfaitement adapté aux agents. Mais personne n'incite un agent à le faire chaque matin, parce que vous devriez être présent chaque matin pour faire l'incitation.

Comment le Loop Engineering les Résout : Les Six Blocs de Construction

Une boucle qui fonctionne réellement sans surveillance n'est pas un long prompt. C'est un petit système avec cinq capacités plus une mémoire. Remarquablement, Claude Code et Codex d'OpenAI intègrent désormais tous les six de manière native — la forme de la boucle est devenue indépendante de l'outil.

1. Automatisations : le battement de cœur

Des exécutions planifiées qui font la découverte et le triage par elles-mêmes. Cela résout le Problème 5.

• Claude Code : /loop réexécute un prompt selon une cadence (d'intervalles d'une minute à des fenêtres de plusieurs jours), des tâches planifiées par cron, des Routines pour des automatisations planifiées dans le cloud, des hooks de cycle de vie, ou des GitHub Actions pour des exécutions qui survivent à la fermeture de votre ordinateur portable.
• Codex : l'onglet Automatisations — choisissez un projet, un prompt, une cadence ; les résultats atterrissent dans une boîte de réception de triage, les exécutions vides s'archivent elles-mêmes.

La primitive tueuse en session est /goal : continuez à travailler à travers les tours jusqu'à ce qu'une condition que vous avez écrite soit vérifiablement vraie — « tous les tests dans test/auth passent et le lint est propre » — et partez.

1. Worktrees : isolement pour le parallélisme

Les worktrees Git donnent à chaque agent son propre répertoire de travail sur sa propre branche, partageant l'historique du dépôt. Les modifications ne peuvent littéralement pas entrer en collision. Cela résout le Problème 4.

• Claude Code : git worktree, le flag --worktree, ou isolation : worktree sur un sous-agent pour que chaque assistant obtienne un checkout frais et auto-nettoyant.
• Codex : worktree intégré par thread.

Les utilisateurs avancés signalent l'exécution de 10 à 15 agents parallèles de cette manière.

1. Compétences : connaissances du projet codifiées

Une compétence est un dossier avec un SKILL.md — vos conventions, étapes de construction et « on ne fait pas comme ça à cause de cet incident » écrit une fois, lu par l'agent à chaque exécution. Cela résout le Problème 2. Sans compétences, la boucle redécouvre votre projet à partir de zéro à chaque cycle. Avec elles, elle cumule.

1. Plugins et Connecteurs (MCP) : des mains sur de vrais outils

Une boucle qui ne voit que le système de fichiers est une petite boucle. Les connecteurs MCP lui permettent de lire votre tracker de problèmes, d'interroger une base de données, d'ouvrir la PR, de mettre à jour le ticket Linear et de ping Slack lorsque le CI passe au vert. C'est la différence entre un agent qui dit « voici le correctif » et une boucle qui livre le correctif.

1. Sous-agents : séparer le créateur du vérificateur

L'idée structurelle la plus importante de tout le modèle. Un agent (ou modèle) écrit ; un autre agent avec des instructions différentes vérifie. Cela résout le Problème 3. Le /goal de Claude Code intègre cela : un modèle séparé évalue si la condition d'arrêt est remplie, de sorte que le travailleur ne note jamais son propre travail.

• Claude Code : sous-agents dans .claude/agents/, équipes d'agents.
• Codex : sous-agents en TOML dans .codex/agents/ — par exemple, un modèle fort avec un effort de raisonnement élevé comme votre réviseur de sécurité, un modèle rapide en lecture seule comme votre explorateur.

1. État : l'épine dorsale de la mémoire

Un fichier Markdown, un journal de progression ou un tableau Linear — tout ce qui vit en dehors de la conversation et enregistre ce qui est fait et ce qui reste à faire. Cela semble trop bête pour avoir de l'importance. C'est l'astuce unique dont dépend tout agent à longue durée de vie : le modèle oublie entre les exécutions ; le dépôt, non. Cela résout également le Problème 2 au niveau de la tâche, et c'est ce qui permet à l'exécution de demain de reprendre exactement là où celle d'aujourd'hui s'est arrêtée. Avec les automatisations, cela dissout le Problème 1 — la boucle fonctionne pendant que vous dormez.

À Quoi Ressemble une Vraie Boucle

Voici la forme de référence (adaptée de la boucle quotidienne d'Osmani) :

1. Une automatisation se déclenche sur le dépôt. Son prompt appelle une compétence de triage qui lit les échecs CI d'hier, les problèmes ouverts et les commits récents, et écrit les résultats dans STATE.md.
2. Pour chaque résultat qui vaut la peine d'être traité, la boucle ouvre un worktree isolé et envoie un sous-agent créateur pour rédiger le correctif.
3. Un sous-agent vérificateur examine le brouillon par rapport aux compétences du projet et aux tests existants.
4. Les connecteurs ouvrent la PR, lient le ticket et publient sur Slack.
5. Tout ce que la boucle ne peut pas gérer atterrit dans une boîte de réception de triage — pour vous.
6. STATE.md enregistre ce qui a été essayé, ce qui a réussi, ce qui est encore ouvert. L'exécution de demain reprend à partir de là.

Sources et lectures complémentaires : Addy Osmani, « Loop Engineering » (addyosmani.com) ; la couverture du loop engineering par The New Stack ; la causerie au coin du feu de Boris Cherny à la conférence Scale de Meta et l'interview sur CNBC ; la documentation de Claude Code sur les Routines (code.claude.com/docs/en/routines) ; la documentation des Automatisations d'OpenAI Codex.

Si vous construisez une boucle à partir de cet article, j'adorerais la voir !! Répondez avec ce que vous avez automatisé en premier.