Tâches parallèles : faire travailler plusieurs Claude simultanément plutôt qu'en file d'attente

📚 Navigation de la série : L'article précédent 40 Chrome : lui faire manipuler le navigateur vous a appris à étendre les capacités de Claude au navigateur pour cliquer sur des pages et remplir des formulaires de façon autonome. Cet article aborde une autre dimension — non pas confier une tâche supplémentaire à un seul Claude, mais lancer plusieurs tâches en parallèle. Nous détaillerons les trois méthodes : l'isolation par git worktree, la gestion de sessions multiples en arrière-plan et l'exécution de scripts en mode headless. Enfin, nous aborderons la question cruciale : quand le parallélisme fait gagner du temps et quand il devient contre-productif.

C'est un peu gênant à avouer, mais la première fois que j'ai voulu travailler « en parallèle », j'ai fait une belle erreur : j'ai ouvert deux terminaux, je me suis positionné dans le même répertoire de projet avec cd, et j'ai demandé à un Claude de modifier la page de connexion front-end tandis que l'autre devait corriger un bug back-end.

Je me disais tout content : « Voilà de quoi doubler ma productivité ! »

Résultat : les deux instances modifiaient simultanément le fichier package.json. Les dépendances ajoutées par l'une étaient directement écrasées et annulées par les modifications de l'autre. Un coup d'œil à git status montrait un espace de travail totalement désorganisé où il était impossible de distinguer l'auteur de chaque ligne de code. Ce jour-là, j'ai perdu bien plus de temps à démêler manuellement les modifications qu'il ne m'en aurait fallu en traitant les tâches de façon séquentielle. C'est là que j'ai compris : paralléliser ne se résume pas à ouvrir plusieurs fenêtres, l'essentiel est de veiller à ce que les processus n'interviennent pas sur les mêmes zones.

Heureusement, Claude Code intègre des solutions adaptées pour gérer le parallélisme — --worktree attribue à chaque session une copie isolée du codebase, --bg bascule les tâches en arrière-plan et claude agents fournit une console de contrôle centralisée. Dans cet article, nous allons voir comment surmonter ces difficultés et appliquer concrètement ces différentes méthodes.

À la fin de cet article, vous obtiendrez :

• Une explication simple de l'intérêt de la parallélisation et de ses deux prérequis : des tâches indépendantes et l'absence de conflits sur les fichiers
• Un tableau comparatif des quatre approches officielles (subagents, agent view, agent teams et workflows) pour choisir la plus adaptée à vos besoins
• La méthode pour isoler chaque session avec --worktree afin d'éviter les écrasements de code, avec des précisions sur le fichier .worktreeinclude et la gestion du nettoyage
• La gestion des tâches en arrière-plan avec claude agents et --bg pour surveiller l'avancement sur un écran unique et n'intervenir qu'en cas de besoin
• L'utilisation de claude -p (mode headless) pour automatiser des tâches par scripts, optimisé avec l'option --bare pour accélérer le démarrage
• Le critère de décision essentiel : déterminer quand la parallélisation est bénéfique et quand elle complexifie inutilement le travail

---

01 Clarifier le besoin : quel problème résout la parallélisation et sous quelles conditions ?

Pour faire simple : la parallélisation évite d'exécuter de manière séquentielle des tâches totalement indépendantes. Cependant, elle requiert un prérequis absolu : éviter que ces tâches n'interviennent sur les mêmes fichiers.

Si vous repensez aux quarante chapitres précédents, nous avons presque exclusivement travaillé au sein d'une session unique — lancer une instance de Claude, lui envoyer des instructions et le laisser opérer étape par étape. Ce mode opératoire convient pour 90 % des développements. Cependant, deux cas de figure peuvent vous amener à le trouver trop lent.

D'une part, lorsque les tâches sont naturellement découplées et indépendantes. Par exemple, modifier un style front-end, corriger une anomalie back-end et ajouter des tests unitaires sont trois actions distinctes qui n'ont aucun lien entre elles. Pourtant, elles s'exécutent de façon séquentielle : la correction back-end attend la fin des modifications de l'interface. Bien qu'elles puissent être traitées simultanément, vous êtes contraint de les sérialiser.

D'autre part, lorsque la charge de travail s'avère trop importante pour une seule session. C'est le cas si vous devez remplacer une API obsolète sur l'ensemble d'un codebase impliquant des dizaines de fichiers. Mener cette modification au sein d'une seule session sature rapidement la fenêtre de contexte (sa mémoire de travail, voir chapitre 19), ce qui nuit à sa précision à mesure que le traitement avance.

