# Orchestration d’agents IA : 5 modèles et les outils

URL: https://agentvera.dev/fr/blog/ai-coding-agent-orchestration/ · Publié: 2026-10-28

Orchestration d’agents IA pour coder : orchestrateur et workers, lead avec liste de tâches, fan-out en worktrees, relais, best-of-N, et ce qui casse.

**En bref:**

- L’orchestration se résume à trois décisions : qui découpe le travail, comment les agents partagent l’état (retour, liste de tâches ou messages) et comment leurs changements se rejoignent (contexte, merge ou revue).
- Cinq modèles couvrent la plupart des cas : orchestrateur et workers, un lead avec liste de tâches partagée, fan-out en worktrees puis merge, relais en chaîne et tentatives best-of-N parmi lesquelles vous choisissez.
- La plupart des pannes sont des conflits, des coûts et de la dérive ; worktrees, propriété des fichiers, file de merge, budgets de tokens et superviseur des agents bloqués visent chacun l’une d’elles.

L’orchestration d’agents IA pour coder, c’est la façon de faire travailler plusieurs agents de code sur une même tâche sans qu’ils se marchent dessus. Chaque configuration répond à trois questions : **qui découpe le travail** (vous, un agent lead ou un planificateur), **comment les agents partagent l’état** (résultats renvoyés à l’appelant, liste de tâches partagée ou messages directs) et **comment leurs changements se rejoignent** (dans un seul contexte, par un git merge ou par une revue). Une fois ces trois choix faits, vous avez choisi votre modèle ; l’outil vient ensuite.

Cet article passe en revue les cinq modèles d’orchestration qui comptent pour les agents de code, ce qui tourne mal avec chacun et les outils qui les mettent en œuvre en octobre 2026 : sous-agents et équipes d’agents de Claude Code, Codex cloud, Conductor, Claude Squad, Vibe Kanban et AgentVera. AgentVera publie ce blog, nous disons donc aussi où les autres conviennent mieux. Les informations sur les outils tiers ont été vérifiées dans leur documentation ou leur dépôt.

Si vous cherchez plutôt un comparatif d’outils, lisez [les meilleurs outils pour agents de code IA en parallèle](/fr/blog/best-tools-parallel-ai-coding-agents/). Ici, on parle de l’architecture en dessous.

## Les trois décisions derrière chaque configuration

Avant les modèles, nommons les pièces mobiles :

- **Découpage :** qui transforme « ajouter la facturation » en tâches. Un humain qui découpe à la main est lent mais prévisible ; un agent planificateur est rapide mais peut couper au mauvais endroit.
- **État partagé :** comment l’agent B apprend ce qu’a fait l’agent A. Du plus strict au plus lâche : une valeur renvoyée à l’appelant, une liste de tâches partagée avec dépendances et des messages libres entre agents.
- **Intégration :** comment le code atterrit. Un travail en lecture seule renvoie du texte. Les agents qui écrivent partagent soit un dossier (risqué), soit travaillent dans des git worktrees séparés dont les branches sont fusionnées plus tard.

La plupart des bugs d’orchestration viennent d’un de ces points laissé implicite, par exemple deux agents qui pensent tous deux posséder le fichier du routeur.

## Cinq modèles d’orchestration

### 1. Orchestrateur et workers

Un agent garde la conversation et envoie des missions ciblées à des workers. Chaque worker démarre avec un contexte neuf, fait une seule chose et renvoie un résumé. L’appelant ne voit jamais la transcription complète du worker, seulement son résultat.

- **Bon pour :** la recherche, la recherche dans le code, la revue, l’analyse de tests. Tout ce où le worker lit beaucoup et rapporte peu.
- **Faible pour :** l’écriture en parallèle. Les workers modifient en général la même copie de travail que l’appelant.
- **Exemple :** [les sous-agents de Claude Code](/fr/blog/claude-code-subagents/).

### 2. Lead et coéquipiers avec liste de tâches partagée

Un agent lead crée des tâches avec dépendances ; les coéquipiers les prennent, les terminent et s’écrivent directement. L’état vit dans la liste de tâches, pas dans la tête d’un agent, si bien qu’un coéquipier peut prendre une tâche débloquée il y a une minute.

