Lorsqu’un modèle d’IA disparaît du jour au lendemain : pourquoi les DSI ont besoin d’un plan B

Anthropic a désactivé deux de ses modèles les plus récents dans le monde entier le 12 juin, en raison d’une réglementation américaine sur les exportations que le fournisseur ne peut pas appliquer de manière sélective sur le plan technique. Pour les DSI, il ne s’agit pas d’une nouvelle concernant Anthropic, mais d’un test de résistance pour leur propre approvisionnement en modèles.

En lien :De l’expérimentation à l’exploitation de l’IA : pourquoi la majorité échoue à franchir le cap  /  L’IA automatise le travail junior : pourquoi les DSI ont besoin des jeunes talents

Qu’est-ce qu’une directive de contrôle des exportations ? Une mesure étatique qui restreint l’accès à certaines technologies ou services pour des raisons de sécurité nationale. Elle peut exiger d’exclure un groupe de personnes de l’accès, par exemple en fonction de leur nationalité. Si cette condition ne peut pas être appliquée de manière ciblée, le fournisseur n’a souvent d’autre choix que de bloquer le service de manière large ou totale.

Ce qui s’est passé le 12 juin

Anthropic avait présenté les modèles Claude Fable 5 et Claude Mythos 5 le 9 juin. Trois jours plus tard, le gouvernement américain, sous l’administration Trump, a émis une réglementation sur les exportations liée à la sécurité nationale, selon les rapports du secteur. Celle-ci exige de bloquer l’accès aux deux modèles pour tout ressortissant étranger, aux États-Unis comme à l’étranger, y compris pour les employés étrangers du fournisseur lui-même.

Anthropic ne peut pas filtrer la nationalité en temps réel et à grande échelle. Le fournisseur a donc désactivé les deux modèles pour tous les utilisateurs dans le monde. Les autres modèles de la série restent disponibles. Selon la version gouvernementale, le déclencheur était un signalement d’une autre entreprise concernant une éventuelle faille de contournement (*jailbreak*). Anthropic conteste cette interprétation sur le fond et qualifie cette possibilité de très limitée et non universelle. Dans son communiqué, il est indiqué en substance que l’accès est suspendu et qu’une remise en service est visée.

Du point de vue des DSI, les subtilités juridiques sont secondaires. Ce qui compte, c’est la nature de la panne. Elle n’est pas survenue à cause d’un bug, d’un pic de charge ou d’une pénurie d’approvisionnement, mais en raison d’une mesure réglementaire qu’un fournisseur unique a dû appliquer.

Pourquoi la disponibilité est désormais une question géopolitique

La plupart des registres de risques liés à l’IA traitent la disponibilité comme un sujet technique : redondance, latence, limites de débit, basculement. Ce cas de figure déplace l’axe. Un modèle peut tomber en panne alors que l’infrastructure fonctionne sans faille et que le SLA est formellement respecté.

Cela touche un angle mort dans de nombreuses architectures. Quiconque a intégré un modèle de pointe au cœur d’un produit, d’un workflow ou d’une promesse client a créé une dépendance qui ne peut être sécurisée par la seule surveillance. La question pertinente en comité d’investissement n’est plus seulement de savoir à quel point un fournisseur est techniquement stable. Elle est de savoir à quelle vitesse sa propre création de valeur s’arrête si ce modèle précis devient inaccessible demain.

Pour les décideurs DACH, une seconde couche s’ajoute. La plupart des modèles de pointe sont développés aux États-Unis et soumis au droit américain. Une restriction à l’exportation décidée à Washington peut ainsi avoir un impact direct sur une application à Munich, Vienne ou Zurich, sans que la partie contractante allemande dispose d’un levier de négociation. Dans cette logique, les options de souveraineté et européennes ne sont pas un simple exercice de conformité, mais une question de capacité d’approvisionnement.

Le plan B s’appelle interchangeabilité, pas second fournisseur

Le multi-modèle est souvent mal compris comme une question d’achat : deux contrats au lieu d’un. Le véritable levier se situe un niveau plus bas. L’essentiel est de savoir si un modèle peut être remplacé sans des semaines de refonte.

Trois conditions déterminent une véritable interchangeabilité. Premièrement, une couche d’abstraction qui découple l’application et le modèle, de sorte qu’un changement de fournisseur soit une question de configuration et non de réingénierie. Deuxièmement, une base d’évaluation propre : un ensemble fixe de tests et de cas de référence permettant d’approuver un modèle de remplacement en quelques jours plutôt qu’en plusieurs mois. Troisièmement, une clarté contractuelle sur la sortie, le repli et la portabilité des données avant que la situation d’urgence ne survienne.

Ces éléments ne constituent pas un projet d’envergure. Une couche d’abstraction légère et un ensemble de tests coordonnés peuvent être mis en place en quelques semaines et s’avèrent rentables à chaque changement de fournisseur, qu’il soit imposé par la réglementation ou simplement économiquement judicieux.

Les 90 premiers jours

La première étape ne concerne pas l’architecture, mais un inventaire. Quels produits, processus et promesses clients dépendent d’un seul modèle de pointe, et quel chiffre d’affaires est bloqué en cas de panne ? Cette liste permet de déterminer où l’interchangeabilité est une obligation et où un fournisseur unique reste acceptable.

Vient ensuite le registre des risques : la défaillance d’un fournisseur due à la réglementation doit figurer comme une ligne distincte, avec un responsable, un seuil et une réaction définie. Parallèlement, chaque nouveau contrat d’IA ou renouvellement doit inclure une clause de sortie et de repli. Et pour au moins un cas d’usage critique, un second modèle, idéalement compatible avec l’UE, doit fonctionner en parallèle comme un shadow system, afin que le changement soit testé et non improvisé en cas d’urgence.

Foire aux questions

Image de couverture : générée par IA (juin 2026)