Agent IA OpenAI : Agents API ou Agents SDK, lequel choisir ?

OpenAI a lancé Agents API, son service managé, le 10 septembre 2026. Pour un agent IA, choisissez cette API si la gestion des sessions, la compaction et la reprise constituent l’essentiel de la charge opérationnelle ; préférez Agents SDK si l’application doit garder la main sur le runtime, le déploiement et le cheminement des données. Entre OpenAI Agents API et Agents SDK, l’arbitrage porte donc sur le contrôle et l’exploitation, puisque le service managé n’ajoute aucuns frais propres au harness.

Agents API ou Agents SDK : lequel choisir pour créer un agent IA ?

Pour une petite équipe plateforme qui met en production des agents IA capables de travailler longtemps, OpenAI Agents API constitue le meilleur choix par défaut. OpenAI exécute le harness Codex, conserve la session et les travaux enregistrés, compacte le contexte, coordonne les sous-agents et assure la reprise entre plusieurs tours asynchrones. Autant de tâches d’infrastructure qui différencient rarement un produit. OpenAI l’a lancée en bêta publique le 10 septembre 2026 et indique qu’elle est accessible à tous les développeurs.

Pour un fondateur ayant levé des fonds, épaulé par une petite équipe backend et doté d’un agent de revue documentaire susceptible d’attendre des validations pendant des heures, une session managée vaut davantage que la maîtrise de la boucle. L’équipe produit doit consacrer son temps limité aux règles, aux outils, aux évaluations et à l’expérience utilisateur.

OpenAI Agents SDK s’impose plutôt lorsque le contrôle du runtime est une exigence, pas une simple préférence. Il s’exécute dans votre application : déploiement, stockage, logique d’approbation, implémentation des outils et stratégie d’état restent sous votre responsabilité. Un CTO d’ETI soumis à une politique obligatoire de Zero Data Retention doit aujourd’hui retenir cette voie, car la bêta publique d’Agents API ne prend pas en charge le ZDR.

Pour un développeur senior qui dispose déjà d’un parc de workers, d’une télémétrie sur mesure et d’un processus de reprise éprouvé, migrer uniquement pour ne plus entretenir une boucle modeste serait un mauvais calcul. Le SDK préserve ce contrôle tout en fournissant agents, outils, handoffs, garde-fous, sessions, validation humaine et tracing.

OpenAI Agents API ou Agents SDK : le comparatif express

La différence officielle tient à deux questions : où s’exécute l’orchestration et qui possède l’état entre deux tâches ? Les deux solutions peuvent appeler les modèles et les outils d’OpenAI ; aucune ne rend gratuits les tokens des modèles.

En pratique, le basculement est simple. Si votre agent traite une demande courte dans un service existant, la charge induite par le SDK peut être minime. S’il modifie des fichiers, attend une approbation, survit aux déconnexions, délègue du travail et reprend le lendemain, l’API managée supprime d’autant plus de mécanique que son cycle de vie comporte d’états.

Le harness et la sandbox relèvent de deux choix distincts

Agents API gère la boucle de raisonnement, sans pour autant imposer l’exécution de tous les outils sur l’infrastructure d’OpenAI. OpenAI appelle cette boucle managée le harness Codex : elle coordonne les appels de modèles, l’utilisation des outils, le contexte, les sessions et les sous-agents. L’environnement d’exécution, dans lequel les commandes tournent et les fichiers résident, constitue une ressource séparée.

Cet environnement peut être absent, hébergé par OpenAI ou autohébergé. Sans environnement, le harness peut toujours appeler des serveurs MCP distants et transmettre des appels de fonctions à votre application, mais il ne dispose ni de Bash intégré, ni d’outil apply-patch, ni de fichiers de workspace. Avec une sandbox hébergée par OpenAI, OpenAI provisionne l’espace de travail Linux. Avec un environnement autohébergé, votre exécuteur lance les commandes et les opérations sur les fichiers à la demande du harness managé. Le guide d’architecture matérialise clairement cette séparation.

