OpenAI ouvre l'Agents API et vend le harnais derrière Codex

OpenAI a passé les deux dernières années à vendre aux développeurs des appels de modèles, et plus récemment un framework pour câbler des agents entre eux. Le 10 septembre 2026, l'entreprise a commencé à vendre autre chose : la machinerie intermédiaire. Elle a ouvert son Agents API en bêta publique, donnant à tout développeur l'accès au « Codex harness » géré (la boucle d'agent et l'infrastructure derrière Codex) par un seul appel d'API.

À lire aussi: L'action ServiceNow a perdu 27 % quand la peur de l'IA a gagné le logiciel · Cloudflare rachète Deno pour rendre Workers auto-hébergeable.

La promesse est délibérément étroite et, pour les équipes qui ont construit des agents de longue durée, immédiatement reconnaissable. Vous décrivez la tâche, le modèle, les outils et l'environnement d'exécution. OpenAI s'occupe de tout le reste. Cela inclut les parties que la plupart des équipes sous-estiment jusqu'à ce qu'elles aient plusieurs mois de développement derrière elles : maintenir une session en vie, gérer une fenêtre de contexte qui déborde, réessayer les étapes échouées et coordonner un travail qui doit survivre plus longtemps qu'un seul cycle requête-réponse.

C'est un mouvement de productisation autant que technique. OpenAI n'est plus seulement le fournisseur de l'intelligence qu'utilise un agent; elle veut désormais être le runtime dans lequel vit l'agent.

La partie qu'OpenAI vend réellement

OpenAI propose déjà des briques dans ce domaine. La Responses API permet aux développeurs de combiner des modèles avec des capacités intégrées comme la recherche web, la recherche de fichiers et l'usage de l'ordinateur, et l'Agents SDK aide à définir et orchestrer des flux de travail d'agents. Ce que ces outils laissent à votre charge, c'est l'infrastructure autour du modèle, le runtime, la gestion de session, les réessais, le cycle de vie du bac à sable et l'état.

L'Agents API absorbe cette couche dans un service géré. Comme le rapporte Anirban Ghoshal d'InfoWorld, le service empaquette l'orchestration, la gestion du contexte et l'infrastructure d'exécution dans une seule API, OpenAI hébergeant et maintenant le harnais. La proposition de valeur sur laquelle les analystes reviennent est une réduction de la complexité d'ingénierie : plus de file d'attente, plus de base de données d'état, plus de flotte de bacs à sable, plus de routine de compactage ni de politique de réessai pour une équipe à posséder et à astreindre.

Selon la documentation de l'API, le harnais géré prend en charge :

• L'exécution de commandes et de code dans un bac à sable.
• L'application de compétences et d'instructions pertinentes.
• La connexion à des données externes via des outils ou des serveurs MCP.
• Le pilotage de l'agent pendant qu'il travaille.
• Le résumé du travail précédent pour gérer sa fenêtre de contexte.
• La décomposition du travail en sous-tâches et la délégation à des sous-agents.
• La reprise d'une session là où elle s'est arrêtée.

Les applications fournissent toujours les outils et choisissent où le travail s'exécute. Tout ce qui se trouve au-dessus de cette ligne est désormais le problème d'OpenAI.

La distinction entre un framework et un service géré est le nœud. L'Agents SDK, disponible depuis mars 2025, donne aux développeurs un ensemble de bibliothèques à exécuter eux-mêmes. L'Agents API est son pendant hébergé : un service où le fournisseur opère la boucle. Les frameworks échangent la flexibilité contre le contrôle; les runtimes gérés échangent le contrôle contre moins de code à posséder. Ce qu'OpenAI affirme explicitement, c'est qu'il s'agit du même harnais qu'elle utilise en interne (et non d'une réimplémentation réservée aux développeurs) une affirmation significative sur l'épreuve du terrain, même si les contraintes de la bêta ci-dessous signifient qu'il ne s'agit pas encore d'un substitut à l'identique pour toutes les charges de travail.

Des sessions qui persistent, un contexte qui se compacte tout seul

