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é.

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 les bugs simples. Le problème est ailleurs.

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.

Le logiciel n'est toujours pas un produit. Et c'est ça, le scandale.

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'est pas un produit. On ne peut pas le tenir dans la main, donc les lois de protection du consommateur ne s'appliquent pas, ou s'appliquaient mal jusqu'à très récemment.

Le Cyber Resilience Act européen commence à changer cette donne. 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é.

Le patchable, l'impatchable, et tout ce qui est entre les deux

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.

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.