Loop engineering : guide pratique pour concevoir des workflows d’agents IA

La plupart des équipes commencent à utiliser les agents de codage IA comme elles ont commencé à utiliser les chatbots : elles demandent une chose, lisent la réponse, demandent une correction, relisent, puis recommencent jusqu’à obtenir quelque chose qui semble utilisable. Pour une petite tâche, cela fonctionne. Dès que le travail devient récursif, cela s’effondre.

Une vraie tâche d’ingénierie n’est pas un prompt unique. C’est une boucle.

Vous décrivez un objectif. L’agent lit la base de code. Il forme un plan. Il modifie des fichiers. Il lance des vérifications. Il observe les échecs. Il révise son plan. Il demande plus de contexte, ou il continue. À la fin, il vous rend soit un changement fonctionnel, soit un désordre très convaincant avec des tests qui prouvent le mauvais comportement.

Le loop engineering est la discipline qui consiste à concevoir ce cycle délibérément.

Le prompt engineering demande : « Que dois-je dire au modèle ? » Le loop engineering pose une question plus utile : « Quel système de contexte, d’outils, de vérifications, de mémoire, de budgets et de conditions d’arrêt va pousser cet agent, de manière répétée, vers un travail correct ? »

Cette distinction compte parce que la qualité d’un agent IA ne dépend plus seulement du modèle. Le modèle est une pièce de la machine. La boucle autour de lui décide s’il devient un coéquipier utile, un moteur d’autocomplétion coûteux ou un processus incontrôlé qui brûle des jetons en modifiant votre dépôt.

Ce que signifie le loop engineering

Une boucle est un cycle répétable qui mène un agent d’un objectif initial à un résultat vérifié.

Dans l’ingénierie logicielle, une boucle agentique pratique comporte généralement sept éléments :

1. Déclencheur : ce qui démarre la boucle.
2. Objectif : ce que la boucle cherche à accomplir.
3. Contexte : ce que l’agent est autorisé ou obligé à inspecter.
4. Outils : les actions que l’agent peut effectuer.
5. Vérification : la manière dont la boucle décide si le progrès est réel.
6. Mémoire : ce que la boucle conserve entre les itérations.
7. Règle d’arrêt : quand la boucle doit s’arrêter, escalader ou déclarer l’échec.

L’erreur consiste à traiter l’appel au modèle comme le produit. Le produit, c’est la boucle.

Prenons une correction de bug. Une boucle faible ressemble à ceci :

Utilisateur : Corrige le tunnel de paiement qui échoue.
Agent : Devine, modifie le code, dit que c'est corrigé.
Humain : Vérifie manuellement.

Une boucle plus robuste ressemble à ceci :

Déclencheur : Un test E2E de paiement échoue ou une erreur de production est remontée.
Objectif : Rétablir la finalisation du paiement sans changer la sémantique du provider.
Contexte : La trace d'échec, les routes concernées, l'adapter de paiement, les commits récents et le runbook.
Outils : Lire les fichiers, modifier le code, lancer des tests ciblés, inspecter les logs.
Vérification : Reproduire l'échec, appliquer la correction, faire passer le test ciblé, faire passer les tests unitaires de l'adapter.
Mémoire : Noter la cause racine et les commandes qui prouvent la correction.
Règle d'arrêt : S'arrêter après trois hypothèses ratées ou dès qu'une ambiguïté de schéma ou de contrat de paiement apparaît.

C’est cela, le loop engineering. Il ne s’agit pas d’écrire un plus joli prompt. Il s’agit de façonner l’environnement dans lequel l’agent agit.

Pourquoi cela devient une compétence d’ingénierie centrale

Le premier workflow de codage avec IA était prompt-réponse. Demander un composant. Demander un test. Demander un refactor. L’humain restait au centre et recollait manuellement chaque étape.

