Quand un gouvernement retire un modèle d’IA : ce que la suspension de Fable 5 et Mythos 5 signifie pour les équipes de sécurité

Le soir du 12 juin 2026, Anthropic a désactivé l’accès à deux de ses tout derniers modèles, Claude Fable 5 et Claude Mythos 5, pour l’ensemble de ses clients dans le monde. L’entreprise ne l’a pas fait à cause d’une panne ou d’une faille qu’elle aurait découverte elle-même. Elle l’a fait pour se conformer à une directive américaine sur le contrôle des exportations, reçue ce jour-là à 17 h 21, heure de l’Est, et invoquant des pouvoirs liés à la sécurité nationale.

Pour les professionnels de la sécurité, les détails comptent davantage que les considérations politiques : quel était réellement le déclencheur signalé, comment la mesure s’est-elle déroulée et que révèle-t-elle sur le fait de dépendre du modèle d’un tiers ? Les équipes de sécurité peuvent agir sur ces questions, quelle que soit leur position dans le débat politique.

Ce qui s’est réellement passé avec Fable 5 et Mythos 5 d’Anthropic

Il est utile d’être précis, car la version simplifiée qui circule en ligne (« le gouvernement a interdit le modèle à tout le monde ») ne correspond pas tout à fait aux faits.

Selon la déclaration d’Anthropic, la directive ordonnait à l’entreprise « de suspendre tout accès à Fable 5 et Mythos 5 pour tout ressortissant étranger, qu’il se trouve aux États-Unis ou ailleurs, y compris les employés d’Anthropic de nationalité étrangère ». À première vue, la restriction visait l’accès des ressortissants étrangers, et non celui de tous les utilisateurs.

La désactivation mondiale en a été la conséquence pratique. Comme l’a expliqué Anthropic, « en définitive, cette ordonnance nous oblige à désactiver brusquement Fable 5 et Mythos 5 pour l’ensemble de nos clients afin d’assurer notre conformité ». Il n’existe aucun moyen fiable de distinguer en temps réel les ressortissants étrangers des personnes américaines au sein d’une base de plusieurs centaines de millions d’utilisateurs, en particulier avec un préavis le jour même. L’entreprise a donc désactivé les modèles pour tout le monde. Cette distinction est importante : l’ordonnance visait l’accès des ressortissants étrangers, mais, dans les faits, la seule façon de la faire respecter dans un délai aussi court était une désactivation générale.

La raison avancée était un « jailbreak d’IA » présumé. Voici comment Anthropic a décrit les éléments qui lui ont été communiqués : « le gouvernement ne nous a fourni que des éléments verbaux évoquant un éventuel jailbreak limité et non universel, qui consiste essentiellement à demander au modèle de lire une base de code précise et d’en corriger les failles logicielles ». L’entreprise a ajouté que « le niveau de capacité démontré est largement accessible dans d’autres modèles (notamment GPT-5.5 d’OpenAI) et utilisé chaque jour par les équipes qui protègent les systèmes ».

Le gouvernement n’a pas publié la directive et la lettre ne précisait aucun fondement technique particulier. Les informations publiques reposent donc en grande partie sur le récit d’Anthropic. Les capacités cybernétiques des modèles de pointe constituent légitimement un enjeu de sécurité nationale, et selon les informations publiées, la directive aurait été motivée par l’allégation de jailbreak d’un tiers. Ce que l’on peut examiner ici, c’est la nature de la mesure et sa comparaison avec les pratiques établies en matière de sécurité, plutôt que les détails classifiés qui la sous-tendent.

Le déclencheur présumé : analyse et correction de code

Demander à un modèle de lire une base de code et d’en corriger les failles n’a rien d’une attaque exotique. C’est de la revue de code automatisée et de la correction des vulnérabilités, le même travail qu’effectuent l’analyse statique, les fuzzers, la revue de code assistée par l’IA et tout ingénieur en sécurité qui lance une analyse avant une mise en production. C’est une capacité utilisée régulièrement par les défenseurs et, comme la plupart des capacités de sécurité, elle est par nature à double usage.

La communauté technique l’a rapidement souligné. Sur Hacker News, un commentateur l’a formulé ainsi : « Si j’ai bien compris, le “jailbreak” consiste à demander au modèle de corriger la base de code, qui révèle alors ses failles ? Il semble presque impossible de corriger ce problème tout en conservant de hautes capacités. On veut justement qu’il puisse corriger votre base de code. » Aucun modèle de génération de code performant ne peut corriger des vulnérabilités sans être aussi capable de les décrire.

