Créer des agents IA et des sous-agents en 2026 : guide complet et tutoriel multi-tâches

Pourquoi utiliser plusieurs agents ?

La décomposition devient utile quand les tâches exigent des sources, permissions, modèles ou critères suffisamment différents pour justifier des contextes séparés.

Les bénéfices sont concrets : responsabilités lisibles, prompts plus courts, outils limités, modèles adaptés, tests ciblés et traces plus faciles à interpréter. Des tâches indépendantes peuvent fonctionner en parallèle. Chaque spécialiste ne reçoit que le contexte nécessaire, puis renvoie une synthèse ou des données structurées à l’orchestrateur.

Le coût augmente en contrepartie. Chaque délégation ajoute des appels, de la latence, des risques de routage et des informations à reformuler. Le contexte peut se perdre entre deux agents ; les sorties peuvent se contredire ; une boucle de corrections peut se prolonger. Anthropic souligne que ses systèmes de recherche multi-agents consomment nettement plus de tokens qu’une interaction simple. L’architecture doit donc réserver cette dépense aux tâches dont la valeur et la parallélisation la justifient.

Commencez par un seul agent bien équipé. Ajoutez un spécialiste lorsqu’une erreur revient parce que le prompt devient contradictoire, que l’agent choisit régulièrement le mauvais outil ou qu’une permission doit être isolée. Si l’ordre est stable, codez le workflow. Si la tâche tient dans une requête fiable, ne construisez pas une équipe artificielle.

Les quatre architectures multi-agents à connaître

Le choix d’architecture détermine qui contrôle la conversation, comment circulent les données et où sont appliquées les règles d’arrêt.

Dans le modèle orchestrateur et agents comme outils, l’agent principal appelle des spécialistes puis assemble leurs résultats. Il garde la responsabilité finale : c’est le choix du tutoriel. Dans un handoff, un agent de triage transfère le contrôle à un spécialiste, par exemple facturation, support technique ou remboursement. Le nouveau spécialiste devient l’agent actif pour la suite de la conversation.

Le workflow déterministe confie l’ordre au code : recherche, analyse, production, contrôle, réponse. OpenAI documente ce mode comme plus prévisible en vitesse, coût et performance. Google ADK fournit des workflows séquentiels et parallèles ; sa documentation 2026 oriente aussi les nouveaux projets ADK 2.0 vers des graphes plus flexibles. Microsoft Agent Framework propose des orchestrations séquentielles, concurrentes, par handoff, en groupe et de type manager.

L’exécution parallèle diffuse une entrée vers plusieurs spécialistes indépendants, puis agrège les résultats. Elle exige des sorties structurées, une limite de concurrence et une stratégie pour les erreurs partielles. Elle ne convient pas si l’agent B dépend du résultat de l’agent A. Dans ce cas, le parallèle masque une dépendance et complique la cohérence.

Ce qui a changé en 2026

En 2026, les briques de production progressent surtout sur l’orchestration, la reprise, les approbations, les traces et l’interopérabilité — sans supprimer les arbitrages d’architecture.

OpenAI a publié GPT‑5.6 le 9 juillet 2026 en disponibilité générale. L’alias API gpt-5.6 pointe vers GPT‑5.6 Sol ; Terra vise un équilibre coût-capacité et Luna les volumes sensibles au prix. La documentation recommande le Responses API pour le raisonnement, les outils et les workflows multi-tours. L’orchestration multi-agent directement dans le Responses API est explicitement en bêta : elle ne doit pas être présentée comme une base stable universelle. Le tutoriel utilise donc le SDK Agents et son motif agents-as-tools documenté.

Les anciens tutoriels fondés sur l’Assistants API sont désormais à écarter pour un nouveau projet. OpenAI a annoncé son arrêt au 26 août 2026 et recommande Responses API et Conversations API. L’Agents SDK Python utilise Responses par défaut pour les modèles OpenAI, ajoute des interruptions sérialisables pour l’approbation humaine, des sessions, des limites de tours, le traçage des appels et des sorties structurées.

