Sommaire

L'agent view de Claude Code (qu'on ouvre avec claude agents) est l'endroit où vous lancez, l'une après l'autre, des sessions indépendantes en arrière-plan et où vous les gérez toutes depuis un seul écran. Dans les mots de la documentation officielle, il permet de « dispatcher et gérer de nombreuses sessions Claude Code depuis un seul écran » (Manage multiple agents with agent view).

Cet article s'en tient à la mécanique et au modèle de sécurité. Le vrai danger, ce n'est pas « l'IA qui déraille » : c'est d'aligner dix sessions sans savoir jusqu'où porte l'isolation ni sous quelles permissions elles tournent, pendant que vous regardez ailleurs. En résumé : l'isolation est construite avec un vrai soin, mais trois choses s'en échappent. C'est là-dessus que votre attention mérite d'aller.

📌 D'où viennent ces informations : chaque comportement, numéro de version et nom de réglage ci-dessous a été vérifié dans la documentation officielle au 9 août 2026. L'agent view est une research preview et exige Claude Code v2.1.139 ou une version ultérieure. Les fonctionnalités en préversion bougent : vérifiez votre propre build avec claude --version et confirmez les détails dans la documentation à jour.

🔀 Si vous êtes arrivé ici en cherchant « Dispatch ». Claude possède deux fonctionnalités différentes aux noms fâcheusement proches. Dispatch, dans le panneau latéral de l'application de bureau, est la fonctionnalité qui vous permet d'écrire à Claude depuis votre téléphone pour qu'il travaille sur votre propre ordinateur — ce n'est pas le sujet de cet article, elle est traitée dans comment fonctionne Dispatch et jusqu'où on peut lui faire confiance. Ici, il est question de l'agent view, une fonctionnalité du terminal Claude Code ; les noms se télescopent parce que la documentation officielle appelle « dispatch » l'opération que vous y effectuez.

1. Ce qu'est l'agent view — l'opération que la documentation appelle « dispatch »

Commençons par clouer le nom au sol. Dans Claude Code, « dispatch » est le nom d'une opération que vous effectuez dans l'agent view, et non celui d'une fonctionnalité distincte. Voici comment la documentation officielle le formule.

« L'agent view, qu'on ouvre avec claude agents, est un écran unique qui montre toutes vos sessions en arrière-plan — ce qui tourne, ce qui attend une réponse de votre part et ce qui est terminé. » (Agent view)

La documentation est tout aussi nette sur le moment où il faut y recourir : quand vous avez plusieurs tâches indépendantes, que vous voulez les déléguer, voir leur état d'un coup d'œil et n'intervenir que lorsqu'il le faut vraiment. Une correction de bug, une relecture de PR, une enquête sur un test instable — jetez-y ces trois-là comme trois lignes, continuez votre propre travail dans une autre fenêtre, et allez voir quand une ligne passe à « il faut vous ».

✅ Le travail qui s'y prête

Des tâches indépendantes les unes des autres et que vous n'avez pas besoin de suivre en cours de route. Du travail où recevoir le résultat à la fin suffit, et où vous pouvez faire autre chose pendant ce temps.

❌ Le travail qui ne s'y prête pas

