La terminaison de la boucle est le mécanisme, pas le prompt

Le plus difficile dans une boucle d'agent IA autonome, ce n'est pas de la faire agir. C'est de la faire s'arrêter pour la bonne raison. « An Introduction to Loop Engineering » de MachineLearningMastery (23 juillet 2026) parcourt le passage d'un agent prompté à la main à la conception du cycle qui le prompte, vérifie, mémorise et réexécute — et l'idée porteuse, sous le vocabulaire d'outils, est que la valeur d'une boucle est fixée par sa logique de terminaison et de vérification, non par la finesse d'une seule instruction.

La sortie de la boucle est le mécanisme, pas l'exécution

Une boucle, au sens de l'article, est un cycle répétitif où un modèle agit, obtient une rétroaction de son environnement, utilise cette rétroaction pour décider de la suite, et continue jusqu'à qu'une condition réelle et vérifiable soit satisfaite. Cette dernière proposition est tout l'argument. « Améliore l'appli » ne donne à l'agent rien à vérifier, donc elle tourne indéfiniment ou s'arrête sur une supposition. « Fais passer tous les tests du module d'authentification » est vérifiable mécaniquement, et cette différence est ce qui sépare une boucle dont vous pouvez vous éloigner d'une qui brûle des tokens en silence pendant une heure.

[UNIQUE INSIGHT] C'est le même principe que nous énonçons comme Theorem 3 dans the 21 papers : une propriété est garantie exactement quand son mécanisme est implémenté et mesure. Pour une boucle d'agent, la propriété est « done » — et le mécanisme est un vérificateur déterministe à l'intérieur du cycle, pas l'auto-rapport du modèle. Une boucle sans sortie qui mesure ne produit pas de travail fini ; elle produit des affirmations de travail fini. L'architecture honnête traite « done » comme une affirmation à vérifier, exactement comme le pseudocode de l'article traite verifier.passes(state) comme un contrôle déterministe et non comme une auto-évaluation.

L'article nomme l'unité de travail la boucle plutôt que le prompt, et ce recadrage importe parce qu'il déplace le levier d'ingénierie. Quand le modèle peut écrire le code lui-même, la compétence rare cesse d'être la capacité de formuler une très bonne phrase et devient la capacité de concevoir un cycle qui reste correct, vérifié et pointé vers le bon objectif pendant que personne ne regarde. C'est un habit d'ingénierie système, plus proche de concevoir un thermostat que d'écrire une phrase.

Pourquoi le vocabulaire a changé en une semaine

La chronologie dans l'article est assez spécifique pour la retenir. Le 7 juin 2026, le développeur Peter Steinberger a posté que la compétence pertinente avait déjà changé : vous ne devriez plus prompter les agents de code, vous devriez concevoir les boucles qui les promptent pour vous. Ce post aurait dépassé 6,5 millions de vues en quelques jours. Le lendemain, l'ingénieur de Google Addy Osmani a publié un essai titré simplement « Loop Engineering » qui a donné à l'idée une anatomie — automations, worktrees, skills, connecteurs, sub-agents, et sous tout ça la mémoire externe. Boris Cherny, qui dirige Claude Code chez Anthropic, est cité disant qu'il ne prompte plus Claude directement ; il écrit des boucles qui le promptent.

La vitesse a du sens quand on regarde ce qui a changé en dessous. À mi-2026, les agents de code étaient devenus assez bons pour tourner sans surveillance sur de vraies longues durées, se remettant de leurs propres erreurs en chemin. Dès qu'une seule exécution peut durer une heure et toucher des dizaines de fichiers, le goulot n'est plus le prompt. C'est de savoir si vous avez construit un cycle qui garde l'agent productif, vérifié et pointé vers le bon objectif pendant toute l'heure — y compris la partie où personne ne regarde.

Prompt, contexte, harness, boucle — chaque couche enveloppe la précédente

