Analyse
Three-Agent Harness Anthropic : Planner / Generator / Evaluator pour PME 2026
Le 24 mars 2026, Anthropic Engineering a publié un retour terrain sur le design des « harnesses » d’agents long-running — c’est-à-dire la couche qui orchestre un agent IA capable de coder, lire, exécuter et raisonner pendant plusieurs heures sur une tâche unique. L’article, signé par Prithvi Rajasekaran (Member of Technical Staff, Applied AI), a fait l’objet d’une large couverture presse tech à partir du 4 avril 2026 (InfoQ, Medium, vktr.com). Sa conclusion : qu’un seul agent — même Opus 4.7 — n’est pas suffisant pour des résultats production-ready sur des sessions multi-heures. La solution proposée s’appelle le three-agent harness Planner-Generator-Evaluator, et le pattern est directement applicable pour les PME qui veulent passer leurs agents Claude en production sans dégradation qualité après 30 minutes.
Pourquoi un seul agent ne suffit plus en 2026
L’article Anthropic identifie un biais comportemental constant chez les agents agentiques en mai 2026 :
« Les agents ont tendance à louer leur travail avec assurance — même quand, pour un observateur humain, la qualité est manifestement médiocre. »
Ce phénomène — le self-grade inflation problem — est aggravé sur les tâches longues, où l’agent finit par justifier ses propres décisions précédentes plutôt que les remettre en question. Trois solutions ont été testées par Anthropic :
| Approche | Limites observées |
|---|---|
| Agent solo + auto-review | Self-grade systématique, faux positifs |
| Agent solo + checklist humaine | Coût humain élevé, pas scalable |
| 3-agent harness PGE | Suppression du biais via séparation des contextes |
C’est l’option 3 qui s’impose comme pattern de référence pour les workflows de plus de 30 minutes en 2026.
L’architecture des 3 agents
1. Planner — l’architecte
Le Planner reçoit une consigne courte (1 à 4 phrases utilisateur) et la transforme en specification produit complète. Sa contrainte principale : viser l’ambition et le design haut niveau, pas les détails techniques. La raison est documentée dans l’article : sur-spécifier les exigences au niveau Planner crée des erreurs en cascade dans le Generator (chaque détail erroné devient une contrainte rigide).
flowchart TB
User[Demande utilisateur<br/>1-4 phrases] -->|Input| Planner
Planner -->|Output| Spec[Product Spec<br/>scope ambitieux,<br/>design haut niveau]
Spec -->|Handoff fichier| Generator
Generator -->|Implémente itérativement,<br/>git version control| Code[Code + tests]
Code -->|Sprint contract<br/>négocié| Evaluator
Evaluator -->|Playwright,<br/>tests bout-en-bout| Verdict{Verdict}
Verdict -->|OK| Done[Production-ready]
Verdict -->|Bugs / gaps| Generator2. Generator — l’implémenteur
Le Generator implémente le code itérativement. Dans le retour terrain Anthropic, il opère sur une stack moderne et réaliste pour PME — React + Vite + FastAPI + SQLite ou PostgreSQL. Son trait distinctif : il auto-évalue son travail avant le handoff, mais sa note ne fait pas autorité — c’est l’Evaluator qui tranche. Le Generator garde un git versionné (commits, branches) pour permettre des rollbacks.
3. Evaluator — le contrôleur indépendant
L’Evaluator est l’innovation centrale : il n’a pas accès au contexte ni au raisonnement du Generator. Il reçoit uniquement les artefacts livrés (code, tests, démos) et le sprint contract négocié en amont. Pour les tâches frontend, il utilise Playwright (un framework de test E2E) pour interagir avec l’app comme un utilisateur final — clics, saisies, vérifications visuelles. Il identifie bugs, gaps d’usabilité et problèmes de qualité de code.
Sprint Contracts : le contrat ce qui veut dire « fait »
Avant qu’une feature soit codée, le Generator et l’Evaluator négocient explicitement ce que veut dire « terminé ». Le Sprint Contract est un fichier JSON ou Markdown signé par les deux agents qui contient :
- User stories réécrites en critères testables
- Liste de checkpoints (boutons, formulaires, endpoints API)
- Cas d’erreur attendus et comportements
- Critères de qualité (accessibilité, perf, tests unitaires)
L’Evaluator s’engage à ne pas changer ces critères en cours de route — il les utilise mécaniquement pour valider. Le Generator s’engage à les couvrir tous.
Structured Artifacts : la mémoire entre sessions
Les agents ne partagent pas de contexte mémoire — ils communiquent via fichiers. C’est le second pilier qui rend le pattern scalable :
product-spec.md: output Planner, input Generatorsprint-contract.json: sortie négociation Generator/Evaluatorprogress.txt: journal append-only du Generator (commits, blocages, dépendances installées)evaluation-report.md: verdict Evaluator avec liste bugs détectés
Cette approche évite l’inflation de contexte (chaque agent a une fenêtre vide en début de session) et préserve un audit trail lisible pour les humains. C’est une mécanique très proche de celle décrite par Anthropic dans son article complémentaire Effective harnesses for long-running agents — qui couvre la persistance via le Memory tool client-side ou les Managed Agents qui historisent les events côté serveur.
Métriques publiées par Anthropic
L’article fournit deux benchmarks chiffrés sur des projets jouets, mais représentatifs :
| Projet | Architecture | Durée | Coût | Qualité finale |
|---|---|---|---|---|
| Retro game maker | Solo Opus 4.7 | 20 min | 9 $ | Variable, debug humain nécessaire |
| Retro game maker | 3-agent harness PGE | 6 h | 200 $ | Production-ready |
| DAW application (browser) | Harness simplifié 2 agents sur Opus 4.6 | 3 h 50 min | 124,70 $ | Production-ready |
Le ratio coût × 22 entre solo et harness PGE est élevé en absolu, mais à mettre en regard du coût d’un développeur humain (200 $ = ~2 h de senior) et de l’absence de review nécessaire derrière. Pour les PME, le sweet spot est les tâches qui nécessitent une qualité production sans review ligne par ligne : intégrations, scripts de migration, dashboards interne, refactos.
Application à des cas d’usage PME en 2026
Le pattern n’est pas réservé au coding. Trois adaptations transposables aux workflows business :
Cas 1 — Génération de rapports clients automatisés
- Planner : transforme « rapport mensuel d’activité client X » en spec détaillée (sections, chartss, métriques attendues).
- Generator : extrait les données via MCP CRM, calcule, met en forme.
- Evaluator : vérifie cohérence chiffres, complétude des sections, lisibilité (Playwright peut ouvrir le PDF généré et grep sa structure).
Cas 2 — Refonte UI/UX d’un dashboard interne
- Planner : transforme « moderniser le dashboard finance » en spec Figma-textuelle ambitieuse.
- Generator : code en React + Tailwind + Recharts.
- Evaluator : test Playwright responsive 320 / 768 / 1280, accessibility audit, screenshots comparatifs.
Cas 3 — Migration de base de données
- Planner : spec de la migration (schéma cible, contraintes business, rollback strategy).
- Generator : écrit migrations SQL + tests d’idempotence + script de bascule.
- Evaluator : exécute en sandbox PostgreSQL, vérifie contraintes, performance des requêtes critiques.
Sur quel modèle Claude faire tourner chaque agent ?
L’article Anthropic teste implicitement Opus 4.6 et Opus 4.7. Pour une PME qui veut optimiser cost/perf, le pattern de routing est le suivant :
| Agent | Modèle recommandé | Raison |
|---|---|---|
| Planner | Opus 4.7 | Décisions structurantes, raisonnement haut niveau, peu de tokens consommés |
| Generator | Sonnet 4.6 (ou Opus 4.7 sur tâches complexes) | Volume de tokens élevé, Sonnet 4.6 reste le meilleur coding model pour le coût |
| Evaluator | Opus 4.7 | Détection biais, raisonnement croisé sur sprint contract |
Le routing fin entre Haiku 4.5 / Sonnet 4.6 / Opus 4.7 est détaillé dans notre guide architecture multi-agents Haiku 4.5 + Sonnet 4.6 cost-perf. Le 3-agent harness PGE peut aussi tourner intégralement sur Managed Agents avec un agent par session, ou en self-hosted via le Computer Use Agent SDK.
Évolution du pattern avec les modèles 2026
Anthropic note dans l’article que la complexité du harness peut être réduite à mesure que les modèles progressent. Concrètement :
- Sur Opus 4.6 (février 2026), l’Evaluator devient parfois optionnel sur des tâches courtes (moins de 30 min)
- Sur Opus 4.7 (avril 2026, qui apporte la self-verification native), un harness à 2 agents (Planner + Generator) suffit sur de nombreuses tâches modérées
- Pour des tâches multi-heures critiques (refonte app, codebase complète), le 3-agent reste prudent
Ce point rejoint la philosophie générale 2026 : le pattern d’orchestration dépend du modèle ET de la difficulté de la tâche. Pour la PME, le bon réflexe est de commencer en harness 2-agents sur Opus 4.7 et n’ajouter l’Evaluator que sur les workloads qui nécessitent un contrat qualité ferme.
Trois recommandations pour intégrer le pattern PGE en PME 2026
- Démarrer avec un cas d’usage borné (génération rapport, migration DB, refonte page interne) — pas avec une refonte d’app entière. Le pattern PGE coûte 20× le solo agent ; il faut que le surcoût soit justifié par un livrable mesurable.
- Investir 2-3 jours dans le sprint contract avant le premier run — c’est ce qui détermine la qualité finale. Un Sprint Contract flou = un Evaluator perdu.
- Logger en JSON les Structured Artifacts dans un Git ou un bucket S3 — c’est votre audit trail. Pour les PME en secteur régulé (santé, finance, légal), c’est aussi un argument fort de conformité face à un audit.
Le 3-agent harness PGE n’est pas une promesse magique — c’est un pattern d’ingénierie issu d’observations terrain Anthropic, qui demande d’investir dans l’outillage avant de déployer en production. Mais sur les workflows long-running où la qualité est non négociable, c’est l’architecture la plus solide publiée en 2026 à ce jour.
FAQ
Quelle est la différence entre le pattern Planner-Generator-Evaluator et un agent unique boosté Opus ?
La différence centrale est l’auto-évaluation. Un agent unique tend à valider son propre travail de façon trop optimiste — Anthropic le formule explicitement dans son article d’avril 2026 : « les agents ont tendance à louer leur travail avec assurance, même quand pour un observateur humain la qualité est manifestement médiocre ». Séparer l’Evaluator dans un troisième agent (avec un contexte distinct) supprime ce biais de self-grade, à la manière des GAN où le générateur et le discriminateur sont entraînés indépendamment. C’est particulièrement décisif sur les tâches de plus de 30 minutes où la dérive cumule.
Le pattern PGE est-il rentable pour une PME en 2026 ?
Oui dès lors que la tâche dure plus de 30 minutes en agent unique et que la qualité finale a une valeur métier. Le rapport coût/bénéfice publié par Anthropic est éloquent : sur la création d’un retro game maker, l’agent solo finit en 20 min pour 9 $ mais avec qualité variable ; le harness 3-agents atteint un résultat de production en 6 h pour 200 $. Pour une PME, le seuil de bascule est : si le résultat doit être merge en production sans review humaine ligne par ligne, le harness PGE devient rentable. Pour des prototypes jetables ou des PoC, l’agent unique reste meilleur ROI.
Avec Claude Opus 4.7, faut-il encore conserver le 3ème agent (Evaluator) ?
L’article Anthropic note que la complexité du harness peut être réduite à mesure que les modèles progressent — leurs propres tests montrent qu’avec Claude Opus 4.6 l’Evaluator devient parfois optionnel sur des tâches modérées. Avec Opus 4.7 (avril 2026) qui apporte de la self-verification native, on peut envisager un harness 2-agents (Planner + Generator) pour des tâches courtes à moyennes. Mais sur les workloads vraiment longs (codebase complète, refonte d’app, ventes B2B avec recherche prolongée), garder l’Evaluator reste prudent en 2026.
Quel framework technique sous-jacent utiliser pour implémenter le pattern PGE ?
Trois options viables en 2026 selon votre niveau de souveraineté souhaité : (1) Claude Managed Agents — vous créez 3 agents distincts dans Anthropic et orchestrez leurs sessions via API ; rapide à mettre en place, mais data passe par Anthropic. (2) Claude Agent SDK self-hosted — vous codez l’orchestration en Python/TS sur votre infra ; full contrôle, mais DevOps requis. (3) Frameworks tiers type LangGraph ou CrewAI — qui implémentent ce pattern par-dessus Claude API ; intermédiaire, mais dépendance à un layer additionnel. Pour une première mise en prod, Managed Agents reste la voie la plus rapide.
Le pattern fonctionne-t-il pour des workflows non-coding (rédaction, recherche, négociation B2B) ?
Oui, et l’article Anthropic le suggère sans le détailler. Pour la rédaction longue : Planner = brief + outline ambitieux ; Generator = rédaction itérative ; Evaluator = fact-checking + cohérence (avec WebFetch). Pour la négociation B2B : Planner = stratégie + objectifs ; Generator = drafts d’emails et propositions ; Evaluator = vérification anti-engagement risqué + alignement légal. Le pattern PGE est agnostique au domaine — c’est la séparation des contextes qui apporte la valeur.