Claude Opus 4.6 et les équipes d'agents : comment construire un workflow multi-agents

Anthropic a sorti Opus 4.6 le 5 février. Une fonctionnalité m'a marqué plus que les scores de benchmarks : les équipes d'agents. Une session Claude Code peut désormais lancer plusieurs agents indépendants, chacun avec sa propre fenêtre de contexte, qui travaillent sur différentes parties d'un projet en même temps.

Je les utilise sur des projets réels depuis le jour du lancement. Voici ce que j'ai retenu.

Ce que sont les équipes d'agents

Dans une session Claude Code classique, tu parles à un seul agent. Il lit des fichiers, écrit du code, lance des tests. Pour paralléliser, tu peux créer des sous-agents mais ce sont des exécutants ponctuels : ils font une tâche et renvoient le résultat. Aucune communication entre eux.

Les équipes d'agents changent ça. Un agent lead (ta session principale) crée une équipe, lance des coéquipiers et coordonne le tout via une liste de tâches partagée. Chaque coéquipier est une instance Claude Code complète avec sa propre fenêtre de contexte. Les coéquipiers s'envoient des messages directement, prennent des tâches dans la liste partagée et travaillent sur des fichiers séparés en parallèle.

Une petite équipe de dev, en somme. Le lead joue le tech lead qui découpe le travail. Les coéquipiers sont des développeurs : chacun prend son morceau, communique quand il le faut, rend compte à la fin.

Les outils de coordination

Le lead et les coéquipiers partagent le même jeu d'outils.

TeamCreate initialise une équipe. L'outil écrit un fichier de configuration et crée un répertoire de tâches partagé sur le disque. Chaque équipe a un nom qui sert d'espace de noms.

TaskCreate et TaskUpdate gèrent le travail. Le lead crée des tâches dont les descriptions servent de prompts pour celui qui les prend. Trois états possibles : en attente, en cours, terminée. Une tâche peut dépendre d'une autre : la tâche B ne se débloque qu'une fois la tâche A finie.

SendMessage gère la communication. Un coéquipier envoie un message direct à un agent précis ou diffuse à tout le monde. Le lead est notifié automatiquement quand un coéquipier termine ou passe en veille.

TaskList montre à chaque agent le travail disponible, qui fait quoi, ce qui est bloqué. Un coéquipier qui finit une tâche consulte la liste et prend le prochain élément débloqué.

Tout ça vit sur le disque, en JSON, dans ~/.claude/teams/ et ~/.claude/tasks/. La prise de tâches passe par un verrouillage de fichier : deux coéquipiers ne peuvent pas saisir le même travail.

Une session type

Je construis une fonctionnalité qui demande une migration de base de données, un endpoint API et des composants frontend. Je dis à Claude :

"Crée une équipe d'agents. Un coéquipier gère la migration, un autre construit la route API, le troisième travaille sur les composants React."

Le lead crée trois tâches, lance trois coéquipiers, assigne à chacun sa partie. Chaque coéquipier reçoit le contexte complet du projet (CLAUDE.md, serveurs MCP, skills installées) plus la description de sa tâche. Il n'hérite pas de l'historique de conversation du lead. La description de la tâche porte donc tout le poids.

Dans mon terminal, je navigue entre les coéquipiers avec Shift+Bas pour voir où ils en sont ou donner une instruction de plus. Avec tmux, chaque coéquipier a son propre panneau, je vois tout le travail en cours d'un coup d'oeil.

Les coéquipiers avancent en indépendance. Le coéquipier migration finit le schéma, marque sa tâche terminée. Le coéquipier API, qui attendait ce schéma, se débloque tout seul et enchaîne. Le coéquipier frontend, lui, travaillait déjà sur les composants depuis le début : aucune dépendance à attendre.

Quand les équipes d'agents apportent vraiment quelque chose

Après plusieurs semaines d'usage, le schéma est net.

La recherche en parallèle, c'est l'usage que je fais le plus souvent. Trois coéquipiers explorent différents aspects d'un problème puis confrontent leurs conclusions. La recherche séquentielle souffre d'un biais d'ancrage : dès qu'une réponse plausible apparaît, on arrête de chercher. Avec plusieurs enquêteurs, ce problème disparaît.

Ça marche aussi très bien quand le travail se répartit naturellement en fichiers séparés. Frontend d'un côté, backend de l'autre, tests à part : chaque coéquipier possède sa partie, zéro conflit.

La revue de code suit la même logique. Un coéquipier sur la sécurité, un sur la performance, un sur la couverture de tests. Un relecteur seul se fixe souvent sur une seule catégorie de problèmes ; trois spécialistes en parallèle en attrapent davantage.

Mon pattern préféré : le débogage par hypothèses concurrentes. Cinq coéquipiers testent chacun une théorie différente sur l'origine d'un bug, en essayant activement de réfuter les théories des autres. Celle qui survit a de bonnes chances d'être la bonne.

Quand elles sont contre-productives

Les équipes d'agents ne sont pas toujours le bon outil. J'ai gaspillé des tokens pour le vérifier.

