Faire travailler plusieurs sessions à la fois — et pourquoi je ne le fais pas

Quelqu’un te l’a dit, et depuis l’idée s’installe toute seule : on peut lancer plusieurs agents à la fois. Tu as quatre choses à faire ce soir — un bug à corriger, une pull request à relire, un test capricieux à comprendre, une recherche à mener. Elles n’ont presque rien à voir entre elles, et tu les regardes se faire l’une après l’autre.

Si une session fait une chose, quatre sessions devraient en faire quatre. La phrase est exacte. Ce qu’elle ne dit pas, c’est laquelle des quatre façons de lancer répond à ta situation, ce que tu paies pour ça, et ce qui se perd entre les quatre.

Ce qui se passe vraiment

Tu parallélises déjà — ce que je ne monte pas, c’est la coordination

Tu parallélises depuis la leçon 12. /simplify lance quatre agents en parallèle. Un subagent est l’ouvrier isolé qui travaille à part et ne rend qu’un résumé. Il se lance à plusieurs dans un seul message, et c’est ce que fait la chaîne qui produit ces leçons : deux relecteurs, en parallèle, dans une même session. Le geste tient en une phrase, et la documentation en donne la forme :

Étudie les modules d'authentification, de base de données et d'API en parallèle,
avec un subagent séparé pour chacun.

Tu vois qu’ils sont partis à ceci : une ligne par agent apparaît dans le panneau d’agents, sous ta zone de saisie, avec son état. C’est le même panneau tout au long de cette leçon.

Une session tolère vingt subagents à la fois par défaut ; au-delà, l’outil qui les lance échoue avec Concurrent subagent limit reached, et il est dit à Claude de ne pas réessayer. Le plafond se règle par la variable CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, posée dans l’environnement de la session ou dans le bloc env de ton ~/.claude/settings.json. C’est la seule limite dure des subagents, et elle a trois trous : ultracode n’y est pas soumis, un embranchement lancé par /subtask prend une place sans jamais être bloqué, et la reprise d’un subagent terminé en prend une sans vérifier la limite. Donc la question n’est pas « est-ce que je peux en lancer plusieurs ». Tu peux. La question est de savoir qui coordonne, et s’ils doivent se parler — c’est cette partie-là que je ne monte pas.

Quatre façons de lancer plusieurs agents, qui ne se remplacent pas

La documentation les range elle-même en quatre, et le tableau vaut d’être connu avant d’en choisir une :

Ce que tu lances	Ce que c’est	Ce qui revient chez toi
Subagents	des ouvriers délégués à l’intérieur de ta session	un résumé, à l’appelant, et à lui seul
Agent view	un écran pour lancer et surveiller des sessions d’arrière-plan, ouvert par claude agents — en research preview, livré pour essai et susceptible de changer (leçon 10)	chaque tâche reste une conversation entière : tu ouvres la ligne, tu réponds, tu ressors
Équipes de sessions	des sessions coordonnées, avec liste de tâches partagée et messagerie — expérimental, désactivé par défaut	ce que chaque agent te dit, et ce qu’ils se disent entre eux
Workflows	un script qui lance beaucoup de subagents et recoupe leurs résultats	la réponse finale, seule

Trois outils les accompagnent sans être des façons de lancer des agents : les worktrees (le terme est passé en leçon 6, le sujet entier est la leçon 14), la messagerie entre sessions, et /batch, un skill (une fiche réutilisable : du savoir ou une procédure) qui découpe un gros changement en 5 à 30 subagents isolés chacun dans son worktree. Et la documentation nomme elle-même le moment où l’on passe du subagent à l’équipe : quand tu lances déjà des subagents en parallèle et que tu butes sur les limites de contexte, ou quand tes subagents ont besoin de se parler.

Ce qu’une équipe ajoute au subagent, et ce qu’elle facture

La différence tient en une phrase. Un subagent a sa propre fenêtre, mais ses résultats reviennent à l’appelant et il ne parle qu’à son parent. Dans une équipe, chaque agent est une session Claude Code complète et indépendante : tu peux parler directement à n’importe lequel sans passer par le lead, la session principale, celle où tu tapes. Et eux peuvent se parler entre eux. Ces sessions-là s’appellent des coéquipiers — sur ton écran et dans les réglages, tu verras le mot anglais, teammate.

