Un agent unique avec vingt outils et un historique qui grandit à chaque tour finit par se noyer dans son propre contexte : plus il en sait, moins il raisonne bien sur chaque décision précise. Le pattern orchestrateur/sous-agents répond à ce problème par la spécialisation plutôt que par l'accumulation.
Le principe
Un agent orchestrateur reçoit la tâche globale et délègue des sous-parties à des sous-agents isolés, chacun avec son propre contexte restreint et un set d'outils limité à sa spécialité. Le sous-agent revient avec un résultat condensé — pas avec tout son historique de travail. L'orchestrateur ne voit jamais le détail de comment le sous-agent est arrivé à sa réponse, seulement le résultat.
Pourquoi ça marche mieux qu'un agent monolithique
| Aspect | Agent unique | Orchestrateur + sous-agents |
|---|---|---|
| Pollution du contexte | Croît à chaque outil ajouté | Contenue — chaque sous-agent a un contexte propre |
| Spécialisation des instructions | Un seul prompt système généraliste | Un prompt système par spécialité (recherche, revue, exécution...) |
| Parallélisation | Séquentiel par nature | Plusieurs sous-agents peuvent tourner en parallèle |
| Coût / latence | Plus bas par tâche simple | Plus élevé — overhead de coordination |
| Debug | Un seul historique à lire | Plusieurs traces à corréler |
Un exemple concret
Claude Code illustre ce pattern directement : sur une tâche composite, il peut lancer un sous-agent dédié à l'exploration du code (lecture, recherche, sans capacité d'édition) qui revient avec un résumé ciblé, pendant que l'orchestrateur garde son propre contexte concentré sur la décision à prendre. Détail pratique dans Claude Code en pratique.
Quand ne pas s'en servir
Si la tâche tient dans un seul appel d'outil ou un raisonnement direct, ajouter un orchestrateur et des sous-agents n'apporte que de la latence et de la facture. Le réflexe reste le même qu'ailleurs sur ce blog : commencer par la question agent ou workflow, puis seulement si un agent est justifié, se demander s'il doit être unique ou orchestré. La boucle sous-jacente de chaque sous-agent suit d'ailleurs la même logique que n'importe quelle boucle agentique — condition d'arrêt stricte incluse.
FAQ
Un sous-agent est-il juste un agent avec moins d'outils ?
C'est une partie de la réponse, mais l'essentiel est le contexte isolé : le sous-agent ne voit pas l'historique complet de l'orchestrateur, et l'orchestrateur ne voit pas le détail du travail du sous-agent — seulement son résultat.
Combien de sous-agents faut-il prévoir ?
Autant que de spécialités distinctes et réellement nécessaires — un par spécialité générique et sur-utilisée (recherche, revue) plutôt qu'un par tâche ponctuelle, sous peine d'explosion de complexité de coordination.
Les sous-agents peuvent-ils tourner en parallèle ?
Oui, c'est un des bénéfices principaux du pattern par rapport à un agent monolithique nécessairement séquentiel — à condition que les sous-tâches soient réellement indépendantes.
