Loop Engineering : mode passagère ou prochain saut ?

À la mi-juin, un post de Peter Steinberger, développeur connu pour avoir construit puis vendu PSPDFKit, circule pendant des semaines parmi les initiés : on ne prompte plus les agents IA, on conçoit les boucles (loops) qui les font tourner. Quelques lignes, un ton de révélation, et en l'espace de quelques jours, le terme "loop engineering" apparaît partout, d' Analytics Vidhya aux blogs d'entreprises spécialisées dans les infrastructures pour agents comme Requesty. Même Boris Cherny, parmi les architectes de Claude Code, en rajoute une couche en parlant d'un saut comparable à celui du code source compilé aux agents autonomes, comme le raconte BDTechTalks en reconstituant la genèse du débat.

Cela sonne familier. Au cours des trois dernières années, le secteur a déjà traversé le même rite presque tous les six mois : prompt engineering, puis context engineering, puis harness engineering, chaque fois avec l'annonce d'un changement de paradigme. La question honnête à se poser n'est pas de savoir si le loop engineering existe — il existe, les outils qui l'implémentent concrètement le prouvent — mais s'il représente réellement un saut conceptuel ou s'il s'agit du dernier chapitre d'une histoire plus longue, racontée chaque fois sous un nouveau nom.

Du prompt au système

Pour comprendre ce qui change, il faut reconstruire la séquence. Le prompt engineering, entre 2022 et 2023, concernait la formulation de l'instruction unique, le choix des mots, la structure du contexte immédiat pour obtenir une meilleure réponse d'un modèle encore relativement myope. Avec l'allongement des fenêtres de contexte et l'apparition des premiers agents capables d'utiliser des outils, l'attention s'est déplacée vers le context engineering, c'est-à-dire ce qu'il faut mettre dans cette fenêtre, quels documents récupérer, comment organiser la mémoire, quels outils rendre disponibles à un moment donné.

L'étape suivante, celle que BDTechTalks décrit dans son article sur l' harness engineering de début juin, concerne l'échafaudage autour du modèle, le fameux harness — l'ensemble des outils, permissions, sandboxes et règles qui transforment un modèle linguistique en un agent capable d'opérer sur un environnement réel sans surveillance constante. C'est ici que la comparaison avec l'anatomie devient utile : si le modèle est le cerveau, le harness est le corps qui lui permet d'agir dans le monde.

Le loop engineering, dans cette progression, déplace encore plus le barycentre. Il ne s'agit plus seulement de ce que le modèle sait ou de ce avec quoi il peut interagir, mais de la façon dont le cycle d'exécution se répète dans le temps, quand il s'arrête, qui vérifie le résultat avant qu'il ne soit considéré comme définitif. C'est la différence entre construire un bon outil et construire le processus qui décide quand cet outil a fini son travail. Requesty, dans un guide pratique destiné à ceux qui construisent des agents en production, distingue quatre variantes opérationnelles : les boucles à battement continu pour la surveillance, les boucles planifiées sur une base temporelle pour les tâches récurrentes, les boucles déclenchées par des événements externes comme un push sur un dépôt, et les boucles orientées vers un objectif qui ne s'arrêtent qu'une fois une condition de succès explicite atteinte ; voir leur aperçu sur les types de boucles.

Le barycentre se déplace donc réellement du contenu du prompt vers le système de contrôle qui l'entoure. Il reste cependant à se demander si ce déplacement mérite une étiquette propre ou s'il est simplement l'évolution naturelle, presque inévitable, du chemin déjà tracé par l'harness engineering.

Il n'est pas né d'hier