Cette indépendance est exactement ce qui coûte. Chaque coéquipier consomme comme une session. Deux chiffres, avec leurs conditions, parce que sans elles ils ne veulent rien dire : environ sept fois plus de tokens qu’une session ordinaire (le token est l’unité dans laquelle se compte la place occupée, un morceau de mot, pas un mot) quand les coéquipiers tournent en mode plan ; et côté sessions d’arrière-plan, dix agents en parallèle brûlent le quota à peu près dix fois plus vite qu’un seul. Une seule salve lourde peut épuiser ton allocation hebdomadaire, et changer de modèle ne rend pas l’accès. Aucune limite dure à la taille d’une équipe : la recommandation officielle est de démarrer à trois à cinq, parce que trois coéquipiers concentrés font souvent mieux que cinq dispersés.

Et un coéquipier ne reçoit pas ta conversation. Il charge le même contexte projet qu’une session ordinaire : CLAUDE.md, serveurs MCP (le MCP étant le branchement vers un service extérieur, leçon 4), skills. S’y ajoute le prompt de lancement que le lead lui écrit. D’où deux conséquences vérifiables chez toi : ton fichier de règles est chargé autant de fois qu’il y a d’agents, et le prompt de lancement est dans le contexte de chacun d’eux dès la première seconde. Dernier point, et il va dans l’autre sens : sur les deux réglages qui décident de la dépense, le coéquipier te suit. Quand ta demande de lancement ne nomme pas de modèle pour lui, il tourne sur le modèle courant du lead, le tien, et il hérite de son niveau d’effort, combien Claude réfléchit avant d’agir (leçon 12). Les deux ne se rattrapent pas pareil : le modèle est figé au démarrage du coéquipier, tandis que l’effort continue de suivre le tien aux tours suivants. /model tapé pendant que tu le regardes ne change que le lead. Le modèle d’un coéquipier se décide donc dans la demande qui le lance, ou par CLAUDE_CODE_SUBAGENT_MODEL posée dans l’environnement ; ne cherche pas de ligne de menu, la version 2.1.234 a retiré celle qui existait, et une valeur restée dans tes fichiers de réglages est ignorée.

La pièce qu’on te vend et qui n’est plus livrée

Piège — la liste de tâches partagée est présentée partout comme le mécanisme de coordination d’une équipe. Depuis la version 2.1.233, les outils de tâches ne sont pas fournis par défaut sur Opus 4.8, Sonnet 5, Fable 5, Mythos 5 et les versions ultérieures de ces familles. Sans eux, ton équipe se coordonne uniquement par messages, pas par la liste. Et le hook TaskCreated, ce déclenchement automatique attaché à un événement dont on te vend qu’il posera ta barrière de qualité, ne se déclenche pas du tout. Tu n’obtiens pas une barrière qui laisse passer : tu obtiens l’absence de barrière, et rien ne te le dit.

Comment on les rallume : lancer avec CLAUDE_CODE_ENABLE_TODO_TOOLS=1 claude, ou nommer l’un des outils dans --allowedTools. La page des outils donne les quatre voies exactes.

Une nuance décide de ton cas, et elle dépend d’un réglage vu plus bas : un coéquipier in-process, dans ton terminal, suit ta session, donc il n’a pas les outils si tu ne les as pas ; un coéquipier dans son propre panneau séparé est un processus distinct, et c’est son modèle à lui (le tien, ou celui que tu lui as nommé) qui décide.

Trois hooks servent aux équipes : TeammateIdle, TaskCreated et TaskCompleted. Pour ces trois-là, une sortie en code 2 bloque — et la leçon 13 t’a dit pourquoi il faut le vérifier événement par événement plutôt que le supposer. Un hook garantit son déclenchement, pas son résultat ; ici, c’est la version installée qui décide s’il se déclenche.

Un workflow, c’est ton plan déplacé dans du code

Un workflow est un script JavaScript que Claude écrit et qu’un moteur exécute en arrière-plan pendant que ta session reste disponible. C’est le déplacement qui compte : la boucle, les branchements et les résultats intermédiaires vivent dans des variables du script, et seule la réponse finale arrive dans le contexte de Claude. Là où une équipe multiplie les fenêtres, un workflow en épargne une. Il demande la version 2.1.154 ou plus, et si tu es sur un plan payant, tu es concerné : ils sont disponibles sur tous les plans payants, et aussi avec un accès API Anthropic, sur Bedrock, Google Cloud Agent Platform et Microsoft Foundry. Sur Pro, il faut les activer depuis la ligne Dynamic workflows de /config.

