OpenAI Agents API vs Agents SDK vs Responses API : sur quoi devriez-vous construire en 2026 ?

La suite logicielle pour agents d'OpenAI a profondément évolué en septembre 2026. La nouvelle API Agents a introduit un environnement d'exécution (harness) Codex managé pour des agents cloud persistants, tandis que l'ancien SDK Agents est entré dans une phase de maintenance pour produit complet. L'API Responses demeure l'interface de plus bas niveau pour les applications nécessitant des appels de modèles directs ou souhaitant gérer elles-mêmes la boucle de l'agent. Il ne s'agit pas de trois couches interchangeables autour d'un même composant : elles placent la frontière du moteur d'exécution (runtime) à différents niveaux.

L'architecture a changé : choisissez une frontière de runtime, pas une bibliothèque

La décision importante n'est plus simplement : « Quel SDK dois-je installer ? » Il s'agit plutôt de savoir qui contrôle le harness, la boucle d'agent, l'état de session persistant, la compaction de contexte, la reprise sur incident, l'environnement d'exécution et le cycle de vie de l'application.

La présentation actuelle des agents par OpenAI rend cette frontière explicite. L'API Agents exécute un harness Codex hébergé et gère l'orchestration ainsi que l'état persistant des sessions. L'API Responses fournit les réponses des modèles et des fonctionnalités hébergées tandis que votre application prend en charge la boucle d'agent périphérique. Le SDK Agents exécute la boucle au sein de votre application et est désormais complet sur le plan des fonctionnalités, ne constituant plus la voie d'avenir pour les futures nouveautés majeures.

Comparatif rapide

1. API Agents : harness managé, agent cloud persistant

L'API Agents expose le harness Codex via un service managé par OpenAI. OpenAI prend en charge les sessions, l'orchestration, la compaction de contexte et la reprise sur incident. Votre application continue de fournir les outils et de choisir l'environnement d'exécution.

Cette dernière distinction est essentielle. « Agent managé » ne signifie pas obligatoirement « tous les calculs s'exécutent chez OpenAI ». L'architecture de l'API Agents prend en charge l'absence d'environnement, un environnement hébergé par OpenAI, ou encore un environnement auto-hébergé connecté au harness hébergé. Avec un environnement auto-hébergé, votre application gère le provisionnement, la reconnexion, l'arrêt et les fichiers persistants, tandis que le harness reste managé.

L'API Agents est ainsi un service de runtime complet, et non un simple format de requête. Les sessions peuvent persister, diffuser leur progression en continu, recevoir des tâches supplémentaires, exploiter des outils, manipuler des fichiers et reprendre leur exécution lors de processus de longue durée.

Ce que vous gagnez avec l'API Agents

• Un harness Codex managé au lieu de devoir concevoir et exploiter vous-même la boucle principale de l'agent.
• Des sessions persistantes pour les opérations réparties sur plusieurs tours et les tâches de longue durée.
• Une orchestration managée, ainsi que la compaction de contexte et la reprise sur incident.
• Des environnements d'exécution hébergés par OpenAI ou auto-hébergés, selon les exigences de vos charges de travail.
• Le streaming et les webhooks pour le suivi de la progression et les événements de cycle de vie.
• Une orientation de plateforme explicitement recommandée par OpenAI pour les nouvelles applications d'agents.

Ce qui reste sous votre responsabilité

• Votre produit et votre serveur d'application.
• L'implémentation des outils (functions) et la logique métier.
• Les décisions d'autorisation et de gouvernance relatives à vos propres systèmes.
• Le cycle de vie de l'environnement d'exécution si vous optez pour des ressources de calcul auto-hébergées.
• L'évaluation, les critères d'acceptation, les garde-fous propres au domaine et la définition de ce que l'agent est autorisé à accomplir.

2. API Responses : maîtriser la boucle, utiliser les primitives de la plateforme

L'API Responses constitue le choix de plus bas niveau lorsque vous souhaitez bénéficier des capacités des modèles et des outils d'OpenAI sans déléguer l'ensemble du runtime de l'agent. OpenAI présente Responses comme la primitive d'API recommandée pour les nouveaux projets et comme une évolution de Chat Completions incluant des outils intégrés, des options d'état multi-tours, des entrées multimodales et l'utilisation d'outils agentiques.

