Claude Mythos – Face à la « bug-calypse » qui se profile

Le prochain modèle de langage étendu (LLM) d’Anthropic, baptisé Claude Mythos, a été annoncé le 7 avril 2026, après une fuite accidentelle le 26 mars. Contrairement aux précédents modèles LLM de pointe rendus publics, Anthropic a choisi de réserver l’accès à certaines entreprises, sur invitation uniquement, en raison de sa capacité exceptionnelle à détecter des vulnérabilités logicielles et à écrire des exploits.

Depuis, d’innombrables articles ont analysé ce que Claude Mythos pourrait changer pour l’industrie du logiciel, les équipes de cybersécurité, les entreprises et la société dans son ensemble. Le sujet a même gagné les médias grand public, au point d’alimenter les conversations de personnes peu familières avec la technologie.

Dans cet article, nous expliquons ce qu’est Claude Mythos, ses conséquences pour la cybersécurité et celles des modèles concurrents, ce que cela signifie concrètement pour les équipes de défense des entreprises, les mesures à prendre pour gérer cette vague, l’influence majeure de l’IA agentique et des frameworks d’orchestration sur l’efficacité, ainsi que les raisons pour lesquelles l’accélération du rythme des vulnérabilités marquera la prochaine ère, parfois appelée la « bug-calypse ».

Qu’est-ce que Claude Mythos ?

Claude Mythos est le modèle de pointe à accès restreint d’Anthropic pour l’analyse avancée en cybersécurité.

Chaque laboratoire d’IA de pointe attribue un nom et un numéro de version à ses modèles. Mythos est le nouveau modèle d’Anthropic centré sur le développement logiciel.

Selon Nicholas Carlini, chercheur en cybersécurité chez Anthropic, l’équipe ne cherchait pas à créer un modèle spécifiquement performant pour détecter et exploiter des vulnérabilités logicielles. Son objectif était plutôt de concevoir un modèle exceptionnel en programmation de manière générale. La détection de bugs a été une conséquence de cette orientation.

L’AI Security Institute britannique l’a testé dans un cyber-range : Mythos est arrivé en tête, suivi de Claude Opus 4.6, puis de GPT-5.4 et GPT-5.3 Codex d’OpenAI.

ExploitGym fournit également un environnement de test dans lequel des agents d’IA doivent détecter des vulnérabilités et écrire des exploits pour 898 vulnérabilités connues, couvrant des programmes en espace utilisateur, le moteur JavaScript V8 de Google et le noyau Linux. 

Claude Mythos Preview et GPT-5.5 d’OpenAI obtiennent des résultats nettement supérieurs à ceux des générations précédentes.

Anthropic a observé des résultats similaires lors de ses premiers tests. L’entreprise a donc décidé de repousser la mise à disposition publique de Claude Mythos, afin de permettre d’abord aux grandes entreprises technologiques de détecter et de corriger leurs vulnérabilités.

Qu’est-ce que Project Glasswing ?

Nommé d’après le célèbre papillon qui se dissimule « à la vue de tous », Project Glasswing d’Anthropic a invité plus de 50 entreprises à utiliser Mythos en préversion privée pour détecter et corriger des vulnérabilités avant que des attaquants ne s’en servent pour développer des exploits visant des failles encore non corrigées. Parmi les invités figuraient AWS, Apple, Cisco, Google, The Linux Foundation, Microsoft, Nvidia et Palo Alto. Anthropic a également accordé jusqu’à 100 millions de dollars de crédits d’utilisation aux participants.

Une question légitime consiste à savoir s’il s’agit seulement d’une stratégie marketing habile ou d’une véritable tentative d’agir de manière responsable face à une nouvelle capacité très puissante. La réponse se situe probablement entre les deux. Les premiers tests montrent clairement un saut de performance, mais une couverture dans les médias grand public ne nuit évidemment pas aux efforts marketing.

Au moment de la rédaction, en juin 2026, un accès public à Mythos ne semble pas prévu à court terme. En revanche, le programme a été élargi à 150 entreprises supplémentaires dans 15 pays, couvrant les infrastructures critiques, l’énergie, l’eau, la santé, les communications et le matériel informatique.

Tout dépend-il du modèle ?

La capacité « one-shot » de Mythos a beaucoup fait parler : « voici une base de code, trouve-moi des vulnérabilités ». Pourtant, ce n’est pas ainsi qu’une entreprise construit un moteur d’analyse chargé de détecter des vulnérabilités, de les vérifier, d’écrire des exploits, de les valider puis, idéalement, de générer des correctifs.