- **Bon pour :** un travail qui évolue en route, quand un testeur doit renvoyer un bug au développeur sans que vous serviez de relais.
- **Faible pour :** le coût et la sécurité des fichiers. Des coéquipiers dans un même dossier peuvent s’écraser mutuellement.
- **Exemple :** les équipes d’agents de Claude Code ; la messagerie entre agents et la liste de tâches d’AgentVera.

### 3. Fan-out en worktrees, puis merge

Un planificateur découpe un changement en parties indépendantes. Chaque partie tourne dans son propre worktree et sa branche, et les branches terminées sont fusionnées une à une dans une branche d’intégration, avec les tests à la fin.

- **Bon pour :** les gros changements aux parties séparables : API, interface, migration.
- **Faible pour :** les parties qui dépendent secrètement l’une de l’autre. Le conflit apparaît au merge, pas à l’édition.
- **Exemple :** Conductor, Claude Squad et Vibe Kanban fournissent les worktrees ; l’équipe parallèle d’AgentVera ajoute le planificateur et le merge. Contexte dans [git worktrees pour agents en parallèle](/fr/blog/git-worktree-parallel-agents/).

### 4. Relais en chaîne

Le planificateur passe la main à l’implémenteur, l’implémenteur au relecteur. Chaque étape reçoit la sortie de la précédente et rien d’autre. C’est la configuration planificateur-implémenteur-relecteur que la plupart des gens essaient en premier.

- **Bon pour :** les tâches récurrentes où vous voulez lire le plan avant qu’une ligne de code soit écrite.
- **Faible pour :** la vitesse. Rien ne tourne en parallèle, et un relais flou gâche toutes les étapes suivantes.
- **Exemple :** traité en détail dans [les workflows d’agents IA](/fr/blog/ai-agent-workflow-pipeline/) et [les équipes d’agents IA](/fr/blog/ai-agent-team/).

### 5. Best-of-N

La même tâche part vers plusieurs tentatives, et vous ou un agent relecteur gardez la meilleure. Aucune coordination, et c’est tout l’intérêt.

- **Bon pour :** les bugs coriaces et le travail d’interface flou, où la première réponse est rarement la meilleure.
- **Faible pour :** le coût, environ N fois les tokens, plus le temps de revue.
- **Exemple :** `codex cloud exec --attempts`, ou deux CLI différentes avec le même prompt dans des worktrees séparés.

### Les modèles côte à côte

| Modèle | Qui découpe | État partagé | Comment le code atterrit | Risque principal |
| --- | --- | --- | --- | --- |
| Orchestrateur et workers | L’agent appelant | Résultats renvoyés à l’appelant | La copie de l’appelant | Workers qui modifient ses fichiers |
| Lead et liste de tâches | Agent lead | Liste de tâches et messages | Souvent un seul dossier | Écrasements, coût en tokens |
| Fan-out et merge | Planificateur ou vous | Plan écrit à l’avance | Branches fusionnées avec un contrôle | Conflits tardifs |
| Chaîne de relais | Vous, à la conception | La sortie de l’étape précédente | La branche de la dernière étape | Lenteur, relais flous |
| Best-of-N | Personne | Aucun | Vous choisissez un diff | N fois le coût |

## Ce qui tourne mal, et le remède

### Conflits

Deux agents dans un même dossier finiront par modifier le même fichier. Les remèdes s’empilent : un worktree par agent qui écrit, un découpage par dossier plutôt que par fonctionnalité, une propriété des fichiers explicite, et des merges un par un sur la dernière pointe pour que le second voie le premier. Une file de merge, c’est cette dernière étape faite proprement.

### Coût

Chaque agent relit le code dont il a besoin, et chaque message entre agents coûte des tokens. La doc d’Anthropic indique que les équipes d’agents consomment nettement plus de tokens qu’une session seule et conseille de commencer avec 3 à 5 coéquipiers. Limitez le nombre d’agents, donnez aux workers un modèle moins cher quand la doc le permet et fixez un plafond par agent pour qu’une boucle ne brûle pas le budget de la journée.

### Dérive et boucles

