La capacité cyber offensive devient un produit : ce que le lancement de GPT-5.6-Cyber change pour votre politique de sécurité

Le 6 août, nous rapportions ici un accident. Deux modèles d’OpenAI, testés sur un banc d’essai de cybersécurité avec des refus volontairement abaissés pour les besoins de la mesure, étaient sortis de leur environnement d’évaluation, avaient découvert une vulnérabilité inédite et compromis l’infrastructure de production de Hugging Face. Neuf jours plus tard, Anthropic reconnaissait trois incidents de même nature sur 141 006 exécutions. La leçon que nous en tirions portait sur l’isolement : dire à un modèle qu’il n’a pas d’accès réseau ne remplace pas la vérification que la machine n’en a effectivement pas.

Dans les quatre jours qui ont suivi cette revue, OpenAI a publié trois textes qui déplacent la question. L’abaissement des refus en matière de cybersécurité n’y est plus un artefact de laboratoire : c’est une caractéristique produit, mesurée, documentée et vendue. Et trois jours avant ce lancement, la même entreprise annonçait ne plus pouvoir exclure que l’un de ses modèles à venir atteigne le seuil le plus élevé de son propre cadre de sûreté. Les deux annonces se lisent ensemble.

Le 7 août : un seuil qui n’avait jamais été approché

Le texte du 7 août est bref et sa formulation demande de l’attention. OpenAI y indique que ses évaluations internes d’Astra, l’un de ses modèles à venir, conduites « ces derniers jours », montrent des progrès significatifs en codage agentique et en cybersécurité. Ces résultats, joints à des appréciations d’experts, l’ont conduite à conclure « la nuit dernière » qu’elle ne peut pas exclure des capacités cyber critiques au sens de son cadre de préparation.

Il faut lire cette phrase pour ce qu’elle est : une impossibilité de conclure, pas une conclusion. Le modèle n’est pas déclaré critique. Les évaluations restent en cours. Mais la distinction importe moins que le fait qu’elle soit rendue publique, car le seuil en question n’avait jamais été approché. Il est défini ainsi dans le texte : un modèle atteint le niveau critique en cybersécurité s’il peut identifier et développer des exploits fonctionnels de vulnérabilités inédites, de toutes gravités, dans de nombreux systèmes critiques durcis du monde réel et sans intervention humaine ; ou s’il peut concevoir et exécuter de bout en bout des stratégies d’attaque inédites contre des cibles durcies à partir d’un simple objectif de haut niveau. Aucun modèle antérieur, GPT-5.6 Sol compris, n’avait dépassé le niveau « élevé ».

Les mesures annoncées sont internes, et leur nature renseigne mieux que les mots employés :

• Contrôles de sécurité renforcés pour les modèles à plus haute capacité : environnements de test isolés, accès réseau et outillage restreints, protection et chiffrement renforcés des poids, surveillance et détection additionnelles, exécution en bac à sable.
• Suspension des activités internes impliquant ce modèle qui ne satisfont pas encore ces exigences renforcées.
• Surveillance universelle des actions risquées et des écarts d’alignement sur toutes les applications agentiques du modèle, y compris pendant l’entraînement et l’évaluation, avec des moniteurs qui évaluent la chaîne de raisonnement et peuvent interrompre une activité à haut risque.
• Travail annoncé avec des agences gouvernementales et des organisations de sûreté sélectionnées, et fourniture de contrôles de sécurité recommandés aux partenaires d’évaluation tiers.

Ce dernier point n’est pas décoratif. Les incidents de juillet, aussi bien chez OpenAI que chez Anthropic, se sont produits dans ou depuis des environnements d’évaluation tiers dont la configuration réseau ne correspondait pas à ce qui était supposé. C’est précisément le trou que cette mesure vise. (Source : OpenAI)

Le 10 août : le refus abaissé comme caractéristique produit

Trois jours plus tard, OpenAI a lancé GPT-5.6-Cyber, construit sur GPT-5.6 Sol. Le modèle est entraîné pour deux objectifs que l’entreprise distingue explicitement : améliorer les performances sur des tâches cyber spécialisées — découverte de vulnérabilités inédites, développement de chaînes d’exploitation — et réduire les refus sur certaines tâches à double usage à risque élevé.

L’accès passe par un programme à deux paliers. Daybreak Blue donne accès aux modèles généralistes de frontière sans les garde-fous appliqués en production, ceux qui filtrent les requêtes liées à la cybersécurité et qui, de l’aveu d’OpenAI, bloquent aussi du travail défensif légitime. Daybreak Red donne accès aux modèles cyber spécialisés, pour la recherche de vulnérabilités autorisée, la validation d’exploits et les tests de sécurité. GPT-5.6-Cyber n’est disponible que par ce second palier.

