Le multi-agents, c’est le buzzword que tout le monde colle sur une slide. C’est aussi là que Claude Code devient vraiment intéressant — quand on s’en sert chirurgicalement.

La forme qui marche : un petit pipeline de sub-agents bornés, chacun faisant une seule chose, avec un handoff explicite. La forme qui échoue : « essaim d’agents qui débattent de l’architecture ».

Soyons tactiques.

Les trois patterns qui livrent vraiment

1. Pipeline linéaire (le pain quotidien)

test-writer  →  test-fixer  →  code-reviewer  →  release-bot

Chaque étape a une entrée et une sortie. Les échecs stoppent le pipeline. C’est 80 % de ce que les équipes utilisent.

2. Fan-out / fan-in

Quand une tâche est naturellement parallèle — traduire 5 fichiers, générer des tests pour 12 modules, scanner les logs de 8 services — éclatez-la.

            ┌─ translator(es) ─┐
            ├─ translator(fr) ─┤
spawner ──> ├─ translator(ar) ─┤── merger
            ├─ translator(pt) ─┤
            └─ translator(de) ─┘

Vous lancez N sub-agents spécialisés en parallèle, puis un sub-agent merger réconcilie les sorties (déduplique, choisit la variante la plus confiante, écrit une seule PR).

3. Boucle de critique

writer  ↔  critic

Le writer produit. Le critic note selon une rubrique. Le writer révise. On s’arrête quand le critic dépasse un seuil ou après N rounds.

Ce pattern brille pour :

• Les réécritures de docs.
• Les plans de migration.
• Les propositions de refactor où « est-ce propre ? » est le gate.

Le critic doit être un sub-agent différent du writer. Un même agent qui s’auto-critique, c’est du théâtre.

Là où le multi-agents arrête de payer

Après un an, voici mon avis honnête sur les rendements décroissants :

• 2 agents : grand bond. Writer + reviewer est un vrai gain.
• 3-4 agents : utile pour des pipelines clairs (test-writer → fixer → reviewer).
• 5+ agents : marginal au mieux. Coût de coordination > gain de délégation.
• « Essaim de 10 agents qui débattent » : une démo, pas un workflow.

Si votre pipeline a plus de 4 sub-agents, demandez-vous si la moitié d’entre eux ne pourraient pas être de simples commandes shell ou des cibles Makefile.

Concrètement : un pipeline « PR factory »

Objectif : prendre un ticket Linear, livrer une PR.

1. ticket-reader     → parse le ticket Linear, sort un prompt /feature
2. implementer       → écrit le code
3. test-writer       → écrit / met à jour les tests
4. test-fixer        → si un test échoue, corrige le code (pas le test)
5. code-reviewer     → review le diff, soit SHIP / FIX-FIRST / REWRITE
6. release-bot       → rédige la description de PR + entrée de changelog
7. (humain)          → relit le diff et pousse

Chaque étape est un sub-agent dans .claude/agents/. L’étape humaine à la fin n’est pas négociable — c’est là que git push se passe.

Temps d’exécution sur une feature typique : 4 à 12 minutes en wall clock. Review humaine à la fin : 5 à 15 minutes. Bout en bout : une feature à l’heure, soutenable.

Comment invoquer un pipeline en pratique

Deux saveurs.

Pas-à-pas manuel (recommandé au début)

> /agents implementer
> Objectif : ... Contraintes : ... DoD : ... Fichiers : ...

# attendre, relire

> /agents test-writer
> Écris des tests pour le nouveau code.

# attendre, relire

> /agents code-reviewer
> Review le diff.

Vous restez aux commandes. Lent mais sûr.

Orchestré via une slash command

.claude/commands/pr-factory.md :

1. Lance `implementer` avec l'objectif fourni par l'utilisateur.
2. Attends la fin. Si implementer échoue, abandonne.
3. Lance `test-writer` sur le diff.
4. Lance `test-fixer` jusqu'à ce que les tests passent ou 3 retries.
5. Lance `code-reviewer` sur le diff final.
6. Si verdict != SHIP, remonte à l'utilisateur et arrête.
7. Sinon lance `release-bot` pour la description de PR.
8. Imprime un résumé d'une ligne et arrête. Ne pousse jamais.

Puis :

> /pr-factory
> Objectif : <remplir> Contraintes : <remplir> DoD : <remplir> Fichiers : <remplir>

Vous tapez une seule commande. Le pipeline tourne. Le push reste une frappe humaine.

Patterns parallèles — quand les utiliser

Lancez des agents en parallèle quand :

• Le travail est indépendant (traduire 5 fichiers, résumer 8 PRs).
• Vous pouvez écrire un merger déterministe (concat, dedup, pick-highest-score).
• Vous pouvez budgéter le coût (parallèle = plus d’appels API, wall clock plus rapide).

Évitez le parallèle quand :

• Les tâches ont des dépendances (test-fixer a besoin du diff de l’implementer).
• L’étape de merge est floue (« quelle architecture préfère-t-on ? »). Ça n’est pas un merge — c’est une décision humaine.

Le truc le plus utile : les handoffs explicites

Chaque sub-agent termine son tour en émettant un handoff structuré :

status: ok | needs-human | failed
artifacts:
  - path: src/cache.ts
  - path: tests/cache.test.ts
notes: "LRU + TTL implémenté. Tous les tests verts."
next: test-writer | code-reviewer | done

L’agent suivant lit ce handoff et sait exactement où il en est. Pas de re-dérivation de contexte, pas de « attends, c’était quoi l’objectif déjà ? »

Standardiser le handoff est la chose à plus haut levier dès qu’on a 3+ sub-agents. C’est l’équivalent multi-agents d’une signature de fonction bien typée.

---

Article suivant : Construire des fonctionnalités complètes — prendre tout ce qu’on a vu dans les articles 3 à 7 et dérouler une session ticket-vers-PR réelle, commande par commande.