Un agent peut s’écarter du plan, relancer la même commande en échec pendant vingt minutes, ou deux agents peuvent se poser la même question en boucle. Des critères d’acceptation clairs par tâche, un signal explicite « terminé » ou « bloqué », des limites de messages et un veilleur qui repère les commandes répétées en attrapent l’essentiel.

### Confiance entre agents

Quand les agents peuvent s’écrire, un message d’un autre agent n’est pas un message de vous. Traitez-le comme une information, pas comme une permission : un agent ne doit pas supprimer une branche ni pousser sur main parce qu’un pair le lui demande.

## Les outils, rangés par modèle

### Sous-agents de Claude Code (orchestrateur et workers)

Les sous-agents sont des fichiers Markdown avec frontmatter YAML dans `.claude/agents/` (projet) ou `~/.claude/agents/` (utilisateur). Chacun tourne dans sa propre fenêtre de contexte et renvoie son résultat à l’appelant ; sa consommation compte dans les mêmes limites. On peut les restreindre avec `tools` ou `disallowedTools` et choisir un `model`. En octobre 2026, les sous-agents peuvent lancer leurs propres sous-agents jusqu’à trois niveaux par défaut, réglé par `CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH` (mettez 1 pour désactiver l’imbrication).

```markdown
---
name: test-triager
description: Lance les tests en échec et rapporte la cause racine. À utiliser après une CI rouge.
tools: Read, Grep, Glob, Bash
model: sonnet
---
Lance les tests en échec, trouve la première vraie erreur et indique fichier, ligne et cause en moins de 15 lignes. Ne modifie aucun fichier.
```

### Équipes d’agents de Claude Code (lead et liste de tâches)

Les équipes d’agents sont expérimentales et désactivées par défaut en octobre 2026. Une session joue le lead ; chaque coéquipier est une instance Claude Code à part, avec son propre contexte. Ils partagent une liste de tâches avec les états en attente, en cours et terminée, plus des dépendances, prennent des tâches d’eux-mêmes et s’écrivent directement. On l’active dans `settings.json` :

```json
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}
```

Les coéquipiers s’affichent in-process par défaut, ou en volets séparés avec tmux ou iTerm2. La doc liste de vraies limites : pas de reprise de session pour les coéquipiers in-process, un statut de tâche qui peut être en retard, une seule équipe par session, pas d’équipes imbriquées et un lead fixe. Elle prévient aussi que deux coéquipiers sur le même fichier s’écrasent : découpez par fichier. Les hooks `TeammateIdle`, `TaskCreated` et `TaskCompleted` permettent d’imposer des règles ; le code de sortie 2 bloque l’action.

### Codex cloud (fan-out et best-of-N, à distance)

Codex cloud exécute des tâches dans un environnement cloud que vous configurez, chacune dans son propre espace de travail, et continue pendant que votre portable dort. Vous relisez le diff, demandez des ajustements, puis ouvrez une PR ou l’appliquez en local. La commande `codex cloud` est marquée expérimentale en octobre 2026 :

```bash
codex cloud exec --env ENV_ID --attempts 3 "Corrige le test de dates instable dans billing/"
codex cloud list --env ENV_ID
codex apply TASK_ID   # applique le diff en local ; code de sortie non nul si git apply échoue
```

`--attempts` accepte de 1 à 4 et c’est le best-of-N le plus simple qui soit. Codex cloud est le meilleur choix quand vous voulez sortir le travail de votre machine ; il ne fait tourner que Codex.

### Conductor (fan-out, Mac)

Conductor fait tourner Claude Code, Codex, Cursor et OpenCode en parallèle, chaque tâche dans son propre espace de travail avec sa branche, son terminal et son diff, puis revue, PR, merge et archivage. Il ne fonctionne que sur Mac. Offres en octobre 2026 : Free, Pro à 50 $ par mois et Teams à 60 $ par utilisateur et par mois. Si toute votre équipe est sur macOS et que vous voulez une interface de fan-out soignée, c’est un choix solide.

### Claude Squad (fan-out, terminal)

