Comment je fais tourner plusieurs agents Claude Code en parallèle

Comment je fais tourner plusieurs agents Claude Code en parallèle

Trois agents. Un seul repo. Zéro conflit.

Cette phrase m'aurait paru absurde il y a six mois. J'utilisais Claude Code sur des projets perso depuis un moment, et à chaque fois que je voulais lancer un deuxième agent pour gérer une fonctionnalité différente, je me heurtais au même mur — conflits Git, répertoires de travail sales, agents qui écrasaient mutuellement leurs modifications. Le contournement était pénible : stash, changer de branche, prier pour que rien ne casse, recommencer.

Puis Anthropic a livré le support natif des work trees Git dans Claude Code. Et honnêtement ? Ça a fondamentalement changé ma façon de développer avec des agents IA.

Je n'exagère pas. Cette seule fonctionnalité a transformé mon workflow de « un agent qui fait les choses séquentiellement » à « trois agents qui bossent sur trois fonctionnalités différentes simultanément, chacun dans son propre bac à sable isolé, et qui mergent proprement quand ils ont fini. » Le gain de productivité a été immédiat et viscéral — je l'ai ressenti dès le premier jour.

Mais voici ce que personne ne te dit sur les work trees dans Claude Code : le comportement par défaut a un piège subtil qui peut envoyer tes commits directement sur main alors que tu penses les envoyer sur une branche de fonctionnalité. J'ai découvert ça à 1h du matin un mardi. Laisse-moi t'épargner ce même moment de panique.

Pourquoi ton workflow mono-agent te freine

Voici un scénario qui te parle sûrement. Tu développes une fonctionnalité — disons, ajouter l'authentification à une API. Tu as Claude Code qui travaille sur le middleware d'auth. À mi-chemin, tu te rends compte que tu dois aussi mettre à jour le schéma de base de données. Et tant qu'à faire, il y a un bug côté frontend qu'un utilisateur a signalé ce matin.

Qu'est-ce que tu fais ? Tu attends. Tu finis d'abord le middleware d'auth, tu le commites, puis tu passes au schéma, puis au correctif. Tout se fait en séquence parce que Git ne te permet d'avoir qu'une seule branche checkoutée à la fois dans un même répertoire de travail.

J'ai passé des mois à travailler comme ça. Ça me semblait normal parce que c'est comme ça que chaque développeur travaille depuis l'invention de Git. Un répertoire, une branche, une chose à la fois.

Le coût de cette approche séquentielle est brutal quand tu travailles avec des agents IA. Claude Code peut générer et itérer sur du code dramatiquement plus vite que je ne peux le taper — mais seulement si je le laisse faire. Quand je crée un goulot d'étranglement dans tout le pipeline en forçant tout à passer par une seule branche, c'est essentiellement comme acheter une voiture de sport et la conduire en première.

Les work trees Git résolvent ça au niveau de l'infrastructure. Et l'intégration native de Claude Code rend ça quasi sans effort. Mais avant de te montrer la mise en place, tu dois comprendre ce que sont réellement les work trees — parce que le modèle mental compte plus que les commandes.

Git Work Trees — La fonctionnalité que tu as ignorée

J'utilisais Git depuis plus de dix ans avant d'utiliser sérieusement les work trees. Honnêtement, je savais qu'ils existaient, mais ils me semblaient être une de ces fonctionnalités obscures de Git dont seuls les développeurs du kernel se souciaient. J'avais tort.

Un work tree Git est un répertoire de travail séparé lié au même dépôt. Pense à ça comme suit : ton repo normal est ton atelier principal. Un work tree, c'est un deuxième atelier de l'autre côté du couloir qui partage la même boîte à outils (ton historique Git, tes remotes, ta config) mais qui a son propre établi où tu peux étaler un projet complètement différent.

Chaque work tree a sa propre branche checkoutée. Tu peux avoir main dans ton répertoire principal, feature/auth dans un work tree, et fix/login-bug dans un autre — tout ça en même temps. Les modifications dans l'un n'affectent pas les autres. Les commits dans l'un n'apparaissent pas dans les autres tant que tu ne merges pas.

L'insight clé qui a fait tilt pour moi : les work trees ne sont pas des copies de ton repo. Ce sont des vues supplémentaires sur le même repo. Ton répertoire .git reste au même endroit. Les work trees ne font que le référencer. Ça veut dire qu'ils sont légers à créer et à supprimer.

Voici la commande Git brute :

git worktree add ../my-feature-branch feature/my-feature

