Boucles plutôt que requêtes : ce qu'est l'ingénierie des boucles pour agents

L'ingénierie des requêtes consiste à rédiger une consigne initiale aussi parfaite que possible, à l'envoyer vers un grand modèle de langage, puis à attendre la réponse avant de formuler la consigne suivante à la main. L'ingénierie des boucles change de logique : elle conçoit un système qui rédige lui-même ces relances. Le système envoie une consigne à un agent, contrôle le résultat, puis sollicite à nouveau l'agent, en boucle, jusqu'au terme prévu, avec une intervention humaine réduite.

La vidéo illustre la boucle avec un service de paiement dont plusieurs tests unitaires échouent. La boucle comprend quatre temps : formuler un objectif, agir, observer le résultat, puis ajuster la conduite. L'agent ouvre un fichier, modifie le code, lance la suite de tests, lit les sorties, puis décide : si un test devient vert, il passe au suivant ; s'il reste rouge, il tente une autre correction, avant de revenir à la question centrale, avons-nous terminé.

Un objectif flou ruine la boucle, car il est évalué à chaque tour et décide de la poursuite ou de l'arrêt. Rendre le paiement plus vite ne dit rien de vérifiable, pas plus qu'une vague bonne résolution de janvier : l'agent peut tourner sans fin ou proclamer victoire après un seul passage. À l'inverse, exiger que chaque test de la suite du paiement soit vert donne une condition d'arrêt nette et précise, que l'agent peut constater sans ambiguïté.

Autour de cette boucle simple s'organise toute une discipline : il faut d'abord un déclencheur qui lance le cycle. Un calendrier programme l'exécution chaque nuit, souvent par une tâche planifiée classique, tandis qu'un crochet événementiel réagit à un fait précis, comme une modification de fichier ou l'ouverture d'une demande de fusion. Les équipes de développement utilisent ces crochets pour la sécurité et la qualité, afin de faire respecter des règles avant toute intégration.

Chaque tour produit du contexte : sorties de tests, contenus de fichiers et journaux d'exécution, qui s'accumulent vite et dispersent l'attention de l'agent. L'ingénierie du contexte choisit ce que la boucle doit vraiment voir. Elle peut condenser les volumes, filtrer l'essentiel, ou recourir à la divulgation progressive : un paquet de compétences apporte alors le mode opératoire d'une tâche récurrente, dévoilé seulement au moment utile, pour garder le champ d'action lisible.

Au centre de la boucle se trouve ce que la vidéo nomme l'épine dorsale, c'est-à-dire un état persistant où l'agent consigne ce qu'il a fait et ce qui a fonctionné. Quelques fichiers Markdown suffisent : ils gardent la trace des essais, des corrections efficaces et des voies sans issue. Relue à chaque itération, cette mémoire oriente les décisions suivantes, évite de répéter les mêmes erreurs et donne à l'ensemble une continuité que le seul contexte immédiat ne permet pas.

Pour agir, l'agent doit sortir de son périmètre et toucher des ressources externes : exécuter du code, parcourir le système de fichiers, lancer des commandes dans le terminal ou interroger des bases de données. L'accès se fait par des outils, soit en appel direct vers une interface documentée, soit par un protocole standard qui expose ces outils de façon uniforme. Bien cadrés, ces outils transforment une intention en opérations concrètes et journalisées, quel que soit le processeur qui exécute le modèle.

Au stade de l'observation, confier la vérification au même agent qui a écrit le code crée un angle mort. Une bonne ingénierie fait donc appel à un second agent, un sous-agent vérificateur doté de ses propres consignes, de son propre contexte et parfois d'un modèle différent. Ce collègue contrôle le travail, signale les fragilités, prend en charge des vérifications déléguées, puis renvoie ses conclusions. La boucle gagne ainsi un regard indépendant avant de décider de la suite.

Reste la question de la place de l'humain, car un vérificateur automatisé demeure un programme comme un autre : la responsabilité du code livré appartient aux développeurs. Lorsque les agents produisent des volumes considérables que personne ne relit vraiment, l'écart grandit entre le code présent et ce que l'équipe comprend réellement. Cette dette de compréhension coûte cher lors d'une panne urgente en production ou d'une migration structurante, quand il faut agir vite sur un ensemble devenu obscur.

Une seconde dette guette : la dette d'intention. L'agent voit ce que le système fait, mais saisit moins bien pourquoi il le fait, sauf si les raisons sont écrites noir sur blanc, par exemple dans un fichier destiné aux agents. Sans cela, une correction valide en théorie peut trahir les objectifs, comme assouplir un contrôle sur un code de réduction pour faire passer un test, au détriment des fonds de l'entreprise. D'où le rôle humain : écrire l'objectif avec sa condition d'arrêt, tenir l'intention visible, assurer un suivi régulier et relire les sorties sans accepter aveuglément.