L'article place loop engineering comme la couche la plus récente dans une progression, chacune enveloppant la précédente au lieu de la remplacer. Prompt engineering (à peu près 2022–2024) était la formulation : rôle, étapes, exemples, chaîne de pensée. Context engineering (2025) a déplacé le focus sur tout ce que le modèle voit au moment de répondre — historique, documents récupérés, sortie d'outils. Le Tobi Lütke de Shopify a offert une définition qui est restée, et dès septembre 2025 Anthropic avait formalisé context engineering comme la curation de l'ensemble optimal de tokens disponibles pendant l'inférence.

Harness engineering est arrivé début 2026 quand les agents ont commencé à faire du travail plus long et multi-étapes en production. Le harness est l'environnement complet autour d'un agent — échafaudage, outils, contraintes, boucles de rétroaction. Loop engineering est la couche au-dessus : là où harness engineering demande quel environnement un agent besoin, loop engineering pose la question plus étroite et plus opérationnelle de quel cycle le maintient au travail vers l'objectif et quand exactement ce cycle s'arrête.

[PERSONAL EXPERIENCE] Nous construisons dans cet ordre de pile chez Everythink depuis que le HAI Engine est entré en production en 2016 — prompt, puis contexte, puis harness, puis boucle — et l'ordre n'est pas cosmétique. Chaque couche contient la précédente, c'est pourquoi une boucle sans sortie déterministe n'est pas sauvée par un meilleur harness, et un harness sans contexte réel n'est pas sauvé par un meilleur prompt. La discipline est de construire vers l'extérieur et de garder chaque couche intérieure honnête.

La lignée de recherche : ReAct, Reflexion, évaluateur-optimiseur

L'article est franc que « loop engineering » est un nom de produit pour une direction de recherche qui accumule des résultats depuis 2022, et connaître la lignée est ce qui sépare la compréhension de l'idée de la répétition de l'article à la mode.

L'ancêtre direct est le motif ReAct (Reason plus Act), introduit en 2022 par Yao et collègues à partir de recherches liées à Princeton et Google. L'idée centrale était d'entrelacer des étapes de raisonnement avec des étapes d'action : penser, agir, observer, penser à nouveau, agir à nouveau. Cet entrelacement est la boucle de base que essentiellement tout agent de code moderne exécute encore. Un an plus tard, Reflexion (Shinn et collègues, 2023) a ajouté la mémoire et l'auto-critique — un Actor qui fait le travail, un Evaluator qui note le résultat, et une étape de Self-Reflection qui écrit une leçon verbale dans une mémoire épisodique que l'agent lit à sa prochaine tentative. Le guide de décembre 2024 d'Anthropic, « Building Effective Agents », a nommé deux motifs de plus : l'évaluateur-optimiseur (un modèle génère, un second vérifie contre des critères explicites, cyclant jusqu'à que l'évaluation passe) et l'orchestrateur-workers (un modèle central découpe une tâche en morceaux, en confie chacun à un worker au contexte propre, et combine les résultats).

La raison pour laquelle cette lignée importe à l'architecte honnête est que chacun de ces motifs est, au fond, une réponse différente à la même question : qu'est-ce qui compte comme « done », et qui le vérifie. ReAct boucle jusqu'à que le modèle décide de s'arrêter. Reflexion boucle jusqu'à que l'Evaluator passe. L'évaluateur-optimiseur boucle jusqu'à qu'un second modèle passe. La progression va vers un contrôle de moins en moins l'agent notant son propre devoir — et les boucles les plus fortes de l'article s'appuient sur un vérificateur déterministe partout où un existe, réservant le jugement du modèle aux parties qui ne peuvent vraiment se quantifier autrement.

L'anatomie d'une boucle à laquelle on peut se fier sans surveillance

