Le 19 août, OpenAI a publié sur son blog développeurs un billet intitulé "Codex as a platform", changeant la façon de présenter Codex : d'"assistant de programmation qui tourne dans le terminal" à "couche d'exécution open source sur laquelle d'autres peuvent construire directement".
L'article commence par rappeler un point souvent négligé : la plupart des utilisateurs connaissent Codex via l'application de bureau, la ligne de commande ou un plugin d'IDE, mais ces trois points d'entrée partagent le même système sous-jacent, déjà publié sur GitHub (dépôt openai/codex, licence Apache 2.0, 109 000 étoiles à ce jour). Ce qu'OpenAI fait ici, c'est un repositionnement : passer d'un "détail d'implémentation interne de notre produit" à "la fondation sur laquelle vous construisez".
Ce qui entoure le modèle
Le texte original en anglais utilise le terme harness, que les milieux techniques traduisent généralement par framework d'exécution ou échafaudage de contrôle. La définition qu'en donne OpenAI est simple :
"That surrounding execution system is the harness."
Ce système d'exécution qui entoure le modèle, c'est le harness.
Détaillé, il est chargé de collecter le contexte, de découper la tâche en étapes exécutables, de maintenir l'état de la session sur plusieurs tours, d'appeler des outils, de s'exécuter dans les limites configurées de bac à sable et de permissions, de s'arrêter au bon moment pour attendre une validation humaine, et enfin de renvoyer le résultat au système métier. Rien de tout cela ne concerne les poids du modèle, mais la qualité d'exécution influence directement les scores. OpenAI cite à nouveau ses propres chiffres ARC-AGI-3 de fin juillet : en activant uniquement, au niveau du harness, la rétention du raisonnement et la compression du contexte, le score de GPT-5.6 Sol sur l'ensemble public est passé de 13,3 % à 38,3 %, tandis que le nombre de tokens en sortie a chuté à environ un sixième. Le modèle n'a pas changé ; c'est la couche qui l'entoure qui a changé.
Trois niveaux d'intégration, classés par degré d'intrusion
OpenAI répartit clairement les modes d'intégration en trois niveaux, afin que les développeurs choisissent selon le scénario plutôt que de tout faire entrer de force dans une fenêtre de chat.
codex exec vise les scripts, les tâches CI et les travaux ponctuels en arrière-plan : il exécute un flux d'agent aux limites bien définies, restitue un résultat structuré, puis s'arrête. Le Codex SDK vise les applications qui doivent démarrer, reprendre et lire en streaming des tâches Codex directement depuis le code. Le Codex app-server est le niveau le plus intrusif : l'application se connecte à un processus Codex local, garde la session ouverte en permanence, reçoit un flux d'événements, peut interrompre à tout moment, expose ses propres outils à l'agent et prend elle-même en charge le traitement des demandes de validation.
Pour illustrer l'usage d'app-server, OpenAI a construit au passage une application de démonstration nommée Relay, un tableau de bord fictif de gestion des incidents de fret. L'utilisateur n'écrit pas de prompt : il sélectionne d'abord un envoi, puis clique sur un bouton du type "Compare recovery" ; l'application transmet le contexte pertinent, Codex utilise un outil MCP branché par l'application elle-même pour récupérer les données à jour et expliquer les options possibles ; pour effectuer un changement réel, une validation humaine reste obligatoire, et ce n'est qu'après l'enregistrement de l'opération en base que l'application actualise sa propre vue métier.
Ce choix de conception est justifié sans détour dans l'article : il ne faut pas remplacer les tableaux de répartition, les chronologies, les cartes et les écrans de tickets par une fenêtre de chat générique — ces interfaces existent précisément pour que les humains comprennent la situation, prennent des décisions et gardent un sentiment de contrôle.
Ceux qui l'ont déjà mis en production
OpenAI cite trois groupes de cas publics. GitHub et JetBrains ont intégré Codex à leurs propres flux de travail IDE ; Cisco a utilisé le Codex SDK dans l'App Builder de Cloud Control ; Thrive Holdings et Crete ont intégré Codex à leur processus de préparation de déclarations fiscales, traitant 7 000 déclarations en phase pilote, avec une réduction d'environ un tiers du temps de préparation.
Ce dernier chiffre est le plus solide des trois. La préparation de déclarations fiscales est un cas typique à forte répétition, faible tolérance à l'erreur et exigences de conformité strictes ; présenter une échelle de pilote assortie d'un indicateur d'efficacité comparable est bien plus utile que des affirmations vagues du type "gain de productivité important". OpenAI en profite aussi pour souligner que ce modèle ne sert pas uniquement les équipes d'ingénierie : tri du support client, coordination des opérations, priorisation des incidents de sécurité, vérification préalable des ventes — tous suivent la même forme : l'application fournit contexte, outils et étapes de validation, et Codex prend en charge la boucle entre les deux.
Jusqu'où va l'open source
Une phrase soulignée dans l'article résume tout : ce qui est ouvert, c'est le harness et les surfaces d'intégration ; l'accès au modèle et les services hébergés restent facturés séparément.
En rapprochant cette phrase des trois niveaux d'intégration, la stratégie d'OpenAI devient claire. La couche d'exécution est cédée gratuitement, auditable et personnalisable, et n'importe qui peut l'intégrer à son propre produit ; mais à chaque boucle d'agent exécutée, les tokens continuent de transiter par l'API d'OpenAI. Plus la partie ouverte est utile et plus de produits l'intègrent, plus le volume d'appels côté modèle augmente. C'est la même manœuvre qu'Anthropic avec MCP, devenu standard de facto pour l'intégration d'outils — sauf que cette fois, OpenAI cède quelque chose de bien plus lourd : tout le runtime.
Pour les équipes qui construisent des produits d'agents, le bénéfice immédiat est d'économiser un travail redondant. État de session, flux d'événements, appels d'outils, interruptions pour validation — la plupart des équipes ont déjà écrit tout cela au moins une fois, avant de devoir encore l'ajuster. Il existe désormais une implémentation validée à grande échelle, lisible ligne par ligne, pour servir de référence. À vue de calcul, si le seul changement au niveau du harness permet déjà de réduire les tokens de sortie à un sixième, le même budget permet de faire tourner cinq boucles supplémentaires — cela seul justifie, pour beaucoup d'équipes, de lire attentivement le code source.
Le prix à payer est tout aussi visible : plus l'intégration est profonde, plus elle se lie étroitement au modèle de facturation d'OpenAI. C'est particulièrement net au niveau app-server, qui dépasse la simple relation d'appel API et fait entrer, de fait, le processus du partenaire directement dans son propre produit.
Sources : blog développeurs d'OpenAI "Codex as a platform", CocoLoop, dépôt GitHub openai/codex ; licence, nombre d'étoiles et les trois niveaux d'intégration vérifiés à partir du dépôt et de la documentation officielle, score ARC-AGI-3 et réduction de tokens selon les chiffres communiqués par OpenAI lui-même.