Mythos ne change rien. Et c'est exactement le problème.

Depuis deux semaines, la communauté cybersécurité débat de Mythos, le modèle d'Anthropic capable de trouver et d'exploiter des vulnérabilités logicielles de manière autonome. Des milliers de failles zero-day découvertes dans des systèmes d'exploitation et des navigateurs que des armées de développeurs n'avaient pas repérées. Le débat est prévisible : est-ce que ça favorise l'attaque ou la défense ? Est-ce du hype ou une vraie rupture ? Est-ce qu'on peut faire confiance à cinquante entreprises pour garder des exploits fonctionnels dans un coffre ?

Ces questions sont légitimes. Elles passent aussi à côté de l'essentiel.

Le syndrome du pas incrémental

Mythos est un pas incrémental dans une longue série de pas incrémentaux. Le problème, c'est qu'on a passé cinq ans à traiter chaque pas comme un événement isolé, sans jamais regarder le déplacement cumulé. On découvre les vulnérabilités automatiquement aujourd'hui. On les exploite automatiquement aujourd'hui. On s'en étonne, et dans six mois on aura oublié qu'on s'en étonnait, parce que le modèle suivant fera la même chose en mieux et que la ligne de base aura encore bougé.

Regardez la trajectoire plutôt que l'événement. En novembre 2024, l'agent Big Sleep de Google annonçait avoir découvert une faille de corruption mémoire exploitable dans SQLite, présentée comme le premier cas public d'une vulnérabilité inédite trouvée par une IA dans un logiciel réel largement déployé. Un an plus tard, en novembre 2025, Anthropic documentait une campagne d'espionnage attribuée à un groupe étatique où l'IA avait exécuté 80 à 90 % des opérations contre une trentaine d'organisations, l'humain n'intervenant qu'à quatre à six moments de décision, et où le système lançait, au pic, des milliers de requêtes par seconde. Entre les deux, personne n'a vraiment sonné l'alarme : chaque étape était « incrémentale ».

Ce glissement permanent empêche toute réaction proportionnée. Si chaque avancée est « incrémentale », alors aucune ne justifie une réponse structurelle. On reste dans le registre du commentaire, de l'analyse, du « wait and see ». Et pendant ce temps, les capacités offensives se démocratisent à un rythme qui rend les architectures de défense existantes progressivement obsolètes.

L'IA trouve-t-elle vraiment toutes les vulnérabilités ?

Soyons précis sur ce que Mythos fait réellement. Le modèle excelle à trouver des variations de vulnérabilités dans des classes bien documentées. Les « known knowns ». Des patterns que les outils de fuzzing et d'analyse statique cherchaient déjà, mais avec une couverture et une vitesse supérieures. C'est impressionnant. C'est aussi la partie facile du problème.

Les « unknown unknowns », les attaques de type Black Swan qu'on ne peut découvrir que par raisonnement parce qu'il n'existe aucun pattern dans les données d'entraînement, restent hors de portée. L'IA ne raisonne pas sur ce qu'elle n'a jamais vu. Elle extrapole à partir de ce qu'elle connaît. Ce qui signifie que les vulnérabilités les plus dangereuses, celles qui redéfinissent les catégories au lieu d'en explorer les variantes, resteront le domaine de l'intelligence humaine, offensive comme défensive.

Mais voici le vrai problème : même si l'IA ne trouve « que » les bugs simples, l'attaquant n'a besoin que d'un seul succès. Le défenseur doit tous les trouver. Si l'IA offensive détecte un bug aléatoire avec 1 % d'efficacité, l'attaquant gagne systématiquement sur un portefeuille suffisamment large de cibles. L'asymétrie fondamentale entre attaque et défense n'est pas résolue par l'IA. Elle est mécaniquement amplifiée. La campagne documentée par Anthropic en donne la mesure : une seule opération automatisée, des milliers de requêtes par seconde, une trentaine de cibles balayées en parallèle. L'attaquant industrialise ; le défenseur, lui, doit toujours tenir chaque porte.

Pourquoi le logiciel n'est-il toujours pas un produit ?

La question que l'industrie refuse de poser est pourtant évidente : si l'IA est capable de trouver des milliers de vulnérabilités critiques dans du code déployé en production depuis vingt ans, pourquoi n'impose-t-on pas son utilisation avant toute mise sur le marché ?

Comparez avec n'importe quel autre domaine d'ingénierie. Un ingénieur en sûreté aéronautique met sa carrière en jeu à chaque certification. Un concepteur de dispositif médical engage sa responsabilité pénale. Un ingénieur en sécurité industrielle signe des documents qui l'engagent personnellement sur la conformité de ses designs. Les exigences de formation, de certification et de responsabilité légale sont massives. Les salaires, paradoxalement, sont souvent inférieurs à ceux de l'industrie logicielle.

De l'autre côté, un développeur logiciel déploie en production le vendredi soir. Le management optimise les lignes de code par jour par personne, sans considération pour la qualité ou la sécurité. Le marché récompense la vitesse. Les conditions contractuelles déchargent le fournisseur de toute responsabilité substantielle. Le logiciel, juridiquement, n'était pas un produit. On ne peut pas le tenir dans la main, donc les lois de protection du consommateur ne s'appliquaient pas, ou s'appliquaient mal.