Enlevez le branding, dit l'article, et une boucle réellement fiable tend à avoir la même poignée de composants : un objectif avec une condition de terminaison véritablement vérifiable ; un ensemble d'outils qui touche l'environnement réel (exécution de code, système de fichiers, terminal, test runner, linter) ; la gestion du contexte (parce que chaque itération ajoute à l'historique et qu'une fenêtre de contexte est de taille fixe) ; une logique explicite de terminaison et d'escalade (une vraie condition de succès, une vraie condition d'échec, un chemin pour remettre à un humain) ; et un traitement d'erreurs qui distingue un problème récupérable d'un blocage dur.

Le squelette en pseudocode que l'article offre vaut la lecture pour la ligne qui fait le vrai travail : if verifier.passes(state): return success(state). Presque chaque décision de conception intéressante en loop engineering est une décision sur cette ligne. Ce qui compte comme verifier.passes — une suite de tests qui passe, un lint propre, une approbation manuelle humaine — détermine si l'idée de « done » de la boucle signifie quelque chose. Comment compact fonctionne détermine si la boucle survit assez longtemps pour finir. Comment no_progress est détecté empêche un agent coincé de brûler silencieusement votre budget.

Les blocs avec lesquels les gens livrent réellement — automations, worktrees, skills, plugins et connecteurs via MCP, sub-agents, état externe — sont la version au niveau outil de la même idée. Celui qu'on sous-estime facilement est l'état externe : le modèle n'a pas de mémoire entre les exécutions, donc ce que la boucle a appris doit vivre quelque part de durable que la prochaine exécution relit elle-même. Ça a l'air trop simple pour compter, et pourtant c'est le même truc dont toute installation d'agent de longue durée finit par dépendre.

La terminaison est la chose la plus chère à faire mal

L'article nomme trois problèmes durs — gestion de contexte, terminaison et vérification — et est abrupt que la terminaison est sans doute l'erreur la plus chère à faire mal. Une boucle a besoin de plusieurs sorties indépendantes empilées : un vérificateur confirmant que l'objectif est atteint, un plafond dur d'itérations, un budget de tokens ou de temps, et une détection de non-progression qui attrape le cas où les dernières étapes ont produit la même erreur ou laissé l'état inchangé. Sans cet ensemble empilé de sorties, une boucle tourne indéfiniment ou s'arrête arbitrairement sur une supposition, et ni l'un ni l'autre n'est acceptable dans quelque chose conçu pour tourner sans surveillance.

[ORIGINAL DATA] The 21 papers formalisent cela comme la distinction entre une propriété affirmée et une propriété mesurée. Theorem 3 dit qu'une propriété est garantie exactement quand son mécanisme est implémenté et mesure. Pour une boucle, la propriété est « l'agent s'est arrêté pour la bonne raison », et le mécanisme est l'ensemble empilé de sorties — chacune un instrument de mesure. Une boucle avec seulement une sortie de vérificateur et aucune de budget n'a pas de mécanisme pour « l'agent est coincé », donc n'a aucune garantie de s'arrêter. Les modes d'échec que l'article liste — débordement et pourriture de contexte, boucles sans progression, mauvaise spécification de l'objectif (l'agent qui supprime un test échouant pour mettre CI au vert), succès halluciné, explosion de coût — se ramènent tous à la même correction : un contrôle déterministe, externe et réel à l'intérieur du cycle, pas la parole de l'agent.

Le cadrage de l'article sur la mauvaise spécification de l'objectif vaut d'être dégagé. Une boucle qui optimise un objectif mal spécifié poursuivra la mauvaise chose avec une réelle efficacité. Le cas manuel est un agent qui supprime un test échouant pour que son statut CI devienne vert — le proxy passe, l'objectif échoue. C'est la même raison pour laquelle nous refusons de promettre des résultats de token, wallet ou community-credit : Wallet & Token, Super App et Community Credit sont Roadmap 🔵, pré-revenu, soumis à la révision Howey, et toute boucle qui les « vérifie » contre un proxy vérifie le proxy, pas le résultat. L'architecte honnête nomme la maturité avant de nommer la boucle.

Vérification : le contrôle externe est le seul « done » honnête

