Si vous avez déjà ouvert une deuxième session de Claude Code sur le même dépôt pour retrouver ensuite un enchevêtrement de remisages et de fusions à moitié faites, le remède n'est pas une meilleure consigne : c'est un répertoire de travail distinct par session. Anthropic fournit l'option --worktree précisément pour cela (documentation officielle), et tous les grands concurrents ont adopté le même principe au premier semestre 2026. Nous travaillons ainsi chaque jour sur notre propre base de code éditoriale multilingue. Voici la séquence qui fonctionne, le problème d'environnement dont personne ne vous prévient, et la limite qu'aucun outil ne supprime.
Ce qui entre réellement en collision quand les agents travaillent en parallèle
Sous la formule « les agents se marchent dessus » se cachent trois conflits distincts, qui appellent chacun une réponse différente.
Les modifications de fichiers. Deux sessions qui modifient le même fichier dans le même répertoire produisent exactement le conflit de fusion dont la résolution dure plus longtemps que la tâche initiale (Developers Digest). Un changement de branche dans un terminal modifie au passage, sans prévenir, les fichiers d'une session qui tourne dans un autre.
L'environnement. Un second répertoire ne contient ni .env, ni dépendances installées, et bien souvent le même port codé en dur que le premier. L'agent se met alors à déboguer votre installation plutôt que votre ticket.
L'attention. Dix agents produisent dix diffs. C'est le conflit qu'aucune option ne résout, et c'est lui qui détermine combien d'agents vous devriez réellement lancer.
Étape 1 : donner à chaque session son propre répertoire de travail
Un git worktree est un répertoire autonome, avec ses fichiers et sa branche, qui partage l'historique et le dépôt distant de votre copie principale. Claude Code le crée et démarre la session directement à l'intérieur :
claude --worktree feature-auth
Par défaut, le répertoire est créé sous .claude/worktrees/feature-auth/ à la racine du dépôt, sur une nouvelle branche nommée worktree-feature-auth. Relancez la même commande avec un autre nom dans un second terminal et vous obtenez une deuxième session isolée. Si vous omettez le nom, un nom est généré, par exemple bright-running-fox (documentation officielle).
Gardez ces répertoires hors de l'état de votre copie principale :
echo ".claude/worktrees/" >> .gitignore
Les exécutions interactives supposent que vous ayez accordé votre confiance au répertoire. Si vous n'avez jamais lancé Claude Code à cet endroit, lancez-le une fois sans option pour accepter la boîte de dialogue, faute de quoi la commande s'interrompt sur une erreur. Les exécutions non interactives avec -p ignorent entièrement cette vérification.
Pour partir d'une demande de fusion plutôt que de votre branche par défaut, passez son numéro précédé de #, entre guillemets afin que l'interpréteur ne le prenne pas pour un commentaire :
claude --worktree "#1234"
Résultat attendu : git worktree list affiche une entrée par session active, chacune sur sa propre branche worktree-*, et aucune session ne voit les modifications d'une autre.
Étape 2 : emporter l'environnement dont le répertoire n'hérite pas
C'est l'étape qui échoue en premier, et elle échoue en silence. Un nouveau répertoire de travail est une copie neuve : les fichiers ignorés par Git ne suivent pas.
❌ Avant. Vous lancez claude --worktree feature-auth, l'agent exécute la suite de tests, et celle-ci échoue sur des variables d'environnement absentes. L'agent consacre ensuite sa fenêtre de contexte à diagnostiquer votre installation locale au lieu de traiter la tâche.
✅ Après. Ajoutez un fichier .worktreeinclude à la racine du projet. Il suit la syntaxe de .gitignore, et seuls sont copiés les fichiers qui correspondent à un motif et sont ignorés par Git, de sorte que les fichiers versionnés ne sont jamais dupliqués :
.env
.env.local
config/secrets.json
La même commande claude --worktree feature-auth démarre désormais avec un environnement fonctionnel, et cela vaut pour chaque répertoire que crée Claude Code (documentation officielle). Les dépendances restent à installer dans la nouvelle copie : faites-en la première consigne donnée à l'agent, ou exécutez vous-même le script d'installation du projet.
Un réglage par défaut mérite d'être modifié. Les nouveaux répertoires partent de la branche par défaut du dépôt distant, ce qui convient la plupart du temps. Lorsque vous répartissez des agents sur un travail qui n'existe qu'en local, partez plutôt de votre HEAD courant :
{
"worktree": {
"baseRef": "head"
}
}
Défaillance à surveiller : si vous conservez le réglage par défaut, un répertoire censé partir d'une branche non poussée démarre silencieusement de main, et l'agent semble perdre un travail qui n'a jamais disparu.
Étape 3 : choisir le mode de coordination adapté au travail
L'isolation n'est pas de l'orchestration. Anthropic documente quatre manières distinctes de faire travailler Claude Code en parallèle, et se tromper de mode est une erreur fréquente et coûteuse (documentation officielle) :
| Mode | Ce qu'il apporte | Quand l'utiliser |
|---|---|---|
| Auxiliaires délégués | Les tâches annexes s'exécutent dans leur propre contexte au sein d'une session et renvoient une synthèse | Une recherche ou un journal volumineux noierait votre conversation principale |
Vue des agents (claude agents) | Un écran unique pour lancer et surveiller des sessions en arrière-plan | Vous avez des tâches indépendantes et souhaitez revenir plus tard |
| Équipes d'agents | Sessions coordonnées avec liste de tâches partagée et messagerie directe, pilotées par une instance responsable | Vous voulez que le travail soit découpé, attribué et tenu synchronisé pour vous |
| Flux dynamiques | Un script qui lance de nombreux auxiliaires et confronte leurs résultats | Un audit de toute la base de code ou une migration de plusieurs centaines de fichiers |
C'est là que se situe le piège. La vue des agents déplace automatiquement chaque session lancée dans son propre répertoire ; les équipes d'agents ne le font pas. Activez les équipes en sautant la répartition des fichiers et vous réintroduisez exactement le conflit que l'étape 1 avait supprimé.
Dès que plusieurs sessions tournent sans surveillance, il vous faut un endroit où leur état devient visible : c'est précisément l'argument que nous avons développé en faveur d'un poste de pilotage pour les agents.
Pour vos définitions d'agents dans .claude/agents/, rendez l'isolation permanente avec une seule ligne d'en-tête :
---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---
Apply the requested refactor across every affected file, then run the tests
and report the results.
Étape 4 : mettre en bac à sable les sessions que vous cessez de surveiller
Les répertoires de travail isolent les fichiers à l'intérieur de votre dépôt. Ils n'isolent rien d'autre sur votre machine, et Claude Code ne prétend pas le contraire. Cela devient déterminant dès que des agents s'exécutent sans demande d'autorisation.
Les bacs à sable de Docker donnent à chaque agent un environnement jetable :
sbx run claude ~/my-project
La commande de démarrage par défaut dans un bac à sable est claude --dangerously-skip-permissions, ce qui se défend justement parce que les dégâts possibles restent circonscrits à un conteneur et n'atteignent pas votre poste (documentation Docker). Le mode clone va plus loin : l'agent travaille dans un clone Git privé, à l'intérieur du bac à sable, tandis que votre dépôt hôte n'est monté qu'en lecture seule.
sbx run --clone claude
Deux contraintes documentées vous attendent (guide d'utilisation Docker) :
- Le mode clone se fixe à la création. Convertir un bac à sable existant revient à le supprimer puis à le recréer.
- Le mode clone est refusé depuis tout répertoire de travail autre que le principal, car le montage en lecture seule ne parvient pas à résoudre le fichier
.gitde ce répertoire. Lancez-le donc depuis votre copie principale.
Les bacs à sable n'héritent pas non plus de la configuration au niveau utilisateur située dans ~/.claude : seule la configuration du répertoire de projet y est visible. Les agents qui dépendent de vos réglages personnels s'y comportent différemment, et le découvrir en pleine tâche est plus pénible que de le savoir d'emblée.
Étape 5 : fixer la limite de simultanéité d'après votre capacité de relecture
Tous les éditeurs proposent désormais le même mécanisme d'isolation. Cursor 3.0 a retiré Composer au profit d'une fenêtre d'agents qui les répartit sur des répertoires isolés et des connexions SSH (Level Up Coding). L'application de bureau GitHub Copilot, présentée à la conférence Microsoft Build le 2 juin 2026, attribue à chaque session parallèle son propre répertoire (Digital Applied), et GitHub a rendu les sessions parallèles généralement disponibles dans VS Code le 9 juillet 2026 (TechTimes). Les orchestrateurs de bureau ont convergé vers le même modèle : un agent par répertoire, assorti d'un diff à valider (Parallel Code). Les tutoriels issus du terrain présentent désormais le travail séquentiel comme une contrainte de l'outil et non de la tâche (les répertoires de travail expliqués).
Quand tous les outils résolvent l'isolation de la même façon, celle-ci cesse d'être un facteur de différenciation. Ce qui reste, c'est votre propre débit de relecture.
Nous nous limitons à quatre sessions simultanées par dépôt, car au-delà le temps consacré à relire et fusionner leurs résultats coûte davantage que ce que la parallélisation fait gagner. Ce n'est pas Git qui bloque le dixième agent. Ce qui le bloque, c'est que dix diffs arrivant ensemble sont moins bien relus que trois qui se présentent l'un après l'autre, et qu'un diff d'agent mal relu revient plus cher qu'une tâche jamais entreprise.
C'est la logique de coût que nous avions appliquée à la facturation des modèles au token : le tarif affiché détermine rarement le montant final.
C'est aussi la raison pour laquelle nous plaidons pour le choix de l'agent le plus sobre lorsque la tâche ne réclame pas l'outil le plus fourni.
Voici comment déterminer votre propre chiffre : lancez trois agents pendant une semaine et mesurez le temps d'attente de chaque diff avant qu'un humain ne l'ouvre. Si cette attente s'allonge, vous n'ajoutez pas de la capacité mais de la file d'attente. Plusieurs sessions simultanées multiplient par ailleurs la consommation de jetons, si bien que la courbe des coûts monte avant celle de la valeur.
Fixez la limite en conscience, isolez proprement en dessous, et les agents parallèles deviennent un véritable levier. Faites du nombre d'agents un objectif et vous aurez construit une file d'attente assortie de travail supplémentaire. Pour une entrée en matière plus terre à terre, commencez par notre introduction honnête destinée aux non-développeurs ; et si vous souhaitez que ce dispositif soit conçu pour votre base de code plutôt que pour une démonstration, notre équipe d'ingénierie réalise exactement ce travail.
Questions fréquentes
Les répertoires de travail sont-ils utiles dès deux agents ? Oui, dès lors que les deux modifient des fichiers. Deux sessions de Claude Code dans une même copie entrent en collision lors des changements de branche et des remisages, quel qu'en soit le nombre (Developers Digest). Le coût se résume à une option : aucun seuil ne justifie d'attendre.
Que devient le répertoire de travail à la fin d'une session ?
En sortie, Claude Code vérifie la présence de fichiers modifiés, de fichiers non suivis et de nouveaux commits. Les sessions propres et sans nom sont supprimées automatiquement ; si le répertoire contient du travail, une question vous est posée. Les exécutions non interactives avec -p ne nettoient jamais : supprimez-les avec git worktree remove (documentation officielle).
Les équipes d'agents remplacent-elles les répertoires de travail ? Non. Les équipes coordonnent le travail, les répertoires isolent les fichiers. Les équipes sont expérimentales, désactivées par défaut, et n'isolent explicitement pas leurs membres, ce qui impose de répartir manuellement la responsabilité des fichiers (documentation officielle).
Un bac à sable est-il nécessaire ou un répertoire suffit-il ? Un répertoire n'isole que les fichiers du dépôt. Si les agents s'exécutent sans demande d'autorisation, utilisez un bac à sable afin que les dégâts possibles restent circonscrits à un conteneur (documentation Docker). Pour des sessions surveillées sur un dépôt de confiance, le répertoire suffit.
Combien d'agents en parallèle est-ce trop ? La limite tient au débit de relecture, non à l'outillage. Si les diffs attendent chaque semaine plus longtemps avant qu'un humain ne les ouvre, vous avez dépassé votre plafond. Nous en utilisons quatre par dépôt et mesurons l'attente plutôt que le nombre d'agents.
Sources
- Sessions parallèles avec les répertoires de travail — documentation de Claude Code — Anthropic, mise à jour du 17/07/2026
- Faire travailler des agents en parallèle — Anthropic, mise à jour du 18/07/2026
- Claude Code dans les bacs à sable Docker — Docker, mise à jour du 15/07/2026
- Bacs à sable Docker : utilisation et mode clone — Docker, mise à jour du 15/07/2026
- GitHub referme la boucle agentique dans VS Code — TechTimes, 09/07/2026
- Parallel Code face à Conductor — Parallel Code, 15/06/2026
- Les répertoires de travail Git expliqués pour les agents parallèles — bri, 14/06/2026
- Le guide pratique 2026 des agents en parallèle — Developers Digest, 10/06/2026
- L'application de bureau GitHub Copilot — Digital Applied, 06/06/2026
- Panorama quotidien de l'IA du 22 mai 2026 — Level Up Coding, 22/05/2026