Comment utiliser git worktree pour coder avec l’IA ?

J’utilise git worktree pour donner à chaque agent IA son propre dossier de travail, sans cloner tout le dépôt ni casser ma branche en cours. C’est simple, propre, et ça évite les collisions quand une feature, un hotfix et plusieurs tests avancent en parallèle.

Pourquoi les agents IA se marchent dessus ?

Quand plusieurs agents IA bossent dans le même dossier, ils ne sont pas vraiment en parallèle. Ils sont juste plusieurs mains sur le même clavier. Même répertoire, mêmes fichiers, même index Git, c’est-à-dire la zone où Git prépare ce qui va partir dans le prochain commit.

Et là, ça part vite en vrille.

Je le vois souvent sur un cas très simple. Je suis sur une branche feature avec un agent IA qui modifie une API, ajoute deux tests, touche un fichier de config. Tout va bien. Puis un hotfix urgent arrive. En workflow classique, je dois stasher mes changements, changer de branche, relancer mon contexte, expliquer à l’agent ce qu’on fait maintenant, corriger, tester, commit, revenir sur ma feature, récupérer le stash, vérifier que rien n’a sauté.

Sur le papier, ça marche. Dans la vraie vie, c’est lourd. Et avec l’IA, c’est encore plus visible, parce que l’agent génère vite beaucoup de modifications.

Le problème devient vraiment pénible quand plusieurs agents travaillent sur des fichiers proches. Un agent refactore un service. Un autre ajoute une validation dans le même module. Vous corrigez un bug à la main entre les deux. Résultat possible : un fichier écrasé, un conflit Git moche, un état local impossible à lire, ou pire, un changement utile perdu dans le bruit.

Le vrai sujet, ce n’est pas que l’IA “fait n’importe quoi”. Bien sûr, elle peut se tromper. Mais ici, le blocage vient surtout du manque d’isolation du workspace. On demande à plusieurs tâches de cohabiter dans un seul espace de travail, avec un seul état local, une seule branche active, un seul index Git.

Chez les équipes qui testent sérieusement l’IA dans le dev, je vois souvent ça. Le modèle n’est pas toujours le facteur limitant. Le bazar dans Git, les changements locaux mélangés, les stashes oubliés, les branches qui traînent, ça bloque beaucoup plus vite qu’on ne l’imagine.

Si on veut faire tourner plusieurs agents, ou juste plusieurs tâches en parallèle sans se crisper, il faut arrêter de penser “un dépôt Git = un seul dossier de travail”. Le bon réflexe, c’est de créer plusieurs espaces de travail séparés, chacun avec ses fichiers, sa branche, son contexte, tout en partageant le même dépôt Git. C’est exactement là que git worktree devient intéressant.

C’est quoi un git worktree ?

Un git worktree, c’est un répertoire de travail séparé, relié au même dépôt Git, avec ses propres fichiers checkoutés et son propre index.

Dit plus simplement, vous avez un seul dépôt Git derrière, avec le même historique, les mêmes commits, les mêmes objets Git. Mais vous pouvez avoir plusieurs dossiers de travail à côté, chacun ouvert sur une branche différente. Chaque dossier a son propre état de fichiers, ses propres modifications en cours, et son propre index. L’index, c’est la zone de préparation de Git, celle qu’on remplit quand on fait un git add avant de commit.

Checkouté, ça veut juste dire que Git a sorti les fichiers d’une branche dans un dossier, pour que vous puissiez bosser dessus. Avec un worktree, Git ne duplique pas tout le dépôt comme un clone classique. Il ajoute un nouveau dossier de travail, branché sur le même backend Git.

Sur disque, ça peut ressembler à ça :

• myapp branche main
• myapp-feat-auth branche feat/auth
• myapp-feat-api branche feat/api
• myapp-hotfix-login branche hotfix/login

Dans cet exemple, myapp reste sur main. Le dossier myapp-feat-auth peut contenir le travail sur l’authentification. Le dossier myapp-feat-api peut contenir le travail sur l’API. Et myapp-hotfix-login peut servir à corriger un bug urgent sans toucher au reste.

C’est là que ça devient intéressant avec l’IA. Un agent peut bosser sur l’authentification dans son dossier. Un autre peut modifier l’API dans un autre dossier. Et moi, pendant ce temps, je peux ouvrir un hotfix à côté, lancer les tests, corriger un truc en prod, sans casser leur contexte. J’ai vu ça chez un client avec plusieurs assistants IA en parallèle, le gain était surtout mental : moins de changements mélangés, moins de peur de tout écraser.

Il y a juste une règle importante à garder en tête. Une même branche ne doit pas être checkoutée dans deux worktrees en même temps. Git peut forcer certains cas particuliers, mais dans un workflow propre, on évite. Une branche, un worktree. C’est plus simple, plus lisible, et ça évite les surprises.

Maintenant qu’on sait ce que c’est, il faut comprendre pourquoi ce n’est pas juste un clone de plus.