Tout ce dont la direction doit être rediscutée en cours de route, tout ce qui se dispute les mêmes fichiers, et tout ce qui contient une action irréversible (un déploiement, la base de données de production, un envoi vers l'extérieur).

2. Un prompt égale une session, pas une relance

C'est le premier point sur lequel on se fait avoir. La documentation le dit noir sur blanc : chaque prompt que vous tapez ici démarre sa propre nouvelle session. Tapez un deuxième prompt, appuyez sur Entrée, et vous obtenez une deuxième session à côté de la première, pas une instruction supplémentaire ajoutée à celle-ci.

Tapez « encore un mot sur la dernière » par simple réflexe de conversation et vous n'avez pas ajouté une remarque : vous avez ajouté un travail. C'est un choix de conception plutôt qu'un accident, puisque l'agent view existe précisément pour aligner des tâches indépendantes. Quand vous voulez vraiment envoyer une instruction complémentaire, vous la passez par le panneau d'aperçu (peek panel), décrit plus bas.

Action Ce qui se passe
Un prompt dans le champ de saisie → Enter Démarre une nouvelle session (elles s'accumulent en parallèle)
Space Ouvre le panneau d'aperçu. Vous y voyez la dernière sortie ou la question en attente, pas la transcription complète
Répondre dans le panneau d'aperçu → Enter Répond à cette session sans quitter l'agent view
→ ou Enter (avec une ligne sélectionnée) Entre dans cette session (attach)
Ctrl+X L'arrête. Appuyez une seconde fois et elle est supprimée (ce qui mène droit au piège de la section 6)
Ctrl+S / Ctrl+T / Ctrl+R Regroupement (par état ou par répertoire) / épinglage / renommage

Encore un point : les subagents et les teammates qu'une session engendre pour son propre compte n'apparaissent pas comme des lignes distinctes. L'écran ne liste que les unités que vous avez dispatchées.

3. Comment fonctionne l'isolation — la session part en worktree avant d'écrire

C'est ici que réside le modèle de sécurité. Une session en arrière-plan se déplace dans un worktree git qui lui est propre avant de modifier le moindre fichier. La description officielle est la suivante.

« Toute session en arrière-plan démarre dans votre répertoire de travail, qu'elle ait été lancée depuis l'agent view, avec /bg ou avec claude --bg. Avant de modifier des fichiers, Claude déplace la session dans un worktree git isolé sous .claude/worktrees/. Ainsi, les sessions parallèles lisent la même copie de travail mais chacune écrit dans la sienne. » (Agent view)

Ce qui fait tenir ce dispositif, c'est que les lectures sont partagées et les écritures séparées. Les sessions parallèles peuvent lire le code les unes des autres, donc leurs hypothèses ne divergent pas, tandis que leurs écritures ne peuvent pas entrer en collision. Trois sessions qui tournent dans le même répertoire et s'écrasent mutuellement leurs fichiers — la pire version de cet accident — devient structurellement impossible.

Et puis il y a la phrase qui compte le plus. « Une fois la session dans un worktree, Claude Code bloque les modifications de fichiers et les commandes qui atteindraient la copie de travail principale — aussi bien pour cette session que pour tout subagent qu'elle engendre. » L'isolation est héritée par les enfants. Si une session dispatchée convoque cinq subagents en interne, les cinq se trouvent à l'intérieur du même mur.

4. Les trois contrôles qui font tenir l'isolation

La documentation est précise sur ce que « bloque » veut dire. Il existe trois types de contrôle.

1. Les modifications de fichiers

Bloque Edit, Write et NotebookEdit visant un chemin situé dans la copie de travail principale.

2. Le répertoire de travail des commandes

Bloque les commandes dont le répertoire de travail se résout vers la copie principale, et celles dont on ne peut pas vérifier qu'elles restent en dehors.

3. Le détournement de git

git -C, --git-dir, GIT_DIR, GIT_WORK_TREE, un cd placé avant git — tout cela est coupé.

Avoir fermé la troisième porte est le signe d'un travail sérieux. Il ne s'agit pas seulement de « ne pas écrire dans la principale » mais aussi de « ne pas tromper git pour qu'il pointe vers la principale ». Et l'arbitrage se fait du côté sûr : une commande qui ne peut pas être vérifiée ne s'exécute pas.

⚠️ Cela dit, ce n'est pas un mur au niveau du système d'exploitation. Les trois contrôles fonctionnent en inspectant ce qu'un appel d'outil demande, pas en confinant un processus. Ce qu'ils protègent, c'est la copie de travail principale du même dépôt, et les fichiers situés hors du dépôt, ainsi que le réseau, n'entrent dans le périmètre d'aucun des trois.

La documentation indique aussi clairement que les commandes PowerShell ne reçoivent que le contrôle numéro 2, celui du répertoire de travail. Si PowerShell est votre shell principal sous Windows, ne comptez pas sur la troisième protection. Confiner le processus lui-même n'est pas le rôle du worktree mais celui du bac à sable.

5. D'où viennent les permissions

Pendant que vous regardez ailleurs, sous quel mode de permission tourne cette session ? Aligner des sessions sans réponse à cette question est la chose la plus dangereuse que vous puissiez faire ici.

La règle officielle est sans ambiguïté. Quand vous dispatchez depuis le champ de saisie de l'agent view, ou que vous lancez claude --bg depuis un shell, c'est le defaultMode des réglages de ce répertoire qui est utilisé. Si ce que vous avez dispatché est un subagent, c'est le permissionMode de son frontmatter qui s'applique à la place.

Autrement dit, les permissions ne se choisissent pas sur le moment : elles sont héritées de votre configuration. Plus votre defaultMode habituel dans settings.json est permissif, plus il devient littéralement vrai qu'au moment où vous dispatchez, dix sessions sans surveillance et à permissions larges viennent au monde. Mettre de l'ordre dans vos modes de permission et vos règles de permission au préalable est une condition, pas un raffinement.

Là où ça doit s'arrêter, en revanche, ça s'arrête correctement. Quand une session a besoin de quelque chose que vous seul pouvez fournir — une réponse à une question, une décision d'autorisation, l'instruction suivante — la ligne passe à « Needs input ». Cet état est le seul point de contrôle qui vous reste. Et c'est pourquoi l'agent view n'est pas « un écran où on aligne des choses avant de partir » mais « un écran où l'on revient pour récupérer les lignes qui attendent une réponse ».

6. Les pièges qu'on ne voit pas venir

L'isolation est soigneusement construite. Malgré tout, trois choses s'en échappent. C'est la partie qui mord pour de bon dans le travail réel.

1. Une autorisation « ne plus demander » sort du worktree

D'après la documentation, choisir « Oui, ne plus demander » pour une commande Bash dans une session en worktree enregistre cette règle dans le .claude/settings.local.json de la copie de travail principale. Résultat : elle s'applique dans la copie principale et dans tous les autres worktrees, et elle survit à la suppression du worktree où elle a été accordée.
Donc une seule décision d'autorisation prise dans un endroit isolé devient une configuration permanente en dehors de lui. Un « ne plus demander » cliqué pendant que vous regardiez ailleurs, à l'intérieur de ce que vous preniez pour un espace de brouillon, s'applique à partir de là. Ne cédez pas au réflexe du « ne plus demander » quand le panneau d'aperçu d'une session dispatchée vous demande une autorisation.

2. Supprimer une session emporte avec elle le travail non commité

C'est écrit tel quel dans les limitations officielles : « Les worktrees créés par Claude sont supprimés en même temps que la session quand vous la supprimez dans l'agent view. Commitez vos modifications avant de supprimer une session qui a modifié des fichiers dans son propre worktree. »
Ctrl+X, c'est arrêter à la première pression, supprimer à la seconde. Appuyez deux fois en faisant le ménage dans une session terminée et le résultat part avec. « Terminé » et « récupéré » ne sont pas la même chose : une fois le résultat entre vos mains, commitez-le ou fusionnez-le avant de supprimer.

3. .worktreeinclude distribue vos secrets à chaque worktree

Un worktree est une copie de travail neuve : un .env ignoré par git n'y figure pas. Comme rien ne tourne sans lui, vous le listez dans .worktreeinclude et il est copié automatiquement à chaque création d'un nouveau worktree.
Pratique — mais retourné dans l'autre sens, cela veut dire qu'une copie supplémentaire de vos identifiants atterrit sur le disque pour chaque session que vous dispatchez. Si vous faites tourner tout ça en parallèle, la seule chose raisonnable est de distribuer des clés de développement, pas celles de production.

Trois autres limitations sont listées officiellement. Le quota se vide de façon multiplicative (« faire tourner dix agents en parallèle consomme votre quota environ dix fois plus vite qu'un seul »). Les sessions tournent en local — elles survivent à la mise en veille, mais éteindre la machine les arrête. Et enfin le fait qu'il s'agisse d'une research preview.

7. Choisir entre les approches — il y a quatre façons de paralléliser

La documentation officielle range la parallélisation en quatre approches. Le dispatch (agent view) n'en est qu'une, si bien que choisir la mauvaise se paie sans détour.

Approche Qui mène la danse Quand la choisir
Subagents Claude délègue au sein d'une même conversation et récupère le résultat Vous ne voulez pas que les sorties du travail annexe (résultats de recherche, logs, fichiers) polluent le contexte principal
Agent view (dispatch) Vous déléguez et vous allez voir plus tard Plusieurs tâches indépendantes. Le sujet de cet article. Research preview
Agent teams Claude planifie, répartit et supervise Vous voulez qu'on prenne en charge pour vous la répartition du travail et la synchronisation. Expérimental, désactivé par défaut. Traité dans son propre article
Workflows dynamiques C'est un script qui tient le plan Un audit de toute la base de code, une migration de 500 fichiers — une échelle qu'aucun tour de conversation ne peut piloter. Et quand les résultats doivent être recoupés

La ligne de partage, c'est qui mène la danse. Si ça se termine à l'intérieur d'une conversation, subagents. Si c'est vous qui lancez et récupérez plus tard, agent view. Si vous voulez que ce soit Claude qui mène, agent teams. Si l'échelle appelle une procédure fixe plutôt qu'un jugement au cas par cas, workflows dynamiques.

Les worktrees, soit dit en passant, sont présentés non comme une façon de paralléliser mais comme un outil d'isolation. L'agent view les utilise automatiquement. Pour les sessions parallèles que vous démarrez vous-même, vous en nommez un explicitement, comme dans claude --worktree <name>.

8. Une routine pour faire tourner tout ça sans casse

Avant de dispatcher

  • Vérifiez le defaultMode de ce répertoire. Il devient, mot pour mot, le niveau de permission d'une session que personne ne surveille
  • Ne déléguez pas un travail contenant des actions irréversibles. Les déploiements, la base de production et les envois vers l'extérieur ont leur place dans une session que vous regardez
  • Les tâches sont-elles vraiment indépendantes ? Si elles dépendent de la même décision de conception, tranchez celle-ci d'abord, puis déléguez
  • Qu'y a-t-il dans votre .worktreeinclude ? Vos clés sont copiées une fois par session alignée

Pendant l'exécution

  • Revenez pour les lignes « Needs input ». C'est le seul point de contrôle
  • Quand on vous demande une autorisation, ne choisissez pas « ne plus demander ». Cette décision survit au worktree
  • Le parallélisme se traduit directement en quota. Dix à la fois le vident dix fois plus vite

Une fois terminé

  • Commitez avant de supprimer. Le second Ctrl+X supprime, et le contenu du worktree part avec
  • Ne prenez pas les résultats pour argent comptant. Tout ce que vous avez fait tourner en parallèle a ajouté une affirmation non vérifiée de plus

Ce dernier point mérite d'être souligné comme règle générale. Paralléliser augmente la quantité totale de relecture. Dix travaux reviennent avec dix questions « est-ce que c'est vrai, ça ? » accrochées derrière ; la vérification, elle, ne se parallélise pas avec le travail. Le plafond du nombre de sessions que vous dispatchez est fixé par le nombre de résultats que vous êtes capable de vérifier.

Résumé

Le dispatch est l'acte de démarrer une session indépendante en arrière-plan depuis l'agent view (claude agents), et il s'agit d'une research preview (v2.1.139 ou ultérieure). Un prompt devient une session, jamais une relance.

Le cœur du modèle de sécurité, c'est l'isolation par worktree. Avant d'écrire, la session se déplace dans .claude/worktrees/, et à partir de là les lectures sont partagées tandis que les écritures sont séparées. Les modifications, les commandes et les détournements de git qui atteindraient la copie de travail principale sont coupés par trois contrôles, et cette protection est héritée par chaque subagent que la session engendre.

Mais trois choses sortent de l'isolation. Une autorisation « ne plus demander » est enregistrée du côté principal, s'applique dans tous les worktrees et survit à la suppression du worktree. Supprimer une session détruit le travail non commité. .worktreeinclude copie vos secrets une fois par worktree. Et comme un worktree n'est pas un mur au niveau du système, tout ce qui se trouve hors du dépôt ainsi que le réseau ne sont pas protégés — c'est le rôle du bac à sable.

FAQ

Q1. Existe-t-il une fonctionnalité qui s'appelle vraiment « Dispatch » dans Claude Code ?

Pas en tant que nom de fonctionnalité autonome. Dispatch est le nom d'une opération à l'intérieur de l'agent view. La documentation officielle décrit l'agent view comme la fonctionnalité qui permet de « dispatcher et gérer de nombreuses sessions Claude Code depuis un seul écran ». La commande qui l'ouvre est claude agents.

Q2. /agents et claude agents, est-ce la même chose ?

Non. La documentation met directement en garde : malgré la ressemblance des noms, /agents n'est pas claude agents. claude agents est la commande shell qui ouvre l'agent view. /agents, depuis la v2.1.198, n'ouvre plus aucun panneau : elle se contente de vous indiquer où se trouvent vos fichiers de définition de subagents.

Q3. Une session dispatchée peut-elle abîmer ma copie de travail principale ?

Pour ce qui est de la copie de travail principale du même dépôt, vous êtes protégé structurellement. Les modifications de fichiers, les répertoires de travail des commandes et les détournements de git sont bloqués par les trois contrôles, et la même protection couvre tout subagent que la session engendre. En revanche, les fichiers situés hors du dépôt et le réseau sont hors périmètre, et sous PowerShell seul le contrôle du répertoire de travail s'applique.

Q4. Quel effet la parallélisation a-t-elle sur le coût ?

Il augmente à peu près proportionnellement au nombre. Les limitations officielles le disent : faire tourner dix agents en parallèle consomme votre quota environ dix fois plus vite qu'un seul. Arrière-plan ne veut pas dire bon marché.

Q5. Puis-je supprimer une session une fois qu'elle est terminée ?

Commitez d'abord, supprimez ensuite. La documentation indique que les worktrees créés par Claude sont supprimés en même temps que la session quand vous la supprimez dans l'agent view. Ctrl+X arrête à la première pression et supprime à la seconde. Avoir reçu le résultat n'équivaut pas à l'avoir récupéré.

Q6. Puis-je choisir le mode de permission à chaque dispatch ?

Pas sur le moment. C'est le defaultMode des réglages de ce répertoire qui est utilisé — ou, si vous avez dispatché un subagent, le permissionMode de son frontmatter. Si votre defaultMode habituel est permissif, c'est cette permissivité qui tourne sans surveillance. Revoyez vos réglages de permission avant de commencer à utiliser le dispatch.

Q7. En quoi est-ce différent des subagents ?

La différence tient à qui mène la danse. Avec les subagents, Claude délègue au sein d'une même conversation et rend le résultat à cette conversation. Avec l'agent view, c'est vous qui déléguez des tâches indépendantes et qui récupérez les résultats après coup. Les subagents engendrés par une session n'apparaissent pas comme des lignes dans l'agent view.

Q8. Que se passe-t-il si je referme mon ordinateur portable ?

Les sessions s'arrêtent. Les limitations officielles précisent que les sessions en arrière-plan tournent sur votre machine : elles survivent à la mise en veille, mais éteindre la machine les arrête. Rien ne tourne dans le cloud, ce n'est donc pas l'outil pour lancer un long travail par-dessus le mur et rentrer chez vous.

Articles liés