Une requête Responses peut elle-même appeler des outils, mais votre application reste responsable du workflow global lorsque vous construisez un agent autour d'elle. Cela signifie que votre code décide de la manière de persister l'état de l'application, du moment de poursuivre, de la façon de récupérer des erreurs, de coordonner les spécialistes, de compacter les historiques volumineux et de représenter le travail pouvant être repris.

Ce n'est pas intrinsèquement inférieur. Il s'agit de la bonne limite lorsque le comportement de l'agent doit être profondément intégré dans la logique applicative existante, lorsque vous avez besoin d'un modèle d'état personnalisé ou lorsqu'un environnement managé masquerait un contrôle dont vous avez réellement besoin.

3. Agents SDK : pris en charge, mais n'est plus la voie d'avenir par défaut

Le SDK Agents demeure un framework open source pour exécuter des workflows d'agents dans votre application. Il fournit les définitions d'agents, les outils, les passages de relais (handoffs), les garde-fous, le traçage, les sessions et la boucle d'exécution en TypeScript et Python.

Cependant, son statut stratégique a évolué. OpenAI qualifie désormais le SDK Agents de « feature complete » : la maintenance, les correctifs de sécurité, les corrections de bugs critiques et les travaux de compatibilité se poursuivent, mais aucune nouvelle fonctionnalité majeure n'est prévue. OpenAI recommande l'API Agents pour les nouvelles applications.

Cela ne signifie pas qu'une application existante basée sur le SDK doive être réécrite immédiatement. Cela signifie que l'architecture ne doit plus supposer que le SDK sera le lieu d'atterrissage des prochaines fonctionnalités majeures de runtime d'agent.

Où se situe le SDK Codex

Le choix actuel ne se résume pas à une simple alternative à trois voies. La vue d'ensemble des runtimes d'OpenAI inclut le SDK Codex comme option pour exécuter le harnais Codex au sein d'une infrastructure que vous gérez. D'un point de vue architectural, cela diffère à la fois de l'API Agents hébergée et du SDK Agents.

Si votre réel besoin est « Je veux le harnais Codex, mais je dois l'exploiter moi-même », le SDK Codex est la surface à évaluer. Si votre exigence est « Je veux maîtriser la boucle autour des appels de modèles », évaluez Responses. Si votre situation est « J'ai déjà une application fonctionnelle basée sur le SDK Agents », le SDK existant peut rester valide pendant que vous planifiez en fonction de son statut de maintenance.

Le test de responsabilité du runtime

Une décision d'architecture judicieuse commence par définir ce que votre équipe doit maîtriser. Évaluez chaque exigence comme : à contrôler obligatoirement, contrôle souhaité, ou préférence pour le managé.

Un arbre de décision pour les nouveaux systèmes

Ce qui ne devrait pas dicter la décision

La migration est un changement d'architecture, pas un simple renommage d'import

Passer de l'Agents SDK à l'Agents API redéfinit la répartition des rôles. Dans le SDK, la boucle s'exécute au sein de votre application. Dans l'Agents API, OpenAI prend en charge le harnais et la session tandis que votre application s'intègre au moyen de tâches, d'événements, d'outils et de frontières d'environnement.

Un plan de migration viable doit par conséquent cartographier l'état des sessions, l'orchestration personnalisée, les passages de relais (handoffs), l'exécution des outils, les approbations, le stockage, le traçage, les nouvelles tentatives, la reprise sur incident, le cycle de vie de l'environnement et toute abstraction propre au fournisseur. Le volume de code peut diminuer alors même que les hypothèses opérationnelles changent.

L'inventaire de la migration

• Définitions des agents et gouvernance des instructions.
• Définitions des outils et localisation de l'exécution de chaque outil.
• Passages de relais (handoffs), modèles manager/spécialiste et comportement des sous-agents.
• Identifiants de session, état des conversations, reprise d'exécution et rétention de l'historique.
• Approbations humaines et sémantique d'interruption.
• Logique personnalisée d'élagage ou de compactage du contexte.
• Traçage, évaluations, observabilité et débogage en production.
• Fichiers auto-hébergés, conteneurs, accès au réseau privé ou autres dépendances d'exécution.
• Abstraction de fournisseurs ou dépendances envers des modèles tiers (hors OpenAI).
• Hypothèses de réessai, de délai d'attente (timeout), d'idempotence, de reprise et de cycle de vie.

