OpenAI dit que son modèle a trouvé 2 zero-days dans V8 — j’ai relu nos 4 règles de divulgation

Panos Petropoulos

Expert développement web · 5 septembre 2026 · 9 min de lecture

Le 3 septembre 2026, OpenAI a publié GPT-6 Astra en le désignant comme le premier de ses modèles à franchir le seuil « Critique » de capacité en cybersécurité. Le détail qui a retenu mon attention n’est pas la classification, c’est une ligne du rapport d’évaluation : pendant les tests, le modèle a trouvé deux failles que personne ne connaissait dans V8. J’ai passé la soirée à relire nos propres règles de réception des signalements. Voici ce qui en ressort.

Ce qui a été annoncé, précisément

OpenAI a publié GPT-6 Astra le 3 septembre 2026, en le décrivant comme son modèle le plus performant et le plus aligné à ce jour. La nouveauté qui compte pour nous est la classification : c’est le premier système de l’entreprise à atteindre le seuil « Critique » de capacité en cybersécurité au titre de son Preparedness Framework.

La définition de ce seuil, telle qu’OpenAI la formule, est précise et mérite d’être citée pour ce qu’elle dit vraiment : avec les outils et les accès appropriés, le modèle peut trouver des failles de sécurité jusque-là inconnues et développer de nouvelles façons de les exploiter sur de nombreux systèmes bien protégés, sans qu’un humain guide chaque étape. Ce dernier point est le vrai basculement : il ne s’agit plus d’un assistant qui accélère un chercheur, mais d’un système qui enchaîne les étapes seul.

Le protocole d’évaluation est documenté. OpenAI a constitué un banc de test interne de 20 vulnérabilités de sévérité élevée de V8 — le moteur JavaScript de Chromium — divulguées entre juin et août 2026. Sur ce banc, Astra a obtenu des taux d’exécution de code arbitraire nettement supérieurs à ceux de GPT-5.6 Sol. Et pendant cette évaluation, il a découvert et utilisé deux vulnérabilités jusque-là inconnues ; OpenAI indique les avoir signalées aux mainteneurs.

Côté mesures d’accompagnement, l’entreprise dit avoir retardé une partie du développement et de la publication de plusieurs semaines pour renforcer les protections contre les usages cyber malveillants et les actions non autorisées du modèle. Le déploiement commence par un ensemble restreint d’organisations, avec un élargissement annoncé dans les jours suivants. La tarification de l’API se situe à 10 dollars par million de jetons en entrée et 50 dollars par million en sortie.

La couverture a insisté sur un autre angle : Axios rapporte qu’OpenAI présente le modèle comme pouvant représenter une forme d’AGI. C’est le genre d’affirmation qui monopolise la discussion. Pour un mainteneur de projet open source, elle est très largement hors sujet — les deux zero-days, eux, ne le sont pas.

L’asymétrie qui devrait nous inquiéter

On lit souvent que ces capacités profitent autant à la défense qu’à l’attaque. C’est vrai sur le papier, et faux dans le calendrier. Trouver une faille et corriger une faille ne coûtent pas la même chose, et surtout ne se heurtent pas aux mêmes contraintes.

Côté attaque, la découverte est le goulot d’étranglement. Une fois la faille trouvée, l’exploitation est un problème technique borné. Côté défense, la découverte n’est que le début : il faut trier le signalement, reproduire le bug, écrire un correctif qui ne casse rien, le faire relire, publier une version, puis attendre que l’écosystème la déploie. Ces étapes reposent sur des humains, souvent bénévoles, souvent seuls.

Automatiser la première moitié de la chaîne d’attaque sans automatiser la seconde moitié de la chaîne de défense, c’est déplacer le point de rupture. Et ce point de rupture, pour la plupart des projets, c’est une seule personne qui lit une boîte mail.

Les 4 règles que nous appliquons désormais

Après cette annonce, j’ai repris nos règles de réception des signalements. Elles n’ont rien de sophistiqué, mais elles répondent au bon problème : la charge de tri, pas la découverte.

