IA : sortir du verrou fournisseur

Un fournisseur double ses prix. Un modèle disparaît. Une région tombe. Une politique d'utilisation change. Si votre produit s'arrête à cet instant, vous n'avez pas intégré une intelligence artificielle : vous avez loué une dépendance.

La réponse habituelle tient en trois mots : « on changera de modèle ».

Non. Pas si les prompts, les outils, les formats de réponse, les règles de sécurité et toute la logique métier ont été coulés autour d'une seule interface. Dans ce cas, le changement n'est pas une option de configuration. C'est une migration sous pression, au pire moment possible.

La souveraineté IA ne consiste pas à bannir les grands fournisseurs ni à tout exécuter en local. Elle consiste à conserver le choix. Choisir le meilleur modèle aujourd'hui, puis pouvoir en sortir demain sans reconstruire le produit.

Model-agnostic ne veut pas dire modèle indifférent

Tous les modèles ne se valent pas. Ils n'ont ni les mêmes capacités, ni la même fenêtre de contexte, ni le même comportement avec les outils, ni la même latence. Prétendre le contraire produit une abstraction mensongère.

Une architecture saine ne dit donc pas : « tous les modèles sont interchangeables ».

Elle dit : « notre métier ne dépend pas de leur dialecte ».

C'est la même différence qu'entre une prise électrique standard et les appareils qu'on y branche. La prise rend la connexion commune. Elle ne transforme pas une bouilloire en four. Le logiciel doit normaliser ce qui peut l'être — messages, réponses, erreurs, usage — et déclarer franchement ce qui ne l'est pas.

Chez OmniRealm, notre client partagé expose une même interface devant cinq familles de fournisseurs : service propriétaire, API compatible avec un standard répandu, acteurs alternatifs et exécution locale. L'application appelle un contrat commun. Les adaptateurs traduisent ce contrat vers chaque fournisseur.

Mais nous ne cachons pas les écarts. Certaines fonctions agentiques ne sont prises en charge que par une partie des adaptateurs. Si une capacité manque, le système échoue explicitement. Il ne fait pas semblant d'avoir compris une demande d'outil pour renvoyer du texte ordinaire.

C'est moins spectaculaire qu'un bouton « changer de modèle ». C'est aussi beaucoup plus honnête.

Les quatre couches à séparer

Le verrou fournisseur apparaît quand quatre choses différentes sont mélangées dans le même code.

1. La logique métier

C'est ce qui donne de la valeur au produit : les règles de qualification d'un prospect, la structure d'un audit, les critères de validation d'un document, le workflow d'un support client.

Cette logique ne devrait connaître ni le nom d'un modèle ni le format JSON particulier d'une API. Elle formule une intention et attend un résultat contractuel.

Si remplacer un fournisseur oblige à réécrire vos règles métier, la frontière est déjà cassée.

2. Le contrat IA

Cette couche décrit les objets communs : une conversation, une réponse, un appel d'outil, une erreur temporaire, un volume consommé.

Le mot important est contrat. Une simple fonction generateText() ne suffit pas dès qu'un produit devient réel. Il faut savoir si la réponse s'est terminée normalement, si elle a été tronquée, si le modèle demande une action, si l'erreur mérite une nouvelle tentative et quel fournisseur a effectivement répondu.

Le contrat est la pièce portable. Il doit être petit, stable et testé indépendamment de chaque backend.

3. Les adaptateurs fournisseur

C'est ici que vivent les dialectes : noms de champs, authentification, streaming, représentation des outils, codes d'erreur.

Un adaptateur n'a pas le droit de contaminer le reste du produit. Il traduit dans les deux sens. S'il manque une capacité, il le déclare.

Cette discipline paraît coûteuse sur le premier fournisseur. Elle devient rentable au deuxième, puis évidente au troisième.

4. Les gardes

Sécurité, validation, budgets et journalisation ne doivent pas dépendre de la bonne volonté du modèle.

Un modèle peut proposer une action. Il ne doit pas décider seul si cette action est autorisée. Un fournisseur peut changer son comportement. Il ne doit pas emporter avec lui votre politique de sécurité.

C'est le même principe que nous détaillions dans Détecter n'est pas bloquer : une intelligence probabiliste détecte et conseille ; une garde déterministe autorise ou refuse.

Placez ces gardes hors du fournisseur, et elles survivent au changement de modèle. Placez-les dans un prompt propriétaire, et vous devrez les réinventer à chaque migration.

Le fallback n'est pas une stratégie de souveraineté

Ajouter un fournisseur de secours est utile. Ce n'est pas suffisant.