Cette nuance évite deux erreurs coûteuses. Premièrement, choisir Agents SDK au seul motif que le code doit tourner dans votre VPC est prématuré : Agents API peut se connecter à un environnement autohébergé. Deuxièmement, choisir Agents API pour qu’OpenAI exécute tout l’est également : les gestionnaires de fonctions applicatifs tournent toujours dans votre code, tandis qu’un exécuteur autohébergé vous laisse le provisionnement, la reconnexion, l’arrêt et la persistance des fichiers.

Pour un workflow privé d’analyse de données, le harness managé pourrait envoyer des appels de fonctions SQL à un service applicatif sans disposer d’un shell généraliste. Pour un agent de code, il pourrait utiliser une sandbox hébergée par OpenAI. Pour un système de build propriétaire, il pourrait se connecter à votre propre worker isolé. Trois modes d’exécution, une seule couche d’orchestration managée.

Propriété des sessions : Agents API domine les tâches longues

Agents API prend l’avantage dès qu’une tâche vit plus longtemps qu’une requête applicative. Une session conserve la configuration de l’agent, la conversation et les travaux enregistrés. Une nouvelle entrée lance un tour asynchrone lorsque la session est inactive, ou réoriente le tour en cours lorsqu’elle travaille. Votre application peut suivre un flux ou recevoir les changements d’état par webhook.

OpenAI gère aussi la compaction du contexte quand une session approche de sa limite. Compacter consiste à remplacer les détails anciens par une représentation conservée plus courte, afin que l’agent puisse continuer au-delà de plusieurs fenêtres de contexte. Le principe est simple à expliquer, bien plus délicat à exploiter : le résumé retenu doit préserver les décisions, les résultats des outils et les tâches inachevées, sans transporter indéfiniment chaque token antérieur.

La reprise constitue l’avantage le plus discret. Les flux d’événements ne rejouent pas les événements manqués. Après une déconnexion, l’application récupère la session et les éléments sauvegardés, puis repart de cet enregistrement durable au lieu de reconstruire un tour d’agent depuis la mémoire du processus. Le guide des sessions distingue un tour terminé, un tour en échec, une annulation et une session simplement inactive.

Prenons l’agent de revue de contrats d’un fondateur ayant levé des fonds. Il lit un document, demande à un sous-agent spécialiste de comparer des clauses, attend l’approbation du service juridique, reçoit ensuite une correction et produit un livrable. La valeur du produit réside dans la revue. Le rejeu des sessions, la compaction, les flux interrompus et la reprise des tours sont des coûts d’exploitation. C’est précisément la charge qu’absorbe l’API managée.

La limite à reconnaître concerne la précision comptable. Les agents peuvent effectuer plusieurs appels de modèles, et les agents racines, sous-agents, nouvelles tentatives, outils et sandboxes participent tous au coût. OpenAI précise que les champs d’usage d’Agents API sont fournis au mieux, peuvent être nuls ou évoluer, et ne constituent pas une facture définitive. Les tokens de raisonnement sont comptés comme tokens de sortie, tandis que les entrées mises en cache restent facturables. Utilisez le guide d’usage pour le débogage, puis rapprochez ces données de la facturation pour vos contrôles financiers.

Le dashboard fait également partie de la frontière d’observabilité. La récupération détaillée des traces et les exportateurs de traces externes ne sont pas accessibles via l’API client de la bêta publique. Si votre pipeline de télémétrie exige l’export programmatique de chaque trace, cette lacune compte davantage qu’un dashboard managé soigné.

Contrôle du runtime et du déploiement : Agents SDK l’emporte

Agents SDK s’impose lorsque votre application doit décider avec précision comment une exécution démarre, s’interrompt, reprend, stocke son état, distribue les outils et échoue. Son runner assure la boucle de l’agent et les handoffs, mais cette boucle reste dans votre service. Le code de votre produit peut donc encadrer chaque transition avec ses propres transactions, files d’attente, limites de débit, journaux d’approbation et outils de télémétrie.

