Conception de faisceaux : comment orchestrer des agents IA sur la durée

#Pourquoi un agent seul ne suffit pas

Donne un brief de quelques phrases à Claude et lance-le sur un projet complet. En 20 minutes et 9 dollars, tu obtiens un résultat. Mais ce résultat est souvent décevant : des fonctionnalités cassées, un workflow mal pensé, une interface générique.

C'est le constat de départ de l'équipe d'ingénierie d'Anthropic dans leur article sur la conception de faisceaux pour applications longue durée. Un agent IA livré à lui-même se heurte à deux problèmes fondamentaux : il gère mal son contexte sur la durée, et il est incapable d'évaluer honnêtement son propre travail.

La solution ? Un faisceau (harness) — un programme qui orchestre plusieurs agents spécialisés, chacun avec un rôle précis. Cet article explore les architectures proposées par Anthropic et les principes de conception qui les rendent efficaces.

#Le problème de l'auto-évaluation

Quand tu demandes à un agent d'évaluer le travail qu'il vient de produire, il fait ce que ferait un développeur trop attaché à son code : il le trouve excellent. Même quand la qualité est manifestement médiocre.

Ce biais est systématique. L'agent qui a généré du code a un "investissement émotionnel" dans sa production. Il va rationaliser les choix douteux et minimiser les défauts. C'est le même mécanisme que la relecture de son propre texte — on voit ce qu'on avait l'intention d'écrire, pas ce qui est réellement écrit.

La solution d'Anthropic s'inspire d'un concept bien connu en machine learning : les réseaux antagonistes génératifs (GANs). Dans un GAN, un réseau génère du contenu pendant qu'un autre l'évalue. Les deux sont en tension : le générateur essaie de produire quelque chose d'assez bon pour tromper l'évaluateur, et l'évaluateur essaie de détecter les failles.

Appliqué aux agents IA, ça donne une architecture où la génération et l'évaluation sont séparées dans deux agents distincts. L'évaluateur n'a aucun lien avec le processus de création — il juge le résultat froid, sans complaisance.

#La boucle générateur-évaluateur pour le design frontend

Pour le design d'interfaces, Anthropic a mis en place une boucle itérative entre deux agents.