Dans les jours qui ont précédé la suspension, certains chercheurs en sécurité formulaient le reproche inverse : les garde-fous de Fable 5 étaient trop stricts pour les travaux légitimes de défense. Valentina Palmiotti, d’IBM X-Force, a déclaré à TechCrunch que le modèle « rejette toute demande qui pourrait avoir un lien même indirect avec la cybersécurité ». Au cours de la même semaine, le modèle a été critiqué pour être trop restrictif envers les défenseurs, puis retiré pour une capacité utilisée à des fins de défense.

Les capacités sont à double usage, une propriété bien connue dans le domaine de la sécurité. Un scanner de ports, un analyseur de paquets, un fuzzer, un moteur SAST, un débogueur et une preuve de concept d’exploitation d’une corruption mémoire sont autant d’outils « offensifs » ou « défensifs », selon qui les utilise et dans quel but. Nous n’interdisons pas nmap et ne classons pas Wireshark comme une arme. Le secteur de la sécurité a généralement conclu qu’on ne peut pas améliorer la défense en interdisant les outils dont elle a besoin.

Comment le secteur de la sécurité gère les risques liés au double usage

Le problème de fond est ancien : une capacité puissante existe et peut être détournée. Le secteur de la sécurité a consacré des décennies à élaborer une réponse, qui constitue un contexte utile, quel que soit le jugement porté sur cette mesure particulière. Cette réponse s’appuie sur quelques disciplines.

Divulgation coordonnée. Lorsqu’une personne découvre une faille grave, la pratique établie consiste à la signaler en privé à la partie en mesure de la corriger, à convenir d’un calendrier, puis à la rendre publique une fois le correctif disponible. L’objectif de la divulgation responsable est de limiter les dommages tout en faisant progresser l’écosystème. Selon Anthropic, l’entreprise n’a reçu que des éléments verbaux évoquant un éventuel jailbreak et n’a pas obtenu de description écrite de la découverte. Le gouvernement n’a pas rendu public son propre processus.

Défense en profondeur. Aucun contrôle n’est censé être parfait : on superpose donc plusieurs contrôles en partant du principe que certains échoueront. Anthropic affirme avoir construit Fable 5 selon ce principe et l’avoir expliqué dès son lancement : « nous pensons qu’aucun fournisseur de modèles ne peut actuellement garantir une résistance parfaite aux jailbreaks ». La stratégie consistait donc à rendre les jailbreaks « soit limités […] soit très coûteux à produire » et à « associer cela à une surveillance approfondie afin de détecter rapidement toute attaque réussie et d’y mettre fin ». C’est la même logique que celle de la sécurité applicative à plusieurs niveaux : analyses dans l’IDE, vérifications dans la pull request, contrôles dans la CI et surveillance en production. On ne s’attend pas à ce que rien ne passe jamais. On s’attend à ce que les différentes couches détectent et contiennent ce qui réussit à passer.

Priorisation fondée sur le risque. Les programmes de sécurité matures ne traitent pas chaque constat comme une urgence absolue : c’est impossible et contre-productif. Lorsqu’une CVE critique est publiée pour un paquet npm populaire, l’écosystème ne met pas tout npm hors ligne. Il évalue la possibilité d’exploitation et l’accessibilité, donne la priorité aux cas réellement importants, applique des correctifs et vérifie leur efficacité. Toute l’approche de Snyk en matière de sécurisation du code généré par l’IA et de sécurité applicative repose sur cette idée : la gravité est nécessaire, mais ne suffit pas. La question utile est toujours : « Parmi ces risques, lesquels sont réels et exploitables, et lesquels faut-il traiter en priorité ? » Les équipes de sécurité sont rarement confrontées à un choix binaire entre tout activer ou tout désactiver. En pratique, il s’agit de trouver une réponse graduée adaptée au risque réel.

Il est difficile d’évaluer comment cette mesure s’inscrit dans ces pratiques à partir des informations publiques, puisque le gouvernement n’a pas décrit son processus. Ces pratiques offrent toutefois un cadre de référence commun pour le débat qui a suivi.

Des réactions divisées à la suspension de Fable 5