Le SDK est disponible pour TypeScript et Python, et le dépôt Python utilise la licence MIT. Le package n’entraîne donc aucuns frais de licence par utilisateur. Les appels aux modèles OpenAI, les outils hébergés, les fournisseurs de sandbox et le calcul qui exécute votre application restent des coûts distincts. Le guide du SDK le destine aux applications code-first qui possèdent leur déploiement, leur stockage, leurs approbations et leur intégration au runtime.

L’état est flexible, plutôt qu’automatique. Une application fondée sur le SDK peut rejouer result.history, conserver une session du SDK dans son propre stockage, associer un identifiant OpenAI Conversations ou reprendre à partir de l’identifiant d’une réponse précédente de Responses API. Chaque option est utile, mais le guide d’exécution des agents avertit qu’associer le rejeu local à un état géré côté serveur peut dupliquer le contexte si les couches ne sont pas volontairement réconciliées.

Cette souplesse prend tout son sens dans un service interne réglementé. Vous pouvez inscrire une approbation et la reprise de l’agent dans une même transaction de base de données, placer l’état dans une région autorisée, exécuter les outils derrière des contrôles de réseau privé et intégrer l’agent à un système de jobs existant. Vous pouvez aussi brancher des modèles ou des fournisseurs via la couche modèle du SDK, sans faire du harness Codex managé la frontière d’orchestration permanente.

La contrepartie est la responsabilité opérationnelle. Un plantage de processus devient votre problème de reprise. La livraison d’un message en double devient votre problème d’idempotence. Croissance de l’historique, politique de compaction, nouvelles tentatives des outils, migrations d’état et rollback du déploiement deviennent également vos problèmes. Le SDK vous en donne le contrôle ; ce contrôle n’a de valeur que si l’application l’exploite.

Comparatif des coûts : aucuns frais distincts pour le harness

À modèle OpenAI, combinaison de tokens et appels d’outils identiques, la facture des tokens et des outils hébergés est la même pour les deux runtimes. Les tarifs ont été vérifiés sur les pages en ligne d’OpenAI le 11 septembre 2026. Pour GPT-6 Astra en contexte court standard, le tarif est de $10.00 par 1 million de tokens d’entrée et $50.00 par 1 million de tokens de sortie. La recherche web coûte $10.00 pour 1,000 appels, auxquels s’ajoutent les tokens du contenu trouvé au tarif du modèle choisi. Agents API elle-même ne facture aucuns frais distincts.

Voici une charge de travail normalisée. Il s’agit d’hypothèses, pas de données de production observées :

• 1,000 jobs d’agent par mois.
• Chaque job consomme au total 10,000 tokens d’entrée non mis en cache et 2,000 tokens de sortie sur GPT-6 Astra. Le contenu renvoyé par la recherche est inclus dans l’enveloppe d’entrée.
• Chaque job effectue un appel de recherche web.
• Dans le scénario Agents API hébergé, chaque job ouvre une nouvelle session de conteneur de 1 GB, facturée au tarif publié de $0.03. Réutiliser une sandbox réduirait ce poste.
• Dans le scénario SDK, un worker partagé est supposé coûter $40 par mois et offrir une capacité suffisante. Stockage, réseau et travail humain sont exclus.

La part du modèle revient à $0.10 en entrée et $0.10 en sortie, soit $0.20 par job. Pour la combinaison supposée de 12,000 tokens, cela représente $0.0167 par tranche de 1,000 tokens de modèle agrégés. Un appel de recherche web ajoute $0.01, portant la dépense OpenAI commune à $0.21 par job.

À 1,000 jobs, Agents API assortie d’un nouveau conteneur hébergé de 1 GB pour chaque job coûte $240 : $210 pour l’usage commun des modèles et de la recherche, plus $30 de conteneurs. Le scénario SDK coûte $250 : les mêmes $210 d’usage OpenAI, auxquels s’ajoutent les $40 supposés pour le worker. En dépense directe, les conteneurs hébergés l’emportent à ce faible volume.