Un seul workflow est livré d’origine, et c’est le plus intéressant du lot pour ce parcours. /deep-research éclate une question en plusieurs angles de recherche web, recoupe les sources, vote sur chaque affirmation, et rend un rapport sourcé dont les affirmations qui n’ont pas survécu sont retirées. Surtout, il fait la distinction que la leçon 13 passe son temps à réclamer : quand les agents vérificateurs ne peuvent pas contrôler une affirmation (limite d’usage atteinte, erreur d’API), le rapport la liste comme non vérifiée plutôt que réfutée. « Personne n’a regardé » et « c’est faux » ne sont pas la même nouvelle, et un dispositif qui les confond ment dans les deux sens. Le mécanisme intéressant d’un workflow n’est donc pas le nombre d’agents, c’est ce motif de qualité répétable.

Ce qui le déclenche, et ce qui ne le déclenche pas :

• le mot-clé ultracode dans un prompt, ou la demande en langage naturel « utilise un workflow » — mais seulement dans un prompt qu’un humain a tapé dans une session interactive ;
• rien de ce qui alimente le prompt depuis ailleurs : -p, le drapeau qui fait tourner Claude Code sans session interactive pour un script, une tâche planifiée, un webhook, un commentaire relayé. Avant la version 2.1.210, il partait aussi de ces routes-là ;
• à ne pas confondre avec /effort ultracode, qui combine l’effort xhigh et l’orchestration automatique : Claude planifie alors un workflow pour chaque tâche substantielle, et chaque demande coûte plus et prend plus de temps.

Se parler aide, sauf quand c’est précisément le contraire

La leçon 12 a posé une règle qui semble contredire tout ce qui précède : nos deux relecteurs ne communiquent pas, et c’est le cœur du dispositif — deux relecteurs qui se sont concertés convergent, et deux relecteurs qui convergent ne trouvent qu’une fois ce qu’ils auraient trouvé deux fois. La documentation des équipes, elle, vend la conversation entre coéquipiers comme le mécanisme clé, pour faire débattre des hypothèses concurrentes : plusieurs causes possibles d’un même bug. Les deux tiennent, pour des travaux différents :

Le critère — quand le travail est un débat, se parler fait converger vers la meilleure hypothèse. Quand le travail est une mesure indépendante, se parler détruit ce qu’on était venu chercher.

Et la clause qui évite le contresens : l’indépendance porte sur la production des constats, pas sur ce qu’on en fait ensuite. Une fois les listes rendues, les faire attaquer l’une par l’autre est le geste 5 de la leçon 12. Ce n’est pas la même phase.

Une relecture est une mesure : sa valeur vient du non-recoupement. Une enquête sur une cause est un débat : sa valeur vient de la confrontation.

Ce que je fais, et ce que je n’ai pas monté

Il faut l’écrire tel quel : je n’ai jamais monté d’équipe de sessions ni de workflow sauvegardé. Et cette absence est vérifiable, contrairement à ce que je croyais : le dossier de configuration d’une équipe disparaît à la fin de la session, mais sa liste de tâches reste, en local, sous ~/.claude/tasks/, sous un nom dérivé de l’identifiant de session. Une équipe qui a tourné laisse une trace ; il n’y en a pas. Ce qui est vérifiable, en revanche, tient en trois faits.

• La chaîne qui produit ces leçons parallélise, et s’arrête juste avant. Deux relecteurs en parallèle, dans un seul message, dans une seule session : du parallélisme de subagents, pas une équipe. Et ce qui fait l’argument de vente des équipes, les faire communiquer, est écarté noir sur blanc par la consigne qui les lance, pour la raison donnée en leçon 12.
• J’ai fait tourner de l’orchestration massive, ailleurs, et j’ai gardé le compte. Une expérimentation clonée et lancée sur mes propres sujets (ni une équipe, ni un workflow : un montage extérieur qui relance des agents par vagues) a produit quinze pages en trois vagues parallèles sur une campagne, douze et vingt-sept sur deux autres. Cinquante-quatre fichiers. Vérification faite avant d’écrire cette phrase : aucun ne se trouve dans le projet client correspondant. Ce que ça établit, et rien de plus : un dispositif qui produit vite produit surtout beaucoup. Je n’ai pas de version séquentielle des mêmes campagnes à comparer, donc ce chiffre ne dit rien de la coordination.
• Les tâches vraiment indépendantes sont plus rares qu’on croit. Sur ce projet-ci, la relecture croisée dont la leçon 12 tire ses chiffres n’a pas pu tourner en parallèle : le second relecteur travaille à partir d’un dépôt versionné (il lit ce qui a changé), et le projet ne l’était pas encore. Il a fallu créer le dépôt, puis le lancer. C’est une dépendance que personne n’avait vue en écrivant le plan. Une liste de quatre tâches « qui n’ont rien à voir entre elles » en contient presque toujours une qui attend une autre.

