Le Guide Complet du Loop Engineering

Au début du mois de juin 2026, une phrase a fait le tour de l'écosystème de l'IA générative. Peter Steinberger, développeur connu pour son outillage autour des agents de code, l'a publiée sur X : « You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents » — vous ne devriez plus prompter les agents de code, vous devriez concevoir les boucles qui les prompteront à votre place. Quelques jours plus tôt, lors de l'événement Acquired Unplugged organisé par WorkOS, Boris Cherny, le créateur de Claude Code chez Anthropic, avait formulé la même idée d'une manière devenue immédiatement virale : « I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops » — je ne prompte plus Claude, j'ai des boucles qui tournent et qui se chargent de prompter Claude et de décider quoi faire ; mon travail consiste à écrire des boucles.

Entre ces deux déclarations, un terme s'est cristallisé pour nommer ce déplacement : le Loop Engineering. Le 7 juin 2026, Addy Osmani — ingénieur de longue date chez Google, connu pour son travail sur l'expérience développeur — a publié l'article fondateur qui lui a donné sa définition canonique. C'est ce texte, relayé presque immédiatement par Business Insider, LangChain, Cobus Greyling et une série de vidéos pédagogiques, qui a transformé une intuition de praticiens en un véritable paradigme nommé.

Cet article a une ambition simple : donner une compréhension complète du Loop Engineering — d'où il vient, ce qu'il est exactement, comment il fonctionne, et pourquoi il représente sans doute la prochaine grande étape dans notre manière de travailler avec les agents IA. Il prolonge directement deux paradigmes que nous avons déjà cartographiés : le Context Engineering et le Harness Engineering, dont le Loop Engineering constitue l'étage supérieur.

Une définition précise (et son piège)

Le Loop Engineering est la pratique qui consiste à concevoir le système — la boucle — qui prompte un agent IA à votre place, au lieu de le prompter vous-même tour après tour. La boucle découvre le travail à faire, le délègue à des agents, vérifie les résultats, persiste l'état et décide de l'action suivante, jusqu'à atteindre un objectif. C'est un déplacement du travail humain : on cesse d'écrire des prompts pour écrire les boucles qui les produisent.

Commençons par la définition la plus citée, celle d'Addy Osmani : « Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. » Le Loop Engineering, c'est se remplacer soi-même en tant que personne qui prompte l'agent ; on conçoit à la place le système qui s'en charge. Osmani précise immédiatement la nature de ce système : « A loop here can be thought of a recursive goal where you define a purpose and the AI iterates until complete » — une boucle est ici un objectif récursif : on définit un but, et l'IA itère jusqu'à ce qu'il soit atteint.

Cobus Greyling, dans son article du 9 juin 2026, donne la formulation opérationnelle la plus complète : le Loop Engineering est le passage d'une situation où vous êtes celui qui prompte l'agent de code tour après tour, à une situation où vous concevez un système — la boucle — qui découvre le travail à faire, distribue les tâches à des agents (souvent des sous-agents), vérifie les résultats, persiste l'état et décide de l'action suivante, le tout sur un rythme (une cadence) ou jusqu'à ce qu'un objectif soit atteint.

Le piège est de croire que le mot « boucle » désigne ici une simple répétition mécanique. Ce n'est pas le cas. Une boucle, au sens du Loop Engineering, est un système qui contient au minimum cinq éléments — un déclencheur, une action, une preuve, une mémoire et une condition d'arrêt — et qui possède un trait que le prompt n'a jamais eu : il s'améliore à chaque exécution. C'est cette différence, et non la répétition, qui fait tout l'intérêt du concept.

Loop Engineering, crash-loop-back-off ou Microsoft Loop ?

Une précision de vocabulaire s'impose, car le mot « loop » est surchargé — et les données de recherche le confirment. Sur les requêtes contenant « loop », le bruit homonyme domine : le « crash loop back-off » de Kubernetes capte de loin la majorité des impressions, loin devant les recherches liées aux agents IA. Microsoft Loop, l'outil de collaboration, ajoute sa part de confusion.

