Git Worktrees + agents parallèles : mon setup Claude Code

La première fois que j'ai lancé deux agents de code dans le même dépôt en même temps, ils se sont battus pour les mêmes fichiers et j'ai passé une heure à démêler le résultat. Le problème, ce n'était pas les agents. C'était moi, qui mettais deux ouvriers à un seul bureau.

Les worktrees Git ont réglé ça, et ils ont fini par changer la façon dont je structure une journée entière de travail.

Le setup

Un worktree est un second répertoire de travail rattaché au même dépôt. Même historique Git, branch différente sortie, fichiers différents sur le disque. Une seule commande :

git worktree add ../project-feature-a feature-a
git worktree add ../project-fix-b fix-b

J'ai maintenant trois répertoires : le dépôt principal et deux worktrees, chacun sur sa propre branch. J'ouvre une session Claude Code dans chacun. Chaque agent a son propre système de fichiers isolé, sa propre branch, son propre dev server qui tourne sur son propre port. Ils ne peuvent physiquement pas entrer en conflit.

Mon organisation réelle un jour type :

• Dépôt principal : là où je travaille manuellement, où je relis et où je merge.
• Worktree 1 : un agent qui construit une feature à partir d'une spec écrite.
• Worktree 2 : un agent sur une tâche plus petite, un bug fix, un refactor, de la couverture de test sur un module que j'ai touché la semaine dernière.

Deux agents qui tournent, c'est mon maximum confortable. J'ai essayé trois. Le facteur limitant n'est pas la puissance de calcul, c'est mon attention. J'y reviens plus bas.

Ce qui a vraiment changé dans mon workflow

La version naïve de cette histoire, c'est "j'écris du code trois fois plus vite maintenant". Ce n'est pas ce qui s'est passé.

Ce qui s'est passé, c'est que l'écriture de code a cessé d'être l'unité de travail. L'unité de travail est devenue la spec. Avant de lancer un agent sur un worktree, j'écris un brief court : l'objectif, les contraintes, quels fichiers comptent, à quoi ressemble le résultat fini, à quoi ne pas toucher. Dix minutes d'écriture. La qualité de ce brief détermine presque tout dans le résultat, ce qui veut dire que la compétence qui s'est affûtée cette année, ce n'est pas le code, c'est la spécification.

La journée ressemble alors à ça : lancer l'agent un sur la feature, lancer l'agent deux sur le fix, faire mon propre travail dans le dépôt principal. Toutes les 20 à 30 minutes, changement de contexte : faire le point avec un agent, répondre à ses questions, le réorienter s'il a dérivé, relire un morceau de diff tant qu'il est encore petit.

L'inconvénient honnête : le changement de contexte a un vrai coût. Trois flux de travail parallèles, ça veut dire trois modèles mentaux chargés en même temps. Certains jours, on se sent comme un tech lead pour une équipe de juniors très rapides et très littéraux. Productif, mais fatigant d'une façon différente de la fatigue du deep work.

Le goulot d'étranglement de la relecture

Voici la partie que personne ne met dans ses threads de setup : quand les agents écrivent la majeure partie du code, la relecture devient le goulot d'étranglement, et ce sont tes habitudes de relecture qui décident de la qualité de ton code.

Les règles que je suis désormais, apprises à la dure :

Relire par morceaux, pas à la fin. Un agent qui a tourné une heure sans surveillance produit un diff trop gros pour être relu honnêtement. Je fais le point aux jalons logiques. Si le diff dépasse quelques centaines de lignes, j'arrête l'agent et je relis avant de le laisser continuer.

Ne jamais merger depuis le worktree. Tout repasse par une branch et une PR, même sur mes propres projets en solo. Le diff de la PR, c'est là où je lis vraiment le code, loin de la conversation qui l'a produit. Lire le code à côté du chat qui l'a généré te rend trop indulgent. L'explication de l'agent te conditionne à voir ce qu'il avait l'intention de faire, pas ce qu'il a réellement écrit.

Les tests ne sont pas négociables. Pas parce que les agents écrivent plus de bugs que moi (discutable), mais parce que sans tests je ne peux pas savoir si un diff qui a l'air sûr de lui est correct. L'agent écrit aussi les tests, mais je relis les tests avec deux fois plus d'attention que l'implémentation. Un test faux qui passe est pire que pas de test du tout.

Garder un rituel de nettoyage. Les worktrees s'accumulent. Lancer git worktree list chaque vendredi, élaguer ce qui est mergé :

git worktree remove ../project-feature-a
git worktree prune

Là où ça brille, là où ça ne brille pas

Ça vaut le coup de paralléliser : les features bien spécifiées, les refactors mécaniques, le rattrapage de tests, les migrations avec un pattern clair, tout ce dont la spec tient sur une page.

Ça ne vaut pas le coup : le travail exploratoire, les décisions d'architecture, tout ce pour quoi je ne sais pas encore ce que je veux. Lancer un agent sur un problème flou ne fait que produire du code sûr de lui pour le mauvais problème, en parallèle. Ce travail-là, je le garde dans le dépôt principal, avec moi aux commandes.

Ce que je me dirais à moi-même au départ

Les worktrees, c'est la partie facile : une commande, pas de magie. Le vrai changement est organisationnel. Tu deviens le manager d'un travail parallèle, et les compétences qui comptent sont l'écriture de bons briefs et la relecture honnête des diffs. Si tes specs sont vagues et tes relectures bâclées, les agents parallèles t'aident juste à produire du mauvais code plus vite.

Commence avec deux. Écris le brief avant d'ouvrir le terminal. Et relis les tests plus durement que le code.