Claude Squad est une interface en terminal qui fait tourner Claude Code, Codex, Gemini, Aider, OpenCode ou Amp dans des worktrees séparés sous tmux. Il est sous licence AGPL-3.0 et requiert tmux et la CLI GitHub ; sous Windows, il tourne dans WSL.

```bash
brew install claude-squad
cs              # Claude Code par défaut
cs -p "codex"   # un autre agent
```

`n` ouvre une session, `Entrée` s’y attache, `Ctrl-q` s’en détache et `s` commit et pousse. Si vous vivez dans le terminal, c’est l’option la plus légère.

### Vibe Kanban (fan-out, tableau)

Vibe Kanban transforme les tâches en cartes, et chaque carte reçoit un espace de travail avec sa branche, son terminal et son serveur de dev ; les commentaires sur le diff repartent vers l’agent, qui peut ouvrir des PR. Il prend en charge Claude Code, Codex, Gemini CLI, Copilot, Amp, Cursor, OpenCode, Droid, CCR et Qwen Code. Son README annonce désormais l’arrêt du projet : en octobre 2026, considérez-le comme maintenu par la communauté (Apache-2.0, `npx vibe-kanban`).

### AgentVera (les cinq, en local)

AgentVera est une application de bureau pour macOS, Windows et Linux qui fait tourner de nombreuses CLI de code côte à côte ; elle peut donc accueillir chaque modèle plutôt qu’un seul :

- **Orchestrateur et workers :** avec les agents qui ouvrent des agents (activé par défaut), un agent lance des assistants via les outils `spawn_agent`, `wait_agent`, `agent_status`, `message_agent` et `stop_agent`. Un assistant peut être n’importe quelle CLI installée, peut travailler dans son propre worktree sur une branche `oto/…` et apparaît sous son parent. Par défaut, chaque agent peut ouvrir 3 assistants et 6 au total peuvent tourner ; les assistants ne peuvent pas ouvrir d’agents eux-mêmes.
- **Lead et liste de tâches :** la messagerie entre agents donne à chaque agent `send_message`, `reply_message`, `wait_reply` et une liste de tâches partagée (`task_add` avec responsable et dépendances, `task_claim`, `task_done`, `task_release`). Quand les dépendances d’une tâche sont terminées, elle devient prête et son responsable est prévenu. Cela marche entre CLI différentes : Claude Code peut confier une tâche à Codex.
- **Fan-out et merge :** une [équipe parallèle](/fr/features/parallel-team/) (offres Pro et Team) découpe un travail en 8 parties au plus, chacune avec des critères d’acceptation et les fichiers attendus, les exécute dans leurs propres worktrees, 3 à la fois par défaut et 6 au maximum, puis les fusionne dans une branche d’intégration. Le contrôle est la commande de tests du projet ; un agent d’intégration corrige conflits et échecs, et l’équipe s’arrête si le contrôle reste rouge après deux tours de correction.
- **Garde-fous contre chaque panne :** la propriété des fichiers refuse par un hook les modifications de Claude Code hors des chemins d’un propriétaire ; la file de merge fusionne une branche à la fois sur la dernière pointe ; les budgets de tokens (désactivés par défaut) plafonnent un agent par tour et par jour ; et le superviseur signale l’agent qui répète la même commande 5 fois en 15 minutes, reçoit la même erreur 3 tours de suite ou passe 20 minutes sans modifier un fichier.

Ces fonctions sont uniquement locales : les assistants ouverts par des agents et la messagerie ne couvrent pas les agents en SSH. Si vous voulez que les tâches continuent dans le cloud portable fermé, Codex cloud convient mieux.

## Comment choisir un modèle

1. **Le travail est-il surtout de la lecture ?** Orchestrateur et workers. Les sous-agents suffisent.
2. **Plusieurs agents doivent-ils écrire du code en même temps ?** Fan-out en worktrees avec une étape de merge. Pas de dossier partagé.
3. **Les tâches changent-elles à mesure que vous apprenez ?** Un lead avec liste de tâches partagée, et 3 à 5 agents.
4. **Lancez-vous la même tâche chaque semaine ?** Une chaîne de relais avec une validation avant l’étape de code.
5. **Le problème est-il dur et la réponse incertaine ?** Best-of-N, en payant en connaissance de cause.

