Contrôles des équipes d'agents

Problème : Tu as activé les équipes d'agents Claude Code et ta première équipe est en ligne. Mais le chef continue à faire le travail lui-même au lieu de déléguer. Les équipiers modifient les mêmes fichiers. Tu ne vois pas ce que chacun fait vraiment. Les contrôles pour résoudre chacun de ces problèmes existent. Ils ne sont juste pas évidents dès le départ.

Gain rapide : Appuie sur Shift+Tab juste après avoir démarré une équipe pour passer en mode délégué. Le chef arrête de toucher le code et se concentre sur la coordination.

Note : C'est un guide complémentaire à la vue d'ensemble des équipes d'agents. Commence par là si tu n'as pas encore configuré une équipe.

Modes d'affichage

Les équipes d'agents te donnent deux modes d'affichage qui changent la façon dont tu surveilles tes équipiers et interagis avec eux.

Mode in-process (par défaut)

Tous les équipiers s'exécutent dans ton terminal principal. Tu passes de l'un à l'autre avec des raccourcis clavier :

Ça fonctionne dans n'importe quel terminal. Pas de configuration supplémentaire, pas de dépendances. Tu regardes la sortie d'un équipier à la fois et tu passes de l'un à l'autre à la demande. Pour la plupart des workflows, le mode in-process te couvre.

Mode split pane

Chaque équipier obtient son propre volet de terminal. Tu vois la sortie de tout le monde côte à côte et tu cliques dans n'importe quel volet pour interagir directement. Utile quand tu veux regarder plusieurs équipiers travailler sur un problème difficile en même temps.

Le mode split pane a besoin de tmux ou iTerm2. Sur macOS, tmux -CC dans iTerm2 est le point d'entrée recommandé. Important : le mode split pane n'est PAS supporté dans le terminal intégré de VS Code, Windows Terminal, ou Ghostty. tmux a des problèmes de compatibilité connus sur certains systèmes d'exploitation et fonctionne mieux sur macOS.

Configure ton mode préféré dans settings.json :

Trois options :

• "auto" (par défaut) utilise les volets divisés quand tu es déjà dans tmux, sinon revient en mode in-process
• "tmux" active les volets divisés et détecte automatiquement si tu es dans tmux ou iTerm2
• "in-process" force tout dans ton terminal principal

Remplace sur une base par session avec le flag CLI.

Mode délégué

Sans mode délégué, le chef commence parfois à implémenter des tâches lui-même au lieu d'attendre les équipiers. C'est contre-productif. Tu lui as dit de coordonner. Il a attrapé une clé et s'est mis à construire.

Appuie sur Shift+Tab pour passer en mode délégué après avoir démarré une équipe. Ça restreint le chef aux seuls outils de coordination : créer des équipiers, envoyer des messages, les arrêter, et gérer les tâches. Le chef ne peut pas toucher le code directement. Il reste entièrement sur l'orchestration.

Utilise le mode délégué quand tu veux que le chef agisse comme chef de projet plutôt que comme contributeur individuel. C'est surtout important pour les grandes équipes, où le rôle du chef est entièrement la coordination. En pratique, activer le mode délégué pour les sessions de 4 équipiers ou plus réduit visiblement le gaspillage de contexte du chef et l'empêche de rivaliser avec ses propres équipiers pour le travail.

Si le chef fonce en avant pendant que les équipiers travaillent encore, tu peux lui dire directement : "Attends que tes équipiers aient terminé leurs tâches avant de continuer." Parfois une indication en langage naturel fait l'affaire. Mais pour un comportement cohérent sur toutes les sessions, le mode délégué applique la contrainte automatiquement.

Workflow d'approbation des plans

Pour les tâches complexes ou risquées, exige que les équipiers planifient avant d'implémenter quoi que ce soit. L'équipier travaille en mode plan en lecture seule jusqu'à ce que le chef examine et approuve l'approche.

Le workflow :

1. L'équipier reçoit la tâche et entre en mode lecture seule
2. L'équipier crée un plan et envoie une demande d'approbation au chef
3. Le chef examine le plan et l'approuve ou le rejette avec des commentaires
4. Si rejeté, l'équipier reste en mode plan, révise, et resoumet
5. Une fois approuvé, l'équipier quitte le mode plan et commence l'implémentation

Le chef prend les décisions d'approbation de façon autonome. Tu façonnes son jugement via le prompt initial. Dis-lui "approuve uniquement les plans qui incluent une couverture de tests" ou "rejette les plans qui modifient le schéma de base de données sans migration." Le chef applique ces règles comme filtre sur chaque plan reçu.

