Le piège du fournisseur.
Ce que la suspension de Fable
par Anthropic signifie pour votre stratégie IA.

Il y a une célébration en cours dans l'IA d'entreprise. De nouveaux modèles chaque trimestre. Des capacités qui étaient des articles de recherche il y a six mois entrent en production via des API. Un écosystème de fournisseurs si bien financé que le budget IT moyen dispose de plus d'intelligence de frontière que les Fortune 100 d'il y a dix ans. Les manchettes sont euphoriques. Et les manchettes passent à côté de l'essentiel.

Le 9 juin, Anthropic a publié Claude 5 en deux paliers. Fable 5 est la version publique avec les classificateurs de sécurité actifs. Mythos 5 est un palier à accès limité via Project Glasswing, disponible pour environ quarante opérateurs sélectionnés. La liste des partenaires Glasswing comprend Amazon, Apple, Google, Microsoft, Nvidia, JPMorgan et la Linux Foundation. Même modèle de base, configurations de déploiement différentes.

Le 11 juin, selon The Economist, Senator Mark Warner, vice-président du Senate Intelligence Committee, a rapporté les propos du chef de la NSA et de Cyber Command, General Joshua Rudd, selon lesquels Mythos « s'était introduit dans presque tous nos systèmes classifiés, non pas en quelques semaines mais en quelques heures ». Un jour plus tard, le US Commerce Department a publié une directive interdisant à tous les ressortissants étrangers à l'échelle mondiale d'accéder à l'un ou l'autre palier, y compris aux propres employés ressortissants étrangers d'Anthropic. La seule façon de se conformer était une suspension mondiale. Les workflows de production qui avaient commencé à migrer vers Fable 5 la semaine du lancement étaient inaccessibles dès le vendredi.

La capacité rapportée est contestée. L'auteur de The Economist a depuis ajouté que la phrase ne devrait pas être lue littéralement, qu'elle fait probablement référence à Mythos utilisé aux côtés d'autres outils dans des conditions spécifiques, et que l'article original aurait gagné à inclure des réserves. Les chercheurs en sécurité soulignent que les systèmes les plus classifiés sont conçus pour être déconnectés du réseau (air-gapped). Aucune agence gouvernementale n'a publiquement confirmé l'évaluation sous-jacente du briefing. Rien de tout cela n'aide les entreprises qui avaient passé la semaine à intégrer Fable 5 dans des pilotes agentiques et qui ont dû revenir au modèle qu'elles utilisaient auparavant. La revendication de capacité n'a pas besoin d'être littéralement vraie pour que la réponse réglementaire mette un modèle de frontière hors ligne. La dépendance est devenue plus dangereuse, quoi qu'il en soit.

C'est la conversation que je tiens avec les CDO et les CIO depuis soixante-douze heures. Et c'est la conversation qui mérite d'être tenue même si vous n'avez pas été affecté cette semaine. Le risque dans votre stratégie IA n'est pas le modèle. Le risque, c'est qui décide si le modèle sera disponible demain.

Pourquoi la dépendance au fournisseur est le risque IA que personne ne valorise

Chaque revue d'architecture IA d'entreprise que je mène commence au même endroit. L'équipe me présente ses cas d'usage. Les choix de modèles. Le travail de prompt engineering. Les garde-fous. Le cadre d'évaluation. À la fin du tour, je sais quel fournisseur ils utilisent, quelle version d'API, quelle famille de modèles, et quel régime de fine-tuning. Ce que je n'entends pas toujours, c'est ce qui se passe si le calendrier de ce fournisseur diverge de celui de mon client.

Cette divergence de calendrier était une hypothèse depuis deux ans. Cette semaine, elle a cessé d'être une hypothèse. Un modèle de frontière qui était la pièce maîtresse de plusieurs pilotes agentiques de production a été retiré pour des raisons qui n'avaient rien à voir avec la sécurité du modèle, rien à voir avec le cas d'usage de l'entreprise, et rien à voir avec quoi que ce soit que l'entreprise aurait pu négocier. L'action est venue d'un régulateur avec lequel l'entreprise n'avait aucune relation, contre un fournisseur sur lequel l'entreprise avait parié, citant des préoccupations que l'entreprise ne pouvait pas influencer.

La plupart des architectures IA que nous auditons ont une dépendance à un fournisseur unique au niveau de la couche modèle. L'intégration est propre. L'économie est propre. Le modèle opérationnel suppose que le fournisseur sera disponible le trimestre prochain. Rien de tout cela n'est faux tant que le fournisseur est disponible. Tout cela est faux dès qu'il ne l'est plus.

La suspension de Fable est une instance claire d'un schéma qui se forme depuis dix-huit mois. Contrôles à l'exportation sur les capacités IA avancées. Actions réglementaires d'États contre des comportements de modèle spécifiques. Limitation côté fournisseur lors de pics de capacité. Changements de tarification arrivés avec un préavis de trente jours sur des contrats structurés autour de feuilles de route de dix-huit mois. L'écosystème des modèles de frontière évolue plus vite que ce que le processus achats des entreprises a été conçu pour absorber.

