Éviter le verrouillage fournisseur d'un LLM : méthode

Un projet qui appelle un seul fournisseur de modèles dépend de ce fournisseur pour ses prix, sa disponibilité, ses modèles et ses fonctions. Le risque n'est pas théorique : un modèle peut être retiré, un tarif peut changer, une règle de données peut évoluer. Le verrouillage (« lock-in » en anglais) désigne le coût de sortie : combien de temps et d'effort il faut pour changer. Cette page ne promet pas d'éliminer ce coût. Elle montre où il se loge, et comment le réduire.

Où se loge le verrouillage

Les documentations lues le 15/11/2026 montrent que les éditeurs ne décrivent pas les outils de la même façon. Trois exemples :

• Anthropic déclare un outil avec name, description et input_schema, qui est un schéma JSON ; le modèle renvoie un bloc tool_use, et l'application répond par un bloc tool_result.
• Mistral déclare un outil avec type égal à "function", puis une clé function contenant name, description et parameters, et appelle client.chat.complete(...) avec tools et tool_choice.
• Google, dans son SDK Python, déclare les fonctions avec types.FunctionDeclaration, les regroupe dans types.Tool, et lit response.function_calls, ou laisse le SDK appeler lui-même une fonction Python passée en paramètre.

Ces trois formes décrivent la même chose : un outil, ses paramètres, et un appel. Un code qui mélange la déclaration de l'outil, sa logique et l'appel au fournisseur doit être réécrit à chaque changement. C'est là que se loge le verrouillage. La même remarque vaut pour les messages, les réglages de génération et les sorties structurées.

Pour les sorties structurées, la validation peut au contraire ne pas dépendre du fournisseur. Pydantic génère un JSON Schema à partir d'un modèle et le valide ensuite : ce schéma se réutilise d'un fournisseur à l'autre, dans la mesure où chaque fournisseur accepte le sous-ensemble utilisé. Voir sorties structurées avec Pydantic.

Une couche d'abstraction dans votre code

La méthode la plus sûre tient en une règle : un seul endroit du code appelle les modèles. Cette couche expose des fonctions de votre métier (résumer un document, extraire un contrat, répondre à un client) et non des appels aux SDK. Derrière, un adaptateur par fournisseur traduit les formats.

Concrètement :

1. définir les messages et les outils dans un format interne à votre projet ;
2. écrire un adaptateur par fournisseur, qui traduit ce format vers le SDK officiel et renvoie les réponses dans votre format ;
3. tester chaque adaptateur sur le même jeu d'exemples ;
4. garder la logique métier hors des adaptateurs.

Anthropic suggère de commencer par appeler directement les API. La même prudence s'applique à la couche d'abstraction : elle doit rester courte. Une abstraction trop épaisse masque les messages réellement envoyés, ce qui complique le débogage. Anthropic le signale à propos des frameworks en général.

Les bibliothèques à interface commune

Plusieurs bibliothèques offrent déjà une interface commune. Le AI SDK de Vercel parle d'une interface unifiée : il indique qu'elle permet de changer de fournisseur « while using the same API for all providers », avec des paquets par fournisseur (@ai-sdk/openai, @ai-sdk/anthropic, @ai-sdk/google, @ai-sdk/mistral). LangChain propose des intégrations de fournisseurs installées par extras, et create_agent pour la boucle d'agent. Haystack découpe ses pipelines en composants réutilisables. Chacune de ces options réduit le coût de changement, mais déplace la dépendance vers la bibliothèque. Voir le comparatif.

Les couches compatibles

Certains fournisseurs proposent une adresse compatible avec le format d'une autre API. Elle permet de changer de modèle sans réécrire le code, mais avec des limites : des champs peuvent être ignorés sans erreur, et des fonctions de l'éditeur ne passent pas toujours. Le détail, avec l'exemple et les limites relevées sur les pages des éditeurs, est dans changer de modèle sans réécrire son code. Cette voie convient à un test ou à une comparaison ; elle ne remplace pas une couche écrite dans votre code pour un usage de production.

Ce qui reste à vérifier

Aucune de ces solutions ne rend un projet interchangeable par magie. Il faut en plus :

• un jeu de test à soi, avec les réponses attendues, pour mesurer un changement de modèle ;
• une liste des fonctions propres au fournisseur utilisé (cache, sorties strictes, outils serveur) et leur coût de remplacement ;
• une surveillance des conditions du fournisseur : tarifs, lieu de traitement des données, durée de vie des modèles ;
• une sortie prévue : qui fait quoi si le fournisseur change de conditions, et combien de temps prend le passage.

Pour la question préalable, savoir si une bibliothèque est nécessaire, lire framework ou appel direct à l'API. Et pour juger une bibliothèque, la grille de juger la maintenance d'un framework.