Mettons donc les choses au clair une fois pour toutes. Le Loop Engineering n'a rien à voir avec le crash loop back-off de Kubernetes (un pod qui redémarre en boucle après un échec de démarrage), ni avec Microsoft Loop (l'outil de collaboration de Microsoft), ni avec l'event loop de JavaScript, ni avec la game loop d'un moteur de jeu. Lorsque nous parlons de boucles ici, il s'agit exclusivement de boucles agentiques : des systèmes qui pilotent des agents IA de manière itérative, avec un objectif et une condition d'arrêt. Cette homonymie n'est pas anecdotique : elle explique pourquoi le terme, pourtant forgé en juin 2026, peine à émerger dans un océan de résultats qui n'ont aucun rapport.

D'où vient le Loop Engineering : une généalogie

Le Loop Engineering n'est pas apparu de nulle part. Il est le dernier maillon d'une chaîne de paradigmes qui se sont succédé à un rythme de plus en plus rapide depuis 2022, à mesure que l'on apprenait à mieux exploiter les grands modèles de langage. Comprendre cette généalogie est essentiel, car elle révèle une logique : à chaque étape, le point de levier — l'endroit où l'effort humain produit le plus d'effet — s'est déplacé d'un cran vers le haut, vers plus d'abstraction et plus d'autonomie.

La première brique théorique est l'article ReAct (« Synergizing Reasoning and Acting in Language Models »), publié en 2022 par des chercheurs de Princeton et de Google Research. ReAct a montré qu'un modèle pouvait alterner raisonnement et action dans une boucle, observant le résultat de chaque action avant de décider de la suivante. C'est l'ancêtre conceptuel direct de toutes les boucles agentiques d'aujourd'hui : l'idée que l'intelligence d'un agent ne réside pas dans une réponse unique, mais dans un cycle pensée-action-observation répété.

Puis vint l'ère du prompt engineering, qui a culminé en 2023. Pendant un temps, savoir formuler le prompt parfait était une compétence parmi les plus recherchées du marché. Mais à mesure que les modèles devenaient meilleurs pour deviner l'intention de l'utilisateur, la valeur du prompt isolé s'est érodée — au point que, dès 2025, plusieurs observateurs annonçaient l'obsolescence du métier de « prompt engineer ».

Un nouveau terme a ensuite pris le relais : le context engineering. Ce qui compte n'est plus la formulation magique du prompt, mais l'ensemble du contexte que l'on fournit au modèle — documents, exemples, mémoire persistante, état. Chez SFEIR, nous l'avons défini comme « l'art de nourrir les agents IA » : le passage d'une interaction isolée à mémoire éphémère (le prompt, au ROI linéaire) à un environnement global à mémoire persistante cross-sessions, au ROI composé. Puis est venue l'ingénierie du harnais (harness engineering), que résume l'équation « Agent = Model + Harness » : configurer l'environnement complet dans lequel un agent s'exécute — ses outils, ses permissions, ses garde-fous, ses capteurs — peut faire gagner plus de vingt points de performance à modèle constant.

Le Loop Engineering est l'étape suivante, et Osmani la situe précisément : il se trouve « one floor above the harness » — un étage au-dessus du harnais. Sa formule est limpide : « The harness but it runs on a timer, it spawns little helpers, and it feeds itself » — le harnais, mais qui tourne sur une horloge, qui engendre de petits assistants, et qui se nourrit lui-même. Cobus Greyling résume la séquence d'une phrase : on se souvient quand le context engineering était nouveau, puis le harness engineering, et maintenant nous avons le Loop Engineering.