Google a mis à jour le 21 juillet sa documentation des Managed Agents Gemini API, toujours en Public Preview. Ils provisionnent un environnement Linux géré pour raisonner, exécuter du code, gérer des fichiers et parcourir le web ; Google demande une revue humaine avant les usages sensibles. ADK formalise les équipes d’agents, les workflows séquentiels ou parallèles et l’interopérabilité A2A, qui standardise la découverte et les échanges entre agents distants.

Microsoft Agent Framework, construit par les équipes à l’origine d’AutoGen et Semantic Kernel, devient la fondation recommandée par Microsoft pour les nouveaux workflows d’agents. Son modèle typé et orienté graphe couvre séquentiel, concurrent, handoff et validation humaine. Anthropic, de son côté, documente des sous-agents Claude Code à contexte et permissions isolés ; ses équipes de recherche décrivent aussi des points de contrôle, une mémoire externe et des reprises pour les tâches longues. Le progrès utile est moins « davantage d’agents » que des agents mieux bornés et opérables.

Tutoriel : un orchestrateur et quatre sous-agents en Python

L’exemple construit une équipe exécutable avec l’OpenAI Agents SDK : recherche web, planification structurée, production, contrôle qualité et synthèse finale.

Le SDK officiel requiert Python 3.10 ou plus ; Python 3.12 constitue un choix courant pour un nouveau projet. Créez un environnement virtuel, installez le paquet openai-agents vérifié en version 0.17.4, puis définissez OPENAI_API_KEY dans votre environnement. Le fichier .env.example ci-dessous est un modèle : remplacez la valeur localement, ne publiez jamais la clé et ne la placez pas dans le dépôt.

L’orchestrateur utilise l’alias gpt-5.6, qui suit GPT‑5.6 Sol au 25 juillet 2026. Les spécialistes utilisent gpt-5.6-terra pour limiter le coût tout en gardant une capacité solide. Ces choix sont configurables par variables d’environnement : évaluez-les sur vos propres cas avant de les figer. Aucun résultat fictif n’est présenté comme une exécution réelle ; le programme affichera la réponse produite avec votre compte et votre demande.

mkdir equipe-agents && cd equipe-agents
python3.12 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

cp .env.example .env
# Modifiez .env, puis chargez-le dans le terminal :
set -a
source .env
set +a

python main.py

openai-agents==0.17.4

OPENAI_API_KEY=your_api_key_here
OPENAI_ORCHESTRATOR_MODEL=gpt-5.6
OPENAI_SPECIALIST_MODEL=gpt-5.6-terra

import os

from agents import Agent, WebSearchTool
from pydantic import BaseModel, Field


ORCHESTRATOR_MODEL = os.getenv("OPENAI_ORCHESTRATOR_MODEL", "gpt-5.6")
SPECIALIST_MODEL = os.getenv("OPENAI_SPECIALIST_MODEL", "gpt-5.6-terra")


class ResearchReport(BaseModel):
    summary: str
    findings: list[str]
    missing_information: list[str]
    confidence: float = Field(ge=0, le=1)


class ActionPlan(BaseModel):
    objective: str
    steps: list[str]
    dependencies: list[str]
    risks: list[str]


class QualityReport(BaseModel):
    approved: bool
    omissions: list[str]
    unverified_claims: list[str]
    corrections: list[str]


research_agent = Agent(
    name="Recherche",
    model=SPECIALIST_MODEL,
    instructions=(
        "Recherchez uniquement les faits nécessaires à la demande. "
        "Privilégiez les sources primaires, signalez les lacunes et "
        "n'inventez jamais une donnée absente."
    ),
    tools=[WebSearchTool()],
    output_type=ResearchReport,
)

