Équipes d'agents Claude Opus 4.6 : construire des workflows multi-agents

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

J'utilise les équipes d'agents 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, on interagit avec un seul agent. Il lit des fichiers, écrit du code, lance des tests. Pour paralléliser, on peut créer des sous-agents mais ce sont des exécutants ponctuels : ils font une tâche et renvoient le résultat. Impossible pour eux de communiquer entre eux.

Les équipes d'agents fonctionnent différemment. Un agent lead (votre 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 peuvent s'envoyer des messages directement, prendre des tâches dans la liste partagée et travailler sur des fichiers séparés en parallèle.

C'est comme une petite équipe de dev. Le lead fait office de tech lead qui découpe le travail. Les coéquipiers sont des développeurs qui prennent chacun leur morceau, communiquent quand c'est nécessaire et rendent compte quand ils ont fini.

Les outils de coordination

La coordination repose sur un ensemble d'outils accessibles au lead comme aux coéquipiers.

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. Les tâches passent par trois états : en attente, en cours, terminée. Elles peuvent avoir des dépendances : la tâche B ne se débloque qu'une fois la tâche A terminée.

SendMessage gère la communication. Les coéquipiers peuvent envoyer des messages directs à un agent précis ou diffuser à tout le monde. Le lead est notifié automatiquement quand un coéquipier termine ou passe en veille.

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

Tout vit sur le disque sous forme de fichiers JSON dans ~/.claude/teams/ et ~/.claude/tasks/. La prise de tâches utilise un verrouillage de fichier pour éviter que deux coéquipiers ne saisissent le même travail.

Une session type

Voici un workflow réaliste. Imaginons que je construise une fonctionnalité qui nécessite 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 et 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 spécifique. Par contre, il n'hérite pas de l'historique de conversation du lead : la description de la tâche est donc essentielle.

Dans mon terminal, je peux naviguer entre les coéquipiers avec Shift+Bas pour voir où ils en sont ou donner des instructions supplémentaires. Avec tmux, chaque coéquipier a son propre panneau et je vois tout le travail en cours simultanément.

Les coéquipiers travaillent de façon indépendante. Quand celui qui gère la migration finit le schéma, il marque sa tâche comme terminée. Si le coéquipier API était bloqué sur le schéma, sa tâche se débloque automatiquement. Le coéquipier frontend travaille sur les composants depuis le début puisqu'il n'avait aucune dépendance.

Quand les équipes d'agents apportent vraiment quelque chose

Après plusieurs semaines d'utilisation, le schéma est clair.

L'usage que je fais le plus souvent, c'est la recherche en parallèle. Trois coéquipiers qui 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'on trouve une réponse plausible, on s'arrête. 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, backend, tests : chaque coéquipier est propriétaire de sa partie sans risque de conflit.

La revue de code bénéficie de la même logique. Un coéquipier sur la sécurité, un sur la performance, un sur la couverture de tests. Un relecteur seul tend à se focaliser sur une catégorie de problèmes. Trois spécialistes en parallèle en attrapent davantage.

Mon pattern préféré reste le débogage par hypothèses concurrentes. Cinq coéquipiers qui 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 à ce processus 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 est plus rapide. Le coût de coordination n'en vaut pas la peine quand la plupart des coéquipiers attendent.

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

Et ne créez pas une équipe pour renommer une variable. Si un agent seul met cinq minutes, le surcoût de coordination n'a aucun sens. Pareil quand chaque tâche dépend de toutes les autres : le parallélisme s'effondre et on paie plusieurs fenêtres de contexte pour des agents en attente.

L'expérience du compilateur C

Anthropic a mené le test le plus ambitieux à ce jour : ils ont confié à 16 agents parallèles la construction d'un compilateur C en Rust en partant de zéro. Sur près de 2 000 sessions et 2 milliards de tokens en entrée pour un coût d'environ 20 000 $, l'équipe a produit 100 000 lignes de code.

Le compilateur peut construire 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 était simple : les agents verrouillaient les tâches via des fichiers texte, tiraient les changements, fusionnaient et poussaient. La découverte clé portait sur la qualité des tâches. Quand les agents ont attaqué le 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é mutuellement leurs modifications. Le parallélisme ne fonctionne que quand 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 est le prompt. Si on reste vague ("gère le truc base de données"), le coéquipier va faire des hypothèses non souhaitées. Il faut être précis sur les fichiers, le comportement attendu et les contraintes. J'ai constaté que cinq minutes de rédaction soignée économisent une heure de travail gaspillé par l'agent.

Pour découvrir les équipes d'agents, mieux vaut éviter de sauter directement dans l'implémentation parallèle. Lancez une revue de code en parallèle ou faites rechercher différentes bibliothèques par vos coéquipiers. Les contours sont nets et le risque faible. On prend le rythme sans miser une feature dessus.

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

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

Limites actuelles

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

Impossible de reprendre des coéquipiers après un redémarrage de session. Si vous faites /resume, 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. Quand quelque chose semble coincé, vérifiez si le travail est réellement fait et mettez le statut à jour manuellement.

Seul le lead gère l'équipe. Les coéquipiers ne peuvent pas créer leurs propres équipes ni se promouvoir. 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 a 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, restez sur un agent seul.

Ce que ça annonce

La version actuelle a encore des aspérités mais le modèle est solide. 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, ce qui est aussi vrai de toutes les équipes d'ingénierie que j'ai connues.

Si vous construisez des workflows d'agents, les équipes d'agents méritent d'être testées. Commencez petit, choisissez les bons problèmes et n'attendez pas de miracle. Les équipes qui fonctionnent le mieux sont celles où vous voudriez aussi plusieurs humains sur le sujet.