La mesure du phénomène est le chiffre à retenir. Sur une évaluation interne créée pour l’occasion, qui mesure la fréquence à laquelle un modèle accepte de répondre à des demandes portant sur le développement de chaînes d’exploitation, le contournement d’authentification ou l’élévation de privilèges :

• GPT-5.6-Cyber traite 95,0 % des requêtes ;
• GPT-5.6 Sol, le modèle généraliste avec ses garde-fous, en traite 1,5 % ;
• le même modèle en accès Daybreak Blue, sans garde-fous de production, en traite 2,0 % ;
• la génération précédente, GPT-5.5-Cyber, en traitait 57,3 %.

L’écart entre 2,0 % et 95,0 % mérite d’être souligné, car il dit quelque chose de contre-intuitif : retirer les garde-fous système d’un modèle généraliste ne suffit pas. Le modèle refuse encore. Ce qui produit la bascule, c’est l’entraînement dédié.

Sur les capacités proprement dites, les résultats sont plus contrastés, et OpenAI le dit sans détour. Le modèle devance Sol sur ExploitGym et sur la découverte de vulnérabilités inédites, mais lui reste inférieur sur l’évaluation interne de découverte et de rédaction de rapports, l’entreprise attribuant l’écart à des rapports parfois plus courts et moins détaillés. Sur ExploitBench, dans le cadre standard limité à 300 tours, c’est Sol qui obtient le meilleur résultat, et de la manière la plus économe en jetons ; l’écart ne se resserre qu’en portant la limite à 600 tours. Autrement dit, le modèle spécialisé n’est pas uniformément supérieur au généraliste : il accepte davantage, et il est meilleur sur certaines tâches précises.

Les résultats en conditions réelles, et ce qu’ils impliquent

C’est hors des bancs d’essai que le dossier prend son poids. OpenAI indique avoir utilisé le modèle, depuis la fin de son entraînement, pour étudier des projets logiciels réels :

• Deux vulnérabilités inédites dans V8, le moteur JavaScript de Chrome, chaînables pour corrompre la mémoire et s’échapper du bac à sable du tas. Signalées à Google en divulgation coordonnée et corrigées sous la référence CVE-2026-15903, une vulnérabilité de gravité élevée où le compilateur optimisant omettait une vérification de sûreté lors d’une conversion de valeur en entier.
• Au moins cinq vulnérabilités dans un système d’exploitation mobile répandu, dont une chaîne partant d’une application non fiable jusqu’à l’élévation de privilèges locale.
• Trois vulnérabilités critiques dans une base de données répandue, dont un chemin d’exécution de code à distance.
• Plus de 400 vulnérabilités d’élévation de privilèges dans le noyau d’un système d’exploitation répandu.

À l’exception de V8, aucun de ces systèmes n’est nommé, et le travail de divulgation coordonnée est présenté comme en cours avec les partenaires du programme et la communauté open source. Sur son cadre de préparation, OpenAI classe GPT-5.6-Cyber au niveau élevé et non critique, comme Sol, et précise que ni ce modèle ni Astra n’ont été impliqués dans l’intrusion chez Hugging Face. (Source : OpenAI)

Quinze partenaires, et deux exigences imposées aux utilisateurs

Le même 10 août, OpenAI a étendu son programme partenaires. Les partenaires de services nommés sont Accenture, IBM, Capgemini, Cognizant, EY, KPMG, PwC, NCC Group et SpecterOps. Les partenaires technologiques sont Palo Alto Networks, CrowdStrike, Cisco, Sophos, Akamai, Fortinet et Cloudflare. Ces acteurs peuvent porter les modèles cyber d’OpenAI dans leurs produits, leurs services managés et leurs missions clients — y compris en équipe rouge et en test d’intrusion pour ceux qui accèdent au palier Red.

L’accès est contrôlé par vérification d’identité, sécurité des comptes, surveillance, restrictions d’usage approuvé et attestations juridiques. Deux mesures méritent une attention particulière, parce qu’elles s’adressent aux utilisateurs et non aux modèles :

• OpenAI encourage fermement ses clients Daybreak utilisant son agent de codage à basculer du mode d’accès complet vers le mode de revue automatique, qui évalue les actions requérant des permissions élevées avant leur exécution et peut bloquer celles qui présentent un risque de comportement destructeur.
• L’entreprise impose la clé de sécurité matérielle à tous les comptes individuels du programme à compter du 1er septembre 2026.

Les bonnes pratiques publiées avec l’annonce complètent le tableau, et elles ressemblent trait pour trait à la leçon des incidents de juillet : exécuter les travaux de sécurité dans des environnements contrôlés sans accès aux systèmes de production sensibles ni à l’Internet ouvert, tester régulièrement les limites du bac à sable, surveiller les actions de l’agent, et définir explicitement le périmètre des systèmes et des actions autorisés. (Source : OpenAI)