Ce qu’on fait

1. Décider avant de lancer — quatre questions, dans cet ordre

D’où vient ce critère, pour qu’on ne me prête pas plus que je n’apporte. Les trois derniers points sont, en substance, la section « Choose an approach » de la page officielle sur le parallélisme. Ce que j’y ajoute : l’ordre, la branche « je ne sais pas », et le fait qu’appliqué honnêtement il sort rarement sur une équipe. Rien dans la documentation ne dit à partir de quel moment le coût dépasse le gain — ça, c’est un avis, et je le pose comme tel.

1. Veux-tu pouvoir entrer dans chaque tâche et reprendre la main ? Si oui, ce ne sont ni des subagents ni une équipe : c’est agent view, qui te rend chaque tâche comme une conversation entière. Le geste est claude agents ; tu tapes une consigne, Entrée, une ligne apparaît, et chaque consigne suivante démarre une session de plus. C’est la réponse à la scène d’ouverture.
2. Ces tâches s’écrivent-elles dans les mêmes fichiers ? Si oui (ou si, comme souvent sur un projet qui a dépassé ta tête, tu n’en sais rien), ne renonce pas : isole. Un worktree par tâche (leçon 14), ou agent view, qui déplace tout seul chaque session dépêchée dans le sien avant qu’elle n’écrive. Trois cas font sauter ce déplacement tout seuls : la session est déjà dans un worktree lié ; son répertoire de travail n’est pas un dépôt git et aucun hook WorktreeCreate n’est configuré ; l’écriture vise un chemin hors du répertoire de travail. Et un quatrième n’est pas un cas, c’est une décision : le réglage worktree.bgIsolation posé à "none" supprime le déplacement pour tout un dépôt, et les sessions d’arrière-plan écrivent alors directement dans ta copie de travail. Dans ces quatre situations, la session écrit là où elle est ; partout ailleurs, tu découvres le conflit au rapatriement au lieu de le deviner. Sur un dépôt que tu n’as pas réglé seul, les trois cas ne suffisent donc pas à conclure que tu es isolé : c’est le « une liste n’est pas un inventaire » de la leçon 14. Ce qui n’isole pas, c’est l’équipe.
3. L’une attend-elle le résultat d’une autre ? Si oui, tu n’as pas quatre tâches, tu en as deux et une file d’attente.
4. Ont-ils besoin de se parler ? Si non, des subagents en parallèle font le travail, coûtent moins cher, et te rendent un résumé au lieu d’une conversation à quatre — le geste est celui du début de leçon, une phrase, un message. Si oui, et seulement là, c’est une équipe.

C’est en répondant à ces quatre questions sur mes propres semaines que je ne monte pas d’équipe. Ce n’est pas un jugement sur l’outil.

2. Commencer par ce qui n’écrit pas de code

Le conseil officiel pour débuter est le même que le mien : commencer par des tâches à frontières claires qui n’écrivent pas de code. C’est ce qui montre la valeur de l’exploration parallèle sans les problèmes de coordination de l’écriture parallèle. Chaque exemple avec son point d’entrée :

• relire une pull request → une ligne dans claude agents, parce que tu voudras entrer dans la conversation pour discuter une trouvaille ;
• enquêter sur un bug dont tu as trois causes possibles → des subagents en parallèle dans un seul message, un par hypothèse ;
• une question de fond → /deep-research, avec la réserve du geste suivant.

3. Jauger le coût avant de le dépenser

La méthode recommandée pour jauger le coût d’un workflow est de le lancer d’abord sur une tranche étroite : un dossier au lieu du dépôt entier, une question serrée au lieu d’une large. Une seule exécution peut consommer nettement plus de tokens que la même tâche en conversation, et les exécutions comptent dans les limites d’usage de ton plan comme n’importe quelle session.

