Le 18 août, OpenAI a rendu publique une décision déjà en cours de traitement en interne depuis un certain temps : l'évaluation des capacités de cybersécurité de son modèle de nouvelle génération, Astra, n'a pas permis de conclure qu'il était "sûr", ce qui a conduit l'entreprise à arrêter, pendant deux semaines, l'entraînement par apprentissage par renforcement (RL) du modèle le plus récent en production. Au moment de la publication, la plus grande session de RL de pointe n'avait toujours pas repris ; seuls les entraînements et évaluations de moindre ampleur se poursuivaient normalement.
L'information avait d'abord émergé le 7 août, quand la version connue à l'extérieur était celle d'un "report du lancement d'Astra par OpenAI". L'article du 18 août dévoile la chaîne de raisonnement derrière ce report : les évaluations internes montraient que les progrès d'Astra en programmation autonome et en attaque/défense cyber étaient tels que l'entreprise ne pouvait pas exclure que le modèle ait déjà atteint le niveau Critical.
Un seuil plus concret qu'on ne l'imagine
Le Preparedness Framework d'OpenAI traduit le seuil Critical en cybersécurité en deux descriptions de capacités vérifiables : le modèle est capable d'écrire de manière autonome des exploits zero-day utilisables, visant plusieurs systèmes critiques réels déjà durcis ; ou, en ne recevant qu'un objectif de haut niveau, il est capable de concevoir et d'exécuter seul une attaque inédite de bout en bout contre une cible durcie.
La conclusion de l'évaluation interne s'est arrêtée au niveau "impossible à exclure", sans confirmer que le seuil était atteint. Mais à en juger par les mesures prises ensuite par l'entreprise, ce niveau a suffi à déclencher un ralentissement préventif : sans attendre de confirmation, ce sont d'abord les entraînements les plus gourmands en calcul, et les plus susceptibles de pousser encore davantage les capacités du modèle, qui ont été arrêtés.
Ce qu'on arrête, c'est l'entraînement ; ce qu'on change, c'est le datacenter
La pause n'est que la moitié de l'histoire. OpenAI a également détaillé une série de changements au niveau de l'infrastructure : isolation des sandbox et séparation réseau renforcées, suppression des services partagés faciles à percer, réduction des autorisations à validité prolongée, journaux de sécurité complétés. Une grande partie des charges de travail d'Astra reste aujourd'hui suspendue, en attente d'être migrée vers des environnements conformes aux nouvelles exigences.
C'est du côté de la surveillance que viennent les chiffres les plus concrets. Le nouveau dispositif de surveillance se compose de deux éléments : un classificateur d'activation opérant au niveau du token, chargé de signaler les comportements suspects pendant la génération, et un enquêteur automatisé, chargé de revérifier ce qui a été signalé. Cette surveillance consomme environ 20 % de la capacité de calcul d'inférence. La fenêtre de réponse cible pour les alertes est fixée à moins de 30 minutes, tout comme le délai dont dispose l'équipe de sécurité pour écarter les fausses alertes.
20 %, sur le papier, ressemble à un simple paramètre technique ; converti en dépenses, c'est autre chose. Les coûts annuels de calcul d'inférence des laboratoires de pointe se situent généralement dans l'ordre du milliard de dollars (estimation approximative, les méthodes de calcul variant d'une entreprise à l'autre), et affecter en permanence un cinquième de ce budget à la surveillance représente un coût fixe de l'ordre du milliard de dollars, un montant qui ne génère aucune capacité utile côté utilisateur. Le fait d'accepter de porter durablement ce coût suggère que l'entreprise n'anticipe pas une fenêtre de risque qui se refermerait en quelques semaines, mais une fenêtre couvrant tout le cycle de vie du modèle de nouvelle génération.
Une autre voie comparable consisterait à donner en priorité les capacités d'attaque/défense au camp défensif, en ouvrant des modèles de recherche de failles à une liste restreinte, échangeant ainsi une surface de déploiement contrôlée contre un délai de réaction. Cette fois, OpenAI a choisi une voie plus en amont, en freinant directement au niveau de l'entraînement. Les deux approches répondent au même constat : la capacité d'attaque des modèles progresse plus vite que le rythme de correction du côté défensif.
Un garde-fou qu'elle s'impose elle-même
Ce processus ne laisse aucune place à une supervision externe. Conditions de déclenchement, critères d'évaluation, durée de la pause, critères de reprise : tout est écrit, jugé et exécuté par OpenAI elle-même, l'extérieur ne recevant qu'une communication a posteriori. L'article ne fournit aucun chiffre vérifiable par un tiers sur la manière dont le seuil Critical est concrètement mesuré, ni sur les scores obtenus par Astra à chaque test. L'entreprise a par ailleurs précisé un point : l'incident de sandbox chez Hugging Face, qui avait suscité des débats, n'a aucun lien avec Astra.
Pour les développeurs qui suivent de près l'avancement, l'impact à court terme se concentre sur deux points : les échéances de lancement des fonctionnalités liées à Astra seront repoussées, et les charges de travail Astra déjà en cours devront migrer d'environnement en conséquence, à un rythme fixé unilatéralement par OpenAI. Quant à la date de reprise de la plus grande session de RL de pointe, l'entreprise n'a donné aucune indication.
Sources : blog officiel d'OpenAI, Axios, CocoLoop, AIGC News ; la définition du seuil Critical dans le Preparedness Framework, la part de 20 % de calcul consacrée à la surveillance et la fenêtre d'alerte de 30 minutes ont été vérifiées à partir des déclarations publiques d'OpenAI.