Boucle de rétroaction et agents en parallèle : deux livres lus

J'écris des fiches de lecture sur des livres techniques. Pour les vérifier, je les fais relire par des agents. Un agent est une instance de Claude, une IA qui travaille seule sur une tâche avec ses outils. Chaque relecteur compare mes affirmations au livre.

Un jour, ces relecteurs m'ont signalé comme inventés des faits parfaitement réels. La faute était la mienne : je leur avais donné des notes condensées au lieu du texte du livre. Ils ne pouvaient pas confirmer ce qu'ils ne voyaient pas. Un juge ne vaut que par ce qu'il a sous les yeux.

Imagine un élève qui corrige sa propre copie. Il retrouve ses idées, les trouve claires et se met une bonne note. Un correcteur extérieur voit ce que l'élève ne voit plus. (Cette image est de moi, elle ne vient pas des livres.)

Avec des agents, ça donne une boucle de rétroaction. Dans la boucle, un agent écrit, un autre note, puis on corrige et on recommence. On s'arrête quand la note atteint un seuil : sous le seuil on corrige, au-dessus on sort.

Je pratique ça tous les jours. Je lance aussi plusieurs agents en même temps, c'est-à-dire en parallèle, au lieu de les faire travailler l'un après l'autre. Un agent peut en lancer d'autres, qu'on appelle des sous-agents. Chacun a sa propre fenêtre de contexte, le texte qu'il garde sous les yeux. Seul son message final remonte à celui qui l'a lancé.

J'avais lu quatre livres sur Claude Code. Le meilleur, The Claude Code Operating Model, chiffre ses propres affirmations. Je voulais plus avancé sur ces deux sujets. Packt m'a ouvert l'accès à sa plateforme d'abonnement ExpertEdge, et j'y ai lu deux livres de 2026 :

• Agentic Architectural Patterns for Building Multi-Agent Systems, d'Ali Arsanjani et Juan Pablo Bustos. Je l'appelle « Arsanjani ».
• Spec-Driven Development with BMAD, de Marlon Vidal Ferreira. Je l'appelle « BMAD », du nom de l'outil qu'il enseigne.

Les deux m'ont appris quelque chose sur les boucles. Sur le parallèle, ils décrivent plus qu'ils ne mesurent.

Celui qui écrit ne doit pas être celui qui note

Le principe le plus solide des deux livres vient d'Arsanjani. Un agent qui produit une solution puis la juge « a du mal à être un critique objectif de son propre travail » (leçon 111). Il rationalise ses erreurs : il se trouve de bonnes raisons de les laisser.

J'ai déjà écrit là-dessus : Aucun agent ne corrige sa propre copie. Le livre en tire un pattern, une recette de conception qui revient souvent. Il s'appelle Hybrid Planner + Scorer. Un agent planifie (le planner), un autre note (le scorer, le noteur), et la note sert à ajuster le premier.

Le livre ajoute que la boucle ne vaut que par sa mesure. Un système d'agents « ne peut améliorer que ce qu'il sait mesurer » (leçon 110).

Arsanjani nomme aussi deux pannes. Elles arrivent quand le juge évolue en même temps que l'agent qui produit (le générateur). C'est le vocabulaire qui m'a le plus servi :

• La collusion : le générateur apprend à « jouer » avec le système. Il produit des sorties médiocres que le juge laisse passer (leçon 114). Pour te représenter la chose : l'élève qui étudie les goûts de son correcteur plutôt que la matière.
• La divergence incontrôlée (runaway divergence) : le système s'éloigne de l'objectif réel pour optimiser un indicateur interne, un chiffre qu'il suit lui-même (leçon 114).