Le workflow récent est agentique. Des outils comme Codex, Claude Code, Cursor agents, OpenCode, Aider et des systèmes internes peuvent chercher, modifier, tester, résumer et itérer. Ils peuvent rester plus longtemps dans la tâche. Ils peuvent coordonner plusieurs fichiers. Certains peuvent appeler des navigateurs, des bases de données, des tickets, des API de déploiement et des systèmes d’observabilité.

Cette puissance change le mode d’échec.

Quand un chatbot vous comprend mal, vous obtenez une mauvaise réponse. Quand une boucle agentique vous comprend mal, elle peut produire un mauvais diff, ajouter des tests faibles, mettre la documentation à jour pour correspondre au mauvais comportement, puis vous annoncer que tout est vert.

L’industrie commence à formaliser le sujet. Le papier LoopSpec présente les boucles comme des objets programmables avec état, actions, observations et conditions de terminaison explicites. Un autre papier récent sur les boucles agentiques infinies étudie ce qui arrive lorsque des agents autonomes continuent à générer des actions sans terminaison efficace. Vous n’avez pas besoin d’adopter tout leur cadre théorique pour retenir la leçon pratique : les boucles doivent être conçues.

L’équipe capable de concevoir des boucles fiables obtiendra plus de valeur des mêmes modèles que l’équipe qui se contente d’écrire de meilleurs prompts.

Prompt engineering, harness engineering et loop engineering

Ces termes se chevauchent, mais ils ne désignent pas le même travail.

Le prompt engineering concerne les instructions. Vous choisissez le rôle, le ton, les contraintes, les exemples, le format de sortie et les comportements de refus.

Le harness engineering concerne le runtime. Vous connectez le modèle aux outils, schémas, systèmes de retrieval, logs, permissions, stockages et interfaces utilisateur.

Le loop engineering concerne le comportement dans le temps. Vous définissez comment l’agent observe le monde, choisit la prochaine étape, vérifie le progrès, gère l’échec, mémorise les leçons, dépense son budget et s’arrête.

Un prompt peut dire :

Tu es un ingénieur senior. Corrige le bug et lance les tests.

Un harness peut donner au modèle un terminal, un éditeur de fichiers et un runner de tests.

Une boucle décide :

• L’agent doit reproduire le bug avant de modifier le code.
• L’agent doit énoncer une hypothèse avant chaque modification.
• L’agent ne lance que des tests ciblés tant qu’une correction plausible n’existe pas.
• L’agent élargit les vérifications avant de finaliser.
• L’agent s’arrête et demande une entrée humaine si l’échec traverse une frontière système.
• La réponse finale inclut la cause racine, les fichiers modifiés et les preuves de validation.

Ce comportement fait la différence entre « l’IA m’a aidé à coder » et « l’IA a exécuté de manière fiable une partie de mon processus d’ingénierie ».

L’anatomie d’une bonne boucle agentique

Une bonne boucle n’est pas forcément compliquée. Elle est explicite.

1. Un déclencheur précis

Les déclencheurs faibles créent des boucles vagues. « Améliore l’application » n’est pas un déclencheur. « Le test E2E /checkout échoue après la redirection du provider » en est un.

De bons déclencheurs incluent :

• Le nom d’un test en échec et sa sortie.
• Une exception de production précise.
• Un ticket avec critères d’acceptation.
• Une alerte de mise à jour de dépendance.
• Une remarque de revue avec fichier et ligne.
• Un élément de checklist de release.

Le déclencheur doit indiquer à l’agent où commencer. Si l’agent passe la première moitié de la boucle à deviner quel problème il résout, la qualité fuit déjà.

2. Un objectif avec des limites

Les objectifs ont besoin d’espace positif et négatif.

Mauvais :

Améliore l'onboarding.

Meilleur :

Réduire l'abandon pendant l'onboarding en ajoutant un flux guidé de création du premier projet. Ne pas modifier la facturation, l'authentification ni les invitations de workspace.

La deuxième version donne à l’agent une direction et une clôture. La clôture compte. Les agents adorent refactoriser. Sans limites, ils « améliorent » souvent des systèmes adjacents simplement parce qu’ils sont visibles dans le contexte.

3. La sélection du contexte

