Quand un fournisseur d'IA peut être coupé : provisionner le risque de dépendance

Imaginez que le moteur sur lequel tourne votre assistant interne, votre outil de support ou votre brique de traitement documentaire devienne inaccessible un lundi matin. Pas pour une panne. Pas pour un dépassement de facture. Parce qu'une autorité, dans un autre pays, a exigé que ce modèle soit coupé. Vos équipes ouvrent l'outil, et il ne répond plus.

Ce scénario n'est plus théorique. Mi-juin 2026, le gouvernement américain a contraint Anthropic à suspendre l'accès à deux de ses modèles, Fable 5 et Mythos 5. La raison invoquée tient à la sécurité, pas à un problème de service. Pour une entreprise qui avait bâti une fonction critique sur l'un de ces modèles, la conséquence est la même qu'une coupure de courant : le service s'arrête, et la décision ne vous appartient pas.

Le risque n'est pas la performance, c'est le point unique

Quand une entreprise choisit un modèle d'IA, elle compare presque toujours les bons critères : qualité des réponses, latence, prix au million de tokens, conformité des données. Ce sont les bons critères, mais il en manque un que personne n'inscrit dans le tableau comparatif : que se passe-t-il si ce fournisseur devient indisponible du jour au lendemain ?

Indisponible ne veut pas seulement dire en panne. Un modèle peut disparaître pour plusieurs raisons qui n'ont rien à voir avec sa fiabilité technique :

• Une décision réglementaire ou politique, comme la coupure de Fable 5 et Mythos 5.
• Le retrait commercial d'une version, fréquent quand un éditeur pousse ses clients vers un modèle plus récent et débranche l'ancien.
• Un changement de conditions d'usage qui exclut votre cas d'usage ou votre secteur.
• Une rupture de la relation contractuelle côté fournisseur, pas côté client.

Dans chacun de ces cas, votre service s'arrête sans que vous ayez commis la moindre erreur. Le problème n'est pas le modèle que vous avez choisi. C'est le fait de n'en avoir qu'un, branché en dur, sans porte de sortie.

Provisionner un risque, c'est l'évaluer avant qu'il arrive

Le mot juste ici est provisionner. En gestion, provisionner un risque, c'est mettre de côté de quoi l'absorber avant qu'il se réalise. Une entreprise provisionne ses créances douteuses, ses litiges, ses garanties. La dépendance à un fournisseur d'IA mérite le même traitement.

Provisionner ne veut pas dire fuir. Il ne s'agit pas d'abandonner le meilleur modèle par principe de précaution. Il s'agit de répondre, avant le déploiement, à trois questions concrètes :

• Quel impact si ce modèle s'arrête demain matin ? Un confort en moins, ou une activité bloquée ?
• Combien de temps pour basculer sur une alternative, dans l'état actuel de votre code ?
• Qui décide de la disponibilité de ce service, et selon quelles règles qui peuvent changer sans vous ?

Une fonction de confort qui peut s'arrêter une journée sans dommage ne demande aucune précaution particulière. Une brique qui traite vos commandes, votre support client ou vos dossiers réglementés ne peut pas dépendre d'un interrupteur que vous ne tenez pas. Le niveau de provision suit l'enjeu, exactement comme une assurance.

Trois niveaux de repli, du plus simple au plus engageant

La bonne nouvelle, c'est qu'un plan de repli ne signifie pas tout réécrire ni tout rapatrier sur vos serveurs. Il existe trois niveaux, et la plupart des entreprises n'ont besoin que du premier ou du deuxième.

Niveau 1 : isoler l'appel au modèle derrière une couche d'abstraction. Au lieu d'appeler directement l'API du fournisseur partout dans votre code, vous passez par une seule fonction intermédiaire qui, elle, appelle le modèle. Le jour où vous changez de fournisseur, vous modifiez cette fonction unique, pas cent endroits dispersés. Ce travail coûte quelques jours au départ et transforme une migration de plusieurs semaines en une opération d'une journée. C'est le minimum vital, et il devrait être la norme dès le premier déploiement.

Niveau 2 : garder une alternative testée, pas seulement identifiée. Avoir un deuxième fournisseur en tête ne suffit pas. Une alternative n'est un repli que si elle a déjà tourné sur vos données, avec vos prompts, et que vous connaissez son comportement. La différence entre un nom noté dans un document et un modèle déjà branché en secours se mesure en heures le jour de l'incident, pas en semaines.

Niveau 3 : héberger en propre ce qui ne peut pas s'arrêter. Pour les fonctions vraiment critiques ou les données très sensibles, faire tourner un modèle ouvert sur votre propre infrastructure supprime la dépendance à un tiers. Les modèles ouverts ont fait des progrès réels, au point qu'un modèle local couvre aujourd'hui une bonne partie des usages courants. Ce niveau demande un vrai investissement, et il ne se justifie que quand l'enjeu le commande. C'est le sujet que nous avons détaillé dans notre article sur le backend produit IA souverain et self-hosted.