Ça crée un nouveau répertoire ../my-feature-branch avec la branche feature/my-feature checkoutée. Tu peux faire cd dedans, apporter des modifications, commiter, pusher — tout ça indépendamment de ton répertoire de travail principal.

Et quand tu as fini :

git worktree remove ../my-feature-branch

Propre. Pas de fichiers résiduels. Pas de branches orphelines sauf si tu le veux.

C'est la base. Maintenant, voici comment Claude Code prend ce concept et le transforme en quelque chose de véritablement puissant.

L'intégration Work Tree de Claude Code — Ce que ça fait concrètement

Quand Anthropic a ajouté le support natif des work trees à Claude Code, ils n'ont pas simplement wrappé les commandes Git. Ils ont construit un système de gestion du cycle de vie autour. Et la différence compte.

Voici ce qui se passe quand tu dis à Claude Code d'utiliser un work tree. Tu peux le déclencher via le CLI ou en configurant un agent pour utiliser le mode isolation. La commande ressemble à ça :

claude --worktree

Ou au sein d'une session, tu peux entrer dans un work tree avec la commande /worktree. Claude Code fait plusieurs choses automatiquement :

1. Crée un nouveau répertoire sous .claude/worktrees/ à la racine de ton projet
2. Génère un nom de branche — souvent quelque chose de fantaisiste et auto-généré (j'ai vu des noms comme claude/witty-fox et claude/brave-eagle)
3. Checkout cette branche basée sur ton HEAD actuel
4. Déplace le contexte de travail de l'agent entièrement dans ce work tree

À partir de ce moment, tout ce que l'agent fait — lectures de fichiers, écritures, opérations Git — se passe dans le work tree. Ton répertoire de travail principal reste intact.

C'est là que ça devient intéressant pour les workflows multi-agents. Chaque agent ou sous-agent peut avoir son propre work tree. L'Agent A implémente un nouvel endpoint d'API dans claude/worktrees/endpoint-feature. L'Agent B écrit des tests dans claude/worktrees/test-suite. L'Agent C corrige un bug CSS dans claude/worktrees/ui-fixes. Les trois tournent simultanément, les trois sont isolés, et aucun d'entre eux ne peut piétiner le travail des autres.

Quand chaque agent a terminé, tu as des branches propres prêtes pour des pull requests.

Je veux être précis sur l'expérience VS Code ici parce qu'elle est vraiment bien faite. Quand tu as plusieurs work trees actifs, le panneau Source Control de VS Code affiche chacun comme un dépôt séparé. Tu peux voir le diff, les modifications staged, et le statut de branche pour chaque work tree indépendamment. C'est comme avoir plusieurs repos ouverts, sauf qu'ils partagent tous le même historique Git.

Cela dit, il y a une subtilité dont je dois te prévenir — et c'est le piège que j'ai mentionné au début.

Le piège du push de branche qui a failli me coûter une journée de travail

Voici ce qui s'est passé. J'ai créé un work tree via Claude Code, fait un paquet de modifications, commité, et pushé. Tout avait l'air bien. Le push a réussi. Je suis passé à la tâche suivante.

Trente minutes plus tard, j'ai vérifié GitHub et j'ai trouvé mes commits de work tree sur main.

Pas sur une branche de fonctionnalité. Sur main. En production.

Le problème est subtil. Quand Claude Code crée un work tree, il crée une nouvelle branche locale basée sur HEAD. Mais quand tu pushes, le comportement par défaut de Git dépend de ta configuration push.default. Si c'est réglé sur simple ou current (qui sont des valeurs par défaut courantes), et que ta nouvelle branche n'a pas encore de branche de tracking upstream, Git pourrait pusher vers main — la branche sur laquelle ton HEAD était basé.

Le correctif est simple, mais il faut le connaître :

git push -u origin claude/your-branch-name

Ce flag -u définit la branche de tracking upstream. Après ce premier push avec -u, les commandes git push suivantes iront au bon endroit.

Astuce pro : tu peux aussi configurer ça globalement pour que Git pousse toujours vers une branche du même nom :

git config --global push.autoSetupRemote true

Avec cette config, chaque nouvelle branche tracke automatiquement une branche remote du même nom. Plus de push accidentels sur main.

Claude Code a commencé à ajouter des garde-fous autour de ça — des prompts et des hooks qui te préviennent quand tu es sur le point de pusher vers une branche qui pourrait ne pas être celle que tu voulais. Mais je te recommande quand même la config globale comme filet de sécurité.

J'ai appris ça à la dure pour que tu n'aies pas à le faire. Si tu ne retiens qu'une seule chose de cet article, que ce soit ça : définis toujours ton upstream avant de pusher depuis un work tree.

Maintenant que nous avons couvert le piège, laisse-moi te guider à travers le workflow complet que j'utilise au quotidien.

Mon workflow complet d'agents parallèles — Étape par étape

Voici le workflow que j'ai adopté après des semaines d'itération. Ce n'est pas la seule façon d'utiliser les work trees avec Claude Code, mais c'est celle qui a été la plus fiable pour moi.

Étape 1 : Planifier le travail parallèle

Avant de lancer plusieurs agents, je passe cinq minutes à identifier les tâches indépendantes. Le mot clé est indépendantes. Si la Tâche B dépend du résultat de la Tâche A, elles ne peuvent pas vraiment tourner en parallèle — tu vas te heurter à des conflits de merge ou des problèmes de dépendances.

Bons candidats pour la parallélisation :

• Développement de fonctionnalité + corrections de bugs (zones différentes du codebase)
• Modifications backend + modifications frontend
• Implémentation + écriture de tests
• Mises à jour de documentation + refactoring de code

Mauvais candidats :

• Deux fonctionnalités qui modifient les mêmes fichiers
• Une migration de base de données et du code qui dépend du nouveau schéma
• Tout ce où le résultat d'une tâche est l'entrée d'une autre

Étape 2 : Créer des work trees pour chaque agent

En général, je pars de ma branche main avec un répertoire de travail propre :

# Verify clean state
git status

# Create work trees for each task
git worktree add .claude/worktrees/feature-auth -b feature/auth
git worktree add .claude/worktrees/fix-login -b fix/login-bug
git worktree add .claude/worktrees/update-tests -b update/test-coverage

Alternativement, je laisse Claude Code les créer. En utilisant l'outil Task avec isolation: "worktree", chaque sous-agent obtient automatiquement son propre work tree :

Use the Task tool with isolation: "worktree" to assign independent work to sub-agents

Chaque sous-agent reçoit une copie fraîche du repo avec sa propre branche, fait son travail, et renvoie les résultats. Le work tree est automatiquement nettoyé s'il n'y a pas eu de modifications, ou préservé avec le nom de branche si des modifications existent.

Étape 3 : Lancer les agents en parallèle

C'est là que la magie opère. Je lance plusieurs sessions Claude Code ou sous-agents, chacun pointant vers un work tree différent.

En pratique, j'ai trouvé que trois agents en parallèle est le point idéal pour mes projets. Au-delà, je commence à perdre ma capacité à évaluer efficacement la qualité du résultat. Ton expérience peut varier selon la complexité de chaque tâche.

Chaque agent travaille de manière complètement indépendante. Ils peuvent lire des fichiers, écrire des fichiers, lancer des tests, faire des commits — le tout sans savoir que les autres agents existent.

Étape 4 : Vérifier et pusher chaque branche

Une fois que les agents ont fini, je vérifie les modifications de chaque work tree :

# Check what happened in each work tree
cd .claude/worktrees/feature-auth
git log --oneline -5
git diff HEAD~1

# Set upstream and push
git push -u origin feature/auth

Je répète ça pour chaque work tree. L'étape de vérification est cruciale — je ne fais pas confiance aveuglément au résultat des agents, surtout quand j'en fais tourner plusieurs. Un scan rapide du diff attrape la plupart des problèmes.

Étape 5 : Créer des pull requests

Depuis chaque work tree (ou depuis le GitHub CLI n'importe où) :

gh pr create --title "Add authentication middleware" --body "Implemented JWT auth..."

Maintenant j'ai trois PR séparées, chacune avec des modifications ciblées, des diffs propres, et aucune contamination croisée.

Étape 6 : Merger et nettoyer

Une fois les PR vérifiées et mergées :

# Back in main directory
git checkout main
git pull

# Remove work trees
git worktree remove .claude/worktrees/feature-auth
git worktree remove .claude/worktrees/fix-login
git worktree remove .claude/worktrees/update-tests

Table rase. Prêt pour le prochain lot.

Si tu as suivi jusqu'ici, tu as déjà un workflow de développement parallèle fonctionnel avec Claude Code. La plupart des tutoriels s'arrêtent là. Mais la vraie puissance apparaît quand tu commences à combiner les work trees avec les sous-agents et l'orchestration hiérarchique des tâches.

Sous-agents avec work trees — Parallélisation hiérarchique

C'est la partie qui m'a véritablement enthousiasmé quand je l'ai comprise pour la première fois.

Claude Code supporte les sous-agents — des agents plus petits et ciblés qu'un agent principal peut lancer pour gérer des tâches spécifiques. Quand tu combines les sous-agents avec l'isolation par work tree, tu obtiens quelque chose de remarquable : un agent principal qui agit comme un chef de projet, déléguant les tâches indépendantes à des sous-agents, chacun travaillant dans son propre environnement isolé.

Voici le modèle mental. Ton agent principal lit la liste des tâches, identifie trois éléments de travail indépendants, et lance trois sous-agents avec isolation: "worktree". Chaque sous-agent :

1. Obtient son propre work tree (créé automatiquement)
2. Travaille sur sa tâche assignée
3. Commite ses modifications
4. Fait un rapport à l'agent principal
5. Voit son work tree préservé avec le nom de branche

L'agent principal passe ensuite en revue les résultats, décide si quelque chose a besoin d'être révisé, et peut même créer des PR de manière programmatique.

J'ai utilisé ce pattern la semaine dernière pour refactorer une API. L'agent principal a analysé le codebase, identifié quatre modules indépendants nécessitant une mise à jour, et a lancé quatre sous-agents. Chaque sous-agent a refactoré son module, écrit les tests, et commité les modifications. L'ensemble du refactoring qui m'aurait pris une journée complète a été fait en environ 40 minutes.

Le détail crucial : les tâches doivent être véritablement indépendantes. Des modifications de fichiers qui se chevauchent entre sous-agents créeront des conflits de merge quand tu essaieras d'intégrer le tout. Planifie soigneusement ta décomposition de tâches.

Il y a encore un pattern que je veux partager — utiliser les work trees pour l'expérimentation.

Les work trees comme bacs à sable jetables

Tous les work trees n'ont pas besoin de devenir une PR. Certaines de mes utilisations les plus productives des work trees sont purement expérimentales.

Je lance un work tree, demande à Claude Code d'essayer une approche complètement différente d'un problème, et j'évalue le résultat. Si ça marche — super, j'ai une branche prête. Si ça ne marche pas — je supprime le work tree et je passe à autre chose. Zéro risque pour mon codebase principal.

Ce pattern de « bac à sable jetable » a changé ma façon de prendre des décisions d'architecture. Au lieu de me torturer pour savoir si l'approche A ou l'approche B est meilleure, j'implémente les deux dans des work trees séparés et je les compare directement. Du vrai code, de vrais tests, de vraies données — pas des débats théoriques sur un tableau blanc.

Le mois dernier, j'hésitais entre deux approches de gestion d'état pour un projet React. J'ai créé deux work trees, implémenté chaque approche, lancé la même suite de tests sur les deux, et comparé les tailles de bundle et les métriques de performance. La décision qui aurait pris une journée de délibération a pris une heure d'expérimentation parallèle.

C'est le changement de mentalité que les work trees permettent. Le code devient peu coûteux à essayer. Les expériences deviennent bon marché. Et les mauvaises idées sont tuées par les preuves, pas par les opinions.

Les vrais compromis dont personne ne parle

Je te rendrais un mauvais service si je présentais les work trees comme purement magiques. Il y a de vraies limitations et des aspérités.

L'espace disque s'accumule. Chaque work tree est un checkout complet des fichiers de ton projet (mais pas un clone complet — il partage le répertoire .git). Pour les gros monorepos, trois ou quatre work trees peuvent consommer un espace disque significatif. J'ai appris à nettoyer agressivement après les merges.

La charge mentale augmente. Suivre ce qui se passe à travers trois agents parallèles demande de la discipline. Je garde un simple fichier texte qui note quel work tree fait quoi, ou je m'appuie sur la gestion des tâches de Claude Code pour suivre la progression. Sans ça, j'ai perdu la trace de quelle branche contenait quelles modifications.

Tout ne se parallélise pas bien. Je l'ai mentionné plus tôt, mais ça vaut la peine de le répéter. Si tes tâches ont des dépendances — si la Tâche B a besoin du résultat de la Tâche A — tu ne peux pas simplement les jeter dans des work trees séparés en espérant que tout ira bien. Tu vas te retrouver avec des conflits de merge ou du code cassé.

Les work trees ne sont pas automatiques. Tu dois explicitement choisir de les utiliser. Claude Code ne créera pas de work trees de lui-même sauf si tu le configures pour. C'est en fait une bonne décision de conception — la parallélisation implicite pourrait causer le chaos — mais ça veut dire que tu dois réfléchir à quand les utiliser.

Le nommage des branches peut prêter à confusion. Les noms de branche auto-générés par Claude Code sont créatifs (j'ai vu des choses comme claude/dazzling-penguin) mais pas toujours descriptifs. J'ai commencé à fournir des noms de branche explicites au lieu de me fier aux noms auto-générés. Le toi du futur remerciera le toi du présent en lisant git log.

Ce ne sont pas des points bloquants. Ce sont juste des choses que tu dois savoir avant de te lancer à fond dans les work trees parallèles. Les gains de productivité surpassent largement ces points de friction — mais seulement si tu les gères intentionnellement.

Ce que j'ai mesuré après un mois de work trees parallèles

J'ai suivi ma production pendant un mois pour voir si les work trees tenaient vraiment leurs promesses. Voici les chiffres bruts.

Avant les work trees (workflow séquentiel) :

• Fonctionnalités complétées en moyenne par jour : 1-2
• Temps moyen du début de la tâche à la PR : 3-4 heures
• Changements de contexte qui ont cassé ma concentration : 5-6 par jour
• Approches expérimentales abandonnées : 1 par semaine (trop coûteuses à essayer)

Après les work trees (workflow parallèle) :

• Fonctionnalités complétées en moyenne par jour : 3-4
• Temps moyen du début de la tâche à la PR : 1,5-2 heures
• Changements de contexte qui ont cassé ma concentration : 1-2 par jour
• Approches expérimentales essayées : 3-4 par semaine (peu coûteuses à explorer)

Le plus gros gain n'était pas la vitesse brute — c'était la réduction des changements de contexte. Quand chaque agent a son propre work tree, je n'ai plus besoin de suivre mentalement « dans quel état est mon répertoire de travail ? » Cette question disparaît tout simplement.

Le nombre d'approches expérimentales a été la métrique surprise. Parce qu'essayer des choses est devenu peu coûteux, j'ai commencé à essayer plus de choses. Et certaines de ces expériences ont mené à des solutions significativement meilleures que ce que mon premier instinct aurait produit.

Gains rapides que j'ai remarqués dès la première semaine : corrections de bugs plus rapides (lancer un work tree, corriger, pusher, PR — fait en minutes), des diffs de PR plus propres (chaque PR ne contient que les modifications d'une seule tâche), et moins de moments « oups, j'ai commité ça sur la mauvaise branche ».

Sur le long terme, je m'attends à ce que l'effet cumulé soit substantiel. Meilleure qualité de code grâce à plus d'expérimentation, livraisons plus rapides grâce à la parallélisation, et un historique Git plus propre grâce aux branches isolées.

L'avenir du développement parallèle assisté par IA

Je suis sincèrement convaincu que la parallélisation basée sur les work trees va devenir un workflow fondamental pour le développement assisté par IA. Pas seulement pour Claude Code — pour n'importe quel outil de codage IA.

Le pattern est naturel. Les agents IA fonctionnent mieux quand on leur donne des tâches ciblées et bien délimitées. Les work trees fournissent l'isolation dont ces agents ont besoin. La combinaison est presque évidente rétrospectivement.

Ce que je surveille pour la suite : une intégration IDE plus poussée (imagine VS Code affichant la progression en temps réel de chaque agent work tree dans un tableau de bord), une décomposition de tâches plus intelligente (l'agent principal identifiant automatiquement quelles tâches peuvent tourner en parallèle), et une détection automatique des conflits (te prévenant avant que deux agents ne commencent à modifier les mêmes fichiers).

Certaines de ces choses existent déjà sous une forme basique. D'autres arrivent. Toutes semblent inévitables.

Voici mon défi pour toi : la prochaine fois que tu t'assois pour travailler sur un projet avec Claude Code, identifie deux tâches complètement indépendantes l'une de l'autre. Crée deux work trees. Lance les deux simultanément. Chronomètre le résultat.

Cette première expérience — regarder deux fonctionnalités se matérialiser en parallèle pendant que tu sirotes ton café — c'est le moment où le workflow fait tilt. Et une fois que ça fait tilt, tu ne reviendras plus en arrière.

Let's Work Together

Tu cherches à construire des systèmes IA, automatiser des workflows, ou faire évoluer ton infrastructure tech ? Je serais ravi de t'aider.

• Fiverr (builds personnalisés & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io