Le contexte est à la fois un budget et un risque.

Trop peu de contexte pousse l’agent à halluciner l’architecture. Trop de contexte lui fait perdre la tâche, surpondérer des fichiers inutiles ou copier des motifs du mauvais sous-système.

Pour les boucles de codage, définissez le contexte en couches :

• Contexte obligatoire : fichiers, logs, docs, schémas ou traces que l’agent doit inspecter.
• Contexte probable : modules voisins et tests associés.
• Contexte interdit : secrets, fichiers générés sans intérêt, répertoires vendor ou documentation historique connue comme obsolète.
• Contexte d’escalade : zones plus larges que l’agent ne peut inspecter qu’après une hypothèse ratée.

C’est un point que beaucoup d’équipes négligent. Elles écrivent de longs prompts mais ne donnent aucune politique de contexte claire. Résultat : l’agent lit trop, lit trop peu, ou lit le fichier dont le nom lui semble le plus familier.

4. La politique d’outils

Les outils sont l’endroit où un agent devient opérationnellement dangereux.

Lire des fichiers est peu risqué. Modifier des fichiers est moyennement risqué. Lancer des tests est généralement sûr. Exécuter des migrations, supprimer des ressources, déployer, envoyer des e-mails, débiter des cartes ou appeler des API de production est très risqué.

Une boucle doit dire quels outils sont autorisés, quand ils le sont, et ce qui exige une approbation.

Par exemple :

tools:
  read:
    allowed: always
  edit:
    allowed: after plan
  tests:
    allowed: targeted first, broad before final
  network:
    allowed: docs and package metadata only
  deploy:
    allowed: never in this loop
  destructive_commands:
    allowed: never without human approval

Ce n’est pas de la bureaucratie. C’est ce qui permet aux agents d’aller vite dans une enveloppe d’exploitation sûre.

5. L’échelle de vérification

Chaque boucle a besoin d’une échelle de preuves. L’agent ne doit pas passer directement de « j’ai changé le code » à « terminé ».

Une échelle de vérification pratique ressemble à ceci :

1. Raisonnement local : le changement correspond à l’hypothèse annoncée.
2. Vérification ciblée : le test, typecheck, lint ou scénario de reproduction passe.
3. Vérification voisine : les tests proches ou intégrations liées passent encore.
4. Vérification système : build plus large, E2E ou smoke test.
5. Signal externe : logs, métriques, retour utilisateur, staging ou canary production.

Toutes les boucles n’ont pas besoin des cinq niveaux. Une faute de frappe peut nécessiter seulement un build. Un bug de paiement a besoin de l’échelle.

L’essentiel est de concevoir la vérification avant que l’agent ne modifie le code. Si la vérification est inventée après le diff, elle devient facilement une histoire qui justifie le diff.

6. Une mémoire qui aide, pas une mémoire qui pollue

La mémoire agentique est utile lorsqu’elle conserve des faits durement acquis :

• « Ce dépôt utilise des cookies Supabase SSR, pas une auth localStorage. »
• « Le worker média a des règles CORS séparées du worker API. »
• « Ce test échoue en CI si le chemin de route n’est pas cité dans zsh. »
• « Les webhooks provider sont gérés dans le portail ; le backoffice doit afficher l’état, pas créer les webhooks. »

La mémoire devient nuisible lorsqu’elle conserve des suppositions obsolètes, des préférences personnelles ou des décisions vraies pour une tâche mais fausses pour la suivante.

Une bonne mémoire de boucle doit être :

• Courte.
• Appuyée par des preuves.
• Limitée à un dépôt, sous-système ou workflow.
• Facile à remplacer lorsque le code actuel la contredit.

Traitez la mémoire comme un cache, pas comme une source de vérité.

7. Les règles d’arrêt

C’est la partie la plus ignorée de la conception de boucles.

Un agent ne doit pas être autorisé à itérer indéfiniment simplement parce qu’il peut continuer à produire des prochaines étapes plausibles. Les règles d’arrêt protègent l’argent, le temps, la qualité du code et la confiance.