Un fallback naïf dit : « si l'appel échoue, essaye ailleurs ». Mais toutes les erreurs ne justifient pas ce geste. Une panne réseau ou une limite temporaire peuvent autoriser le basculement. Une requête invalide ou un refus d'authentification doivent généralement échouer franchement. Sinon, on transforme une erreur de configuration en comportement imprévisible.

Il faut aussi répondre à des questions moins visibles :

le fournisseur de secours accepte-t-il les mêmes outils ?
les données peuvent-elles légalement et contractuellement prendre ce chemin ?
la qualité reste-t-elle acceptable pour cette tâche précise ?
le coût du secours est-il borné ?
les métriques indiquent-elles quel backend a réellement répondu ?

Sans ces réponses, le fallback est un parachute emballé dont personne n'a vérifié la taille.

La souveraineté commence quand le chemin de sortie est testé, pas quand il est dessiné dans un diagramme.

Le piège du harness

Changer de modèle n'est qu'une moitié du problème.

Un agent moderne vit aussi dans un environnement d'exécution : outils, permissions, hooks, mémoire, validations, format des appels. Même si deux modèles comprennent le même prompt, ils ne reçoivent pas nécessairement les mêmes réflexes ni les mêmes garde-fous.

On peut donc être model-agnostic tout en restant enfermé dans un harness.

La bonne réponse consiste à descendre les actifs critiques vers des couches portables :

les instructions métier dans des fichiers lisibles ;
les interfaces d'outils dans des protocoles ouverts ;
les validations bloquantes dans le code, les tests ou les hooks du dépôt ;
les décisions et l'état dans des formats exportables.

Ce qui ne peut vivre que dans une fonction propriétaire du runtime doit être identifié comme une dépendance assumée, pas déguisé en portabilité.

Le test qui ne ment pas

La plupart des équipes évaluent leur indépendance en comptant leurs fournisseurs. Mauvaise métrique.

Vous pouvez avoir trois clés API et rester totalement verrouillé si une seule route est réellement utilisée, testée et observée.

Le bon test est un exercice de sortie :

désactiver le fournisseur principal dans un environnement isolé ;
exécuter un petit jeu de tâches représentatives ;
vérifier la qualité, les appels d'outils, les gardes, le coût et les traces ;
mesurer ce qui casse avant de rétablir le chemin normal.

Si l'exercice exige une semaine de refactorisation, la sortie n'existe pas encore. Si le système bascule mais perd ses validations, elle est dangereuse. S'il répond sans que personne ne sache quel fournisseur a servi la requête, elle est invisible.

Un exercice trimestriel de 30 minutes vaut mieux qu'une promesse d'architecture jamais confrontée au réel.

Ce que nous avons appris

Notre première erreur a été de confondre interface commune et équivalence des capacités. Un chat simple se normalise facilement. Le streaming, les réponses structurées et les appels d'outils révèlent vite les différences profondes.

La correction n'a pas été d'ajouter toujours plus de magie dans l'abstraction. Nous avons fait l'inverse : contrat commun là où le sens est commun, matrice de capacités là où il diverge, erreur explicite quand la promesse ne peut pas être tenue.

La deuxième leçon est économique. Une architecture multi-provider ne sert pas seulement le jour d'une panne. Elle permet d'affecter le bon moteur à la bonne tâche : rapide pour le tri, plus capable pour le raisonnement difficile, local quand la confidentialité ou le coût l'exigent.

La troisième est stratégique : le fournisseur n'est pas votre produit. Les prompts, les processus, les données de contexte, les évaluations et les gardes représentent le capital durable. Le modèle reste un moteur remplaçable — excellent aujourd'hui, peut-être dépassé demain.

Une checklist avant le prochain contrat

Avant d'ajouter une nouvelle fonction IA, posez six questions :

La logique métier connaît-elle le nom du fournisseur ?
Le format de réponse est-il normalisé et validé ?
Les capacités non portables sont-elles déclarées ?
Les gardes critiques vivent-elles hors du modèle ?
Le fournisseur de secours est-il réellement exercé ?
Peut-on attribuer chaque réponse, chaque coût et chaque erreur au backend effectif ?

Deux « non » suffisent pour révéler une dette. Pas forcément une urgence, mais une dette à nommer avant qu'elle devienne un piège.

La souveraineté IA n'est pas l'autarcie. C'est la capacité de négocier, de basculer et de partir.

On peut choisir un fournisseur parce qu'il est le meilleur. On ne devrait jamais être obligé de le garder parce que tout le reste s'effondre sans lui.

Pour prolonger la réflexion sur les dépendances invisibles, lire Le coût caché des abstractions no-code. Pour les gardes indépendantes du modèle, voir Détecter n'est pas bloquer.