Le mode plan est particulièrement précieux quand les équipiers travaillent sur une infrastructure partagée, touchent des schémas de base de données, ou font des changements coûteux à défaire. Le coût de la planification est une fraction du coût d'annuler une mauvaise implémentation sur plusieurs fichiers. Pour un regard plus approfondi sur la façon dont l'approbation des plans s'intègre dans une phase de planification structurée, voir le workflow de bout en bout.

Hooks pour les portes qualité

Les équipes d'agents s'intègrent au système de hooks de Claude Code pour les vérifications qualité automatisées. Deux hooks sont construits spécifiquement pour les workflows d'équipe :

TeammateIdle : S'exécute quand un équipier est sur le point de devenir inactif. Sors avec le code 2 pour envoyer des commentaires et garder l'équipier au travail. Utilise ça pour assigner automatiquement des tâches de suivi ou rediriger un équipier qui a fini tôt. Si un équipier clôture sa tâche principale pendant que d'autres bossent encore, un hook TeammateIdle peut lui router des tâches de revue ou de nettoyage sans aucune étape manuelle.

TaskCompleted : S'exécute quand une tâche est sur le point d'être marquée comme complète. Sors avec le code 2 pour bloquer la complétion et envoyer des commentaires. Utilise ça pour appliquer des portes qualité : exige que les tests passent, que les vérifications lint réussissent, ou que des critères d'acceptation spécifiques soient remplis avant qu'une tâche puisse se fermer.

Ces hooks te permettent de construire des portes qualité structurées sans surveiller manuellement chaque équipier. Un hook TaskCompleted qui lance ta suite de tests signifie qu'aucune tâche ne se ferme avec des tests cassés, peu importe quel équipier a écrit le code. Pour un guide complet du système de hooks et de sa configuration, voir le guide des hooks.

Envoyer des messages directs aux équipiers

Chaque équipier est une session Claude Code complète et indépendante. Tu peux envoyer un message à n'importe quel équipier directement sans passer par le chef.

Mode in-process : Utilise Shift+Haut/Bas pour sélectionner un équipier, puis tape pour envoyer un message. Appuie sur Entrée pour voir la session complète d'un équipier et voir tout ce qu'il a fait. Appuie sur Échap pour interrompre son tour en cours s'il part dans la mauvaise direction.

Mode split-pane : Clique dans le volet d'un équipier pour interagir avec sa session directement. Chaque volet se comporte exactement comme une session Claude Code autonome.

C'est utile quand tu veux rediriger un équipier spécifique, donner un contexte supplémentaire que le chef n'a pas, ou poser une question de suivi ciblée. Parfois le chemin le plus rapide c'est de parler directement au travailleur au lieu de passer par un coordinateur.

Gestion des tâches

La liste de tâches partagée coordonne chaque morceau de travail dans l'équipe. Le chef crée les tâches et les équipiers les traitent. Les tâches ont trois états : en attente, en cours, et complète. Les tâches peuvent dépendre d'autres tâches. Une tâche en attente avec des dépendances non résolues ne peut pas être réclamée tant que ces dépendances ne sont pas complètes. Ça reflète les patterns de chaîne de dépendances de l'orchestration d'équipe.

Le chef peut assigner des tâches explicitement à des équipiers spécifiques, ou les équipiers peuvent s'approprier ce qui est disponible. Après avoir fini une tâche, un équipier prend la prochaine tâche non assignée et débloquée par lui-même. Ce comportement d'auto-appropriation garde l'équipe en mouvement sans intervention constante du chef.

La réclamation de tâches utilise le verrouillage de fichiers pour empêcher les conditions de course où deux équipiers s'emparent de la même tâche simultanément. Le système gère les dépendances automatiquement : quand un équipier termine une tâche dont d'autres dépendent, les tâches bloquées se débloquent sans action manuelle. Un équipier qui attend une dépendance commence à travailler dès que cette dépendance est résolue.

Pour plus de patterns de coordination de tâches, voir la distribution des tâches et les workflows todo.

Taille de l'équipe et sélection de modèle

Claude choisit le nombre d'équipiers en fonction de la complexité de ta tâche, ou tu peux spécifier exactement ce que tu veux.

Tu peux aussi mélanger les modèles dans une seule équipe. Fais tourner le chef sur Opus pour la coordination stratégique pendant que les équipiers tournent sur Sonnet pour l'implémentation ciblée. Ça équilibre coût et capacité. Le chef a besoin d'un raisonnement fort pour la décomposition des tâches et l'approbation des plans. Les équipiers qui font du travail d'implémentation borné arrivent souvent bien avec Sonnet à une fraction du coût.

Pour des réponses encore plus rapides du chef pendant les phases de coordination intensive, combine les équipes d'agents avec le mode rapide.

Gestion du coût en tokens

Les équipes d'agents brûlent beaucoup plus de tokens qu'une session unique. Chaque équipier fait tourner sa propre fenêtre de contexte, et l'utilisation des tokens augmente avec les équipiers actifs. Quand les équipiers tournent en mode plan avant l'implémentation, attends-toi à environ 7x les tokens d'une session standard pour cette phase.

