OpenAI DevDay 2026 : toutes les nouveautés de la pile d’agents

OpenAI DevDay 2026, qui s’est tenu le 29 septembre, a présenté les agents Dots toujours actifs, le modèle GPT-6.1 Sol, Codex Cloud, la prise en charge de MCP Events et une plateforme de plugins élargie, parmi plus de 20 annonces. Ensemble, ils font de ChatGPT et Codex une pile d’agents capable d’agir sur des systèmes connectés, ce qui place les autorisations et les entrées non fiables au cœur de la sécurité des applications.

Les annonces d’OpenAI DevDay témoignent d’un changement dans le fonctionnement des logiciels d’IA. Un modèle peut désormais s’inscrire dans un workflow de plus longue durée : recevoir un objectif, recueillir le contexte d’applications connectées, utiliser un navigateur ou un environnement de codage, puis poursuivre son travail à l’arrivée de nouvelles tâches. Le récapitulatif de DevDay couvre les nouveautés grand public, développeur et entreprise ; le fil conducteur reste toutefois un agent capable d’agir sur plusieurs systèmes. Certaines annonces correspondent à de nouveaux lancements, d’autres enrichissent des produits existants, et plusieurs sont encore des aperçus.

Cela permet une automatisation utile. Les autorisations, les entrées non fiables et les preuves des actions réellement effectuées par un agent deviennent également des questions centrales de sécurité applicative.

Illustration originale de Plexicus représentant la pile d’agents annoncée ; il ne s’agit pas d’une capture d’écran d’un produit OpenAI.

Les agents persistants rencontrent le travail connecté

Dots sont les agents toujours actifs d’OpenAI. Chaque dot dispose d’un ordinateur dans le cloud, d’un navigateur, d’un contexte persistant et d’un accès aux applications connectées, selon les autorisations et approbations configurées. OpenAI décrit la recherche proactive comme un travail d’arrière-plan en lecture seule ; les autres actions dépendent des autorisations plus larges du dot. Cette distinction est importante : observer un nouveau problème, préparer une modification et l’exécuter ne devraient pas relever de la même autorisation.

OpenAI a également décrit des dots spécialisés avec une identité organisationnelle et un accès dédié. Il s’agit d’une orientation pilote, et non d’une flotte d’entreprise généralement disponible. Les équipes qui envisagent des agents persistants devraient attribuer à chaque identité un responsable clairement défini, un accès limité et un historique de ses actions. Un modèle de menace à plusieurs couches, comme OWASP MAESTRO pour l’IA agentique, aide à déterminer où appliquer chaque contrôle.

GPT-6.1 Sol fournit un autre élément de la pile. OpenAI le positionne pour le codage, l’utilisation de l’ordinateur et les workflows de longue durée (documentation du modèle). La baisse du coût par tâche peut rendre les exécutions répétées d’agents abordables. Mais la capacité d’un modèle ne prouve ni que sa sortie est sécurisée, ni que ses actions sont autorisées.

Des modèles plus rapides et une infrastructure privée

OpenAI a également étendu Ultrafast, une offre de vitesse premium. Lors de DevDay, l’entreprise a annoncé jusqu’à 300 jetons par seconde pour GPT-6 Astra Ultrafast, puis prévu GPT-6.1 Sol Ultrafast (récapitulatif de DevDay). Il s’agit des performances annoncées par OpenAI, et non d’une prévision pour toutes les charges de travail. La vitesse compte parce qu’un agent peut effectuer des dizaines d’étapes successives de raisonnement et d’utilisation d’outils. Réduire la latence de chaque étape peut rendre un workflow interactif. Cela ne dispense pas de vérifier le résultat.

Les annonces relatives à la confidentialité répondent à une autre contrainte. Zero Data Retention with Private Safety Processing est présenté aux clients API éligibles qui ont besoin d’un traitement automatisé de sécurité sans conservation des prompts et réponses par OpenAI ; l’architecture peut utiliser un stockage cloud géré par le client. Private Inference a été annoncé comme une fonctionnalité à venir, avec un projet reposant sur le calcul confidentiel et des contrôles vérifiables. Les équipes doivent examiner le service et le contrat dont elles disposent réellement avant de considérer un aperçu comme une garantie déjà applicable sur le traitement des données. Cette question devient importante lorsque des agents peuvent lire du code source, des messages internes et des dossiers clients.

Des sessions de codage au travail logiciel continu

Codex Cloud fournit aux agents de codage des environnements cloud réutilisables. Combiné à la revue de code et à Codex Security Cloud, il suggère un workflow dans lequel les agents inspectent un dépôt, proposent des modifications, exécutent des contrôles et examinent les résultats de sécurité sans dépendre de l’ordinateur portable ouvert d’un développeur.

La frontière de sécurité englobe le dépôt et les systèmes qui l’entourent : code source, dépendances, secrets, CI, tickets et pull requests. Un patch généré par un agent doit toujours faire l’objet d’une revue du comportement qu’il modifie ; notre analyse des vulnérabilités dans les pull requests générées par l’IA en explique la raison. La réussite d’un test renseigne sur les cas testés, mais ne prouve pas que tous les chemins d’autorisation ou tous les points de terminaison exposés sont sûrs.