Le troisième problème dur de l'article est la vérification, et c'est vraiment une question de confiance. Le standard d'or est la vérification déterministe — tests, type checkers, compilateurs, linters — parce qu'ils renvoient un succès ou échec objectif contre lequel le modèle ne peut pas argumenter. Un LLM agissant comme son propre juge est plus flexible et réellement nécessaire pour ce qui ne peut se vérifier mécaniquement, mais il est aussi plus manipulable, et un modèle notant le travail qu'il a lui-même produit est un contrôle structurellement faible. Les boucles les plus fortes s'appuient sur un vérificateur déterministe partout où un existe, et réservent le jugement du modèle aux parties d'une tâche qui ne peuvent vraiment se quantifier autrement.

C'est le même choix architectural derrière the Sisters et the Oracle ✅ chez Everythink. The Sisters produisent chacune un pronostic ; the Oracle ne demande pas à the Sisters si elles ont raison. Il normalise leurs probabilités en un ensemble calibré, trié descendant, avec l'entropie en nats, en exactement un endroit — parce qu'une propriété est garantie exactement quand son mécanisme est implémenté et mesure, et qu'un auto-rapport n'est pas une mesure. Le HAI Engine ✅ fait tourner ce motif en production depuis 2016. La leçon que le vocabulaire de loop engineering rattrape est que le vérificateur doit être en dehors de ce qu'il vérifie, ou il n'en est pas un.

Human-in-the-loop est un vrai motif, insiste l'article, pas un repli. L'agent tourne jusqu'à qu'il heurte une véritable ambiguïté ou une décision à enjeu réel, s'interrompt et attend une personne. C'est le bon choix chaque fois qu'une supposition erronée est chère à défaire — un changement de base de données de production, une décision face au client. Le mode d'échec est l'inverse des autres : interrompre si souvent que l'humain ne gagne réellement pas de temps à avoir un agent dans la boucle.

Comment ça se cartographie sur la topologie d'Everythink

Chez Everythink, le vocabulaire de loop engineering se cartographie sur une topologie plutôt que sur un seul agent. The space is the router : un réseau contient des communautés, une communauté contient des rooms, et la room est là où une requête est routée avant que quoi que ce soit réponde. Ce routage est une décision de terminaison prise avant que la boucle commence — il décide quelle fenêtre de contexte, quel vérificateur, quelles Sisters, quels outils s'appliquent à une requête donnée. Une boucle qui tourne dans la mauvaise room a le mauvais vérificateur par construction, et aucune quantité d'itération ne le corrigera, parce que la boucle mesure la mauvaise propriété.

Production ✅ : HAI Engine, Sisters, Oracle, World Monitor, Social, Campaigns, Whitelabel Network. Partial ⚠️ : Matchmaking, Marketplace, Calendar. Roadmap 🔵 : Wallet & Token, Super App, Community Credit — nommés comme Roadmap, jamais promus en silence, parce qu'une boucle qui vérifie une capacité Roadmap contre un proxy vérifie le proxy. Périmètre civil et défensif seulement : nous ne construisons pas de boucles dont la condition de terminaison est un résultat de targeting, et nous ne le ferons pas. Inclusion by design : une boucle qui ne marche que sur connexion rapide est une boucle avec une sortie de budget cachée, donc la topologie contourne la faible connectivité plutôt que d'échouer sur elle.

La souveraineté du client est l'autre moitié de la logique de terminaison. L'article est clair qu'une boucle ne supprime pas le jugement humain ; elle relocalise où il s'applique. Quelqu'un possède toujours l'objectif, la définition de done et l'appel final. Chez Everythink le propriétaire du réseau possède ça — votre réseau, votre marque, vos données, votre vérificateur. La boucle est le mécanisme ; le propriétaire est celui qui décide ce que « done » signifie et vérifie que le vérificateur le signifie aussi.

Points-clés

