Deux choses portent le nom de « Claude Code en équipe ». Les confondre fait perdre du temps.
La première est une fonctionnalité. Une session pilote plusieurs sessions Claude Code qui travaillent en parallèle. La seconde est un chantier d’entreprise. Équiper cinq développeurs, poser des règles, décider qui relit quoi.
Voici les deux, avec ce que la documentation d’Anthropic en dit. Relevé le 29 septembre 2026.
Les équipes d’agents, en une minute
Une session prend le rôle de chef d’équipe. Elle répartit le travail, lance des coéquipiers et rassemble les résultats. Plus léger qu’un coéquipier, le sous-agent ne rend qu’un résumé.
Chaque coéquipier est une session Claude Code complète. Il a sa propre fenêtre de contexte. Il parle directement aux autres, sans passer par le chef.
Ils se partagent une liste de tâches. Un coéquipier qui finit prend la suivante tout seul. Un verrouillage de fichier empêche que deux la prennent en même temps.
Vous pouvez parler à n’importe lequel d’entre eux directement.
Deux avertissements de la documentation
C’est expérimental, et c’est désactivé par défaut. La documentation l’écrit en avertissement. Il faut poser la variable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS à 1 pour activer les équipes d’agents.
Sans elle, la fonctionnalité reste éteinte. C’est ce qu’écrit la documentation d’Anthropic au 29 septembre 2026.
Et ça consomme nettement plus de jetons qu’une session seule. Anthropic l’écrit aussi. C’est mécanique : chaque coéquipier est une instance séparée, avec sa propre fenêtre de contexte.
Une équipe qui teste ça un lundi après-midi sans le savoir découvre la facture le mardi.
Sous-agent ou coéquipier, la question qui se pose avant
La documentation conseille de vérifier d’abord si une option plus légère fait le travail. Le sous-agent en est une.
Un sous-agent travaille dans votre session et vous rend un résultat. Un coéquipier est autonome, discute avec les autres et coûte plus cher.
La documentation le pose ainsi. Le sous-agent quand il faut un exécutant rapide sur un point précis, qui rend son résultat. Le coéquipier quand les agents doivent se partager ce qu’ils trouvent, se contredire et se coordonner seuls.
La revue de code à plusieurs angles est le cas d’école. Un relecteur seul trouve un type de problème et s’y installe. Trois relecteurs, chacun avec sa consigne, couvrent la sécurité, la performance et les tests en même temps.
Ce qui casse, et ce n’est pas la technique
Les fichiers partagés. Deux coéquipiers qui éditent le même fichier produisent des écrasements. La documentation le dit franchement, et le remède est de découper le travail par fichiers, pas par tâches.
C’est une discipline d’équipe humaine appliquée à des agents. Qui possède quoi.
Les autorisations. Les coéquipiers démarrent avec le mode d’autorisation du chef. La documentation note une exception, le mode dontAsk, dont ils n’héritent pas. Si le chef tourne avec --dangerously-skip-permissions, tous les autres aussi.
Les demandes d’autorisation remontent à la session du chef. Quelqu’un doit être devant l’écran pour répondre.
Le mode plan est le cran d’avant. Claude lit, explore et propose, sans modifier votre source.
Le nombre. Anthropic recommande de commencer entre trois et cinq coéquipiers. Sa documentation prévient qu’à partir d’un certain nombre, la coordination augmente et les gains ne suivent plus.
L’autre sens : équiper une vraie équipe
C’est l’autre moitié de la question, et c’est celle qui décide du résultat en entreprise.
Cinq développeurs qui découvrent Claude Code chacun dans son coin trouvent cinq façons de faire. Aucune ne sort de leur poste.
Ce qui change l’échelle, ce sont les conventions écrites au même endroit. Un fichier CLAUDE.md dans le dépôt, que chaque session lit au démarrage. Vos règles de nommage, vos commandes de test, ce qu’on ne touche pas.
Un coéquipier charge le même contexte projet qu’une session ordinaire. Ce que vous écrivez une fois profite à tous les agents de l’équipe.
La règle de validation, le vrai sujet
La question n’est pas de savoir si l’agent code bien. Elle est de savoir qui relit, et à quoi on ne le laisse pas toucher.
Une équipe sans cette règle produit du code plus vite et le relit moins. C’est là que l’outil coûte plus qu’il ne rapporte.
Trois décisions vous reviennent. Ce qui part en production sans relecture humaine. Ce à quoi l’agent n’a pas accès, les secrets et les migrations de base de données en tête. Qui arbitre quand deux agents ne sont pas d’accord.
Écrivez-les avant de lancer la première équipe, pas après le premier incident.
Les hooks, pour que la règle tienne toute seule
Une règle écrite dans un fichier de consignes ne bloque rien. Un hook, si.
Un hook est un script que Claude Code lance à un moment précis. Pour les événements qui peuvent bloquer, un code de sortie 2 refuse l’action. Même un allow renvoyé en JSON par le hook ne passe pas devant.
Trois événements servent directement au travail en équipe, d’après la documentation. TeammateIdle se déclenche quand un coéquipier s’apprête à se mettre en attente. Un code 2 le renvoie au travail avec un retour. TaskCreated peut refuser la création d’une tâche. TaskCompleted peut refuser qu’une tâche soit marquée terminée. Le mécanisme complet est dans les hooks de Claude Code.
C’est la différence entre une consigne et une barrière. La consigne se contourne un vendredi soir.
Un avertissement de la documentation mérite d’être repris tel quel. Pour une autorisation dure, elle renvoie au système de permissions. Le hook valide. Le contrôle d’accès reste ailleurs.
Par où commencer avec une équipe de cinq
Commencez par une tâche sans écriture. Une relecture de pull request, un tour dans la doc d’une bibliothèque, une piste de bug. La documentation le conseille et c’est le bon ordre.
Vous verrez la valeur du travail en parallèle sans payer le prix des conflits d’écriture.
Ensuite seulement, passez à l’implémentation, avec un découpage par fichiers et la règle de validation écrite.
C’est ce que je monte pendant la formation Claude Code, sur vos dépôts et vos conventions. Les trois décisions ci-dessus sont la première demi-journée, avant la moindre ligne de code.
Ce qui n’est pas encore là
Au 29 septembre 2026, Anthropic liste ses propres limites. C’est une bonne raison d’attendre avant d’y poser un processus critique.
Les commandes /resume et /rewind ne restaurent pas les coéquipiers en process. Le statut des tâches peut retarder, ce qui bloque les tâches dépendantes. L’arrêt peut être lent. Une session a une seule équipe. Un coéquipier ne peut pas en lancer une. Le chef reste le chef.
La première fois, ça coince. On dit trois fois que c’est bizarre, puis ça tourne. C’est normal, et c’est pour ça qu’on commence par une revue et pas par une migration.
Source relevée le 29 septembre 2026, la documentation des équipes d’agents et celle des hooks d’Anthropic.