Conception + Audit de Boucle
Prémisse. Un LLM est un système feed-forward : prompt entrant → jetons sortants, sans capacité intégrée à « viser l’objectif » au fil des tours. Pour le faire se comporter comme un système orienté objectif, on l’encapsule dans une boucle de rétroaction. Cette compétence vous aide à écrire cette boucle correctement et à l’auditer pour qu’elle ne s’emballe pas.
Quand l’utiliser / ne pas l’utiliser
À utiliser quand :
- Vous voulez confier une tâche répétitive à un agent qui s’exécute en boucle (écrire→tester, tester→corriger, corriger→vérifier…).
- Vous avez déjà une boucle et craignez qu’elle dérive, triche ou exécute une réponse erronée jusqu’au bout.
Ne pas utiliser pour :
- Une tâche ponctuelle → exécutez-la directement ; pas besoin de boucle.
- Un simple minuteur / sondage → utilisez
/loop; aucune conception spécifique. - Comment câbler l’architecture de la boucle (pipelines → DAGs, récupération après long délai) → c’est la couche mécanique ; voir
autonomous-loops/continuous-agent-loop. Cette compétence ne couvre que « l’objectif est‑il correct et la boucle va‑t‑elle déraper ? » — elle ne réexplique pas la mécanique.
Ligne rouge de base : deux niveaux de rétroaction
| Niveau | Propriétaire | Rôle |
|---|---|---|
| Exécution (bas) | machine / agent | Mesure « à quelle distance de l’objectif littéral » et réduit cet écart à zéro. La machine est forte ici. |
| Jugement (haut) | humain | Décide « cet objectif est‑il correct, faut‑il le changer, faut‑il arrêter ». La machine ne peut pas sortir de sa propre boucle pour remettre l’objectif en question. |
Un thermostat peut retourner « écart par rapport à 26 °C », mais quand vous avez de la fièvre et voulez 28 °C, il ne peut pas juger si 26 est la bonne cible — il se contente de tendre vers 26. « Quel réglage aujourd’hui » reste toujours une décision humaine. Confier le jugement / la validation / le dernier interrupteur à la machine = supprimer la rétroaction de haut niveau = elle fonce, vite et fort, vers un objectif que personne n’a remis en question → résultat erroné.
Action 1 — Écrire une boucle (5 étapes)
Étape 0 · Soustraire d’abord : faut‑il vraiment la construire ? (barrière à 4 conditions, tout échec = veto)
① la tâche se répète au moins une fois par semaine ② la vérification peut être automatisée ③ le budget de tokens le permet ④ l’agent dispose d’outils qui exécutent et voient le résultat
Si une seule condition manque → ne construisez pas de boucle ; faites‑le manuellement ou autrement.
Ce qui arrête la plupart des gens n’est pas « sais‑je écrire une boucle », c’est « mon dépôt mérite‑t‑il une boucle ». Un dépôt qui mérite une boucle possède une référence de réconciliation (échantillon de référence / total amont) + des tests + un linter. Un dépôt qui ne la mérite pas ne fera qu’amplifier ses erreurs avec une boucle.
Étape 1 · Définir un objectif décidable par machine (la partie difficile — la boucle en dépend entièrement)
Toute la boucle repose sur la capacité du comparateur à répondre à « est‑ce fini ? » Le comparateur ne peut fonctionner que si votre condition de sortie peut être jugée oui/non par une machine.
- Mauvais : Vague (« rends‑le bon », « améliore le style ») → le comparateur ne peut pas juger → soit il ne passe jamais (coincé à réessayer), soit il devine (passe/bloque au hasard).
- Bon : Décidable (« les 96 tests unitaires sont verts ET un fichier de changements est produit », « les champs du module‑02 sont remplis, pytest passe, la logique métier est inchangée ») → une seule vérification tranche ; la boucle converge proprement.
Cadre objectif en cinq points :
- Le critère de complétude est vérifiable par machine.
- Les conditions limites sont définies en même temps que le critère de complétude (« ce qu’il NE doit PAS faire ») — anti‑Goodhart ; des limites absentes = une licence pour tricher.
- Il existe un repli en cas d’échec — limite de tentatives N + escalade à un humain si dépassée.
- L’objectif est stratifié.
- Préférer la réconciliation à l’assertion comme critère de complétude — s’ancrer sur un fait externe (échantillon de référence / total amont / rapprochement financier / chiffres back‑office de la plateforme) avant vos propres assertions. « Tous les tests passent » peut être truqué (assouplir les assertions, simuler des mocks, avaler des exceptions) ; « différence par rapport à la référence < 0,01 » ne le peut pas.
Auto‑vérification : lisez l’objectif à quelqu’un qui ne connaît pas le domaine — peut‑il exécuter une commande et dire si c’est fini ? Sinon, il n’est pas assez décidable. Recommencez.
Étape 2 · Choisir le type de boucle
| Votre tâche | Type de boucle (cybernétique) | Comment elle s’arrête |
|---|---|---|
| A un test de complétude clair (écrire jusqu’à complétude / traiter un lot d’images) | servo (boucle fermée de type /goal) | s’arrête à l’atteinte de l’objectif |
| Pas de point d’arrêt, doit maintenir un état (alerte de stock / contrôle périodique de santé) | régulateur (thermostat de type /loop) | ne s’arrête jamais ; n’agit que sur changement (zone morte pour filtrer le bruit) |
| Échantillonnage périodique, arrêt sur une condition (surveiller une PR jusqu’à ce que l’IC soit vert) | régulateur avec sortie | s’arrête quand la condition de sortie est vérifiée |
| Doit « garantir que quelque chose arrive à temps » | encapsuler le ci‑dessus dans /schedule | cron le déclenche |
Règle empirique : test de complétude clair → servo ; maintenance d’état sans point d’arrêt → régulateur ; « à faire à temps » → encapsuler un régulateur dans une planification.
Étape 3 · Choisir un squelette
Type maintenance (entretenir quelque chose d’existant) → dispatching piloté par document. La boucle n’est pas « exécuter un contrôle fixe sur un minuteur », elle « lit un document sur un minuteur et ne se déclenche que si le document a changé ». Le document est la file de tâches + la machine d’état + l’interface humaine. Trois disciplines : ① la colonne problème est en écriture humaine seulement, la colonne résultat est en écriture boucle seulement, l’état avance dans un seul sens et ne revient jamais en arrière ; ② le code de sortie est définitif (si le script dit exit 1, le script a raison) ; ③ l’état n’avance que jusqu’à « en attente de vérification » — la cellule « fait » n’est basculée que par un humain. La boucle est l’exécutante, pas le certificateur.
Type greenfield (construire à partir de zéro) → planifier / construire / juger, trois rôles.
| Rôle | Fait | Clé |
|---|---|---|
| Planification | décomposer l’objectif en un cahier des charges + conditions d’acceptation décidables | l’acceptation doit pouvoir être jugée par script |
| Construction | écrire selon le cahier des charges | ne doit pas modifier les conditions d’acceptation |
| Jugement | exécuter l’acceptation indépendamment ; passé → arrêt, échec → retourner avec la raison de l’échec à Construction | indépendante + déterministe |
Trois règles de fer (toutes parient sur le juge) : ① le juge doit être indépendant — pas le même agent que Construction (noter son propre travail gonfle toujours les notes) ; ② règles déterministes — pytest / diff de réconciliation / vérification de type / diff, jamais « ça a l’air bon » ; ③ Construction ne peut pas modifier les conditions d’acceptation pour passer. Trois tentatives échouées → escalade à un humain.
Étape 4 · Ajouter un amortissement (contre les oscillations / l’emballement)
Limite de tentatives, arrêt d’urgence, dernier interrupteur actionné par un humain = amortissement. Une rétroaction négative sans amortissement oscille (la boucle Ralph‑Wiggum : tourne sur elle‑même, brûle des tokens).
Étape 5 · Déployer en trois phases (ne pas passer en automatique complet le premier jour)
① L’exécuter une fois à la main (vous oblige à énoncer exactement « comment le juge décide ») → ② durcir en compétence / sous‑agents Claude Code (un Claude principal boucle, dispatche planification/construction/jugement) → ③ l’accrocher à cron pour automatisation complète.
Action 2 — Auditer une boucle (checklist = cinq modes de défaillance)
Faire passer la boucle dans chaque ligne. Dès qu’une ligne est touchée = cette boucle va dysfonctionner ; la renvoyer. Ces cinq modes sont tirés de l’expérience négative (pièges) — valent plus que des règles positives.
| # | Mode de défaillance (comment ça casse) | Question d’audit (un impact = rouge) | Anticorps |
|---|---|---|---|
| 1 | L’objectif est un vœu pieux → la boucle tourne, brûle de l’argent | La condition de sortie peut‑elle être jugée oui/non par une machine ? Ou est‑ce « gère‑le bien / rends‑le bon » ? | Remplacer par une condition de résultat décidable (Action 1·Étape 1) |
| 2 | La « vérification » est écrite comme « vérifier si ça a l’air correct » → l’agent déclare avec confiance que c’est bon et s’arrête | Le juge est‑il l’accusé lui‑même ? La vérification repose‑t‑elle sur « ça a l’air bon » ou sur des règles déterministes ? | Réconciliation + règles de code de sortie + juge indépendant |
| 3 | (le pire) Ne vérifie que « tous les tests passent » → l’agent supprime les tests | Y a‑t‑il une limite (« ce qu’il NE doit PAS faire ») ? Ou seulement un critère de complétude ? | Critère de complétude + limite ensemble (l’anticorps Goodhart) |
| 4 | Compte sur l’agent pour demander des clarifications en cours de route → il ne le fera pas ; il exécute la réponse erronée jusqu’au bout | Y a‑t‑il un point de « clarification uniquement à l’exécution » ? | Tout clarifier en amont ; décider une fois pour toutes avant le lancement |
| 5 | CLAUDE.md gonflé + mémoire obsolète → plus la boucle tourne vite, plus elle commet d’erreurs | Les documents/mémoire dont elle dépend sont‑ils frais ? Qui les maintient ? | Mémoire stratifiée + lint périodique |
Plus trois lignes rouges (en violer une = interdit de passer en automatique) :
- Garder le jugement avec l’humain. L’acceptation / la cellule « fait » est basculée par un humain ; la boucle n’est pas le certificateur.
- La responsabilité ne se délègue pas. Tout ce dont l’échec vous serait intolérable (fusionner la mauvaise PR / publier la mauvaise chose / mal allouer de l’argent) → ne pas déléguer l’autorité automatiquement.
- Avertissement contre‑intuitif. Plus une boucle est « auto‑améliorante / réécrit ses propres règles », plus elle nécessite une surveillance humaine stricte (pour voir en quoi elle a transformé les règles) — pas moins. La machine est trop rapide pour être interceptée après coup, donc le jugement humain doit se situer avant l’action (une barrière dure), pas comme un correctif a posteriori.
Exemple concret — audit d’une boucle « gardien nocturne des tests »
Vous voulez une boucle qui s’exécute chaque nuit et corrige les tests qui échouent.
- Objectif naïf : « faire passer tous les tests. » → L’auto‑vérification de l’étape 1 échoue : c’est l’appât du mode de défaillance #3.
- Objectif décidable (corrigé) : « tous les tests verts ET aucun fichier de test supprimé ou affaibli ET couverture non réduite ET un fichier de changements produit. » Les limites sont maintenant définies en même temps que le critère de complétude.
- Type : servo avec une limite de tentatives de 3 (Étapes 2 + 4).
- Squelette : planification/construction/jugement — le juge est l’IC exécuté indépendamment, jamais l’agent correcteur (Étape 3).
Appliquons la checklist d’audit, et elle capture ce que la version naïve aurait manqué :
- #3 impact → le naïve « tous les tests passent » permet à l’agent de supprimer un test qui échoue pour « gagner ». Corrigé par la limite « aucun fichier de test supprimé/affaibli. »
- #2 impact → si l’agent correcteur jugeait aussi sa propre correction, il se validerait lui‑même. Corrigé par « juge = IC indépendant, déterministe. »
- #4 impact → si une correction est ambiguë, l’agent ne s’arrêtera pas pour demander à 2 h du matin ; il livrera une supposition. Corrigé par le pré‑chargement : les corrections ambiguës sont laissées à l’humain, non devinées.
- Ligne rouge → la boucle ouvre une PR mais ne l’auto‑fusionne pas ; l’humain actionne le dernier interrupteur (la responsabilité ne se délègue pas).
La boucle naïve et la boucle auditée diffèrent par quatre lignes de contrainte — et c’est la différence entre « se réveiller avec une suite de tests supprimée » et « se réveiller avec une PR propre. »
Conclusion en une phrase
La partie difficile de l’écriture d’une boucle n’est pas « sais‑je écrire une boucle », c’est définir un objectif qu’une machine peut réconcilier — décidable, borné, basé sur la réconciliation. Le contrôleur doit être déterministe et externe ; gardez le jugement et la norme avec l’humain ; le système tend vers l’entropie, donc entretenez‑le. Une boucle ne récompense que celui qui a déjà réfléchi. Comptez sur elle pour penser à votre place, et elle pensera volontiers de travers, avec vous, à grande échelle.
Filiation : la rétroaction à deux niveaux de Wiener (The Human Use of Human Beings, 1950) pour la séparation jugement/exécution et les lignes rouges ; le modèle planification/construction/jugement d’Anatoli (Loops explained) et d’Addy (Loop Engineering). Couche mécanique (comment câbler l’architecture de la boucle) : voir
autonomous-loops/continuous-agent-loop. Cette compétence n’implémente pas la mécanique ; elle couvre la définition de l’objectif et la prévention de l’emballement uniquement.