1. Une adresse de contact sécurité qui existe et qui est lue. Le fichier SECURITY.md à la racine du dépôt, avec une adresse qui arrive dans une boîte réellement consultée. Cela paraît trivial ; c’est le premier point de défaillance sur la majorité des projets que nous auditons. Une adresse qui rebondit transforme une divulgation responsable en divulgation publique.

2. Un délai de réponse annoncé, même modeste. Écrire « nous accusons réception sous 7 jours » vaut infiniment mieux que ne rien écrire. Un chercheur qui n’a aucune idée du délai attendu publie plus vite. Un délai annoncé, même long, achète du temps — à condition de le tenir.

3. Une politique explicite sur les rapports assistés par IA. C’est la règle nouvelle, et elle est directement liée à l’annonce du 3 septembre. Beaucoup de projets reçoivent déjà des volumes croissants de signalements générés automatiquement, souvent plausibles en apparence et faux au fond. Décidez maintenant ce que vous exigez : un cas de reproduction exécutable, une version affectée précise, et le refus explicite des rapports non reproductibles. Écrivez-le dans le SECURITY.md.

4. Une chaîne de publication qui survit aux vacances. Pouvoir publier un correctif ne doit pas dépendre d’une seule personne détenant les clés de signature ou les accès de publication. Deux mainteneurs au minimum doivent pouvoir sortir une version. C’est le point le plus pénible à mettre en place et celui qui compte le plus le jour où ça arrive.

Le vrai risque est en aval, chez ceux qui consomment

Il y a un angle mort dans la discussion. On parle des mainteneurs, mais la majorité des développeurs ne maintiennent pas V8 : ils l’utilisent, à travers dix couches de dépendances qu’ils n’ont jamais lues.

Si la découverte de failles s’accélère, le facteur limitant du côté défensif devient la vitesse à laquelle un correctif publié en amont arrive dans les applications déployées. Sur ce terrain, la plupart des équipes sont mauvaises, et pour des raisons structurelles : personne ne sait exactement quelles versions tournent en production, les mises à jour de dépendances sont repoussées parce qu’elles cassent des choses, et l’inventaire n’existe que dans la tête de deux personnes.

C’est exactement le problème que documentent les rapports de branche sur le doublement des attaques sur la chaîne d’approvisionnement open source, et que nous avons vu se matérialiser lors de la compromission de 444 paquets npm en août 2026. La leçon commune de ces deux épisodes est que la difficulté n’est jamais de corriger — c’est de savoir ce qu’on fait tourner.

Ce qu’il faut éviter de conclure trop vite

Deux précautions honnêtes, parce que le sujet se prête aux emballements.

Les chiffres viennent d’OpenAI et concernent OpenAI. Le banc de 20 vulnérabilités V8 est un banc interne, conçu et évalué par l’entreprise qui commercialise le modèle. Ce n’est pas une raison de l’écarter — les deux zero-days signalés aux mainteneurs sont un fait vérifiable en aval — mais c’est une raison d’attendre des évaluations indépendantes avant d’extrapoler.

Le seuil « Critique » est une classification maison. Le Preparedness Framework est le référentiel d’OpenAI, pas une norme externe. Cela n’enlève rien à la valeur de l’information, mais « premier modèle Critique » ne veut pas dire « premier modèle capable de faire cela » : cela veut dire « premier modèle qu’OpenAI classe ainsi selon ses propres critères ».

La question réellement actionnable pour un mainteneur reste la même, et elle ne dépend d’aucun de ces débats : combien de temps s’écoule aujourd’hui entre un signalement crédible et un correctif publié ? Si vous ne connaissez pas ce chiffre, c’est le premier à mesurer. Pour les équipes qui construisent des produits sur ces briques, la même logique s’applique au moment de concevoir une plateforme ou une application fintech : l’inventaire des dépendances fait partie de l’architecture, pas de la maintenance.

Questions fréquentes