Au-delà du prompt : concevoir des systèmes autonomes avec le Loop Engineering

Le principe du Loop Engineering cherche à encapsuler la routine quotidienne avec un agent d'intelligence artificielle qui consiste à saisir une invite, attendre le résultat, lire la réponse puis saisir la consigne suivante pour corriger le tir. Plutôt que d'agir comme le contrôleur permanent d'un outil semi-automatisé, passant la journée à corriger manuellement les dérives du modèle, le loop engineering s'appuie sur des systèmes qui s'occupent de ça à votre place, sans oublier la supervision humaine du travail produit par les boucles, et la surveillance des boucles.

Le développement d'applications d'intelligence artificielle se voit donc bousculer par une nouvelle approche. Comme le résume Boris Cherny, responsable de Claude Code chez Anthropic : « Je ne formule plus d'invites pour Claude. J'ai des boucles en arrière-plan qui interrogent Claude et décident des actions à mener. Mon travail consiste désormais à concevoir des boucles. »

Le Loop Engineering peut se résumer simplement : ça consiste à concevoir des systèmes d'agents autonomes qui formulent les invites, exécutent les outils, évaluent le résultat et prennent la décision suivante à votre place.

La pile à trois couches : Prompt, Contexte et Boucle

Le Loop Engineering ne remplace pas le Prompt Engineering ni le Context Engineering. Il les enveloppe dans une couche de contrôle supérieure. Pour concevoir un système d'agent fiable, nous devons appréhender ces trois couches complémentaires :

• Le Prompt (Les instructions) : Les consignes et les rubriques destinées à un seul tour de conversation. Si cette couche est défaillante, le modèle comprend de travers ou invente des règles.
• Le Contexte (La vision) : Ce que l'agent peut observer à un instant précis (historique, documents récupérés, retours d'outils). Une mauvaise gestion ici entraîne une surconsommation de jetons et des décisions basées sur des données obsolètes.
• La Boucle (Le contrôle) : Le mécanisme de persistance qui pilote l'agent d'un tour à l'autre (planificateurs, politiques de budget et boucles de validation). Sans cette couche de contrôle, l'agent s'égare ou s'arrête prématurément sans vérifier son travail.

On a donc en utilisation concrète l'agent Harness, (en gros un LLM doté d'importants outils et d'une mémoire pour cadrer le travail), qui permet d'agir sur un environnement via des specs bien formulés, auquel on va superposer une boucle de contrôle, qui peut fonctionner de manière planifiée, par exemple sur l'apparition d'un nouveau ticket de bug, formuler les instructions initiales, lancer l'agent dans le harnais, évaluer le résultat et itérer jusqu'à ce qu'un critère de succès soit atteint. La boucle répond à la question : comment le système accomplit-il une tâche de bout en bout sans intervention humaine ?

C'est un exemple simple, en production, il faut appliquer un peu de rigueur et de maturité dans le déclenchement de boucle :

• L0 — Compte-rendu uniquement : la boucle observe et rapporte, sans jamais agir sur le dépôt ou le système cible.
• L1 — Stabilisation : la boucle tourne en observation pendant un temps donné pour valider sa fiabilité avant toute action automatique.
• L2 — Petits gains automatisés : un validateur, des répertoires de travail isolés et un nombre maximal de tentatives sont mis en place ; la boucle commence à agir, mais dans un périmètre restreint.
• L3 — Autonomie surveillée : la boucle agit sans supervision directe, mais uniquement si une liste de restrictions, un budget de dépense et des indicateurs de suivi sont déjà en place.

Ce chemin progressif répond à une question simple : ne jamais accorder à une boucle plus d'autonomie que ce que vos garde-fous peuvent réellement couvrir.

Les quatre niveaux de boucles d'agents

L'ingénierie de boucles s'organise selon une hiérarchie de complexité croissante, théorisée notamment par les équipes de LangChain.

Niveau 1 : La boucle de l'agent (L'exécution de base)