Les réactions du public se sont rapidement divisées. Selon un premier argument, Anthropic avait publiquement défendu le pouvoir des gouvernements de réglementer le déploiement de l’IA et s’y opposait désormais lorsqu’un gouvernement l’exerçait. Dans sa déclaration, Anthropic a reconnu que les gouvernements devraient pouvoir bloquer les déploiements dangereux, mais uniquement « dans le cadre d’un processus légal transparent, équitable, clair et fondé sur des faits techniques », et a affirmé que « cette mesure ne respecte pas ces principes ». Le gouvernement a invoqué la sécurité nationale, un enjeu reconnu concernant les capacités cybernétiques des modèles de pointe, et selon les informations publiées, la directive faisait suite à l’allégation de jailbreak d’un tiers. Les éléments précis n’ont pas été rendus publics.

D’autres réactions ne concernaient ni l’une ni l’autre des parties. Les développeurs qui avaient créé des solutions reposant sur Fable 5 se sont concentrés sur la fiabilité, et beaucoup ont vu dans cet épisode un argument en faveur des modèles à poids ouverts ou auto-hébergés, qu’on ne peut pas désactiver à distance. Quelques-uns y ont vu, avec scepticisme, une opération de communication avant une introduction en bourse. Simon Willison a consigné le moment précis où l’accès a été coupé.

Il existe aussi un précédent. Dans les années 1990, les États-Unis considéraient le chiffrement fort comme une munition réglementée et en limitaient l’exportation. Les tribunaux américains ont finalement estimé que la publication de code de sécurité constituait une expression protégée. Ces contrôles limitaient les exportations ; ils n’imposaient pas la mise hors ligne d’un produit déjà déployé pour les utilisateurs du pays. C’est l’une des différences avec le cas présent.

L’enjeu de fiabilité que les équipes de sécurité ne peuvent ignorer

Laissons de côté les questions juridiques : une leçon opérationnelle demeure, quelle que soit l’issue du débat politique.

Une seule directive a mis hors ligne, en quelques heures, un produit généralement accessible pour l’ensemble de ses utilisateurs à l’échelle mondiale. Pour toute personne ayant intégré Fable 5 à un flux de travail, la disponibilité du modèle pouvait être révoquée par des facteurs échappant à son contrôle et à celui de son fournisseur. Les développeurs qui ont réagi en temps réel en ont tiré une conclusion évidente : la redondance des modèles est désormais une exigence de résilience, et non un simple critère de coût ou de performance. Faire d’un seul modèle hébergé une dépendance critique crée un point de défaillance unique. Or, les points de défaillance uniques posent un problème de sécurité, qu’ils cèdent à cause d’une panne, d’un problème de facturation, d’un changement de politique ou d’une lettre gouvernementale.

C’est la même rigueur que Snyk applique au reste de la chaîne d’approvisionnement logicielle. On ne peut pas gérer ce qu’on ne voit pas. C’est pourquoi connaître votre périmètre d’exposition à l’IA, inventorier les composants et dépendances d’IA réellement présents dans vos systèmes grâce à la découverte des actifs, et prévoir la défaillance de chacun d’entre eux deviennent des exigences de base. La suspension de Fable 5 en est une démonstration concrète.

Ensemble, c’est mieux : la place des outils de sécurité

Quelle que soit l’issue du débat politique, les équipes de sécurité doivent continuer à travailler. La question pratique est de savoir comment gérer au quotidien les capacités d’IA à double usage ; le secteur de la sécurité dispose de pratiques éprouvées. Chez Snyk, nous observons déjà ce phénomène au sein même des outils d’IA : dans le cadre de notre recherche ToxicSkills, nous avons audité près de 4 000 compétences d’agents IA et constaté que plus d’un tiers comportaient au moins une faille de sécurité, allant de l’injection de prompt à l’exposition de secrets, voire à des logiciels malveillants.

La divulgation coordonnée, les contrôles à plusieurs niveaux, la surveillance continue et la priorisation fondée sur le risque ne sont pas des concepts abstraits. Ce sont des pratiques quotidiennes qui permettent au monde de continuer à livrer des logiciels malgré la découverte constante de vulnérabilités. Elles s’appliquent directement à la création et à l’exploitation de solutions reposant sur l’IA :

• Sécurisez en continu le code produit par ces modèles. L’IA écrit davantage de code et plus vite, mais celui-ci n’est pas toujours sûr. Analyser le code généré par l’IA au moment de sa création et dans les pull requests, en appliquant des correctifs automatisés lorsque c’est possible, permet de concilier rapidité et sécurité au lieu de les opposer. C’est au cœur des recommandations de Snyk pour développer en toute sécurité avec l’IA et pour adopter des approches au niveau des types afin de sécuriser la génération de code par l’IA.