planning_agent = Agent(
    name="Planification",
    model=SPECIALIST_MODEL,
    instructions=(
        "Transformez la demande et les recherches reçues en plan d'action. "
        "Hiérarchisez les étapes, explicitez les dépendances et les risques."
    ),
    output_type=ActionPlan,
)

production_agent = Agent(
    name="Production",
    model=SPECIALIST_MODEL,
    instructions=(
        "Produisez le livrable demandé à partir du contexte transmis. "
        "Respectez le format, distinguez les faits des propositions et "
        "n'ajoutez aucune affirmation non étayée."
    ),
)

quality_agent = Agent(
    name="Contrôle qualité",
    model=SPECIALIST_MODEL,
    instructions=(
        "Contrôlez cohérence, complétude, preuves et respect des contraintes. "
        "Retournez un verdict exploitable et des corrections précises."
    ),
    output_type=QualityReport,
)

orchestrator = Agent(
    name="Orchestrateur",
    model=ORCHESTRATOR_MODEL,
    instructions=(
        "Vous êtes responsable de la réponse finale. Analysez la demande, "
        "appelez seulement les spécialistes nécessaires et transmettez-leur "
        "le contexte minimal. Pour une demande factuelle complexe, utilisez "
        "Recherche, puis Planification, Production et Contrôle qualité. "
        "Arbitrez les contradictions. Si le contrôle refuse le livrable, "
        "demandez une seule correction ciblée à Production. Ne prétendez "
        "jamais avoir exécuté une action externe."
    ),
    tools=[
        research_agent.as_tool(
            tool_name="research_specialist",
            tool_description=(
                "Collecte des faits sourcés, relève les lacunes et renvoie "
                "une synthèse structurée."
            ),
        ),
        planning_agent.as_tool(
            tool_name="planning_specialist",
            tool_description=(
                "Transforme une demande et des recherches en plan ordonné "
                "avec dépendances et risques."
            ),
        ),
        production_agent.as_tool(
            tool_name="production_specialist",
            tool_description=(
                "Produit le livrable demandé à partir d'un plan validé et "
                "du contexte fourni."
            ),
        ),
        quality_agent.as_tool(
            tool_name="quality_specialist",
            tool_description=(
                "Vérifie le livrable, les contraintes, les omissions et les "
                "affirmations non vérifiées."
            ),
        ),
    ],
)

import asyncio
import sys

from agents import Runner
from agents.exceptions import AgentsException, MaxTurnsExceeded

from agents_config import orchestrator


DEFAULT_REQUEST = (
    "Analyse le lancement d'un service de création de sites web assistée "
    "par IA, construis un plan de lancement, propose les principaux "
    "contenus et vérifie les risques ou affirmations non démontrées."
)


async def main() -> None:
    request = " ".join(sys.argv[1:]).strip() or DEFAULT_REQUEST

    try:
        result = await Runner.run(
            orchestrator,
            request,
            max_turns=12,
        )
    except MaxTurnsExceeded:
        print("Arrêt : limite de tours atteinte.", file=sys.stderr)
        raise SystemExit(2)
    except AgentsException as error:
        print(f"Erreur Agents SDK : {error}", file=sys.stderr)
        raise SystemExit(1)

    print(result.final_output)


if __name__ == "__main__":
    asyncio.run(main())

Agents-as-tools ou handoffs : que choisir ?

Utilisez un agent comme outil pour une sous-tâche délimitée ; utilisez un handoff lorsqu’un spécialiste doit devenir propriétaire de la conversation.

Dans l’exemple, l’orchestrateur doit comparer la recherche, le plan, la production et le verdict qualité. Les agents comme outils sont donc naturels : chaque spécialiste reçoit une entrée générée pour sa mission, retourne son résultat, puis l’orchestrateur poursuit. Le SDK distingue clairement ce mécanisme d’un handoff, où le spécialiste reçoit l’historique et prend la suite.