Le générateur produit une page web à partir d'un brief. L'évaluateur examine le résultat en interagissant avec la page comme un vrai utilisateur (via Playwright, un outil d'automatisation de navigateur), puis rend un verdict basé sur quatre critères :

La boucle tourne entre 5 et 15 itérations. À chaque tour, l'évaluateur pointe les faiblesses, et le générateur corrige. C'est un processus de raffinement progressif, pas une tentative de tout réussir du premier coup.

#L'architecture à trois agents pour le full-stack

Pour des projets plus complexes (applications full-stack), Anthropic ajoute un troisième rôle : le planificateur. L'architecture devient :

#Le planificateur

Il reçoit un brief de 1 à 4 phrases et le transforme en spécification complète. Point crucial : il évite délibérément les détails techniques granulaires. Pourquoi ? Parce qu'une spécification trop détaillée crée des erreurs en cascade. Si le planificateur prescrit une structure de base de données précise et qu'elle s'avère inadaptée en pratique, tout le reste s'effondre.

Le planificateur définit le quoi, pas le comment. Il laisse au générateur la liberté de choisir l'implémentation.

#Le générateur

Il implémente les features de manière itérative. Dans les expériences d'Anthropic, la stack utilisée était React + Vite côté frontend, FastAPI côté backend, avec SQLite ou PostgreSQL pour la base de données. Mais le principe est indépendant de la stack.

#L'évaluateur

Il vérifie le travail du générateur en utilisant des sprint contracts — des contrats de sprint définis avant le début du codage. Un sprint contract décrit précisément ce qui doit fonctionner à la fin d'un sprint. L'évaluateur exécute des tests automatisés (toujours via Playwright) pour vérifier chaque point du contrat.

#Sprint contracts : l'accord avant le code

Les sprint contracts sont au cœur de l'architecture. Ils résolvent un problème fréquent chez les agents : la dérive par rapport aux objectifs.

Sans contrat explicite, un agent peut implémenter 80 % d'une feature, déclarer victoire, et passer à la suite. Le contrat de sprint empêche ça en fixant des critères de complétion mesurables avant que l'implémentation commence.

Le flux ressemble à ça :

1. Le planificateur découpe le projet en sprints
2. Pour chaque sprint, il définit un contrat avec des critères précis
3. Le générateur implémente le sprint
4. L'évaluateur vérifie chaque critère du contrat
5. Si un critère échoue, le générateur recommence cette partie

C'est un processus discipliné qui imite les meilleures pratiques du développement logiciel humain — mais avec un avantage : la boucle de feedback est instantanée.

#Agent solo vs faisceau complet : les résultats

Anthropic a comparé les deux approches sur un même projet (un créateur de jeux vidéo rétro) :

Le rapport coût-bénéfice est clair : le faisceau coûte 22 fois plus cher et prend 18 fois plus de temps, mais il produit un résultat réellement utilisable. L'agent solo crée une illusion de productivité — du code est généré rapidement, mais il ne fonctionne pas.

#L'anxiété de contexte

Un phénomène inattendu identifié par Anthropic : l'anxiété de contexte. Quand un agent approche de la limite de sa fenêtre de contexte, il commence à bâcler son travail. Il conclut prématurément, saute des étapes, prend des raccourcis.

C'est comme un développeur qui sait que sa journée se termine dans 30 minutes — il va committer du code à moitié fini plutôt que de risquer de perdre son travail.

Deux stratégies pour gérer ce problème :

• La compaction : résumer les échanges précédents pour libérer de la place dans le contexte. Ça aide, mais ça ne suffit pas — le résumé perd des détails importants
• Le reset de contexte : vider complètement la fenêtre et démarrer une nouvelle session avec un handoff structuré. Plus radical, mais plus efficace

Le reset de contexte est la stratégie privilégiée dans les faisceaux d'Anthropic. Chaque nouvelle session reçoit un résumé structuré de l'état du projet, pas un historique conversationnel. L'agent repart avec un contexte propre et ciblé.

#Le principe d'évolution : chaque composant est une hypothèse

C'est peut-être la leçon la plus importante de l'article d'Anthropic. Chaque composant d'un faisceau encode une hypothèse sur ce que le modèle ne sait pas faire seul.

Le sprint contract suppose que l'agent ne peut pas maintenir le cap sans objectif explicite. L'évaluateur séparé suppose que l'agent ne peut pas juger son propre travail. Le planificateur suppose que l'agent ne peut pas décomposer un projet complexe en étapes cohérentes.

Mais les modèles s'améliorent. Avec l'arrivée de Claude Opus 4.6, l'auteur de l'article a pu retirer le mécanisme de sprint contracts sans perte de qualité. Le modèle avait suffisamment progressé en planification et en suivi de contexte pour maintenir le cap sans cette béquille.

Ça veut dire quoi en pratique ? Que tes faisceaux doivent être conçus pour être simplifiés. Chaque composant que tu ajoutes devrait avoir une raison d'être documentée et être régulièrement testé : est-ce que l'agent peut s'en passer maintenant ?

Un faisceau trop rigide empêche le modèle d'utiliser ses capacités réelles. Un faisceau absent le laisse échouer sur ses faiblesses. L'art est dans l'équilibre.

#Construire son propre faisceau

Si tu veux appliquer ces principes à tes projets, voici une approche progressive :

#Commence simple

Un faisceau minimal avec deux agents (générateur + évaluateur) couvre déjà 80 % des cas. Le générateur écrit le code, l'évaluateur le teste via des outils d'automatisation.

# Boucle basique générateur-évaluateur
while true; do
  # Génération
  claude --print "Implémente la feature suivante : $FEATURE"

  # Évaluation
  RESULT=$(claude --print "Teste la feature $FEATURE en utilisant Playwright. Retourne PASS ou FAIL avec les détails.")

  if echo "$RESULT" | grep -q "PASS"; then
    echo "Feature validée."
    break
  fi
done

#Ajoute un planificateur si nécessaire

Si ton projet dépasse 5-6 features, un planificateur qui découpe le travail en sprints évite la dérive. Il n'a pas besoin d'être un agent séparé — ça peut être une étape initiale dans ton script.

#Documente les hypothèses

Pour chaque composant de ton faisceau, note pourquoi il existe. Exemple :

## Composants du faisceau

- **Évaluateur séparé** : le modèle ne juge pas objectivement son propre code (testé avec Sonnet 4.5, toujours vrai avec Opus 4.6)
- **Sprint contracts** : retiré depuis Opus 4.6 — le modèle maintient le cap sans contrat explicite
- **Reset de contexte** : nécessaire au-delà de 80k tokens de contexte

#Teste régulièrement la valeur de chaque composant

À chaque nouvelle version de modèle, retire un composant et compare les résultats. Si la qualité reste identique, le composant est devenu inutile — supprime-le.

#Ce qu'il faut retenir

La conception de faisceaux pour agents IA n'est pas un problème technique — c'est un problème d'architecture de collaboration. Les mêmes principes qui font fonctionner les équipes humaines (séparation des rôles, critères de qualité explicites, feedback rapide) s'appliquent aux agents.

Les trois principes fondamentaux :

1. Séparer la génération de l'évaluation — un agent ne peut pas juger objectivement son propre travail
2. Définir les critères de succès avant l'implémentation — les sprint contracts empêchent la dérive
3. Traiter chaque composant comme une hypothèse temporaire — les modèles évoluent, tes faisceaux doivent évoluer aussi

Pour aller plus loin, consulte l'article original d'Anthropic sur la conception de faisceaux et son compagnon sur les harnesses efficaces pour agents long-running.