Les ingénieurs de Google vous expliquent ce qu'est l'ingénierie de boucle ? Cinq blocs de construction + mémoire externe, le cours obligatoire de l'IA en 2026

Loop Engineering est un système qui exécute lui-même une proxy de prompt, conçu par une architecture composée de cinq blocs : Automations, Worktrees, Skills, Plugins/Connectors, Sub-agents, complétés par une mémoire externe. Cet article est tiré de Google Software Engineer Addy Osmani.
(Précédent : Anthropic a ajouté la détection de distillation dans Claude Fable 5, peut-elle bloquer les modèles open source chinois ?)
(Contexte supplémentaire : Anthropic : leader américain en modèles d’IA, pense que seul en étant supérieur à la Chine on peut défendre la démocratie, propose de criminaliser les attaques par distillation)

Table des matières de l’article

Toggle

• Cinq blocs, avec quelques notes
• Automations : le battement du cœur de la boucle
• Worktrees : éviter que le parallèle ne devienne chaos
• Skills : enfin, plus besoin de réexpliquer ton projet à chaque fois
• Plugins et connecteurs : la boucle tend la main vers tes outils réels
• Sub-agents : séparer la création de la vérification
• À quoi ressemble une boucle
• Ce que la boucle ne fait pas encore pour toi
• Assembler la boucle, mais continuer à être ingénieur

Loop engineering consiste à remplacer le « prompt proxy » que tu fais toi-même par un système que tu conçois pour faire cette tâche. La « boucle » ici peut être comprise comme un objectif récursif : tu définis un but, l’IA itère jusqu’à ce qu’il soit atteint. Je crois que c’est peut-être la façon dont nous collaborerons avec des agents de codage à l’avenir.

Mais pour commencer, c’est encore très early, je suis moi-même sceptique, et tu dois absolument faire attention aux coûts de tokens. Je vais décomposer cette idée : qu’est-ce que c’est, et qu’est-ce que cela implique.

Peter Steinberger a récemment dit : « Tu ne devrais plus prompt ton agent de codage. Tu devrais concevoir une boucle qui prompt ton agent. » Boris Cherny, responsable de Claude Code chez Anthropic, a aussi dit quelque chose de similaire : « Je ne prompt plus Claude. Je laisse la boucle faire le prompt, c’est la boucle qui décide ce qu’elle doit faire. »

Il y a environ deux ans, pour obtenir des résultats d’un agent de codage, tu écrivais un bon prompt, fournissais du contexte, puis tu lisais la réponse, et tu enchaînais. L’agent était un outil, et tu le contrôlais de bout en bout, tour après tour. Cette phase touche à sa fin, du moins certains le pensent.

Aujourd’hui, tu construis un petit système : il cherche du travail, l’attribue, vérifie, note ce qui est terminé, puis décide de la prochaine étape, en laissant ce système « pousser » l’agent plutôt que de le faire toi-même. J’ai déjà écrit sur son proche cousin, « agent harness engineering », qui consiste à créer un environnement pour faire fonctionner un seul agent — un « modèle d’usine » pour la construction logicielle.

Loop engineering est une version plus avancée que harness : harness reste là, mais il exécute selon un rythme, crée des assistants, se nourrit lui-même.

Ce qui m’étonne, c’est que ce n’est plus seulement un outil. Il y a un an, pour écrire une boucle, tu devais assembler beaucoup de bash, la maintenir toi-même, c’était ton propre truc. Maintenant, ces composants sont intégrés directement dans le produit. La liste de Steinberger correspond presque entièrement à l’application Codex, puis à Claude Code. Une fois que tu vois que la forme est la même, tu ne te battes plus pour « quel outil utiliser » : tu conçois une boucle qui peut tourner indépendamment de l’outil.

Cinq blocs, avec quelques notes

Une boucle nécessite cinq éléments, plus une mémoire. Je vais d’abord les lister, puis faire correspondre.

2. Automations : déclenchées selon un calendrier, pour faire automatiquement discovery et triage.
3. Worktrees : isoler deux agents parallèles pour éviter qu’ils ne se marchent dessus.
4. Skills : encoder la connaissance spécifique au projet, qui était auparavant guessée.
5. Plugins et connecteurs : connecter l’agent à tes outils existants.
6. Sub-agents : un pour générer des idées, un autre pour vérifier.