Il faut plutôt un framework d’orchestration composé de plusieurs agents d’IA, chacun chargé d’une étape précise de la chaîne de travail. Niels Provos, chercheur en sécurité reconnu, a d’ailleurs voulu démontrer qu’un bon framework utilisant des modèles d’IA publics existants pouvait être tout aussi efficace pour détecter des vulnérabilités.

Le principal enseignement est que les LLM et les agents tendent naturellement à vouloir atteindre rapidement un résultat final. En divisant le travail en étapes plus petites, ils peuvent toutefois accomplir chaque tâche de manière indépendante. Différents modèles et outils d’IA peuvent aussi assister différents agents, afin d’utiliser le meilleur outil à chaque étape.

Cette approche s’appuie également sur des travaux antérieurs, notamment l’AI Cybersecurity Challenge (AIxCC) de la DARPA, organisé d’août 2023 à août 2025. Sept équipes finalistes devaient créer un système entièrement automatisé capable de détecter des vulnérabilités, de produire une Proof of Vulnerability (PoV) pour chacune d’elles, puis d’écrire, de tester et d’appliquer un correctif.

Plusieurs membres de l’équipe gagnante, Atlanta, travaillent désormais chez Microsoft sur un service de framework d’analyse portant le nom de code MDASH.

Qu’est-ce que le nom de code MDASH ?

Ce framework d’analyse agentique multi-modèle utilise plus de 100 agents d’IA fondés sur différents modèles, probablement dont Mythos puisque Microsoft participe à Glasswing, afin de détecter des vulnérabilités. Le récent Patch Tuesday de Microsoft comprenait 16 correctifs pour des vulnérabilités de la pile réseau et d’authentification de Windows détectées avec MDASH. Lors d’un test portant sur cinq années de vulnérabilités signalées dans la fonction de journalisation de Windows, MDASH a retrouvé 96 % des bugs recensés, ainsi que 100 % des bugs signalés dans la pile réseau TCP.

Microsoft l’a également testé sur le benchmark public CyberGym, où MDASH a obtenu la première place.

Il est clair qu’un framework réunissant plusieurs agents qui travaillent de concert surpasse les requêtes uniques, et que la détection des vulnérabilités n’est que la première étape.

Il est essentiel de confirmer qu’un bug est réel, qu’il ne s’agit pas d’un doublon déjà connu et qu’il peut être exploité. En outre, les bugs modernes, en particulier sous iOS et Android, exigent souvent l’enchaînement de plusieurs vulnérabilités, ce qu’une seule requête accomplit difficilement. Surtout, de nouveaux modèles peuvent être intégrés dès qu’ils deviennent disponibles.

Le framework constitue donc le moteur, tandis que les différents modèles, chacun efficace à certaines phases, sont testés et ajoutés au fil du temps.

Résultats de Project Glasswing à ce jour

Palo Alto publie habituellement entre 10 et 15 correctifs par mois. Ce mois-ci, l’entreprise en a publié 24.

Cloudflare a analysé 50 dépôts de code internes et constaté de nettes améliorations dans la construction de chaînes d’exploitation et la génération de preuves. Plus important encore, le rapport signal/bruit s’est amélioré : les résultats de Mythos étaient de meilleure qualité. Cloudflare a également souligné l’importance d’un bon framework, capable de décomposer chaque tâche et de faire travailler les agents en parallèle. L’analyse a révélé 2 000 bugs, dont 400 classés comme élevés ou critiques.

Mozilla a détecté 271 vulnérabilités dans la version 150 du navigateur Firefox, soit plus de dix fois le nombre trouvé dans la version 148 avec un modèle Anthropic antérieur.

Anthropic a utilisé Mythos pour analyser plus de 1 000 projets open source. Le modèle a détecté 23 019 vulnérabilités potentielles, dont 6 202 classées comme élevées ou critiques. Anthropic en a vérifié manuellement 1 752 : plus de 90 % étaient valides et plus de 62 % ont été confirmées comme élevées ou critiques.

Le Data Breach Investigations Report 2026 de Verizon, référence annuelle du secteur couvrant la période d’octobre 2024 à novembre 2025, met en évidence un résultat particulièrement intéressant : l’exploitation de vulnérabilités est désormais le vecteur d’accès initial le plus courant, avec 31 %, tandis que l’utilisation abusive d’identifiants, jusque-là en tête, est tombée à 13 %.

Il faut ici dissiper un mythe sur les LLM et leurs garde-fous. Demandez aujourd’hui à l’un d’eux de vous expliquer comment fabriquer une bombe, créer une arme biologique ou produire un exploit pour une vulnérabilité logicielle : il refusera.