Analogie : le passage en caisse au supermarché. Si une seule caisse est ouverte, dix clients font la queue avec leur panier et le dernier doit attendre le passage des neuf précédents — c'est le traitement séquentiel. Un magasin bien organisé ouvrira des caisses supplémentaires pour répartir les clients sur trois ou quatre files d'attente simultanées, réduisant ainsi drastiquement l'attente globale. Paralléliser le travail revient à ouvrir ces caisses supplémentaires : répartir les tâches indépendantes entre plusieurs instances de Claude pour qu'elles s'exécutent en même temps au lieu d'attendre dans une file unique.

Cependant, l'ouverture de caisses supplémentaires repose sur un prérequis implicite : each file d'attente doit être autonome et sans interférence. Si three caissiers partagent le même tiroir-caisse et y manipulent la monnaie en même temps, la confusion s'installe immédiatement — c'est l'erreur du scénario initial. La règle d'or de la parallélisation est donc la suivante :

Les tâches touchent-elles aux mêmes fichiers ? Utilisez des worktrees pour isoler le travail.

En pratique, voici les scénarios adaptés à la parallélisation :

• « Corriger des bugs sur three modules indépendants » — lancer three sessions simultanées, sans interférence
• « Identifier le code mort au sein du répertoire utils/ » — déléguer la recherche à un sous-agent pour éviter d'encombrer le contexte de la discussion principale (voir chapitre 23)
• « Appliquer une même modification par script sur 30 fichiers différents » — automatiser le traitement sous forme de tâches headless

💡 Résumé en une phrase : La parallélisation permet d'exécuter des tâches indépendantes en simultané (comme ouvrir des caisses de supermarché supplémentaires) ; cependant, son efficacité repose sur une condition unique — éviter que les processus ne ciblent les mêmes fichiers, sous peine de générer des conflits.

---

02 Les quatre approches officielles : distinguer les solutions pour faire le bon choix

Claude Code propose plusieurs approches pour gérer le parallélisme. La documentation comporte une page dédiée à l'exécution d'agents en parallèle. Le critère de distinction principal réside dans la question suivante : qui assure la coordination des tâches ? S'agit-il de Claude qui distribue et consolide le travail au sein d'une même session, de vous-même qui lancez les processus en arrière-plan pour vérification ultérieure, ou de Claude qui orchestre une équipe d'agents ?