Et la sixième : la mémoire. Un fichier markdown, ou un tableau Linear, tout ce qui vit hors de la conversation unique, pour enregistrer « ce qui a été fait, la prochaine étape ». Ça peut sembler idiot, mais c’est la technique sur laquelle reposent tous les agents longue durée : le modèle oublie tout entre deux runs, donc la mémoire doit être stockée sur disque, pas dans le contexte. L’agent oublie, le repo non.

Les deux produits supportent maintenant ces cinq éléments.

| Terme original | Rôle dans la boucle | Codex app | Claude Code | | --- | --- | --- | --- | | Automations | Déclenchement planifié, discovery et triage | Onglet Automations : choisir projet, prompt, cadence, environnement ; résultats dans Triage ; /goal pour run-until-done | Tâches planifiées, cron, /loop, /goal, hooks, GitHub Actions | | Worktrees | Isoler le développement parallèle | Chaque thread a son worktree intégré | git worktree, --worktree, isolation via isolation: worktree sur subagent | | Skills | Encoder la connaissance du projet | Agent Skills (SKILL.md), appelé via $name ou implicitement | Agent Skills (SKILL.md) | | Plugins / connecteurs | Connecter à tes outils | Connectors (MCP) + plugins de diffusion | Serveurs MCP + plugins | | Sub-agents | Idées et vérifications | Définis en TOML dans .codex/agents/ | Dans .claude/agents/ : task subagents, équipes d’agents | | State | Suivi de l’état d’avancement | Markdown ou via connector Linear | Markdown (AGENTS.md, fichiers de progression) ou via MCP Linear |

Les noms diffèrent, mais la capacité essentielle est la même. Je vais détailler chaque point, car honnêtement, le diable est dans les détails : si la boucle reste stable ou fuit, tout dépend de ces détails.

Automations : le battement du cœur

Automations est ce qui fait que la « boucle » devient vraiment une boucle, et pas juste « ce que tu as lancé une fois ». Dans Codex app, tu crées une automation dans l’onglet, choisis le projet, le prompt, la fréquence, si ça tourne en local ou en background. Les découvertes sont envoyées dans la boîte de triage, celles qui ne sont pas pertinentes sont archivées, c’est pratique.

Chez OpenAI, ils l’utilisent pour des tâches répétitives mais essentielles : tri quotidien des issues, résumés CI, briefing de commits, repérer les bugs introduits la semaine dernière. Automation peut appeler des skills, donc tes tâches périodiques sont maintenues : tu déclenches $skill-name, plutôt que de coller une grosse série d’instructions dans un cron obsolète.

Claude Code suit une logique similaire, mais avec un chemin différent : via planification et hooks. Tu peux utiliser /loop pour faire répéter prompt ou commande à intervalle régulier, planifier avec cron, utiliser hooks pour déclencher des commandes shell à des points précis du cycle de vie de l’agent, ou pousser tout ça dans GitHub Actions pour continuer après la fermeture de ton laptop. La logique est la même : tu définis une tâche automatique, lui donnes un rythme, et la découverte t’arrive automatiquement, sans que tu aies à ouvrir ton terminal.

Un autre terme utile dans une session : /loop, qui répète selon un rythme. /goal, qui tourne jusqu’à ce que la condition que tu as écrite soit vraie, avec une vérification par un petit modèle pour décider si c’est terminé. La différence : /loop répète à intervalle régulier, /goal continue jusqu’à ce qu’un critère soit rempli, avec une vérification à chaque étape. Tu peux lui donner une condition comme « tous les tests dans auth passent, le lint est clean » et il s’arrête. Codex a aussi /goal, qui tourne sur plusieurs cycles jusqu’à ce qu’une condition de stop soit remplie, puis peut pause, resume, ou reset. Ces deux termes, même concept, dans deux outils différents, illustrent le pattern central.

C’est donc « faire émerger le travail ». La suite de la boucle consiste à « faire quelque chose avec ces tâches ».

Worktrees : éviter que le parallèle ne devienne chaos