Ici, il vaut la peine de ralentir, car c'est le point où l'enthousiasme du moment risque de faire perdre la mémoire technique. L'idée d'un système qui génère une tentative, l'observe, la corrige et réessaie n'est pas née avec les agents LLM de 2026. Le pattern ReAct, publié par un groupe de recherche de Princeton et Google en 2022, formalisait déjà le cycle de raisonnement et d'action entrelacés que beaucoup appellent aujourd'hui simplement "la boucle". L'année suivante, Reflexion ajoutait un niveau d'autocritique verbale, l'agent relisant sa propre erreur et la transformant en leçon pour la tentative suivante. Et la séparation entre celui qui génère une solution et celui qui la vérifie, le pattern dit maker-checker, est un principe de génie logiciel aussi vieux que la revue de code elle-même, bien avant que quiconque ne pense à l'appliquer à un modèle linguistique.

Même la littérature plus récente confirme la continuité plutôt que la rupture. Un travail de 2024 de l'université Tsinghua propose un framework de raffinement itératif de l'expérience pour les agents qui développent des logiciels, dans lequel l'agent accumule et filtre progressivement ses propres expériences passées au fil des cycles successifs — une architecture conceptuellement proche de nombreuses boucles actuelles, publiée alors que le terme "loop engineering" n'avait pas encore été inventé, comme on peut le lire dans l' article original.

Il y a une image qui rend bien l'idée, empruntée à un domaine éloigné de l'informatique. Dans le jeu vidéo d'enquête The Forgotten City, le protagoniste revit la même journée des dizaines de fois, non pas pour subir le temps qui se répète comme une punition mais pour l'utiliser ; chaque cycle affine la compréhension d'un mystère qui, au premier tour, semblait insoluble. Ce n'est pas un hasard si Douglas Hofstadter, dans Gödel, Escher, Bach, avait déjà donné un nom philosophique à cette idée : la "boucle étrange" (strange loop), un cycle qui, en revenant sur lui-même, produit un niveau de compréhension plus élevé que celui dont il était parti. Le loop engineering, au fond, essaie de faire la même chose avec le code, à la différence que pour boucler la boucle, ce n'est plus seulement l'intuition humaine qui intervient, mais un second agent qui fait office de contrôleur.

Alors, qu'est-ce qui est vraiment nouveau ? Pas la théorie, qui plonge ses racines dans des années de recherche sur les agents et les systèmes multi-agents. Ce qui est nouveau, c'est la systématisation pratique, l'apparition de commandes dédiées comme /loop dans Claude Code ou les automatisations récurrentes dans Codex, qui rendent un pattern autrefois artisanal enfin composable et réutilisable à l'échelle, comme le confirme également l'analyse technique publiée par max-gherman.dev sur l'anatomie des boucles modernes. C'est la différence, déjà apparue lors d'une conversation précédente sur ce même article, entre une révolution théorique et une maturation technique — moins spectaculaire à annoncer, probablement plus utile à posséder. Schéma conceptuel du Loop Engineering

Qui gagne, qui risque

Où cette approche fonctionne-t-elle vraiment ? Les exemples les plus solides proviennent de tâches ayant un critère de succès objectif et vérifiable mécaniquement : l'agent qui corrige le code jusqu'à ce que la suite de tests passe, celui qui surveille les logs de production et ouvre un ticket lorsque le taux d'erreur dépasse un seuil, celui qui révise les pull requests vieilles de quelques jours en signalant les blocages aux auteurs. Dans ces cas, la boucle a un arbitre clair — le test qui passe ou échoue, le nombre qui dépasse ou non le seuil — et la vérification ne nécessite pas de jugement humain en temps réel.

Le problème commence quand cet arbitre manque ou est faible. Si le critère de succès est vague — "le rapport est assez bon", "l'analyse est complète" — la boucle risque ce que l'analyse technique de max-gherman.dev appelle l'approbation hallucinée : un second agent qui déclare terminé un travail seulement partiellement fait parce que son propre jugement n'est ancré dans rien de vérifiable mécaniquement. Requesty, dans son propre guide opérationnel, énumère les mêmes risques sous d'autres noms : la fuite incontrôlée d'itérations sans plafond maximum, la dégradation du contexte dans les boucles très longues, l'amnésie d'état lorsque l'agent perd la trace de ce qu'il a déjà traité entre un cycle et l'autre.