C'est le schéma le plus simple. L'agent reçoit une consigne de départ, appelle les outils nécessaires en boucle pour lire et modifier des fichiers, puis s'arrête lorsqu'il estime avoir terminé. Ce niveau dépend entièrement de la capacité d'auto-évaluation immédiate du modèle.

Niveau 2 : La boucle de vérification (La validation de qualité)

Le niveau un commet souvent des erreurs sur des tâches complexes. Le niveau deux introduit un validateur (ou censeur) indépendant de l'agent d'exécution. Ce censeur peut être déterministe (un script qui compile le code ou lance des tests unitaires) ou cognitif (un modèle d'évaluation de type LLM-as-a-judge). Si le travail de l'agent ne respecte pas les critères définis, le censeur formule un rapport d'erreur précis et le réinjecte dans le contexte de l'agent pour qu'il corrige sa copie. L'agent itère jusqu'à ce que le censeur valide le résultat. C'est vrai qu'ajouter une vérification augmente la latence et le coût de chaque exécution, mais c'est un compromis qui reste largement justifié dès que la qualité prime sur la vitesse.

Niveau 3 : La boucle événementielle (L'intégration système)

À ce niveau, l'humain n'est plus l'initiateur du processus. La boucle est connectée à vos outils de production. Elle se déclenche de manière autonome à la réception d'un événement externe (par exemple, un message Slack dans un canal dédié, un webhook GitHub lors de l'ouverture d'une pull request, ou une tâche planifiée à intervalle régulier). La boucle s'éveille, déroule les niveaux précédents en arrière-plan et publie les résultats là où vous en avez besoin.

Niveau 4 : La boucle d'optimisation (Le hill-climbing)

C'est le niveau le plus avancé, celui de l'amélioration continue. Chaque exécution d'agent produit des traces, de préférence structurées au standard OpenTelemetry (OTel). Un agent d'analyse examine ces traces de production à tête reposée. Lorsqu'il identifie un échec récurrent (par exemple, un outil mal utilisé ou une consigne ignorée), il met à jour la configuration de la boucle en modifiant le prompt système principal ou les règles du validateur. Ces traces peuvent aussi alimenter un entraînement par renforcement, transformant les erreurs de production en signal d'apprentissage pour le modèle lui-même. Un peu comme le principe d'auto apprentissage abordé dans l'article sur Hermes agent.

La sécurité dans les boucles : où et comment placer l'humain

Automatiser ne signifie pas retirer l'humain de la boucle. LangChain, un acteur important de l'évolution de l'écosystème des LLM pour le développement, insiste sur ce point : à chaque niveau décrit plus haut, il existe un point naturel où la supervision humaine apporte une valeur qu'aucun automatisme ne remplace.

Certaines expertises peuvent être codifiées directement dans les prompts et les outils, mais pour les actions sensibles, comme une opération sur une base de données de production, la revue humaine en direct demeure indispensable. Quatre points d'ancrage concrets permettent d'intégrer cette supervision sans casser l'autonomie de la boucle :

• Dans la boucle de l'agent (niveau 1) : exiger une validation humaine explicite avant toute action ou tout appel d'outil sensible, plutôt que de laisser l'agent agir puis corriger après coup.
• Dans la boucle de vérification (niveau 2) : remplacer ou compléter le censeur automatique par un humain qui joue le rôle de validateur pour les workflows les plus critiques, plutôt que de faire confiance uniquement à un LLM-as-a-judge.
• Dans la boucle applicative (niveau 3) : faire approuver par un humain les résultats avant qu'ils ne soient renvoyés à l'utilisateur final, notamment pour les livrables destinés à un public externe.
• Dans la boucle d'optimisation (niveau 4) : faire passer toute amélioration du harnais (changement de prompt, de règle de validation) par une revue humaine avant son déploiement, pour éviter qu'une boucle d'auto-amélioration ne dérive silencieusement.

Les trois dérives de l'autonomie en production

À mesure que les boucles d'agents deviennent plus autonomes et complexes, trois enjeux majeurs cessent d'être théoriques pour les équipes de développement :

• La charge de validation (Done n'est pas une preuve) :

Déléguer la validation des résultats à un sous-agent de vérification ou à un évaluateur cognitif (LLM-as-a-judge) aide à automatiser le contrôle. Cependant, cela ne transfère pas la responsabilité finale. L'humain doit rester dans la boucle de décision pour valider le rayon d'impact et la cohérence fonctionnelle avant toute livraison. Un censeur automatique vérifie qu'un test passe, pas qu'une décision a du sens dans son contexte métier.

Ce risque prend une forme précise : le surajustement aux tests (overfitting to tests). Un agent peut faire passer l'intégralité de la suite de tests tout en manquant l'exigence produit réelle, en particulier quand les tests sont trop étroits ou que le comportement visible par l'utilisateur final n'est jamais vérifié directement. La seule protection fiable consiste à combiner les tests automatisés avec une revue de l'exigence elle-même et, pour les changements visibles, une vérification manuelle ou dans le navigateur

• La dette de compréhension : Plus vos boucles d'agents génèrent et intègrent du code de manière autonome à un rythme élevé, plus l'écart se creuse entre l'état réel du logiciel et ce que votre équipe technique en comprend réellement. La vitesse de livraison ne doit pas se faire au détriment de la maîtrise de la base de code.

Pour reduire la dette pour l'équipe pilotant les loops : écrire des objectifs clairs, un signal de validation précis pour la fin de la boucle, et préférer des changements petits, sur un scope limité (frontend ou backend exclusivement, voir un seul composant applicatif), et réversibles à chaque tour de boucle plutôt que des réécritures spéculatives larges. Et maintenir la documentation à jour à chaque features et corrections réalisées par les agents.

• L'économie des jetons (Le budget d'exécution) : Une boucle autonome sans politique de budget stricte n'a pas de condition d'arrêt rationnelle. Sans coupe-circuit (circuit breaker) pour bloquer les exécutions après un certain seuil de dépense, une anomalie de logique peut consommer l'équivalent de plusieurs centaines d'euros en appels d'API en une seule nuit. Une simple alerte de dépassement de budget est asynchrone et suppose qu'un humain la voie et agisse à temps, alors qu'un coupe-circuit peut bloquer l'appel API suivant de façon automatique, sans attendre d'intervention humaine.

Les cinq piliers du Loopcraft (+ la sécurité et le workspace gouverné)

Bâtir un système de boucle robuste nécessite d'assembler plusieurs briques fondamentales. Le projet de référence documenté par Cobus Greyling ici en dénombre cinq, plus une mémoire persistante qui les relient toutes :

• Les automations (Scheduling) :

C'est le déclencheur de votre système. Il s'agit des tâches planifiées ou des déclencheurs qui cadencent le travail. C'est ce qui évite à un ingénieur de devoir lancer manuellement l'analyse.

• Les répertoires isolés (Worktrees) :

Dès que plusieurs agents travaillent en parallèle sur le même projet, ils risquent de modifier les mêmes fichiers et de provoquer des conflits. L'utilisation de répertoires de travail Git isolés garantit que chaque agent dispose d'un espace propre, sans collision entre exécutions parallèles.

• Les compétences (Skills) :

Les consignes d'écriture et de conception propres à votre entreprise doivent être documentées sous forme de fichiers de compétences (les fichiers de type SKILL.md). L'agent peut ainsi les charger dynamiquement au bon moment sans saturer sa fenêtre de contexte.

• Les connecteurs :

Ce sont les interfaces physiques de l'agent avec le monde extérieur. Avec le standard Model Context Protocol (MCP), les boucles peuvent interroger votre base de données, vérifier l'état d'un pipeline d'intégration continue, ou écrire dans un ticket de gestion de projet.

• Les sous-agents :

Pour accomplir des tâches complexes, l'agent principal doit pouvoir déléguer à des sous-agents spécialisés, typiquement selon une répartition "maker / checker" où l'un génère et l'autre vérifie. Cette séparation des rôles évite au modèle principal de perdre le fil de son objectif.

• La persistance mémoire (State) :

Les LLMs perdent leur contexte entre chaque exécution. Pour maintenir un historique fiable des actions passées et des étapes à venir, la boucle doit donc enregistrer son état dans un fichier persistant (typiquement un STATE.md), lu au démarrage de chaque exécution et mis à jour à la fin, plutôt que de tenter de tout retenir dans la fenêtre de contexte

• L'espace de travail gouverné (La brique de sécurité manquante) :

Conserver la mémoire de l'agent ne suffit pas pour travailler en production. La boucle doit s'exécuter dans des frontières strictes, notamment :

• Attribuer une identité propre à chaque sous-agent si possible.
• Un journal d'audit imuable des actions
• Une liste noire de chemins et de fichiers que la boucle n'a jamais le droit de modifier, quelle que soit la tâche.
• Une politique stricte sur la fusion automatique (auto-merge), généralement désactivée pour tout ce qui dépasse un changement mineur.
• Un mécanisme de retour arrière (rollback) automatique et rapide en cas d'anomalie.
• Le principe de moindre privilège appliqué aux connecteurs MCP eux-mêmes : chaque connecteur ne doit exposer que les actions strictement nécessaires à la boucle.
• Un coupe-circuit pour limiter le budget d'exécution.

Un exemple simplifié de fichier de permission pour un agent:

Un agent qui rédige la documentation, un agent qui gère les releases et un agent qui applique des correctifs de sécurité ne doivent pas partager le même profil de permissions, les mêmes logs, ni le même chemin de rollback. Fusionner ces profils "pour simplifier" est une erreur à éviter.

De la théorie au code : Bâtir ses propres boucles

Pour implémenter ces concepts en local, deux approches complémentaires coexistent.

La première s'appuie sur les outils de développement en ligne de commande de la communauté, à l'image du projet de Cobus Greyling. Son dépôt propose un ensemble d'utilitaires pratiques pour initialiser des structures de boucles, en voici quelques uns présent dans le dossier /tree/main/tools :

cobusgreyling/loop-engineering

• loop-init pour structurer le dossier de départ de votre projet, avec fiche de compétences, d'état, et de gestion du budget de tokens.
• loop-audit pour calculer un score de préparation de votre boucle qui bloque l'autonopie de la boucle si les éléments critiques (budget...) ne sont pas correctement configurés.
• loop-cost pour estimer le coût en tokens d'un pattern avant même de le planifier, une étape utile pour éviter les mauvaises surprises budgétaires évoquées plus haut.
• loop-context pour orchestrer les variables d'état et empêcher le système de tourner indéfiniment en cas d'erreur de logique (le coupe-circuit ou circuit breaker).
• loop-worktree pour automatiser la création et la suppression d'espaces de travail isolés dans Git.

La deuxième approche consiste à utiliser les commandes natives des assistants modernes. Claude Code et Codex CLI proposent la commande /goal, pensée spécifiquement pour l'exécution longue et autonome : l'agent boucle jusqu'à ce qu'un critère de succès explicite soit vérifié, sans qu'une commande de reprise manuelle soit nécessaire à chaque étape. Ça reste beaucoup moins granulaire que cobusgreyling/loop-engineering, mais c'est une fonction qui prendra en maturité avec l'évolution des agents harness.

Au-delà de la boucle unique : gouverner une flotte

Tout ce qui précède décrit comment concevoir une boucle fiable. Mais dès qu'une entreprise fait tourner plusieurs dizaines de boucles en parallèle, un nouveau problème apparaît : la fiabilité d'une chaîne d'agents se compose à la baisse, pas de façon additive. Cinq agents fiables à 90% chacun, enchaînés en série, ne donnent pas un système fiable à 90%, mais plutôt 0,9⁵, soit environ 59%. C'est précisément ce qui explique qu'une démonstration convaincante avec un ou deux agents devienne, une fois généralisée, "ingérable en production".

La réponse à ce problème porte un nom : le plan de contrôle IA (control plane), qui prolonge le Loop Engineering en le portant à l'échelle d'une flotte gouvernée. Là où une boucle unique se conçoit avec sa preuve de succès et sa condition d'arrêt, la gouvernance de flotte conçoit le système qui garantit que plusieurs boucles restent fiables, traçables et économiquement soutenables. Trois piliers structurent cette couche supplémentaire :

• Des évaluations continues, pas ponctuelles.

Le principe déjà vu au niveau d'une seule boucle ("done n'est pas une preuve") se généralise à l'échelle de la flotte via quatre contrôles automatisés qui tournent sur chaque interaction en production : détection d'hallucination, complétude de la réponse, adhérence au périmètre assigné, et exactitude de l'objectif poursuivi par l'agent.

• Une passerelle unifiée plutôt que des garde-fous dispersés.

La gouvernance ne peut pas vivre à l'intérieur de chaque agent : si chaque boucle porte ses propres règles de sécurité, elles finissent par diverger, et le premier agent mal configuré ouvre une brèche pour l'ensemble du système. Une passerelle centralisée porte à la place l'identité par agent, le contrôle d'accès, l'observabilité de bout en bout et les garde-fous d'entrée comme de sortie.

• Un suivi du coût des tokens dédié.

Contrairement au cloud classique, où le coût suit une logique de ressources provisionnées, la consommation de tokens d'une flotte d'agents s'accumule à travers des dizaines de projets à monitorer. Il faut surveiller avec des quotas par équipe, par agent ou par projet, qui déclenchent une alerte dès qu'un pic anormal apparaît. Et coupler ça à des plafond de cycles et des budget de token par tâche, le fameux coupe-circuit expliqué plus haut.

C'est un rôle à part entière pour celui qui conçoit ces systèmes : il ne s'agit plus seulement de faire fonctionner une boucle, mais de définir les rôles, les permissions et les critères de fiabilité d'une flotte entière d'agents. Écrire la meilleure boucle individuelle et dessiner le système qui peux rendre fiables des dizaines ou des centaines de boucles à la fois sont deux compétences métiers bien différentes.

Conclusion

Le Loop Engineering marque le passage de l'assistant de programmation interactif au collaborateur autonome d'arrière-plan. Cependant, La boucle autonome ne remplace pas la nécessité de garder un humain sur le chemin des décisions et du monitoring. Construire une boucle fiable et qu'on peut réellement laisser tourner la nuit sur un système de production reste, lui, un exercice d'ingénierie à part entière, et c'est précisément cet exercice que le Loop Engineering vous invite à prendre au sérieux dès la conception, plutôt qu'à improviser après le premier incident. Une boucle bien conçu, c'est une boucle réfléchie avant tout pour la vitesse à laquelle un système peut être vérifié, corrigé, et arrêté. Pas la vitesse à laquelle il génère du code ou des réponses.

Liens utiles

• L'introduction de LangChain au Loop Engineering : langchain.com/blog/the-art-of-loop-engineering
• Addy Osmani — Loop Engineering (article fondateur du terme) : addyosmani.com/blog/loop-engineering
• LangChain — The Art of Loop Engineering : langchain.com/blog/the-art-of-loop-engineering
• Cobus Greyling — Loop Engineering (dépôt GitHub de référence) : cobusgreyling/loop-engineering
• Cobus Greyling — Operating Loops (documentation détaillée) : cobusgreyling/loop-engineering
• Developers Digest — Permissions, Logs, and Rollback for AI Coding Agents : developersdigest.tech/blog/permissions-logs-rollback-ai-coding-agents
• Codex CLI — The /goal Command and the Verification Problem : codex.danielvaughan.com
• Claude Code - La commande /goal : code.claude.com/docs/fr/goal
• Kilo Code — What Is Loop Engineering? (perspective complémentaire, orientée cycle cognitif de l'agent) : kilo.ai/articles/what-is-loop-engineering