Claude Mythos a été capable de trouver des milliers de failles critiques en quelques semaines, dont certaines vieilles de 27 ans, sans aucune intervention humaine. Le taux de succès en exploitation directe : 83%. De là se demander comment notre industrie va réagir à ce changement, parce que Mythos n’est pas une nouvelle dans la colonne « AI au service de la cybersécurité ». C’est le signal que le modèle fondamental sur lequel toute l’industrie a construit ses défenses depuis trente ans vient de devenir obsolète.
Ce que Mythos révèle vraiment
Claude Mythos Preview est un modèle d’Anthropic dans une catégorie distincte des modèles existants, supérieur, selon la compagnie elle-même, à tout autre système frontalier disponible à ce jour. Son mode de fonctionnement est simple à comprendre et difficile à accepter : on lui fournit du code source, on lui dit « trouve une vulnérabilité », et le système travaille seul. Il lit, émet des hypothèses, teste avec des débogueurs, chaîne des primitives d’exploitation, et produit soit un rapport détaillé avec un exploit fonctionnel, soit la conclusion qu’aucune faille n’existe.
Les résultats publiés dans le cadre du Project Glasswing parlent d’eux-mêmes. Des milliers de vulnérabilités zero-day identifiées sur l’ensemble des systèmes d’exploitation et navigateurs majeurs. Un bug de 27 ans dans OpenBSD. Une faille de 16 ans dans FFmpeg que cinq millions de passages d’outils automatisés n’avaient jamais détectée. Des vulnérabilités chaînées dans le noyau Linux permettant une escalade de privilèges de l’utilisateur au contrôle total de la machine. Tout cela sans qu’un humain ait posé la moindre ligne de code d’exploit.
Ce chiffre mérite qu’on s’y arrête : 83,1% de taux de succès en première tentative. Pour donner une référence, le meilleur chercheur en sécurité du monde ne fait pas 83% au premier essai sur des vulnérabilités inconnues.
Anthropic a réagi de façon pragmatique en limitant l’accès et en constituant Project Glasswing, un consortium d’une quarantaine d’entreprises critiques comme AWS, Apple, Microsoft, Cisco ou JPMorgan Chase, pour que les éditeurs puissent corriger leurs propres systèmes avant que les capacités ne se diffusent. C’est responsable. Mais est-ce suffisant ?
L’attaque intelligente : bien au-delà de la découverte de failles
Ce que Mythos démontre sur la découverte de vulnérabilités est spectaculaire. Mais la menace la plus profonde des LLM en contexte offensif ne se limite pas à trouver des failles. Elle touche à quelque chose de plus fondamental : la capacité d’un logiciel malveillant à raisonner sur son environnement.
Imaginez un malware qui, une fois implanté dans un système, ne lance pas immédiatement son payload. À la place, il interroge silencieusement l’environnement. Quels logiciels sont installés ? Quelles versions ? Quels outils de sécurité tournent en arrière-plan ? Quels sont les processus légitimes typiques de cet utilisateur, à quelle heure, avec quelle fréquence ? Quels rapports de sécurité sont accessibles sur le réseau, et quelles sont leurs lacunes documentées ?
Ce scénario n’est plus de la science-fiction. C’est la direction naturelle d’un LLM embarqué dans un contexte d’attaque. Les techniques dites « Living off the Land » — qui consistent à utiliser les outils légitimes déjà présents dans le système pour éviter toute détection — ont toujours été redoutées précisément parce qu’elles ne laissent pas de signature. Un LLM peut les pousser à un niveau que nous n’avons jamais vu : analyser tous les exécutables présents, identifier ceux qui correspondent à la posture de sécurité de la cible, et construire une chaîne d’attaque parfaitement adaptée, en temps réel, sans jamais toucher un outil reconnu comme malveillant.
La sécurité opérationnelle de l’attaquant devient elle aussi assistée par IA. Observer les patterns de connexion d’un utilisateur pendant quelques jours et n’agir que dans les fenêtres où une activité anormale sera noyée dans le bruit quotidien. Lire les limitations connues d’un EDR déployé sur le réseau cible et adapter les techniques d’exfiltration en conséquence. Créer un comportement qui ressemble à un utilisateur légèrement distrait plutôt qu’à une intrusion.
En novembre 2025, Anthropic a révélé qu’un groupe parrainé par l’État chinois avait utilisé Claude Code pour conduire des chaînes d’attaque complètes, allant de la reconnaissance à l’exfiltration, sur une trentaine d’organisations, avant que la compagnie ne détecte l’opération. Ce n’était pas un test de concept. C’était en production, contre de vraies cibles.
La mort du cycle de patching tel que nous le connaissions
Il y a une vérité inconfortable que personne dans l’industrie ne veut vraiment dire à voix haute : le processus de gestion des correctifs, tel qu’il existe dans la grande majorité des organisations, est mort.
En 2018, la fenêtre entre la divulgation publique d’une vulnérabilité et son exploitation active était en moyenne de 771 jours. En 2026, elle est inférieure à 24 heures. Et deux tiers des vulnérabilités exploitées le sont sur le jour zéro, avant même qu’un correctif existe.
La conséquence pratique est radicale. Une banque, un hôpital, une infrastructure critique ne peut plus se permettre d’appliquer le modèle « vulnerability disclosed Monday, patch tested Friday, deployed next Tuesday. » Ce modèle suppose une fenêtre de réaction de plusieurs jours. Cette fenêtre n’existe plus.
Pire encore : dans un contexte Mythos, nous devons désormais partir du principe que toute vulnérabilité découverte disposera d’un exploit fonctionnel dans les heures qui suivent sa divulgation. Ce n’est plus une hypothèse de worst case. C’est le scénario par défaut.
Cela pose un problème structurel pour les organisations qui maintiennent des systèmes complexes. Tester un correctif avant de le déployer en production, c’est s’assurer qu’il ne casse pas d’autres fonctions critiques. Dans une banque, mettre à jour un composant touche des chaînes de dépendances entières. Dans un hôpital, un patch raté peut interrompre un système de monitoring. Ce travail de validation ne se fait pas en deux heures. Il ne se fera jamais en deux heures.
La réponse ne peut pas être « patche plus vite ». La réponse doit être une refonte complète de l’architecture de résilience : segmentation agressive, isolation des systèmes critiques, détection comportementale qui ne repose pas sur des signatures connues, et capacité de confinement automatisé avant même qu’un humain ait été alerté.
Les systèmes en fin de vie sont désormais des bombes à retardement
Si le délai d’exploitation s’est effondré à quelques heures, la question des systèmes end-of-life prend une dimension nouvelle et alarmante. Jusqu’ici, un système non maintenu était risqué parce que ses vulnérabilités s’accumulaient sans correctif. Aujourd’hui, il est critique parce que ces mêmes vulnérabilités sont désormais exploitables à l’échelle, sans expertise particulière, par quiconque dispose d’accès à un LLM offensif.
Windows 10, des versions abandonnées d’Android, des automates industriels SCADA qui n’ont pas été mis à jour depuis dix ans, des équipements médicaux tournant sur des OS obsolètes, des applications métiers développées en interne dont le développeur a quitté l’entreprise il y a trois ans : tous ces systèmes représentent une surface d’attaque qui était théoriquement exploitable, mais dont l’exploitation exigeait des compétences rares. Ce n’est plus le cas.
La démocratisation des capacités offensives par les LLM signifie que les attaquants qui n’auraient jamais pu développer un exploit sur un système obscur peuvent désormais le faire. La rareté des compétences était un garde-fou imparfait mais réel. Ce garde-fou disparaît.
Le futur du développement logiciel : LLM comme condition nécessaire à la mise en production
Il y a une ironie profonde dans ce que Mythos a déclenché. Anthropic a créé un outil suffisamment puissant pour trouver des milliers de vulnérabilités critiques en quelques semaines. Ce faisant, Anthropic a aussi fait la démonstration qu’un tel outil est indispensable pour auditer du code avant qu’il ne soit déployé. Le créateur du problème est aussi le créateur de la solution.
La direction que prend l’industrie est claire : toute organisation qui écrit du code, qu’il s’agisse d’un éditeur logiciel, d’une banque développant ses propres outils, d’un hôpital maintenant son système de gestion des dossiers patients, devra intégrer une revue de sécurité assistée par LLM comme condition non négociable avant toute mise en production. C’est ce que nous appelons « VulnOps » : une fonction permanente d’opérations de vulnérabilité, automatisée comme DevOps, capable de scanner en continu l’ensemble du patrimoine logiciel.
Mais cette réponse, aussi nécessaire soit-elle, ne règle pas le problème le plus complexe : celui de tout ce qui existe déjà.
La dette technique devient une dette de sécurité existentielle
Toutes les organisations qui utilisent des logiciels — c’est-à-dire toutes les organisations — sont assises sur un stock de code qui n’a jamais été audité avec des outils de niveau Mythos. Certains de ces logiciels sont des produits commerciaux dont l’éditeur maintiendra des correctifs. D’autres sont des solutions open source communautaires. D’autres encore sont des applications développées en interne, parfois par des équipes qui ont depuis été restructurées, parfois par des prestataires dont le contrat s’est terminé il y a cinq ans.
Que fait-on avec une application de gestion RH développée en 2017 par un développeur parti en 2021, dont personne dans l’entreprise ne maîtrise plus le code source, et qui tourne sur un serveur dans un coin du datacenter ? La réponse honnête est : personne ne sait. Et c’est exactement le type de cible qu’un attaquant armé d’un LLM va chercher en premier.
Les systèmes sans maintenance active ne recevront pas de patches Glasswing. Les solutions propriétaires dont l’éditeur a disparu ne seront pas couvertes par les programmes de divulgation coordonnée. Les frameworks vieillissants qui sous-tendent des applications critiques continueront d’accumuler des failles que personne ne sait plus corriger.
La réponse à ce problème n’est pas technique au premier chef. Elle est stratégique et organisationnelle. Les entreprises doivent traiter leur inventaire applicatif comme ce qu’il est : un registre de risques. Chaque application non maintenue est une exposition. Chaque composant end-of-life est une surface d’attaque. L’isolation, la segmentation et le déclassement de ces systèmes ne sont pas des projets IT. Ce sont des priorités de survie.
Ce que les organisations doivent faire maintenant
La première urgence est de réévaluer les modèles de risque. Beaucoup d’organisations utilisent encore des métriques basées sur des fenêtres d’exploitation qui n’existent plus. Une banque qui estime son risque résiduel sur la base d’un délai d’exploitation de plusieurs semaines est en train de faire des rapports au conseil d’administration qui ne correspondent plus à la réalité.
La deuxième urgence est d’abandonner la dépendance exclusive au patching réactif et d’investir dans la détection comportementale. Un système qui ne dépend pas de signatures connues pour détecter une intrusion est le seul qui puisse fonctionner lorsque l’exploit utilisé contre vous a été généré il y a quatre heures et que personne au monde ne le connaît encore.
La troisième urgence est d’établir un inventaire réel des applications, en commençant par les systèmes exposés sur internet et en progressant vers l’ensemble du patrimoine. Les agents IA rendent ce travail significativement plus rapide. Sans inventaire, il est impossible de savoir ce qu’on défend.
Enfin, la question de la gouvernance des outils IA internes doit être traitée comme une priorité de sécurité. Chaque organisation qui déploie des agents IA dans son infrastructure élargit sa surface d’attaque. Les agents sont des systèmes privilégiés, non couverts par les contrôles de sécurité existants, et leur sécurisation ne peut pas être une réflexion après-coup.
La question qui compte vraiment
Lors de son interview sur la RTS, le présentateur a demandé à Steven Meyer si nous devions avoir peur. Sa réponse : la bonne question n’est pas « sommes-nous en danger ? », mais « qui aura accès à ces capacités en premier : les défenseurs ou les attaquants ? »
Il y a une lecture optimiste de Mythos que certains experts défendent avec conviction, et qui mérite d’être prise au sérieux. Pendant trente ans, nous avons accumulé de la dette de sécurité parce que nous n’avions pas les outils pour auditer l’ensemble de notre code. Pour la première fois, nous pouvons imaginer un monde où les failles ne s’accumulent plus indéfiniment, où la vérification formelle devient accessible à grande échelle, où les logiciels peuvent être produits avec un niveau de sécurité structurellement supérieur à ce qui était possible jusqu’ici. Ce n’est pas une consolation, c’est une réalité technique que l’industrie doit saisir.
Mais cette opportunité n’est pas automatique. Elle dépend de qui agit en premier, de qui investit maintenant, de qui accepte que les règles du jeu ont changé. Les organisations qui attendent que leurs fournisseurs leur envoient des mises à jour, qui maintiennent des systèmes end-of-life parce que le remplacement est complexe, qui n’ont pas d’inventaire applicatif à jour, qui dépendent d’un modèle de patching conçu pour une menace d’une autre époque : elles ne sont pas seulement exposées. Elles avancent à découvert dans un environnement qui a fondamentalement changé.
Retrouvez l’interview complète de Steven Meyer sur Le Forum de la RTS.