Le handoff convient à un support client : un agent de triage identifie la facturation, le diagnostic technique ou le remboursement, puis transmet le dossier au bon interlocuteur. Microsoft documente la même différence : le handoff transfère propriété et contexte, tandis qu’un agent-outil rend la main au principal. Si l’ordre doit être garanti — par exemple calcul, validation, écriture, double contrôle — le code doit rester l’orchestrateur.

Ajouter des sorties structurées

Une sortie Pydantic transforme une réponse libre en contrat vérifiable par le SDK et exploitable par le code.

Dans agents_config.py, ResearchReport impose un résumé, une liste de constats, les informations manquantes et une confiance comprise entre zéro et un. ActionPlan et QualityReport font de même pour les étapes et le verdict. Le paramètre output_type demande au modèle une sortie structurée ; Pydantic valide ensuite les champs.

Cette structure ne garantit pas la vérité. Elle garantit que l’application peut détecter un champ absent, comparer des résultats, calculer une règle d’escalade ou refuser la suite. Un niveau de confiance reste une auto-évaluation du système, pas une probabilité calibrée. Il doit compléter les preuves, jamais les remplacer.

from pydantic import BaseModel, Field
from agents import Agent


class FindingReport(BaseModel):
    summary: str
    findings: list[str]
    confidence: float = Field(ge=0, le=1)
    items_to_verify: list[str]


verification_agent = Agent(
    name="Vérification",
    instructions="Retournez uniquement des constats reliés aux éléments reçus.",
    output_type=FindingReport,
)

Mémoire, état et partage du contexte

Les agents ne partagent pas automatiquement une mémoire complète et fiable ; l’application doit décider quelles données circulent et où réside l’état autoritaire.

Le contexte local du SDK peut contenir des dépendances et un état applicatif sans être envoyé au modèle. Le contexte du modèle correspond aux messages, instructions et résultats d’outils qu’il voit. Les sessions du SDK conservent un historique entre plusieurs exécutions, tandis que previous_response_id ou Conversations API assurent une continuité gérée côté OpenAI. La documentation déconseille de superposer ces mécanismes sans raison.

Transmettre tout l’historique maximise l’information mais augmente le coût et le bruit. Un résumé réduit le volume mais peut perdre une contrainte. Des données structurées donnent un contrat plus robuste. Pour une commande, un paiement ou un workflow interrompu, la base de données de l’application doit rester l’état autoritaire : statut, version, approbation, identifiants et journal ne doivent pas dépendre uniquement de la mémoire conversationnelle.

Les tâches longues demandent des points de contrôle et une reprise. Anthropic décrit une mémoire externe pour préserver le plan lorsque les contextes se remplissent, ainsi que des artefacts persistants pour éviter de recopier de grands résultats entre agents. Le principe est transférable : stocker les livrables et décisions, puis transmettre des références et des résumés vérifiés.

Sécurité et validations humaines

La sécurité vient de permissions minimales, de paramètres validés, de limites d’exécution et d’une interruption obligatoire avant toute action sensible.

Séparez lecture et écriture. L’agent de recherche consulte des sources ; il ne publie rien. L’agent de production prépare un brouillon ; il ne l’envoie pas. Chaque outil limite les domaines, API, fichiers et champs accessibles. Les entrées provenant du web, d’e-mails ou de documents sont des données non fiables : elles peuvent contenir des injections de prompt. Les instructions de ces contenus ne doivent pas remplacer la politique de l’application.

Validez les paramètres avant l’appel, filtrez les données sensibles, imposez un nombre maximal de tours et un plafond de dépense. Journalisez le modèle, les outils, les décisions et les erreurs sans enregistrer inutilement des secrets. Les guardrails d’entrée et de sortie peuvent interrompre une exécution ; les guardrails d’outils contrôlent les fonctions avant et après leur appel. Ils complètent les permissions mais ne remplacent pas une autorisation métier.

