Subagent-driven development : paralléliser les agents sans casser son codebase

Le multi-agents fait rêver sur le papier : cinq agents qui avancent en parallèle, cinq fois plus vite. En pratique, sans méthode, on obtient cinq agents qui modifient les mêmes fichiers, se contredisent et laissent un codebase incohérent. Le subagent-driven development est la discipline qui rend le parallélisme réellement productif. Son ingrédient clé est étonnamment simple : un worktree git par agent. Voici comment ça marche.

Le problème : la concurrence sur les fichiers

Un sous-agent est une instance séparée que la session principale lance pour une tâche cadrée, avec son propre contexte, son prompt système, ses outils et ses permissions. La force du modèle — l’exécution parallèle — est aussi son danger : si deux agents écrivent dans le même répertoire de travail, ils s’écrasent mutuellement. La solution n’est pas de sérialiser (on perdrait le gain), mais d’isoler.

La brique de base : un worktree par agent

Un worktree git est une copie de travail liée au même dépôt, sur une branche distincte, dans un répertoire séparé. Deux agents dans deux worktrees partagent l’historique .git mais isolent leur espace de travail : zéro conflit de fichiers pendant qu’ils travaillent. C’est exactement le mécanisme que la Copilot app applique nativement, en donnant à chaque session son propre worktree.

# Un worktree isolé par tâche d’agent
git worktree add ../wt-auth    -b agent/auth
git worktree add ../wt-search  -b agent/search
git worktree add ../wt-tests   -b agent/tests

# Trois agents travaillent en parallèle, chacun dans son répertoire
# Puis on relit et on fusionne, tâche par tâche
git worktree list
git merge agent/auth        # après revue humaine
git worktree remove ../wt-auth

Des tâches bornées, pas des mandats flous

L’isolation ne suffit pas ; il faut aussi cadrer. Un sous-agent doit recevoir une tâche bornée : un objectif clair, un périmètre de fichiers défini, des critères de réussite explicites (tests qui passent, contrat d’interface respecté). Un agent avec un mandat vague — « améliore le module » — produit du code imprévisible et déborde de son périmètre. Un agent avec un contrat net — « ajoute la validation d’email dans ce service, avec ces tests » — reste dans les rails. Le découpage des tâches est le vrai travail de l’orchestrateur, comme nous l’avons vu pour l’orchestration multi-agents.

La synthèse humaine reste au centre

• Relire chaque worktree avant de fusionner — le diff d’un agent se vérifie, surtout sur la sécurité et les dépendances.
• Fusionner une tâche à la fois — pour isoler l’origine d’un problème et garder un historique lisible.
• Arbitrer les chevauchements — quand deux agents touchent une zone commune, c’est à l’humain de trancher l’intégration.
• Nettoyer les worktrees terminés — pour ne pas accumuler des branches et des répertoires fantômes.

Ce que ça change dans le quotidien

Le subagent-driven development déplace l’effort du développeur : moins de frappe, plus de conception de tâches et de revue. C’est un changement de posture qui déroute au début — on a l’impression de « moins coder » — mais qui décuple le débit quand il est maîtrisé. Il s’articule naturellement avec le spec-driven development : des spécifications claires en amont donnent aux sous-agents les contrats dont ils ont besoin pour travailler sans dériver.

Les pièges à éviter

Trois erreurs récurrentes. Sur-paralléliser : lancer dix agents sur une tâche qui n’en demande que deux crée plus de coût de synthèse que de gain. Sous-spécifier : des tâches floues produisent des diffs à jeter. Négliger la revue : fusionner sans relire, c’est importer directement la dette et les vulnérabilités du code généré. L’isolation technique ne remplace pas la discipline humaine — elle la rend possible.

Le subagent-driven development est une compétence d’équipe, pas un tour de magie. Découper, isoler, contractualiser, synthétiser : ces réflexes s’acquièrent et transforment le parallélisme en gain réel plutôt qu’en chaos. C’est précisément ce que nous travaillons en atelier — donner à une équipe les patterns concrets (worktrees, contrats de tâches, revue) pour exploiter les sous-agents sans exploser le codebase. La puissance est disponible ; encore faut-il la canaliser.

Sources : Subagent-driven development (Oakheart Lab), Claude Code Subagents and Orchestration Guide, Single-Agent vs Multi-Agent AI (Augment Code).