La bêta publique modifie le modèle de risque

L'Agents API constitue la trajectoire recommandée pour les nouvelles applications d'agents, mais elle est également en bêta publique. Ces deux réalités ne sont pas contradictoires. L'orientation stratégique répond à la question : « où va la plateforme ? » Le statut de bêta répond à la question : « quelle ampleur de modifications d'interface et d'exploitation dois-je anticiper ? »

Pour les systèmes en production, isolez l'intégration derrière une frontière applicative. Conservez autant que possible l'état du domaine, les permissions, les données d'audit et les règles métier en dehors des objets de session propres au fournisseur. Cela facilite l'absorption des évolutions de l'API sans faire du runtime d'agent la source de vérité de l'ensemble de votre produit.

Une architecture par défaut pragmatique

Pour de nombreuses nouvelles applications natives OpenAI, un choix par défaut pertinent pour 2026 est : l'Agents API pour le harnais managé et la session persistante, des services de domaine et une gestion des autorisations propres à l'application, des outils d'appel de fonctions explicites pour les actions métier, ainsi qu'une exécution hébergée par OpenAI ou auto-hébergée selon les contraintes de données et de calcul.

Cette approche préserve la puissance du runtime d'agent sans en faire le détenteur de la vérité métier. L'application continue de déterminer ce qu'un utilisateur a le droit de faire, quelles données font foi, quelles actions requièrent une approbation et comment les résultats sont validés.

Qu'est-ce qui remettrait cette réponse en question ?

Cette recommandation évolue si l'Agents API ajoute ou supprime des fonctionnalités, sort de bêta avec des contrats d'interface différents, modifie les périmètres d'environnement ou de tarification, ou propose des outils de migration réduisant les écarts de responsabilité. Elle change également si votre application dépend de la portabilité entre fournisseurs, d'une sémantique d'orchestration sur mesure, d'une exécution exclusivement locale ou d'une capacité que le harnais managé ne peut pas prendre en charge.

Pour une application existante basée sur l'Agents SDK, la réponse varie également en fonction du coût de migration. Si le système est stable, rigoureusement évalué et non bridé par le statut « feature complete » du SDK, une migration immédiate risque de générer plus de risques que de valeur. En revanche, si la feuille de route du produit repose sur des fonctionnalités exclusivement déployées dans l'Agents API, différer la migration peut engendrer une dette technique d'une autre nature.

Limites

Cette comparaison se concentre sur la répartition des responsabilités d'exécution et les orientations annoncées par OpenAI pour sa plateforme. Elle ne constitue pas un banc d'essai sur la latence, la qualité ou le coût total pour une charge de travail spécifique. Ces critères dépendent du choix du modèle, de l'utilisation des outils, de l'environnement, de la durée de la tâche, de la mise en cache, de l'utilisation de bacs à sable (sandboxes) et de l'architecture de l'application.

L'API Agents est également assez récente pour que l'expérience en production soit encore en cours d'accumulation. Une conception doit donc être validée avec des charges de travail représentatives plutôt que choisie uniquement en fonction du positionnement du produit.

Conclusion

En 2026, la décision relative aux agents OpenAI concerne fondamentalement la maîtrise du runtime. L'API Agents implique qu'OpenAI prenne en charge une plus grande part du harnais et des mécanismes de session persistante. L'API Responses signifie que votre application maîtrise la boucle autour des primitives de la plateforme. L'Agents SDK reste pertinent pour les systèmes existants, mais n'est plus la destination par défaut pour les nouvelles fonctionnalités majeures du runtime d'agents.

Pour une nouvelle application, suivez les orientations de la plateforme à moins qu'une exigence réelle ne vous contraigne à descendre plus bas dans la pile. Commencez par l'API Agents, passez à l'API Responses lorsque vous devez maîtriser la boucle, évaluez le Codex SDK lorsque vous avez besoin du harnais dans votre infrastructure, et conservez l'Agents SDK là où les investissements existants ou des manques temporaires de fonctionnalités le justifient.

FAQ

Glossaire

Sources primaires et lectures complémentaires