Choisissez ensuite l’outil selon la plateforme : Conductor uniquement sur Mac, Claude Squad si vous voulez un terminal, Codex cloud si le travail doit tourner à distance, AgentVera si vous voulez plusieurs CLI et modèles dans une application de bureau sur n’importe quel système.

## Une petite orchestration à essayer aujourd’hui

Le plus petit fan-out utile ne demande que git et deux CLI :

```bash
git worktree add ../app-api -b feat/api
git worktree add ../app-ui -b feat/ui
(cd ../app-api && claude "Ajoute l'endpoint /invoices. Ne touche qu'à src/api/.")
(cd ../app-ui && codex "Construis la page des factures selon le contrat /invoices. Ne touche qu'à src/ui/.")
git checkout -b integrate/invoices
git merge feat/api && npm test
git merge feat/ui && npm test
```

Les règles qui font marcher le tout sont dans les prompts : un dossier par agent, un contrat convenu entre eux et un passage des tests après chaque merge. Tout ce qu’un outil ajoute par-dessus (planification, listes de tâches, superviseur, file) automatise l’une de ces lignes. Pour aller plus loin avec Claude Code et Codex côte à côte, voyez [agents de code en parallèle](/fr/blog/parallel-coding-agents/).

## En résumé

L’orchestration d’agents IA pour coder tient moins à l’outil qu’à trois choix : qui découpe le travail, où vit l’état partagé et comment le code atterrit. Orchestrateur et workers convient à la lecture, une liste de tâches au travail qui évolue, le fan-out avec merge aux gros changements séparables, les chaînes de relais aux tâches récurrentes et le best-of-N aux problèmes difficiles. Quel que soit votre choix, mettez des garde-fous contre les conflits, les coûts et la dérive dès le premier jour.

Pour essayer plusieurs modèles au même endroit, [téléchargez AgentVera](/fr/download/) et commencez avec deux agents et une liste de tâches partagée avant d’activer une équipe parallèle.

## Questions fréquentes

**Qu’est-ce que l’orchestration d’agents IA pour coder ?** C’est la couche qui coordonne plusieurs agents de code sur une même tâche : quelque chose découpe le travail, les agents partagent l’état via des valeurs renvoyées, une liste de tâches ou des messages, et leurs changements sont combinés par un merge ou une revue au lieu de se percuter dans un dossier.

**Par quel modèle d’orchestration commencer ?** Commencez par orchestrateur et workers, comme les sous-agents de Claude Code, pour la recherche et la revue dans une session. Passez au fan-out en git worktrees quand plusieurs agents doivent écrire du code en même temps, et ajoutez une étape de merge avec les tests à la fin.

**Les équipes d’agents de Claude Code sont-elles prêtes pour la production ?** En octobre 2026, elles sont expérimentales et désactivées par défaut. On les active avec le réglage CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, et la doc cite des limites comme l’absence de reprise de session pour les coéquipiers in-process et une seule équipe par session.

**Pourquoi l’orchestration multi-agents coûte-t-elle autant ?** Chaque agent a sa propre fenêtre de contexte et relit le code dont il a besoin. Les messages de coordination ajoutent des tokens. La doc d’Anthropic indique que les équipes d’agents consomment nettement plus de tokens qu’une session seule : gardez les équipes petites et plafonnez la dépense par agent.

**Comment empêcher deux agents de modifier le même fichier ?** Donnez à chaque agent qui écrit son propre git worktree et sa branche, découpez le travail par dossier et fusionnez les branches une à une, avec les tests lancés sur le résultat fusionné. Des règles de propriété des fichiers peuvent aussi refuser les modifications hors des chemins d’un agent.

---

**À propos d’AgentVera.** AgentVera est une app de bureau pour macOS, Windows et Linux, développée par Solviera Teknoloji. Elle exécute 18 agents de code IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) côte à côte, par projet, dans de vrais terminaux avec les installations et connexions CLI de l’utilisateur. L’offre gratuite inclut des agents illimités. Télécharger: https://agentvera.dev/fr/download/ · Tarifs: https://agentvera.dev/fr/pricing/