La Codex CLI mise à jour ajoute le pilotage vocal, une vue /agents et des améliorations pour suivre et reprendre plusieurs tâches d’agents (récapitulatif de DevDay). Le changement opérationnel essentiel est qu’un développeur peut superviser plusieurs agents en parallèle. La responsabilité des tâches et la provenance de chaque changement de code prennent donc plus d’importance que l’interface utilisée pour lancer le travail.

L’expérience de bureau Code Review intègre résumés, diffs, questions et revue dans le cloud au workflow du développeur. La revue cloud automatique dépend de la connexion et de la configuration du dépôt. Codex Security Cloud peut analyser les dépôts connectés à la demande ou selon un calendrier, examiner les résultats et préparer des corrections lorsque la machine locale est hors ligne. Ces fonctionnalités peuvent raccourcir la boucle de retour, mais les résultats doivent toujours être accompagnés de preuves d’atteignabilité et d’impact : c’est le manque que Deep Code Analysis vise à combler. Les corrections proposées doivent être retestées au regard du comportement modifié, comme le décrit notre playbook de remédiation autonome.

Le guide d’utilisation de l’ordinateur d’Agents API ajoute une autre interface. Dès qu’un agent peut cliquer dans des applications, une page visible sert à la fois de contexte de tâche et de vecteur potentiel pour des instructions malveillantes. Limitez les sessions du navigateur à leur objectif, contrôlez les systèmes accessibles et exigez une revue avant toute modification lourde de conséquences.

L’Agents API dans son ensemble rassemble l’orchestration, l’utilisation d’outils, la gestion du contexte, les connexions MCP et les sandboxes dans une même interface de développement. OpenAI héberge le navigateur utilisé pour les interactions avec l’ordinateur, tandis que l’application du développeur contrôle toujours l’accès aux sites et le workflow environnant. L’API Decisions, annoncée en aperçu limité, adopte une approche plus restreinte : les développeurs lui donnent un ensemble fini de réponses autorisées et le modèle choisit parmi celles-ci (récapitulatif de DevDay). Des sorties bornées peuvent faciliter le routage ou la classification, mais une réponse choisie par un modèle ne devrait pas, à elle seule, autoriser une opération sensible.

Le récapitulatif de DevDay met également en avant Amazon Bedrock Managed Agents powered by OpenAI. Il s’agit d’une extension d’un partenariat antérieur avec AWS, et non d’une technologie apparue pour la première fois lors de DevDay. AWS décrit l’identité, la mémoire, la capacité de calcul, les contrôles de sécurité et les journaux d’audit des agents dans son infrastructure. Les entreprises qui l’adoptent doivent toujours faire correspondre ces contrôles à leurs propres autorisations et processus de revue.

MCP Events ajoute une voie d’entrée

OpenAI ajoute la prise en charge de la spécification proposée MCP Events. Au lieu d’interroger un service, ChatGPT peut s’abonner aux événements d’un serveur MCP. OpenAI documente la livraison de webhooks signés, les identifiants d’événement, les filtres, les contrôles d’autorisation et les protections contre les boucles de rétroaction.

Un événement peut être utile : un nouveau rapport de bug peut déclencher une investigation et la préparation d’un correctif. Mais son contenu vient de l’extérieur du périmètre d’instructions de l’agent. Un rapport falsifié ou rédigé à des fins malveillantes doit rester une donnée de la tâche, même s’il arrive par un webhook valide. L’authentification établit quel service a envoyé l’événement ; elle ne rend pas chaque phrase de son contenu sûre à suivre.

Illustration originale de Plexicus représentant un workflow MCP Events ; il ne s’agit pas d’une capture d’écran d’un produit OpenAI.

Les plugins et leurs extensions d’interface élargissent cette voie. Un plugin peut exposer des outils, des données et des interfaces interactives à un agent. Examinez ses portées demandées, son fournisseur, son traitement des données et ses opérations d’écriture comme pour toute autre intégration logicielle (guide de sécurité des plugins OpenAI).

La documentation des plugins OpenAI décrit désormais des packages qui combinent des skills, un serveur MCP, une interface et des connexions externes. Les extensions de plugins peuvent fournir des barres latérales, des panneaux, des éditeurs, des formulaires et un contexte partagé avec une conversation. Plugin Creator et une procédure de soumission révisée visent à simplifier la création et la publication ; OpenAI décrit un annuaire commun à ChatGPT et Codex. Un canal de distribution plus vaste rend également plus importante l’évaluation des logiciels et des portées derrière un simple bouton d’installation.

Les Sites peuvent héberger les plugins pris en charge et ainsi exposer des capacités connectées à plusieurs personnes sur une même page propulsée par l’IA. La page peut être partagée, mais les données et actions de chaque personne doivent toujours respecter ses propres autorisations. Pour les développeurs, c’est une solution d’hébergement d’applications. Pour les équipes de sécurité, c’est un autre endroit où examiner la frontière entre contexte partagé et autorité individuelle (récapitulatif de DevDay).