Qui gagne dans ce scénario ? Probablement les équipes confrontées à des tâches répétitives et bien définies, disposant d'un budget pour expérimenter l'infrastructure nécessaire : revue automatique du code, surveillance continue, extraction de données à grande échelle. Les fournisseurs d'infrastructure gagnent aussi — passerelles de routage de modèles, plateformes d'orchestration — qui trouvent dans le loop engineering un nouveau vocabulaire pour vendre un problème en réalité déjà existant : celui de gérer en toute sécurité et avec des coûts prévisibles un nombre d'appels au modèle qui croît de plusieurs ordres de grandeur par rapport à un simple chat. Ceux qui risquent le plus sont les équipes qui importent l'enthousiasme sans l'infrastructure de vérification sous-jacente, convaincues qu'il suffit d'ajouter un cycle de répétition à un prompt déjà fragile pour obtenir une fiabilité qui n'existait pas auparavant. Une boucle autour d'un mauvais critère de succès ne produit pas un meilleur résultat ; elle ne produit qu'une erreur répétée avec plus d'assurance.

Le compte en tokens

La dernière question, peut-être la plus concrète pour ceux qui doivent décider d'investir ou non du temps dans cette approche, concerne le rapport entre la qualité gagnée et les ressources consommées. Une boucle n'est pas gratuite : chaque itération est un nouvel appel au modèle, souvent plus d'un si le cycle prévoit un générateur et un vérificateur séparés ou plusieurs agents spécialisés qui se partagent le travail. Requesty estime qu'une boucle de révision quotidienne avec plusieurs sous-agents peut coûter des dizaines de dollars par jour au prix fort sur les modèles les plus puissants — un chiffre qui baisse sensiblement en ne routant que les étapes nécessitant réellement un raisonnement avancé vers les modèles les plus chers, et en déléguant la classification et l'écrémage à des modèles plus économiques, comme décrit dans leur analyse sur les coûts de routage.

Cela soulève une question que l'enthousiasme général a tendance à laisser au second plan : que vaut réellement une itération de plus ? Si la deuxième tentative de la boucle corrige une erreur qui, autrement, aurait fini en production, le coût est probablement bien investi ; si, en revanche, le cycle continue de tourner en produisant des variations marginales d'un résultat déjà acceptable dès la première tentative, il s'agit d'une dépense qu'aucun tableau de bord de coûts ne justifie a posteriori. La mesure sérieuse de la valeur d'une boucle n'est donc pas le nombre d'itérations qu'elle effectue, mais à quel point elle améliore réellement le résultat par rapport au coût marginal de chaque cycle supplémentaire — un calcul que trop d'articles enthousiastes sur le sujet ne font tout simplement pas.

Une discipline de contrôle, pas une nouvelle intelligence

Pour en revenir à la question d'ouverture, le loop engineering mérite-t-il l'attention qu'il reçoit ? La réponse honnête est oui, avec un préalable qui redimensionne la portée de l'annonce. Nous n'assistons pas à la découverte d'un nouveau principe ; le cycle générer-vérifier-corriger était déjà écrit dans les articles sur les agents de 2022 et même plus tôt dans les pratiques de génie logiciel traditionnelles. Ce qui est en train de mûrir effectivement, c'est la capacité de rendre ce principe opérationnel à l'échelle, avec des outils natifs, un état persistant hors contexte, un routage des coûts et des critères d'arrêt plus rigoureux qu'un simple jugement subjectif.

Il vaut la peine de se demander, alors, si dans un an on parlera encore de loop engineering comme d'une catégorie en soi, ou si le terme sera simplement absorbé par le vocabulaire ordinaire de l'ingénierie des agents — tout comme aujourd'hui plus personne ne parle de prompt engineering comme d'une discipline séparée, mais le considère comme acquis dans chaque conversation technique. C'est peut-être là le destin le plus probable du loop engineering : non pas une révolution dont on se souviendra, mais une pièce du puzzle qui, dans quelques mois, n'aura plus besoin d'un nom propre pour être pratiquée.