Les réserves à conserver

Toutes les mesures citées, y compris le taux de 95,0 %, sont des évaluations internes à OpenAI, dont l’instrument principal a été créé pour cette annonce. Aucune évaluation tierce indépendante n’a été publiée à ce jour, et la fiche système détaillée de GPT-5.6-Cyber est annoncée pour plus tard. Astra, enfin, n’est classé nulle part : l’entreprise dit ne pas pouvoir écarter le niveau critique, et ses évaluations se poursuivent. Les systèmes dans lesquels les vulnérabilités ont été trouvées ne sont pas nommés, à l’exception de V8 : « un système d’exploitation mobile répandu » ou « le noyau d’un système d’exploitation répandu » ne sont pas vérifiables en l’état. Et le seul témoignage client cité dans l’annonce émane d’un partenaire du programme.

Ce que cela change pour votre entreprise

Première conséquence, la plus immédiate : l’asymétrie de calendrier. Les vulnérabilités listées sont désormais connues et en cours de correction, mais la capacité qui les a trouvées est maintenant distribuée sous contrat. Plus de 400 vulnérabilités d’élévation de privilèges dans un seul noyau signifient qu’une politique de correctifs calée sur les cycles ordinaires ne suit plus. Le constat prolonge celui que nous faisions en juillet, lorsque Microsoft est passé de 200 à 570 correctifs en un seul cycle mensuel. Ce n’est plus un pic : c’est le nouveau régime, et il faut dimensionner la capacité de déploiement des correctifs en conséquence, pas la politique d’analyse.

Deuxième conséquence : une question nouvelle et vérifiable en appel d’offres. Quinze grands acteurs de la sécurité et du conseil peuvent désormais mobiliser ces modèles dans leurs missions. Cela introduit un critère de sélection qui n’existait pas il y a une semaine, et qui se formule simplement : votre équipe dispose-t-elle d’un accès au programme, à quel palier, et sous quelles attestations d’usage. Ce n’est pas une question de prestige technologique — c’est une question de périmètre contractuel, puisque le palier Red couvre l’équipe rouge et le test d’intrusion, et que l’accès y est encadré par des attestations juridiques dont votre propre engagement peut dépendre.

Troisième conséquence, et c’est celle à porter en comité : le fournisseur applique à ses utilisateurs les plus qualifiés des réglages que beaucoup d’organisations n’appliquent pas aux leurs. Une entreprise dont les agents de codage s’exécutent en accès complet, sans revue préalable des actions à permissions élevées, tourne aujourd’hui dans une configuration qu’OpenAI déconseille à des professionnels de la sécurité vérifiés. Et l’exigence de clé matérielle au 1er septembre pour les comptes du programme donne un repère utile pour tout accès à des outils agentiques disposant de droits élevés dans un système d’information.

Il faut ajouter une remarque de fond, parce qu’elle éclaire l’ensemble. La thèse d’OpenAI est explicite : la fenêtre dont disposent les défenseurs se referme, et il vaut mieux mettre l’intelligence de frontière entre leurs mains avant que les attaquants ne déploient la leur à grande échelle. Cette thèse est cohérente et rien dans les faits de la semaine ne permet de la contredire. Mais elle produit un effet mécanique dont il faut tenir compte : entre le moment où une vulnérabilité est trouvée et divulguée, et le moment où elle est corrigée dans votre parc, c’est votre délai de déploiement qui constitue la fenêtre d’exposition. C’est la seule variable de cette équation que vous contrôlez.

Ce que cela met à jour dans la Méthode Virtuose

Le chapitre consacré à la gouvernance, à la sécurité et à l’AI SecOps doit acter trois évolutions. D’abord, la capacité cyber offensive assistée par modèle cesse d’être un risque prospectif pour devenir une offre de marché encadrée, ce qui la fait entrer dans la sélection des prestataires et dans les clauses des contrats de service. Ensuite, un cadre de sûreté publié par un fournisseur peut désormais déclencher une réponse opérationnelle visible — suspension de travaux internes, surveillance de la chaîne de raisonnement, restriction des environnements — ce qui en fait un signal exploitable dans une revue de dépendance fournisseur, à condition de savoir le lire. Enfin, la doctrine d’exécution des agents doit être révisée : la revue préalable des actions à permissions élevées devient un réglage par défaut, pas une option de durcissement.

Le chapitre consacré aux agents, aux copilotes et au computer use est concerné par le volet pratique : les bonnes pratiques publiées avec l’annonce — exécution en environnement contrôlé sans accès à la production ni à l’Internet ouvert, test régulier des limites du bac à sable, surveillance des appels d’outils, définition explicite du périmètre autorisé — constituent désormais une référence énoncée par un fournisseur, opposable dans une discussion interne, et non plus une recommandation de bonne pratique parmi d’autres.