OpenAI Agents SDK

L'OpenAI Agents SDK est le framework officiel en Python et TypeScript d'OpenAI pour la création d'applications multi-agents prêtes pour la production. Sorti le 15 mars 2025, il a remplacé Swarm, le précédent prototype d'orchestration expérimental d'OpenAI, et est distribué sous forme de bibliothèque gratuite sous licence MIT sur PyPI et npm. Le SDK fonctionne de pair avec la Responses API d'OpenAI et offre aux développeurs un moyen structuré de définir des agents, de les connecter à des outils, de transférer le travail entre eux et de valider leurs entrées et sorties avant que quoi que ce soit n'atteigne l'utilisateur.

Les primitives de base sont intentionnellement minimalistes : les agents (des LLM dotés d'instructions et d'outils), les transferts ou handoffs (le routage d'un agent à un autre en fonction de l'intention), les garde-fous ou guardrails (la validation des entrées et sorties pouvant interrompre ou rediriger l'exécution), et le traçage (la visualisation intégrée du workflow pour le débogage et la surveillance). Au-delà de ces éléments, le SDK prend en charge l'intégration de serveurs Model Context Protocol (MCP), la gestion des sessions persistantes, les points d'approbation avec intervention humaine (human-in-the-loop), les agents vocaux via la Realtime API avec gpt-realtime-1.5, et, depuis la mise à jour d'avril 2026, les agents Sandbox capables d'exécuter du code, d'inspecter des fichiers et de lancer des commandes dans des environnements de conteneurs isolés.

Ce que fait réellement l'OpenAI Agents SDK en mai 2026

Le SDK Python en est à la version v0.15.1 (sortie le 2 mai 2026) avec 92 versions au total et plus de 25,800 étoiles GitHub depuis son lancement. La version TypeScript, ajoutée en juin 2025, a atteint la version v0.8.5 en avril 2026. Les deux sont sous licence MIT et fonctionnent avec la Responses API d'OpenAI ainsi qu'avec n'importe quel point de terminaison compatible Chat Completions, ce qui signifie que les développeurs peuvent router vers des modèles non-OpenAI via LiteLLM ou des adaptateurs similaires.

Un agent minimal en Python nécessite quatre lignes de code. Les agents sont définis par un nom, un ensemble d'instructions et une liste facultative d'outils. L'appel Runner.run_sync() gère la boucle complète de l'agent : l'invocation du modèle, le traitement des appels d'outils, la gestion des transferts et le renvoi de la sortie finale. Le système de traçage enregistre chaque étape automatiquement et l'affiche dans un tableau de bord visuel lié à la plateforme OpenAI.

La mise à jour Sandbox Agents d'avril 2026 a introduit l'exécution basée sur des conteneurs : les agents peuvent désormais inspecter des fichiers, exécuter des commandes shell, appliquer des correctifs de code, installer des packages et conserver l'état de l'espace de travail tout au long d'une tâche prolongée. Cette fonctionnalité n'est actuellement disponible que dans le SDK Python, la prise en charge de TypeScript étant annoncée comme prévue mais sans calendrier précis. La même mise à jour a présenté en avant-première les « sous-agents » (décomposition parallèle des tâches sous un agent principal) et le « mode code », tous deux encore sur la feuille de route au moment de la rédaction.

La prise en charge des serveurs MCP signifie que tout outil exposé via le Model Context Protocol se connecte au SDK de la même manière qu'un outil de fonction, donnant à l'Agents SDK accès à l'écosystème MCP en pleine croissance sans travail d'intégration sur mesure. Les outils hébergés par OpenAI, notamment la recherche web, la recherche de fichiers et l'interpréteur de code, sont disponibles nativement mais lient les données de l'agent au stockage de la plateforme OpenAI.

Où se situe l'Agents SDK par rapport à LangGraph et au Claude Agent SDK d'Anthropic

LangGraph est l'alternative architecturale la plus proche pour les équipes qui créent des workflows complexes. Il utilise un modèle de graphe orienté : les agents sont des nœuds, des arêtes conditionnelles contrôlent les transitions d'état, et le framework prend en charge les workflows cycliques, le véritable débogage par voyage dans le temps grâce à des points de contrôle intégrés, ainsi que la couche d'observabilité LangSmith. LangGraph est totalement agnostique vis-à-vis des modèles ; passer de GPT-4o à Claude 3.5 ou Gemini 1.5 Pro ne nécessite aucune modification structurelle du graphe. Le modèle de transfert de l'OpenAI Agents SDK est plus simple et plus rapide à mettre en œuvre, mais les primitives de graphe de LangGraph offrent un contrôle plus précis sur la logique de branchement et la récupération d'erreurs dans les workflows comportant de nombreux chemins conditionnels. Le compromis est réel : la courbe d'apprentissage de LangGraph est nettement plus abrupte, et les équipes signalent régulièrement que la documentation n'est pas adaptée aux débutants.

Le Claude Agent SDK d'Anthropic se situe à l'autre extrémité du spectre concurrentiel. Tout comme l'OpenAI Agents SDK, il s'agit d'un framework officiel maintenu par le fournisseur, construit autour de chaînes d'utilisation d'outils et de sous-agents, avec une gestion de l'état assurée par des serveurs MCP. Sa conception axée sur la sécurité intègre la réflexion étendue directement dans la boucle de l'agent et est spécifiquement optimisée pour les modèles Claude. Cela signifie que la dynamique de verrouillage propriétaire est symétrique : le SDK d'OpenAI vous lie aux outils hébergés et à la Responses API d'OpenAI ; le Claude Agent SDK vous lie à la famille de modèles d'Anthropic. Pour les équipes déjà investies dans l'un des écosystèmes, le SDK respectif est le choix naturel. Pour les équipes qui doivent rester agnostiques vis-à-vis des fournisseurs au niveau de l'orchestration, aucun des deux n'est une solution parfaite, et LangGraph ou Agno deviennent plus attrayants.

Comparé à CrewAI, l'OpenAI Agents SDK échange le DSL basé sur les rôles de CrewAI (qui permet de faire fonctionner une équipe multi-agents en environ 20 lignes avec une connaissance minimale du framework) contre une API de plus bas niveau et plus explicite. CrewAI dispose de modules de mémoire intégrés ; l'Agents SDK n'en a pas. L'intervention humaine (human-in-the-loop) de CrewAI ne se déclenche cependant qu'à la fin d'une tâche, tandis que l'Agents SDK prend en charge des points d'approbation en cours de workflow. Pour les équipes qui le comparent à AutoGen, la principale différence est qu'AutoGen se concentre sur des topologies d'agents conversationnels avec des réseaux d'agents flexibles, tandis que l'Agents SDK a une approche très arrêtée sur le modèle de transfert et s'attend à ce que vous travailliez avec ses primitives plutôt que de composer les vôtres.

« Si votre équipe est déjà sur OpenAI et a besoin de transferts propres d'agent à agent, l'OpenAI Agents SDK est le framework le plus directif, ce qui est un avantage : moins de décisions, une mise en œuvre plus rapide, et les primitives de traçage/garde-fous font gagner des semaines de développement sur mesure. » - Critique du blog mem0.ai, décembre 2025

À quoi ressemble la réalité de la boucle d'agent

Le workflow standard : définir les agents, assigner les outils, configurer les transferts, ajouter les garde-fous, exécuter. Le traçage est automatique. Un agent de révision de code utilisant la primitive Sandbox reçoit un diff de pull request, lance un conteneur, exécute des tests, applique des correctifs et renvoie une sortie structurée. Les développeurs qui créent des pipelines de support client décrivent un agent de routage qui classifie l'intention de l'utilisateur et transfère la demande à des spécialistes de la facturation, de la technique ou des retours, chacun ayant ses propres instructions et outils, le tout visible dans une seule trace sur le tableau de bord OpenAI. Il ne s'agit pas de cas d'usage théoriques, mais de modèles de production documentés par l'équipe du SDK.

Le modèle de coût caché est un point que les développeurs signalent à plusieurs reprises après leur premier déploiement réel. Chaque tour d'agent renvoie le contexte complet de la conversation au modèle. Un workflow en 5 étapes ne consomme pas 5 fois plus de tokens qu'un appel unique ; selon la longueur du contexte, il peut en consommer 3 à 4 fois plus. Les équipes qui exécutent de gros volumes de workflows agentiques doivent modéliser ce coût à l'avance. Un pipeline de révision de code estimé entre 0,075 et 0,14 $ par révision commence à peser lourd à plusieurs milliers de révisions par jour.

Les workflows d'agents vocaux utilisant la primitive RealtimeAgent s'exécutent sur gpt-realtime-1.5 avec détection automatique des interruptions, gestion du contexte et garde-fous. Le lancement du SDK TypeScript en juin 2025 incluait la fonctionnalité RealtimeAgent, et les développeurs peuvent déployer des agents vocaux côté client ou côté serveur. La mise à jour de juin 2025 a immédiatement suscité des signalements de dégradation de la qualité audio, de bruits parasites dans les flux audio en arrière-plan et d'augmentations de la latence des appels de fonction de la part des développeurs sur les forums communautaires, bien que ces problèmes soient distincts des fonctionnalités de base de transfert et de garde-fous.

« Les mises à jour les plus excitantes à ce jour ! La conversation en temps réel et les capacités d'intervention humaine changent complètement la donne. » - développeur, forum de la communauté OpenAI, 3 juin 2025

Le manque de mémoire est une constante dans les critiques. Le SDK gère proprement le contexte à court terme grâce à sa gestion de session, mais la mémoire durable, les couches de récupération et la personnalisation nécessitent une infrastructure externe. Les équipes qui créent des agents devant se souvenir des utilisateurs d'une session à l'autre doivent intégrer leur propre base de données vectorielle ou utiliser un outil comme Letta pour la gestion de la mémoire en parallèle du SDK. Il ne s'agit pas tant d'un défaut de conception que d'un choix de périmètre délibéré : le SDK gère l'orchestration, pas la couche de données. Cependant, cela signifie que l'argument du « chemin rapide vers la production » comporte un astérisque pour les applications avec état (stateful).

À qui s'adresse l'OpenAI Agents SDK

Le SDK est le point de départ idéal pour un profil spécifique : les équipes qui utilisent déjà l'API d'OpenAI, qui sont à l'aise en Python et qui créent des workflows où la délégation propre d'agent à agent est le défi principal. L'automatisation du support client, les pipelines de recherche en plusieurs étapes, les agents de révision de code et les workflows de génération de contenu correspondent tous parfaitement à l'ensemble de primitives du SDK. Le traçage et les garde-fous intégrés apportent ici une véritable valeur ajoutée : les équipes qui auraient autrement dû les créer de toutes pièces économisent un temps d'ingénierie précieux.

Les développeurs qui souhaitent expérimenter avec des agents vocaux ou des workflows Realtime API en production trouvent dans l'Agents SDK un cadre qu'aucun autre framework majeur n'égale actuellement avec le même niveau de support officiel. La primitive RealtimeAgent, combinée à l'intégration des outils MCP, crée une base crédible pour les applications agentiques axées sur la voix (voice-first).

Les équipes qui débutent avec les frameworks d'agents et qui paient déjà pour l'accès à l'API d'OpenAI disposent d'un point d'entrée à faible friction. Le démarrage rapide est véritablement minimaliste. La qualité de la documentation est systématiquement jugée claire et bien organisée dans les critiques. Le parti pris du framework, souvent cité comme un risque, fonctionne comme un avantage pour les équipes qui ne veulent pas prendre 15 décisions architecturales avant de déployer leur premier agent.

Pour ceux qui s'appuient sur DSPy pour l'optimisation des prompts ou sur LangChain pour des outils plus larges de chaîne de pensée (chain-of-thought), l'Agents SDK peut compléter plutôt que remplacer ces outils. Ce n'est pas une plateforme d'IA full-stack ; c'est une couche d'orchestration qui suppose que vous ferez vos propres choix concernant les couches de données, de mémoire et d'évaluation des modèles.

Ce que l'OpenAI Agents SDK n'est pas

Il n'est pas agnostique vis-à-vis des modèles au niveau de la couche des outils hébergés. La couche d'inférence peut pointer vers n'importe quel point de terminaison compatible Chat Completions, mais dès que vous utilisez File Search, Vector Stores, Code Interpreter ou Threads, vos données résident sur la plateforme d'OpenAI sans chemin d'exportation standard. Ashpreet Bedi, fondateur d'AgnoAGI, a noté que « la Responses API est intentionnellement conçue pour empêcher les développeurs de changer de fournisseur en modifiant la base_url ». Il s'agit d'une véritable contrainte architecturale, et non d'un risque hypothétique.

Ce n'est pas un moteur de workflow basé sur des graphes. Les équipes qui créent des workflows avec des boucles conditionnelles complexes, des branches parallèles, des points d'approbation à des moments arbitraires et des relectures basées sur des points de contrôle ont besoin de LangGraph. Le modèle de transfert de l'Agents SDK est séquentiel et explicite. Vous pouvez construire une exécution parallèle avec asyncio, mais il n'y a pas d'abstraction au niveau du framework pour cela, et la fonctionnalité prévue de sous-agents n'a pas de date de sortie confirmée.

Ce n'est pas une solution complète pour les équipes travaillant principalement en TypeScript à l'heure actuelle. Les SDK Python et TypeScript sont maintenus en parallèle, mais la version Python reçoit systématiquement les fonctionnalités majeures en premier. Les agents Sandbox, la nouvelle architecture de harnais, le mode code et les sous-agents sont tous exclusifs à Python en mai 2026, la parité TypeScript étant indiquée comme « prévue pour une version future » sans calendrier précis. Créer aujourd'hui un pipeline d'agents de production axé sur TypeScript avec l'Agents SDK implique d'accepter un retard de fonctionnalités.

Ce n'est pas un framework de mémoire ou de récupération. Les équipes qui ont besoin que les agents se souviennent des utilisateurs, récupèrent des informations dans des bases de connaissances ou personnalisent les réponses au fil du temps devront créer ou intégrer une couche externe. Le SDK ne se prononce pas sur la façon dont vous résolvez ce problème.