Dans l’Agents SDK, needs_approval peut suspendre un outil ou un agent utilisé comme outil. Le résultat expose alors une interruption, convertible en RunState sérialisable ; une personne approuve ou refuse, puis le Runner reprend l’agent initial. Cette procédure convient à l’envoi d’un e-mail, un paiement, une suppression, une modification de base, une publication, un changement de permissions ou toute action irréversible.

Traces, tests et évaluation

Une évaluation d’agent doit mesurer le résultat final et le chemin qui y conduit : routage, outils, handoffs, erreurs, latence, coût et respect des limites.

Le traçage est activé par défaut dans l’Agents SDK et enregistre les générations, appels d’outils, handoffs et guardrails. Les traces aident à comprendre pourquoi une réponse réussit ou échoue. OpenAI présente le trace grading comme l’attribution de scores structurés à la trace complète ; les trace evals comparent ensuite plusieurs exécutions pour détecter les régressions. Les critères doivent rester reliés au métier.

Créez un jeu stable avant de modifier prompts, modèles ou architecture. Testez une demande simple qui ne nécessite qu’un spécialiste, une demande qui en exige deux, une information absente, une sortie invalide, un outil indisponible, une approbation refusée, un agent hors périmètre et une contradiction entre spécialistes. Vérifiez aussi la condition d’arrêt et l’absence d’action externe.

Le taux de succès final ne suffit pas. Mesurez la complétude, les preuves, les corrections humaines, les appels inutiles, la latence et le coût. Réduire les tokens en omettant une contrainte reste une régression.

Optimiser le coût et la vitesse

L’optimisation consiste à réduire les appels et le contexte sans dégrader les critères qui justifient le système.

Commencez avec un agent et ajoutez un sous-agent seulement lorsqu’une responsabilité claire apparaît. Utilisez un modèle moins coûteux pour l’extraction, le classement ou un contrôle simple, et gardez le modèle le plus capable pour l’orchestration ou une décision complexe. Dans GPT‑5.6, Terra et Luna donnent des options explicites ; leurs performances doivent être mesurées sur les tâches réelles.

Parallélisez uniquement ce qui est indépendant. Réduisez l’historique transmis, préférez les sorties structurées et mettez en cache les données stables lorsque le mécanisme et la politique de fraîcheur sont maîtrisés. Fixez max_turns, suivez l’usage par requête et configurez des alertes ou limites de dépense. Depuis le 22 juillet 2026, OpenAI documente aussi des plafonds mensuels stricts au niveau organisation ou projet.

Le meilleur gain vient souvent du retrait d’un agent. Une fonction déterministe, une requête de base ou un seul appel bien cadré coûtent moins cher et se testent mieux. L’architecture doit pouvoir expliquer pourquoi chaque délégation existe.

Douze erreurs fréquentes

La plupart des échecs viennent d’un périmètre flou, d’un contrôle absent ou d’une complexité ajoutée avant d’avoir défini la qualité attendue.

Il faut aussi tester le routage, interrompre les actions irréversibles, surveiller les versions et lire les statuts de maturité. Un exemple fondé sur l’Assistants API devient obsolète en août 2026. La fonction multi-agent du Responses API reste bêta au 25 juillet et les Managed Agents Gemini sont en Public Preview : aucune ne doit être présentée comme une garantie de production universelle.

Quand ne pas utiliser un système multi-agent ?

N’utilisez pas plusieurs agents lorsque la tâche est courte, entièrement déterministe ou impossible à évaluer objectivement.

Une fonction classique suffit pour une règle stable. Un workflow codé convient lorsque l’ordre ne doit jamais varier. Un appel unique reste préférable s’il produit une réponse fiable avec un contexte raisonnable. Le multi-agent est aussi un mauvais choix lorsque la latence est critique, le budget très limité ou les responsabilités impossibles à séparer.

L’absence d’évaluation est un signal d’arrêt : si personne ne peut définir une bonne sortie, ajouter des critiques et des orchestrateurs ne crée pas de vérité. Commencez par le résultat, les preuves et les conséquences d’une erreur. L’architecture vient ensuite.