À 10,000 jobs, le scénario managé et hébergé atteint $2,400 : $2,100 de dépense commune plus $300 de conteneurs. Le scénario SDK atteint $2,140 avec le worker partagé supposé. Le point de bascule du coût de calcul se situe à 1,334 nouvelles sessions de conteneur par mois : c’est le premier nombre entier de sessions pour lequel $0.03 par session dépasse $40.

Le scénario Agents API autohébergé constitue la ligne la plus importante. Si Agents API utilise le même worker supposé à $40, son total pour 10,000 jobs s’élève lui aussi à $2,140. Le harness Codex reste managé, mais la facture d’exécution rejoint celle du scénario SDK, car OpenAI n’ajoute aucuns frais propres au harness.

La facture monétaire oublie encore la variable principale : le temps d’ingénierie. Au-dessus du point de bascule, économiser $260 par mois sur le calcul n’a aucun intérêt si le SDK mobilise plusieurs heures de travail plateforme. En dessous, un système SDK mature peut ne presque rien coûter à maintenir.

Pour imposer des plafonds budgétaires stricts à l’une ou l’autre architecture, associez vos estimations de charge aux garde-fous définis au niveau du projet dans Contrôles budgétaires pour les API d’agents IA en 2026. Une estimation sert à planifier, pas à faire respecter une limite.

Migration vers Agents API : le vrai coût d’un départ du SDK

Passer d’Agents SDK à Agents API est une migration de runtime, pas un simple changement de nom de package. Les définitions d’agents et les schémas d’outils peuvent sembler familiers, mais les identifiants de session, les sessions du SDK, les conversations Responses, les sessions Agents API et les sandboxes sont des ressources différentes. Traitez l’état comme une donnée qui franchit une frontière, pas comme un identifiant directement transférable.

1. 1

   Figer le contrat de comportement

   Consignez les instructions actuelles de l’agent, les schémas d’outils, les points d’approbation, la forme de sortie, le budget de tokens et la politique d’échec. Conservez le même modèle et les mêmes outils pendant la comparaison afin de ne pas confondre une variation de qualité avec un progrès du runtime.

2. 2

   Transposer la configuration de l’agent et des outils

   Transférez le modèle, les instructions, les connexions MCP et les définitions de fonctions dans la configuration Agents API. Les gestionnaires de fonctions applicatifs ont toujours besoin d’un service qui reçoit les appels et renvoie les résultats ; l’orchestration managée ne suffit pas à les héberger.

3. 3

   Tracer la frontière de l’état

   Démarrez les nouvelles conversations sous forme de sessions Agents API et enregistrez leurs identifiants avec les fiches de conversation de l’application. Gardez les anciens historiques du SDK lisibles pendant la transition. Si l’ancien contexte doit perdurer, transformez uniquement l’état métier nécessaire en entrée explicite au lieu de faire passer une session SDK pour une session Agents API.

4. 4

   Remplacer la plomberie du cycle de vie

   Remplacez le point d’entrée du runner intégré au processus par la création de sessions, les événements, les éléments enregistrés, les actions requises, les webhooks, l’annulation et la suppression. Rendez chaque webhook et chaque résultat de fonction idempotents, car la gestion de l’état ne supprime pas le risque de livraison en double à la périphérie de votre application.

5. 5

   Tester en parallèle et valider les régressions

   Soumettez le même jeu d’évaluation aux deux solutions. Comparez la réussite des tâches, le total des tokens d’entrée et de sortie, les appels d’outils, le temps écoulé, le comportement de reprise et l’intervention humaine. Ne déplacez le trafic que lorsque la nouvelle voie respecte l’ancien contrat.

