Vous confiez un bug à Claude Code et une petite fonctionnalité à Codex, vous partez, et vous revenez sur un fichier qui ne ressemble à rien. La modification d'un des agents a disparu. Ou bien les deux modifications sont là et le build échoue. Ou pire, tout compile et un test casse quelque part que ni l'un ni l'autre n'a touché. Rien n'a planté pendant votre absence. Les deux agents ont fait le travail demandé. Le fichier ne pouvait pas contenir deux auteurs à la fois, et personne ne vous a dit lequel avait gagné.
Ce silence, c'est le vrai problème. Un fichier n'est pas un outil de fusion. Quand deux agents de codage écrivent dans auth.ts dans le même répertoire à des moments qui se chevauchent, il n'y a ni verrou, ni file d'attente, ni avertissement ; il n'y a que le processus qui a enregistré en dernier. Cet article déroule la collision étape par étape, nomme le mode de défaillance à chaque stade, et se termine par une checklist à exécuter avant votre prochaine session en parallèle.
Il pointe aussi vers le workflow auquel ces correctifs mènent. Sharkly est une plateforme tout-en-un de commandement et de gestion d'agents qui se place au-dessus des agents de codage que vous utilisez déjà. Elle attribue à chaque Tâche son propre worktree isolé et rend visibles le contexte, la progression, les blocages, les résultats et la revue humaine, de la demande à la mise en production. Vous pouvez instaurer la même discipline à la main avec du Git classique, et l'essentiel de cet article vous montre comment. La dernière section traite du moment où le faire à la main cesse d'être rentable.
Il n'y a pas de verrou : le dernier qui écrit gagne
Commençons par la pire version, car c'est la plus courante et la moins visible. Les deux agents tournent dans le même répertoire de travail. L'agent A lit auth.ts, planifie une modification et commence à écrire. L'agent B lit le même auth.ts une seconde plus tard, planifie une modification différente sur la version qu'il a lue, et écrit lui aussi.
Aucun n'a lu la modification de l'autre, parce qu'elle n'était pas encore enregistrée au moment de la lecture. Celui qui enregistre en second écrase le fichier sur le disque avec une version qui n'a jamais contenu le travail du premier agent. C'est le « dernier qui écrit gagne », et c'est silencieux. Pas de marqueur de conflit, pas d'erreur, pas de code de sortie. L'agent A signale un succès. L'agent B aussi. L'un des deux vous ment sans le savoir.
La course au lockfile est la même défaillance, mais dans un endroit plus coûteux. L'agent A lance npm install et réécrit package-lock.json ; l'agent B, en pleine installation, le réécrit à nouveau à partir d'un état de départ différent. Le résultat est un lockfile qui ne correspond à aucun des deux arbres de dépendances, et la casse se manifeste sur la machine de quelqu'un d'autre des jours plus tard. Les sorties de build partagées, un port unique de serveur de développement et un cache global échouent tous de la même manière.
La solution n'est pas un agent plus intelligent. C'est de donner à chaque agent sa propre pièce.
Une copie de travail par agent : l'écrasement silencieux devient un conflit visible
Un worktree Git est une seconde copie extraite d'un même dépôt, sur sa propre branche, partageant un unique magasin d'objets .git. Chaque agent dispose d'un vrai répertoire pour éditer, builder et tester, sans voir le travail en cours des autres.
# From the main repo
git worktree add ../repo-agent-a -b agent/auth-refactor
git worktree add ../repo-agent-b -b agent/session-timeout
Pointez l'agent A vers ../repo-agent-a et l'agent B vers ../repo-agent-b. Désormais, les modifications non enregistrées de A dans auth.ts sont invisibles pour B, et aucun des deux agents ne peut écraser le fichier de l'autre sur le disque, puisqu'ils éditent deux fichiers différents sur deux branches différentes. Le modèle des worktrees est approfondi dans Git worktrees for AI coding agents et coding agent worktrees: one checkout per task.
Remarquez ce que l'isolation a accompli ici. Elle n'a pas empêché les deux agents d'éditer le même fichier. Elle a converti une perte de données silencieuse en un conflit de fusion visible au moment où les branches se rejoignent. C'est une vraie amélioration : Git s'arrête et vous montre les lignes exactes en désaccord, et vous les résolvez en ayant pleine vue sur les deux versions. Un conflit que vous pouvez voir est un problème que vous pouvez corriger. L'écrasement que vous ne voyiez pas, c'est celui qui partait en production.
Une limite qu'il faut énoncer clairement : les worktrees isolent les fichiers, pas les effets de bord. Une base de données partagée, un port unique ou un chemin de sortie codé en dur entrent toujours en collision entre worktrees. Isolez-les aussi, ou sérialisez les agents qui en ont besoin.
Le conflit que vous ne pouvez pas voir
Voici le mode de défaillance qui survit à l'isolation. L'agent A, travaillant dans son propre worktree, renomme getUser() en fetchUser() et met à jour tous les appels qu'il possède. L'agent B, travaillant en parallèle dans son propre worktree, écrit trois nouveaux appels à getUser(), parce que c'était le nom de la fonction au moment où B a lu le fichier.
Les deux branches fusionnent sans aucun marqueur de conflit. Git compare des lignes, et ligne par ligne rien ne se chevauchait : A a modifié ses fichiers, B en a ajouté de nouveaux. La fusion est propre. Puis le build casse sur un getUser non défini, ou bien il compile et échoue à l'exécution là où le vérificateur de types n'a pas pu aller. Aucun outil ne l'a signalé, parce que textuellement il n'y avait aucune collision. Les deux modifications divergeaient sur le sens du fichier, pas sur son texte.
C'est pourquoi « il suffit d'isoler les agents » n'est pas la réponse complète. L'isolation reporte une collision sur un même fichier vers une collision sur une même interface, et le second type se cache mieux que le premier. Le levier ici, c'est le cadrage des tâches, pas l'outillage. Une règle utile : si vous ne pouvez pas décrire les tâches de deux agents sans nommer le même fichier ou la même fonction, alors c'est une seule tâche, pas deux. Découper le travail selon les frontières des modules, c'est l'essentiel de ce qui évite que faire travailler Claude Code et Codex ensemble sur une même base de code ne se transforme en après-midi de débogage. Quand deux tâches partagent réellement une interface, sérialisez-les, ou fusionnez et rebasez entre les étapes pour que le second agent lise la réalité du premier.
Où le montage fait maison cesse de passer à l'échelle, et ce qu'apporte un tableau de tâches
Deux agents et un fichier partagé, vous pouvez gérer ça à la main : deux worktrees, un cadrage soigné, une fusion que vous surveillez. La méthode tient jusqu'à ce que le décompte devienne difficile. Quel agent est sur quelle branche. Quel worktree correspond à quelle tâche. Laquelle de cinq fusions propres a discrètement modifié une interface partagée. Quelles branches attendent votre revue, et lesquelles vous avez déjà regardées. Les commandes Git ne sont jamais devenues plus difficiles ; c'est la tenue des comptes autour qui l'est devenue, et c'est précisément là que les collisions sur un même fichier passent entre les mailles, parce que vous avez approuvé une fusion que vous n'avez pas lue entièrement.
Un tableau de tâches change ce que vous suivez. Au lieu d'un mur de terminaux et de worktrees détachés, chaque unité de travail est une Tâche avec un responsable, une branche et un état. Dans Sharkly, une Tâche obtient automatiquement son propre worktree isolé, de sorte que l'isolation au niveau des fichiers est le comportement par défaut plutôt qu'une commande dont vous devez vous souvenir. L'exécution, les blocages et les résultats reviennent à la Tâche, ce qui vous permet d'évaluer une modification par rapport à son périmètre déclaré au lieu de reconstituer l'intention à partir d'un diff. Et la répartition du travail reste fixe : les agents recherchent, exécutent, testent et rendent compte ; les humains fixent la direction, accordent l'autorité et acceptent le résultat. L'automatisation s'arrête là où le jugement de l'équipe est requis.
Ce dernier point est celui que l'isolation seule ne résout jamais. De meilleurs outils facilitent l'isolation et la fusion, mais la revue ne passe pas à l'échelle avec le nombre d'agents ; elle passe à l'échelle avec votre attention, et la revue humaine est le véritable goulot d'étranglement du travail d'agents en parallèle. Cinq agents produisent cinq branches dans le temps qu'il vous faut pour en lire une attentivement. Un tableau de tâches ne lit pas le code à votre place. Il garde la file d'attente honnête, pour que la modification d'apparence plausible ne soit pas survolée et fusionnée parce que vous avez perdu de vue dans quelle pile elle se trouvait. La même arithmétique des conflits se retrouve au niveau du dépôt, comme le montre plusieurs agents de codage dans un même dépôt.
Vous pouvez bâtir cela avec des worktrees et de la discipline, ou utiliser Sharkly pour gérer le workflow. Si vous faites déjà tourner plusieurs agents, l'intérêt est d'avoir un seul endroit où leurs tâches et leurs résultats résident, au lieu d'être éparpillés entre les terminaux.
La checklist à exécuter avant votre prochaine session en parallèle
Exécutez ceci avant de pointer deux agents sur quoi que ce soit :
- Donnez à chaque agent son propre worktree. Jamais deux agents dans un même répertoire de travail.
git worktree add ../repo-<task> -b agent/<task>par tâche. Voir parallel agents in isolated worktrees. - Cadrez les tâches pour qu'elles ne nomment pas le même fichier ni la même fonction. Si c'est inévitable, c'est une seule tâche ; sérialisez-la.
- Isolez les effets de bord, pas seulement les fichiers. Séparez les bases de données, les ports, les chemins de sortie et les caches, ou sérialisez les agents qui les partagent.
- Rebasez avant de fusionner quand deux branches ont tourné sur le même commit de départ, pour que le travail du second agent se place au-dessus de celui du premier.
- Lancez la vérification de types et la suite de tests complète après chaque fusion, pas après la dernière. Les conflits sémantiques passent une fusion propre et échouent ici.
- Révisez chaque branche par rapport au périmètre de sa tâche, une à la fois. Une pile de coches vertes non lues, c'est là que le conflit invisible part en production.
Deux agents qui éditent un seul fichier n'est pas un cas limite rare ; c'est à quoi ressemble le travail en parallèle dès que vos tâches se chevauchent d'un centimètre. Anticipez la collision, rendez-la visible, et gardez une personne qui décide de ce qui est fusionné.
