Sous-agents IA : définition, architecture orchestrateur/travailleurs et cas d'usage PME

Un sous-agent IA est un agent spécialisé qu'un agent principal (le superviseur) appelle comme un outil pour traiter une sous-tâche précise, puis dont il reprend le résultat pour continuer. C'est le motif le plus simple et le plus utilisé en multi-agent — et selon LangChain et Anthropic, c'est aussi celui par lequel toute équipe devrait commencer.

Pourquoi cela intéresse une PME ? Parce qu'un seul agent qui "sait tout faire" devient vite illisible, coûteux en tokens et difficile à maintenir. La décomposition en sous-agents spécialisés (un pour le CRM, un pour les documents, un pour les emails) rend le système plus fiable, plus auditable et plus évolutif. Cet article explique le motif en détail, compare les architectures équivalentes (subagents, skills, handoffs, router) documentées par LangChain, et donne des cas d'usage concrets pour les PME. C'est un approfondissement de notre définition de l'agent IA ; pour les systèmes multi-agents complets, voir notre article dédié.

TL;DR

• Un sous-agent est un agent travailleur piloté par un agent superviseur, isolé dans son propre contexte.
• Le motif orchestrateur/travailleurs (subagents) est le plus simple et le plus recommandé pour démarrer.
• Il existe quatre grandes familles d'architecture multi-agent (subagents, skills, handoffs, router) — chacune avec ses cas d'usage.
• Pour les PME : commencez par un agent unique avec de bons outils, ajoutez des sous-agents seulement quand un contexte unique devient trop chargé.
• La règle d'or (LangChain, Anthropic) : "start with a single agent, add tools before adding agents."

Le problème que les sous-agents résolvent

La documentation de LangChain (*Choosing the Right Multi-Agent Architecture*) identifie deux contraintes qui rendent un agent unique insuffisant à mesure qu'il grossit :

1. Gestion du contexte. Quand un agent doit connaître le CRM, la documentation produit, les procédures RH et la base support, son prompt devient énorme. Même avec des fenêtres de contexte larges, la latence augmente et la qualité baisse : le modèle "se noie" dans un contexte trop riche. Les sous-agents permettent de ne charger le contexte spécialisé que quand il est nécessaire.

1. Développement distribué. Plusieurs équipes (ventes, support, RH) veulent faire évoluer leurs compétences sans marcher les unes sur les autres. Un monolithe rend cela impossible ; des sous-agents séparés donnent à chaque équipe son périmètre.

Les sous-agents répondent à ces deux contraintes en isolant le contexte : chaque sous-agent a son propre prompt, ses propres outils, et ne "voit" que ce qui le concerne.

Le motif orchestrateur/travailleurs (subagents)

C'est l'architecture de référence. Un agent superviseur (orchestrateur) reçoit la demande de l'utilisateur, décide quels sous-agents appeler, leur passe les bonnes entrées, et recombine leurs résultats.

Comment ça marche, concrètement :