Un budget de migration indicatif rend l’arbitrage concret. Supposons un workflow existant doté de trois outils de type fonction, de sessions persistantes et d’une approbation humaine. Prévoyez 24 heures d’ingénierie à $150 par heure : 6 heures pour la configuration et la transposition des outils, 8 pour les sessions et le cycle de vie, 6 pour les webhooks, la reprise et l’idempotence, puis 4 pour les régressions et les contrôles de coût. Soit un coût de migration ponctuel de $3,600.

Si la compaction, la reprise, les sessions et l’orchestration managées permettent d’économiser, par hypothèse, 6 heures d’ingénierie chaque mois, le gain de main-d’œuvre atteint $900 par mois et l’investissement est amorti en quatre mois. Si le chemin SDK actuel ne demande qu’une attention occasionnelle, l’amortissement peut disparaître. C’est tout le sens de ces hypothèses : la migration se justifie par la baisse du travail opérationnel, pas par des tokens moins chers.

Dans quels cas faut-il rester sur Agents SDK ?

Ne migrez pas si les garanties de la bêta publique en matière de données ne répondent pas aux exigences des achats. La présentation actuelle d’Agents API indique que la résidence des données est limitée aux États-Unis et que le Zero Data Retention n’est pas pris en charge. Une sandbox autohébergée ne change rien à cette politique, puisque le harness et la session restent dans le service managé.

Conservez Agents SDK dans l’un des cas suivants :

• Votre runtime doit s’exécuter avec un ordonnanceur personnalisé, une frontière transactionnelle ou une enveloppe de latence directement contrôlée par l’application.
• Votre politique de stockage, d’export des traces ou de résidence des données n’est pas compatible avec la bêta publique managée.
• Votre agent dépend d’une souplesse entre fournisseurs ou d’une abstraction de modèles qui ne doit pas reposer sur le harness Codex.
• Votre système SDK dispose déjà d’une compaction, d’une reprise, d’une observabilité et d’un déploiement fiables, avec peu de maintenance continue.
• L’essentiel du travail est court et sans état ; une session managée et durable supprime donc peu d’infrastructure.

La bêta publique constitue aussi un choix de maturité. OpenAI indique qu’elle évoluera rapidement avant la disponibilité générale. Une équipe au calendrier strict de gestion des changements peut préférer l’évaluer maintenant et migrer une fois le contrat stabilisé.

Le SDK a, lui aussi, son cas d’exclusion. Une startup légère ne devrait pas le choisir uniquement pour éviter un verrouillage fournisseur théorique, tout en reconstruisant en coulisses les sessions, la reprise, le cycle de vie des sandboxes et l’orchestration. Un contrôle que le produit n’exploite jamais devient une dette de maintenance.

Pour les agents qui doivent exécuter du code, comparez séparément la couche d’environnement avec Les meilleures sandboxes de code pour agents IA en 2026. Le choix d’une sandbox ne permet pas de déterminer qui doit posséder l’état d’orchestration.

Les résultats clients donnent une direction, pas une garantie

Les premiers chiffres favorisent la solution managée, mais il s’agit de résultats clients publiés dans l’annonce d’OpenAI du 10 septembre, pas d’un benchmark indépendant et contrôlé. SafetyKit a fait état d’une baisse de 60% du coût par dossier. Hypha a signalé une réduction de 86% des réponses d’agent en échec après avoir séparé le harness managé de sa sandbox. Ciridae a rapporté une progression du score d’évaluation de 0.71 à 0.85 et une latence réduite de 4x.

Ces résultats prouvent que la frontière du runtime peut compter. Ils ne permettent pas de prédire les économies de votre migration : l’article ne normalise ni l’architecture antérieure des clients, ni la combinaison de modèles, ni le volume de tokens, ni la difficulté des tâches, ni le travail d’ingénierie. Servez-vous de ces retours pour justifier une évaluation en parallèle, pas pour établir une prévision.

FAQ sur OpenAI Agents API et Agents SDK

Pourquoi utiliser OpenAI Agents SDK ?

