À retenir
- Un sous-agent est un agent délégué : l'agent principal garde le contexte global et répartit des tâches bornées sur des agents secondaires, chacun avec son contexte isolé.
- La parallélisation peut diviser les temps de traitement : plusieurs sous-agents travaillent en même temps, mais la latence totale ne baisse que si la décomposition est réellement indépendante.
- Les coûts baissent quand les rôles sont spécialisés : des modèles compacts 10 à 50 fois moins chers peuvent exécuter la majorité des sous-tâches (source : MindStudio).
- Le surcoût de coordination est réel : chaque interaction via l'orchestrateur ajoute un appel de modèle supplémentaire, et un workflow agentique consomme couramment 20 à 100 appels LLM par tâche.
- Ce guide vous donne le code : architecture orchestrateur-travailleurs, exemple Python complet, règle des trois conditions et pièges à éviter.
Vendredi, 17 h 42. Votre agent de support doit traiter une réclamation client, mettre à jour une base de connaissances et compiler un rapport hebdomadaire. Il fait tout — dans le désordre, avec un contexte qui déborde, et une latence qui fait fuir vos testeurs. Vous passez votre week-end à découper le prompt en « étapes ». Puis vous découvrez que l'OpenAI Agents API gère les sous-agents nativement, et vous vous demandez si ce n'est pas la solution. En partie, oui. Mais pas toujours — et c'est exactement ce que ce guide va trancher.
L'API Agents d'OpenAI, lancée en bêta publique en septembre 2026, met à disposition des développeurs le harnais et l'infrastructure qui propulsent Codex, avec une prise en charge multi-agent native (OpenAI). Derrière le terme marketing « sous-agents » se cache un choix d'architecture précis, avec des bénéfices mesurables et des limites tout aussi mesurables. Pour comprendre d'abord ce qui se joue, voir [LIEN_INTERNE: les fondamentaux des agents IA → /blog/fondamentaux-agents-ia]. Voici de quoi trancher en connaissance de cause.
Pourquoi les sous-agents méritent un guide dédié
Les pages officielles d'OpenAI mentionnent les sous-agents en un paragraphe : « permettez aux agents de paralléliser le travail avec des sous-agents ». Aucun détail d'implémentation, aucun chiffre, aucune condition d'usage. Les articles d'actualité (comme BDM) annoncent la fonctionnalité sans montrer de code. Et la recherche académique, elle, est formelle : les bénéfices des architectures multi-agents sont réels mais conditionnels.
Un sous-agent est un agent IA qui exécute une tâche spécifique et bornée au sein d'un système plus large, sous la direction d'un orchestrateur (MindStudio). L'orchestrateur gère la compréhension globale, la décomposition et la synthèse. Les sous-agents exécutent des étapes précises — extraction de données, classification, génération, appels d'outils, validation — sans avoir besoin de comprendre l'ensemble du workflow.
💡 Bon à savoir : Chaque interaction avec un sous-agent ajoute un appel de modèle supplémentaire pour le transit via l'orchestrateur. Un workflow à 20 nœuds, c'est 20 appels de coordination invisibles dans la facture — d'où l'importance de choisir des modèles compacts en exécution.
C'est l'analogie de l'orchestre : le chef ne joue pas de chaque instrument, il lit la partition, donne le tempo, et chaque musicien exécute sa partie. Si le chef devait jouer tous les instruments, la symphonie deviendrait une cacophonie — et c'est exactement ce qui arrive à votre agent unique surchargé de responsabilités.
Orchestrateur
Comprend la demande globale, décompose en sous-tâches, orchestre en parallèle, synthétise les résultats. C'est « le chef d'orchestre » qui décide.
Sous-agents
Exécutent une tâche bornée avec un contexte isolé : recherche, analyse, génération, résumés. Ils ne voient que leur partition.
Contextes séparés
Chaque sous-agent a sa propre fenêtre de contexte. L'orchestrateur ne transfère que les informations nécessaires, pas tout l'historique.
Exécution parallèle
Les sous-tâches indépendantes s'exécutent en parallèle. Le temps total dépend de la plus longue branche, pas de la somme des étapes.
Concrètement, dans l'API Agents, l'agent principal conserve son propre contexte et coordonne des sous-agents qui travaillent en parallèle pour accélérer les tâches de recherche, d'analyse et de programmation (OpenAI). L'orchestration manuelle — celle que vous faisiez le vendredi soir — disparaît.
Implémenter des sous-agents : le code qui tourne
Place à la pratique. L'OpenAI Agents SDK (Python) expose des primitives de haut niveau pour créer un agent superviseur et lui attacher des sous-agents via le paramètre handoffs ou tools. Le pattern le plus simple et le plus robuste est celui de l'orchestrateur-travailleurs : le superviseur appelle les sous-agents comme des outils, ils restent sans état, et l'isolation contextuelle est maximale (LangChain).
Pour choisir le modèle adapté à chaque sous-agent, consultez la gamme des modèles GPT de 2026.
Voici une architecture complète pour un assistant de veille financière : un agent principal, un sous-agent dédié à la recherche de marchés, un autre à la synthèse d'actualités.
from agents import Agent, Runner
import asyncio
# Sous-agent 1 : recherche de données marchés
market_analyst = Agent(
name="MarketAnalyst",
instructions="""Tu es analyste marchés. Extrais les cours,
variations et volumes à partir des sources fournies.
Réponds avec des chiffres précis et datés.""",
model="gpt-4.1-mini", # modèle compact pour une tâche bornée
)
# Sous-agent 2 : synthèse d'actualités
news_synthesizer = Agent(
name="NewsSynthesizer",
instructions="""Tu es journaliste financier. Résume les
actualités en 5 points factuels, avec sources et dates.
Ne produis aucun conseil d'investissement.""",
model="gpt-4.1-mini",
)
# Agent orchestrateur
supervisor = Agent(
name="Supervisor",
instructions="""Tu es le chef d'orchestre d'une veille financière.
1. Délègue la collecte des données à MarketAnalyst.
2. Délègue la synthèse des actualités à NewsSynthesizer.
3. Combine leurs résultats dans un rapport structuré.""",
tools=[market_analyst.as_tool(), news_synthesizer.as_tool()],
model="gpt-4.1",
)
async def main():
result = await Runner.run(
supervisor,
"Analyse la semaine boursière du CAC 40 "
"et résume les 3 actualités majeures."
)
print(result.final_output)
asyncio.run(main())
Ce pattern a un coût direct : un appel de modèle supplémentaire par interaction, parce que les résultats transitent par l'agent principal (LangChain). C'est le prix de la coordination — et c'est précisément là que la décision architecturale se joue. Pour approfondir les alternatives d'architecture, voir [LIEN_INTERNE: les patterns d'orchestration multi-agents → /blog/patterns-orchestration-multi-agents].
Définir les frontières de contexte
Une sous-tâche mérite un sous-agent uniquement si elle peut fonctionner sans connaître les résultats des autres sous-tâches. Posez la question : « Ce sous-agent a-t-il besoin de l'historique complet ? » Si oui, ne le séparez pas.
Choisir un modèle par rôle
L'orchestrateur exige un modèle puissant (gpt-4.1, o4-mini pour le raisonnement). Les sous-agents peuvent tourner sur des modèles compacts — c'est là que se fait l'économie.
Ne passer que l'essentiel
Transmettez au sous-agent la consigne et les seules données nécessaires. Un contexte chargé inutilement à chaque sous-agent multiplie le coût par le nombre de nœuds.
Tester l'isolation, pas l'exactitude
Le premier test n'est pas « le sous-agent répond-il juste ? », mais « le sous-agent échoue-t-il si une information vit dans un autre contexte ? ». Si oui, la décomposition est mauvaise.
Pour les développeurs qui veulent aller plus loin, l'API Agents propose aussi la compaction automatique du contexte : à l'approche de la limite contextuelle, le service résume les échanges antérieurs tout en préservant les informations nécessaires, ce qui permet des sessions multi-fenêtrès sans logique maison (BDM). Combinée aux sous-agents, elle évite le scénario classique de l'agent unique qui « oublie » le début de la conversation.
L'API Agents n'applique aucuns frais supplémentaires sur l'API elle-même : seuls les tokens et outils consommés sont facturés (source : BDM). Le coût marginal d'ajouter un sous-agent est donc le coût de ses tokens — d'où l'importance du choix du modèle par rôle.
Sous-agents, tools ou agent unique : que choisir ?
Le choix dépend de trois critères — contexte, spécialisation et latence — et dans la plupart des cas, l'agent unique bien outillé reste la bonne décision. Trois architectures dominent : l'agent unique avec outils, le pattern sous-agents (superviseur-travailleurs), et les pipelines séquentiels. Les critères de choix sont le contexte, la spécialisation et la latence.
Le verdict de terrain : un agent unique bien outillé reste la bonne décision par défaut (Gravity). Le passage aux sous-agents se justifie par trois conditions précises, que nous détaillons plus bas. L'erreur symétrique consiste à croire que « multi-agents = plus intelligent » : les benchmarks disent le contraire quand l'orchestration est ajoutée sans besoin réel.
Quel est l'impact chiffré des sous-agents ?
Trois résultats empiriques suffisent à trancher : les petits modèles orchestrés battent les grands modèles seuls, mais une mauvaise orchestration double la latence sans gagner en qualité. Les données expérimentales sont rares sur les sous-agents spécifiquement, mais les études sur les systèmes multi-agents sont suffisamment claires pour orienter l'architecture.
Les systèmes multi-agents de petits modèles peuvent battre un grand modèle unique. Une étude contrôlée sur cinq benchmarks (GAIA, GPQA, AIME, MuSiQue, HLE) montre que des systèmes composés de petits modèles surpassent des modèles uniques nettement plus grands, même avec accès direct aux outils. Le point crucial : la performance globale est pilotée par la capacité de l'orchestrateur, pas par celle des sous-agents — ces systèmes sont « planner-limited », non « executor-limited » (arXiv).
La délégation ne crée un avantage que si la frontière « gagne » le coût de la coordination. Une évaluation sur 1 500 cas de e-commerce a comparé une architecture distribuée agent-à-agent et un agent unique : qualité comparable selon l'éditeur, mais latence moyenne plus que doublée (35,1 s contre 13,4 s), consommation de tokens en hausse et coût total inférieur, grâce à la spécialisation des modèles — un modèle puissant pour orchestrer, des modèles moins chers pour exécuter (Algolia).
L'orchestration externe peut être contre-productive. Une étude comparant LangGraph et une approche « in-context » (procédure complète dans le prompt système, le modèle s'auto-orchestrant) sur trois domaines procéduraux montre que l'approche in-context obtient de meilleurs scores (4,53–5,00 sur 5 contre 4,17–4,84), avec des taux d'échec de 0,5–11,5 % contre 9–24 %. L'orchestration impose en outre 1,2 à 1,7 fois plus d'appels LLM par conversation (arXiv).
💡 Bon à savoir : Une latence qui passe de 13 à 35 secondes par requête, sur un service qui traite 10 000 requêtes par jour, représente 61 heures de traitement cumulé supplémentaires par jour. Pour un usage interactif, c'est rédhibitoire ; pour un traitement par lots nocturne, c'est sans importance.
Traduisons en temps de vie, parce que ces moyennes cachent des réalités très différentes : une latence qui passe de 13 à 35 secondes par requête, sur un service qui traite 10 000 requêtes par jour, représente 61 heures de traitement cumulé supplémentaires par jour. Pour un usage interactif, c'est rédhibitoire. Pour un traitement par lots nocturne, c'est sans importance. La même architecture peut être excellente ou aberrante selon le point de service.
Ne confondez pas « le coût token est plus bas » et « l'architecture est meilleure ». L'étude Algolia montre un coût inférieur, mais une latence multipliée par 2,6. Si votre cas d'usage est du temps réel client, la latence tue l'expérience avant que la facture ne vous sauve.
Le point positif des études : la spécialisation paie. Répartir les rôles — un modèle fort pour le raisonnement, des modèles compacts pour les tâches bornées — est la seule voie pour rendre le multi-agents économiquement viable. C'est le cœur de la stratégie « sous-agents ».
La règle des trois conditions pour passer au multi-agents
Les recherches convergent vers un framework de décision simple. Trois conditions justifient réellement le passage au multi-agents, et il faut les vérifier dans l'ordre (Gravity).
Condition 1 : le contexte excède une seule fenêtre
Votre agent doit analyser un dépôt de code de 200 000 lignes, synthétiser 500 pages de documents, croiser des sources hétérogènes. La fenêtre de contexte du modèle — même à 1 million de tokens — finit par saturer, et la compaction automatique de l'API Agents ne remplace pas une vraie séparation des préoccupations. Si tout tient dans une fenêtre, la séparation en sous-agents ajoute de la coordination sans rien résoudre.
Condition 2 : la spécialisation produit des résultats mesurablement meilleurs
Un agent critique qui évalue avec une grille explicite peut surpasser l'auto-relecture d'un agent unique. Un agent dédié à l'extraction de données structurées, avec un prompt et des outils spécialisés, fera mieux qu'un agent généraliste. La spécialisation doit se démontrer par un test A/B, pas par intuition : si les deux architectures donnent la même qualité, gardez l'agent unique.
Condition 3 : la décomposition parallèle est propre
Les sous-agents ne doivent pas avoir besoin de connaître mutuellement leurs résultats. Deux sous-tâches qui partagent profondément de l'information appartiennent au même agent — on ne sépare que ce qui peut fonctionner avec des informations réellement isolées. C'est la règle du couplage faible, héritée de l'architecture logicielle.
Contexte dépassé
Code sur grand dépôt, revue de centaines de pages, synthèse multi-sources. La fenêtre unique est saturée.
Spécialisation démontrée
Un rôle précis (extraction, classification, évaluation) produit des résultats mesurablement supérieurs avec un agent dédié.
Parallélisme propre
Les sous-tâches sont indépendantes : aucun échange de résultats intermédiaires requis entre sous-agents.
Ma recommandation, sans détour : commencez par un agent unique bien outillé, et ne passez au multi-agents que lorsqu'une exigence concrète n'est pas satisfaite. C'est la méthodologie recommandée par les travaux les plus récents, et c'est aussi la plus rapide à déployer. Pour les projets qui nécessitent une montée en compétence rapide sur ces architectures — et éviter de réinventer les anti-patterns que tout le monde expérimente en ce moment — un accompagnement ciblé fait gagner des semaines. C'est exactement l'objectif de [LIEN_INTERNE: notre formation sur l'orchestration d'agents IA → /formations/orchestration-agents-ia].
Quels sont les pièges des sous-agents ?
Trois pièges reviennent systématiquement dans les projets : l'orchestrateur-bouteille, les sous-agents sans état qui « oublient », et le surcoût de coordination invisible. Les sous-agents ne sont pas une mode : ils sont une réponse à un problème réel de passage à l'échelle. Mais comme toute abstraction, ils ont leurs pièges — et les équipes qui les découvrent en ce moment tombent toutes dans les mêmes.
L'orchestrateur-bouteille. Si chaque interaction passe par l'agent principal, il devient le point de congestion. Dans l'étude Algolia, la latence a plus que doublé précisément pour cette raison. Symptôme : votre orchestration sérialise ce qui pourrait être parallèle.
Les sous-agents sans état qui « oublient ». Un sous-agent performe sa tâche puis restitue un résultat compressé au parent. S'il a besoin d'accéder à une information traitée par un pair, l'architecture est fausse : la frontière de contexte a été mal dessinée.
Le surcoût de coordination invisible. Chaque sous-agent ajoute un appel de modèle supplémentaire pour le transit via l'orchestrateur. Sur un workflow à 20 nœuds, c'est 20 appels de coordination invisibles dans la facture — et les études montrent que les workflows agentiques consomment couramment 20 à 100 appels LLM par tâche (MindStudio).
Méfiez-vous des benchmarks « maison » qui comparent une architecture soignée à un agent unique mal prompté, ou inversement. Les études contrôlées — comme celles d'Algolia et de l'arXiv — montrent que la qualité est souvent comparable et que le vrai différentiel se joue sur la latence, le coût et la capacité à passer à l'échelle.
💡 Bon à savoir : Le pattern « équipes d'agents » est une alternative plus lourde : coordination continue, communication pair-à-pair, état partagé. Il se justifie pour des problèmes de négociation et de planification itérative. Pour une tâche isolée avec résultat compressé remonté au parent, les sous-agents « fire-and-forget » suffisent largement.
C'est exactement le type de décision que nous aidons les équipes à structurer chez The Intelligence Academy : partir de votre architecture réelle, la challenger avec les données disponibles, et repartir avec un plan d'implémentation — pas avec un cours théorique sur les agents.
Mesurez, ne supposez pas
Avant de séparer en sous-agents, mesurez le nombre de tokens consommés, le nombre d'appels outils et le temps de réponse de votre agent unique. Sans baseline, aucune optimisation n'est vérifiable.
Définissez les frontières par le contexte, pas par le rôle
La règle est simple : deux sous-tâches qui partagent de l'information en continu appartiennent au même agent. Le rôle est un indice, le contexte est la vérité.
Spécialisez les modèles, pas seulement les prompts
L'économie des sous-agents vient des modèles compacts en exécution — 10 à 50 fois moins chers que les modèles frontiers. Un prompt spécialisé sur un gros modèle rate la moitié du bénéfice.
Prévoyez l'échec par branche
Un sous-agent qui échoue doit être retenté, court-circuité ou signalé — sans faire échouer l'ensemble. L'orchestrateur doit expliciter sa stratégie de dégradation.
Le pattern « équipes d'agents » est une alternative plus lourde : coordination continue, communication pair-à-pair, état partagé. Il se justifie pour des problèmes de négociation et de planification itérative. Pour une tâche isolée avec résultat compressé remonté au parent, les sous-agents « fire-and-forget » suffisent largement (source : Daily Dose of DS).
Sources et références
- OpenAI — Présentation de l'API Agents (2026) — lancement de l'API, fonctionnalités multi-agents et environnements d'exécution
- BDM — OpenAI lance l'API Agents (2026) — détail du harnais Codex, compaction du contexte, tarification
- arXiv — Can Small Agents Collaborate to Beat a Single Large Model? (2026) — étude contrôlée multi-agents vs modèle unique sur 5 benchmarks
- Algolia — Monolithic vs distributed agents (2026) — benchmark 1 500 cas e-commerce, latence, coûts, qualité
- arXiv — In-Context Prompting Obsoletes Agent Orchestration (2026) — comparaison LangGraph vs approche in-context sur 3 domaines procéduraux
- LangChain — Choosing the Right Multi-Agent Architecture (2026) — patterns orchestrateur-travailleurs, handoffs, router, skills
- MindStudio — What Is the Sub-Agent Era? (2026) — économie des sous-agents, modèles compacts 10-50x moins chers
- Gravity — Single-Agent vs Multi-Agent (2026) — conditions d'utilisation du multi-agents, méthodologie
FAQ
Comment utiliser les sous-agents dans l'API Agents d'OpenAI ?
L'API Agents (et le SDK Python associé) permet de créer un agent superviseur et de lui attacher des sous-agents. La méthode la plus simple : définir chaque sous-agent avec la classe Agent, puis les exposer à l'orchestrateur via as_tool(). L'agent superviseur les appelle comme des outils, dans le cadre d'un pattern orchestrateur-travailleurs. La bonne pratique est de donner à chaque sous-agent un modèle adapté à sa tâche — les modèles compacts suffisent pour les tâches bornées — et de ne transmettre que le contexte strictement nécessaire.
Quelle est la différence entre sous-agents et tools dans l'OpenAI Agents API ?
Un tool est une fonction déterministe : il effectue une action précise (appel API, requête SQL, recherche) et retourne un résultat structuré. Un sous-agent est un agent LLM complet : il reçoit une consigne, planifie, peut utiliser des outils, et raisonne en langage naturel pour produire sa réponse. En pratique, un sous-agent peut être exposé comme un tool de l'orchestrateur (agent.as_tool()), ce qui brouille la frontière. La distinction opérationnelle : les tools apportent des capacités, les sous-agents apportent du raisonnement spécialisé avec un contexte isolé.
Quand faut-il utiliser des sous-agents plutôt qu'un agent unique ?
Trois conditions cumulatives : le contexte excède une seule fenêtre de modèle ; la spécialisation des rôles produit des résultats mesurablement meilleurs ; la décomposition en sous-tâches est propre (les sous-agents n'ont pas besoin de partager leurs résultats). Si une seule condition manque, l'agent unique avec des tools bien conçus reste plus simple, plus rapide et moins coûteux. Commencez toujours par l'agent unique et ne migrez qu'avec une exigence concrète non satisfaite.
Les sous-agents améliorent-ils vraiment la qualité des réponses ?
C'est variable — et c'est la conclusion honnête des benchmarks. Une étude contrôlée sur cinq benchmarks montre que des systèmes multi-agents de petits modèles peuvent surpasser un grand modèle unique, mais la performance dépend surtout de la capacité de l'orchestrateur, pas des sous-agents. Une autre étude sur 1 500 cas e-commerce montre une qualité comparable entre architecture distribuée et agent unique, avec une latence doublée. Les sous-agents améliorent la qualité quand ils permettent une spécialisation réelle — un agent critique avec une grille d'évaluation explicite, par exemple — pas quand ils sont ajoutés pour la forme.
Combien coûtent les sous-agents dans l'OpenAI Agents API ?
L'API Agents elle-même n'ajoute pas de frais : vous payez les tokens et les outils consommés, comme avec l'API Responses classique. Le surcoût des sous-agents vient des appels de coordination (un appel de modèle supplémentaire par interaction via l'orchestrateur) et des tokens de contexte transmis à chaque sous-agent. La stratégie économique est de faire exécuter la majorité des sous-tâches par des modèles compacts — 10 à 50 fois moins chers que les modèles frontiers — tout en gardant le modèle puissant pour l'orchestration et la synthèse.
Envie de passer à la pratique ? Notre formation dédiée vous accompagne pour appliquer tout ça à votre métier.
Pour aller plus loin
Conclusion
Les sous-agents de l'OpenAI Agents API sont une vraie brique d'architecture, pas une fonctionnalité marketing de plus. Ils répondent à un problème concret — le contexte qui déborde, la latence qui explose, la spécialisation impossible — à condition de respecter la règle des trois conditions : fenêtre de contexte saturée, spécialisation démontrée, décomposition propre. Les chiffres sont là : les systèmes multi-agents bien orchestrés surpassent les grands modèles seuls, mais mal orchestrés, ils doublent la latence sans améliorer la qualité.
Commencez par un agent unique. Mesurez. Puis séparez ce qui doit l'être — avec un orchestrateur fort et des petits modèles spécialisés en exécution. C'est la voie que confirment les études, et c'est celle que nous faisons pratiquer aux équipes que nous accompagnons, sur leurs vrais dossiers, pas sur des exercices génériques. Pour aller plus loin, découvrez [LIEN_INTERNE: notre formation OpenAI Agents API → /formations/openai-agents-api].