Si tu fais tourner plusieurs agents en même temps, les fichiers risquent de se marcher dessus, ce qui mène à la catastrophe. Deux agents modifiant le même fichier, c’est comme deux ingénieurs qui commit sur la même ligne sans se parler. git worktree résout ça : c’est un répertoire de travail séparé, avec sa propre branche, partageant l’historique du repo. Ainsi, l’édition par un agent ne peut pas entrer en collision physique avec celle d’un autre.

Codex supporte nativement les worktrees, donc plusieurs threads peuvent travailler simultanément sur le même repo sans conflit. Claude Code utilise git worktree, l’option --worktree pour ouvrir une session dans son propre checkout, et la configuration isolation: worktree sur chaque subagent (chacun a son checkout propre, qui se nettoie après). J’ai déjà écrit sur cette approche dans l’article « orchestration tax » : le worktree élimine la collision mécanique, mais la limite reste la capacité de revue humaine — c’est ton bandwidth qui détermine combien d’agents tu peux faire tourner.

Skills : tu n’as plus besoin de tout réexpliquer

Skills, c’est ce qui te permet de ne pas répéter à chaque session la connaissance du projet. Les deux outils utilisent le même format : un dossier contenant SKILL.md, avec instructions et métadonnées, plus éventuellement des scripts, références, assets. Chez Codex, tu peux invoquer un skill avec $ ou /skills, ou il se déclenche automatiquement si la tâche correspond à la description. C’est pourquoi une description précise et simple bat une description sophistiquée. Chez Claude Code, c’est pareil, j’en ai parlé dans l’article « agent skills ».

Skills, c’est aussi « intention sans avoir à la payer à chaque fois ». J’ai déjà évoqué dans l’article « the intent debt » : chaque session d’agent démarre à froid, il doit deviner avec confiance ton intention, en comblant les trous. Skill, c’est écrire cette intention à l’extérieur — dans la convention, dans les étapes de build, dans « on ne fait pas comme ça parce que la dernière fois… » —, et l’agent la lit à chaque run. Sans skill, chaque boucle repart de zéro, en réécrivant tout ton projet. Avec skill, tu accumules de la valeur composable.

Une chose importante : skill, c’est le format d’écriture, plugin, c’est la façon de distribuer. Si tu veux partager un skill entre repos, ou en faire un package, tu le packes en plugin. Codex le fait, Claude Code aussi.

Plugins et connecteurs : la boucle tend la main vers tes outils réels

Une boucle limitée au système de fichiers est très restreinte. Connectors, construits sur MCP, permettent à l’agent de lire des issues, consulter une base de données, appeler une API staging, envoyer un message Slack. Codex et Claude Code parlent tous deux de MCP, donc un connector écrit pour l’un peut souvent être réutilisé pour l’autre. Les plugins regroupent connecteurs et skills, pour que ton équipe installe tout d’un coup, sans tout reconstruire à la main.

C’est cette intégration qui permet à la boucle d’agir dans ton environnement réel : pas seulement te dire « si ça pouvait faire ça, ça le ferait », mais faire réellement.

Sub-agents : séparer la création de la vérification

Le meilleur outil structurel dans une boucle, c’est de séparer « écrire » et « vérifier ». Le modèle qui écrit le code se donne souvent une auto-évaluation trop indulgente. En utilisant un second agent, différent, qui vérifie ce que le premier a produit, tu peux attraper ses illusions.

Codex ne crée des subagents que sur demande, en parallèle, puis intègre leurs résultats dans une réponse unique. Tu définis chaque agent dans .codex/agents/ en TOML, avec nom, description, instructions, et éventuellement modèle et effort de raisonnement — ton contrôleur de sécurité peut utiliser un modèle puissant avec un budget élevé, ton explorateur peut être léger et en lecture seule. Claude Code fait pareil, avec ses subagents et équipes d’agents dans .claude/agents/. La séparation classique : un agent explorateur, un agent implémentant, un vérificateur.