1. Le superviseur analyse la requête et la décompose.
2. Il appelle un ou plusieurs sous-agents (en parallèle si possible).
3. Chaque sous-agent exécute sa spécialité dans son propre contexte isolé.
4. Les résultats remontent au superviseur.
5. Le superviseur synthétise et répond (ou enchaîne avec d'autres sous-agents).

Propriété clé documentée par LangChain : les sous-agents sont sans état (stateless) — ils ne se souviennent pas des interactions passées. C'est volontaire : cela garantit une isolation forte du contexte, au prix d'un appel de modèle supplémentaire (les résultats doivent repasser par le superviseur).

Une donnée frappante

Anthropic a publié des résultats internes où une architecture multi-agents (Claude Opus 4 comme superviseur, Claude Sonnet 4 en sous-agents) surpassait un agent Claude Opus 4 unique de 90,2 % sur leurs évaluations de recherche internes. La raison : la distribution du travail sur des agents au contexte séparé permet un raisonnement parallèle qu'un agent unique ne peut pas atteindre. Ce chiffre est spécifique à la recherche à grand volume, mais il illustre le potentiel du motif quand le cas le justifie.

Les quatre familles d'architecture multi-agent

LangChain formalise quatre motifs. Les comprendre permet de choisir le bon pour chaque cas PME.

1. Subagents (orchestrateur/travailleurs)

• Principe : un superviseur coordonne des sous-agents spécialisés.
• Idéal pour : plusieurs domaines distincts (agenda, email, CRM), besoin d'exécution parallèle, pas besoin que les sous-agents parlent directement à l'utilisateur.
• Trade-off : ajoute un appel modèle par interaction (coût + latence), mais offre contrôle centralisé et isolation.

2. Skills (révélation progressive)

• Principe : techniquement un seul agent, mais il charge des "compétences" (prompts + scripts + ressources) à la demande.
• Idéal pour : un agent avec beaucoup de spécialisations possibles, où l'on n'a pas besoin d'imposer de contraintes entre compétences. Agents de code, assistants créatifs.
• Trade-off : le contexte s'accumule dans la conversation au fur et à mesure que les skills sont chargées → risque de "token bloat".

3. Handoffs (transitions pilotées par l'état)

• Principe : l'agent actif change dynamiquement selon le contexte. Chaque agent peut transférer vers un autre via un appel d'outil.
• Idéal pour : flux support qui collectent l'information par étapes, expériences conversationnelles multi-étapes.
• Trade-off : plus étatique, exige une gestion d'état soignée.

4. Router (dispatch parallèle et synthèse)

• Principe : une étape de routage classifie l'entrée et la dirige vers des agents spécialisés, exécutés en parallèle, puis synthétise.
• Idéal pour : domaines verticaux distincts, requêtes sur plusieurs sources en parallèle, synthèse multi-agents.
• Trade-off : sans état → performances stables par requête, mais surcharge de routage si on a besoin d'historique.

Tableau de décision (adapté de LangChain)

Et un tableau de capacités, d'après LangChain :

Performance réelle : latence, coût, tokens

LangChain a publié une analyse comparative sur trois scénarios représentatifs. Les enseignements pour les PME :

Requête unique ("acheter un café") : Skills, Handoffs et Router font 3 appels modèle ; Subagents en fait 4 (résultat repasse par le superviseur). Sur une tâche simple, le motif subagents est donc le plus cher.

Requête répétée : les motifs étatiques (Skills, Handoffs) économisent 40 à 50 % d'appels sur la seconde requête en conservant le contexte. Subagents reste à coût constant.

Requête multi-domaines (comparer trois sujets en parallèle) : Subagents et Router sont les plus efficaces en tokens. Subagents traite 67 % de tokens en moins que Skills grâce à l'isolation du contexte. C'est ici que l'architecture sous-agents brille.

Conclusion pour la décision : si vos tâches sont multi-domaines et volumineuses, les sous-agents payent leur surcoût. Si vos tâches sont simples et répétitives, restez sur un agent unique.

Les cas d'usage concrets pour les PME

Plutôt qu'une liste abstraite, voici cinq cas où l'architecture sous-agents apporte une valeur mesurable.

Cas 1 — Assistant interne multi-domaines

Un agent superviseur reçoit les questions des employés et route vers :

• un sous-agent RH (congés, paie, procédures)
• un sous-agent IT (accès, mot de passe, logiciels)
• un sous-agent documentation produit (specs, prix, processus)

Chacun a son propre corpus et ses outils. Le superviseur synthétise. Bénéfice : contexte maîtrisé, chaque équipe met à jour sa skill sans toucher aux autres. Voir Assistant IA interne.

Cas 2 — Support client avec escalade

Un agent superviseur classifie le ticket et appelle :

• un sous-agent consultation commande (statut, livraison)
• un sous-agent base de connaissances (FAQ, procédures)
• un sous-agent rédaction de réponse (ton, langue)

Si la confiance est faible, le superviseur escalade vers un humain. Voir Support client IA.

Cas 3 — Traitement documentaire finance/RH

Pour une demande de remboursement de notes de frais :

• un sous-agent extraction lit le reçu
• un sous-agent vérification politique compare aux règles
• un sous-agent comptabilisation crée l'écriture

Le superviseur orchestre et garde la trace. Voir IA pour la finance.

Cas 4 — Qualification commerciale

Un agent superviseur analyse un lead entrant et appelle :

• un sous-agent enrichissement (données publiques, web)
• un sous-agent scoring (modèle de propension)
• un sous-agent rédaction message (personnalisé)

Voir IA pour les ventes.

Cas 5 — Reporting automatisé multi-sources

Le superviseur demande à plusieurs sous-agents de récupérer des données (CRM, ERP, support) en parallèle, puis synthétise un rapport hebdomadaire. Voir Automatisation IA.

Anatomy d'un sous-agent : ce qu'il contient

Pour bien comprendre, regardons ce qu'il y a concrètement dans un sous-agent bien conçu. Chaque sous-agent est une petite "personne virtuelle" avec :

• Un prompt système : son rôle, son périmètre, ce qu'il peut et ne peut pas faire. Exemple : "Tu es l'agent RH. Tu réponds aux questions sur les congés, la paie et les procédures internes. Tu n'as pas accès aux données commerciales."
• Des outils : les fonctions qu'il peut appeler. Le sous-agent RH aura accès à l'API congés mais pas à l'API comptabilité.
• Un contexte spécialisé : la documentation, les règles métier, les exemples pertinents pour son domaine.
• Une contrainte de sortie : le format attendu de sa réponse pour que le superviseur puisse la consommer (JSON structuré, résumé court, etc.).

L'isolation est la clé : un sous-agent ne doit pas "voir" le contexte des autres. C'est cette isolation qui rend le système modulaire et auditable.

Pseudo-code d'une orchestration sous-agents

Voici à quoi ressemble la logique d'un superviseur qui appelle des sous-agents :

``` fonction traiter(demande_utilisateur): intention = classifier(demande_utilisateur)

si intention == "RH": resultat = appeler_sous_agent("RH", demande_utilisateur) sinon si intention == "IT": resultat = appeler_sous_agent("IT", demande_utilisateur) sinon si intention == "mixte": # parallèle : deux sous-agents en même temps [rh, it] = attendre_tous([ appeler_sous_agent_async("RH", demande_utilisateur), appeler_sous_agent_async("IT", demande_utilisateur) ]) resultat = synthetiser(rh, it)

# garde-fou : escalader si confiance faible si confiance(resultat) < seuil: return escalader_vers_humain(demande_utilisateur, resultat)

return formater_reponse(resultat) ```

Ce schéma illustre les trois propriétés essentielles : classification, appel (parallèle si besoin), et escalade. C'est l'ossature de tout système sous-agents en production.

Le coût caché : la supervision

Un point souvent négligé : le superviseur lui-même consomme des ressources. Plus le nombre de sous-agents grandit, plus le superviseur doit "réfléchir" pour choisir qui appeler. Au-delà de 7 à 10 sous-agents, le superviseur devient un goulot d'étranglement et peut faire de mauvais choix de routage.

La solution courante est la hiérarchie : un superviseur de superviseurs. Le superviseur de premier niveau route vers des "chefs de domaine" (RH, IT, commercial), qui eux-mêmes orchestrent des sous-agents spécialisés. Mais cette hiérarchie ajoute de la latence et de la complexité de debug. C'est pourquoi il faut résister à la tentation de tout démultiplier.

Quand les sous-agents dépassent leurs limites : passer au multi-agent

Les sous-agents sont une forme simple de multi-agent. Quand les besoins grandissent (communication directe entre agents, topologies complexes, protocoles inter-fournisseurs), on entre dans le territoire des systèmes multi-agents à part entière, avec leurs propres motifs (mesh, swarm, handoffs). Le sous-agent est l'étage d'entrée ; le multi-agent avancé est l'étage supérieur, à réserver aux cas qui le justifient.

La question du modèle : faut-il le même LLM partout ?

Un point de design important : faut-il utiliser le même modèle pour le superviseur et les sous-agents ? La réponse court-termiste est "oui, c'est plus simple". La réponse optimisée est "non, on adapte".

• Le superviseur fait du raisonnement stratégique (décomposition, choix de routage, synthèse). Il mérite un modèle fort (un modèle frontier type Claude Opus, GPT de haut niveau, ou un modèle open source équivalent).
• Les sous-agents font des tâches souvent plus ciblées (extraction, classification, rédaction d'un message). Un modèle plus léger (Claude Haiku/Sonnet, GPT mini, un modèle open source petit) suffit et coûte 5 à 10 fois moins cher.

Cette approche asymétrique est documentée par Anthropic comme l'une des sources principales d'économie sans perte de qualité. Sur un volume élevé, la différence de coût est considérable. Voir Budget agent IA PME pour le détail des arbitrages.

Surveiller et améliorer un système sous-agents

Une fois en production, trois métriques méritent une attention particulière :

1. Taux d'escalade : combien de requêtes remontent vers un humain ? Trop élevé = les sous-agents ne sont pas assez capables ; trop bas = ils prennent peut-être des risques. Une fourchette saine est souvent 10–25 % selon le domaine.
2. Qualité par sous-agent : mesurer séparément la qualité de chaque sous-agent, pas seulement du système global. Un sous-agent faible dégrade l'ensemble sans que ce soit visible dans la moyenne.
3. Coût par interaction : suivre l'évolution. Une dérive du coût signale souvent un sous-agent qui boucle ou un superviseur qui sur-route.

Ces métriques font partie de notre grille de 10 KPI pour mesurer le succès d'un agent IA.

Quand NE PAS utiliser de sous-agents

L'erreur classique : vouloir de la sophistication avant d'en avoir besoin. LangChain est explicite : *"Start with a single agent and good prompt engineering. Add tools before adding agents. Graduate to multi-agent patterns only when you hit clear limits."*

Ne passez aux sous-agents que si :

• le prompt unique devient illisible ou trop long
• plusieurs équipes doivent faire évoluer des compétences indépendamment
• vous avez besoin de parallélisme réel (plusieurs sources interrogées en même temps)
• le coût des tokens d'un agent monolithique devient prohibitif

Sinon, un agent unique avec des outils bien conçu reste supérieur en simplicité, traçabilité et coût.

Coûts et garde-fous spécifiques aux sous-agents

• Coût : chaque interaction dans un motif subagents coûte un appel supplémentaire. Sur un volume élevé, cela s'additionne. Voir Budget agent IA PME.
• Observabilité : il faut tracer non seulement le superviseur mais chaque sous-agent, sinon le debug devient un cauchemar.
• Sécurité : chaque sous-agent doit avoir accès uniquement aux outils de son périmètre. Un sous-agent RH ne doit pas pouvoir écrire dans la comptabilité. Voir Sécurité des agents IA.
• Limites de boucle : un superviseur peut entrer dans une boucle d'appels inter-sous-agents. Il faut un nombre maximal d'itérations et un budget maximal.

Frameworks et implémentation

Plusieurs frameworks implémentent ces motifs, ce qui évite de tout coder à la main :

• LangGraph (LangChain) : implémente subagents, handoffs, router avec gestion d'état. Documentation complète sur les motifs multi-agent.
• AutoGen (Microsoft) : motif conversationnel multi-agent, agents enchaînés, supervisés, avec réflexion et group chats.
• OpenAI Swarm / Agents SDK : motif léger d'orchestration par handoffs.
• Deep Agents : implémentation clé en main du motif subagents + skills.
• Claude Code subagents : implémentation intégrée pour le développement.

Le choix du framework importe moins que la clarté du motif choisi. Voir aussi Agents IA open source vs propriétaires.

FAQ

Sous-agent et agent, c'est pareil ? Techniquement oui (même architecture), mais conceptuellement un sous-agent est *au service* d'un superviseur, dans un périmètre réduit, sans interaction directe avec l'utilisateur final.

Combien de sous-agents maximum ? Il n'y a pas de chiffre magique. Au-delà de 5 à 7 sous-agents, la supervision devient complexe. Si vous en avez besoin de plus, c'est souvent le signe qu'il faut restructurer en plusieurs systèmes.

Les sous-agents parlent-ils entre eux ? Dans le motif subagents classique, non : ils ne parlent qu'au superviseur. Pour la communication directe entre pairs, il faut un motif mesh (plus complexe). Voir Systèmes multi-agents.

Faut-il un modèle différent par sous-agent ? Pas obligatoirement, mais c'est souvent pertinent : un modèle léger pour la classification, un modèle puissant pour la rédaction. C'est le principe du coût par cas.

Un sous-agent peut-il appeler un autre sous-agent ? Oui (multi-hop), mais cela ajoute de la complexité et de la latence. À réserver aux cas qui le justifient vraiment.

Pour aller plus loin

• Architecture multi-agent complète → Systèmes multi-agents
• La mémoire que gardent les agents → Mémoire des agents IA
• Déployer concrètement → Déploiement en 14 jours
• Cadrer votre premier cas → Demander un audit IA

Les sous-agents sont un outil d'architecture, pas une fin en soi. Mal utilisés, ils ajoutent de la complexité et du coût pour rien. Bien utilisés — quand le contexte d'un agent unique déborde — ils rendent le système plus fiable, plus modulaire et plus économique en tokens. La clé est de reconnaître le bon moment pour les introduire.