Plusieurs agents IA sur un même dépôt
Plusieurs agents peuvent partager un dépôt si l'écriture est arbitrée : un agent annonce les chemins qu'il va toucher, le serveur les lui attribue, et les refuse à tous les autres jusqu'à ce qu'il les rende. Sans cet arbitrage, le second agent efface le travail du premier sans que rien ne le signale.
Le cas qui casse tout
Deux agents reçoivent deux tâches qui touchent le même fichier. Le premier lit le fichier, réfléchit vingt secondes, écrit. Le second a lu la même version avant que le premier écrive, et il écrit par-dessus. Rien n'a planté, rien n'a averti, et le travail du premier a disparu.
Ce cas n'est pas rare dès qu'il y a plus d'un agent, parce que les agents lisent large et écrivent vite. C'est la raison pour laquelle presque tous les outils isolent : une machine par agent, une branche par agent.
Ce que fait le reste du monde : un worktree par agent
La réponse courante à ce problème est le partitionnement : on donne à chaque agent son propre worktree git, une copie complète des fichiers avec son propre index, et on s'arrange pour que les périmètres ne se chevauchent pas. C'est ce que font Windsurf, Conductor et OpenHands, et c'est ce que recommandent la plupart des guides.
Ça marche, et ça a exactement un défaut : le partitionnement est une promesse, pas une garantie. Personne ne vérifie que les périmètres ne se chevauchent pas, et quand ils se chevauchent on l'apprend à la fusion, quand les deux agents ont fini et que plus personne ne se souvient du raisonnement.
La réservation, en trois temps
Avant d'écrire, un agent annonce les chemins qu'il va toucher. Le tableau les lui attribue s'ils sont libres, et les refuse s'ils sont tenus. Un seul détenteur par fichier, à tout instant.
Pendant le travail, un observateur regarde les écritures réelles sur le disque et attribue chacune à son auteur. Une écriture sur un chemin tenu par quelqu'un d'autre est photographiée avant d'atterrir : la version précédente est conservée, donc rien n'est perdu même quand la règle est contournée.
À la fin, l'agent rend ses chemins. Le fichier redevient disponible pour le suivant, sans fusion, parce qu'il n'y a jamais eu deux versions vivantes en même temps.
Ce que ça donne à l'écran
Chaque fenêtre montre son agent au travail, et le tableau montre qui tient quoi. On voit qu'un agent attend, et pourquoi. Un agent bloqué est visible avant qu'il fasse des dégâts, ce qui est la vraie différence avec une file d'attente invisible.
Les gens comptent aussi. Plusieurs personnes sur le même canvas pilotent leurs propres agents et voient les curseurs des autres, avec un nom sur chacun.
Quand ce n'est pas la bonne forme
Si vos tâches sont vraiment indépendantes et longues, l'isolation par machine reste raisonnable : rien à arbitrer, rien à attendre. Le partage gagne quand les tâches se touchent, ce qui est le cas dès qu'on travaille sur une même fonctionnalité. Les comparatifs détaillent le choix outil par outil.
Réponses directes
Faut-il utiliser git worktree pour lancer plusieurs agents ?
C'est la réponse que donnent la plupart des guides, et elle marche : un worktree par agent, chacun avec son index et ses fichiers, donc aucune collision possible. Elle a un coût, et c'est toujours le même : autant de copies que d'agents, et une fusion par copie à la fin. Un dossier unique avec une réservation de fichier supprime les deux, au prix d'un agent qui attend parfois trente secondes.
Pourquoi ne pas donner une branche à chaque agent ?
C'est la solution courante et elle déplace le coût vers la fin. Trois branches produisent trois fusions, et les conflits apparaissent quand les trois agents ont fini, donc au moment où personne ne se souvient du raisonnement. Un dossier partagé règle le conflit au moment où il se produit.
Que se passe-t-il si un agent ignore la réservation ?
Il n'a pas le choix : la règle est appliquée par le serveur, pas suggérée au modèle. Un observateur surveille les écritures et attribue chacune à son auteur, et une écriture sur un chemin tenu par quelqu'un d'autre est photographiée avant d'atterrir, donc les deux versions existent encore.
Combien d'agents en même temps ?
Cinq fenêtres d'agent sur la formule Pro, et davantage au-dessus. La limite pratique n'est pas la machine, c'est le nombre de chantiers indépendants que le projet contient à un instant donné.