Anthropic a publié le 1er septembre deux modèles présentés comme identiques : « Claude Fable 5.1 et Claude Mythos 5.1 sont le même modèle, mais avec des niveaux de garde-fous différents. » Le premier est ouvert à tous et sait désormais identifier des vulnérabilités dans du code source, sans produire d'exploit ; le test d'intrusion, la génération d'exploits et l'analyse de binaires restent refusés. Le second lève ces limites, mais n'est accessible qu'au travers d'un programme d'accès vérifié destiné aux professionnels de la sécurité. Deux jours plus tard, OpenAI classait son nouveau modèle au niveau « critique » de sa propre grille de capacités cyber, avec le même dispositif : accès élargi après vérification d'identité.
Deux laboratoires concurrents, quarante-huit heures d'écart, la même décision. Ce n'est pas une coïncidence de calendrier : c'est une doctrine qui se fixe.
La frontière entre « trouver » et « exploiter » est commode à énoncer et poreuse en pratique. En audit, la preuve d'exploitabilité est souvent le seul moyen de séparer une vulnérabilité réelle d'une anomalie théorique. Un débordement dans une fonction que vos flux n'atteignent jamais ne justifie pas une fenêtre de maintenance ; le même débordement accessible depuis une interface exposée en justifie une le soir même. Seule la tentative d'exploitation permet de trancher.
La restriction gêne donc d'abord celui qui défend. Celui qui attaque ne s'inscrit à aucun programme de vérification : il utilise un modèle à poids ouverts, ou il contourne. Anthropic le documente lui-même — des chercheurs avaient obtenu du code d'exploitation de la version précédente en demandant simplement une identification de vulnérabilité.
Le goulot d'étranglement d'un audit n'a jamais été de trouver des failles ; c'est de les remettre en contexte : quelle version tourne vraiment en production, quel chemin de code est atteignable depuis l'extérieur, quelle compensation existe déjà. Un modèle qui signale une faiblesse dans un fichier isolé ne répond à aucune de ces trois questions.
En revanche, un point nouveau apparaît dans les appels d'offres : votre prestataire est-il adhérent d'un programme d'accès vérifié ? La réponse est vérifiable, et elle dit quelque chose de ses moyens réels.
Elle ouvre aussi un autre sujet. Adhérer suppose d'envoyer du code, parfois des binaires, à un modèle hébergé par un tiers. Sur un périmètre sous clause de confidentialité ou contrainte de souveraineté, la question se pose avant la mission, pas pendant.
Votre fenêtre d'exposition se réduit. L'hypothèse implicite qu'une faille obscure, dans un composant peu regardé, resterait ignorée des mois durant ne tient plus.
Trois questions à porter au prochain comité : combien de temps sépare chez vous la publication d'un correctif de son application réelle, quels composants tiers embarqués ne sont couverts par aucune veille, et dans quel cadre juridique votre code sortirait de chez vous si votre auditeur passe par un modèle externe.
Choisir un modèle « souverain » ne suffit pas à rendre un usage conforme. Ce qui se contrôle, ce sont les données qui sortent, ce qu'en fait le prestataire, et la trace qu'on en garde.
Le standard est publié depuis 2024. Ce qui bloque en entreprise n'est pas le choix de l'algorithme, c'est de savoir où la cryptographie se trouve réellement — et combien de temps les équipements déjà déployés vont vivre.
CyberIA Labs