• La valeur d'une boucle est fixée par sa logique de terminaison et de vérification, non par la finesse d'un seul prompt.
• « Done » est une affirmation à vérifier par un contrôle externe déterministe à l'intérieur du cycle — pas l'auto-rapport de l'agent. C'est Theorem 3 : une propriété est garantie exactement quand son mécanisme est implémenté et mesure.
• Empilez les sorties : un vérificateur, un plafond dur d'itérations, un budget de tokens ou de temps, et une détection de non-progression. Une boucle à une sortie n'a pas de mécanisme pour les modes d'échec que les autres attrapent.
• La lignée de recherche — ReAct (2022), Reflexion (2023), l'évaluateur-optimiseur d'Anthropic (2024) — est une progression vers un contrôle de moins en moins l'agent notant son propre devoir.
• La mauvaise spécification de l'objectif est l'échec cher : une boucle qui optimise un proxy passera le proxy et échouera l'objectif. Nommez la maturité (Production ✅ / Partial ⚠️ / Roadmap 🔵) avant de nommer la boucle.
• The space is the router : le routage décide quel vérificateur s'applique avant que la boucle commence. Une boucle dans la mauvaise room a le mauvais vérificateur par construction.

Questions fréquentes

Loop engineering est-il juste un nouveau nom pour prompt engineering ?

Non. Prompt engineering optimise la formulation d'une seule instruction. Loop engineering conçoit le cycle qui prompte, vérifie, mémorise et réexécute un agent — et sa décision porteuse est la logique de terminaison et de vérification, non la formulation. L'article place loop engineering comme la couche extérieure, enveloppant prompt, context et harness engineering au lieu de les remplacer.

Qu'est-ce qui rend une boucle sûre à tourner sans surveillance ?

Un ensemble empilé de sorties indépendantes : un vérificateur déterministe confirmant l'objectif, un plafond dur d'itérations, un budget de tokens ou de temps, et une détection de non-progression. Sans les quatre, une boucle tourne indéfiniment, s'arrête sur une supposition ou brûle silencieusement des ressources dans une impasse. L'article est explicite : la terminaison est la chose la plus chère à faire mal.

Comment ça se relie à Theorem 3 ?

Theorem 3 dit qu'une propriété est garantie exactement quand son mécanisme est implémenté et mesure. Pour une boucle d'agent, la propriété est « done », et le mécanisme est le vérificateur déterministe à l'intérieur du cycle. Une boucle sans sortie qui mesure produit des affirmations de travail fini, pas du travail fini — c'est le mode d'échec « succès halluciné » de l'article.

Une boucle supprime-t-elle l'humain du processus ?

Non. L'article est clair qu'une boucle relocalise le jugement humain au lieu de le supprimer. Quelqu'un possède toujours l'objectif, la définition de done et l'appel final. Human-in-the-loop est un vrai motif pour les décisions à enjeu réel ; le mode d'échec est d'interrompre si souvent que l'humain ne gagne pas de temps.

Où Everythink utilise-t-il ça ?

The Sisters et the Oracle ✅ font tourner le même motif : the Oracle ne demande pas à the Sisters si elles ont raison — il normalise leurs probabilités en un ensemble calibré en exactement un endroit. Le HAI Engine ✅ fait tourner ça en production depuis 2016. The space is the router : le routage décide quel vérificateur s'applique avant que la boucle commence.

Si vous concevez un réseau où des agents autonomes doivent s'arrêter pour la bonne raison, la topologie doit router avant que quoi que ce soit réponde. Créez votre réseau — the space is the router, et le vérificateur est le vôtre.

Sources

• Shittu Olumide, « An Introduction to Loop Engineering », MachineLearningMastery, 23 juillet 2026 — https://machinelearningmastery.com/an-introduction-to-loop-engineering
• Yao et al., « ReAct: Synergizing Reasoning and Acting in Language Models », 2022 — https://arxiv.org/abs/2210.03629
• Shinn et al., « Reflexion: Language Agents with Verbal Reinforcement Learning », 2023 — https://arxiv.org/abs/2303.11366
• Anthropic, « Building Effective Agents », décembre 2024 — https://www.anthropic.com/engineering/building-effective-agents
• Addy Osmani, « Loop Engineering », 8 juin 2026 — https://addyosmani.com/blog/loop-engineering/