Quand l'IA redéfinit la cybersécurité : comment Mythos a changé nos priorités en production.

Stéphane RobinLinkedIn

Senior Engineer chez Abbeal, Pôle Amériques · Montréal. Spécialisé services financiers réglementés, modernisation legacy, sécurité Java/Spring Boot.

La dette technique n’a jamais été un sujet anodin. Mais avec l’arrivée de Mythos, elle est devenue une urgence.

Il y a quelques semaines, l’annonce du modèle Claude Mythos Preview d’Anthropic a provoqué une onde de choc dans les équipes de sécurité des grandes organisations. Pas uniquement parce que le modèle est techniquement impressionnant — mais parce qu’il a fondamentalement changé le calcul du risque CVE.

Sur le terrain, chez un de nos clients dans le secteur financier, acteur majeur de la place de Montréal, nous avons vécu ce basculement en temps réel. Voici ce que nous avons appris.

Le Défi : quand des vulnérabilités “mineures” deviennent critiques.

Qu’est-ce que Mythos, concrètement ?

Claude Mythos est un modèle de grande envergure développé par Anthropic, capable d’identifier et d’exploiter des vulnérabilités de sécurité de manière autonome, à une échelle et une vitesse inédites. Parmi ses capacités documentées :

Découverte autonome de zero-days : le modèle a identifié des failles dormantes depuis des décennies — dont un bug vieux de 27 ans dans OpenBSD et une vulnérabilité de 16 ans dans FFmpeg.

Génération d’exploits fonctionnels : sans intervention humaine significative, Mythos transforme une CVE en vecteur d’attaque opérationnel.

Démocratisation de l’attaque : un ingénieur sans formation en sécurité peut, avec Mythos, identifier et exploiter des failles critiques dans des systèmes complexes.

Anthropic a restreint l’accès au modèle via le “Projet Glasswing”, le réservant à un consortium d’organisations d’ infrastructure critique pour permettre des correctifs préventifs. Mais la réalité du terrain est sans appel : la menace existe, elle est documentée, et les équipes sécurité des grandes organisations en ont pleinement conscience.

Ce que ça change pour les équipes sécurité

Avant Mythos, le classement des CVE reposait sur une évaluation du risque d’exploitation : une vulnérabilité cotée CVSS 5.0, difficile à exploiter manuellement, pouvait raisonnablement rester dans le backlog plusieurs mois.

Avec Mythos, ce raisonnement s’effondre.

Un modèle capable d’automatiser la découverte et l’exploitation à grande échelle transforme toute CVE en priorité potentielle — y compris celles qui dormaient dans la dette technique depuis des années, jugées trop complexes à exploiter pour mériter une action immédiate.

La réponse sur le terrain : ce qui se passe chez notre client

Un réalignement total des priorités

L’équipe sécurité de notre client a déclenché une revue systématique de l’ensemble des API et composants exposés. L’objectif : identifier toutes les CVE ouvertes liées à des composants en dette technique et les requalifier à l’aune du risque Mythos. Le résultat a été immédiat : des vulnérabilités classées “faibles” ou “à traiter dans le prochain cycle” sont remontées en tête de backlog. Les équipes de développement ont reçu des demandes de correctifs avec une contrainte claire — deux semaines pour passer en production.

Les chantiers en cours

Les principales actions engagées :

Migration Spring Boot 2.x → 3.x (voire 4.x) : un passage non trivial, qui implique des adaptations d’API, de configuration de sécurité et de compatibilité des dépendances.

Montées de version ciblées : chaque bibliothèque associée à une CVE active fait l’objet d’une mise à jour vers la version “safe” la plus récente compatible. Migration Java 17 → 21 (minimum) : les applications encore bloquées sur Java 17 sont concernées en priorité. Java 25, bien que disponible, pose encore des problèmes de compatibilité sur certains composants dont le cycle de release est plus lent — sa généralisation est reportée.

Un shift de planning inévitable

Ces chantiers ne s’ajoutent pas au planning existant — ils le déplacent. Un décalage d’au moins deux semaines est attendu sur les livrables fonctionnels prévus. C’est un coût réel, assumé, et surtout justifié.

Ce que cette situation révèle sur la gestion de la dette technique

La dette contenue n’est plus suffisante

Notre client avait une dette technique gérée, documentée, et globalement maîtrisée. Elle n’était pas ignorée — elle était priorisée dans un contexte de risque raisonnable. Mythos a redéfini ce contexte.

Ce cas illustre une réalité plus large : la gestion de la dette technique ne peut plus être évaluée indépendamment de l’évolution du paysage des menaces. Une CVE que vous avez accepté de reporter hier peut devenir votre plus grande exposition demain, si les outils d’exploitation évoluent.

Les organisations moins rigoureuses sont en bien plus mauvaise posture

Ce que nous observons chez notre client — une organisation qui avait déjà une culture de la qualité logicielle — donne une idée de ce que traversent des structures moins attentives à leur hygiène technique. La combinaison de dette non documentée, de versions obsolètes et de CVE jamais traitées représente, dans ce nouveau contexte, un risque systémique.

Pourquoi ce sujet nous importe chez Abbeal ?

Chez Abbeal, nous intervenons précisément sur ces enjeux : architecture logicielle, qualité de code, modernisation de stack et accompagnement des équipes dans la gestion de leur dette technique.

Ce que cette expérience nous confirme : La dette technique est un risque métier, pas seulement un risque technique. Elle se mesure en fenêtres d’exposition, pas uniquement en vélocité de développement.

Les équipes qui traitent sérieusement leur stack sont mieux équipées pour répondre à ce type de crise. Deux semaines de sprint sécurité, c’est gérable quand les fondations sont saines.

L’expertise en modernisation de stack est plus stratégique que jamais. Spring Boot 3.x, Java 21, mise à jour de dépendances — ce ne sont pas des chantiers “nice to have”. Ce sont des prérequis à la résilience.

Si vous travaillez sur ces sujets — en tant que client à la recherche d’un partenaire technique, ou en tant qu’ingénieur cherchant à rejoindre une équipe qui traite ces enjeux sérieusement — nous serions heureux d’en discuter.

Prochaines étapes

Quelques actions concrètes si vous voulez anticiper ce type de situation dans votre organisation :

1. Auditez votre CVE backlog à l’aune du risque d’exploitation par IA, pas seulement par humain.
2. Cartographiez vos composants en dette : versions de Spring Boot, Java, bibliothèques critiques.
3. Mettez en place un pipeline de montée de version continue pour éviter les accumulations qui créent des fenêtres d’exposition larges.
4. Challengez vos SLA de correctifs : deux semaines de délai de mise en prod pour un patch de sécurité, c’est désormais le standard minimum dans les organisations matures.

Cet article est basé sur un retour d’expérience terrain. Les détails sensibles ont été généralisés pour respecter la confidentialité de notre client.

Abbeal accompagne les équipes de développement dans la modernisation de leur stack, la réduction de la dette technique et la mise en place de pratiques d’ingénierie durables.