SynoptïaDes surnoms, et des rôles assez précis
Je les appelle Fafa, Soso et Grob. Dans le post où je présentais cette organisation, Fable conduisait le travail, Sol examinait le plan puis les changements avant livraison, et Grok pouvait reprendre des corrections sur sa propre branche.
Je n’écris pas le code. Je définis ce que je veux obtenir et j’arbitre quand leurs conclusions divergent. Cette répartition ne fait pas disparaître la responsabilité du résultat. Elle me donne davantage de matière pour l’assumer.
Sur THÉRÈSE, le premier duo avait déjà produit deux refus de livraison. L’un de ces retours recensait douze points, dont quatre vulnérabilités préexistantes. C’est le constat rapporté dans ce post, pas une mesure du taux de réussite de tous mes agents.
Donner autre chose qu’un résumé flatteur
Si le premier agent explique que tout est terminé et que le second ne lit que son explication, le contrôle commence avec un handicap. Il manque les pièces.
Je conseille de transmettre la demande initiale, les fichiers concernés et les critères d’acceptation. Le rapport du premier agent peut aider à se repérer, mais le relecteur doit pouvoir consulter le résultat directement.
Sur du code, cela signifie regarder les changements et les contrôles exécutés. Pour un article, cela signifie relire les sources derrière les affirmations. Pour un tableur, il faut examiner les formules et les cas limites, puis ouvrir le fichier. La seconde opinion a besoin d’un objet concret.
Examiner le plan avant de payer la correction
Une relecture en fin de tâche arrive parfois trop tard : la mauvaise hypothèse a déjà été déclinée dans plusieurs écrans ou documents.
Pour un travail important, je trouve utile de demander un avis sur le plan avant l’exécution. Le relecteur peut relever une information manquante, une modification inutile ou un résultat impossible à vérifier. Une petite correction locale n’a pas besoin de cette cérémonie à chaque fois.
La mission peut rester courte : « Qu’est-ce qui empêche ce plan de répondre à la demande ? Donne les points bloquants avec une preuve ou une question à résoudre. » On cherche de quoi décider, pas une collection d’objections pour le plaisir.
Quand les deux ne sont pas d’accord
Un désaccord est utile s’il devient vérifiable. Le relecteur annonce une régression ? Qu’il montre l’action qui échoue. Le premier agent affirme que le problème existait déjà ? Qu’il compare avec l’état précédent.
Certains écarts restent des choix. Un menu peut être plus compact mais moins facile à découvrir. Dans ce cas, les agents peuvent exposer les conséquences ; le responsable du produit tranche en fonction de ses utilisateurs.
Je conserve aussi les réserves non résolues. Un « oui, mais je n’ai pas pu ouvrir le fichier » ne vaut pas un contrôle du fichier. Cette distinction évite de transformer une limite d’accès en certificat de qualité.
Corriger et publier sont deux actions distinctes
Dans l’organisation décrite sur LinkedIn, Grob travaillait sur sa branche sans permission de publier. C’est un détail important : une correction peut être préparée et examinée avant de toucher le résultat utilisé par d’autres personnes.
Je recommande le même principe pour les documents et les messages : une copie de travail, des changements visibles, puis une validation adaptée à l’action. Ajouter un relecteur ne doit pas élargir discrètement les droits de l’équipe.
Deux avis ne font pas une garantie
Les agents peuvent manquer la même information ou suivre le même raisonnement fragile. Leur accord ne remplace ni un calcul vérifié ni un essai dans l’application. Et si chaque avis ouvre une nouvelle boucle sans fin, le contrôle devient lui-même un problème de coût.
Je garderais donc cette organisation pour les travaux qui justifient le second regard, avec une condition de fin explicite. Le prochain apprentissage viendra du résultat que l’on aura réellement essayé.
Pour prolonger : la visite visuelle de THÉRÈSE et le coût des boucles d’agents. Le parcours PROPULSER, avec Claude Code ou Codex, permet de travailler cette méthode sur vos propres usages.