Mais ces blocages sont « souples » et peuvent être contournés avec suffisamment d’insistance. Il n’existe aujourd’hui aucun moyen de créer un LLM qui puisse détecter des vulnérabilités et écrire des exploits uniquement pour les équipes de défense, sans pouvoir faire de même pour les attaquants.

OpenAI mène également un projet similaire, appelé Daybreak. Il faut donc s’attendre à voir apparaître davantage d’outils d’analyse par IA centrés sur la cybersécurité.

L’essor de l’analyse de vulnérabilités par IA en tant que service

Les premiers résultats prometteurs de MDASH et des frameworks d’analyse de Cloudflare favoriseront l’essor de services managés permettant aux entreprises d’analyser leur propre code. OpenHack, proposé par Hadriansecurity, constitue une option open source dans laquelle l’entreprise choisit les modèles à utiliser.

Dans le domaine de l’open source, IBM et Red Hat collaborent sur Project Lightwell. Leur objectif est de mobiliser 20 000 ingénieurs, renforcés par l’IA, afin d’aider les entreprises à sécuriser les logiciels open source dont plus de 90 % dépendent.

Google a également annoncé AI Threat Defense, qui doit valider les risques, générer des correctifs et prendre en charge les workflows de remédiation.

À l’inverse, il faut surveiller l’essor des « Anonymous LLMs as a Service ». Des groupes criminels peuvent louer un accès à des modèles auprès de fournisseurs qui gèrent des identifiants volés, puis exécuter leurs charges de travail d’IA.

Guide pratique pour les équipes de défense dans l’ère post-Mythos

Étape 1

Comme l’indique la couverture du Guide du voyageur galactique : « Pas de panique ». Oui, les LLM et les frameworks d’analyse permettront de trouver davantage de vulnérabilités logicielles. Mais les équipes de défense s’adapteront, et ces outils leur sont aussi accessibles : analysez et corrigez les bugs de vos logiciels avant que les attaquants ne le fassent. Nous avons déjà connu ce type de transition.

Lorsque les premiers décompilateurs sont apparus, certains pensaient que les spécialistes de l’ingénierie inverse deviendraient inutiles. Puis sont venus les fuzzers et les outils d’analyse statique. À chaque étape de la course entre attaquants et équipes de défense, nous nous sommes adaptés et améliorés.

Étape 2

Étape 2 – Les fondamentaux n’ont pas changé. La protection d’une entreprise contre les cybercriminels repose toujours sur une bonne hygiène de cybersécurité. La plupart des violations ne sont pas causées par des failles zero-day, mais par des erreurs humaines.

Des attaquants habiles peuvent appeler le helpdesk avec toutes les informations personnelles nécessaires, faire réinitialiser les identifiants d’un compte administrateur, puis chiffrer tous les serveurs avec un ransomware, comme cela s’est produit chez Jaguar Land Rover. Ils peuvent aussi convaincre une personne de cliquer sur un lien dans un email de phishing. Ces scénarios n’ont rien à voir avec des vulnérabilités logicielles.

Étape 3

Il faudra corriger plus rapidement les logiciels essentiels à l’activité. Le délai entre la découverte d’une vulnérabilité et la disponibilité d’un exploit opérationnel diminue depuis huit ans, comme le montre le projet Zero Day Clock. Cette baisse s’est produite en grande partie avant que l’IA ne soit utilisée pour détecter les vulnérabilités. Mais le rythme va encore s’accélérer à mesure que Claude Mythos et les modèles similaires se généraliseront.

Étape 4

Étape 4 – Adoptez le Continuous Threat Exposure Management (CTEM). Les entreprises tentent depuis plus de dix ans, sans réel succès, d’appliquer les correctifs plus vite. Le CTEM prend le relais là où la gestion traditionnelle des vulnérabilités (VM) atteint ses limites.

Une solution VM fournit une liste très longue de logiciels vulnérables dans l’ensemble de l’entreprise, avec une priorité faible, moyenne, élevée ou critique, généralement basée sur le score CVSS. Les équipes IT et de sécurité, souvent surchargées, finissent donc par traiter uniquement les correctifs élevés et critiques, parfois après plus de 30 jours.

Le CTEM évalue au contraire les risques de sécurité sur l’ensemble du patrimoine numérique, détecte les vulnérabilités et les classe selon le contexte et l’environnement, plutôt que selon un score CVSS générique. Une vulnérabilité dans la base de données d’un serveur isolé d’Internet est peu prioritaire. Elle devient critique s’il existe un chemin d’accès depuis Internet. Les vulnérabilités de risque moyen deviendront également des cibles légitimes pour l’IA, qui pourra développer des exploits contre elles, alors que les attaquants humains y consacraient rarement du temps.

