OpenAI "démonté et vendu" Codex

Parce que cette fois, OpenAI a « démonté et vendu » le Codex.

L'ensemble des fonctionnalités initialement cachées derrière le Codex et chargées de permettre à l'agent de continuer à travailler, d'appeler des outils, de gérer le contexte et de coordonner plusieurs agents ont été extraites et regroupées dans une API cloud que tous les développeurs peuvent appeler.

Le Codex en tant que service ?

En fait, OpenAI démantèle le Codex depuis longtemps.

Dès avril 2025, lorsque OpenAI a publié pour la première fois o3 et o4-mini, la CLI Codex était open source. C'est un peu la version OpenAI de Claude Code, installée directement dans le terminal local. Comment exécuter l'agent et comment appeler les outils sont tous clairement affichés sur GitHub. Si vous êtes prêt à faire l’effort, vous pouvez le reprendre, le modifier et l’exécuter vous-même.

Mais à cette époque, les choses étaient simplement distribuées. Que vous puissiez les utiliser et comment vous souhaitez les utiliser reste votre affaire.

Un mois plus tard, la version cloud du Codex, le produit que nous connaissons aujourd'hui, était officiellement lancée. Les utilisateurs peuvent lui confier l'entrepôt de code, et chaque tâche correspond à un bac à sable cloud indépendant. Codex peut modifier le code, exécuter des tests, corriger des bogues et gérer plusieurs tâches en même temps.

Quelques mois plus tard, en octobre 2025, OpenAI a publié le SDK Codex.

Pour faire simple, le SDK est une boîte à outils destinée aux développeurs, de sorte que Codex peut non seulement être utilisé comme un produit autonome, mais peut également être intégré dans les applications d'autres personnes. Le SDK permet aux développeurs d'utiliser quelques lignes de code TypeScript pour démarrer le même agent qui pilote la CLI Codex, obtenir une sortie structurée, conserver l'état de la tâche et continuer à s'exécuter après une pause.

Cependant, le SDK est principalement adapté à l'appel du Codex dans des programmes et n'a pas encore ouvert toutes les capacités d'interaction du Codex. Il convient parfaitement aux flux de travail en arrière-plan, aux scripts automatisés et aux programmes côté serveur. Mais si vous souhaitez créer un client complet comme Codex IDE, cela reste un peu difficile.

Ainsi, en février 2026, OpenAI a officiellement publié le Codex App Server et, pour la première fois, a systématiquement expliqué clairement le harnais dans le Codex.

OpenAI a clairement expliqué que les extensions Codex Web, CLI, IDE et Mac App semblent être des produits différents, mais qu'ils exécutent en fait le même harnais Codex en dessous, qui est la couche responsable de la boucle d'agent, du thread, de l'exécution des outils, de l'authentification et de l'état de gestion.

App Server ajoute une interface JSON-RPC bidirectionnelle à cet ensemble complet de Harness. JetBrains, Xcode ou d'autres clients n'ont pas besoin de recréer une boucle d'agent. Ils peuvent démarrer directement le serveur d'applications pour piloter le Codex complet.

Avec App Server, d'autres produits peuvent être directement connectés au harnais Codex complet.

Mais à ce stade, il reste un dernier problème à résoudre.

Le SDK contrôle l'agent Codex local, et le serveur d'applications lui-même est également un processus résident qui doit être démarré et maintenu par les développeurs. Bien que le problème de l'intégration du Codex dans le produit ait été résolu, il est encore un peu difficile de l'exécuter de manière stable dans un service en ligne.

Pour donner un exemple plus précis, si vous utilisez App Server pour créer votre propre site Web Coding Agent, le frontal a été connecté au Codex, mais lorsque l'utilisateur clique sur "Réparer cet entrepôt", vous devrez toujours trouver un moyen de résoudre un grand nombre de problèmes d'exploitation et d'infrastructure ultérieurs.

Puis le 19 août est arrivé. Ce jour-là, OpenAI a unifié la CLI, le SDK et le serveur d'applications qui avaient été ouverts au cours de l'année écoulée dans le récit de la plate-forme « Open Codex Harness », et a clairement fait passer le Codex d'un produit à une plate-forme.

Puis le 10 septembre (heure des États-Unis), soit hier, l'API Agents a été officiellement ouverte aux tests publics.

Cette fois, les développeurs n'ont qu'à indiquer quatre éléments à l'API : tâches, modèles, outils et environnements d'exécution - pour créer directement un agent. Codex Harness, qui est responsable de la compression du contexte des longues sessions, de la planification des outils et de la collaboration des sous-agents, est hébergé et maintenu par OpenAI lui-même.

Vous pouvez même choisir la machine sur laquelle l'agent travaille réellement. Vous pouvez choisir d'utiliser le bac à sable d'OpenAI, votre propre infrastructure ou des environnements tiers tels que Cloudflare, E2B et Modal. Harness est fourni par OpenAI et l'environnement d'exécution est déterminé par le développeur.