L'API s'organise autour de quatre concepts, selon la documentation : l'agent (modèle, instructions, outils et serveurs MCP), l'environnement (un bac à sable optionnel pour les fichiers, les commandes et les compétences), la session (une instance d'agent durable qui répond à de nouvelles entrées), et les événements et items (les entrées envoyées et les sorties produites).

La durabilité est le point d'orgue. Une session peut tourner pendant des minutes, des heures ou des jours, OpenAI conservant l'état pour que les développeurs poursuivent le travail d'un tour à l'autre sans reconstruire le contexte de conversation. Le compactage du contexte est automatique : à mesure qu'une session approche de sa limite, le contenu antérieur est condensé sans que le développeur écrive de logique de compactage. Lorsque le mode multi-agents est activé, le compactage est appliqué indépendamment à l'agent racine et à chaque sous-agent, afin que leurs contextes n'interfèrent pas.

La coordination des sous-agents suit le même schéma géré. L'agent racine peut engendrer des sous-agents, leur confier des tâches délimitées, attendre les résultats et synthétiser une réponse finale, le texte de Simon Carter notant une valeur par défaut de max_concurrent_subagents à trois comme point de départ recommandé. Une session peut aussi être reprise après un échec, supprimée quand elle n'est plus nécessaire, ou pilotée en cours de tour pendant qu'elle travaille, ce dernier point compte pour tout ce qui touche à des systèmes de production.

Le guide de démarrage rapide rend la chose concrète : un assistant de codage qui écrit tree.py, l'exécute et rapporte une arborescence de répertoires, OpenAI gérant l'agent, sa conversation et le bac à sable. Le premier exemple fonctionnel tient en un seul appel du SDK.

Sur le plan opérationnel, les applications suivent une session en diffusant la sortie ou en s'abonnant à des webhooks, afin d'apprendre quand un agent a terminé ou a besoin d'une entrée plutôt que d'interroger à l'aveugle. La documentation avertit qu'un tour terminé ne garantit pas que chaque outil a réussi (des événements se terminant par turn.failed, turn.cancelled ou session.failed indiquent un échec ou une annulation) et qu'un flux déconnecté doit être récupéré en récupérant les items sauvegardés de la session avant de réessayer. Ce conseil rappelle que gérer un agent de longue durée tient autant à la gestion des échecs qu'à la qualité du modèle, précisément le travail qu'OpenAI propose désormais d'absorber.

Trois endroits pour exécuter le travail

L'environnement d'exécution est l'une des rares décisions que l'API laisse au développeur, et il y a trois options :

1. Un bac à sable hébergé par OpenAI, la même infrastructure de bac à sable que derrière Codex, configurable avec des fichiers, des paquets, des compétences et des plugins, et facturée aux tarifs standards des conteneurs.
2. Un bac à sable auto-hébergé, exécutez codex exec-server dans votre propre environnement. Il s'enregistre avec une clé restreinte et se connecte en sortie via WebSocket, si bien qu'aucun port entrant n'a besoin d'être ouvert.
3. Des bacs à sable partenaires, Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop et Vercel sont tous pris en charge, permettant aux entreprises de garder le calcul dans leur propre VPC et de choisir leur approche des fichiers, des secrets et de la configuration.

Le harnais lui-même est en outre open source via le dépôt Codex, selon le rapport de Carter, de sorte que les équipes peuvent inspecter son fonctionnement quel que soit le runtime choisi.

L'économie : aucun frais pour le harnais

La tarification est inhabituellement simple, et c'est la partie la plus susceptible de peser sur les décisions d'adoption. OpenAI ne facture aucun frais supplémentaire pour l'Agents API elle-même. L'usage des modèles est facturé aux tarifs standards de l'API du modèle choisi, les outils OpenAI utilisent leurs tarifs standards, et les bacs à sable hébergés par OpenAI sont facturés aux tarifs standards des conteneurs. Le calcul que vous exécutez vous-même, ou que vous confiez à un fournisseur partenaire, est facturé par celui qui l'opère.

Pour les équipes qui pèsent le construire-contre-acheter, cela supprime une source courante d'hésitation : il n'y a pas de taxe de harnais séparée qu'il faudrait justifier face au coût de l'ingénierie du runtime en interne. Le compromis, c'est qu'une fois les pièces gérées en place, les remplacer est un chantier plus lourd que de changer un point de terminaison de modèle.

Les limites qui comptent : résidence aux États-Unis uniquement et pas de ZDR

Les contraintes de la bêta ne sont pas des notes de bas de page. Pendant la bêta publique, la résidence des données est limitée aux États-Unis, et le service ne prend pas en charge la Zero Data Retention (ZDR), une limitation qui s'applique même lorsqu'une équipe fournit son propre bac à sable auto-hébergé. OpenAI n'a donné aucun calendrier public pour l'élargissement de la résidence.

Cette combinaison est un véritable obstacle pour une large part du marché. Les charges de travail de la santé, des services financiers, du juridique et de l'Europe reposent souvent sur le maintien des données dans une juridiction donnée et sur des garanties contractuelles que les invites et les sorties ne sont pas conservées. InfoWorld cite des analystes qui font exactement ce point, l'un notant que la lacune de la ZDR pourrait limiter l'adoption dans les secteurs réglementés et un autre observant que les équipes basées dans l'UE ont une contrainte dure à vérifier avant d'envisager toute migration. Les start-ups, les entreprises SaaS et les grands groupes déjà standardisés sur OpenAI sont, en revanche, les premiers adoptants les plus probables.

La concurrence et la question de l'enfermement

Le runtime d'agents géré est déjà une catégorie encombrée, ce qui compte parce que cela déplace le cadre de « OpenAI peut-elle le faire ? » à « pourquoi choisir la version d'OpenAI ? »

• Les Claude Managed Agents d'Anthropic sont en bêta publique depuis avril 2026.
• L'Amazon Bedrock AgentCore d'AWS a atteint la disponibilité générale pour son harnais géré en juin 2026 et effectue la même catégorie de travail (la boucle, l'exécution des outils, le contexte, l'état et la récupération) tout en laissant les clients utiliser n'importe quel modèle et changer de fournisseur en cours de session sans perdre le contexte.
• Le Foundry Agent Service et LangGraph de Microsoft se situent dans le même voisinage, selon InfoWorld.

La différence concurrentielle est la portabilité. Un harnais géré qui accepte plusieurs modèles abaisse le coût du changement; un harnais lié aux modèles, à la gestion du contexte, aux outils, à l'orchestration et à l'environnement d'exécution d'un seul fournisseur l'augmente. Les analystes cités par InfoWorld désignent l'enfermement comme la principale préoccupation, et notent qu'une dépendance plus profonde peut affaiblir la position de négociation d'une entreprise sur les prix et les conditions. Les entreprises poursuivant des stratégies multi-modèles pourraient préférer un harnais indépendant ou une répartition hybride.

L'accès, et une horloge de migration

L'accès est ouvert à tout développeur. La création d'une clé d'API d'application nécessite api.agents.read et api.agents.write pour les opérations de session, plus api.responses.write pour l'inférence de modèle. Les requêtes portent l'en-tête OpenAI-Beta: agents=v1; les SDK officiels l'ajoutent automatiquement pour ceux qui utilisent une bibliothèque cliente plutôt que cURL.

Il y a aussi une échéance attachée au changement plus large. OpenAI met hors service Agent Builder et Evals le 30 novembre 2026, orientant les flux de travail basés sur le code vers l'Agents SDK et l'Agents API. Les équipes qui utilisent l'un ou l'autre outil disposent d'une fenêtre finie pour planifier une migration, et l'arrivée de l'API gérée leur donne une cible vers laquelle se diriger, ou une raison de reconsidérer entièrement l'approche.

Ce qu'il faut surveiller

• La résidence et la conservation. Savoir si OpenAI ajoute une résidence régionale des données ou une voie ZDR est la contrainte la plus susceptible de déterminer l'adoption en entreprise. Aucun calendrier n'a été donné, alors guettez-le dans la documentation des contrôles de données de l'API.
• Le coût réel à l'échelle. « Aucun frais de harnais » est propre sur une page de tarifs. Le chiffre qui compte est le coût total une fois additionnées les sessions de longue durée, les heures de conteneur des bacs à sable et la consommation de jetons, en particulier face aux runtimes auto-hébergés et partenaires.
• La portabilité des modèles. Savoir si l'Agents API prend en charge des modèles autres que ceux d'OpenAI (ou permet un changement de fournisseur en cours de session comme le vante Bedrock AgentCore) décidera de la part d'enfermement que les équipes acceptent réellement.
• La mise hors service du 30 novembre. Surveillez la vitesse à laquelle les utilisateurs d'Agent Builder et d'Evals sont dirigés vers l'Agents SDK et l'Agents API, et si les chemins de migration tiennent.
• La pression concurrentielle. Avec Anthropic et AWS qui livrent déjà des runtimes gérés comparables, surveillez si OpenAI rivalise sur les fonctions, le prix ou l'ouverture, et si la position du « sans frais supplémentaires » survit à la disponibilité générale.

Image de couverture : des développeurs travaillant sur des ordinateurs portables lors d'un événement de programmation. Photo de Matthew (WMF), via Wikimedia Commons, CC BY-SA 3.0.