Space transforme la pile en travail partagé

ChatGPT Space est l’espace d’OpenAI pour les pages, fichiers, feuilles de calcul, présentations et agents. Pages permet aux personnes et aux agents de modifier ensemble un document pouvant utiliser le contexte connecté et être mis à jour au fil du temps. Les diapositives collaboratives ont été présentées comme une fonctionnalité à venir, avec génération, édition, commentaires et export. Une page partagée qui s’actualise à partir d’outils est utile, mais ses propriétaires doivent pouvoir identifier les données sources, l’instruction de mise à jour et le public visé.

Teams et Team Tasks réunissent le travail planifié ou déclenché par événement dans un environnement organisationnel commun. OpenAI prévoit également @ChatGPT dans Slack et Microsoft Teams, où un agent peut participer à un canal ou à un fil avec des outils approuvés et les autorisations pertinentes de l’utilisateur (récapitulatif de DevDay). Cela réduit la friction entre discussion et action. Mais une question évidente se pose : à qui appartient l’autorité d’une demande formulée dans une conversation de groupe ?

Le plugin Meetings peut transformer une discussion enregistrée en notes et en tâches dans l’application macOS, puis alimenter les travaux de suivi. OpenAI indique que l’audio de la réunion est supprimé dès que les notes sont prêtes. Les équipes devraient néanmoins prendre en compte le consentement, la durée de conservation des notes et la question de savoir si une suggestion orale doit devenir une tâche exécutable. Les profils partageables facilitent la découverte de certains travaux ; les contrôles de partage de l’espace de travail déterminent toujours qui peut y accéder.

Identité, offres et distribution

Sign in with ChatGPT permet aux utilisateurs éligibles de reporter l’utilisation de leur abonnement dans des applications tierces participantes, avec des contrôles propres à chaque application (aide OpenAI). ChatGPT devient ainsi une option de connexion et une source d’utilisation portable. La revue de sécurité reste classique : identifiez le tiers, examinez les accès accordés et sachez comment les révoquer.

Pro 500 est la nouvelle offre individuelle à forte utilisation, avec accès à Astra Ultrafast lorsqu’il est pris en charge. L’OpenAI Marketplace permet aux entreprises éligibles d’affecter une partie de leur engagement commercial à des logiciels partenaires approuvés. Les deux ont été annoncés dans le récapitulatif de DevDay. Ils changent la façon dont la capacité d’agents et les intégrations peuvent être achetées, mais ne modifient pas la nécessité d’évaluer les outils qui reçoivent les données de l’organisation.

Ce que les équipes AppSec doivent vérifier après OpenAI DevDay

Le principal risque vient de l’enchaînement de capacités raisonnables prises individuellement : un agent lit un message, consulte un dépôt, utilise un navigateur, puis modifie un ticket ou ouvre une pull request. Le préjudice dépend du moment où du contenu non fiable est élevé au rang d’autorité et des actions que l’agent peut ensuite réaliser.

Illustration originale de Plexicus représentant la surface d’attaque d’un agent ; il ne s’agit pas d’une capture d’écran d’un produit OpenAI.

Pour chaque workflow, les équipes de sécurité doivent vérifier :

• Identité et portée : quelles informations d’identification chaque agent utilise-t-il, que peut-il lire ou modifier et quand son accès expire-t-il ?
• Limites des entrées : les pages récupérées, messages, charges utiles d’événements et résultats d’outils restent-ils des données non fiables ? L’injection de prompt occupe la première place des OWASP Top 10 pour les applications LLM.
• Validation des actions : quelles écritures nécessitent l’approbation d’une personne et cette approbation porte-t-elle sur l’action et la destination exactes ?
• Traçabilité : les journaux relient-ils un événement à la décision de l’agent, à ses appels d’outils, à la modification qui en résulte et au réviseur ?
• Validation : un résultat est-il atteignable et exploitable dans le périmètre autorisé, par exemple via un AI Swarm Pentest, et le correctif a-t-il été retesté ?

L’annexe de sécurité de GPT-6.1 Sol d’OpenAI présente les résultats d’évaluations en cybersécurité et décrit les mesures de protection du déploiement. Ce sont des résultats de benchmark communiqués par le fournisseur dans des conditions d’évaluation précises, et non une mesure de la sécurité de chaque déploiement d’agents. L’application, les autorisations, les intégrations et les contrôles humains déterminent toujours l’exposition réelle.

La question AppSec durable posée par DevDay est concrète : à mesure que les agents opèrent plus longtemps et sur davantage de systèmes, les équipes peuvent-elles montrer quelles actions étaient autorisées, quelles preuves les justifiaient et si le logiciel produit est sécurisé ? La vérification fondée sur des preuves doit couvrir l’ensemble du workflow, de l’événement entrant à la modification finale.

Questions fréquentes