Introduction
Entre le 12 juin et le 30 juin 2026, deux modèles d’intelligence artificielle de premier plan ont cessé d’être accessibles à leurs clients dans le monde entier. La cause tient à une directive de contrôle des exportations émise par le gouvernement américain, invoquant des autorités de sécurité nationale.
Aucune panne, aucune cyberattaque, aucune défaillance d’infrastructure. Cet épisode transforme un risque théorique de dépendance technologique en scénario opérationnel documenté, et impose de traiter les fournisseurs de modèles d’IA comme des tiers critiques au sens d’ISO 22301, de NIS2 et de DORA.
Les faits établis
La chronologie repose sur les communications officielles d’Anthropic et sur la couverture de CNBC, Reuters et Forbes.
Date | Fait établi | Portée |
9 juin 2026 | Anthropic lance Claude Fable 5, premier modèle de la gamme Mythos rendu accessible au public, et Claude Mythos 5, réservé à des organisations partenaires (Project Glasswing). | Les capacités de frontière deviennent des technologies à double usage. |
12 juin 2026, 17h21 (heure de l’Est) | Anthropic reçoit une directive gouvernementale de contrôle des exportations, invoquant des autorités de sécurité nationale, imposant de suspendre tout accès aux deux modèles pour l’ensemble des ressortissants étrangers, à l’intérieur comme à l’extérieur des États-Unis, y compris les salariés étrangers d’Anthropic. | Portée extraterritoriale d’une décision nationale. |
12 juin 2026, soir | Faute de mécanisme permettant de vérifier la nationalité des utilisateurs en temps réel, Anthropic désactive les deux modèles pour l’intégralité de sa clientèle. Les autres modèles Claude restent disponibles. | Une obligation ciblée produit une indisponibilité mondiale par contrainte opérationnelle. |
Mi-juin 2026 | Le motif rapporté porte sur une méthode de contournement des garde-fous de Fable 5 relatifs à certaines tâches de cybersécurité, notamment l’identification de vulnérabilités logicielles. Anthropic conteste publiquement la gravité de cette évaluation. | La sécurité d’un modèle devient un objet de politique publique. |
26 juin 2026 | Autorisation gouvernementale permettant le rétablissement de Mythos 5 pour certaines organisations américaines. | L’accès devient différencié selon la juridiction et le profil du client. |
30 juin 2026 | Le Département du Commerce lève les contrôles à l’exportation visant les deux modèles. | La durée de la restriction relève d’une négociation extérieure au client. |
1er juillet 2026 | Fable 5 est redéployé mondialement sur les services propres d’Anthropic, puis progressivement sur les plateformes cloud partenaires. | La restauration s’effectue de manière échelonnée selon les canaux de distribution. |
Après redéploiement | Fable 5 revient assorti de garde-fous renforcés : certaines requêtes sont redirigées vers un modèle moins capable, Claude Opus 4.8. Anthropic indique que ce mécanisme se déclenche dans moins de 5 % des sessions et qu’il est volontairement calibré de façon conservatrice. | Le retour du service s’accompagne d’une modification du périmètre fonctionnel. |
Durée de l’indisponibilité : dix-huit jours.
Ce dernier point mérite une attention particulière. Le modèle rétabli diffère du modèle initialement livré. La restauration de la disponibilité s’est accompagnée d’une redéfinition unilatérale du comportement fonctionnel. Une organisation ayant construit un processus sur les capacités de la version du 9 juin a récupéré, le 1er juillet, un service dont le périmètre a évolué.
Ce que l'événement démontre
L’affaire Fable 5 constitue le premier cas documenté d’indisponibilité mondiale d’un modèle d’IA de frontière provoquée par une décision souveraine étrangère. Elle établit que la continuité d’un service d’IA dépend de facteurs juridiques et géopolitiques situés hors du système d’information du client, hors de son contrat, et hors de son plan de continuité tel qu’il est généralement rédigé aujourd’hui.
Ce constat appelle une conséquence méthodologique directe : le risque fournisseur appliqué aux modèles d’IA doit intégrer la décision réglementaire extraterritoriale au même titre que la panne, la cyberattaque et la défaillance humaine.
Ce que dit la recherche
Précaution méthodologique
L’événement date de juin 2026. Aucune littérature évaluée par les pairs ne lui est encore consacrée directement. L’analyse se construit donc à partir de quatre champs connexes, matures et citables : le verrouillage fournisseur dans le cloud, la souveraineté numérique et les dépendances stratégiques, la portabilité et l’interopérabilité, et les architectures multimodèles avec mécanismes de bascule.
Les prépublications figurant ci-dessous sont signalées comme telles. Leur usage dans un livrable client suppose une vérification préalable des résultats annoncés.
Tableau des publications de référence
Référence | Nature | Résumé de l’apport | Exploitation pour l’analyse |
Blancato, F. G. (2024), « The cloud sovereignty nexus: How the European Union seeks to reverse strategic dependencies in its digital ecosystem », Policy & Internet, 16(1), 12–32. DOI 10.1002/poi3.358 | Article évalué par les pairs | L’auteur analyse la manière dont l’Union européenne articule migration vers le cloud et réduction de sa dépendance envers les fournisseurs étrangers. L’étude démontre que les exigences réglementaires et les outils de politique industrielle regroupés sous le terme de souveraineté des données visent simultanément la protection de la confidentialité et la contestation de la position dominante des fournisseurs américains sur le marché européen. Deux études de cas structurent la démonstration : Gaia-X et l’Alliance européenne pour les données industrielles, l’edge et le cloud. | Référence académique centrale. Elle fonde l’idée que la souveraineté se mesure en capacité de réduction et de maîtrise d’une dépendance, plutôt qu’en autarcie technologique. |
Srivatsa, K. V. A., Maurya, K. K., Kochmar, E. (2024), « Harnessing the Power of Multiple Minds: Lessons Learned from LLM Routing », Proceedings of the Fifth Workshop on Insights from Negative Results in NLP, ACL, p. 124–134. aclanthology.org/2024.insights-1.15 | Communication évaluée, atelier ACL | Les auteurs testent la faisabilité d’un routage dirigeant chaque requête vers le LLM le plus adapté d’un ensemble, sur des tâches de raisonnement exigeantes. Le résultat est explicitement nuancé : le routage présente un potentiel, sans se révéler viable dans tous les scénarios. Le modèle de routage entraîné, malgré une borne théorique supérieure à celle de chaque modèle isolé, atteint en pratique le niveau du meilleur modèle unique. | Contribution majeure, précisément parce qu’elle est publiée dans un atelier consacré aux résultats négatifs. Elle interdit de présenter l’architecture multimodèle comme une garantie automatique de performance équivalente. |
Garg, S., Sagtani, A. (2026), « Unsolvability Ceiling in Multi-LLM Routing: An Empirical Study of Evaluation Artifacts », arXiv:2605.07395. arxiv.org/abs/2605.07395 | Prépublication, non évaluée par les pairs | Étude à grande échelle portant sur plus de 206 000 paires requête-modèle et six jeux d’évaluation. Les auteurs établissent qu’une part substantielle des échecs attribués aux limites intrinsèques des modèles provient en réalité d’artefacts d’évaluation : biais des juges automatiques en faveur de la verbosité, troncature liée aux budgets de génération, désalignement des formats de sortie. Les routeurs entraînés sur des étiquettes bruitées s’effondrent fréquemment vers la classe majoritaire, avec un coût d’opportunité de 13 à 17 points. | Argument opérationnel décisif : un modèle de secours doit être évalué sur des cas métier réels, avec un protocole d’évaluation contrôlé. Un benchmark générique fournit une indication trompeuse du niveau de service atteignable après bascule. |
« ContinuityBench: A Benchmark and Systems Study of Stateful Failover in Multi-Provider LLM Routing » (2026), prépublication arXiv (cs.LG) | Prépublication récente, non évaluée par les pairs | Le travail porte sur la bascule avec état entre fournisseurs de LLM. Il distingue le rétablissement d’une réponse et la préservation du contexte opérationnel, de l’historique et de l’état de session, et propose une architecture de transfert d’état. | Référence thématiquement centrale pour la distinction entre disponibilité et continuité fonctionnelle. Les résultats quantitatifs annoncés appellent une vérification directe auprès de la source avant toute citation dans un livrable client. |
Hu, Q. J. et al. (2024), « RouterBench: A Benchmark for Multi-LLM Routing System », arXiv:2403.12031. arxiv.org/abs/2403.12031 | Prépublication largement citée | Cadre d’évaluation systématique des systèmes de routage multi-LLM, adossé à un jeu de données de plus de 405 000 résultats d’inférence. Les auteurs formalisent un cadre théorique du routage et comparent les approches existantes en explicitant leurs limites. | Base méthodologique pour construire un protocole de test de bascule reproductible et documenté. |
Li, H. et al. (2026), « LLMRouterBench: A Massive Benchmark and Unified Framework for LLM Routing », arXiv:2601.07206. arxiv.org/abs/2601.07206 | Prépublication | Réévaluation systématique du domaine sur plus de 400 000 instances, 21 jeux de données et 33 modèles. La complémentarité entre modèles est confirmée. En revanche, de nombreuses méthodes de routage, y compris des routeurs commerciaux, atteignent des performances comparables entre elles et ne dépassent pas systématiquement une ligne de base simple. | Confirme que l’investissement dans une couche de routage sophistiquée produit un gain de résilience réel et un gain de performance à démontrer au cas par cas. |
Moravčík, M. et al. (2024), « Model-Driven Approach to Cloud-Portability Issue », Applied Sciences | Article évalué par les pairs | Analyse des obstacles à la portabilité des services cloud, en particulier ceux induits par les scripts, outils et langages propres à chaque fournisseur. | Transposition directe aux systèmes d’IA : prompts calibrés, appels d’outils, mémoire, évaluations et workflows d’agent constituent autant de points d’adhérence à une API particulière. |
Zhang, Z. et al. (2013), « A survey on cloud interoperability: taxonomies, standards, and practice », ACM SIGMETRICS Performance Evaluation Review | Revue évaluée par les pairs | Taxonomie des obstacles techniques à l’interopérabilité entre fournisseurs cloud. Interfaces, formats et services propriétaires élèvent le coût de migration et consolident le verrouillage. | Démontre que la faculté contractuelle de changer de fournisseur laisse entière la question de la réversibilité technique effective. |
Tahir, M. et al. (2020), « A Systematic Review on Cloud Storage Mechanisms Concerning e-Healthcare Systems » | Revue systématique | Les secteurs sensibles doivent évaluer conjointement disponibilité, confidentialité, sécurité, récupérabilité et dépendance aux infrastructures externalisées. | Étend l’analyse aux organisations intégrant des LLM dans des processus réglementés : santé, finance, opérateurs essentiels. |
Cinq enseignements consolidés
- Le verrouillage dépasse la dimension contractuelle. Une clause de résiliation coexiste sans difficulté avec une incapacité opérationnelle à migrer. Dans le cas d’un LLM intégré, l’adhérence porte sur les formats d’API, les prompts calibrés sur le comportement d’un modèle donné, les connecteurs et appels d’outils, les systèmes de mémoire, les embeddings et bases vectorielles, les mécanismes de sécurité, les seuils d’évaluation métier et les agents construits autour du modèle.
- La disponibilité et la continuité constituent deux niveaux distincts.
Niveau | Objet de la vérification |
Disponibilité | Le service répond. |
Continuité fonctionnelle | Le processus métier se poursuit. |
Continuité sémantique | Le modèle de secours traite la tâche avec une qualité équivalente. |
Continuité de conformité | Les exigences de sécurité, de confidentialité et de traçabilité demeurent satisfaites. |
Le redéploiement de Fable 5 illustre cette gradation avec une netteté rare : le service est revenu, avec un comportement modifié.
- L’architecture multimodèle déplace le risque autant qu’elle le réduit. Elle supprime un point unique de défaillance et introduit des exigences nouvelles : tests de compatibilité, normalisation des interfaces, gestion centralisée du contexte, scénarios de bascule préétablis, évaluation du risque propre au second fournisseur, maîtrise des écarts de performance et de comportement. La littérature sur le routage, notamment Srivatsa et al. et Garg et Sagtani, confirme que le gain se démontre et ne se présume pas.
- La souveraineté pertinente est une souveraineté opérationnelle. Une organisation est souveraine lorsqu’elle connaît ses dépendances, arbitre entre plusieurs solutions et conserve une capacité crédible de poursuivre ou de rétablir son activité.
- Le risque géopolitique intègre le périmètre du plan de continuité. Aux scénarios classiques s’ajoutent la restriction réglementaire extraterritoriale, l’interdiction d’accès fondée sur la nationalité ou la localisation, la rupture contractuelle imposée au fournisseur, la modification unilatérale des conditions d’usage, le retrait d’un modèle ou d’une fonctionnalité, et l’incompatibilité juridique entre juridictions.
Référentiels et textes applicables
Référentiel | Exigence mobilisable | Application au cas |
NIST AI RMF 1.0 | La catégorie GOVERN 6 traite les risques provenant des logiciels, données et acteurs tiers. GOV 6.2 prévoit des processus de contingence en cas de défaillance d’un système d’IA tiers. | Référence la plus directement applicable. Elle fournit le vocabulaire d’audit du scénario Fable 5. |
NIST Generative AI Profile (AI 600-1) | Extension du cadre aux risques propres à l’IA générative : fournisseurs, composants intégrés, contrats, responsabilités, plans de contingence. | Base de construction d’une grille d’audit du fournisseur de LLM. |
Directive NIS2, article 21 | Mesures proportionnées de continuité d’activité, de gestion de crise et de sécurité de la chaîne d’approvisionnement. | Un fournisseur de modèle intégré à un processus essentiel relève de l’analyse de dépendance et du dispositif de continuité. |
Guide technique ENISA pour NIS2 | Déclinaison opérationnelle : gestion des fournisseurs, continuité, dépendances, chaîne d’approvisionnement. | Support de mise en œuvre pour les RSSI. |
DORA | Gestion du risque lié aux prestataires TIC, du risque de concentration et des stratégies de sortie. | Le recours massif à un même modèle relève de l’analyse de concentration technologique. |
Règlement européen sur l’IA (AI Act) | Partage d’informations entre fournisseurs de modèles à usage général et acteurs en aval ; encadrement des modèles à risque systémique. | Distingue les obligations du fournisseur de modèle et celles de l’organisation qui l’intègre à son propre système. |
Data Act | Facilitation du changement entre services de traitement de données et réduction des obstacles au switching. | Traite la portabilité. L’équivalence fonctionnelle entre deux LLM demeure à démontrer séparément. |
Cloud Sovereignty Framework, Commission européenne (2025) | Évaluation multidimensionnelle : juridique, opérationnelle, technologique, données, sécurité, chaîne d’approvisionnement. | Matrice de référence pour construire une grille de souveraineté IA. |
ISO 22301 | Analyse d’impact sur l’activité, stratégies de continuité, procédures documentées, exercices. | Cadre principal pour tester la perte d’accès à un fournisseur d’IA critique. |
ISO/IEC 27001:2022 | Maîtrise des risques liés aux fournisseurs, aux services cloud, aux changements et à la continuité de la sécurité de l’information. | Inscrit les LLM externes à l’inventaire des actifs et au dispositif de gestion des tiers. |
ISO/IEC 42001:2023 | Gouvernance et management des systèmes d’IA : responsabilités, risques, cycle de vie. | Gouverne la sélection, la surveillance, le remplacement et le retrait des modèles. |
Quatre constats structurants
1 — La dépendance à un modèle unique constitue un risque de continuité d’activité
L’intégration d’un LLM dans un processus essentiel crée un point de défaillance dès lors que l’organisation ne dispose ni d’un modèle de remplacement testé, ni d’une procédure de fonctionnement dégradé.
2 — Le risque fournisseur excède la panne technique
L’indisponibilité procède également d’une décision géopolitique, d’un contrôle à l’exportation, d’un conflit juridique, d’un changement contractuel, d’une évolution des politiques de sécurité du fournisseur ou du retrait unilatéral d’un modèle.
3 — Le multicloud se distingue du multimodèle
Fable 5 était distribué par Anthropic, AWS, Google Cloud et Microsoft. Ces quatre canaux donnaient accès au même modèle, soumis à la même décision réglementaire. La multiplication des plateformes de distribution laisse la dépendance intacte.
Plusieurs hébergeurs constituent plusieurs solutions de continuité uniquement lorsqu’ils reposent sur des fournisseurs de modèles distincts et des régimes juridiques distincts.
4 — La souveraineté IA se mesure en capacité de remplacement
Les indicateurs pertinents portent sur le délai de bascule, la portabilité des données et des prompts, la conservation de la mémoire et des journaux, l’interchangeabilité des outils, le maintien du niveau de sécurité, l’équivalence des performances métier et la disponibilité d’un fonctionnement local ou dégradé
Grille d'audit : douze points de contrôle
Domaine | Point de contrôle |
Criticité | Recensement des processus interrompus par une indisponibilité de 24 heures, 7 jours et 30 jours. |
Dépendances | Identification du mode d’appel du modèle : accès direct ou via AWS, Google Cloud, Microsoft, ou un intégrateur. |
Juridiction | Détermination du droit applicable au fournisseur, à l’hébergeur et aux sous-traitants. |
Réversibilité | Vérification de la transférabilité des prompts, agents, outils, historiques et données. |
Secours | Existence d’un modèle secondaire effectivement testé en conditions métier. |
Équivalence | Démonstration documentée de la fiabilité du modèle secondaire sur le processus concerné. |
Sécurité | Comparaison des filtres, règles de confidentialité et contrôles d’accès entre modèle principal et modèle de secours. |
Contrat | Documentation des motifs de suspension admissibles et des obligations d’information du fournisseur. |
Continuité | Définition d’un RTO et d’un RPO propres au service d’IA. |
Exercices | Réalisation effective d’un exercice de perte totale du fournisseur. |
Mode dégradé | Existence d’une procédure humaine ou non-IA maintenant les opérations essentielles. |
Gouvernance | Désignation de l’autorité habilitée à décider la bascule et à accepter une baisse temporaire de performance. |
Cette grille se déploie naturellement dans le cadre d’une analyse EBIOS RM alimentant un Business Impact Analysis ISO 22301, méthodologie que DEVFORMA défend en tant que membre du Club EBIOS. L’article EBIOS RM : management des risques cyber avec ISO 27005/27001, ISO 22301, NIS2 et DORA détaille cette articulation.
Monter en compétence sur ces sujets
DEVFORMA intervient comme organisme de formation certifié Qualiopi et comme cabinet de conseil GRC et cybersécurité. Les parcours suivants couvrent directement les compétences mobilisées par ce cas.
Continuité d’activité et gestion de crise
- ISO 22301 Lead Implementer — conception et déploiement du SMCA, analyse d’impact, stratégies de continuité.
- ISO/IEC 22361 Lead Crisis Manager — pilotage de crise, directement applicable à un scénario de perte de fournisseur.
Gouvernance et management de l’IA
- ISO/IEC 42001 Lead Implementer — mise en œuvre du SMIA, gouvernance du cycle de vie des modèles.
- Lead AI Risk Manager — management du risque appliqué aux systèmes d’IA.
- Certified Artificial Intelligence Professional (CAIP) — socle technique et de gouvernance IA.
Analyse de risques et sécurité de l’information
- EBIOS Risk Manager — construction de scénarios de menace incluant le risque fournisseur et le risque réglementaire.
- ISO/IEC 27005:2022 Risk Manager — cycle complet de gestion des risques.
- ISO/IEC 27001 Lead Implementer — SMSI, gestion des tiers et des services cloud.
- ISO/IEC 27017-18 Lead Cloud Security Manager — sécurité des services cloud et maîtrise des dépendances d’hébergement.
- ISO/IEC 27035 Lead Incident Manager — gestion des incidents et retour à l’état nominal.
Conformité réglementaire
- NIS 2 Directive Lead Implementer — article 21, continuité et chaîne d’approvisionnement.
- DORA Foundation et DORA Lead Manager — risque prestataire TIC, risque de concentration, stratégies de sortie.
Le catalogue complet et l’offre de conseil permettent de construire un parcours adapté au niveau de maturité de l’organisation. Les équipes DEVFORMA accompagnent également la conduite d’un exercice de perte de fournisseur d’IA et l’intégration des modèles externes au dispositif documentaire ISO 22301 / 27001 / 42001 : nous contacter.
