Claude Code subagents et Agent Teams : le guide pratique

Tu as vu passer les mots "subagents", "Agent Teams", "orchestration", et tu te demandes si tu loupes quelque chose. Court : pour la plupart de tes tâches, non. Mais sur les gros chantiers, oui, et ça vaut le coup de comprendre.

On démêle ça sans jargon.

Un subagent, c'est quoi au juste

Un subagent, c'est un assistant spécialisé avec son propre contexte, son propre prompt et ses propres permissions d'outils.

Quand l'agent principal tombe sur une sous-tâche bien délimitée, il la délègue à un subagent. Celui-ci bosse dans sa propre fenêtre de contexte, fait son travail, et renvoie juste le résultat. L'agent principal n'a pas son historique complet qui pollue son contexte, il reçoit la conclusion.

L'intérêt, c'est ça : garder le contexte de l'agent principal propre. Au lieu d'avoir un seul agent qui se noie dans 50 000 tokens de recherche de fichiers, tu as un subagent qui fait la recherche et remonte trois lignes utiles.

Tu déclares tes subagents dans le dossier .claude/agents/ de ton projet. Chacun a un nom, une description qui dit quand l'utiliser, et un prompt système.

---
name: test-writer
description: Utilise quand il faut écrire ou réparer des tests
---
Tu écris des tests. Tu vises la couverture des cas limites,
pas le happy path. Tu ne touches jamais au code de prod.

Agent Teams, le cran au-dessus

Agent Teams, c'est l'orchestrateur multi-agents intégré à Claude Code. Encore expérimental, désactivé par défaut, mais c'est une bonne porte d'entrée.

Le principe : un agent chef découpe une grosse tâche, délègue chaque morceau à un agent spécialiste (avec son propre modèle, ses prompts, ses outils), les spécialistes bossent en parallèle sur un système de fichiers partagé, et les résultats remontent vers le chef.

Si "déléguer à un spécialiste" te rappelle les subagents, c'est normal. Agent Teams, c'est cette idée poussée jusqu'à faire tourner plusieurs agents vraiment en parallèle, pas juste l'un après l'autre.

Au-delà de l'intégré, il existe des orchestrateurs tiers comme Multiclaude ou Gas Town. Ils sont opinionés, ce qui en fait justement de bons points de départ quand tu débutes : ils décident à ta place tant que tu n'as pas tes propres habitudes.

Quand tu en as besoin (et quand non)

Soyons clairs : l'orchestration multi-agents n'a aucun intérêt pour 95% des tâches assistées par agent. Pour la majorité de ton boulot quotidien, un seul agent est plus rapide et plus simple.

Aujourd'hui, le multi-agent reste une façon chère et expérimentale d'attaquer des gros projets.

Tu en as besoin quand :

• Le projet se découpe en morceaux vraiment indépendants qui touchent des fichiers différents.
• Une seule fenêtre de contexte ne suffit pas à tout tenir.
• Tu veux paralléliser un refactor large ou une migration sur tout le repo.

Tu n'en as pas besoin pour un bug fix, une feature ciblée, ou quoi que ce soit qui tient dans une seule tête.

Le piège, c'est de lancer une "team" de dix agents pour un truc qu'un agent ferait en cinq minutes. Tu paies en tokens et en complexité un parallélisme que la tâche ne justifie pas.

Le vrai problème : la visibilité

Voici ce dont personne ne parle assez. Dès que tu fais tourner plusieurs subagents ou une Agent Team, tu perds le fil.

Un chef délègue à cinq spécialistes. Lequel bosse ? Lequel a fini ? Lequel attend une décision ? Dans un terminal, tu vois un mur de texte qui défile, et tu ne sais pas qui fait quoi.

C'est là qu'un tableau de bord visuel change tout. AgentsRoom te montre chaque agent et chaque subagent comme une tuile distincte, avec son statut en clair. Tu vois la délégation se faire, tu vois qui attend ta réponse, tu vois qui a planté. Le mur de texte devient une carte lisible.

Sans cette vue, l'orchestration multi-agents reste une démo impressionnante mais ingérable au quotidien. Avec, ça devient un outil que tu utilises pour de vrai.

Par où commencer

Ne saute pas direct à une team de huit agents.

Commence par un ou deux subagents pour des tâches précises et répétitives : un qui écrit les tests, un qui fait la recherche dans le code. Tu vas vite sentir le gain sur le contexte de ton agent principal.

Quand cette mécanique est naturelle, active Agent Teams sur un chantier qui se découpe bien. Garde un œil sur qui fait quoi, valide les plans avant l'exécution, et arrête-toi dès que la review devient ton goulot.

Le multi-agent récompense ceux qui structurent avant de lancer. Pas ceux qui lancent le plus d'agents.