Boucles d'agents : comment un mot est devenu un produit en six semaines

Si vous avez passé le mois de juin sur X ou LinkedIn, vous avez croisé la phrase sous une forme ou une autre : le prompting est mort, place aux boucles. Le genre d'affirmation qui se propage vite parce qu'elle est simple, et qui mérite qu'on s'y arrête parce qu'elle est fausse — ou plus exactement, parce qu'elle est vraie d'une manière beaucoup plus intéressante que ce que le slogan laisse entendre.

Voici ce qui s'est réellement passé, ce que le concept recouvre, et pourquoi la partie la plus importante du sujet est aussi celle dont personne ne parle.

Acte 1 — Juin 2026 : trois phrases et un nom

Tout part de déclarations de praticiens, pas d'une publication de laboratoire.

Boris Cherny, qui dirige Claude Code chez Anthropic, lâche dans une interview une phrase qui va circuler à plusieurs centaines de milliers de vues en vingt-quatre heures : « I don't prompt Claude anymore. My job is to write loops. » Peter Steinberger, dans la foulée, formule l'impératif : arrêtez de prompter vos agents de code, concevez les boucles qui les promptent.

Le 7 juin, Addy Osmani — directeur chez Google Cloud AI, mais il écrit à titre personnel — publie l'essai qui donne au phénomène son nom et, plus utilement, sa structure : Loop Engineering. Sa définition tient en une ligne : vous vous remplacez vous-même comme personne qui prompte l'agent, et vous concevez le système qui le fait à votre place.

Rien de technologiquement neuf là-dedans. Osmani le dit lui-même : ce qui a changé, c'est que les briques nécessaires ont cessé d'être un tas de scripts bash maison pour devenir des fonctionnalités livrées dans les produits. Le concept était là ; l'outillage vient de le rattraper.

Le piège : « boucle » désigne trois choses différentes

C'est de là que vient l'essentiel de la confusion, et c'est le point à poser avant tout le reste.

Un papier publié sur arXiv fin juin par Sandeco Macedo (Instituto Federal de Goiás) prend le slogan au sérieux et commence par démêler les trois sens du mot :

1. La boucle de programmation. Un while. Du flot de contrôle. Rien à voir avec le sujet.
2. Le cycle interne de l'agent. Le modèle qui appelle des outils en boucle jusqu'à une condition d'arrêt — penser, agir, observer, décider à nouveau. Formalisé dès 2022 avec ReAct, c'est la plomberie du harness. Elle existe qu'on la conçoive ou non. C'est aussi ce que décrit Google dans son whitepaper Introduction to Agents sous le nom de cycle Think → Act → Observe.
3. La spécification de boucle. Un artefact externe, borné et réutilisable, qu'un humain conçoit et confie au harness : un déclencheur, un objectif, une vérification, une règle d'arrêt, une mémoire.

Seul le troisième sens est neuf. La formule du papier est bonne : le harness fournit le moteur, le loop engineering écrit le pilote.

Acte 2 — Le mot est cadré

Trois semaines après l'essai d'Osmani, le sujet a déjà sa doctrine.

L'empilement

Le papier arXiv situe la pratique comme une couche supplémentaire, pas comme un remplacement :

Chaque couche englobe la précédente. Le verdict sur le slogan est sans ambiguïté : une boucle, c'est au fond un prompt répété avec un échafaudage autour. Apprendre à se servir de la clé à molette ne veut pas dire jeter le tournevis.

Non, le prompting n'est pas mort. Un prompt bâclé à l'intérieur d'une boucle produit juste du travail bâclé plus vite.

L'anatomie

Une boucle digne de ce nom comporte cinq éléments plus une mémoire :

• Un déclencheur — humain, planifié, ou événementiel.
• Un objectif, de préférence vérifiable.
• Une exécution, idéalement via des compétences nommées et testées plutôt que du prompt improvisé.
• Une vérification réelle.
• Une règle d'arrêt menant à un état terminal nommé : succès, sans-objet, bloqué, stagnant, épuisé. Une erreur ne compte jamais comme un succès.
• Une mémoire persistante, sur disque et non dans la conversation — parce que le modèle oublie tout entre deux exécutions. L'agent oublie, le dépôt non.

La taxonomie officielle

Le 30 juin, l'équipe Claude Code publie sa propre définition : une boucle, c'est un agent qui répète des cycles de travail jusqu'à ce qu'une condition d'arrêt soit atteinte. Quatre types :

L'exemple donné pour le mode goal est parlant dans sa banalité : /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries. Quand le critère de succès est défini, l'agent n'a plus à juger de ce qui est « assez bon » : un modèle évaluateur distinct vérifie la condition à chaque tentative d'arrêt et renvoie au travail tant qu'elle n'est pas remplie.

Le vrai sujet : la vérification

C'est ici que les articles de reprise décrochent, et c'est ici que tout se joue.

La partie difficile d'une boucle n'est pas d'écrire une meilleure instruction. C'est de concevoir le contrôle qui décide que le travail est terminé. Une boucle sans contradicteur, c'est un agent qui se donne raison à lui-même.

Le papier arXiv propose une échelle de rigueur à cinq niveaux, qui est probablement l'outil le plus utile de tout le corpus :

Le message qui organise l'échelle tient en une phrase : ne prétendez pas qu'un niveau 4 est un niveau 1. Une boucle n'est autonome qu'au niveau où se situe réellement son vérificateur.

Et une règle d'or, qui évite 80 % des sur-ingénieries : une boucle ne se justifie face à un simple prompt planifié que si le résultat d'un tour change l'action du tour suivant. Sinon, ce n'est pas une boucle, c'est une tâche cron déguisée.