Et pour savoir où tu en es avant de lancer, il y a un cadran. /usage affiche les limites de ton offre et où tu en es dedans ; sur une offre Pro, Max, Team ou Enterprise, il ventile en plus la dépense par skill, subagent, plugin et serveur MCP — donc il répond aussi à « qu’est-ce qui m’a coûté ça » après coup. /cost et /stats sont les mêmes. C’est le seul instrument du parcours qui regarde ton allocation plutôt que ta session : à lancer avant une salve lourde, pas après.

Les autres cadrans regardent ce qui tourne, et la documentation en donne un par façon de lancer — se tromper de cadran, c’est voir une liste vide et en conclure que rien ne tourne :

• claude agents ouvre agent view : chaque session d’arrière-plan, son état, et celles qui attendent quelque chose de toi ;
• /tasks liste ce qui tourne en fond dans la session courante, les subagents déjà terminés compris, et te laisse en regarder un, t’y attacher ou l’arrêter ;
• /workflows liste les exécutions de workflow en cours et terminées, la phase où chacune en est et combien d’agents ont fini.

La tranche étroite vaut aussi pour /deep-research, et c’est pour ça que ce geste vient après celui-ci : une question n’a pas de sous-dossier, donc la tranche étroite, c’est la question elle-même. Pose-la serrée, regarde /workflows pendant que ça tourne : c’est là que tu vois ce que ça consomme, phase par phase, et que x arrête l’agent sélectionné ou le run entier. Et fais-le une fois, pas en boucle. Une touche vaut d’être retenue : s sauve le script comme commande. C’est la suite naturelle du geste de la leçon 9 — un workflow qui a fait ce que tu voulais devient une commande.

4. Si tu montes une équipe quand même

La fonction est expérimentale et désactivée par défaut : sans la variable, aucune équipe n’est montée et Claude ne propose ni ne lance de coéquipier. Elle s’active à 1, dans l’environnement de la session ou dans le bloc env de ton ~/.claude/settings.json :

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude

Ce que tu viens d’acheter n’est pas seulement la possibilité de monter une équipe. Une fois la variable active, un subagent que Claude nomme de lui-même part comme coéquipier : les équipes peuvent se former sans que tu en aies demandé une. Et un enchaînement qui attendait le résultat d’un subagent peut se bloquer, parce qu’un coéquipier notifie seulement qu’il s’est arrêté, sans son résultat. La variable à 0 rend aux subagents nommés leur statut de subagent.

Cinq gestes, dont quatre tiennent le coût :

• nommer un modèle moins cher dans la demande qui les lance — « lance quatre coéquipiers, chacun sur Sonnet ». Sans ça, chacun démarre sur le tien, et ça ne se rattrape plus après ;
• garder l’équipe petite, l’usage étant à peu près proportionnel à sa taille ;
• garder le prompt de lancement serré, puisqu’il est dans le contexte de chacun d’eux ;
• arrêter les coéquipiers dont le travail est fini, chacun consommant jusqu’à sa sortie même quand tu ne le regardes pas. Deux façons : sélectionner sa ligne dans le panneau d’agents et appuyer sur x, ou demander au lead — « demande au coéquipier researcher de s’arrêter », une extinction négociée que le coéquipier peut refuser en expliquant pourquoi ;
• et le cinquième, qui tient le résultat : partitionner le travail à la main, pour que chacun possède ses fichiers. Ce n’est pas une optimisation, c’est la seule protection qui existe.

Un dernier réglage avant de chercher où sont passés tes agents : le mode d’affichage par défaut est in-process, tout dans un seul terminal. Il se change avec teammateMode dans ~/.claude/settings.json — "tmux" pour un panneau par coéquipier, ce qui exige tmux ou iTerm2. Avant la version 2.1.179 le défaut était "auto" : une mise à jour n’ouvre plus de panneaux séparés sans réglage explicite. Ce réglage décide aussi de l’affaire des outils de tâches.

5. Le geste le moins cher : deux sessions qui se parlent

Si ton besoin réel est « que cette session sache ce que l’autre a trouvé », il existe plus léger qu’une équipe. La messagerie entre sessions demande la version 2.1.224 ou plus et tourne sur macOS et Linux, WSL 2 compris. Pas sur Windows natif, pas sur les plateformes cloud. Quand elle est disponible, elle est active sans rien à activer. Une troisième condition, rarement citée et qui vise exactement le lecteur méfiant : si tu as posé DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ou DISABLE_GROWTHBOOK pour couper les remontées, elle reste éteinte — elle dépend de l’évaluation de drapeaux que ces variables coupent. Pour voir ce que ta session peut joindre : /list-agents (alias /peers).