Son exemple parle de code (leçon 115). Un agent correcteur (le « fixer ») répare une faille. Un agent auditeur (l'« auditor ») note le correctif. L'histoire se déroule en deux cycles :

1. Au premier cycle, le correcteur découvre qu'envelopper un plantage dans un try/except suffit à obtenir une bonne note. Un try/except attrape l'erreur et la cache. Le système plafonne.
2. Au second cycle, l'auditeur est réentraîné sur des paires « rustine » contre « vraie correction ». Réentraîner un modèle, c'est le faire réapprendre à partir de nouveaux exemples. Les scores du correcteur chutent, et il doit apprendre à déboguer.

Un juge de ce genre s'appelle un LLM-juge. C'est un modèle de langage, une IA qui écrit du texte, chargé de noter la sortie d'un autre. Si ses critères sont génériques, il se laisse tromper. Une métrique de ressemblance entre textes est un calcul qui note à quel point deux textes se ressemblent. Le livre note que l'une d'elles, BERTScore, est « aveugle à la logique » (leçon 112).

Attention, ma boucle n'est pas de même nature. Celle d'Arsanjani réentraîne des modèles (leçons 113 à 115). La mienne corrige un document d'après un rapport, sans toucher aux modèles. Ce qui se transpose, c'est la panne et le remède, pas la mécanique. Les seuils chiffrés et le nombre maximum de tours décrits plus bas sont de mon cru.

Contre la triche : un contrôle extérieur, puis un budget limité

Contre ces deux pannes, Arsanjani prescrit un ancrage externe : « une revue humaine périodique ou une validation contre un golden dataset » (leçon 114). Un ancrage externe est un point de contrôle placé hors de la boucle, que les agents ne maîtrisent pas. Un golden dataset est un jeu de cas dont la bonne réponse est connue d'avance.

Pour des agents de code, l'ancrage le plus direct est le test réellement exécuté. Un test est un petit programme qui vérifie qu'une fonctionnalité marche. C'est là que le livre BMAD est utile.

BMAD est un cadre de travail open source. Des agents y ont chacun un rôle (analyste, architecte, développeur, testeur) et se passent des documents écrits avant le moindre code. Le livre en tire six gestes de contrôle que je retiens, indépendamment de l'outil :

• Rouge avant vert. Un test rouge échoue parce que la fonctionnalité n'existe pas encore. Un test vert passe. Un module de tests génère, avant le code, un test par critère d'acceptation, une condition écrite que la fonctionnalité doit remplir. Chaque test est marqué test.skip() (« ignore-moi »). La méthode s'appelle ATDD, pour Acceptance Test-Driven Development : on écrit d'abord les tests qui vérifient que la fonctionnalité fait ce qui était demandé. Le développeur retire les skip un par un, du rouge au vert. Des tests écrits après l'implémentation ne couvrent pas forcément tous les scénarios, dit le livre (leçon 26).
• Une porte avant d'écrire du code. Une porte est un contrôle qu'on franchit avant d'avancer. Le check d'implementation readiness croise le cahier des besoins, l'architecture et le découpage du travail. Il rend PASS, CONCERNS ou FAIL (leçon 15). Un FAIL se lit sans drame : l'erreur existe encore dans un document, pas dans du code.
• Une revue en trois passes après chaque story. Une story est une unité de travail rédigée dans un fichier, assez petite pour tenir dans une session. Une session est une conversation avec l'agent. Il y a trois passes : un chasseur d'erreurs de logique, un chasseur de cas limites et un auditeur des critères d'acceptation. Un cas limite est une situation rare, comme une liste vide, ou un accès concurrent. Le livre conseille de confier la revue « idéalement à un autre modèle » (leçon 30). Il précise que la couche de revue « n'est pas une formalité » (leçon 18).
• Une boucle d'auto-correction. Dans la démonstration, un test de bout en bout échoue : il parcourt l'application comme le ferait un utilisateur. Le workflow se corrige alors tout seul. Un workflow est une procédure BMAD lancée par une commande. Il relance la suite de tests, trouve un autre défaut, le corrige et vérifie (leçon 30).
• Une session neuve par étape. Le livre interdit l'enchaînement (« never chain », leçon 43), parce que le contexte accumulé biaise la suite. Ouvrir une session neuve, c'est repartir sans mémoire de la précédente.
• Une rétrospective qui réécrit les consignes. Un epic est un grand lot de stories. En fin d'epic, après une porte de couverture des tests, la rétrospective relit les notes laissées par chaque story. Elle régénère project-context.md (leçon 31). C'est l'équivalent BMAD d'un CLAUDE.md, le fichier de consignes que l'agent relit au début de chaque session. Il devient « le registre vivant de la façon dont le projet a appris à se construire » (leçon 19).

Dernier garde-fou, côté Arsanjani : le plafond de budget. Un plafond est une limite qu'on ne dépasse pas. Dans l'exemple du livre, un agent analyste doit résumer 5 000 PDF avec un budget de 50 dollars. À 90 % du budget consommé, vers le 50e PDF, un disjoncteur coupe la collecte. Un disjoncteur coupe tout quand une limite est franchie, comme dans une maison. L'agent passe alors au rapport avec les données déjà là (leçon 117).

Le même livre avoue qu'une boucle d'apprentissage peut coûter « 10 à 100 fois » une inférence normale, sans citer de source. Une inférence est un appel au modèle pour obtenir une réponse.

Côté BMAD, le coût se résume à deux formules. La leçon 31 dit « long et gourmand en tokens ». La leçon 29 dit « très cher en tokens, mais bien moins que de laisser ces problèmes arriver en production ». Il n'y a aucun chiffre de tokens ni de dollars. Un token est le petit morceau de texte que le modèle lit et que ton abonnement compte. Donc, pour une boucle à plusieurs tours, fixe le plafond avant le premier tour, pas après la première facture.

Ma boucle à moi : une note à atteindre, trois tours au maximum

Aucun des deux livres ne donne de seuil de sortie, de nombre de tours ou de répartition des rôles pour une boucle de relecture. Voici la mienne, rodée sur quatre fiches de livres et un article. Une fiche est ma note de lecture d'un livre, publiée sur ce site. Les fiches de la série précédente sont parties de 59 à 76 sur 100 au premier tour. Elles sont arrivées entre 84 et 97 après les tours Sonnet. L'article de la série précédente est passé de 6,1 à 8,1 sur 10.

Un tour est un cycle complet : un relecteur note, puis un autre agent corrige. Sonnet et Opus sont deux modèles d'Anthropic, Opus étant le plus coûteux : je le garde pour la dernière passe. Chaque rôle reçoit et rend ceci :

Les seuils de sortie dépendent de ce que je relis :

• Pour une fiche : 85 sur 100 au moins. La note de fidélité aux faits doit valoir 20 au moins, et chaque idée 8 minimum sur quatre axes.
• Pour un article : une moyenne d'au moins 8 sur 10 et aucun critère sous 7.

Mon plafond est de trois tours Sonnet au maximum : trois essais, puis on arrête. Au-delà, je passe à la relecture Opus avec la liste de ce qui bloque, plutôt que de boucler.

Le relecteur d'un nouveau tour reçoit le rapport du tour précédent. Il garde ainsi la même grille et la même sévérité, parce qu'un relecteur neuf sans historique note autrement.

Côté isolation, le relecteur reçoit le texte, les règles, le livre et le rapport précédent (voir le tableau), sans le raisonnement de rédaction. Chaque rapport va dans un fichier. Chaque version corrigée est commitée entre deux tours, c'est-à-dire sauvegardée dans l'historique du code. Une session qui redémarre perd donc les agents en cours, pas le travail. Le squelette de rapport que je demande ressemble à ceci :

Moyenne : X/10 (seuil 8, aucun critère < 7). Sortie atteinte : oui/non.

Critères notés sur 10 : accroche, structure, fidélité et faits, voix, autonomie, utilité, SEO, niveau par rapport aux étalons.

Pour chaque point perdu : le passage fautif cité, la source qui le contredit
(chercher par recherche de texte dans le livre, pas dans les notes), la correction demandée.
Pour passer le seuil : les corrections par ordre de priorité.

Plusieurs agents à la fois : décrit dans les livres, jamais mesuré

Reste une question : lancer plusieurs agents en parallèle améliore-t-il vraiment le résultat ? Les livres le décrivent, mais ne le mesurent nulle part.

Une comparaison : confier trois chapitres à trois personnes qui écrivent en même temps. Il faut un chef qui distribue le travail, puis quelqu'un qui rassemble les chapitres. Avec des agents, c'est le même schéma.

Arsanjani décrit le parallèle. Le multi-agent, c'est plusieurs agents qui coopèrent. Il est présenté comme une coordination qui « permet un traitement parallèle » (leçon 43). Le livre montre du vrai code concurrent, en deux versions :

• Un superviseur, l'agent qui distribue le travail, lance trois collecteurs de données dans des threads avant qu'un rédacteur assemble le rapport (leçon 50). Un thread est un fil d'exécution : un travail qui avance en même temps que les autres.
• Un autre superviseur les lance avec asyncio.gather (leçon 91). C'est la fonction Python qui lance plusieurs tâches ensemble et attend qu'elles aient fini.

Deux patterns servent à vérifier un résultat :

• Le consensus par exécution parallèle (leçon 69) : deux agents indépendants font la même tâche. Leurs scores sont comparés avec une tolérance de 10 points.
• Le vote majoritaire (leçon 75) : trois agents ou plus répondent, et on retient la réponse la plus fréquente.

La fusion des réponses est traitée, par une moyenne ou un vote. En cas de désaccord, il y a une escalade vers un humain : on passe la main à une personne.

Les écritures simultanées sur un état partagé ont leur pattern (leçon 64). Un état partagé est un ensemble de données que plusieurs agents lisent et modifient. Deux agents qui écrivent en même temps peuvent s'écraser. Le livre propose des opérations atomiques sur un magasin comme Redis, une base de données rapide, en mémoire. Une opération atomique ne peut pas être coupée en deux par une autre. Il prévoit aussi une durée de vie pour les informations.

Les limites sont ailleurs :

• Dans les exemples de vérification, le code appelle les agents l'un après l'autre, et leurs réponses sont inventées. Le score de la leçon 69 sort de random.randint, une fonction qui tire un nombre au hasard. Les votes de la leçon 75 sont codés en dur.
• Le coût de la redondance est dit en une phrase, « le pattern de redondance le plus cher » (leçon 75), pas mesuré.
• Il n'y a rien sur des agents de code qui éditent un même dépôt : pas de conflit de fichiers, pas de branches isolées. Un dépôt est le dossier où vit le code d'un projet.

Les conseils qui m'ont servi tiennent sur l'indépendance. Un deuxième avis médical n'a de valeur que si le second médecin n'est pas sorti de la même école que le premier. Le livre le dit des agents : ils doivent être « idéalement alimentés par des modèles de fondation différents » (leçon 75). Un modèle de fondation est le grand modèle d'IA de départ, comme Claude. Il faut un nombre impair d'agents pour éviter les égalités, avec un chemin prévu pour le désaccord. Trois copies du même prompt, c'est payer trois fois la même erreur. Un prompt est la consigne donnée à l'agent.

BMAD en dit moins, et le livre ne s'accorde pas avec lui-même :

• La leçon 31 décrit une revue qui lance trois agents en parallèle. La leçon 18 affirme que la même revue suit trois passes en séquence.
• La leçon 42 répond à « peut-on lancer plusieurs stories en parallèle ? » par oui, sous conditions. Il faut personnaliser le workflow pour découper par couche plutôt que par tranche verticale, ou confier des epics indépendants à des responsables différents. Ce conseil décrit une équipe de personnes, pas des agents.
• Le Party Mode charge tous les agents dans une même discussion pour avoir plusieurs points de vue (leçon 7) : un seul fil de conversation.
• BMAD Loop est un orchestrateur issu de la communauté, un programme qui lance les étapes dans l'ordre. Il enchaîne les workflows en séquence (leçon 31).

Aucun des deux ne dit combien d'agents lancer à la fois, ni ce que ça coûte, ni comment ils s'en sortent sur un vrai dépôt.

Voici ce que je fais, sans prétendre que ce soit la bonne réponse. Les relectures de plusieurs fiches tournent en parallèle, deux ou trois agents à la fois sur mon serveur (un chiffre de confort, pas une mesure). Chacun écrit son rapport dans un fichier, et je commite entre deux tours. Ce schéma recoupe ce que le livre d'Arsanjani appelle incremental checkpointing : sauvegarder chaque étape pour qu'un lot interrompu reparte des fichiers déjà écrits. Le rapprochement est de moi, le livre ne l'applique pas à des agents de code.

Quel livre lire selon ton profil

Agentic Architectural Patterns (Arsanjani et Bustos) : 5,6 sur 10 sur ma fiche, note provisoire. C'est un catalogue d'une cinquantaine de patterns. Il nomme bien les pannes et ne mesure rien : pas un benchmark, des gains non sourcés, du code qui simule le modèle.

Ses premières sections sont du contexte d'entreprise teinté Google Cloud, à survoler. Elles couvrent le choix du modèle, le RAG (faire chercher des documents à l'agent) et le fine-tuning (réentraîner le modèle). Lis-le si tu pilotes déjà des agents et que tu cherches des mots pour tes pannes de boucle. Commence par les leçons 110 à 112, 114 et 115.