Ce qui frappe dans cette généalogie, c'est sa vitesse. Quatre paradigmes en trois ans. Et à chaque fois, le même mouvement : le développeur recule d'un cran, abandonne une tâche manuelle à la machine, et se réinvestit dans la conception du système qui exécute cette tâche. Comme le résume Osmani à propos de Cherny : l'idée n'est pas que le travail soit devenu plus facile ; c'est que le point de levier s'est déplacé.

Comment fonctionne une boucle : l'anatomie en cinq parties

Une boucle de Loop Engineering se décompose en cinq éléments invariants : un déclencheur, une action, une preuve, une mémoire et une condition d'arrêt. Cette structure n'est pas une convention arbitraire : plusieurs praticiens majeurs — Shubham Saboo pour les Product Managers, Matthew Berman dans sa Loop Library, Claire Vo dans son émission « How I AI » — y sont arrivés indépendamment. C'est le signe d'une convergence réelle, pas d'un effet de mode.

Une boucle utile spécifie ces cinq choses : un déclencheur (trigger) qui dit quand la boucle démarre ; une action qui dit ce que l'agent doit faire ; une preuve (proof) qui établit comment on sait que le résultat est meilleur ; une mémoire qui détermine où l'apprentissage est sauvegardé pour l'itération suivante ; et une condition d'arrêt (stop condition) qui dit quand la boucle doit se terminer.

C'est ce dernier élément qui compte le plus avec les boucles récursives. Comme l'observe Shubham Saboo, beaucoup de systèmes IA n'échouent pas parce que le modèle est mauvais ; ils échouent parce que la boucle n'a pas de sortie propre. L'agent continue de générer, il étend la portée du projet, il invente du travail. Une bonne boucle doit pouvoir dire « stop » : rien de significatif n'a changé, l'entrée est trop maigre, c'est bloqué, le niveau de qualité n'a pas été atteint, ou une décision humaine est requise. Une boucle qui sait dire « stop » est une boucle que vous pouvez laisser tourner ; une boucle qui ne le sait pas est une boucle que vous devez surveiller en permanence. Chacun de ces cinq blocs se relie aux primitives techniques recensées par Osmani : automatisations, worktrees Git, skills, connecteurs, sous-agents, et mémoire persistante.

L'écosystème des boucles : du loopcraft aux outils natifs

Le Loop Engineering ne s'arrête pas à la conception d'une boucle isolée. Très vite, les praticiens ont compris qu'on pouvait empiler les boucles — une pratique que swyx, du podcast Latent Space, a baptisée le loopcraft, « l'art d'empiler les boucles ». LangChain a formalisé cette idée dans un article du 16 juin 2026 décrivant quatre niveaux : la boucle de l'agent (qui automatise le travail), la boucle de vérification (qui garantit la qualité), la boucle événementielle (qui automatise le travail à grande échelle) et la boucle d'ascension ou hill-climbing (qui automatise l'amélioration elle-même). Monter d'un étage, c'est passer d'une boucle qui fait le travail à une boucle qui améliore la boucle — c'est là que le loopcraft devient une véritable architecture.

Parallèlement, des outils ont intégré nativement ces concepts. Claude Code est aujourd'hui le précurseur, avec des primitives pensées spécifiquement pour le Loop Engineering : la commande /loop, qui relance un prompt sur un intervalle ; la commande /goal, qui poursuit le travail jusqu'à ce qu'une condition vérifiable soit atteinte ; les tâches planifiées (scheduled tasks) ; les skills décrits dans des fichiers SKILL.md ; les worktrees Git pour le travail parallèle ; et les sous-agents. C'est dans cet univers qu'est née la fameuse boucle « Ralph Wiggum », une technique aussi rustique qu'efficace inventée par Geoffrey Huntley : relancer le même prompt en boucle jusqu'à ce que le travail soit fait. Ces outils natifs concentrent d'ailleurs la demande la plus concrète sur le sujet : « qu'est-ce qu'une loop dans Claude Code », « comment l'utiliser », « comment l'arrêter », « quelle différence entre /loop et une tâche planifiée » sont parmi les questions les plus fréquemment posées.

