Dépendance fournisseur IA : le plan de secours que vous n’avez pas
Un vendredi soir, à 17h21, Anthropic reçoit une directive du gouvernement américain : suspendre l’accès à ses deux nouveaux modèles, Fable 5 et Mythos 5, pour tout ressortissant étranger, y compris ses propres salariés non américains. Incapable de trier ses utilisateurs un par un, l’entreprise coupe les modèles pour tout le monde (communiqué d’Anthropic). Quatre jours plus tôt, Fable 5 venait à peine d’ouvrir au public.
Personne n’avait vu venir cette histoire. C’est précisément le problème.
Et tout ne se joue pas à Washington. Pendant qu’Anthropic se débat avec l’administration américaine, son grand rival navigue sur une économie vertigineuse. Selon ses propres prévisions, OpenAI s’attend à près de 14 milliards de dollars de pertes pour la seule année 2026 et ne se projette pas rentable avant 2029, ce qui l’oblige à lever des financements par dizaines de milliards. Personne ne prédit sa disparition pour demain matin. Mais un service dont le modèle économique repose sur des levées de fonds continues n’offre pas les mêmes garanties de durée qu’une activité rentable. Deux géants, deux fragilités opposées, le même angle mort pour leurs clients.
On débat sans fin de la qualité des modèles, de leur prix, de leur vitesse. Beaucoup plus rarement de ce qui arrive le jour où ils cessent de répondre. Or intégrer l’IA dans une organisation est devenu un métier à part entière, et ce métier inclut une question qu’on préfère éviter : que se passe-t-il si le fournisseur disparaît du tableau, sans préavis ?
Mettez les deux bout à bout et le tableau se dessine. Un modèle peut sauter sur décision politique, comme pour Fable 5. Il peut aussi voir son éditeur réduire la voilure faute de rentabilité, voir son tarif doubler du jour au lendemain, ou se retrouver bloqué dans votre pays pour des raisons réglementaires. Le résultat est le même : un outil sur lequel vous comptiez n’est plus là.
Ce qui s’arrête, le jour où l’IA s’arrête
Première surprise quand on pose franchement la question : beaucoup d’organisations sont incapables d’y répondre. Elles ont branché un assistant ici, un agent là, une génération de comptes-rendus dans un coin, et l’ensemble s’est diffusé sans jamais avoir été cartographié.
Le travail de base ne consiste pas à choisir un modèle de secours. Il consiste à dresser la liste. Quels processus reposent aujourd’hui sur une IA externe ? Lesquels sont critiques, au sens où leur arrêt bloque une livraison client ou une obligation légale ? Lesquels sont confortables mais reprenables à la main pendant quelques jours ?
Cet inventaire révèle presque toujours deux choses. Des dépendances oubliées, parce qu’un service tiers utilise lui-même une IA en coulisses. Et une poignée de processus bel et bien vitaux, souvent bien moins nombreux qu’on ne le craignait. C’est sur ceux-là, et eux seuls, qu’un plan se justifie.
Un exemple revient souvent. Une équipe commerciale s’est mise à rédiger ses propositions et ses relances avec un assistant, sans que la direction l’ait jamais formalisé. Le jour où l’accès saute, ce n’est pas une ligne de budget qui s’évapore, c’est une partie du rythme commercial. Personne ne l’avait inscrit nulle part comme une dépendance, et elle en était pourtant devenue une.
Le verrou n’est pas le modèle, c’est la plomberie
Changer de modèle, en théorie, prend cinq minutes : on remplace une clé d’API par une autre. En pratique, presque personne ne peut le faire, et la raison ne tient pas au modèle lui-même.
Le verrou se cache dans tout ce qu’on a construit autour. Les prompts calés au mot près sur le comportement d’un modèle précis. Les intégrations qui attendent un format de réponse particulier. Les automatisations qui s’enchaînent en supposant que tel outil répondra de telle façon. Déménager tout cela vers un autre fournisseur, dans l’urgence, relève du chantier, pas du réglage.
La parade tient en un mot : découpler. Faire transiter ses appels par une couche intermédiaire au lieu de coder en dur un fournisseur unique dans chaque automatisation. Cette couche, souvent appelée routeur, permet de rediriger le trafic vers un autre modèle sans toucher au reste de la chaîne. Sa mise en place a un coût, mais c’est la différence entre une bascule de quelques heures et une réécriture de plusieurs semaines.
Un plan B qui tient ne s’improvise pas le jour J
Un fournisseur de secours qu’on n’a jamais essayé n’est pas un plan B. C’est une intention. Le jour où le premier tombe, on découvre que les prompts ne rendent pas la même chose ailleurs, que les résultats dérivent, que personne ne sait configurer l’accès.
Un bon plan B repose sur trois réflexes. Tester sérieusement un second fournisseur sur vos cas réels, pas sur une démo, et garder cette configuration prête à l’emploi. Accepter que la portabilité a un coût : un prompt réglé pour un modèle donné ne produira pas exactement le même résultat sur un autre, il faut le réajuster, et cela se fait plus vite à froid que dans la panique. Réserver une option souveraine aux processus les plus sensibles : des modèles ouverts comme Mistral ou Llama, hébergeables sur votre propre infrastructure, que personne ne peut couper à distance, au prix d’un peu de performance et d’un peu d’exploitation supplémentaire.
Ces trois réflexes ne pèsent pas du même poids partout. Un processus de confort se contente d’un retour au travail manuel pendant quelques jours. Un processus critique mérite le second fournisseur déjà testé. Seul le coeur vital justifie l’option souveraine, plus lourde à mettre en place et à maintenir.
Il y a une ironie utile dans l’affaire Fable 5. Le modèle public était lui-même conçu avec un filet : sur les sujets sensibles, il refusait de répondre et repassait la main à un modèle plus ancien et plus prudent. Anthropic avait prévu un repli pour son propre produit. La question se retourne d’elle-même : pourquoi votre organisation n’en aurait-elle pas un ?
Commencer petit, mais commencer
Rien de tout cela n’oblige à transformer sa maison en bunker. La plupart des entreprises n’ont aujourd’hui aucun plan, et l’objectif n’est pas de passer de zéro à une redondance totale en une semaine.
Construire un plan de continuité IA, dans l'ordre
Cartographier la dépendance
Lister les processus qui reposent sur une IA externe et repérer ceux dont l’arrêt bloquerait une livraison ou une obligation légale.
Découpler de la plomberie
Faire passer les appels par une couche intermédiaire plutôt que de coder en dur un fournisseur unique, pour pouvoir basculer sans tout réécrire.
Tester un plan B réel
Configurer un second fournisseur sur vos cas concrets, réajuster les prompts à froid et garder la solution prête à l’emploi.
Réserver une option souveraine
Pour le plus critique, un modèle ouvert hébergé chez soi que personne ne peut couper à distance, au prix d’un peu de performance.
La première marche est gratuite ou presque : la cartographie. Savoir ce qui dépend de quoi, et lesquels de ces liens feraient mal en cassant. Vient ensuite le découplage des seuls processus critiques, puis un fournisseur de secours testé pour eux. La résilience face à l’IA ne se souscrit pas en catastrophe comme une assurance le jour du sinistre. Elle se construit calmement, avant d’en avoir besoin. Choisir ses outils en connaissant leurs portes de sortie fait maintenant partie du métier, autant que choisir le bon modèle.
En pratique chez BGT
Cet article s’appuie sur des déploiements IA réels en PME et ETI. Si vous préparez le vôtre, autant en parler avec une équipe dont c’est le métier.
Voir nos solutions IA générative →








