Faire tourner plusieurs agents IA en parallèle avec git worktree
Claude Code ou Codex sur trois tâches à la fois, sans qu’ils réécrivent les fichiers les uns des autres. Le mécanisme existe déjà dans git : un dossier de travail par tâche, un historique partagé.
Mis à jour le 9 octobre 2026 · 8 min de lecture
Le problème : deux agents, un seul dossier
Un agent de code lit, écrit et lance des commandes dans ton dossier de travail. Lance-en un deuxième dans le même dossier et tout se mélange : l’un change de branche pendant que l’autre écrit, l’un lance les tests sur le code à moitié modifié par l’autre, et le diff final contient les deux tâches emmêlées.
Cloner le dépôt une deuxième fois marche, mais tu dupliques tout l’historique et les branches ne se voient pas entre clones. Git a mieux : les worktrees.
Git worktree en trente secondes
Un worktree est un dossier de travail supplémentaire rattaché au même dépôt. Tous partagent un seul .git : mêmes commits, mêmes branches, mêmes remotes. Chacun a sa propre branche, ses propres fichiers et son propre état.
Ton dossier habituel. Tu n’y touches pas pendant que les agents travaillent.
Agent 1 : la nouvelle fonction d’export.
Agent 2 : la refonte de l’authentification.
Les trois dossiers partagent un seul historique : un commit fait dans mon-projet-export est visible tout de suite depuis mon-projet, sans push ni pull.
Un worktree par tâche
Depuis ton dépôt, une commande crée le dossier et la branche d’un coup. Place les worktrees à côté du dépôt, pas dedans, pour que ni git ni tes outils ne les confondent avec ton code.
-b crée une nouvelle branche à partir de ta position actuelle. Sans -b, tu donnes une branche existante : git worktree add ../mon-projet-fix fix/login.
git worktree list affiche chaque dossier, son dernier commit et sa branche. C’est ton tableau de bord.
Lancer un agent dans chaque worktree
Un terminal par worktree, un agent par terminal. L’agent ne voit que son dossier, donc il ne peut ni écraser ni tester le travail d’un autre.
Claude Code sait aussi créer le worktree lui-même : claude --worktree export ouvre une session dans un nouveau worktree nommé export.
Écris des tâches qui ne se chevauchent pas
Les worktrees isolent les fichiers pendant le travail, pas au moment du merge. Deux agents qui modifient le même fichier produiront un conflit à la fin. Découpe par zone du code : une tâche sur l’export, une sur l’auth, une sur les dépendances.
Les pièges à connaître
Les dépendances ne sont pas partagées
Un worktree ne contient que les fichiers suivis par git. Pas de node_modules, pas de .venv, pas de build : relance l’installation dans chaque nouveau worktree (pnpm install, uv sync…). Avec pnpm, le store global évite de tout retélécharger.
Les fichiers .env non plus
Ils sont ignorés par git, donc absents du nouveau dossier. Copie-les : cp .env ../mon-projet-export/. Sans eux, l’agent verra des tests échouer pour une mauvaise raison.
Une branche, un seul worktree
Git refuse d’extraire une branche déjà utilisée ailleurs : fatal: 'feat/export' is already used by worktree. C’est une protection, pas un bug. Crée une nouvelle branche.
Les ports et la base de données, eux, sont partagés
Deux serveurs de dev sur le port 3000 se battent. Donne un port à chaque worktree (PORT=3001 pnpm dev). Même logique pour une base locale : deux agents qui lancent des migrations sur la même base se gênent.
Ta machine aussi
Trois agents, trois serveurs de dev, trois suites de tests : la RAM part vite. Sur un portable, deux ou trois chantiers en parallèle est un plafond raisonnable.
wt new export crée le worktree, copie les .env, installe les dépendances et réserve un port libre. wt done export --merge fusionne et range. Un seul fichier bash, licence MIT : github.com/nestaweb/worktree-agents.
Relire, merger, nettoyer
Quand un agent a fini, relis tout ce qu’il a changé par rapport à main, pas seulement son dernier message. Les trois points comparent depuis le moment où la branche est partie.
git worktree remove refuse de supprimer un dossier qui contient des modifications non commitées. Ajoute --force seulement si tu es sûr de vouloir les perdre. La branche, elle, reste : supprime-la à part.
Si tu as effacé un dossier à la main, git worktree list le marque prunable. git worktree prune nettoie ces références.
Quand ça devient une équipe.
Et qu’elle tourne la nuit.
À la main, la méthode tient pour deux ou trois chantiers. Au-delà, tu passes ton temps à créer des dossiers, copier des .env, surveiller des terminaux et relire des diffs. C’est exactement ce que Vision Island automatise.
Tu écris la tâche depuis l’encoche de ton Mac. Vision crée le worktree et la branche.
Un architecte rend le plan en phases. Rien ne s’exécute avant ton feu vert.
Sécurité et qualité relisent le diff complet, en lecture seule, avant que tu merges.
La machine travaille pendant que tu dors. Au réveil, ce qui attend ta décision est rangé au même endroit.
Le Privacy Gateway bloque ou redirige vers un modèle local : rien ne sort sans ta permission.
Questions fréquentes
Quelle différence entre git worktree et git clone ?
Un clone copie tout le dépôt et vit sa vie : ses branches ne sont visibles ailleurs qu’après un push. Un worktree partage le même .git : pas de copie de l’historique, et chaque commit est visible immédiatement depuis les autres dossiers.
Combien d’agents lancer en parallèle ?
Autant que de tâches vraiment indépendantes et que ta machine encaisse. Sur un portable, deux ou trois. La limite pratique est souvent ton attention pour relire, pas la technique.
Supprimer un worktree supprime-t-il la branche ?
Non. git worktree remove supprime le dossier, la branche et ses commits restent. Supprime-la avec git branch -d une fois mergée.
Ça marche avec Codex, Cursor ou un LLM local ?
Oui. Le worktree est un mécanisme de git, pas d’un outil : tout agent qui travaille dans un dossier en profite, qu’il tourne dans le cloud ou sur un modèle local.