Qui est concerné : pas seulement les développeurs

On aurait tort de croire que le Loop Engineering est une affaire de développeurs. Shubham Saboo, Senior AI PM chez Google Cloud, a montré de façon convaincante que la prochaine compétence des Product Managers n'est pas le prompt engineering mais la conception de boucles. Pour un PM, une boucle ne part pas du code mais des artefacts qui façonnent le travail produit : une skill de revue de PRD, un résumeur d'appels clients, une grille d'évaluation, une checklist de lancement. Claire Vo, fondatrice de ChatPRD, le formule avec humour : si vous avez déjà utilisé une tâche planifiée dans un agent, vous avez déjà écrit une boucle. Le Loop Engineering, dit-elle, consiste simplement à rappeler qu'il n'est pas nécessaire d'utiliser vos doigts humains pour taper un prompt afin que votre agent travaille pour vous.

Le revers de la médaille : ce qui rend les boucles dangereuses

Le Loop Engineering n'est pas une formule magique, et les sources les plus sérieuses insistent sur ce point. Contrairement à une idée reçue, concevoir une boucle est plus difficile que d'écrire un prompt, pas plus facile : cela demande un véritable jugement système. Osmani identifie trois dettes qui s'aggravent à mesure que la boucle s'améliore. La vérification reste à votre charge : « a loop running unattended is also a loop making mistakes unattended » — une boucle qui tourne sans surveillance est aussi une boucle qui commet des erreurs sans surveillance ; et « 'done' is a claim and not a proof » — « terminé » est une affirmation, pas une preuve. La dette de compréhension : plus la boucle livre vite du code que vous n'avez pas écrit, plus l'écart se creuse entre ce qui existe et ce que vous comprenez. Et la reddition cognitive : quand la boucle tourne seule, il est tentant de cesser d'avoir un avis et de prendre simplement ce qu'elle vous rend.

À cela s'ajoute le poste de coût le plus visible : les tokens. L'usage combiné de sous-agents et de boucles fréquentes fait exploser la consommation. Selon les données d'Anthropic sur les systèmes multi-agents, ceux-ci consomment de l'ordre de quinze fois plus de tokens qu'une conversation classique. Plusieurs praticiens ont rapporté des factures conséquentes après un week-end d'exécution autonome laissée sans surveillance — un risque à traiter comme un enjeu FinOps à part entière, comme pour tout agentic coding.

Par où commencer : cinq leviers pour rester l'ingénieur

Adopter le Loop Engineering ne se décrète pas ; cela se construit, et toujours dans le bon ordre. Voici cinq leviers d'action concrets, du plus prudent au plus engageant.

Commencez par la condition d'arrêt, pas par l'action. La tentation est d'écrire d'abord ce que l'agent doit faire. C'est l'inverse qui produit des boucles fiables : définissez d'abord ce qui doit faire cesser la boucle — qualité atteinte, entrée trop maigre, décision humaine requise. Une boucle sans sortie propre est une boucle qu'on ne peut pas laisser tourner.

Rendez la preuve vérifiable par la machine, jamais par déclaration. « Terminé » n'est pas une preuve : exigez un test qui passe, une métrique qui bouge, une grille remplie. Le bloc « preuve » est le point où le jugement humain reste maître, car c'est lui qui distingue une boucle qui s'améliore d'une boucle qui s'emballe. C'est exactement le déplacement que connaît déjà la revue de code, du créateur au vérificateur.

Versionnez vos boucles comme du code. Une boucle, c'est un artefact : skill, prompt, grille d'évaluation, condition d'arrêt. Le mettre sous contrôle de version, le faire relire, l'évaluer sur des cas connus — c'est ce qui transforme une astuce personnelle en pratique d'équipe reproductible.

Budgétez les tokens avant de lancer en autonomie. Une boucle laissée seule sur un week-end peut multiplier la facture. Posez un plafond, un horaire, une alerte — la même discipline FinOps que pour n'importe quel usage d'agents.

