Bilan d’OpenAI DevDay 2026 pour les développeurs : ce qui change

OpenAI DevDay 2026 ne s’est pas limité à une avalanche de nouveaux modèles. Dans son bilan du 29 septembre, OpenAI a surtout dessiné une nouvelle architecture : un modèle plus économique, un runtime d’agents managé, des environnements de développement dans le cloud et un agent grand public capable de fonctionner en continu. Pour les développeurs, le changement majeur se situe autour du modèle : sessions, outils, environnements et exécution en arrière-plan passent de plus en plus sous le contrôle de produits gérés par OpenAI.

Le verdict côté développeurs

GPT-6.1 Sol est la nouveauté API la plus immédiatement exploitable. OpenAI le référence sous le nom gpt-6.1-sol, avec la prise en charge de Responses API, des appels d’outils, de l’utilisation d’un ordinateur et de MCP. L’Agents API, actuellement en bêta publique, sert à construire des agents managés dans l’esprit de Codex. Codex Cloud transforme le développement asynchrone en workflow hébergé. Dots illustre la même orientation côté grand public, mais ne remplace pas une API destinée aux développeurs.

La stratégie la plus pragmatique consiste à commencer par tester Sol et l’Agents API, à utiliser Codex Cloud lorsque l’exécution distante réduit les frictions de coordination, et à considérer Dots comme un signal produit plutôt que comme une surface d’intégration stable.

Ce qui est disponible et ce qui arrive encore progressivement

Le bilan officiel de DevDay évoque plus de 20 lancements, mais les quatre nouveautés qui intéressent directement les développeurs n’en sont pas au même stade.

La documentation du modèle d’OpenAI reste la référence pour vérifier l’accès à l’API, tandis que l’annonce de l’Agents API confirme son statut de bêta. Aucun de ces documents ne garantit des quotas ou une disponibilité régionale identiques pour tous les comptes.

GPT-6.1 Sol rebat les cartes économiques des boucles d’agents

Dans son annonce de GPT-6.1 Sol, OpenAI présente Sol comme une évolution de GPT-6 Sol, capable de se rapprocher des performances d’Astra en programmation et en utilisation d’un ordinateur, pour un coût d’exploitation inférieur. Selon RuntimeWire, les tarifs publiés par OpenAI sont de 2 $ par million de tokens en entrée, 0,10 $ par million de tokens d’entrée mis en cache et 10 $ par million de tokens en sortie. Le contexte récurrent coûte donc nettement moins cher lorsqu’une application peut réutiliser des entrées mises en cache au lieu de renvoyer le même contexte.

Cette tarification est intéressante pour les workflows d’agents qui manipulent de longues consignes, des traces d’outils ou le contexte répété d’un projet. Elle ne rend pas toutes les tâches bon marché pour autant : les boucles riches en sorties, les nouvelles tentatives, les actions dans un navigateur et les coûts des outils externes peuvent rapidement peser davantage. Le positionnement « proche d’Astra » avancé par OpenAI reste une promesse qualitative, pas un substitut à des tests sur votre dépôt, vos schémas d’outils et votre budget d’échec.

Un premier test pertinent consiste à faire passer 20 à 50 tâches représentatives dans Sol et dans votre modèle actuellement utilisé en production, puis à mesurer le taux de réussite, le taux de correction des appels d’outils, la latence et le nombre total de tokens. Vous verrez ainsi si le prix inférieur des tokens résiste aux frais réels d’orchestration.

Agents API : passer de l’appel de modèle à l’exécution managée

L’Agents API est l’annonce la plus structurante pour les développeurs, car elle dépasse le simple choix d’un modèle. OpenAI décrit un harness Codex managé qui prend en charge les sessions, l’orchestration, la condensation du contexte et la reprise après incident, tandis que les développeurs fournissent les outils et les environnements d’exécution.

L’annonce de la bêta publique et les articles consacrés au lancement mentionnent l’exécution de code, la modification de fichiers, les connexions MCP, la délégation à d’autres agents et l’utilisation d’un ordinateur via un navigateur hébergé par OpenAI. L’API vise donc le runtime complet autour d’un agent, et pas seulement un appel responses.create accompagné d’un prompt système plus long.

Votre application reste responsable de l’authentification, des permissions métier, de la conception des outils, de la politique d’approbation, de l’observabilité, des listes de domaines autorisés, de la confirmation des actions sensibles, des journaux d’audit et des cas d’échec reproductibles. L’utilisation d’un ordinateur hébergé peut réduire l’infrastructure dédiée au navigateur, mais elle ne supprime pas ces garde-fous.

« Des nouvelles sur les performances de Sol 6.1 par rapport à Opus 5.5 ? » — u/Ashamed-Subject-8573, dans une discussion sur r/codex

Cette question résume l’écart entre le keynote et l’adoption en production. Les développeurs ont besoin de connaître le comportement du modèle réellement servi, la fiabilité des outils et le coût sur leur propre charge de travail, pas seulement d’un comparatif mis en avant dans une présentation. Considérez l’Agents API comme un runtime en bêta à évaluer, et non comme la preuve que tous les workloads d’agents doivent migrer vers la pile managée d’OpenAI.

Codex Cloud intègre le runtime au produit

Codex Cloud étend les agents de programmation au-delà du terminal actif du développeur. Les informations publiées lors du lancement décrivent des environnements réutilisables contenant les dépôts, dépendances, outils et paramètres d’accès d’un projet. Les tâches peuvent s’exécuter à distance depuis un ordinateur, le web ou un mobile, puis être reprises après la fermeture du portable.

Les conséquences sont avant tout opérationnelles :

