Subagent-driven development : déléguer pour scaler la qualité

TL;DR — Les agents IA peuvent exécuter des tâches de développement en parallèle, mais seulement si chaque agent travaille dans un contexte isolé. La technique : un worktree git par tâche, chaque agent reçoit un brief précis avec contraintes explicites, les outputs sont reviewés avant merge. Résultat : 3-5× plus de débit sur les tâches implémentables, avec une qualité contrôlée. Anti-pattern à éviter : un seul contexte partagé entre plusieurs tâches divergentes.

---

L’IA appliquée au développement logiciel ne ressemble pas à ce que la plupart des articles décrivent. Ce n’est pas “demander à Claude de coder à ta place”. C’est apprendre à décomposer un problème en sous-tâches implémentables, à briefer précisément, et à reviewer intelligemment.

Ce que j’appelle le subagent-driven development est une méthodologie concrète, pas un concept abstrait. Voici comment elle fonctionne sur un projet réel.

Le problème de la pollution de contexte

Quand on demande à un agent IA de faire plusieurs choses dans la même conversation, le contexte se pollue rapidement. Exemple typique :

Tour 1: "Implémente le composant Header"
Tour 2: "Maintenant le Footer"
Tour 3: "Ajoute l'internationalisation au Header"
Tour 4: "Le Footer devrait aussi être i18n"

Au Tour 4, l’agent a en mémoire les instructions parfois contradictoires des tours précédents, les décisions intermédiaires, et les corrections apportées. Le contexte devient bruité. La qualité des outputs se dégrade.

La solution : chaque tâche implémentable = un agent séparé dans un contexte propre.

Worktrees git comme mécanisme d’isolation

Un worktree git crée un répertoire de travail séparé associé à une branche différente, dans le même dépôt :

# Créer les worktrees pour chaque tâche parallèle
git worktree add .worktrees/task-header -b feat/header
git worktree add .worktrees/task-footer -b feat/footer
git worktree add .worktrees/task-i18n -b feat/i18n

Chaque worktree est un répertoire indépendant avec son propre working tree. Un agent travaille dans .worktrees/task-header sans jamais voir les fichiers modifiés dans .worktrees/task-footer.

# Structure résultante
repo/
├── .git/                    # Référentiel partagé
├── .worktrees/
│   ├── task-header/         # Agent A travaille ici
│   ├── task-footer/         # Agent B travaille ici
│   └── task-i18n/           # Agent C travaille ici
└── src/                     # Branche main (stable)

Quand les agents ont terminé, les branches sont mergeées comme n’importe quelle branche feature. S’il y a des conflits, ils sont résolus en un seul endroit — le merge — et non éparpillés dans plusieurs contextes d’agent.

Brief d’agent : ce qui fait la différence

La qualité du brief est le facteur déterminant. Un brief vague produit une implémentation vague. Un brief précis produit une implémentation précise et reviewable.

Structure d’un brief efficace :

# Brief Agent — [Nom de la tâche]

## Contexte
[Repo, stack, conventions existantes]

## Worktree
[Chemin absolu du worktree + nom de branche]

