Cette semaine, nous avons clôturé à San Francisco la troisième édition d’OpenAI DevDay, la plus grande à ce jour. Des collègues de toute l’entreprise ont travaillé dur pour que l’événement voie le jour. Et à mesure que DevDay approchait, une phrase revenait dans nos conversations : « Je n’aurais jamais pu faire ça sans Codex. »
Cette année, c’était notre premier DevDay avec Codex. Nous l’avons utilisé pour tout ce que nous avons créé. Des démos sur scène (même celles qui ne portaient pas sur Codex) aux bornes d’arcade de l’espace communautaire, en passant par les produits eux-mêmes, Codex a joué un rôle central dans la préparation de DevDay 2025.
Voici un aperçu des coulisses et de la façon dont Codex nous a aidés à gagner du temps, à résoudre des problèmes, à mener plusieurs tâches de front, à définir nos priorités et à nous organiser.
Piloter les caméras et créer un serveur MCP pour l’éclairage de la salle
Commençons par le projet le plus visible : la démo de Codex que Romain Huet a présentée lors de la conférence d’ouverture. Si vous l’avez manquée, vous pouvez la voir ici.
Comme l’a expliqué Romain, nous sommes partis de notre application de démarrage pour les agents Realtime. Codex a créé tout le reste de ce que vous voyez dans la démo.
Au départ, Romain voulait montrer comment Realtime pouvait piloter la caméra et l’éclairage dans le public. En se penchant sur le projet, il s’est heurté à une difficulté : comment commander la caméra et les lumières par programmation ?
Codex a trouvé comment piloter la caméra en réseau avec VISCA, un protocole du début des années 1990 ! Il a implémenté ce protocole de manière entièrement autonome et a même créé un serveur MCP qui pilotait les lumières à l’aide du protocole d’éclairage.
Avec Codex CLI, Romain a pu traiter les deux problèmes en parallèle et obtenir une première version fonctionnelle en un après-midi sans toucher au clavier. Il s’est ainsi épargné de longues heures de recherche et d’expérimentation.
Place au rythme
L’une des grandes annonces de DevDay a été le lancement de l’Apps SDK, qui permet de créer des applications interactives directement dans ChatGPT. Pour sa démo lors de la présentation Developer State of the Union, Katia Gil Guzman voulait s’appuyer sur le serveur MCP d’éclairage que Codex avait créé pour Romain et proposer une interface de pads musicaux aux fonctions variées.
L’interface devait être aussi agréable à regarder que fonctionnelle. Elle devait notamment gérer la connexion au serveur MCP pour piloter les lumières et permettre de jouer de différents instruments.
Grâce à Codex Cloud et à la fonctionnalité best-of-N, Katia a rapidement obtenu une application fonctionnelle tout en affinant plusieurs interfaces en parallèle. Elle a essayé aussi bien des designs modernes et futuristes que des interfaces aux couleurs d’OpenAI DevDay. Elle a même pu tester différentes fonctionnalités sans perdre de temps ni multiplier les efforts.
Concevoir plusieurs jeux en parallèle
Si vous avez parcouru les couloirs de DevDay, vous avez peut-être aperçu ArcadeGPT. Ces deux bornes d’arcade vous permettaient de personnaliser votre propre jeu vidéo en remixant des jeux existants avec GPT-5.
Lorsque Kevin Whinnery a commencé à poser les bases du projet, il lui fallait toute une sélection de jeux que GPT-5 pourrait remixer, et il en avait besoin rapidement. Pour les créer et les améliorer sans attendre, il avait ouvert sept (!!) terminaux. Dans chacun, une instance de Codex CLI développait un jeu Phaser dans un seul fichier.
Avec Codex CLI, Kevin pouvait faire évoluer chaque jeu de manière asynchrone et les tester tous en même temps. Les participants avaient ainsi un large choix de jeux auxquels jouer et qu’ils pouvaient remixer.
Recréer les applications de démo
Pour ma part, j’ai utilisé Codex pour pratiquement tout ce que j’avais à faire avant DevDay. Difficile de citer toutes les fois où j’ai été heureux de pouvoir compter sur lui, mais l’une d’elles m’a particulièrement marqué.
Je préparais une démo d’affinage pour ma présentation sur les modèles ouverts et j’avais tout réalisé avec Streamlit. Mais l’application Streamlit était compliquée, le public avait du mal à suivre et certains bugs de comportement étaient difficiles à corriger. J’ai pris quelques captures d’écran et réalisé une première maquette avec v0, puis j’ai téléchargé le prototype d’application Next.js et confié la suite à l’extension Codex pour IDE.
Je lui ai demandé de partir de mon application Streamlit, de créer un serveur FastAPI qui remplirait les mêmes fonctions et de le connecter à mon interface Next.js. J’ai lancé la tâche et je suis parti déjeuner. À mon retour, l’application était entièrement implémentée et fonctionnait. J’ai ensuite confié d’autres tâches à Codex pour créer des pages qui me permettraient de mieux illustrer la démo.
Sans Codex, cette démo n’aurait jamais été prête à temps.
Du croquis au stand
Erika Kettleson a gagné du temps en réalisant toute la démo de son stand avec l’extension Codex pour IDE. Elle a d’abord fourni un croquis à Codex, qui en a tiré une première interface. Elle lui a même fait écrire des évaluations pour déterminer quel modèle offrait le meilleur compromis entre vitesse et qualité pour la génération de SVG. Codex l’a aidée à peser les avantages et les inconvénients d’une architecture à un seul agent et d’une architecture multi-agents pour la démo. Il a ensuite refactorisé l’ensemble du code pour passer à un seul agent.
Une fois la démo prête, Codex a créé des diagrammes Mermaid détaillés dont Erika s’est servie sur le stand pour expliquer aux visiteurs comment fonctionnait l’application.
La revue de code à grande échelle
Le lancement d’AgentKit comprenait la sortie de nos nouveaux SDK Guardrails pour Python et TypeScript. Ces SDK sont conçus pour fonctionner avec nos SDK Agents pour Python et TypeScript, ainsi qu’avec Agent Builder. Kazuhiro (Kaz) Sera a rejoint l’équipe pour l’aider à finaliser les SDK et à les rendre agréables à utiliser pour les développeurs.
Avec Codex, il s’est rapidement familiarisé avec le code source des deux SDK et a pu remonter à l’origine de certains des bugs qu’ils avaient repérés ensemble. Il les a corrigés avec Codex CLI et l’extension pour IDE, puis a utilisé la revue de code de Codex pour repérer d’éventuels bugs restants.
Grâce à Codex, Kaz a pu aider l’équipe à publier les SDK tout en utilisant les mêmes outils pour peaufiner les exemples d’applications ChatKit que nous avons publiés le même jour.
Mener plusieurs projets de front
À l’approche de DevDay, beaucoup d’entre nous travaillaient sur un nombre croissant de projets en parallèle. Avec l’extension pour IDE et la CLI, nous pouvions déléguer à Codex plusieurs tâches à la fois, en local comme dans le cloud.
Il était courant de nous voir lancer trois ou quatre tâches totalement indépendantes en même temps. J’ai par exemple demandé à Codex d’ajouter la prise en charge des notebooks Jupyter au serveur gpt-oss, de refactoriser ma démo d’agent et d’y corriger quelques bugs, de réorganiser une partie de la documentation de Codex et de déboguer ma session d’affinage, le tout en parallèle.
Pour passer rapidement d’un sujet à l’autre, nous passions peu de temps à peaufiner nos prompts. Nous décrivions le problème à Codex en quelques phrases courtes, lancions la tâche et passions aussitôt à la suivante. Nous revenions plus tard voir où en était Codex. Même pour une courte absence, nous avions pris l’habitude de nous dire, avant de nous lever : « Allez, je lance encore une tâche dans Codex. »
Mettre de l’ordre dans la documentation
Lancer plusieurs produits pour les développeurs demande de rédiger beaucoup de documentation. Au début, les textes sont éparpillés un peu partout, dans des dépôts GitHub, dans Google Docs ou dans Notion. On les retravaille souvent jusqu’à la dernière minute. Ce lancement n’a pas fait exception.
Avec Codex Cloud, l’équipe a pu confier ces documents épars à Codex en lui indiquant dans les grandes lignes comment les découper et les répartir dans notre documentation. Codex s’est chargé du reste. Il a découpé les fichiers, les a convertis en MDX, a mis en place la navigation nécessaire et a ouvert une pull request. Nous avons pu la partager avec les équipes, qui ont utilisé les aperçus de déploiement pour relire la documentation et l’affiner.
Sans Codex, ce travail nous aurait normalement pris des heures, voire des jours, à l’approche de DevDay.
Les quêtes secondaires
Vous connaissez sans doute la situation : vous travaillez sur votre tâche la plus importante et, soudain, vous repensez à cette autre tâche que vous aviez prévu de faire, mais que vous remettez sans cesse à plus tard parce que quelque chose vous interrompt.
La veille de DevDay, nous en étions là. Entre deux répétitions, nous essayions de tout préparer pour le grand jour. Katia s’apprêtait à monter sur scène pour répéter sa démo quand elle s’est rendu compte qu’elle n’avait pas publié la nouvelle version de la page 404 comme prévu.
Elle a aussitôt ouvert un nouvel onglet dans Codex Web et demandé à Codex de créer une nouvelle version de developers.openai.com/404. Avec la fonctionnalité best-of-n, elle lui a fait produire deux propositions en parallèle.
Dans les cinq minutes qui lui restaient avant de monter sur scène, Katia a pu comparer les deux propositions grâce aux captures d’écran affichées dans Codex, ouvrir la page pour y apporter quelques retouches avec l’extension pour IDE et publier la nouvelle page 404.
Ce n’est qu’un aperçu
Nous pourrions sans doute parler pendant des heures du rôle de Codex dans la préparation de DevDay, sans même aborder l’aide qu’il apporte à chacun d’entre nous au quotidien. Ces exemples ne donnent qu’un aperçu de la façon dont nous utilisons Codex chez OpenAI.
Pour en savoir plus sur notre utilisation de Codex et découvrir quelques bonnes pratiques, regardez notre présentation sur Codex à DevDay ou consultez notre documentation.