1. Les tâches longues deviennent asynchrones. Une revue de code, une correction de tests ou une migration peut continuer sans garder une session locale ouverte.
2. La configuration des environnements devient partageable. Les équipes peuvent définir un espace de travail approuvé plutôt que réinstaller les dépendances pour chaque tâche.
3. Les relais entre humains et agents sont simplifiés. Un développeur peut inspecter les différences, reprendre une session et décider de ce qui sera fusionné.
4. La sécurité devient un sujet de déploiement. L’accès aux dépôts, les secrets, les flux réseau sortants et l’identité cloud doivent faire l’objet de règles explicites.

Le bilan de DevDay d’OpenAI et le même inventaire des produits évoquent également une vue agents dans Codex CLI, des commandes vocales, la revue de code sur ordinateur et Codex Security Cloud pour les dépôts GitHub connectés. L’ensemble donne à Codex une dimension qui dépasse largement l’autocomplétion : celle d’une couche d’opérations d’ingénierie à distance.

Codex Cloud ne remplace pas automatiquement un environnement de développement local. Les équipes doivent encore vérifier la prise en charge des dépôts, l’installation des dépendances, l’accès réseau, la gestion des secrets, la durée des sessions et la capacité à retrouver un espace de travail reproductible après un échec. Commencez par des tâches de maintenance peu risquées avant de lui confier des migrations de production ou des changements critiques pour une mise en production.

Dots illustre la vision grand public, pas l’API développeur

Dots montre la direction prise par OpenAI pour ses produits d’agents : un assistant toujours actif, doté de son propre ordinateur dans le cloud, d’applications connectées, d’un contexte persistant et de capacités d’exécution en arrière-plan. L’annonce de Dots et la documentation consacrée aux espaces de travail décrivent les services connectés et les accès contrôlés, tandis que les informations de lancement mentionnent des accès via ChatGPT, Slack et Microsoft Teams pour certains forfaits et marchés.

Pour les développeurs, Dots confirme le passage de la simple conversation à la délégation, tout en laissant ouvertes d’importantes questions sur l’autonomie et la confidentialité. La documentation des espaces de travail d’OpenAI confirme que les accès dépendent de l’espace de travail et des paramètres du forfait ; les informations de lancement mentionnent des accès via ChatGPT, Slack et Microsoft Teams sur les marchés concernés. Dots ne constitue pas un contrat développeur : avant de choisir un agent hébergé, comparez le niveau de contrôle, la localisation des données, les permissions des outils, l’auditabilité et le coût de sortie avec l’Agents API.

Une séquence d’adoption pragmatique pour les équipes d’ingénierie

Ces quatre lancements s’intègrent dans un ordre d’évaluation assez naturel :

1. Évaluez GPT-6.1 Sol sur du travail réel. Utilisez des tâches issues de vos dépôts, des appels d’outils structurés et du contexte représentatif. Intégrez l’hypothèse des entrées mises en cache dans le calcul des coûts.
2. Construisez un workflow Agents API limité. Choisissez une tâche réversible, comme le tri de tickets, le diagnostic de tests ou la mise à jour de documentation. Ajoutez des étapes d’approbation avant d’élargir les permissions.
3. Déplacez sélectivement les tâches asynchrones vers Codex Cloud. Testez d’abord un environnement réutilisable avec des dépôts non sensibles, puis documentez les contrôles liés aux secrets et au réseau.
4. Utilisez Dots comme signal pour la veille produit. Surveillez ses permissions, ses intégrations et sa disponibilité, mais n’en faites pas une dépendance de l’architecture de votre application.
5. Conservez une couche de portabilité. Stockez les définitions d’outils, les prompts, les cas d’évaluation et la logique d’approbation dans votre propre dépôt afin de pouvoir remplacer une API en préversion si ses limites ou son comportement évoluent.

Sol dispose d’une référence de modèle API et de tarifs publiés ; l’Agents API est explicitement en bêta publique ; Codex Cloud est un workflow hébergé dont plusieurs aspects opérationnels restent à clarifier ; Dots demeure la base la moins adaptée pour établir un contrat développeur.

FAQ

GPT-6.1 Sol est-il disponible dans l’API ?

Oui. La page du modèle destinée aux développeurs d’OpenAI référence gpt-6.1-sol pour une utilisation via l’API, notamment avec Responses API et les fonctionnalités orientées outils. L’accès et les limites peuvent varier selon le compte et le déploiement.

L’Agents API est-elle disponible en version générale ?

Non. OpenAI a annoncé l’Agents API en bêta publique. Mettez en place une évaluation, une journalisation et une solution de repli avant de l’utiliser pour des actions de production irréversibles.

Dots est-il accessible via une API pour les développeurs ?

Non. Dots est un produit d’agent OpenAI soumis à ses propres règles de déploiement et de forfait. Pour construire des agents managés, l’Agents API constitue la surface destinée aux développeurs.

Codex Cloud remplace-t-il un environnement de développement local ?

Pas par défaut. Il ajoute l’exécution distante et des environnements réutilisables, mais les équipes doivent valider l’accès aux dépôts, les dépendances, les secrets, la politique réseau, la persistance et les workflows de revue.

Que doivent vérifier les équipes avant de déplacer du travail de production ?

Vérifiez le modèle réellement servi, le coût des nouvelles tentatives et des appels d’outils, le traitement des données, les limites de permissions, la récupération après échec, l’observabilité, la disponibilité régionale et la possibilité de revenir en arrière si une fonctionnalité en bêta évolue.

Le compromis que les développeurs ne doivent pas négliger

Le compromis est simple : les sessions et navigateurs managés réduisent le travail d’infrastructure, tandis que les runtimes autogérés préservent davantage de contrôle sur les données, les identifiants, le débogage et les changements de modèle. Commencez par Sol et l’Agents API, puis n’utilisez Codex Cloud que lorsque le gain opérationnel est clairement démontré.