J’ai déjà plaidé deux fois pour cette approche : une « orchestration d’agents de code », et une « revue de code adversariale ». Dans une boucle, c’est crucial, car elle tourne souvent sans que tu regardes. Un vérificateur fiable est la seule garantie que tu peux avancer en toute confiance. Les subagents consomment plus de tokens, car chacun doit faire tourner son propre modèle et ses outils. Donc, il faut réserver cette dépense pour les « vérifications de valeur ». La règle dans Claude Code /goal est que la boucle décide si c’est terminé, par un modèle dédié, pas celui qui écrit le code — « l’exécutant vs le vérificateur » appliqué à la condition d’arrêt.

À quoi ressemble une boucle

En assemblant tout, un seul thread devient un petit tableau de bord de contrôle. Voici la forme que j’utilise souvent.

Une automation tourne chaque matin dans le repo. Elle appelle un skill de triage, qui lit les échecs CI, issues ouvertes, commits récents, et écrit tout dans un markdown ou un tableau Linear. Pour chaque découverte pertinente, ce thread ouvre un worktree isolé, délègue à un subagent la rédaction d’une solution, puis un second subagent vérifie cette proposition contre les skills et tests existants.

Connectors permettent d’ouvrir des PR, de mettre à jour des tickets. Tout ce qui ne peut pas être fait par la boucle va dans la boîte de triage. Le fichier d’état est la colonne vertébrale : il enregistre ce qui a été tenté, ce qui est en cours, ce qui reste ouvert — pour que la prochaine matinée puisse continuer là où on s’est arrêté.

Regarde ce que tu as fait : tu n’as conçu qu’une seule fois. Aucune étape n’est promptée par toi. C’est la concrétisation de la phrase de Steinberger. Et cette même boucle peut tourner dans Codex et Claude Code, parce que les composants sont les mêmes.

Ce que la boucle ne fait pas encore pour toi

La boucle change la forme du travail, mais ne t’en décharge pas. Et trois problèmes deviennent plus aigus, pas plus faciles, avec l’amélioration.

La vérification reste ta responsabilité. Une boucle qui ne fait pas l’objet d’un contrôle, c’est une boucle où personne ne surveille les erreurs. La séparation du vérificateur et du créateur, c’est pour que la « complétude » ait un sens ; mais « terminé » reste une assertion, pas une preuve. Je répète ce que j’ai dit dans « code review in the age of AI » : ton boulot, c’est de sortir un code « que tu as personnellement validé pour déployer ».

Ta compréhension peut se dégrader, si tu laisses faire. Plus vite la boucle déploie « ce qui n’est pas ton code », plus grande sera l’écart entre « ce qui existe » et « ce que tu as vraiment ». C’est une dette de compréhension, et une boucle fluide ne fait que l’accroître — sauf si tu lis ce que la boucle produit.

Une posture confortable est une posture dangereuse. Quand la boucle tourne toute seule, tu as tendance à arrêter de juger, à accepter tout ce qu’elle renvoie. Je l’appelle « surrender cognition » (abandon cognitif). Concevoir une boucle, c’est un antidote quand tu as du jugement, mais un accélérateur quand tu veux éviter de réfléchir — le même mouvement, deux résultats opposés.

Assembler la boucle, mais continuer à être ingénieur

Je pense que c’est la direction vers laquelle notre travail va évoluer. Mais, si je ne vérifie pas moi-même le code, ou si je me fie entièrement à la boucle automatique, la qualité du produit va baisser. Je risque de tomber dans une spirale descendante, de plus en plus profond.

En résumé : construis ta boucle, mais n’oublie pas que prompt ton agent toi-même reste une méthode efficace. Tout est question d’équilibre.

La boucle change aussi selon « qui » l’utilise. Deux personnes utilisant la même boucle peuvent obtenir des résultats complètement opposés. Une personne l’utilise pour accélérer un travail qu’elle comprend profondément, une autre pour éviter de comprendre. La boucle ne fait pas la différence, c’est toi qui la façonnes.

C’est pour ça que le « loop design » est plus difficile, pas plus simple, que le prompt engineering. La clé de Cherny n’est pas que le travail devienne plus simple, mais que le levier change de place.

Construis ta boucle, mais comme un « ingénieur qui veut continuer à faire », pas comme quelqu’un qui veut juste appuyer sur le bouton « démarrer ».