Agents API ouvre le harnais de Codex, mais OpenAI garde l’exploitation

14 septembre 2026 à 00:00|Auteur: Équipe éditoriale de QUASA|6 min de lecture| 1

OpenAI a ouvert le 10 septembre 2026 la bêta publique de l’Agents API, qui donne aux développeurs accès au harnais logiciel utilisé derrière Codex. L’annonce d’OpenAI précise que l’entreprise héberge et maintient ce harnais, avec ses sessions longues, sa gestion du contexte, ses appels d’outils et sa coordination de sous-agents.

La différence avec un appel de modèle isolé est opérationnelle : le client ne reçoit plus seulement une sortie, mais confie une tâche à une session durable dont OpenAI exécute la boucle. Le Blog du Modérateur confirme le statut de bêta publique, l’accès à tous les développeurs et le choix entre un environnement OpenAI, une infrastructure propre ou un fournisseur partenaire.

Une couche d’exploitation, pas un nouveau modèle

Une application ouvre une session durable Agents API qui conserve son état au-delà d’un appel de modèle isolé.

L’Agents API ne remplace pas le modèle sélectionné. À la création d’une session, l’application définit le modèle, les instructions et les outils de l’agent, choisit son environnement, puis lui transmet une tâche. Le modèle produit toujours les décisions et les sorties ; le harnais organise leur exécution dans la durée.

Dans un appel isolé, l’application envoie une entrée et traite la réponse correspondante. Pour obtenir un agent durable en interne, elle doit ajouter une boucle d’exécution, conserver l’état, réinjecter les résultats des outils, gérer les interruptions et décider comment reprendre le travail. L’Agents API transfère l’exploitation de cette couche à OpenAI, mais pas la logique métier du produit.

Le mot « harnais » désigne ici le logiciel qui relie le modèle au contexte, aux outils et au déroulement d’une tâche. Ses fondations restent consultables dans le code ouvert de Codex, tandis qu’OpenAI exploite et fait évoluer la version managée accessible par l’API.

Ce que le harnais prend effectivement en charge

Une session Agents API compacte son contexte et coordonne des sous-agents parallèles avant de réunir leurs résultats.

La session conserve son état entre plusieurs tours. Le client peut suivre les événements en continu, recevoir des webhooks, ajouter une nouvelle tâche ou réorienter l’agent pendant son travail. Il n’a donc pas à reconstruire toute la conversation à chaque reprise, même s’il demeure responsable de la conservation et de la présentation des événements dans sa propre application.

À l’approche de la limite de contexte du modèle, le service compacte les travaux antérieurs afin de conserver les informations nécessaires à la suite de la session. Cette fonction permet de travailler sur plusieurs fenêtres de contexte sans développer une logique de compactage distincte. Elle ne garantit toutefois ni la fidélité de chaque détail ni la justesse du résultat final.

Le harnais gère également la sélection et l’enchaînement des outils. La recherche d’outils charge les définitions pertinentes à la demande ; les appels programmatiques peuvent être exécutés en parallèle, chaînés ou filtrés avant le retour de leurs résultats dans le contexte. Les capacités raccordées peuvent être des fonctions clientes, des serveurs MCP ou des outils intégrés.

Lorsque le mode multi-agent est activé, l’agent principal peut diviser une tâche en sous-tâches indépendantes. Les sous-agents travaillent en parallèle avec des contextes distincts, puis l’agent principal rassemble leurs résultats. OpenAI assure cette coordination, mais le client décide d’activer la fonction et de définir les capacités disponibles.

L’environnement et les capacités restent un choix du client

Le harnais et l’environnement d’exécution sont deux composants distincts. Le client peut utiliser un bac à sable hébergé par OpenAI, sa propre infrastructure ou celle d’un partenaire. Dans le premier cas, OpenAI provisionne et administre l’espace où l’agent peut lancer du code, manipuler des fichiers et produire des artefacts.

Le caractère hébergé ne détermine pas quels fichiers, paquets, compétences, secrets ou accès réseau sont légitimes. Le client doit choisir ces ressources, limiter les permissions et encadrer les actions ayant des effets externes. Avec un environnement autohébergé, il assume en plus le calcul, le stockage, le réseau, l’isolation et le cycle de vie de cette infrastructure.

Les fonctions et serveurs MCP fournis par l’entreprise restent également sous sa responsabilité : disponibilité, authentification, validation des entrées, journalisation et effets de bord. Le harnais peut décider d’appeler une fonction autorisée ; il ne reprend pas la responsabilité de la base de données, du déploiement ou du service externe que cette fonction modifie.

Le partage des rôles dans une architecture minimale

L’Agents API exécute la boucle managée entre les outils autorisés et le bac à sable, tandis que le client garde les validations.

Dans une architecture minimale, le backend du client authentifie l’utilisateur, prépare la tâche et ouvre une session Agents API. Il configure le modèle et les outils autorisés, puis choisit l’environnement. OpenAI exécute la boucle de l’agent, maintient la session, compacte le contexte si nécessaire et renvoie les événements et artefacts produits.

Autour de cette boucle, l’application conserve les contrôles décisifs : règles métier, validation des résultats, approbation humaine des opérations sensibles, gestion des budgets, interface utilisateur et traitement des erreurs. Elle décide aussi quelles données peuvent être transmises au service. Le code d’orchestration diminue, mais la responsabilité du produit ne change pas de propriétaire.

OpenAI : session durable, boucle d’agent, compactage du contexte, reprise, orchestration des outils et coordination des sous-agents.
Client : modèle, instructions, données, outils, permissions, règles métier, validation et expérience utilisateur.
Responsabilité variable : le calcul, le stockage et le bac à sable relèvent d’OpenAI, du client ou d’un partenaire selon l’environnement retenu.

Une API sans supplément, pas une exécution gratuite

L’utilisation de l’Agents API n’entraîne pas de supplément propre au service, mais les composants consommés restent payants. La documentation technique de l’Agents API indique que les jetons sont facturés au tarif du modèle choisi, les outils OpenAI à leurs tarifs standards et les bacs à sable hébergés aux tarifs des conteneurs.

Une infrastructure interne ou partenaire ajoute ses propres dépenses de calcul, de stockage et de réseau. Le multi-agent peut aussi multiplier les exécutions et les contextes actifs. Le compactage et la recherche d’outils cherchent à réduire la quantité de contexte inutile ; ils ne rendent pas les longues sessions gratuites.

La même documentation fixe deux limites importantes de la bêta : la résidence des données de l’Agents API n’est actuellement proposée qu’aux États-Unis et le service n’est pas compatible avec Zero Data Retention, même avec un bac à sable autohébergé. Les sessions et les artefacts publiés peuvent être supprimés, mais choisir son propre environnement ne supprime pas l’état conservé par l’API.

OpenAI n’a pas encore annoncé de date de disponibilité générale. À ce stade, l’Agents API est donc une infrastructure managée pour la session et l’orchestration : OpenAI exploite le harnais de Codex, tandis que l’entreprise cliente conserve ses capacités, ses contrôles, son environnement choisi et les coûts produits par chacun de ces composants.