Où vont les tokens :

• Chaque équipier charge le contexte du projet indépendamment (CLAUDE.md, skills, fichiers du projet)
• La communication ajoute du coût : chaque message entre agents consomme des tokens dans le contexte de l'émetteur et du récepteur
• La diffusion multiplie le coût par le nombre d'équipiers qui reçoivent le message
• Le chef consomme des tokens pour la coordination, la gestion des tâches et la synthèse des résultats

Quand le coût en vaut la peine :

• Tâches de recherche et de revue où plusieurs perspectives détectent des problèmes qu'un seul passage raterait
• Sessions de débogage où le test de plusieurs hypothèses en parallèle résout les problèmes plus vite que les suppositions séquentielles
• Grandes implémentations de fonctionnalités où les économies de temps justifient la dépense en tokens
• Décisions d'architecture où une évaluation approfondie évite des erreurs coûteuses plus tard

Comment garder les coûts bas :

• Utilise Sonnet pour les équipiers qui font du travail d'implémentation ciblé et réserve Opus pour le chef
• Préfère les messages directs aux diffusions quand c'est possible
• Limite la taille de l'équipe à ce que la tâche requiert réellement (3 équipiers vaut souvent mieux que 6)
• Utilise des sous-agents ou des sessions uniques pour les tâches routinières qui n'ont pas besoin de communication inter-agents
• Définis une portée claire pour chaque équipier pour éviter l'exploration inutile

Règle générale : Une équipe de 3 équipiers qui tourne 30 minutes brûle environ 3 à 4x les tokens d'une session unique faisant le même travail séquentiellement. L'échange c'est vitesse et couverture contre coût.

Optimisation de CLAUDE.md pour les équipes

Chaque équipier charge ton CLAUDE.md au démarrage avec une fenêtre de contexte fraîche. La discussion antérieure du chef ne suit pas, c'est pourquoi la qualité de CLAUDE.md compte tant pour les équipes. Si CLAUDE.md est vague, chaque équipier gaspille des tokens à réexplorer la base de code par lui-même. Trois équipiers chargeant le contexte simultanément signifie 3x le coût en tokens si ce contexte nécessite de l'exploration plutôt qu'une lecture rapide.

Trois règles rendent les équipes d'agents visiblement plus efficaces :

Règle 1 : Décris tes limites de modules

Plus tes limites de modules dans CLAUDE.md sont claires, plus Claude divise intelligemment le travail entre les équipiers. Utilise un tableau :

Quand tu dis à Claude de "créer une équipe et diviser par propriété de fichiers", il lit la structure et assigne des listes de fichiers explicites à chaque équipier. Zéro conflits.

Règle 2 : Garde le contexte projet court et opérationnel

Stack, point d'entrée, commande de test, base de données. Lectures courtes, pas d'explorations.

Aucun équipier ne devrait avoir besoin de demander au chef de quoi parle le projet ou où se trouvent les fichiers. Chaque round de "quel framework est-ce ?" brûle des tokens dans le contexte de l'équipier et celui du chef quand il répond.

Règle 3 : Définis ce que "vérifié" signifie

Quand CLAUDE.md liste comment vérifier que les choses fonctionnent, les équipiers utilisent ces signaux pour auto-vérifier leur propre travail avant de rendre compte.

Claude adapte la vérification par tâche. Pour une tâche de nettoyage, les équipiers pourraient utiliser grep pour vérifier les suppressions. Pour une fonctionnalité, ils lancent la suite de tests. Avoir des portes à l'échelle du projet donne au chef un vocabulaire pour "terminé" qu'il peut appliquer automatiquement.

Avec des règles claires dans CLAUDE.md, les équipiers rapportent exactement ce qu'ils ont fait sans intervention du chef. Des règles claires en entrée, des rapports clairs en sortie. Pour en savoir plus sur la structuration de tes fichiers projet, voir la maîtrise de CLAUDE.md.

Pour tout mettre ensemble

Tu as maintenant les contrôles pour gérer les équipes d'agents efficacement. Commence avec le mode délégué lors de ta prochaine session d'équipe et ressens la différence que ça fait dans le comportement du chef. Ajoute un hook TaskCompleted pour appliquer ta suite de tests. Écris les limites de modules dans ton CLAUDE.md et laisse Claude diviser le travail automatiquement.

Pour des prompts réels que tu peux copier et adapter, voir Cas d'utilisation et modèles de prompts des équipes d'agents. Pour le dépannage des problèmes courants et les limitations actuelles, voir les Meilleures pratiques des équipes d'agents. Pour le workflow complet de planification à production qui relie tous ces contrôles, voir le guide de workflow de bout en bout.