Le 10 septembre, OpenAI a lancé l’Agents API en bêta publique, « mettant à la disposition des développeurs, via une API simple et flexible, le harnais et l'infrastructure qui propulsent Codex ». Lors du DevDay du 29 septembre, elle s'est enrichie de l'utilisation de l'ordinateur (computer use), d'un pendant natif pour AWS et d'un voisin : les nouveaux dots permanents de ChatGPT reposent sur ce même harnais Codex.
Pour un développeur qui conçoit un produit d'agents, c'est une excellente nouvelle : le harnais que vous vous apprêtiez à coder tant bien que mal devient le problème de quelqu'un d'autre. En revanche, pour un ingénieur dont l'équipe utilise déjà Claude Code et Codex sur une base de code en production, la perspective est bien différente. L'API répond à la question « comment faire tourner un agent pendant des heures ? », mais pas à « comment mon équipe sait-elle ce que six d'entre eux ont fabriqué, et qui a validé le site web sur lequel l'un d'eux vient de se connecter ? ». C'est précisément à cette seconde question que répond Sharkly.
En résumé
L'Agents API héberge le harnais de Codex : sessions persistantes, compactage de contexte, recherche d'outils, sous-agents et bac à sable (sandbox) hébergé chez OpenAI, sur votre infrastructure ou auprès de neuf partenaires, sans frais supplémentaires en dehors des jetons, des outils et du temps de conteneur. Le DevDay y a ajouté le computer use, où votre application approuve chaque nouvelle origine web ainsi que chaque connexion (l'approbation de l'origine ne constituant pas une validation des actions individuelles), ainsi que Bedrock Managed Agents, qui exécute ses fonctionnalités fondamentales au sein d'AWS. En revanche, rien de tout cela ne prend en charge la dimension collaborative d'équipe : qui a attribué la tâche, quel agent s'en charge, ce qui a abouti, ce qui a échoué et qui valide le résultat final.
Qu'est-ce que l'Agents API, et que gère OpenAI ?
La présentation d'OpenAI résume l'API à quatre concepts fondamentaux. Un Agent représente « le modèle, les instructions, les outils et les serveurs MCP mis à sa disposition ». Un Environment (environnement) est « un bac à sable ou une machine facultative où l'agent accède aux fichiers, charge des compétences et exécute des commandes ». Une Session est « une instance persistante d'un agent qui accomplit des tâches et réagit aux entrées ». Enfin, les Events and items (événements et éléments) constituent les entrées transmises et les sorties générées en retour.
Vous créez une session avec une configuration d'agent, lui confiez une tâche une fois l'environnement prêt, suivez son déroulement par streaming ou via des webhooks, puis envoyez d'autres tâches ou consignes de guidage au sein de cette même session. Voici l'exemple tiré de la documentation, raccourci :
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
L'essentiel des nouveautés tient en deux lignes. multi_agent active la délégation vers des sous-agents avec une limite de concurrence, tandis que environment.type détermine l'emplacement d'exécution du code : openai_hosted, self_hosted, ou l'un des bacs à sable partenaires (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel).
La documentation résume cette répartition du travail en une phrase : « OpenAI gère les sessions, l'orchestration, le compactage du contexte et la reprise sur incident, tandis que votre application fournit les outils et choisit son environnement d'exécution ».
| Ce qu'OpenAI prend en charge | Ce qui reste à votre charge |
|---|---|
| La boucle de l'agent : appels de modèle, utilisation des outils, réessais | La tâche, ainsi que les critères de validation (« definition of done ») |
| Le compactage du contexte lorsqu'une session approche de sa limite | Les outils : serveurs MCP, fonctions, outils intégrés |
| La recherche et le chargement des outils | Les identifiants et secrets, via des identifiants de coffre-fort (vault IDs) |
| La décomposition et la coordination des sous-agents | Le choix de l'environnement et sa configuration |
| La reprise de session et le guidage | Tout ce qui se passe une fois la session terminée |
La consommation de modèles est facturée aux tarifs habituels de l'API correspondante, les outils aux tarifs standards, et les bacs à sable hébergés par OpenAI au tarif des conteneurs ; l'article de lancement précise qu'« il n'y a pas de frais supplémentaires pour l'utilisation de l'Agents API ». La documentation mentionne clairement deux limites : l'API « ne prend actuellement en charge la résidence des données qu'aux États-Unis et ne propose pas la rétention zéro des données (Zero Data Retention ou ZDR) », et opter pour un bac à sable auto-hébergé ne le rend pas pour autant éligible au ZDR. Si l'un de ces points est déterminant pour votre conformité, internaliser le bac à sable ne changera rien à la donne.
Les nouveautés annoncées au DevDay
L'utilisation de l'ordinateur (Computer use). Ajoutez l'outil computer_use, activez un environnement graphique de bureau sur un environnement hébergé par OpenAI, et l'agent prend les commandes d'un navigateur hébergé. Le guide d'utilisation du computer use structure le flux de travail autour d'événements d'approbation. Le navigateur sollicite l'accord de l'utilisateur avant d'accéder à chaque nouvelle origine de site web, sites publics compris. Les connexions se présentent sous forme de demandes distinctes que votre application restitue avec des champs pour l'e-mail, le mot de passe et le code de vérification ; les passkeys et la connexion par code QR ne sont pas prises en charge, et seul l'agent principal — et non un sous-agent — peut demander des identifiants. Une phrase mérite toute votre attention : « L'approbation de l'origine n'impose aucune confirmation avant des actions individuelles ». Pour les achats ou les modifications destructrices, la documentation recommande de restreindre le navigateur hébergé aux ressources incapables de les réaliser, ou d'utiliser un environnement de navigateur sous votre contrôle. Le récapitulatif du DevDay indique que le computer use est disponible « via l'API ainsi que dans Codex et ChatGPT Work sur les forfaits Pro 500 et Enterprise ».
Bedrock Managed Agents, propulsé par OpenAI. OpenAI et Amazon ont repris « les fonctionnalités clés de l'Agents API » en les adaptant pour fonctionner nativement dans AWS. La page produit d'AWS le présente en préversion et précise que l'environnement d'exécution de l'agent ainsi que l'inférence des modèles restent cantonnés à AWS, chaque agent disposant de sa propre identité et de ses propres autorisations AWS.
Les dots reposent sur le même harnais. Decrypt rapporte que le harnais de Codex « propulse désormais les dots et est open source ». Les dots sont les agents permanents de ChatGPT, dotés chacun de leur propre machine dans le cloud, et notre guide explicatif sur les dots détaille leurs points forts.
Une seule et même boucle anime donc désormais un agent de code, une session d'API, un agent AWS et un assistant disponible en continu. Le harnais converge. Mais ce sont les événements d'approbation qui retombent directement sur l'équipe : chacun d'eux constitue une question au sein d'une session, à laquelle doit répondre la personne qui garde le flux ouvert. Lorsque cinq sessions sollicitent une réponse simultanément, il faut bien déterminer qui a l'autorité pour approuver quelle origine, et consigner cette décision. Il s'agit là d'une problématique de barrières d'approbation (approval gates), et nous avons exploré sa déclinaison côté machine dans les garde-fous pour le computer use de GPT-6 Astra.
Ce qu'elle ne gère pas : la dimension collaborative d'équipe
Une session n'a conscience que d'elle-même. Elle ignore que trois autres sessions interviennent sur le même dépôt, ou que le résultat d'une quatrième est en attente de lecture depuis mardi. Ce sont des problématiques de gestion d'équipe, et elles apparaissent dès lors que plusieurs personnes font tourner plusieurs agents en parallèle.
Cinq questions que l'API laisse en suspens, par conception :
- Qui a attribué cette tâche, et à quel ticket est-elle rattachée ? Une session dispose d'un identifiant et des métadonnées que votre code y inscrit. Un responsable, un Sprint ou un lien vers le ticket d'origine n'existent que si vous les y insérez vous-même.
- Quels dépôts et branches ont été modifiés ? Le diff doit être acheminé vers un endroit où un réviseur peut l'examiner.
- Qu'est-ce qui est terminé, qu'est-ce qui a échoué, qu'est-ce qui est en attente ? Les événements défilent en continu tant que vous êtes à l'écoute, ou vous parviennent par webhook. Rien ne s'accumule dans une file de résultats en attente d'une intervention humaine.
- Qui valide le résultat ? Un événement d'approbation concerne un site web ou une connexion, pas le travail accompli. « La session s'est achevée » et « une personne a examiné les preuves et validé le résultat » sont un seul et même événement, à moins que vous ne construisiez le second de toutes pièces.
- Qu'en est-il des agents qui ne proviennent pas d'OpenAI ? Utiliser Claude Code pour un type de tâche et Codex pour un autre implique deux modèles de session et deux interfaces distinctes à surveiller.
Vous pouvez évidemment bâtir ces cinq éléments au-dessus des événements : un tableau de bord, un webhook, un champ de statut, une colonne de révision. Puis quelqu'un finit par demander : « au fait, le correctif sur l'export a-t-il été déployé ? », et la réponse est perdue au fond d'un historique de terminal que personne n'a sauvegardé. Notre article sur la gestion des tâches d'agents IA aborde cette approche « maison ».
Sous-agents au sein d'une session ou tâches sur un tableau de bord ?
Le paramètre max_concurrent_subagents est la réponse apportée par l'API au besoin de parallélisation, et il s'avère pertinent pour certains types de charges de travail. C'est précisément le compromis que nous évoquions lorsque Codex a porté sa limite de sous-agents à 64 : les sous-agents partagent un parent commun, consolident leurs réponses en une seule synthèse et sont révisés comme un unique résultat.
Privilégiez les sous-agents au sein d'une session lorsque les opérations portent essentiellement sur de la lecture, sont indépendantes et que seule la réponse globale compte : explorer quatre API, scanner une base de code à la recherche d'un motif particulier, ou rassembler des indices lors d'un incident.
Préférez des tâches distinctes lorsque chaque élément produit du code qui doit faire l'objet d'une revue individuelle : une migration, une fonctionnalité sur un module spécifique ou un correctif touchant un fichier partagé. Dans Sharkly, chaque exécution bénéficie de son propre arbre de travail git isolé (worktree) sur une machine dont vous avez la maîtrise, et chaque résultat réintègre sa tâche dédiée avec son diff, son journal d'exécution et son relecteur attitré. Écraser quatre modifications lourdes en écriture dans un unique résumé de sous-agents revient à masquer quatre décisions derrière une seule.
Foire aux questions
Quel modèle fait tourner le computer use ? Les exemples de la documentation s'appuient sur gpt-6-astra. Consultez le guide avant de supposer qu'un autre modèle fonctionne avec l'outil computer_use.
Sharkly exécute-t-il des sessions de l'Agents API ? Sharkly fait tourner des agents de code en ligne de commande (CLI) installés sur vos ordinateurs, tels que Codex et Claude Code, en tant qu'environnements d'exécution (Runtimes). Les sessions de l'Agents API relèvent d'un service hébergé et non d'un Runtime installé ; il convient donc de les traiter comme un canal d'exécution distinct.
Où s'effectue la revue humaine ? Avec l'Agents API, là où vous décidez de l'implémenter : les événements d'approbation encadrent l'accès aux sites web et les connexions, pas la validation du travail livré. Dans Sharkly, un Agent peut mettre sa Tâche en attente de revue humaine, la requête arrive dans la boîte de réception du responsable, et une personne modifie le statut après avoir examiné la réponse, le journal d'exécution et le diff.
La juste place de chaque couche
Une session persistante sur l'infrastructure d'OpenAI est l'élément le plus pratique de cette annonce, mais aussi le plus captif. Pour une équipe d'ingénierie, cela a toute son importance : le meilleur agent de code du marché évolue en permanence, et une équipe dont les états de révision et les règles d'attribution sont enfermés dans la base de sessions d'un seul fournisseur devra reconstruire son workflow à chaque fois que le leader change.
Si vous développez un produit piloté par des agents ou un service backend, l'Agents API représente le bon niveau d'abstraction, tout comme Bedrock Managed Agents pour les équipes qui doivent impérativement rester au sein d'AWS. Vous bénéficiez du harnais sans avoir à le maintenir et de bacs à sable sans devoir les provisionner. Il est même probable que vous n'ayez aucunement besoin d'un tableau de tâches : votre application en tient lieu.
En revanche, si vos agents sont de véritables coéquipiers opérant sur votre propre base de code — lancés par des humains, relus par des humains, déployés via vos dépôts et gestionnaires de tickets existants —, l'équation n'est plus la même. Codex et Claude Code assurent l'exécution. Sharkly orchestre l'attribution au niveau de l'équipe, les machines connectées, le contexte des tâches, la progression, les blocages, les résultats et la revue humaine à travers l'ensemble de ces outils. Il ne remplace ni l'un ni l'autre de ces Runtimes, ni l'Agents API. Cette même question de positionnement s'applique désormais à Codex lui-même, un sujet que nous abordons dans Codex dans le cloud ou sur vos propres machines.
Louez le harnais si vous construisez un agent. Conservez la maîtrise d'une couche de gestion indépendante de tout fournisseur si vous pilotez une équipe d'agents.
Si vous faites déjà tourner plusieurs agents, Sharkly vous offre un espace centralisé pour gérer leurs tâches et leurs livrables. Sharkly ne vend pas de jetons : la consommation de modèles reste facturée via les abonnements ou les clés d'API configurés dans les outils que vous connectez.