La déclaration officielle est très claire : il n'y a aucun frais supplémentaire pour l'API Agents elle-même. En d’autres termes, l’hébergement Harness, la gestion de sessions longues et d’autres fonctionnalités ne facturent pas de niveau distinct de frais de plateforme d’agent.

Les développeurs paient en fonction des modèles de jetons et des outils réellement utilisés ; si le propre sandbox d’hébergement d’OpenAI est utilisé, les ressources informatiques sont calculées séparément.

Depuis plus d'un an, OpenAI fait la même chose : diviser le Codex d'un produit spécifique en fonctionnalités réutilisables couche par couche, tout en permettant aux développeurs de se soucier de moins en moins d'eux-mêmes.

Si vous devez donner un nom à cette gamme de produits, elle est en fait très similaire au SaaS de l'époque, sauf que cette fois, ce n'est pas un logiciel qui est entretenu, mais du Codex.

Codex en tant que service.

Le harnais a également commencé à bifurquer

Bien sûr, OpenAI n'est pas le seul à lorgner sur Harness.

Lorsque DeepSeek Harness (ci-après dénommé DSH) a été publié, une équation très forte a été donnée :

Agent = Modèle + Harness.

Pour DeepSeek, le modèle ne représente que la moitié de l'agent, et l'autre moitié est le harnais qui est chargé de lui permettre de comprendre l'environnement, d'appeler les outils, de gérer l'état et de continuer à exécuter les tâches. Ce n’est que lorsque les deux se coordonnent que l’agent peut réellement accomplir ses tâches.

DSH a fait de Harness un framework ouvert hautement modulaire : les modèles, les outils, les compétences, les sessions, les bacs à sable, le stockage, la boucle d'agent, la planification et même l'interface utilisateur peuvent tous être remplacés.

Le slogan « Tout est un plug-in » n'est pas qu'une plaisanterie. Il est préférable que tout le monde écrive des plug-ins et s'adapte à DSH. En fin de compte, que DeepSeek ou d’autres modèles fonctionnent sur le dessus, le même ensemble de harnais peut être utilisé en dessous.

C'est un contraste intéressant avec la direction que prend actuellement OpenAI.

Bien qu'OpenAI ait également open source le harnais Codex, l'API Agents va évidemment dans l'autre sens : vous pouvez utiliser votre propre harnais, ou vous pouvez prendre celui open source, mais si vous trouvez cela gênant, vous pouvez simplement l'ignorer et me laisser l'organiser pour vous.

Nous le considérons donc davantage comme un « service ». OpenAI est responsable de l’hébergement et de la maintenance continue de Harness. Les développeurs n'ont qu'à décider ce qu'ils veulent que l'agent fasse, quels outils utiliser et où l'exécuter. Même si le modèle est mis à niveau à l'avenir, si Harness change en conséquence, OpenAI se préparera également à le regrouper.

Dans un sens, il existe deux itinéraires vagues au niveau du harnais :

La voie représentée par DeepSeek s'apparente davantage à la construction d'un écosystème ouvert, transformant chaque partie en un plug-in que les développeurs peuvent assembler eux-mêmes ; tandis que le parti représenté par OpenAI, c'est comme parier sur les services cloud, mettre de l'argent et de la demande en place, et je vous aiderai à résoudre le reste.

On peut même penser que l'un veut faire en sorte que Harness ressemble de plus en plus à Linux, et que l'autre veut faire en sorte que Harness ressemble de plus en plus à AWS.

Bien sûr, ce n'est qu'une métaphore. OpenAI dispose également de Codex Harness open source, et il n'est pas impossible pour DeepSeek de fournir davantage de services d'hébergement à l'avenir. Mais au moins à ce stade, l’orientation des deux produits est évidemment différente.

Il est intéressant de noter qu'Anthropic a en fait une longueur d'avance sur OpenAI en transformant Harness en un service.

Dès septembre 2025, Anthropic a lancé le SDK Claude Agent, ouvrant aux développeurs les outils, la gestion du contexte, le système d'autorisations et les capacités de sous-agent derrière Claude Code, afin que d'autres puissent utiliser cet ensemble d'éléments en tant qu'agents.

En avril de cette année, la société a lancé Claude Managed Agents encore plus tôt qu'OpenAI. La session, l'harnachement et le bac à sable sont divisés en trois couches indépendantes : Anthropic est responsable de l'hébergement de l'harnais et des tâches longues. Le bac à sable peut être fourni par Anthropic ou peut être connecté à d'autres environnements d'exécution. Cette idée est en fait assez proche de l’API Agents actuelle. Anthropic lui-même le définit comme « un service d'hébergement pour les tâches d'agent à long terme ».

Donc, dans un sens, OpenAI continue d’avancer sur le chemin emprunté par Anthropic cette fois-ci. La différence est qu'OpenAI a un Codex plus « produit ».

Cependant, comme Codex et Claude Code donnent depuis longtemps des impressions de produits différentes, même s'ils racontent la même histoire, ils suscitent des sentiments très différents. Claude Code donne plutôt l'impression de laisser les développeurs s'asseoir dans le terminal et écrire du code avec l'agent, tandis que Codex App met l'accent sur l'interface de « supervision simultanée de plusieurs agents à long terme » dès le début.