Un chiffre pour calmer le battage : sur un corpus public de cinquante boucles réelles analysées à la main, 78 % ont encore un déclencheur manuel, 78 % tournent en agent solo, et seules 32 % développent une mémoire persistante. La pratique a bien mieux résolu le « comment je sais que c'est fini » que le « comment ça tourne sans moi ». Le discours est en avance sur les usages.

Acte 3 — Juillet 2026 : le mot devient un produit

Le 20 juillet, Linear annonce Loops : des workflows d'agents récurrents pour les équipes. L'annonce cite explicitement l'essai d'Osmani et pose le constat qui justifie le produit — le loop engineering est resté cantonné aux workflows de développeurs individuels ; et si toute une équipe produit pouvait travailler ainsi ?

Le fonctionnement est exactement l'anatomie décrite plus haut, packagée : on décrit la tâche en langage naturel, on choisit un déclencheur planifié ou événementiel, et à chaque exécution l'agent relit ses instructions et décide de la suite en s'appuyant sur le contexte des tickets, les bases de code connectées, les serveurs MCP et les exécutions précédentes.

Les cas d'usage annoncés sortent du code : diagnostiquer et router les bugs entrants, générer automatiquement les tickets iOS/Android/web dérivés d'une demande de fonctionnalité, ou confronter chaque soir les projets actifs au plan de release et mettre le document à jour quand le périmètre a bougé.

Six semaines, donc, entre le billet de blog qui nomme la pratique et la fonctionnalité facturée — disponible sur les plans Business et Enterprise, consommant des crédits IA. C'est un cycle d'adoption complet en compression maximale, et c'est en soi une donnée sur l'état du secteur.

Ce qui se perd en route

Reprenez la liste des cinq éléments d'une boucle et confrontez-la à ce que Linear livre. Déclencheur : oui. Objectif : oui. Exécution : oui. Mémoire : oui. Vérification et états terminaux nommés : rien.

La formulation employée est révélatrice : entièrement pilotées par l'IA, les Loops peuvent exercer un jugement, gérer les exceptions, naviguer dans l'ambiguïté. C'est la description d'un agent qui décide, pas d'un contrôle qui valide. Le mécanisme de confiance proposé est la visibilité partagée : n'importe qui peut relire les instructions et inspecter chaque exécution.

Traduit sur l'échelle : c'est un niveau 5. De la supervision humaine, pas de la vérification automatisée. Sur du triage de bugs, parfait. Sur « mettre à jour le plan de release parce que le périmètre a bougé », vous avez un agent qui modifie un document de référence partagé avec pour seul garde-fou le fait que quelqu'un puisse aller relire. C'est précisément l'anti-pattern « faire passer un niveau 4 pour un niveau 1 », appliqué à l'échelle d'une équipe entière.

Ce n'est pas un procès fait à Linear, qui livre un produit cohérent et probablement très utile. C'est une observation sur la mécanique d'abstraction : chaque couche ajoutée éloigne du contrôle, alors que le contrôle est exactement là où se trouve la valeur.

Les trois dettes

Osmani ferme son essai sur trois problèmes qui s'aggravent quand la boucle fonctionne bien, ce qui est contre-intuitif et mérite d'être retenu :

• La charge de vérification. Une boucle qui tourne sans surveillance est aussi une boucle qui se trompe sans surveillance. Séparer le vérificateur du producteur donne du sens au mot « terminé » — mais « terminé » reste une affirmation, pas une preuve.
• La dette de compréhension. Plus vite la boucle livre du code que vous n'avez pas écrit, plus l'écart se creuse entre ce qui existe et ce que vous comprenez.
• La reddition cognitive. La tentation d'arrêter d'avoir un avis dès que le système semble s'en sortir.

Sa conclusion vaut d'être citée telle quelle, parce qu'elle échappe aux deux camps habituels : deux personnes peuvent construire exactement la même boucle et obtenir des résultats opposés. L'une s'en sert pour aller plus vite sur un travail qu'elle maîtrise en profondeur. L'autre s'en sert pour éviter d'avoir à le comprendre. La boucle ne fait pas la différence. Vous, si.

À retenir

• « Boucle » désigne trois choses ; seule la troisième — la spécification externe — est nouvelle.
• Le loop engineering est une couche au-dessus du prompting, pas à sa place.
• La compétence centrale est le contrôle, pas l'instruction. Si vous ne savez pas écrire la vérification, vous n'avez pas de boucle.
• Pas de boucle si le résultat d'un tour ne change pas l'action du suivant. Une tâche planifiée suffit.
• Celui qui produit ne doit pas être celui qui valide.
• Nommez vos états d'arrêt. Une erreur n'est jamais un succès.
• Prévoyez un plafond de budget. Les coûts en tokens d'une boucle non bornée montent bien plus vite que l'intuition ne le suggère.

Sources

• Addy Osmani, Loop Engineering, 7 juin 2026 — addyosmani.com
• Addy Osmani, Own the Outer Loop, 9 juillet 2026 — le correctif : l'agent tient la boucle interne, l'ingénieur possède la boucle externe
• Anthropic, Loop engineering: Getting started with loops, 30 juin 2026 — claude.com
• Anthropic, Building Effective Agents, décembre 2024 — la distinction workflow / agent et les patterns evaluator-optimizer et orchestrator-workers
• Sandeco Macedo, Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting, arXiv:2607.00038, 28 juin 2026
• Linear, Introducing Loops, 20 juillet 2026 — linear.app
• Simon Willison, Designing agentic loops, septembre 2025 — le volet sécurité : conteneur isolé sans réseau, identifiants restreints, plafond de budget
• Google, Introduction to Agents, novembre 2025 — le cycle interne Think / Act / Observe et la discipline Agent Ops
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, arXiv:2210.03629, 2022