Paralléliser Claude Code

Un agent qui code, c’est un multiplicateur ; plusieurs en même temps, c’est une équipe. Exécuter plusieurs instances de Claude Code en parallèle est l’un des gains de productivité les plus importants qu’offre l’outil : assignez à chacune une tâche différente et laissez-les travailler simultanément — une fonctionnalité par-ci, un refactoring par-là, des tests ailleurs. Votre rôle change de nature : moins de frappe, plus d’orchestration et de revue.

Le défi : les conflits de fichiers

L’obstacle saute aux yeux dès la deuxième instance : quand deux instances tentent de modifier le même fichier simultanément, elles peuvent écrire du code conflictuel — chacune ignorant ce que fait l’autre, aucune ne travaillant sur une base stable. La solution est un principe d’isolation : donner à chaque instance son propre espace de travail. Chaque agent travaille sur sa copie du projet, en aveugle des autres, et les travaux se réunissent seulement à la fin, par un mécanisme de fusion contrôlé.

Git worktrees

Ce mécanisme existe déjà dans votre outillage : les git worktrees créent des copies complètes de votre projet dans des répertoires séparés, chacune liée à sa propre branche :

Projet principal (main)
├── .trees/
│   ├── feature-a/    ← Branche feature-a, instance Claude #1
│   └── feature-b/    ← Branche feature-b, instance Claude #2

Chaque dossier contient une copie intégrale de la codebase — pas un simple checkout partagé — si bien que deux instances Claude Code lancées dans .trees/feature-a/ et .trees/feature-b/ ne peuvent physiquement pas se marcher dessus. Et comme chaque worktree est une branche Git ordinaire, la réunification finale passe par l’outillage que votre équipe pratique déjà : commit, merge, résolution de conflits.

Commandes slash personnalisées

Créer un worktree, y lier les dépendances, ouvrir l’éditeur : le rituel se répète à chaque nouvelle tâche — donc il s’automatise. Créez des fichiers .md dans .claude/commands/ pour en faire des commandes slash :

/project:create_worktree feature_b
/project:merge_worktree feature_b

Le contenu du fichier .md est le prompt complet de l’opération, et $ARGUMENTS sert de placeholder pour les valeurs dynamiques — le nom de la branche, ici. C’est l’ingénierie de prompt appliquée à votre propre outillage : le prompt d’orchestration est écrit une fois, soigné une fois, puis rejoué en une ligne. Détail qui épargne une surprise : la commande de création gagne à lier symboliquement les dépendances non suivies par Git (comme node_modules), absentes de tout worktree neuf.

Flux de développement parallèle

Le cycle complet, une fois les commandes en place :

1. Créer plusieurs worktrees
2. Lancer Claude Code dans chaque espace
3. Assigner différentes tâches
4. Travailler en parallèle
5. Commiter quand chaque tâche est terminée
6. Fusionner dans main

Les étapes 1 et 6 tiennent chacune en une commande slash ; les étapes 2 à 5 sont du travail d’agent que vous supervisez. Et pour l’étape 6, Claude peut même gérer les conflits de fusion intelligemment : il lit les deux versions, comprend l’intention de chacune et propose la réconciliation — l’étape que tout développeur redoute devient une tâche déléguée de plus.

La limite de cette approche n’est plus la vitesse d’écriture du code : c’est votre capacité à définir des tâches nettes et à relire les résultats. Les agents produisent en parallèle ; vous restez le point de convergence qui découpe, arbitre et valide.

Points clés à retenir

• Plusieurs Claude Code en parallèle = une équipe ; votre rôle glisse vers l’orchestration et la revue
• Un espace de travail isolé par instance — les git worktrees fournissent exactement cela
• Chaque worktree est une branche : la réunification passe par le merge Git classique
• .claude/commands/ + $ARGUMENTS : le rituel de création/fusion tient en une commande slash
• La nouvelle limite d’échelle : la clarté de vos découpages de tâches et votre capacité de revue