Des règles utiles :

• S’arrêter après trois hypothèses ratées.
• S’arrêter quand le même test échoue pour deux raisons différentes.
• S’arrêter quand la tâche traverse un sous-système non approuvé.
• S’arrêter avant toute commande destructive.
• S’arrêter quand l’agent ne peut pas reproduire le bug.
• S’arrêter quand des secrets, identifiants ou décisions produit manquent.
• S’arrêter quand le coût estimé dépasse le budget de la tâche.

La règle d’arrêt n’est pas un aveu de faiblesse. C’est une surface de contrôle. Une boucle incapable de s’arrêter n’est pas autonome ; elle est non gouvernée.

Cinq motifs de boucles pratiques

Voici des motifs qui valent la peine d’être transformés en workflows réutilisables.

La boucle de correction de bug

Objectif : passer d’un rapport d’échec à une correction vérifiée.

Utilisez-la avec un message d’erreur, un test cassé, une route défaillante, une régression ou un symptôme de production.

Boucle :

1. Lire la sortie d’échec et le code le plus proche.
2. Reproduire, ou expliquer pourquoi la reproduction est impossible.
3. Énoncer une hypothèse.
4. Faire le plus petit changement qui teste l’hypothèse.
5. Lancer la vérification ciblée.
6. Si elle échoue, mettre à jour l’hypothèse.
7. Avant de finaliser, lancer une vérification voisine.

Arrêtez lorsque l’agent ne peut pas reproduire, ne peut pas former de nouvelle hypothèse, ou découvre que le problème dépend d’une dépendance externe ou d’une décision produit.

La boucle de revue de code

Objectif : trouver les risques avant le merge.

Utilisez-la pour relire un diff, une PR, une migration ou une branche de release.

Boucle :

1. Inspecter le diff avant les fichiers complets.
2. Identifier d’abord les changements de comportement, pas les préférences de style.
3. Tracer les flux de données affectés.
4. Chercher les tests manquants autour du comportement modifié.
5. Classer les remarques par sévérité.
6. Proposer des corrections ciblées.

La boucle de revue ne doit pas réécrire le code par défaut. Sa sortie est du jugement : bugs, régressions, risques de sécurité, lacunes de tests et questions.

La boucle de refactor

Objectif : améliorer la structure sans changer le comportement.

Le refactoring est l’endroit où les agents sont à la fois utiles et risqués. Ils vont vite, mais peuvent effacer des contraintes importantes parce que l’ancien code « avait l’air désordonné ».

Boucle :

1. Définir l’invariant : quel comportement doit rester identique.
2. Identifier la plus petite frontière à modifier.
3. Ajouter ou confirmer des tests de caractérisation.
4. Déplacer le code par petites étapes.
5. Lancer les tests après chaque étape significative.
6. S’arrêter si le refactor exige une décision produit ou de schéma.

Une boucle de refactor sans tests de caractérisation n’est qu’une boucle de réécriture avec un plus beau nom.

La boucle de recherche

Objectif : répondre à une question technique avec des preuves.

Utilisez-la avant d’adopter une bibliothèque, changer d’architecture, choisir un modèle ou dépendre d’une nouvelle API.

Boucle :

1. Énoncer la décision à prendre.
2. Chercher d’abord les sources primaires : docs officielles, specs, papiers, changelogs.
3. Extraire les contraintes qui affectent la base de code.
4. Comparer les options à ces contraintes.
5. Enregistrer la décision, les hypothèses et la date de fraîcheur.

La boucle de recherche doit séparer les faits de l’inférence. « La documentation dit X » et « donc nous devrions faire Y » sont deux types de propositions différents.

La boucle de readiness release

Objectif : décider si un changement est prêt pour les utilisateurs.

Boucle :

1. Lire la checklist de release ou les critères d’acceptation.
2. Identifier les parcours utilisateur touchés par le changement.
3. Lancer les vérifications au bon niveau : unitaires, intégration, navigateur, smoke ou staging.
4. Inspecter les logs ou le monitoring si disponibles.
5. Lister les bloqueurs, risques et inconnues restantes.
6. S’arrêter avant le déploiement sauf si le déploiement est explicitement dans le périmètre.