Un message est un texte qu’un Claude écrit à un autre. Jamais l’historique, jamais des fichiers — pour déplacer une conversation entière, on reprend la session (leçon 7). Le Claude qui reçoit le lit entre deux appels d’outils, sans jamais interrompre l’outil en cours ; si la session est au repos, Claude Code démarre un nouveau tour avec le message, et une fois livré, ce message compte dans ton usage comme un prompt que tu aurais tapé.

Ce que ça ne fait pas

Une équipe n’isole rien — agent view, si

Les équipes n’isolent pas les coéquipiers dans des worktrees. Deux coéquipiers qui éditent le même fichier s’écrasent. La parade documentée n’est pas un mécanisme, c’est une discipline : partitionner le travail pour que chacun possède ses fichiers. Un lecteur qui vient de lire la leçon 14 supposera l’inverse, et il a raison partout ailleurs : agent view déplace chaque session dépêchée dans son propre worktree avant qu’elle n’écrive, sauf dans les trois cas listés plus haut (worktree déjà lié, hors dépôt git sans hook WorktreeCreate, écriture hors du répertoire de travail) et sauf si l’isolation a été coupée pour le dépôt par le réglage vu plus haut ; et /batch isole chaque subagent dans le sien. C’est l’équipe qui fait exception, et c’est elle qui donne la mauvaise réponse à la question de la leçon 14.

Ça ne se reprend pas

C’est la limite frontale de ce que la leçon 7 t’a promis, et elle vaut des deux côtés :

• /resume et /rewind ne restaurent pas les coéquipiers en processus. Pire : le lead peut ensuite essayer d’écrire à des coéquipiers qui n’existent plus ;
• un workflow ne se reprend que dans la même session Claude Code. Si tu quittes pendant qu’il tourne, la session suivante repart de zéro ;
• et un workflow interrompu pendant que plusieurs agents tournaient coûte à la reprise. Les agents terminés sont réutilisés, mais seulement jusqu’au premier qui n’avait pas fini : tous ceux partis après celui-là repartent, même s’ils avaient terminé.

Ajoute que l’arrêt lui-même peut être lent, qu’une session n’a qu’une seule équipe, et que le lead est fixe pour la vie de la session.

Ton mode de permission ne commande que le lancement

La leçon 8 a installé les modes ; voici les deux exceptions qu’il faut y ajouter.

• Côté équipes : les coéquipiers démarrent avec les réglages d’autorisation du lead. Si le lead tourne avec --dangerously-skip-permissions, tous aussi. En contrepartie, leurs demandes d’autorisation remontent dans ta session et c’est toi qui les approuves ; la seule exception voulue est l’approbation de plan, que le lead accorde seul.
• Côté workflows, la page officielle se contredit, et il faut le savoir avant de s’y fier. Elle écrit à un endroit qu’un workflow lancé par le mot-clé tourne dans le mode de permission de la session et que ses agents subissent les mêmes contrôles que n’importe quel appel d’outil ; elle écrit à un autre que les subagents d’un workflow tournent toujours en acceptEdits et héritent de ta liste d’autorisations quel que soit ton mode, les éditions de fichiers étant approuvées automatiquement. Les deux phrases sont sur la même page. La lecture prudente est la seconde : ne compte pas sur ton mode pour voir passer chaque écriture. Les commandes shell, les récupérations web et les outils MCP absents de ta liste peuvent, eux, t’interrompre en pleine exécution — et en -p comme dans le SDK, il n’y a personne à qui demander.

Une garantie tient dans tout ça, et elle est écrite : un message entre agents n’est jamais un accord de ta part. Un coéquipier ne peut ni répondre à une demande d’autorisation à ta place, ni relayer une action qui lui a été refusée ; et un message entrant ne peut pas faire changer les réglages d’autorisation, le CLAUDE.md ou la configuration, une commande écrite dedans arrivant en texte brut sans jamais être exécutée.

Les garde-fous de coût n’en sont pas