Cela change, lentement. Le Cyber Resilience Act européen, entré en vigueur le 10 décembre 2024, impose enfin des obligations de sécurité tout au long du cycle de vie des produits comportant des éléments numériques : signalement des vulnérabilités activement exploitées à partir du 11 septembre 2026, gros du dispositif applicable au 11 décembre 2027. En parallèle, la nouvelle directive européenne sur la responsabilité du fait des produits, adoptée fin 2024, range désormais explicitement le logiciel, systèmes d'IA compris, parmi les « produits » : ce qu'on ne pouvait pas tenir dans la main devient un objet de responsabilité au même titre qu'un grille-pain. Mais la résistance culturelle est colossale. L'industrie logicielle s'est construite sur un modèle économique où la qualité est externalisée vers l'utilisateur final. Vous déployez, vous patcherez plus tard. Vous trouvez un bug, c'est une « fonctionnalité ». Et quand l'IA trouve des milliers de failles dans votre code, le réflexe n'est pas de se demander pourquoi elles étaient là. C'est de débattre de savoir si l'IA qui les a trouvées est une menace ou une opportunité.

Que faire des systèmes qu'on ne peut pas patcher ?

Il y a dans le débat actuel une distinction qui mérite qu'on s'y arrête : la différence entre les systèmes qu'on peut patcher et ceux qu'on ne peut pas.

Vos navigateurs, vos téléphones, vos services cloud majeurs : patchables, vérifiables, déployables rapidement. Pour ces systèmes, l'IA défensive finira probablement par produire un bénéfice net. On trouvera plus vite, on patchera plus vite, le cycle se raccourcira. C'est d'ailleurs le versant lumineux d'un outil comme Big Sleep : une faille corrigée avant même qu'un attaquant ait eu la chance de la voir.

Mais il y a tout le reste. Les voitures connectées. Les transformateurs électriques. Les systèmes de contrôle industriel. Les équipements IoT qui n'ont jamais été conçus pour recevoir une mise à jour. Les systèmes bancaires hérités qui tournent depuis trente ans sur du code que plus personne ne comprend entièrement. Ces systèmes ne disparaîtront pas. Ils ne seront pas remplacés dans les six à dix-huit mois pendant lesquels les capacités de type Mythos se démocratisent. Et les protéger exige autre chose que de l'IA : de la segmentation réseau, du cloisonnement, du moindre privilège. Des principes qui ont vingt ans et qu'on a passé la dernière décennie à négliger au profit de l'agilité et de l'interconnexion.

Ce n'est pas l'IA qui rend ces principes obsolètes. C'est l'IA qui rend leur absence inexcusable.

Cinquante entreprises et un exploit

Anthropic ne rend pas Mythos public. Le modèle est partagé avec cinquante entreprises. Cinquante organisations, des milliers d'employés, avec accès à un système capable de produire des exploits fonctionnels contre des logiciels que tout le monde utilise.

La question de gestion des risques est limpide : combien de temps avant qu'un exploit produit dans ce cadre se retrouve entre des mains non autorisées ? Ce n'est pas du cynisme. C'est de l'arithmétique. Cinquante entreprises, des chaînes de sous-traitance, des prestataires, des stagiaires, des employés mécontents, des comptes compromis. Le périmètre de confiance est immense. Et l'histoire de la sécurité informatique nous enseigne une chose avec une régularité déprimante : ce qui peut fuiter finit par fuiter.

Ce que Mythos révèle vraiment

Mythos ne crée pas un nouveau problème. Il rend un problème ancien impossible à ignorer. Nous produisons du logiciel avec les standards de qualité d'une industrie artisanale et nous le déployons dans des infrastructures critiques. Nous connectons à Internet des systèmes qui n'ont jamais été conçus pour y être exposés. Nous refusons d'appliquer à l'ingénierie logicielle les exigences que nous imposons à toute autre discipline d'ingénierie. Et quand une IA trouve des milliers de preuves que cette approche est défaillante, nous débattons de l'IA au lieu de débattre de l'approche.

La vraie question n'est pas de savoir si Mythos favorise l'attaque ou la défense. C'est de savoir pourquoi, en 2026, il faut un modèle d'IA à 20 000 dollars pour découvrir des failles qui auraient dû être trouvées par des pratiques d'ingénierie élémentaires il y a vingt ans.

Sources

• Campagne de cyberespionnage menée à 80-90 % par une IA, novembre 2025 : Anthropic.
• Première faille mémoire inédite trouvée par une IA dans un logiciel réel (SQLite), novembre 2024 : Google Project Zero.
• Calendrier et obligations du Cyber Resilience Act : Commission européenne.
• Le logiciel reconnu comme « produit » : directive (UE) 2024/2853 sur la responsabilité du fait des produits, EUR-Lex.
• Mythos et son cadre de diffusion : Anthropic, Glasswing.