Ce que l'IA souveraine signifie réellement pour une entreprise

La réaction à l'actualité de cette semaine, dans certains milieux, a été prévisible. Construisez vos propres modèles. Faites-les tourner dans vos propres datacenters. Coupez le fournisseur de la boucle. La réaction est juste dans la direction et fausse dans le détail. La plupart des entreprises ne devraient pas entraîner des modèles de fondation à partir de zéro. Le coût en capital est réel, les talents sont rares, et le résultat est rarement compétitif par rapport à ce qui est disponible commercialement.

La souveraineté dans une architecture IA d'entreprise ne signifie pas refuser d'utiliser des modèles de fournisseurs. Elle signifie refuser d'être otage de l'un d'eux. La différence existe, et elle est architecturale.

Une architecture de workflow agnostique au fournisseur

Chaque workflow agentique que nous concevons aujourd'hui dispose d'une couche de routage de modèles qui abstrait le fournisseur sous-jacent. Un workflow qui utilise Fable 5 aujourd'hui devrait être à un changement de configuration près d'utiliser Claude Opus 4.8, ou un poids ouvert de la famille Llama, ou un modèle concurrent qui sortira le mois prochain. Si changer de fournisseur exige une réarchitecture de votre logique d'agent, votre architecture n'est pas agnostique au fournisseur. Elle est simplement actuelle pour ce fournisseur.

Un pattern orchestrateur. Le bon modèle pour la bonne tâche.

La dépendance à un fournisseur unique commence généralement comme une habitude liée à un modèle unique. L'équipe choisit le modèle le plus performant sur le marché et y route toutes les tâches. Appels de classification, appels de synthèse, extraction de documents, raisonnement orienté client, triage interne. Tout vers le même fournisseur, au même niveau de prix, sur le même calendrier. Cette habitude est la dépendance.

Le pattern orchestrateur la résout. Une couche de routage qui envoie chaque tâche au modèle qui lui correspond. Un petit modèle à poids ouverts pour la classification et l'extraction légère. Un modèle fournisseur de gamme intermédiaire pour la synthèse et la réponse structurée. Un modèle de frontière uniquement pour les tâches qui exigent réellement un raisonnement de frontière. Le résultat est un coût plus bas, une latence plus rapide, une exposition de données plus restreinte, et une empreinte fournisseur qui ne s'effondre pas quand un fournisseur passe hors ligne. Le bon modèle pour la bonne tâche n'est pas de l'optimisation. C'est une posture de souveraineté qui s'autofinance.

Une couche modèle en propre pour les charges de travail qui le justifient

Pas toutes les charges de travail. Celles où les données sont assez sensibles, le volume assez élevé, ou la continuité opérationnelle assez critique pour justifier le coût. Pour ces charges, un modèle à poids ouverts affiné, exécuté sur une infrastructure que vous contrôlez, dans une région que vous choisissez, avec un calendrier de mise à jour que vous fixez, est la seule architecture qui ne vous fera pas perdre un trimestre quand un régulateur bouge.

Posséder la couche modèle pour ces charges de travail ferme aussi un autre type de risque. Chaque prompt et chaque récupération qui touche une API tierce, ce sont des données que votre entreprise place dans la surface de contrôle de quelqu'un d'autre. Même avec des clauses d'exclusion des données négociées, chaque cycle de renégociation est une chance de perdre cette protection. Faire tourner les workflows sensibles sur votre propre matériel réduit le risque qu'un modèle de frontière laisse fuir de la propriété intellectuelle, et le risque que votre logique tarifaire propriétaire, vos transcriptions clients ou vos artefacts de stratégie deviennent les données d'entraînement de quelqu'un d'autre via un chemin de rétention opaque. Ce n'est pas un projet de recherche. C'est une décision d'achat avec un retour sur investissement mesurable.

Un data fabric qui ne fuit pas dans le jeu d'entraînement de quelqu'un d'autre

Si vos données commerciales propriétaires, vos interactions clients ou votre télémétrie opérationnelle circulent vers une API tierce sous des conditions que vous n'avez pas négociées pour l'exclusion des données, vous ne payez pas seulement pour de l'inférence. Vous subventionnez aussi le prochain modèle de votre fournisseur. Le data fabric qui soutient l'IA souveraine est celui où vous décidez ce qui franchit la frontière et ce qui ne la franchit pas.

Un plan de sortie que vous avez testé, pas seulement écrit

Chaque charge de travail IA en production devrait avoir un chemin de migration documenté et répété vers un second fournisseur. Pas dans une présentation. Dans un runbook que votre équipe a exécuté dans les quatre-vingt-dix derniers jours. Les entreprises qui ont traversé la suspension de Fable cette semaine sans impact opérationnel sont celles qui avaient déjà testé la migration. Celles qui l'ont rencontrée à froid sont celles qui expliquent l'incident à leurs conseils d'administration ce matin.