Gardez une boucle de relecture humaine au-dessus de tout. Plus la boucle livre vite, plus la compréhension devient le goulot d'étranglement. Conservez un rituel où un humain comprend, conteste et valide ce que la boucle produit. L'essentiel à retenir : le Loop Engineering n'est pas une astuce de productivité, c'est un déplacement du point où s'exerce votre jugement. On ne cesse pas de penser ; on pense un cran plus haut.

La synthèse : ce que devient le travail

Si l'on devait résumer le Loop Engineering en une idée, ce serait celle-ci : la génération est résolue, le jugement reste humain. Shubham Saboo le formule ainsi : « Generation is solved with AI Agents. Loop Engineering can produce infinitely. Verification and judgment are all that's left » — la génération est résolue par les agents IA, le Loop Engineering peut produire à l'infini, la vérification et le jugement sont tout ce qu'il reste.

Le travail ne disparaît pas ; il se déplace. Il ne consiste plus à écrire le code ni même à écrire le prompt, mais à concevoir, versionner, évaluer et surveiller les boucles qui rendent le jugement reproductible. Osmani livre la maxime qui devrait guider toute cette pratique : « Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go » — construisez la boucle, mais construisez-la comme quelqu'un qui a l'intention de rester l'ingénieur, et non d'être seulement la personne qui appuie sur « démarrer ».

Chez SFEIR, nous lisons ce déplacement dans la continuité de notre cap « AI for IT — la stratégie du 10x » : viser une productivité multipliée par dix suppose précisément de cesser de produire du code à la main pour outiller, à un cran d'abstraction supérieur, les systèmes qui le produisent. Le Loop Engineering est l'expression la plus avancée de ce mouvement amorcé avec le context engineering puis le harness engineering. Mais il n'a de valeur que si l'ingénieur reste aux commandes du jugement. La phrase de Cherny par laquelle nous avons commencé — « mon travail consiste à écrire des boucles » — n'annonce pas la disparition de l'ingénieur. Elle décrit son élévation : non plus celui qui tape le prompt, mais celui qui conçoit la machine à juger, et qui reste responsable de ce qu'elle juge.

Pour aller plus loin

Ce guide pose le cadre ; six articles approfondissent chacun une facette du Loop Engineering.

• Pourquoi le Prompt Engineering est mort (vive le Loop Engineering) — le paradigme qui se referme et celui qui le remplace : pourquoi le prompt, qui s'accomplit une fois, cède la place à la boucle, qui s'améliore, et ce qui survit malgré tout de l'art du prompt.
• L'anatomie d'une loop : les 5 blocs fondamentaux — le how-to qui détaille déclencheur, action, preuve, mémoire et condition d'arrêt, puis les met en regard des primitives techniques (worktrees, skills, sous-agents).
• Loopcraft : l'art de combiner les boucles IA — l'étage architectural : empiler les quatre boucles (agent, vérification, événementielle, ascension) et distinguer le harnais de la boucle.
• Les outils natifs du Loop Engineering dans Claude Code — la mise en pratique outillée : les commandes /loop et /goal, les tâches planifiées et la fameuse boucle Ralph Wiggum.
• Loop Engineering pour les Product Managers — la transposition hors-développement : signal produit hebdomadaire, evals comme travail de PM, dépôt versionné comme mémoire du produit.
• Les limites, coûts et défis du Loop Engineering — le contrepoids honnête : explosion des tokens, boucles infinies, autonomie prématurée et paradoxe de Jevons, avec leurs garde-fous.

Questions fréquentes sur le Loop Engineering

Le Loop Engineering rend-il le travail plus facile ? Non, c'est l'inverse. Concevoir une boucle fiable — choisir le bon déclencheur, écrire une preuve vérifiable, dimensionner une condition d'arrêt, anticiper les modes d'échec — réclame davantage de jugement système qu'écrire un prompt. Le paradigme n'offre pas la facilité, mais le levier : un même effort de conception produit des centaines d'exécutions au lieu d'une seule.

