Articles
Conception des boucles d'agents autonomes ── L'architecture au-delà des prompts
Product
Career
Traduction automatique du texte original en japonais
※Cet article est une textualisation (restructuré au format Manuscript) basée sur des matériaux internes (format diagrammatique). Le thème en est la conception d'une architecture résiliente multi-agents « Generator-Evaluator » qui continue à écrire, réviser et fusionner du code même pendant que les humains dorment.
La fin de « l'horloge humaine »
L'utilisation traditionnelle de l'IA fonctionnait selon « l'horloge humaine ». L'agent attend une entrée, l'humain appuie sur Entrée, les tokens sont générés, puis s'arrêtent. Et ainsi de suite. En juin 2026, un point de basculement a été atteint. Peter Steinberger (OpenClaw), Boris Cherny (Claude Code) et Addy Osmani (Chrome) ont convergé indépendamment vers la même compréhension au cours de la même semaine. Les outils ont franchi le seuil, ont-ils dit.
L'essence du changement est celle-ci : cesser d'être la personne qui envoie des prompts à un agent, et devenir la personne qui conçoit le système qui le fait à votre place. Le moteur de boucle autonome possède trois propriétés : (1) il est déclenché par une minuterie (il s'éveille selon un horaire), (2) il engendre des sous-agents parallèles (des assistants), et (3) il s'alimente lui-même (la sortie d'hier devient l'entrée d'aujourd'hui).
La pile de protocoles IA à 4 couches
Les niveaux d'utilisation de l'IA peuvent être organisés en quatre, le rayon d'impact des défaillances augmentant à chaque niveau supérieur.
| Couche | Préoccupation centrale | Unité de limite | Rayon d'impact des défaillances | Position de l'humain |
|---|---|---|---|---|
| Couche 1 : Prompt | Ce qu'on communique au modèle | Un seul échange | Erreur évidente immédiate | Dactylographe |
| Couche 2 : Contexte | Ce qu'on met dans la fenêtre | Une session | Raisonnement erroné confiant | Éditeur |
| Couche 3 : Harnais | Armer une exécution (outils/actions) | Une tâche | Mauvaise différence capturée avant la livraison | Relecteur |
| Couche 4 : Boucle | Ordonnancement du harnais | Itération sans pilote | Corrosion structurelle progressant sur des jours | Architecte |
L'anatomie d'une boucle qui tourne
Une boucle autonome se compose de cinq nœuds.
Discovery (Découverte) ── supportée par Skills (SKILL.md). Connaissance permanente du projet, remboursant la « dette d'intention ».
Handoff (Passation) ── supportée par Worktrees. Répertoires git indépendants pour l'exécution parallèle.
Verification (Vérification) ── supportée par des sous-agents. Séparation Generator-Evaluator. « Une entité capable de dire non ».
Persistence (Persistance) ── supportée par des connecteurs (MCP) et la mémoire. L'état réside dans des fichiers sur disque (./state/triage.md, etc.). L'agent oublie, mais le référentiel ne l'oublie pas.
Scheduling (Ordonnancement) ── supporté par l'infrastructure d'automatisation (cron local, GitHub Actions, routines cloud). Fermer la boucle.
Parallélisation Worktree
Problème : deux agents éditant le même répertoire de travail, c'est comme deux ingénieurs commettant sur la même ligne. Les collisions cassent un pipeline sans pilote. Primitive : séparer les répertoires de travail indépendants, comme claude --worktree fix/auth-test 'draft the fix'. Effet : transformer la parallélisation de « ça marche mais c'est un bazar » à « ça marche et c'est propre ». Plusieurs répertoires de travail indépendants au sein d'un seul référentiel permettent un triage des issues à haut débit.
La bulle d'auto-persuasion ── Séparer Generator et Evaluator
L'antipattern est que le générateur (Generator) se corrige lui-même. Le générateur ne regarde pas son code, il regarde sa propre chaîne d'auto-persuasion. En revanche, la séparation de type GAN sépare le générateur et l'évaluateur (Evaluator), donnant à l'évaluateur le rôle d'un relecteur de code adversaire. « Supposez ce code cassé jusqu'à preuve du contraire. Ne le complimentez pas. Trouvez où il échoue. »
Insight central : paramétrer un évaluateur indépendant comme un sceptique rigoureux est mathématiquement et pratiquement bien plus réalisable que de rendre un générateur critique envers ses propres résultats.
Jugement par exécution externe
Défaut : si l'évaluateur ne fait que lire le code, le jugement porte sur « l'apparence correcte » plutôt que « le fonctionnement correct ». Changement : connecter l'évaluateur à un environnement d'exécution externe (ex : Playwright MCP). Nouvelle norme : l'évaluateur clique sur des boutons, force les transitions d'écran, récupère l'état du DOM, exécute les tests. Le jugement passe de « l'intention » au « comportement ». Le flux devient : agent d'évaluation → connecteur Playwright MCP → inspection DOM/captures d'écran/exécuteur de tests → jugement de passage/échec.
Conditions d'arrêt du Maker-Checker
Quand la boucle devrait-elle s'arrêter ? La primitive /goal exprime « boucler jusqu'à satisfaction de la condition » (ex : /goal tous les tests dans test/auth passent et le lint est propre). Le Generator (modèle lourd) écrit le code, l'Evaluator (modèle lourd) exécute les tests via MCP, le Gatekeeper (modèle rapide et frais) évalue le /goal. Si satisfait, sortir de la boucle ; sinon, renvoyer le motif d'échec au Generator.
Principe : le jugement d'achèvement doit être rendu par un modèle frais qui ne porte aucun bagage de contexte du modèle ayant exécuté le travail. Et il y a une phrase à retenir : le plancher de la boucle est l'évaluateur. Le générateur définit le plafond de ce qui est produit ; l'évaluateur définit le plancher de ce qui n'est pas produit.
Les cinq formes d'échec de la boucle
| Élément manquant | Antipattern | Symptôme | Correction nécessaire |
|---|---|---|---|
| Absence de vérification | Boucle qui hoche la tête | 100 tours, approbation continue de ses propres déchets | Implémentation de la séparation Generator-Evaluator |
| Absence de persistance | Boucle amnésique | Redécouvrir exactement le même travail chaque matin | Forcer l'écriture sur disque des fichiers d'état |
| Absence d'ordonnancement | Boucle manuelle | N'a pas fonctionné une seule fois depuis le jour de la démonstration | Connecter cron/déclencheurs d'événements |
| Absence de découverte | Boucle aveugle | Encore à coller « corrigez ce bug » 30 minutes à chaque fois | Codifier les heuristiques dans SKILL.md |
| Absence de passation | Boucle emmêlée | Cinq agents parallèles détruisant un seul répertoire git | Forcer la séparation via --worktree |
Entrelacement déterministe à l'échelle de l'entreprise
Le pipeline « Minions » de Stripe suit le flux : Trigger (Slack) → Orchestrateur de contexte (Sourcegraph/Jira) → Génération de code (LLM) → Portail de linter obligatoire → Correction du lint (LLM) → Commit Git → Revue humaine (1 300 PR par semaine), fusionnant 1 300 PRs générés par la machine par semaine (entraîné par le framework open-source Goose).
Le secret est de confier du travail déterministe à un système déterministe. La collecte de contexte et le lint sont strictement codifiés en dur, et le LLM est complètement enfermé à l'intérieur de garde-fous rigoureux. L'environnement est traité comme « Cattle, Not Pets » (du bétail, non des animaux de compagnie) ; les Devbox sur EC2 sont immédiatement remplacées et jetées pour éviter la corruption d'état.
Topologie d'exécution ── Où la boucle habite-t-elle ?
| Topologie | État de la machine | Session | Intervalle minimum | Accès FS local |
|---|---|---|---|---|
| Cloud (Cloud Routines / GitHub Actions) | Machine OFF possible | Pas nécessaire | 1 heure | Aucun (clone propre) → Optimal pour le triage de nuit |
| Desktop (macOS cron) | Machine ON | Pas nécessaire | 1 minute | Oui → Optimal pour la maintenance périodique du référentiel |
| Local (/loop command) | Machine ON | Nécessaire | 1 minute | Oui → Optimal pour les vérifications fréquentes en cours de développement |
Appeler la réexécution locale « fonctionnant pendant qu'on dort » est une exagération. L'ordonnancement local achète la fréquence ; l'ordonnancement cloud achète la vraie autonomie. On ne peut pas obtenir les deux avec un seul ordonnanceur.
La spirale infernale des boucles sans surveillance
Les boucles sans pilote présentent quatre risques : la dette de vérification (les tests passent mais le code contient des défauts logiques subtils, fusionné) → la corruption de la compréhension (la carte mentale de la base de code diverge de la réalité) → la capitulation cognitive (« je ne sais pas comment ça marche, mais acceptons la PR ») → le gaspillage de tokens (l'agent sans surveillance génère des assistants toute la nuit et réessaie continuellement des corrections de bugs inutiles). Ce ne sont pas quatre risques distincts, mais un unique mode de défaillance composé. Une boucle sans évaluateur rigoureux a délégué son autorité de dépense à ses propres bugs.
L'économie de la génération à coût zéro
Devient abondant : la génération. Le coût du code, des plans, des corrections, des pull requests tend vers zéro, et le travail mécanique s'effondre. Reste rare : le jugement. La boucle peut générer 100 candidats d'implémentation, mais la sélection repose sur « l'apparence correcte » et non sur « l'exactitude réelle ». La boucle comme amplificateur : la boucle est un fidèle symbole multiplicatif. Apportez de la compréhension et elle l'amplifiera ; apportez de la paresse et elle amplifiera le désastre.
Disjoncteurs opérationnels
Lire toujours des échantillons (défense contre la corruption de compréhension) : chaque jour, expliquez avec vos propres paroles une PR générée par machine choisie au hasard. Si vous ne pouvez pas l'expliquer, votre carte mentale est déjà obsolète.
Fixer des limites avant la livraison (défense contre le gaspillage de tokens) : les plafonds budgétaires par exécution ou le nombre maximum de retries ne sont pas pour les économies ; c'est un disjoncteur transformant un risque ouvert en risque borné.
Laisser une porte ouverte (défense contre la capitulation cognitive) : créer au moins un point de contrôle de pause pour les humains. Non pour intervenir à chaque fois, mais pour garantir la capacité à intervenir.
Déployer une boucle résiliente minimale
La configuration minimale est la suivante : déclencher par horaire (cron : automatisation cloud), exécuter les compétences (morning-triage : découverte), écrire les résultats dans ./state/triage.md (persistance). Les corrections découvertes s'exécutent via worktree (fix/$finding : passation), jugées par /goal (vérification : « les tests passent et le lint est propre »). Les sorties se divisent en ./inbox/ (tout non vérifié), ./state/, ./src/, et ne jamais fusionner automatiquement. Tout non vérifié atterrit dans ./inbox/ — c'est le principe.
Enfin, terminons par ces mots.
« Créez une boucle. Mais créez-la en restant ingénieur. Pas en tant que personne qui appuie simplement sur un bouton. »