D'ailleurs, Google a déjà rejoint cette voie. Lors de la conférence I/O en mai de cette année, l'API Gemini a lancé les agents gérés, qui ont également transformé Antigravity Harness et sandbox en services gérés. Mais les cartes de Google ne s’arrêtent pas là, dont nous parlerons plus tard.

Mais cela dit, peu importe qui vient en premier... En fin de compte, bien sûr, celui qui fera de son harnais la couche par défaut pour les développeurs pourra manger le plus gros gâteau.

Qui est le grand gagnant ?

Après tout, pourquoi les entreprises modèles commencent-elles maintenant à s'emparer de Harness ?

Tout comme l'équation donnée par DSH, Agent = Modèle + Harnais, le modèle peut indiquer à l'agent quoi faire ensuite, mais pour réellement exécuter une tâche du début à la fin, il doit toujours savoir où se trouve le fichier, quel outil doit être appelé, comment récupérer lorsqu'une erreur se produit et où les résultats sont finalement écrits.

En d'autres termes, le modèle détermine la limite supérieure des capacités de l'agent, et Harness détermine de plus en plus s'il peut terminer le travail.

Une fois que la dimension de la concurrence passera de « l'intelligence » à « l'exécution », celles qui auront le plus d'avantages ne seront peut-être pas celles qui disposent des meilleurs modèles.

Car une fois que l'agent commence réellement à travailler, les éléments dont il a besoin (e-mails, documents, réunions, communications, autorisations de compte, etc.) sont souvent entre les mains des sociétés de plateforme traditionnelles.

La récente « guerre des agents de bureau » en Chine est en fait un exemple très typique : les choses que les grandes entreprises ont accumulées à l'ère des plates-formes Internet représentaient auparavant une partie des fonctions de leurs écosystèmes respectifs, mais à l'ère des agents, ces choses s'avèrent être les outils que les agents doivent appeler lorsqu'ils travaillent réellement.

De nos jours, tout le monde travaille comme agent de bureau. En apparence, ils sont plus intelligents et plus compétents que les autres employés de l’IA. En coulisses, ils réutilisent en réalité les avantages de la plateforme qu’ils ont accumulés dans le passé. Quiconque dispose de plus de données d'entreprise, de documents, d'outils et d'autorisations aura plus de facilité à laisser l'agent faire le travail.

Les entreprises modèles doivent avoir accès à des portails dont elles ne disposent pas, et les entreprises qui créent des logiciels de bureautique et des plateformes Internet depuis plus de dix ans disposent déjà de ces portails.

En d’autres termes,

les sociétés d’IA veulent renouer avec le monde réel, et les sociétés de plateformes ont déjà un trousseau de clés entre les mains.

Dans cette optique, si nous devons trouver un acteur du « compartiment familial » offrant le plus d'avantages, Google est probablement le plus exagéré.

De TPU, l'infrastructure cloud, Gemini à la recherche, Workspace, Chrome et Android, Google couvre presque tous les aspects clés de l'IA, de la technologie sous-jacente aux utilisateurs finaux. La recherche, Gmail, Calendrier, Drive, YouTube, Maps et autres produits forment naturellement un environnement numérique qui peut être appelé par les agents. Ces actifs étaient des portails indépendants dans la génération précédente d'Internet, mais à l'ère des agents, ils peuvent être réorganisés dans la même tâche.

En fait, Google a commencé à intégrer les fonctionnalités de l'agent dispersées dans divers produits dans le même système d'exécution en bas. Gemini Spark, les agents gérés dans l'API Gemini et même certaines expériences d'agent dans la recherche partagent progressivement le même harnais antigravité.

Mais du côté des utilisateurs, les choses sont encore un peu compliquées.

Aujourd'hui, Google propose également des agents Gemini Spark, Workspace Studio, Antigravity, Gemini Enterprise et Information dans la recherche. Ils sont confrontés à différents utilisateurs et scénarios, mais pour les gens ordinaires, lorsqu'ils souhaitent confier une affaire complexe à Google, ils ne savent toujours pas vers qui se tourner.

Pour Google, la plupart des conditions sont déjà réunies pour accomplir tout cela. Ce qui manque, c'est une réponse produit assez simple.

Et si Google comprend vraiment cette question - qu'il s'agisse de créer un atelier d'agent unifié ou de laisser le même système d'exécution d'agent pénétrer l'ensemble de l'écosystème Google, afin que les utilisateurs s'habituent à "trouver Google lorsqu'ils ont des problèmes", le paysage concurrentiel du marché mondial des agents changera probablement à nouveau.

Cela dit, même si Google met réellement ce « compartiment familial » dans un agent, les utilisateurs nationaux ne pourront probablement le regarder qu'en premier.

Jetons d'abord un coup d'œil à la guerre des agents nationaux et voyons comment elle se déroulera ensuite.