• Encadrez le comportement de l’IA par des garde-fous. L’unité de contrôle utile est généralement l’action, et non le modèle dans son ensemble. Les travaux de Snyk sur les garde-fous pour les assistants de codage IA et sur l’avenir de la sécurité des agents IA illustrent cette approche : limitez les actions possibles d’un agent, surveillez-le et intervenez de manière ciblée.

• Considérez les systèmes d’IA comme faisant partie de la surface d’attaque que vous gérez déjà. L’injection de prompt, la divulgation d’informations sensibles et les autres risques de l’OWASP Top 10 for LLMs sont des risques applicatifs auxquels les pratiques de sécurité des applications permettent de répondre. Les résultats de ToxicSkills évoqués plus haut relèvent exactement de cette catégorie : des risques réels, mesurables et gérables avec les outils et les processus dont les équipes de sécurité disposent déjà.

La sécurisation du code généré par l’IA est le point de départ de la plupart des équipes. Cette courte présentation de Snyk montre comment procéder concrètement :

Play Video: The Secret to Secure AI Code

Le secret pour sécuriser le code généré par l’IA (Comment sécuriser le code écrit par l’IA à mesure que son volume et sa vitesse augmentent)

Rien de tout cela ne vous oblige à choisir entre « l’IA est sûre » et « l’IA est dangereuse ». C’est la même approche que le secteur de la sécurité applique à toute technologie puissante : partir du principe qu’il existe des risques, mettre en place des mesures de protection à plusieurs niveaux pour les gérer, signaler les problèmes et les corriger de manière coordonnée, et donner aux équipes de sécurité les moyens d’agir.

Ce que les équipes de sécurité et les développeurs doivent retenir

1. Ne rendez aucun modèle hébergé indispensable à lui seul. Prévoyez plusieurs modèles et des solutions de repli sans interruption pour tout ce qui est important. Une disponibilité que vous ne maîtrisez pas est un risque à anticiper.

2. Répertoriez les endroits où l’IA intervient dans votre stack. Impossible d’évaluer l’ampleur d’un incident sans avoir recensé vos actifs. Identifiez les services, les pipelines et les produits qui dépendent de chaque modèle et composant d’IA.

3. Analysez systématiquement le code généré par l’IA, sans attendre qu’un problème survienne. Vu le volume et la vitesse de production du code écrit par l’IA, l’analyse dès sa création et lors des pull requests, associée à des mesures correctives automatisées, est le moyen le plus efficace de suivre le rythme.

4. Privilégiez les garde-fous et la surveillance plutôt que les boutons d’arrêt d’urgence. Limitez les actions, surveillez le comportement et intervenez de façon ciblée. Ne désactivez complètement un système que lorsque la situation le justifie réellement, et définissez à l’avance les critères correspondants.

5. Pratiquez la divulgation coordonnée et attendez la même chose des autres. Impossible de corriger une vulnérabilité que vous ne voyez pas. Exigez des preuves et un plan de correction, et appliquez les mêmes exigences aux autres.

Conclusion

La suspension de Fable 5 et Mythos 5 fera encore débat sur les plans juridique et politique, et chacun pourra légitimement se demander si les gouvernements devraient pouvoir mettre hors ligne un modèle déployé. Pour les équipes de sécurité, les enseignements durables ne dépendent pas de qui a raison. La capacité au cœur de la controverse est utilisée couramment par les équipes de sécurité. Et le résultat concret — la suppression en quelques heures d’une dépendance accessible dans le monde entier — plaide clairement en faveur de la redondance et de la visibilité.

Les capacités puissantes à double usage ne sont pas un problème nouveau, et le secteur de la sécurité sait déjà comment y faire face : prévoir suffisamment de modèles de secours pour qu’aucun fournisseur ne soit indispensable à lui seul, savoir où l’IA intervient dans votre stack, analyser le code généré par l’IA dès son intégration, encadrer les actions de l’IA par des garde-fous plutôt que de recourir aux boutons d’arrêt d’urgence, et pratiquer la divulgation coordonnée dans les deux sens. En appliquant ces principes en continu, les équipes peuvent poursuivre leurs livraisons malgré les risques liés au double usage. C’est là que les outils de sécurité, notamment ceux de Snyk, entrent en jeu. C’est la voie à suivre ensemble.