La dépendance ne concerne pas que le modèle

Un point que beaucoup d'équipes négligent : changer de modèle ne suffit pas si tout le reste reste captif. La vraie question de souveraineté ne se limite pas au choix du fournisseur, elle porte sur l'ensemble de la chaîne. C'est l'angle que nous avons traité dans notre article sur l'alternative française à ChatGPT en entreprise, du côté du droit applicable et de l'emplacement des données.

Ici, le sujet est différent mais complémentaire. Même avec un fournisseur parfaitement conforme, si vos prompts, vos données de référence et votre logique métier sont enfermés dans le format propriétaire d'un seul outil, vous restez dépendant. Provisionner le risque, c'est aussi garder la portabilité de ce que vous construisez autour du modèle, pas seulement du modèle lui-même.

Comment SolidScale traite la dépendance dans la méthode S3

La dépendance à un fournisseur ne se règle pas après un incident. Dans la méthode Scan, Solve, Scale, elle se pose dès le cadrage, comme un critère et non comme une option.

Scan : l'audit gratuit de 30 minutes qualifie le niveau de criticité de chaque fonction visée. Une brique dont l'arrêt bloque l'activité n'a pas le même traitement qu'un assistant de confort. Cette qualification détermine le niveau de repli à provisionner, avant même de choisir un outil.

Solve : la couche d'abstraction du niveau 1 fait partie de la construction par défaut, pas d'une option à débattre. Le modèle est branché derrière une frontière nette, ce qui garde la liberté de changer sans tout casser. Pour les cas critiques, l'alternative est testée pendant le sprint, pas promise pour plus tard.

Scale : quand l'usage s'étend, la cartographie des dépendances est revue. Un point unique acceptable sur un pilote restreint ne l'est plus à l'échelle de l'entreprise, et le plan de repli se renforce en conséquence.

Ce qu'il faut retenir

La coupure de Fable 5 et Mythos 5 a rappelé une évidence que l'enthousiasme autour de l'IA fait souvent oublier : un service que vous ne contrôlez pas peut s'arrêter sur une décision qui n'est pas la vôtre.

• Le risque n'est pas la qualité du modèle, c'est la dépendance à un point unique.
• Une coupure peut venir d'une décision politique, d'un retrait commercial ou d'un changement de conditions, sans aucune faute de votre part.
• La parade tient en trois niveaux : abstraction systématique, alternative testée, et self-hosted pour le critique.
• Provisionner ce risque est une décision d'architecture, à prendre avant le déploiement.

L'action concrète tient en une phrase : avant de brancher une fonction importante sur un modèle d'IA, isolez l'appel derrière une couche unique et gardez une alternative déjà testée.

Questions fréquentes

Faut-il vraiment prévoir un repli pour chaque usage de l'IA ?

Non. Le niveau de précaution suit la criticité. Une fonction de confort qui peut s'arrêter une journée sans conséquence ne demande rien de particulier. Une brique qui bloque votre activité si elle tombe mérite au minimum une couche d'abstraction et une alternative testée. Le bon réflexe est de classer vos usages par impact avant de décider.

La couche d'abstraction, c'est compliqué à mettre en place ?

C'est un travail simple s'il est fait au départ, et coûteux s'il est ajouté après coup. Concrètement, il s'agit de faire passer tous les appels au modèle par une seule fonction intermédiaire, au lieu de les disperser dans le code. Quelques jours de travail au lancement évitent des semaines de migration le jour où il faut changer de fournisseur.

Un modèle hébergé en interne est-il à la hauteur des modèles commerciaux ?

Pas toujours sur les tâches les plus exigeantes, mais les modèles ouverts couvrent aujourd'hui une large part des usages courants en entreprise. Pour beaucoup de fonctions internes, un modèle local bien intégré fait le travail, avec l'avantage de supprimer la dépendance à un tiers. La décision se prend cas par cas, en mettant le besoin réel en face du coût d'hébergement.

Comment savoir quelles fonctions provisionner en priorité ?

En répondant à une question simple pour chacune : si ce service s'arrête demain matin, est-ce un inconfort ou un blocage ? Les blocages passent en priorité. C'est exactement ce que qualifie la phase Scan de la méthode SolidScale, avant tout choix d'outil.

Sources

• Blog du Modérateur, Le gouvernement des États-Unis force Anthropic à couper l'accès à Fable 5 et Mythos 5, juin 2026, blogdumoderateur.com
• Journal du Net, Quand un État peut éteindre votre IA : le risque de dépendance que personne ne provisionne, juin 2026, journaldunet.com
• Siècle Digital, Anthropic contraint de couper en urgence ses IA jugées les plus dangereuses, juin 2026, siecledigital.fr