Fan-out d'agents et worktrees git : du parallélisme sans collisions

Le pattern : un parent, plusieurs enfants qui écrivent

Muse Code repose sur une règle simple : quand un job se découpe en plusieurs tâches distinctes, elles sont automatiquement réparties entre des agents séparés. L’agent parent lance un enfant capable d’écrire du code par tâche. Rien à configurer, aucun « mode parallèle » à activer — la décomposition et la répartition sont le comportement par défaut dès que le travail est assez gros pour en profiter.

La question évidente arrive tout de suite : si plusieurs agents peuvent écrire du code en même temps, dans le même dépôt, pourquoi tout ne finit-il pas en conflits de merge et en fichiers écrasés ?

Une vraie session de fan-out : six tâches sur un même jeu, quatre déjà mergées, deux encore en cours — chacune dans son propre worktree sous .muse/worktrees/, sans jamais toucher au checkout principal.

Les worktrees : l’isolation façon git

Chaque agent enfant reçoit son propre git worktree — un checkout séparé du dépôt qui partage l’historique avec ta copie principale, mais possède son propre répertoire de travail et sa propre branche. Deux enfants peuvent modifier le même fichier chacun dans leur worktree sans jamais voir les changements de l’autre en cours de route. Structurellement, la collision est impossible.

Tout aussi important : ta copie de travail reste propre. Le répertoire ouvert dans ton éditeur n’est jamais celui qu’un agent est en train de modifier. Rien ne bouge sous ton curseur, aucune modification d’agent à moitié finie ne pollue ton diff, et abandonner le travail d’un agent coûte le prix de la suppression de son worktree, c’est-à-dire rien. Les changements n’atteignent ta branche que lorsque le travail est terminé et relu.

Pourquoi pas de simples branches ? Ou des conteneurs ?

Des branches classiques partagent un seul répertoire de travail — changer de branche en pleine tâche tirerait le tapis sous les pieds d’un agent en train de tourner. Des conteneurs complets ou des clones du dépôt fonctionneraient, mais c’est lourd : object stores dupliqués, mise en place lente, merge pénible. Les worktrees frappent en plein dans le mille. Leur création est quasi instantanée, ils partagent la base d’objets git sous-jacente, et re-merger la branche terminée d’un enfant, c’est du git ordinaire — pas de couche de synchro maison à laquelle faire confiance, pas d’état propriétaire à déboguer.

Six fonctionnalités à la fois, démonstration à l’appui

Les démos de lancement s’appuyaient massivement sur ce mécanisme : dans l’exemple de développement de jeu, Muse Code a construit six fonctionnalités simultanément, chaque agent dans son worktree, et chaque branche a mergé proprement. C’est le gain concret — le temps réel d’un sprint multi-fonctionnalités s’effondre vers la durée de sa tâche la plus longue, au lieu de la somme de toutes.

Essaie la recette

Le fan-out d’agents est l’un des trois patterns pour lesquels Meta livre des recettes dans son cookbook — découper un gros job entre des subagents pour que rien ne se percute en vol. Le cookbook en propose la version exécutable. Et comme le travail réparti en fan-out est exactement le genre de chose que tu voudras auditer plus tard, chaque spawn d’enfant, chaque appel d’outil et chaque merge est capturé dans l’event log — rien ne se passe hors procès-verbal sous prétexte que ça s’est passé en parallèle.