Workflows multi-agents avec Claude Code : le guide complet

Un seul agent Claude Code est puissant. Plusieurs agents orchestrés ensemble ? C'est une équipe de développement complète. Ce guide explore les patterns d'orchestration multi-agents.

Pourquoi le multi-agent ?

Les projets modernes impliquent des tâches parallélisables :

Frontend et backend en simultané
Tests et documentation en parallèle
Refactoring de plusieurs modules indépendants

Un seul agent traite ces tâches séquentiellement. Plusieurs agents les traitent en parallèle.

Les skills d'orchestration

Loki Mode — L'approche autonome

Score : 85/100 | Le plus ambitieux

Loki Mode prend un PRD (Product Requirements Document) et déploie le produit avec une intervention minimale. Il :

Analyse le PRD et découpe en tâches
Crée les agents spécialisés
Coordonne l'exécution
Gère les dépendances entre tâches
Déploie le résultat

Quand l'utiliser : Projets greenfield, prototypes, hackathons.

Prérequis : Le flag --dangerously-skip-permissions est requis (Loki Mode a besoin d'autonomie totale).

Gastown — L'orchestrateur modulaire

Score : 75/100 | Le plus flexible

Gastown utilise un vocabulaire unique (convoys, polecats, rigs) pour coordonner des agents :

Convoys : Groupes de tâches liées
Polecats : Agents spécialisés
Rigs : Configurations d'environnement
Beads : Unités de travail atomiques

Quand l'utiliser : Projets existants complexes nécessitant une orchestration fine.

Patterns d'orchestration

Pattern 1 : Fan-Out / Fan-In

Orchestrateur
  ├── Agent Frontend (composants React)
  ├── Agent Backend (API endpoints)
  ├── Agent Tests (E2E + unitaires)
  └── Agent Docs (README + API docs)

Chaque agent travaille indépendamment, l'orchestrateur agrège les résultats.

Pattern 2 : Pipeline séquentiel

Agent Analyse → Agent Implémentation → Agent Review → Agent Deploy

Chaque agent passe le contexte au suivant.

Pattern 3 : Spécialisation

Agent "Senior Dev" (architecture, code review)
Agent "Junior Dev" (implémentation, tests)
Agent "DevOps" (CI/CD, déploiement)
Agent "PM" (specs, documentation)

Chaque agent a un rôle et des skills différents.

Mise en pratique

Étape 1 : Définir les tâches parallélisables

Identifiez les tâches sans dépendances mutuelles. Exemple pour une feature CRUD :

✅ Parallélisable : schema DB + composants UI + tests
❌ Séquentiel : migration DB → API endpoint → intégration frontend

Étape 2 : Configurer les agents

Chaque agent a besoin de :

Un répertoire de travail isolé (git worktree)
Les skills appropriés à sa tâche
Un contexte clair (quoi faire, limites)

Étape 3 : Gérer les conflits

Le risque principal du multi-agent : les conflits de merge.

Solutions :

Répertoires de travail séparés (worktrees)
Découpage par fichier/module (pas de chevauchement)
Merge fréquent vers la branche principale

Limites et précautions

Coût : Chaque agent consomme des tokens. 4 agents = ~4x le coût.
Complexité : L'orchestration ajoute de la complexité. Ne multi-agentez pas un projet simple.
Conflits : Les agents peuvent produire du code incompatible. Les reviews sont essentielles.
Debugging : Tracer un bug à travers plusieurs agents est plus difficile.

Quand utiliser le multi-agent ?

Situation	Approche
Feature simple	1 agent suffit
Feature complexe, modules indépendants	Multi-agent
Prototype rapide	Loki Mode
Projet existant, refactoring large	Gastown
Équipe qui veut standardiser	Skills + 1 agent

Conclusion

Le multi-agent est un multiplicateur de force, pas une solution miracle. Utilisez-le quand les tâches sont vraiment parallélisables et que le gain de temps justifie la complexité ajoutée.