Claude Code Parallel Sessions : faire tourner plusieurs agents avec des git worktrees

Hier j'ai mergé 17 PRs, fermé 22 issues, et j'en ai encore 7 en pending. Notre sprint se termine ce soir. Je n'ai pas écrit la plupart du code. J'ai fait tourner des Claude Code parallel sessions sur trois terminaux, j'ai reviewé ce que les agents produisaient, et mergé ce qui était prêt.

Ce n'est pas théorique. Je vais détailler exactement ce que j'ai fait, à quoi ressemble le setup, et pourquoi la partie la plus dure n'a rien à voir avec git.

Le setup : les issues comme carburant

Avant de pouvoir faire tourner des agents en parallèle, il te faut un backlog de tasks bien scopées. Pour nous, ce sont des GitHub Issues dans un board GitHub Project.

N'importe qui dans la team peut filer une issue. On a un flow où Claude sait créer des GitHub issues faciles à reprendre plus tard : titre clair, steps de reproduction pour les bugs, critères d'acceptation pour les features. Il y a une commande de triage qui les classifie par priorité (P0, P1, P2) et par taille. Au moment où je m'installe pour bosser, le board du sprint a déjà tout trié.

Hier, je voulais cleaner toutes les issues P0 du sprint en cours. Certaines étaient des petits bugs. D'autres des features plus grosses. Chacune avait déjà assez de context dans l'issue pour qu'un agent bosse dessus indépendamment.

Cette dernière phrase, c'est tout le jeu. Si tes issues ne sont pas assez bien spec'd pour qu'un agent les prenne à froid, les sessions parallèles ne te sauveront pas. Tu passeras plus de temps à expliquer du context que tu n'en économises à l'implémentation.

Trois terminaux, trois rôles

J'utilise CMUX pour gérer plusieurs sessions Claude Code côte à côte. Voilà à quoi ressemblait hier :

Terminal 1 : Une session Claude Code dans son propre git worktree, dédiée à une seule GitHub issue. Je dis à Claude de créer un worktree et une branch pour l'issue #47 (ou quel que soit le numéro). Il check out une copie propre du repo, crée une branch comme fix/47-broken-validation, et commence à bosser. Totalement isolé du reste.

Terminal 2 : Pareil, issue différente. Un autre worktree, une autre branch, un autre agent qui bosse indépendamment. Pendant que le Terminal 1 fix un bug de validation, le Terminal 2 implémente une petite feature sur une autre partie de la codebase.

Terminal 3 : Celui-là reste sur le repo principal. Pas de worktree. C'est là que je vis. Je review les PRs que les deux autres terminaux créent, je lance l'app, je teste les changes, je fais une code review, et je merge ce qui est prêt. Quand une PR est mergée, je tire la prochaine issue P0 du board et j'envoie un des terminaux libres dessus.

Le cycle tourne toute la journée. Deux agents buildent, je review et merge, puis je réassigne. À la fin de la journée : 17 mergées, 22 fermées, 7 encore en pending review.

Je creuse les sessions parallèles et l'isolation par worktree dans le cours d'agentic coding.

Pourquoi des worktrees et pas des clones séparés

Un git worktree, c'est un checkout léger d'une autre branch qui partage le même répertoire .git que ton repo principal. Pas un clone. Pas une copie. Même historique, mêmes remotes, même config.

git worktree add ../fix-47 -b fix/47-broken-validation

Claude Code a un support natif des worktrees. Tu peux aussi utiliser le flag --worktree pour démarrer une session directement dans un nouveau worktree.

L'important : ton CLAUDE.md et ton répertoire .claude/ vivent dans l'historique git. Chaque worktree hérite du même context projet automatiquement. Chaque agent lit les mêmes conventions, les mêmes règles de frontière, les mêmes docs d'architecture. Tu n'as pas à ré-expliquer ta codebase trois fois.

Le context switching va te casser la tête

Voilà ce dont personne ne te parle sur les Claude Code parallel sessions : le tooling est trivial. CMUX, worktrees, boards d'issues. Tu peux tout monter ça en un après-midi.

La partie dure, c'est ton cerveau.

Quand le Terminal 1 te pose une question sur un middleware d'auth pendant que le Terminal 2 attend une approbation sur une migration de base de données et que le Terminal 3 a un test qui fail que tu dois regarder, ta tête commence à tourner. Tu perds le fil de quel terminal bosse sur quoi. Tu approuves un truc que tu n'aurais pas dû. Tu oublies quelle PR tu as déjà reviewée.

Ça fait l'effet de perdre la tête. C'est normal. C'est la courbe d'apprentissage.

Mon conseil : commence avec deux terminaux, pas trois. Un agent bosse, tu review dans l'autre. Habitue-toi au rythme. Apprends à context-switcher sans perdre le fil de ce que chaque session fait.

Donne-toi le droit d'être lent au début. Tu entraînes une nouvelle compétence. Pas une compétence technique. Une compétence cognitive. La capacité à tenir plusieurs flux de travail indépendants dans ta tête, à basculer entre eux sans confusion, et à maintenir la qualité de review à travers tous.

Au bout de quelques semaines à deux terminaux, ajoute-en un troisième. C'est là que le vrai levier s'enclenche, parce que maintenant tu as un terminal dédié à la review et deux agents parallèles qui produisent du travail pour toi à checker.

Ce qui le fait marcher (et ce qui le casse)

Le système marche quand :

• Les issues sont bien scopées. Une issue, un sujet, assez de context pour qu'un agent bosse en autonomie.
• Les tasks ne touchent pas les mêmes fichiers. Deux agents qui éditent le même fichier de config, ça veut dire des merge conflicts qui mangent plus de temps que ce que tu as économisé.
• Tu review vraiment. Skippe l'étape de review et tu ne fais pas de l'agentic coding. Tu ships juste ce qui est sorti.

Le système casse quand :

• Les issues sont vagues. « Fix le dashboard » n'est pas une issue qu'un agent peut prendre. « Le chart du revenue affiche NaN quand la plage de dates est vide » en est une.
• Tu essaies d'aller trop vite. Quatre ou cinq agents simultanés, ça a l'air génial jusqu'à ce que la merge queue s'empile et que les rebases commencent à conflicter.
• Tu arrêtes de faire attention. Les agents te diront avec assurance que tout marche quand le code compile mais que les tests fail. Fie-toi à tes tests, pas au self-report de l'agent.

Trois terminaux, c'est mon sweet spot. Deux, c'est toujours safe. Au-delà de trois, la charge cognitive et l'overhead de merge commencent à manger les gains.

Les chiffres

17 PRs mergées. 22 issues fermées. 7 en pending. Une journée de boulot sur un sprint qui se termine ce soir.

Je n'ai pas tapé la plupart du code. Je l'ai reviewé, testé, fixé ce qui avait besoin d'être fixé, et mergé ce qui était prêt. Le shift de rôle, c'est la vraie insight ici. Tu arrêtes d'être la personne qui écrit le code et tu deviens celle qui dirige et valide le travail. Comme un tech lead, sauf que ta team, c'est trois sessions Claude Code dans des panes CMUX.

Ce shift est inconfortable au début. Puis ça devient la seule façon dont tu veux bosser.

Hier a changé ma façon de penser les sprints. Pas plus d'heures, meilleure décomposition. Je couvre le scaling up dans le cours d'agentic coding.