Si l'étape 2 dépend du résultat de l'étape 1, un agent seul va plus vite. Le coût de coordination ne se justifie pas quand la plupart des coéquipiers attendent.

Deux coéquipiers qui éditent le même fichier finissent par écraser le travail l'un de l'autre. Je l'ai appris à mes dépens. Il faut découper le travail pour que chacun soit propriétaire de fichiers différents, sinon le temps passé à résoudre les conflits dépasse le temps gagné à paralléliser.

Ne crée pas une équipe pour renommer une variable. Si un agent seul met cinq minutes, le surcoût de coordination n'a aucun sens. Même chose quand chaque tâche dépend de toutes les autres : le parallélisme s'effondre et tu paies plusieurs fenêtres de contexte pour des agents qui attendent.

L'expérience du compilateur C

Anthropic a mené le test le plus ambitieux à ce jour : confier à 16 agents parallèles la construction d'un compilateur C en Rust, à partir de zéro. Près de 2 000 sessions, 2 milliards de tokens en entrée, un coût d'environ 20 000 $. Résultat : 100 000 lignes de code.

Le compilateur construit Linux 6.9 sur x86, ARM et RISC-V. Il compile QEMU, FFmpeg, SQLite, PostgreSQL et Redis. Il passe 99 % de la suite de tests GCC torture. Il fait tourner Doom.

Le mécanisme de coordination restait simple : les agents verrouillaient les tâches via des fichiers texte, tiraient les changements, fusionnaient, poussaient. La vraie découverte portait sur la qualité des tâches. Face au noyau Linux, une tâche géante et interconnectée, les 16 agents se sont rués sur le même bug, l'ont corrigé en parallèle et ont écrasé leurs modifications respectives. Le parallélisme ne fonctionne que si les tâches sont réellement indépendantes.

L'autre enseignement critique : "le vérificateur de tâches doit être quasi parfait, sinon Claude résout le mauvais problème." Des tests solides sont le socle du travail autonome des agents.

Conseils pratiques

La description de la tâche, c'est le prompt. Reste vague ("gère le truc base de données") et le coéquipier va faire des hypothèses non souhaitées. Sois précis sur les fichiers, le comportement attendu, les contraintes. Cinq minutes de rédaction soignée économisent une heure de travail gaspillé par l'agent.

Pour découvrir les équipes d'agents, évite de sauter directement dans l'implémentation parallèle. Lance une revue de code en parallèle. Fais chercher différentes bibliothèques par tes coéquipiers. Les contours sont nets, le risque faible. Tu prends le rythme sans miser une feature dessus.

Laisser une équipe tourner trop longtemps sans supervision coûte cher. Vérifie l'avancement des coéquipiers, redirige les approches qui ne mènent nulle part, arrête ceux qui dérivent. Je vise 5 à 6 tâches par coéquipier : assez petit pour garder un rythme de points de contrôle, assez grand pour que chaque tâche produise un livrable clair.

Un détail agaçant : chaque fois qu'un coéquipier demande une permission manquante, la requête remonte au lead. Pré-approuve les opérations fréquentes dans les paramètres de permissions avant de lancer l'équipe. Sinon tu passes la moitié de la session à cliquer "approuver".

Limites actuelles

Les équipes d'agents restent en research preview. Quelques points à connaître.

Impossible de reprendre des coéquipiers après un redémarrage de session. Fais /resume et le lead risque d'envoyer des messages à des coéquipiers qui n'existent plus. Il faudra en créer de nouveaux.

Les tâches ne sont pas toujours marquées comme terminées correctement, ce qui bloque les tâches dépendantes. Quelque chose semble coincé ? Vérifie si le travail est réellement fait et mets le statut à jour à la main.

Seul le lead gère l'équipe. Les coéquipiers ne créent pas leurs propres équipes, ne se promeuvent pas. Une équipe par session, un lead par équipe.

Le contexte ne persiste pas entre les sessions. Chaque coéquipier démarre avec le contexte du projet plus sa description de tâche. Pas de mémoire partagée entre les exécutions.

La consommation de tokens augmente avec la taille de l'équipe. Chaque coéquipier porte sa propre fenêtre de contexte complète. Pour la recherche et la revue, le surcoût en vaut généralement la peine. Pour les tâches de routine, reste sur un agent seul.

Ce que ça change pour construire

La version actuelle a des aspérités. Le modèle, lui, tient la route : découper un travail complexe en morceaux indépendants, assigner des spécialistes, les laisser communiquer et s'auto-coordonner.

Ce qui me frappe, c'est à quel point les modes de défaillance sont familiers. Des specs floues mènent à du travail gaspillé, pareil qu'avec des humains. Trop de dépendances et personne n'avance. Des fichiers partagés créent des conflits. Les équipes qui fonctionnent le mieux sont celles avec une propriété claire, exactement comme dans toutes les équipes d'ingénierie que j'ai connues.

Tu construis des workflows d'agents ? Les équipes d'agents méritent le test. Commence petit, choisis les bons problèmes, n'attends pas de miracle. Les équipes qui fonctionnent le mieux sont celles où tu voudrais aussi plusieurs humains sur le sujet.