C’est le cas d’école de la leçon 13 : Claude Code affiche un avertissement « Large workflow » au-delà de 25 agents programmés ou d’un total de tokens projeté dépassant 1,5 million. Cet avertissement est consultatif. Il ne met pas en pause, il ne limite rien. Les sessions en ultracode ne le voient pas du tout — l’activer, c’est déjà avoir accepté les grosses exécutions.

Et les deux réglages ne sont pas indépendants : si tu choisis toi-même un guide de taille (workflowSizeGuideline, medium par défaut depuis la version 2.1.219), son nombre d’agents remplace le seuil de 25. Seul le guide par défaut laisse le seuil à 25. Et ce guide est envoyé à Claude comme un conseil, pas comme un plafond. Les seuls vrais plafonds sont ceux du moteur : 16 agents simultanés au plus (moins si Claude Code dispose de moins de CPU) et 1 000 agents par exécution, pour empêcher les boucles folles. Le reste est de l’affichage.

Les pannes qui ressemblent toutes à « c’est fini »

Le mode d’échec commun est celui de la leçon 13 : un dispositif qui a fini et un dispositif qui s’est arrêté produisent la même chose à l’écran, c’est-à-dire rien. Ceux qui sont documentés comme tels : le statut d’une tâche traîne et les tâches qui en dépendent ne peuvent plus être réclamées ; un coéquipier s’arrête sur erreur au lieu de récupérer ; le lead décide seul que l’équipe a fini alors que des tâches restent ; une écriture de boîte aux lettres échoue. Ce dernier cas est réparé — un message n’est déclaré envoyé que si l’écriture réussit, alors qu’avant la version 2.1.224 Claude Code le déclarait envoyé quand même. Réparé ne veut pas dire impossible : c’est la classe de panne qu’il faut connaître, pas cette version-là.

Et le panneau d’agents ne te sauvera pas : les subagents s’y affichent au même endroit que les coéquipiers, donc le voir peuplé ne confirme pas qu’une équipe s’est formée. Quant à une ligne de coéquipier qui disparaît, elle a été masquée, pas arrêtée : les lignes au repos se cachent trente secondes après que tout le panneau est au repos, et le coéquipier continue de tourner, de consommer et d’être joignable pendant qu’il est caché.

Ce n’est ni automatisable, ni le gain de temps qu’on te vend

Lancer des coéquipiers exige une session interactive. En mode non interactif avec -p, SDK compris, Claude ne lance pas de coéquipier et un subagent nommé reste un subagent ordinaire.

Et pour finir par où cette leçon a commencé, en séparant les deux choses qu’on te vend en une :

• le parallélisme achète du temps de calendrier, et rien d’autre — plusieurs choses avancent pendant que tu fais autre chose. Il ne rend pas le travail meilleur, et il coûte à peu près proportionnellement au nombre d’agents ;
• la coordination, elle, n’achète pas de temps. Une équipe consomme comme autant de sessions qu’elle compte d’agents, ultracode allonge chaque demande, et une exécution de workflow coûte nettement plus que la même tâche en conversation. Ce qu’elle achète, c’est un motif de vérification appliqué sans que tu aies à t’en souvenir ;
• le non-recoupement n’est du côté d’aucun des deux : il s’achète en refusant de coordonner. C’est le geste de la leçon 12, et c’est le moins cher des trois.

Où c’est écrit

Le fond de cette leçon vient de la documentation officielle. Les procédures, les tableaux et les options exhaustives sont là-bas, et c’est délibérément là qu’on t’envoie :

• Faire tourner des agents en parallèle — le tableau des quatre approches, les questions de tri dont les miennes viennent, et le cadran qui correspond à chaque façon de lancer ; puis les pages de chacune : agent view et les cas où son isolation automatique en worktree est sautée, le réglage qui la coupe compris, les équipes, les workflows ;
• La messagerie entre sessions — ce qu’un message transporte et ses conditions de disponibilité ;
• Le coût, les erreurs, les outils pour les outils de tâches et les quatre façons de les rallumer, les hooks, et les subagents pour la limite de vingt et ses exceptions.

Ces liens pointent vers les pages anglaises, pour les raisons données en leçon 4 : la version française existe (remplace /en/ par /fr/), mais elle traduit une partie des mots de ton écran, et elle peut être en retard sur le fond.