Il faut aussi dissiper un autre mythe : appliquer un correctif ne rend pas toujours un système plus sûr. La recommandation d’installer tous les correctifs dès leur publication repose surtout sur le travail coordonné de grandes équipes et, désormais, de frameworks d’analyse par IA. Ces équipes reçoivent les vulnérabilités signalées dans le cadre de programmes de bug bounty, les trient, les hiérarchisent, créent des correctifs de sécurité spécifiques, puis les diffusent chaque mois. Cette méthode s’applique aux principaux navigateurs web, aux systèmes d’exploitation mobiles et de bureau, aux grandes infrastructures Cloud et au code de certains fournisseurs de sécurité.

Pour les autres logiciels et services SaaS utilisés par l’entreprise, les correctifs introduisent statistiquement souvent davantage de nouvelles vulnérabilités qu’ils n’en résolvent. Bien entendu, lorsqu’une vulnérabilité connue est activement exploitée et qu’un correctif est disponible, il faut l’installer au plus vite. Mais il ne faut pas supposer qu’un système corrigé est automatiquement plus sûr.

Étape 5

Si votre entreprise développe et maintient du code, pour des applications internes ou destinées à des clients, elle devra commencer à l’analyser régulièrement avec un bon framework soutenu par des modèles performants. Pour les nouveaux projets, il est utile d’intégrer cette analyse dès le départ afin de réduire les reprises ultérieures. Il faut toutefois prévoir suffisamment de ressources pour gérer le volume de problèmes que l’IA risque de détecter.

Le code source a toujours fait partie des actifs les plus précieux. Il devrait donc déjà bénéficier d’une protection adaptée. Désormais, toute fuite pourrait toutefois entraîner une analyse en quelques heures ou quelques jours, puis le développement d’exploits à la vitesse d’une machine.

Étape 6

La pile logicielle de l’entreprise comprend presque certainement des composants open source. Comme leur code source est public, les attaquants pourront les analyser librement. Les équipes de développement doivent donc être encore plus conscientes des risques liés aux attaques de la chaîne d’approvisionnement. Le code interne peut être excellent et régulièrement analysé.

Mais si une dépendance contient un bug non corrigé, l’application peut rester vulnérable. Il est important de soutenir les structures qui accompagnent les projets open source : elles auront besoin de services d’analyse par IA pour faire face à la vague de bugs à venir.

Pour gérer les défis à venir, il faut également comprendre comment encadrer en interne les LLM, les agents d’IA et les serveurs MCP. L’organisme à but non lucratif Center for Internet Security (CIS) propose trois guides utiles.

Étape 7

Développez une véritable culture de résilience en cybersécurité dans toute l’entreprise. Il ne suffit plus de consacrer un budget minimal à la cybersécurité, de la considérer uniquement comme un centre de coûts plutôt que comme un levier de croissance sûre, puis de gérer les conséquences lorsqu’une violation survient.

Le renforcement de l’environnement devient essentiel : protéger les données sensibles dans SharePoint et OneDrive, empêcher les emails malveillants d’atteindre les boîtes de réception, et former correctement les personnes afin qu’elles ne tombent pas dans les pièges qui franchissent les défenses.

---

Réduisez votre exposition dans Microsoft 365 avant que des attaques à la vitesse de l’IA ne l’exploitent

Claude Mythos montre clairement que le cycle de vie des vulnérabilités s’accélère. Les attaquants et les équipes de défense agissent plus vite. Les entreprises qui attendent une violation pour assainir leurs autorisations Microsoft 365 auront toujours un temps de retard.

Avec 365 Permission Manager d’Hornetsecurity, les équipes de sécurité et les administrateurs Microsoft 365 reprennent le contrôle sur les accès dans Teams, SharePoint et OneDrive. Utilisez-le pour détecter les partages risqués, appliquer des politiques de conformité, recevoir des alertes en cas de modification critique des autorisations, corriger les violations et générer les rapports nécessaires pour prouver que les accès sont maîtrisés.

Vous souhaitez réduire l’exposition des données et renforcer la gouvernance de Microsoft 365 ? Demandez un essai gratuit de 365 Permission Manager d’Hornetsecurity.

---

Conclusion

L’IA générative continue de transformer la cybersécurité. Claude Mythos met en lumière le manque de qualité du code de nombreux logiciels utilisés par les entreprises. Votre entreprise doit donc appliquer les mesures présentées afin de gérer la vague de bugs à venir.