Utilisez OpenAI Agents SDK lorsque votre application doit garder la maîtrise directe du déploiement, du stockage, des décisions d’approbation, de l’implémentation des outils et de la boucle du runtime. Vous bénéficiez ainsi des primitives d’agents d’OpenAI sans déplacer l’orchestration dans Agents API, le service managé.

OpenAI Agents SDK ou PydanticAI : lequel choisir ?

Il s’agit d’un autre comparatif de frameworks. Décidez d’abord si vous voulez confier à OpenAI le harness Codex via Agents API, ou conserver dans l’application un runtime fondé sur un SDK ; comparez ensuite les frameworks SDK dans le second scénario.

Quel est le meilleur SDK pour un agent IA ?

Aucun SDK ne convient à toutes les architectures. OpenAI Agents SDK est un excellent choix si sa boucle TypeScript ou Python, ses outils, ses handoffs, ses garde-fous, ses sessions et ses intégrations OpenAI répondent aux besoins de votre application, et si vous souhaitez garder la maîtrise du déploiement.

OpenAI Agents SDK est-il gratuit ?

Agents SDK pour Python est sous licence MIT, le package n’entraîne donc aucuns frais de licence. Vous payez néanmoins les appels de modèles, les outils payants, les services de sandbox et l’infrastructure qui exécute votre application.

Comment utiliser OpenAI Agents SDK ?

Installez le package officiel TypeScript ou Python, définissez un agent avec des instructions et des outils, choisissez une seule stratégie d’état, puis exécutez-le dans votre application. Ajoutez approbations, persistance, tracing et sandboxing uniquement là où le workflow l’exige.

Combien coûte un agent IA OpenAI ?

Additionnez entrées du modèle, entrées mises en cache, sorties, appels d’outils, sandbox ou calcul applicatif, services tiers et travail opérationnel. Agents API n’ajoute aucuns frais propres au harness ; selon les hypothèses de cet article, le coût direct de l’environnement bascule à 1,334 nouvelles sessions de conteneur de 1 GB par mois face à un worker partagé à $40.

L’API OpenAI est-elle gratuite ou payante ?

L’usage des modèles et des outils payants de l’API OpenAI est mesuré selon la tarification de l’API. Un abonnement ChatGPT constitue un contrat produit distinct et ne couvre pas l’usage de l’API par une application Agents API ou Agents SDK.

Pourquoi payer $20 pour ChatGPT ?

Cette question concerne l’abonnement ChatGPT, pas le choix entre Agents API et Agents SDK. Un abonnement ChatGPT donne accès au produit ChatGPT selon les conditions de l’offre ; l’usage de l’API OpenAI est facturé séparément.

OpenAI Agent Builder est-il gratuit ou payant ?

Agent Builder était inclus dans la tarification standard des modèles de l’API, mais il ne correspond à aucun des deux runtimes comparés ici. OpenAI indique mettre progressivement fin à Agent Builder, dont l’arrêt est programmé le 30 novembre 2026.

L’action à lancer lundi

La semaine prochaine, choisissez un workflow de longue durée et menez une comparaison en parallèle. Gardez constants le modèle, les instructions, le budget de tokens, les outils et le jeu d’évaluation. Envoyez les nouvelles conversations de test vers Agents API, maintenez les historiques utilisateurs existants sur la voie SDK et retenez le même environnement d’exécution des deux côtés si vous souhaitez isoler la valeur du harness managé.

Relevez la réussite des tâches, le total des tokens, les appels d’outils payants, les sessions de facturation des sandboxes, les incidents de reprise, les interventions humaines et le temps d’ingénierie. Choisissez Agents API si la gestion des sessions et de la reprise qu’elle supprime compense le contrôle abandonné. Conservez Agents SDK si le service managé échoue à une exigence sur les données ou économise trop peu de temps d’exploitation pour amortir la migration.

Avant de changer le runtime d’un agent, récupérez la checklist d’audit des workflows métier fondés sur l’IA.