Si tu n'as jamais écrit d'agent, commence par AI Engineering de Chip Huyen (la fiche). Il est plus solide sur les fondations et sur la mesure de la qualité. Entre Huyen et Arsanjani, Huyen d'abord : Arsanjani vient ensuite, en lecture ciblée.

Spec-Driven Development with BMAD (Ferreira) : 5,2 sur 10 sur ma fiche, note provisoire. C'est un cours court de 3 h 20, un mode d'emploi d'outil. Il est daté : l'auteur prévient que son cours « pourrait contenir des informations périmées » (leçon 6). Il est lié à Cursor, l'éditeur de code à IA dont il est ambassadeur au Brésil.

À lire pour ses boucles de contrôle (tests rouges, porte, revue, rétrospective) et sa règle de la session neuve, en diagonale pour le reste. Il convient mieux à une petite équipe qu'à quelqu'un qui code seul. Le livre le dit lui-même (« un processus d'équipe, pas un outil solo », leçon 45).

Conclusion

J'ai cherché des livres qui m'apprennent à faire travailler des agents ensemble. Ce qui m'a le plus servi, c'est ce que chaque agent n'a pas le droit de croire de l'autre. Exemples : le juge qui applaudit un try/except, le relecteur qui lit des notes au lieu du texte. Arsanjani décrit la coopération avec du code qui simule les agents, et BMAD avec des démonstrations d'outil. Aucun des deux ne dit ce que ça donne avec dix agents réels sur un dépôt.

Alors, plus avancés que ce que je pratique ? Sur le vocabulaire des pannes de boucle, oui : collusion, divergence et ancrage externe m'ont servi. Sur la mécanique d'une boucle de relecture et sur des agents de code en parallèle, non. Aucun des deux ne fixe de seuil de sortie ni de plafond de tours pour une boucle de relecture. Aucun ne donne de nombre d'agents à lancer à la fois. Ma boucle fait déjà tout ça.

Je n'ai pas trouvé de livre qui chiffre le parallèle. Le chiffre de mon serveur, deux ou trois agents, est un réglage de confort, pas une mesure, et j'aimerais lire quelqu'un qui en ait une.