L'autre erreur. Tout verrouiller.

La mauvaise réaction à l'actualité de cette semaine est l'inverse de la mauvaise réaction à l'actualité de l'année dernière. L'année dernière, la mauvaise réaction était de greffer une API de frontière sur chaque workflow sans une architecture en dessous. Cette semaine, la mauvaise réaction est de débrancher entièrement l'IA d'entreprise et d'attendre que le paysage réglementaire se stabilise.

Il ne se stabilisera pas. Et pendant que la direction débat pour savoir s'il faut autoriser l'IA à l'intérieur du périmètre de l'entreprise, les employés l'utilisent déjà à l'extérieur du périmètre. Ils collent des transcriptions clients dans des applications de chat grand public pour rédiger des réponses. Ils téléversent des contrats fournisseurs dans des outils gratuits pour les synthétiser. Ils utilisent des comptes personnels sur des appareils personnels parce que le travail devant eux doit être livré et que la réponse officielle est encore « nous évaluons ».

Tout verrouiller n'arrête pas ce trafic. Cela déplace ce trafic vers un endroit où votre équipe sécurité ne peut pas le voir, où votre équipe gouvernance des données ne peut pas l'auditer, et où vos protections de propriété intellectuelle ne portent pas. Le tabou se renforce. L'usage devient plus négligent. La surface fantôme s'agrandit. Et l'entreprise se retrouve avec la pire version de la dépendance qu'elle essayait d'éviter, parce que l'usage se fait dans les pires conditions possibles.

La bonne réaction est d'adopter l'IA à un certain niveau, à des conditions que vous contrôlez. Un palier sanctionné de modèles approuvés et de classes de données approuvées. Une couche de routage orchestrée qui rencontre les employés là où ils essaient de travailler. Une politique claire sur ce qui circule où, et une surface utilisable où ils n'ont pas besoin de quitter la plateforme pour obtenir la réponse. Les entreprises qui l'ont fait n'ont pas éliminé l'IA fantôme. Elles l'ont réduite à une fraction de ce qu'elle aurait été autrement, et elles ont déplacé le travail qui compte le plus sur une stack qu'elles peuvent défendre.

La question du séquencement que cette semaine a clarifiée

La conviction de TechSparq sur l'IA est que le modèle n'est pas la stratégie. L'architecture de processus autour du modèle est la stratégie. Cet argument est le nôtre depuis deux ans. Cette semaine, il est devenu moins coûteux à démontrer. Une entreprise qui avait construit son pilote agentique sur Fable 5 seul a appris en soixante-douze heures que le modèle est la partie la plus remplaçable du système. Une entreprise qui avait construit son pilote agentique sur une couche de routage, un data fabric souverain et un plan de sortie testé a appris qu'elle n'avait rien à faire cette semaine sinon continuer à travailler.

La bonne séquence pour l'IA d'entreprise est la même aujourd'hui qu'elle l'était lundi. Commencez par le workflow qui produit un résultat business mesurable. Concevez l'architecture de processus dont le workflow dépend. Choisissez le modèle qui correspond aux exigences du workflow, y compris ses exigences de souveraineté. Construisez la couche de routage qui vous permet de changer de modèle quand le calendrier change. Testez le changement. Puis livrez.

Les équipes les plus exposées cette semaine étaient celles qui avaient commencé par le modèle. Pas parce que le modèle était mauvais. Parce que le modèle était la première décision au lieu de la dernière. Au moment où le reste de l'architecture a été conçu, le modèle avait déjà façonné les hypothèses de routage, les flux de données et les attentes opérationnelles. Revenir là-dessus en un seul trimestre n'était pas le travail que quiconque voulait faire sous pression réglementaire.

Que faire ce trimestre

Si vous avez des charges de travail IA en production, auditez les dépendances aux modèles avant la fin du mois. Documentez quels workflows dépendent de quels fournisseurs. Cartographiez les clauses contractuelles qui régissent la continuité. Identifiez la solution de second fournisseur pour chaque chemin critique. L'audit prend une semaine. Ne pas l'avoir fait coûte un trimestre.

Si vous êtes encore en pilote, traitez les décisions d'architecture comme le travail et la sélection du modèle comme un paramètre. Le bon pilote est celui que vous pourriez relancer sur un autre modèle en une semaine. Si le vôtre ne le pourrait pas, c'est l'architecture qui est le problème, pas le modèle.

Si vous partez de zéro, ne commencez pas par le modèle. Commencez par le workflow, l'architecture des données et les exigences de souveraineté. La sélection du modèle est une conséquence en aval de ces trois décisions, pas un point de départ. La suspension de Fable a rendu ce séquencement moins coûteux à expliquer. Les équipes qui construisent avec ce principe en tête passeront cette année à livrer de l'IA en production. Les équipes qui ne le font pas passeront cette année à expliquer des incidents.