Faut-il encore comprendre le code si une boucle le produit ? Oui, et plus que jamais. Plus une boucle livre vite, plus la compréhension devient le goulot d'étranglement. Une boucle dont personne ne relit le travail accumule ce qu'Osmani nomme une dette de compréhension, qui se rembourse toujours, généralement au pire moment. La maîtrise technique change de fonction : elle passe de l'écriture à la vérification.

Le Loop Engineering est-il réservé aux développeurs ? Non. Product Managers, analystes et responsables d'opérations construisent des boucles légitimes à partir d'artefacts non logiciels — grilles d'évaluation, checklists, gabarits de synthèse. C'est une compétence de conception de systèmes qui rendent un jugement reproductible, qu'il soit technique, produit, éditorial ou opérationnel.

Quelle différence entre une boucle et une tâche planifiée ? Une tâche planifiée déclenche une action à un moment donné ; c'est l'un des déclencheurs possibles d'une boucle, pas la boucle elle-même. Une boucle de Loop Engineering ajoute à ce déclencheur une preuve, une mémoire qui persiste l'apprentissage entre exécutions, et une condition d'arrêt — elle s'améliore à chaque tour, là où une simple tâche planifiée se contente de répéter.

Comment arrêter une boucle qui s'emballe ? En l'ayant conçue pour s'arrêter d'elle-même : une condition d'arrêt explicite (qualité atteinte, entrée trop maigre, plafond de tokens, décision humaine requise) est le premier garde-fou. À défaut, gardez toujours un plafond de coût et une boucle de relecture humaine au-dessus du système.

Points clés

• Le Loop Engineering, c'est concevoir le système qui prompte un agent IA à votre place — la boucle découvre le travail, le délègue, vérifie, persiste l'état et décide de l'action suivante jusqu'à un objectif.
• Il prolonge une généalogie rapide : prompt → context → harness → loop. Le loop se situe « un étage au-dessus du harnais » (Osmani, juin 2026).
• Une boucle a cinq blocs invariants : déclencheur, action, preuve, mémoire, condition d'arrêt. C'est la condition d'arrêt qui distingue une boucle exploitable d'une boucle à surveiller.
• Ne pas confondre avec les homonymes : le Loop Engineering n'a aucun rapport avec le crash loop back-off de Kubernetes ni avec Microsoft Loop.
• Le coût est réel : les systèmes multi-agents consomment de l'ordre de quinze fois plus de tokens qu'une conversation classique (Anthropic) — à budgéter avant toute exécution autonome.
• La génération est résolue, le jugement reste humain : « terminé » est une affirmation, pas une preuve. Construire la boucle « comme quelqu'un qui a l'intention de rester l'ingénieur » (Osmani).

Sources

1. Addy Osmani — Loop Engineering — addyosmani.com, 7 juin 2026.
2. Business Insider — Forget prompt engineering: 'Loop engineering' is all the rage now — businessinsider.com, juin 2026.
3. Cobus Greyling — Loop Engineering — cobusgreyling.substack.com, 9 juin 2026.
4. LangChain — The Art of Loop Engineering — langchain.com, 16 juin 2026.
5. Boris Cherny — Claude Code & the Future of Engineering (Acquired Unplugged, WorkOS) — youtube.com, juin 2026.
6. Peter Steinberger — citation publique « designing loops that prompt your agents », X, juin 2026.
7. swyx (Latent Space) — « loopcraft », 2026.
8. ReAct — Yao, Narasimhan et al., Princeton & Google Research, 2022.
9. Anthropic — données multi-agents (~15× tokens), 2026.
10. SFEIR — Context Engineering, matière first-party, 2026.
11. SFEIR — Harness Engineering, matière first-party, 2026.
12. SFEIR — AI for IT — la stratégie du 10x, matière first-party, 2026.