## Base commit
[Hash du commit de base — pour savoir d'où partir]

## Tâche
[Description précise et bornée de ce qu'il faut implémenter]

## Contraintes
- ❌ Ne pas toucher [fichiers hors scope]
- ✅ Utiliser [patterns existants spécifiques]
- ✅ Conventions de commit : [format attendu]

## Définition de "done"
[Critères vérifiables : build passe, tests passent, etc.]

## Rapport attendu
[Ce qu'on attend comme output à la fin]

La section “Contraintes” est la plus importante. Elle évite que l’agent “améliore” des fichiers qu’il ne devrait pas toucher, ou qu’il réinvente des patterns déjà définis.

Sélection du modèle : cheap vs capable

Toutes les tâches ne méritent pas le même niveau de modèle. Une taxonomie pratique :

Tâche	Modèle recommandé	Justification
Écriture d’articles, documentation	Capable (Sonnet/Opus)	Nuance + cohérence narrative
Implémentation features bien spécifiées	Capable	Contexte étendu, raisonnement
Corrections de bugs ciblées	Capable ou Haiku	Le brief suffit à guider
Formatage, renommage de masse	Haiku	Pas de raisonnement requis
Review de code, détection de patterns	Capable	Patterns implicites à détecter

La règle : utiliser le modèle le moins cher qui donne un résultat acceptable pour la tâche. Sur un projet avec 20 tâches parallèles, le choix de modèle a un impact direct sur le coût.

TDD avec des subagents

Le TDD (Test-Driven Development) s’adapte naturellement au subagent-driven development. Le flux :

Étape 1 : Écrire les tests d’abord (humain ou agent)

// tests/blog.test.ts — écrit AVANT l'implémentation
import { describe, expect, it } from 'vitest';
import { glob } from 'glob';
import matter from 'gray-matter';
import { readFileSync } from 'fs';

describe('Blog articles schema validation', () => {
  const articlePaths = glob.sync('src/content/blog/fr/*.mdx');

  it('should have at least 5 articles', () => {
    expect(articlePaths.length).toBeGreaterThanOrEqual(5);
  });

  for (const articlePath of articlePaths) {
    it(`${articlePath} — has valid frontmatter`, () => {
      const raw = readFileSync(articlePath, 'utf-8');
      const { data } = matter(raw);

      expect(data.title).toBeTruthy();
      expect(data.description).toBeTruthy();
      expect(data.date).toMatch(/^\d{4}-\d{2}-\d{2}$/);
      expect(data.tags).toBeInstanceOf(Array);
      expect(data.readingMinutes).toBeGreaterThanOrEqual(1);
    });
  }
});

Étape 2 : Brief l’agent implémenteur avec les tests comme spécification

Les tests deviennent la définition de “done”. L’agent sait exactement ce qu’il doit produire pour passer CI.

Étape 3 : Review diff, pas conversation

La review d’un agent se fait sur le diff git, pas dans la conversation. Ouvrir le PR, regarder les fichiers modifiés, vérifier que les contraintes ont été respectées.

L’erreur classique : reviewé la conversation de l’agent pour juger la qualité de son output. Ce qui compte c’est le code produit, pas le raisonnement intermédiaire.

Anti-patterns documentés

Contexte partagé entre tâches divergentes — Deux tâches qui modifient les mêmes fichiers dans le même contexte créent des conflits implicites dans la mémoire de l’agent.

Brief incomplet sur les conventions — “Utilise le style existant” est insuffisant. Pointer vers un fichier exemple spécifique : “Utilise le même pattern que src/pages/demos/[...slug].astro pour la page de détail.”

Pas de définition de done — Un agent qui n’a pas de critère clair de terminaison va soit s’arrêter trop tôt (tâche incomplète), soit sur-implémenter (features non demandées).

Reviewer trop tard — Si on laisse un agent travailler 30 minutes avant de regarder sa direction, le coût d’un revert est élevé. Checkpoint intermédiaire à ~25% d’avancement.

Métriques réelles sur ce projet

Sur la construction de ce portfolio (8 plans, ~126 commits) :

• Tâches exécutées en parallèle : jusqu’à 3 simultanées
• Ratio review/implémentation : ~1h de review pour 3-4h d’implémentation agent
• Taux de revert complet (agent ayant tout faux) : ~10%
• Économie de temps estimée vs implémentation solo : 2-3×

Le 10% de revert complet vient principalement de briefs insuffisants sur les conventions, pas d’une incapacité du modèle. Améliorable.

Pour aller plus loin

• Git Worktrees — documentation officielle
• Test-Driven Development (Kent Beck) — fondements du TDD
• Conventional Commits — convention de messages pour un historique lisible par des agents