Pourquoi c’est mieux que plusieurs clones ?

Quand je lance plusieurs agents IA sur le même projet, je veux éviter le bazar. Plusieurs clones peuvent dépanner vite fait, oui. Mais dès qu’on commence à faire ça sérieusement, avec une branche par agent, des tests en parallèle, des revues, des retours en arrière, ça devient vite sale.

Avec plusieurs clones, chaque dossier contient sa propre copie du dépôt. Ça veut dire son historique Git, ses références, ses branches locales, sa configuration parfois différente. Sur un petit projet, ça passe. Sur un monorepo ou un projet avec beaucoup d’historique, vous commencez à payer le prix en espace disque, en temps de clone, et surtout en confusion.

Le vrai problème, ce n’est pas juste le disque. C’est la dispersion. Vous avez un agent IA qui travaille dans un clone, un autre dans un autre clone, vous faites un fetch ici, un pull là-bas, et vous finissez par vous demander pourquoi une branche existe dans un dossier mais pas dans l’autre. J’ai déjà vu ça chez un client avec trois assistants IA branchés sur le même repo. Techniquement ça marchait. Humainement, personne ne savait plus où était la version propre.

Avec git worktree, les dossiers de travail restent séparés, mais ils partagent le même historique Git. En gros, Git garde une base commune, et chaque worktree checkout seulement les fichiers nécessaires pour une branche donnée. Le coût disque supplémentaire vient surtout des fichiers présents dans chaque dossier, pas d’une duplication complète du dépôt.

C’est beaucoup plus lisible quand on orchestre plusieurs agents IA. Un dossier pour l’agent qui corrige les tests, un autre pour celui qui refactorise, un autre pour tester une idée risquée. Tout reste coordonné autour du même dépôt Git.

Approche	Avantage	Limite	Usage conseillé
Clone multiple	Simple à comprendre et rapide à improviser.	Duplique l’historique Git, disperse les branches et demande souvent des synchronisations manuelles.	Utile pour dépanner ou tester ponctuellement un projet isolé.
Git worktree	Partage le même historique Git tout en gardant des dossiers de travail séparés.	Demande de comprendre un minimum la logique des branches et des worktrees.	Idéal pour piloter plusieurs agents IA ou travailler proprement sur plusieurs tâches en parallèle.

Pour moi, la différence est assez nette. Plusieurs clones, c’est du bricolage acceptable. Git worktree, c’est une base de travail plus stable, plus propre, et mieux adaptée dès qu’on veut industrialiser un workflow avec l’IA.

Quelles commandes faut-il connaître ?

Il suffit de connaître quelques commandes git worktree pour créer, lister, protéger, supprimer et nettoyer ses espaces de travail. Dans un contexte IA, c’est largement suffisant pour garder le contrôle. Je crée un worktree par agent, par mission, ou par tentative un peu risquée. Comme ça, l’IA peut modifier du code sans polluer ma branche principale.

• J’utilise git worktree add ../myapp-feat-auth -b feat/auth quand je veux créer un nouveau worktree avec une nouvelle branche. Typiquement, je lance un agent IA sur une feature d’authentification, et je lui donne son propre dossier. Il peut casser des choses, tester, générer du code, je garde le reste propre.
• J’utilise git worktree add ../myapp-hotfix-login hotfix/login quand la branche existe déjà. C’est pratique si un agent doit reprendre un hotfix en cours, ou si je veux comparer ce qu’il propose avec une correction déjà commencée.
• J’utilise git worktree list pour voir tous les worktrees liés au dépôt. Quand vous avez deux ou trois agents IA qui bossent en parallèle, ça évite vite le bazar. Je vois les dossiers, les branches associées, et je sais qui travaille sur quoi.
• J’utilise git worktree lock ../myapp-feat-auth pour protéger un worktree contre un nettoyage accidentel. Je le fais surtout quand une expérimentation IA est longue, ou quand je veux garder un état précis pour le relire plus tard.
• J’utilise git worktree unlock ../myapp-feat-auth quand je n’ai plus besoin de cette protection. Par exemple, une fois que j’ai validé ou abandonné les changements proposés par l’agent.
• J’utilise git worktree remove ../myapp-feat-auth pour supprimer proprement un worktree. En général, je le fais quand la branche a été mergée, ou quand l’essai IA ne vaut pas le coup d’être gardé.
• J’utilise git worktree prune pour nettoyer les métadonnées de worktrees supprimés à la main. Ça arrive quand quelqu’un efface un dossier directement au lieu de passer par Git. Pas dramatique, mais autant remettre le dépôt au propre.

Avant de supprimer quoi que ce soit, je vérifie toujours l’état du worktree avec git status. Un agent IA peut avoir laissé des modifications locales utiles, un test intéressant, ou un bout de refacto pas encore commité. J’ai déjà vu des équipes supprimer trop vite un dossier et perdre une bonne piste.