Cette boucle consiste moins à écrire du code qu’à refuser de confondre des checks locaux verts avec une readiness production.

Un template de boucle réutilisable

Voici un template compact que vous pouvez adapter à n’importe quel workflow agentique :

name: bug-fix-loop

trigger:
  type: failing-test | production-error | user-report | review-finding
  required_input:
    - exact error or failing behavior
    - affected route/module/test when known

goal:
  outcome: restore the expected behavior
  non_goals:
    - unrelated refactors
    - dependency upgrades
    - product behavior changes

context:
  must_read:
    - failing output
    - nearest implementation file
    - nearest test or spec
  may_read:
    - neighboring modules
    - recent commits
    - runbooks
  avoid:
    - generated files
    - secrets
    - unrelated vendor code

tools:
  read_files: allowed
  edit_files: allowed after hypothesis
  run_tests: targeted first, broader before final
  network: docs only
  destructive_actions: require approval

iteration:
  before_edit:
    - state current hypothesis
    - state expected verification
  after_edit:
    - run focused check
    - compare result to hypothesis
    - keep, revise, or revert the hypothesis

verification:
  required:
    - focused failing case passes
    - related test or type check passes
  final_report:
    - root cause
    - changed files
    - commands run
    - remaining risk

stop_rules:
  - stop after three failed hypotheses
  - stop if reproduction is impossible
  - stop if fix requires product decision
  - stop before destructive command

Le but n’est pas de transformer chaque boucle en document YAML. Le but est de rendre la procédure opérationnelle cachée assez explicite pour qu’un agent puisse la suivre et qu’un humain puisse l’auditer.

Comment commencer sans surconcevoir

Vous n’avez pas besoin d’une plateforme pour pratiquer le loop engineering. Commencez par trois gestes simples.

D’abord, écrivez un fichier AGENTS.md pour votre dépôt. Indiquez comment lancer les checks, quel package manager utiliser, quels motifs comptent, quelles commandes sont dangereuses et ce que l’agent doit inspecter avant de modifier. C’est la frontière de boucle au niveau du dépôt.

Ensuite, créez deux ou trois boucles spécifiques. Une boucle de bug-fix, une boucle de revue et une boucle de readiness release suffisent à la plupart des équipes. Gardez-les courtes. Le but est le comportement, pas le théâtre documentaire.

Enfin, mesurez la boucle. Suivez la fréquence à laquelle l’agent :

• Résout la tâche en une passe.
• A besoin d’une correction humaine.
• Lance les bonnes vérifications.
• Touche des fichiers non liés.
• S’arrête au bon moment.
• Produit un rapport final auquel un reviewer peut faire confiance.

Si vous mesurez ces résultats, vous améliorerez la boucle plus vite que le prompt.

La partie difficile, c’est le jugement

Le loop engineering ne supprime pas le jugement humain. Il le déplace plus tôt.

Au lieu de juger chaque jeton produit par le modèle, vous jugez la boucle :

• Avons-nous donné le bon déclencheur ?
• Avons-nous contraint l’objectif ?
• Avons-nous fourni le bon contexte ?
• Avons-nous autorisé les bons outils ?
• Avons-nous défini la preuve avant l’édition ?
• Avons-nous appris à l’agent quand s’arrêter ?

C’est une meilleure utilisation du temps d’ingénierie senior.

L’avenir du développement assisté par IA n’appartiendra pas aux équipes avec les prompts les plus longs. Il appartiendra aux équipes avec les meilleures boucles : assez serrées pour être sûres, assez flexibles pour résoudre de vrais problèmes, assez observables pour être déboguées, et assez honnêtes pour s’arrêter quand la machine ne sait plus ce qu’elle fait.

Le prompting est la manière de parler au modèle. Le loop engineering est la manière de construire une relation de travail avec lui.