Voici un aperçu des quatre méthodes disponibles (cette section sert de vue d'ensemble, les chapitres suivants détaillent chaque solution) :

Approche	Définition	Coordination	Cas d'usage type
Subagents (sous-agents)	Processus lancé au sein d'une session, travaillant sur son propre contexte et retournant un résumé à la fin	Gérée par Claude au sein de la discussion	Éviter d'encombrer la session principale avec des logs ou des résultats de recherche intermédiaires qui ne vous intéressent pas
Agent view (vue d'ensemble)	Console unique pour superviser et orchestrer plusieurs sessions en arrière-plan via la commande claude agents (Research Preview)	Supervisée par vous-même à intervalles réguliers	Vous lancez plusieurs tâches indépendantes et souhaitez en contrôler l'état d'un coup d'œil, en n'intervenant qu'en cas de besoin
Agent teams (équipes d'agents)	Sessions multiples collaborant sur une liste de tâches commune et s'échangeant des messages sous la direction d'un leader (Expérimental, désactivé par défaut)	Orchestrée par Claude agissant comme chef d'équipe	Vous souhaitez que Claude découpe un projet complexe en sous-tâches, les distribue à des agents et assure leur synchronisation (voir chapitre 29)
Workflows (flux de travail dynamiques)	Scripts exécutant une série de sous-agents en parallèle avec vérification croisée des résultats (Research Preview)	Gérée par script plutôt que par interaction séquentielle avec Claude	Tâches de grande envergure (audit complet d'un codebase, migration de 500 fichiers) dépassant les capacités de coordination de simples sous-agents

⚠️ Notes de compatibilité : L' agent view et les workflows sont en version d'évaluation (Research Preview) ; les agent teams sont en version expérimentale et désactivées par défaut. Les interfaces, les raccourcis et les comportements sont susceptibles d'évoluer. Vérifiez votre version avec claude --version avant de commencer. Les subagents constituent une fonctionnalité stable.

Retenez simplement ce principe de base : la méthode de coordination définit l'approche — répartition directe par Claude au sein d'un échange → subagent ; décentralisation en arrière-plan sous votre contrôle → agent view ; gestion d'équipe par Claude agissant comme leader → agent teams ; automatisation séquentielle par script → workflows.

Deux autres composants ne constituent pas des approches de parallélisation à proprement parler, mais agissent comme des utilitaires de support. Nous nous concentrerons sur le premier dans cet article :

• Worktrees : Offrir à chaque session sa propre copie Git de travail, garantissant que deux sessions parallèles n'éditent jamais le même fichier. C'est la solution technique au problème décrit dans le scénario initial (détails à la section 03).
• /batch : Un skill permettant à Claude de découper une modification d'envergure en 5 à 30 sous-agents isolés par des worktrees, chacun soumettant sa propre Pull Request. Il s'agit d'une combinaison pratique des concepts de subagent et de worktree, et non d'une méthodologie d'orchestration distincte.

Les concepts de subagents (chapitre 23) et d'agent teams (chapitre 29) ayant déjà été détaillés, ils ne seront pas abordés ici. Cet article se concentre sur les aspects non traités : l'isolation par worktree, les sessions multiples en arrière-plan et l'exécution headless.

💡 Résumé en une phrase : La parallélisation propose quatre approches structurées se distinguant par leur mécanisme de coordination ; les worktrees et le skill /batch agissent comme des utilitaires de support ; cet article traite spécifiquement de l'isolation par worktree, des tâches en arrière-plan et du mode headless.

---

03 Isolation par worktree : attribuer une copie dédiée à chaque session

Cette section apporte la réponse au problème d'interférence initial et constitue le concept clé de ce chapitre.

Rappelons l'origine du conflit : lancer deux sessions au sein du même répertoire revient à faire travailler deux personnes sur le même document physique. Les modifications s'écrasent mutuellement de façon inévitable. L'utilisation de git worktree (une fonctionnalité native de Git) permet de résoudre ce problème à la racine.

Analogie : photocopier un document en plusieurs exemplaires pour que chacun travaille sur sa copie. Si three ingénieurs doivent apporter des annotations sur un unique plan papier en même temps, le document deviendra rapidement illisible. La bonne méthode consiste à en faire three copies — chacun travaille sur la sienne, puis les modifications sont consolidées à la fin. C'est le rôle de git worktree : générer à partir d'un même historique de dépôt plusieurs répertoires de travail indépendants, disposant chacun de leurs propres fichiers et branches, tout en partageant la base de commits et le dépôt distant. Les modifications appliquées par une session sur sa copie de travail n'altèrent pas les fichiers des autres sessions.

La documentation officielle résume parfaitement cet avantage :

在自己的 worktree 中运行每个 Claude Code 会话意味着一个会话中的编辑永远不会触及另一个会话中的文件，因此您可以让 Claude 在一个终端中构建功能，同时在第二个终端中修复错误。

Lancer une session isolée en une seule commande

La méthode la plus directe : ajouter l'argument --worktree (ou l'abréviation -w) suivi d'un identifiant au démarrage. Claude créera automatiquement un répertoire de travail isolé et y lancera la session. Par défaut, ce worktree is placé sous le chemin .claude/worktrees/<nom>/ à la racine de votre dépôt, avec une branche nommée worktree-<nom> :

claude --worktree feature-auth

Pour lancer une seconde session indépendante : ouvrez un autre terminal, spécifiez un identifiant différent et lancez la même commande :

claude --worktree bugfix-123

Les deux sessions opèrent désormais sur leurs copies respectives, l'une sur les fonctionnalités et l'autre sur la correction de bugs, sans interférence sur les fichiers. Si vous ne souhaitez pas spécifier d'identifiant, omettez-le pour laisser Claude en générer un automatiquement (par exemple, bright-running-fox) :

claude --worktree

Vous pouvez également lui demander de basculer en worktree en cours de session par une simple consigne : « Travaille dans un worktree ». L'outil utilisera alors EnterWorktree pour initialiser le répertoire.

Before la première utilisation de --worktree dans un répertoire, vous devez y exécuter une instance standard de claude afin de valider la boîte de dialogue de confiance de l'espace de travail. Sans cette validation préalable, --worktree renverra une erreur et vous demandera de lancer claude normalement (cette règle s'applique également au mode -p).

Trois points de vigilance pour les débutants

Piège 1 : Le répertoire .claude/worktrees/ doit être ajouté à votre .gitignore. Dans le cas contraire, les fichiers de ces répertoires de travail apparaîtront comme non suivis (untracked) dans votre répertoire principal, ce qui pollue vos retours Git. La documentation insiste sur ce point.

Piège 2 : Le worktree étant une copie neuve, votre fichier .env n'y figure pas. Le worktree est un checkout propre. Les fichiers non suivis par Git présents dans votre répertoire principal (tels que .env ou .env.local) ne sont pas copiés par défaut. Par conséquent, les sessions parallèles risquent d'échouer par manque de variables d'environnement. La solution consiste à créer un fichier .worktreeinclude à la racine de votre projet, en y listant les fichiers locaux à copier automatiquement dans chaque worktree (la syntaxe est identique à celle de .gitignore) :

.env
.env.local
config/secrets.json

J'ai moi-même fait cette erreur : après avoir lancé une session avec -w pour modifier du code back-end, Claude affichait en boucle une erreur de connexion à la base de données. J'ai passé du temps à analyser le problème, pensant à une panne de base de données, avant de réaliser que le fichier .env n'avait pas été copié dans le worktree, rendant la chaîne de connexion inaccessible. Depuis, je place systématiquement un fichier .worktreeinclude à la racine de mes projets pour m'épargner ce désagrément.

Piège 3 : Choisir entre « conserver » ou « supprimer » à la fermeture. Les règles de nettoyage par défaut sont les suivantes :

• Aucune modification effectuée (aucun changement non validé, aucun fichier non suivi, aucun nouveau commit) : Le worktree et sa branche sont supprimés automatiquement. Toutefois, si la session a fait l'objet d'un nommage explicite via --name, Claude demandera confirmation avant de procéder.
• Des modifications ont été apportées : Claude vous demandera s'il faut « conserver ou supprimer » le répertoire — choisir la conservation préserve le répertoire et la branche pour y revenir plus tard ; choisir la suppression efface le travail non commité.
• Les worktrees créés en mode non interactif (-p) ne sont pas nettoyés automatiquement en l'absence d'invite de sortie ; vous devez les supprimer manuellement avec la commande git worktree remove.

Initialiser les worktrees manuellement

Si vous souhaitez contrôler l'emplacement et la branche cible de vos répertoires de travail, vous pouvez utiliser directement les commandes Git natives (ce sujet est détaillé au chapitre 43 « Flux de travail Git ») :

# 在新分支上建一个 worktree
git worktree add ../project-feature-a -b feature-a

# 进去启动 Claude
cd ../project-feature-a && claude

# 列出所有 worktree
git worktree list

# 干完删掉
git worktree remove ../project-feature-a

La documentation officielle souligne un point que l'on oublie fréquemment : chaque worktree constitue un checkout indépendant. Vous devez y réinstaller les dépendances et configurer votre environnement virtuel — le répertoire ne partagera pas les dossiers node_modules du répertoire principal.

💡 Résumé en une phrase : Le worktree attribue à chaque session sa propre copie de travail isolée (comme annoter des photocopies distinctes) ; la commande claude --worktree <nom> initialise le processus ; retenez les trois points de vigilance — déclarer le répertoire dans le .gitignore, lister les fichiers requis dans .worktreeinclude et choisir le sort du worktree lors de la fermeture.

---

04 Sessions multiples en parallèle : tâches en arrière-plan et console de supervision

Si l'isolation par worktree évite les conflits de fichiers, une question se pose : devez-vous ouvrir autant de terminaux et basculer de l'un à l'autre pour surveiller vos différentes sessions ? Cela s'avère fastidieux. C'est ici qu'intervient l'agent view (vue d'ensemble des agents).

Analogie : le tableau d'affichage de la tour de contrôle d'un aéroport. Les aiguilleurs du ciel ne se focalisent pas sur un seul avion. Un écran central récapitule l'état de l'ensemble des vols : roulage, attente d'autorisation, atterrissage. Les opérateurs gardent un œil sur la synthèse et n'interviennent que lorsqu'un vol requiert leur validation. La commande claude agents fournit ce même tableau de bord : toutes les sessions en arrière-plan y sont listées, leur statut est immédiatement identifiable et vous n'intervenez que si nécessaire.

⚠️ Version d'évaluation : L' agent view est une fonctionnalité en phase d'évaluation (Research Preview). Elle nécessite une version récente de Claude Code. Les interfaces et raccourcis sont susceptibles d'évoluer. Vérifiez votre configuration avec claude --version au préalable.

Envoyer des tâches en arrière-plan

Le principe d'une session en arrière-plan est qu'elle est détachée de votre terminal actif — fermer la fenêtre, quitter le shell ou initier un autre échange n'interrompt pas son exécution. Il existe deux méthodes pour l'activer.

Option 1 : Depuis le terminal au démarrage, avec l'option --bg :

claude --bg "调查一下 SettingsChangeDetector 这个不稳定的测试为啥老挂"

Après validation, Claude affiche l'identifiant court de la session et les commandes d'administration associées :

backgrounded · 7c5dcf5d
  claude agents             list sessions
  claude attach 7c5dcf5d    open in this terminal
  claude logs 7c5dcf5d      show recent output
  claude stop 7c5dcf5d      stop this session

Option 2 : En cours de discussion, en saisissant /bg (abréviation de /background) pour déplacer l'échange en arrière-plan.

Superviser le travail via claude agents

Lancez la console de supervision :

claude agents

L'interface occupe l'intégralité du terminal et regroupe les sessions en arrière-plan par état d'avancement — « Requiert votre intervention », « En cours de traitement » ou « Terminé ». Les icônes et couleurs indiquent l'état de chaque tâche :

État	Indicateur visuel	Signification
En cours de traitement	Icône animée	Exécution d'un outil ou génération d'une réponse
Requiert votre intervention	Jaune	Attente d'une validation de permission ou d'une réponse de votre part
Terminé	Vert	Tâche exécutée avec succès
Échec	Rouge	Erreur lors de l'exécution

L'utilisation de la console de supervision s'appuie sur three commandes principales :

• Espace (aperçu) : Sélectionner une ligne et appuyer sur Espace affiche un panneau récapitulant les dernières lignes d'activité ou le point de blocage — évitant ainsi d'entrer dans la session complète pour une simple vérification.
• Répondre : Saisir du texte directement au sein du panneau d'aperçu et appuyer sur Entrée transmet le message sans quitter la console globale.
• Entrée / → (attacher) : Pour intervenir activement dans une session, appuyer sur Entrée vous connecte à la discussion sous forme de console interactive ; appuyer sur ← dans une ligne de saisie vide vous ramène au tableau de bord général.

Voici un détail important mais peu visible qui fait le lien avec la section précédente : avant d'éditer le moindre fichier, chaque session en arrière-plan est automatiquement isolée par Claude au sein d'un worktree sous .claude/worktrees/. En d'autres termes — l'utilisation de l'agent view prend en charge automatiquement l'isolation de vos répertoires de travail, vous évitant d'avoir à spécifier manuellement -w comme décrit à la section 03. La documentation officielle valide ce comportement : l'agent view crée les worktrees associés pour chaque session distribuée.

Exemple de flux parallèle courant : lancer three sessions en arrière-plan pour corriger un test instable (flaky), analyser une Pull Request et documenter une fonction. Vous pouvez vaquer à vos occupations, puis lancer de temps à autre claude agents — valider les tâches terminées (en vert) ou répondre aux demandes de permission (en jaune). C'est bien plus efficace que de gérer three terminaux ouverts.

⚠️ Rappel sur la facturation : Les sessions en arrière-plan consomment votre forfait de la même manière que les discussions interactives. Lancer dix sessions en parallèle multiplie votre consommation par dix. Évitez d'ouvrir un nombre excessif de processus sous prétexte qu'ils s'exécutent en tâche de fond.

💡 Résumé en une phrase : La commande --bg (au lancement) ou /bg (en cours de discussion) bascule la session en arrière-plan, tandis que claude agents affiche le tableau de bord de supervision ; les commandes d'aperçu (Espace) et de reconnexion (Entrée) permettent d'agir sur les processus ; l'isolation par worktree est automatisée pour ces tâches, mais gardez à l'esprit l'impact sur votre consommation de crédit.

---

05 Mode Headless : automatiser les tâches par scripts

Les deux approches précédentes requièrent votre présence devant le terminal. Cependant, certaines tâches ne nécessitent pas de supervision directe — comme appliquer une même modification sur une série d'éléments, ou intégrer Claude dans un script ou un outil d'Intégration Continue (CI) pour l'appeler de façon automatique comme un utilitaire CLI. C'est le rôle du mode headless (mode non interactif s'exécutant sans interface graphique avant de fermer).

Analogie : glisser une consigne écrite dans un automate et récupérer le produit. Vous ne restez pas devant le distributeur à observer le mécanisme interne. Vous insérez la monnaie, tapez le code et l'article est éjecté. Le mode headless fonctionne de la même manière : vous déclarez vos consignes et paramètres au sein de la commande claude -p指定，l'outil exécute la tâche et renvoie le résultat sur la sortie standard avant de s'arrêter.

L'option dédiée est -p (ou --print). Spécifier cette option lance claude en mode non interactif pour une exécution unique :

claude -p "找出 auth.py 里的 bug 并修掉" --allowedTools "Read,Edit,Bash"

L'argument --allowedTools permet de déclarer les autorisations d'outils préalables — aucun utilisateur n'étant présent pour cliquer sur « Valider », vous devez lui indiquer les outils qu'il est autorisé à appeler de manière autonome sans blocage (la gestion des droits est détaillée aux chapitres 20 et 35).

Trois utilitaires complémentaires

1) Redirection d'entrée (pipes). Le mode headless lisant l'entrée standard (stdin), vous pouvez lui rediriger des données via des pipes comme avec n'importe quel utilitaire CLI. Par exemple, pour analyser un journal d'erreur de compilation et exporter le retour dans un fichier :

cat build-error.txt | claude -p "简明扼要说清这个构建错误的根因" > output.txt

C'est une méthode particulièrement rapide pour diagnostiquer un échec de compilation sans avoir à copier-coller manuellement le log dans une discussion.

2) L'option --bare pour accélérer le chargement. Par défaut, claude -p charge le même contexte qu'une session interactive (hooks, skills, plugins, configurations MCP et fichier CLAUDE.md). Cette au niveau de l'initialisation peut s'avérer lente dans un script ou être polluée par des configurations utilisateur sous ~/.claude. L'option --bare désactive ces mécanismes de recherche automatique, réduisant le temps de démarrage et assurant un comportement reproductible d'une machine à l'autre :