Une réserve de date, plus importante ici qu’ailleurs. L’ensemble a été contrôlé le 20 août 2026 contre l’instantané de la documentation officielle du même jour et la version 2.1.234 installée localement. C’est la date du dernier contrôle, pas une promesse de fraîcheur, et ce contrôle-là a retourné le modèle sur lequel tournent les coéquipiers, que cette leçon avait d’abord écrit à l’envers. La page des équipes se décrit elle-même « as of v2.1.178 » et cite des changements jusqu’à la version installée elle-même ; l’absence par défaut des outils de tâches date de la 2.1.233 — une version avant celle installée ici. Sur une fonction expérimentale, ce genre de fait vieillit en jours : vérifie contre ce que claude --version te répond.

Ce que cette leçon ajoute : l’ordre des questions de tri et la branche « je ne sais pas » ; l’arbitrage entre faire parler les agents et les faire taire, avec la clause de phase — que deux pages officielles soutiennent en sens contraire sans jamais se rencontrer ; la contradiction non signalée d’une page sur les permissions d’un workflow ; et un aveu daté sur ce qui a été lancé en parallèle et ce qu’il en est resté.

Le point de bascule

« On peut en lancer plusieurs » cesse d’être une réponse et devient une question : c’est à ça que tu le verras. Devant quatre tâches et l’envie de tout lancer d’un coup, ta première question n’est plus « combien j’en lance ? » mais « est-ce que je veux pouvoir entrer dedans, et est-ce qu’ils ont besoin de se parler ? ».

Vérifier que c’est passé

Ce soir : un bug à corriger, une pull request à relire, un test capricieux à comprendre, une recherche de fond. Tu ne sais pas quels fichiers les trois premières vont toucher. Qu'est-ce que tu lances ?

Pas une équipe. Veux-tu pouvoir entrer dans chaque tâche ? Pour la relecture de pull request et le bug, probablement oui : claude agents, une ligne par tâche. Mêmes fichiers ? Tu n’en sais rien. Ce n’est pas une raison de renoncer : agent view déplace tout seul chaque session dans son propre worktree, sauf dans les trois cas où le déplacement saute (le seul probable ici étant de dépêcher depuis un worktree déjà lié au lieu de ton dépôt principal) et sauf si l’isolation a été coupée pour le dépôt par le réglage prévu pour ça. Donc tu découvriras le conflit au rapatriement au lieu de le deviner. L’une attend-elle une autre ? Si le test capricieux dépend du correctif du bug, ce n’est pas deux tâches parallèles, c’est une file d’attente. Besoin de se parler ? Non — donc pas d’équipe. La recherche part à part en /deep-research, une fois, sur une question posée serrée.

Tu as lu qu'une équipe se coordonne par une liste de tâches partagée, et tu as écrit un hook sur la création de tâche pour imposer un critère de qualité. Tu montes ton équipe sur ton modèle habituel, coéquipiers dans ton terminal. Rien ne se déclenche. Bug ?

Non : depuis la version 2.1.233, les outils de tâches ne sont pas fournis par défaut sur Opus 4.8, Sonnet 5, Fable 5, Mythos 5 et les versions ultérieures de ces familles. Sans eux, l’équipe se coordonne uniquement par messages et le hook TaskCreated ne se déclenche pas du tout : pas une barrière qui laisse passer, l’absence de barrière. Et un dispositif absent produit exactement la même chose qu’un dispositif qui passe. Pour les rallumer : CLAUDE_CODE_ENABLE_TODO_TOOLS=1 claude. Détail qui compte : un coéquipier in-process suit ta session, donc il n’a pas les outils si tu ne les as pas — dans son propre panneau, c’est un processus distinct, et c’est son modèle qui décide : le tien, sauf si tu lui en as nommé un autre.

Tu travailles en mode manuel parce que tu veux voir chaque écriture avant qu'elle se fasse. Tu lances un workflow. Tu gardes la main sur chaque modification de fichier ?

Ne compte pas dessus. La page officielle dit deux choses contradictoires : qu’un workflow lancé par le mot-clé tourne dans le mode de permission de la session, et que ses subagents tournent toujours en acceptEdits quel que soit ton mode, les éditions de fichiers étant approuvées automatiquement. Quand une source se contredit, on retient la lecture qui coûte le moins si elle est vraie : ton mode ne commande que l’invite de lancement. Ce qui peut encore t’interrompre, ce sont les commandes shell, les récupérations web et les outils MCP absents de ta liste. À ne pas confondre avec les équipes, où les coéquipiers démarrent avec le mode du lead et où leurs demandes remontent bien chez toi (leçon 8).