Ces commandes donnent la base. Mais les commandes seules ne suffisent pas. Pour que le workflow soit vraiment fiable avec l’IA, il faut aussi préparer le dépôt proprement avant de lancer les agents.

Comment préparer un workflow propre ?

Un workflow propre avec git worktree, ça commence avant même de lancer l’IA. Je vérifie d’abord que ma version de Git est compatible, que mon dépôt principal est clean, puis je crée un worktree dédié pour chaque tâche IA, chaque feature, ou chaque hotfix urgent.

Git worktree existe depuis Git 2.5. Donc je commence toujours par afficher la version installée :

git --version

Ensuite, je regarde l’état du dépôt principal. C’est bête, mais c’est là que beaucoup de problèmes commencent. Si je crée un worktree alors que mon dossier principal contient déjà des fichiers modifiés, je perds vite le fil. Donc je fais :

git status

Si j’ai du travail en cours, je choisis. Soit je commit, soit je stash. Le stash, c’est une mise de côté temporaire de mes changements. Pratique quand ce n’est pas prêt à être sauvegardé proprement dans l’historique Git.

git add .
git commit -m "init work before creating ai worktree"

Après ça, je peux créer un dossier séparé pour une tâche IA. Par exemple, si je veux demander à un agent de bosser sur l’authentification :

git worktree add ../myapp-feat-auth -b feat/auth

Mon workflow reste simple. Je garde main dans le dossier principal. Je crée un dossier par feature IA. Je crée aussi un dossier séparé si un hotfix arrive en urgence. Chaque agent IA travaille dans son propre répertoire, avec sa propre branche. Quand le résultat est validé, je merge dans la branche cible, comme dans un workflow Git classique.

J’ai vu un truc très net chez un client. Dès que l’équipe a commencé à nommer clairement ses dossiers de worktree, les revues sont devenues beaucoup plus simples. Les retours arrière aussi. Surtout quand trois ou quatre tests IA tournaient en parallèle. Avant ça, personne ne savait vraiment quel dossier contenait quoi.

Bonne pratique	Pourquoi je le fais
Un worktree par tâche	Ça évite de mélanger les changements IA, les features et les correctifs urgents.
Une branche par worktree	Chaque travail reste isolé et facile à merger ou abandonner.
git status avant suppression	Je vérifie que je ne jette pas du travail non commité.
git worktree remove plutôt qu’une suppression manuelle	Git garde un état propre et sait que le worktree a disparu.
git worktree prune seulement pour nettoyer	Je l’utilise pour supprimer les références orphelines, pas comme commande réflexe.

On gagne quoi à isoler ses agents IA ?

Git worktree règle un problème très concret : travailler avec l’IA sans transformer son dépôt en champ de mines. Je garde un dossier propre pour main, je crée des espaces séparés pour les features, les hotfixs et les agents IA, et je limite les collisions entre fichiers, branches et contextes. Ce n’est pas une usine à gaz. Quelques commandes suffisent : add, list, lock, remove, prune. Le vrai bénéfice, c’est la fluidité. Vous pouvez tester plus vite, interrompre moins souvent votre travail, et faire tourner plusieurs assistants IA sur la même base de code avec beaucoup moins de risques.

FAQ

• À quoi sert git worktree dans un projet avec IA ?
  Git worktree sert à créer plusieurs dossiers de travail séparés à partir du même dépôt Git. C’est très utile avec l’IA parce que chaque agent peut travailler sur sa branche, dans son propre espace, sans écraser les fichiers d’un autre agent ou mon travail en cours.
• Quelle est la différence entre git worktree et plusieurs clones ?
  Avec plusieurs clones, je duplique le dépôt et son historique dans plusieurs dossiers. Avec git worktree, les dossiers de travail sont séparés mais ils partagent le même backend Git. C’est plus léger, plus coordonné, et plus propre pour suivre plusieurs branches en parallèle.
• Est-ce qu’un worktree peut utiliser la même branche qu’un autre ?
  Dans un usage propre, j’évite de checkout la même branche dans deux worktrees différents. L’idée, c’est justement d’avoir une branche claire par espace de travail : une feature, un hotfix, un test IA. Ça limite les états ambigus et les conflits inutiles.
• Quelles commandes git worktree faut-il connaître en priorité ?
  Les commandes de base sont git worktree add pour créer un worktree, git worktree list pour les lister, git worktree remove pour supprimer proprement, git worktree lock et unlock pour protéger ou libérer un worktree, et git worktree prune pour nettoyer les métadonnées restantes.
• Que faut-il vérifier avant de créer un git worktree ?
  Je vérifie d’abord ma version de Git avec git –version, puis l’état du dépôt avec git status. Si j’ai des changements locaux importants, je les commit ou je les stash avant de créer un nouveau worktree. Ça évite de démarrer un workflow IA sur une base déjà confuse.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en Tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent mettre l’IA dans leurs vrais workflows, pas juste faire des démos. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’ai travaillé avec Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres. Si vous voulez structurer vos usages IA, data ou automatisation sans perdre du temps dans le flou, contactez-moi.