claude --bare -p "总结这个文件" --allowedTools "Read"

La documentation officielle le souligne :

--bare 是脚本和 SDK 调用的推荐模式，将在未来版本中成为 -p 的默认值。

3) Format structuré avec --output-format json. Parser du texte brut au sein d'un script est souvent complexe. L'option --output-format json force l'outil à retourner un objet JSON structuré avec métadonnées (résultat, identifiant de session et coût d'exécution avec total_cost_usd). Il vous suffit ensuite de le traiter avec un outil comme jq :

claude -p "总结这个项目" --output-format json | jq -r '.result'

Automatiser le traitement par lot

Une exécution unique avec -p n'est pas encore un traitement par lot. La véritable automatisation consiste à encapsuler la commande au sein d'une boucle shell afin de répéter l'opération sur une liste de fichiers. Par exemple, pour documenter chaque fichier .py d'un répertoire :

for f in src/*.py; do
  claude --bare -p "用一句话说明 $f 是干什么的" --allowedTools "Read"
done

Voici la structure type d'un script d'automatisation : une boucle, l'option -p et l'option --bare. Si le volume de modifications concerne des centaines de fichiers ou requiert une phase de vérification croisée, tournez-vous vers les workflows dynamiques ou le skill /batch présentés à la section 02, qui industrialisent cette approche.

⚠️ Note sur la facturation : La documentation officielle indique que l'usage de l'Agent SDK et de claude -p dans le cadre d'un abonnement payant est décompté d'un crédit mensuel distinct dédié à l'Agent SDK, séparé de votre consommation interactive standard. Prenez ce point en compte avant de lancer des traitements par lots massifs (détails au chapitre 06).

💡 Résumé en une phrase : Le mode headless s'active avec claude -p pour une exécution unique non interactive ; l'automatisation s'optimise avec --allowedTools pour accorder les permissions d'outils, --bare pour accélérer le démarrage et --output-format json pour structurer le retour ; encapsuler cette commande dans une boucle for permet d'automatiser des traitements par lots simples.

---

06 Recommandations : quand éviter le parallélisme

Malgré la commodité de ces three méthodes, cette section s'avère essentielle — de nombreux développeurs ayant tendance à vouloir tout paralléliser dès qu'ils maîtrisent ces outils, au risque de complexifier les développements et d'augmenter inutilement leur consommation de crédit.

Voici le critère de choix. Pour qu'une parallélisation soit bénéfique, elle doit valider deux critères simultanément : des tâches indépendantes (l'étape A ne conditionne pas l'étape B) et l'absence de conflit sur les fichiers (ou une isolation garantie par worktree). Si l'une de ces conditions manque, vous vous exposez à des difficultés.

Voici un comparatif des scénarios adaptés à chaque approche :

Scénario	Choix de traitement	Justification
Correction de bugs sur three modules indépendants	✅ Parallèle	Tâches décorrélées sans conflit de fichiers : cas idéal.
Application d'une modification identique sur 30 fichiers	✅ Parallèle (headless ou /batch)	Tâches répétitives indépendantes : idéal à déléguer par lot.
« Refactoriser le module A puis adapter le module B »	❌ Séquentiel	L'étape B dépend de la réussite de A ; paralléliser ferait travailler B sur une version obsolète de A.
Modification conjointe de package.json par deux sessions	❌ Séquentiel (ou isolation stricte par worktree)	Conflit sur le même fichier : c'est l'erreur du scénario de départ.
Petite édition rapide de cinq minutes	❌ Séquentiel	Le temps d'orchestration et de découpage dépasse le temps de traitement de la tâche.
Besoin d'échanger régulièrement des résultats intermédiaires	⚠️ À évaluer	Le coût de communication entre agents est trop élevé ; privilégiez une session unique séquentielle.

Voici three règles empiriques issues de retours d'expérience :

1. Ne parallélisez jamais des tâches présentant des dépendances logiques. Dans un cas comme « refactoriser un cœur de bibliothèque puis adapter les modules dépendants », la seconde étape doit attendre la validation de la première. Si vous tentez de les mener de front, l'agent travaillant sur la seconde étape basera ses modifications sur l'ancien code, rendant tout son travail inutile. Ce type d'erreur se traduit par un gaspillage de crédit de session.

2. Ne découpez pas les tâches mineures. Pour un correctif ne nécessitant que quelques minutes, le temps investi à planifier le découpage, initialiser les sessions et gérer la consolidation finale dépassera le temps d'exécution de la modification. Ordonner le travail a un coût ; le parallélisme sur des petites tâches est inefficace.

3. Le parallélisme accélère la consommation de crédit. Rappelons la règle de la section 04 : superviser dix sessions consomme votre forfait dix fois plus vite. Une bonne pratique consiste à limiter la parallélisation manuelle à three ou cinq sessions actives. Si le volume de tâches s'avère supérieur, recourez aux processus industrialisés comme /batch ou les workflows dynamiques plutôt que d'ouvrir manuellement un grand nombre de terminaux.

En somme, le parallélisme est une arme à double tranchant : extrêmement efficace dans les scénarios adaptés, il s'avère plus lent, plus coûteux et plus complexe que le traitement séquentiel s'il est appliqué à mauvais escient. Déterminer la pertinence de la parallélisation est une compétence clé.

💡 Résumé en une phrase : L'efficacité de la parallélisation repose sur la double condition « indépendance logiques + absence de conflits de fichiers » ; évitez de l'appliquer sur des tâches interdépendantes ou très courtes ; veillez à l'impact sur votre consommation de crédit en limitant les sessions simultanées à three ou cinq, et confiez les volumes importants à /batch.

---

07 Pratique : isoler par worktree et lancer des tâches en arrière-plan

Rien ne remplace la pratique. L'exercice suivant s'appuie entièrement sur un dépôt Git existant (si vous n'en avez pas sous la main, initialisez-en un rapidement pour le test). Les instructions sont directement applicables et accompagnées des résultats attendus afin de vous aider à acquérir les automatismes.

Prérequis : Un dépôt Git valide ; les commandes d'arrière-plan requièrent une version récente de Claude Code (l'agent view étant en Research Preview), vérifiez votre configuration avec claude --version. Les commandes ci-dessous ne nécessitent pas de proxy réseau particulier.

Étape 1 : Se positionner dans le dépôt Git et valider la confiance

cd 你的某个git项目
claude

Ouvrez la session, posez une question simple (par exemple : « Présente-moi ce projet ») puis quittez. Cette étape est requise pour accorder la confiance à l'espace de travail — sans quoi l'appel à --worktree à la prochaine étape renverrait une erreur.

Étape 2 : Démarrer une session isolée avec --worktree

claude --worktree test-parallel

Attendu : Claude initialise un worktree sous .claude/worktrees/test-parallel/ et y lance la session. Toute modification appliquée au sein de cette session cible uniquement cette copie, le répertoire principal restant intact. Si vous quittez la session après avoir modifié des fichiers, le système vous demandera s'il faut « conserver ou supprimer » le worktree — choisissez de le supprimer pour cet entraînement.

Étape 3 : Confirmer la création effective du worktree (ouvrez un autre terminal et placez-vous dans le répertoire principal)

git worktree list

Attendu : La liste affiche le répertoire principal ainsi qu'une ligne supplémentaire pointant vers .../.claude/worktrees/test-parallel associée à sa propre branche. La présence de cette ligne confirme le succès de l'isolation.

Étape 4 : Envoyer une tâche en arrière-plan

claude --bg "列出这个项目所有 markdown 文件的标题"

Attendu : Le terminal affiche backgrounded · <id_court> suivi des outils de contrôle claude attach, claude logs et claude stop. Cette réponse valide l'exécution en arrière-plan ; vous reprenez immédiatement la main sur votre console.

Étape 5 : Consulter le tableau de bord de supervision

claude agents

Attendu : La console de supervision de l'agent view s'affiche en plein écran, et la tâche lancée à l'étape précédente y figure sur une ligne avec son statut associé. Sélectionnez-la et appuyez sur Espace pour consulter l'aperçu de son avancement. Fermez le panneau avec Échap, puis quittez la console avec Échap. La présence de cette synthèse confirme que vous maîtrisez l'orchestration centralisée.

Étape 6 : Nettoyage de l'environnement

# 停掉刚才那个后台会话（短ID 换成第四步打印的）
claude stop <短ID>

# 删掉练手的 worktree（在主项目目录）
git worktree remove .claude/worktrees/test-parallel

Attendu : La commande claude stop affiche une confirmation d'arrêt ; exécuter git worktree list après l'appel à git worktree remove valide la disparition de la ligne test-parallel. La suppression propre de l'environnement confirme la maîtrise du cycle complet.

La validation de ces six étapes confirme votre maîtrise du cycle « isolation → vérification → exécution en tâche de fond → supervision → nettoyage ». Vos futures opérations en parallèle suivront ce même flux, il vous suffira d'adapter la nature des tâches et d'ouvrir les sessions requises.

💡 Résumé en une phrase : La mise en pratique s'articule en six étapes — valider la confiance avec claude → démarrer une session avec --worktree → vérifier avec git worktree list → envoyer en arrière-plan avec --bg → superviser avec claude agents → nettoyer avec stop et git worktree remove ; exécuter ce flux une fois s'avère plus formateur que d'apprendre les commandes par cœur.

---

08 Conclusion

Cet article a détaillé le concept de parallélisation d'instances de Claude, de l'identification des besoins aux contre-indications, en passant par les trois méthodes concrètes de configuration.

Récapitulons les points clés à retenir :

Objectif	Solution technique	Point clé
Comprendre l'intérêt	Critère de double condition : « indépendance + absence de conflit »	Multiplier les files d'attente tout en s'assurant que chaque file reste isolée et autonome.
Distinguer les approches	Quatre méthodes structurées	Le mécanisme de coordination définit l'approche ; agent view et workflows sont en Research Preview, agent teams est en phase expérimentale.
Éviter les conflits de fichiers	Option --worktree / Git native	Assurer une copie de travail dédiée pour chaque session ; veiller à la configuration de .gitignore, .worktreeinclude et au nettoyage de sortie.
Superviser en arrière-plan	Option --bg + claude agents	Sessions détachées du terminal actif avec worktree automatisé ; fonctions d'aperçu (Espace) et de reconnexion (Entrée).
Automatiser par script	Option claude -p (headless)	Associer --allowedTools pour accorder les permissions, --bare pour accélérer le démarrage et --output-format json pour structurer le retour.
Valider la pertinence	Double règle de parallélisation	Éviter le parallélisme sur des tâches interdépendantes ou très courtes ; surveiller la consommation en limitant les sessions actives à 3 ou 5.

Vous êtes désormais en mesure de : comprendre l'intérêt et les critères d'application de la parallélisation ; choisir l'approche la plus adaptée parmi les quatre méthodes officielles ; utiliser --worktree pour isoler vos sessions de travail et éviter les conflits d'écrasement ; lancer des tâches en arrière-plan avec --bg et les superviser depuis la console unique de claude agents ; automatiser des traitements par lots avec claude -p ; et surtout — analyser calmement la pertinence d'une parallélisation avant de découper une tâche de manière systématique.

L'erreur initiale consistant à lancer deux terminaux sur le même répertoire s'expliquait par un manque d'isolation et d'analyse des dépendances. En maîtrisant l'isolation par worktree et les critères de décision, vous vous épargnerez de nombreuses complications dans vos développements parallèles.

---

Lectures recommandées

• Comment poser des questions et donner des consignes : s'adresser efficacement à Claude
• Glossaire (accessible aux débutants) : traduire le jargon technique en termes simples
• GitHub Actions : mentionner Claude dans une PR pour le laisser travailler en autonomie