Le piège du fournisseur unique
Le « vendor lock-in » — la dépendance technologique et financière envers un seul fournisseur — est un risque bien connu dans le monde du logiciel. Avec l'IA, il prend une forme particulière. L'écosystème des modèles de langage évolue à une vitesse sans précédent : de nouveaux modèles, de nouveaux fournisseurs, de nouvelles grilles tarifaires apparaissent chaque mois. Ce qui est le meilleur choix technique aujourd'hui ne le sera peut-être plus dans six mois.
Les chiffres compilés par Swfte AI dans leur analyse de janvier 2026 donnent une idée de l'ampleur du sujet : 67 % des organisations déclarent vouloir éviter une forte dépendance envers un seul fournisseur d'IA, et 45 % estiment que le vendor lock-in les a déjà empêchées d'adopter de meilleurs outils. Côté coûts, une migration forcée de plateforme génère en moyenne 315 000 $ de pertes par projet — sans compter les mois d'immobilisation des équipes techniques.
Le cas de Builder.ai est édifiant : cette plateforme d'IA, autrefois valorisée à 1,3 milliard de dollars et soutenue par Microsoft, a fait faillite en 2025. Les entreprises clientes se sont retrouvées bloquées, incapables d'accéder à leurs systèmes ou à leurs données. Certaines ont dû dépenser des centaines de milliers de dollars pour migrer en urgence leurs workflows IA vers d'autres plateformes.
Ce que ça signifie pour une PME
Le risque est proportionnellement le même, voire plus grand. Une grande entreprise a les ressources pour absorber une migration forcée. Une PME qui a construit un processus métier critique autour d'un seul fournisseur — un chatbot de support client sur une API propriétaire, un système de tri de documents qui dépend d'un modèle spécifique — peut se retrouver dans une impasse si ce fournisseur change de cap. La question n'est pas « si » ça arrivera, mais « quand ».
La couche d'abstraction : ne jamais parler directement au modèle
La première parade technique est de ne jamais coupler votre code applicatif directement à l'API d'un fournisseur de modèle. À la place, on interpose une couche intermédiaire — une passerelle (« gateway ») — qui traduit les requêtes dans un format unifié.
TrueFoundry, reconnu dans le Gartner Market Guide 2025 pour les AI Gateways, décrit bien le principe : une passerelle IA accepte les requêtes de votre application dans un format standardisé, puis les route vers le fournisseur approprié — OpenAI, Anthropic, un modèle auto-hébergé, ou tout autre service intégré — sans que le code applicatif ait besoin de connaître les spécificités de chaque API. Changer de modèle revient à modifier une ligne de configuration, pas à réécrire l'application.
Le développeur Kamil Lobinski a formalisé cette approche dans ce qu'il appelle une « architecture model-agnostic ». Son idée : chaque modèle est décrit par une fiche standardisée (un « descripteur universel ») qui recense ses caractéristiques — identifiant, plateforme d'accès, modalités d'entrée/sortie, paramètres supportés, contraintes. L'application ne dialogue jamais avec un modèle spécifique ; elle consulte un registre central de modèles, et le système choisit le plus adapté en fonction de la tâche, du coût ou de la disponibilité.
En pratique, plusieurs outils rendent cette approche accessible même pour des projets de taille modeste : LiteLLM (un proxy open-source qui unifie plus de 100 fournisseurs derrière une seule interface compatible OpenAI), ou encore des orchestrateurs comme n8n qui permettent de configurer le modèle utilisé sans toucher au workflow.
Ce que ça signifie pour une PME
Si vous faites développer une solution IA, posez cette question dès le départ : « Peut-on changer de modèle sans réécrire le code ? » Si la réponse est non, ou si elle est floue, c'est un signal d'alerte. L'abstraction du modèle n'est pas un luxe architectural — c'est une assurance. Le surcoût initial est minime (quelques heures de travail), mais le gain en cas de migration est considérable.
L'architecture modulaire : chaque brique doit être remplaçable
L'abstraction du modèle est une première étape, mais elle ne suffit pas. Une solution IA typique comporte plusieurs composants : le modèle d'inférence, mais aussi une base de données vectorielle (pour le RAG), un orchestrateur de workflows, des connecteurs vers les outils métier, un système de gestion des prompts. Si tous ces composants sont imbriqués dans un bloc monolithique, changer l'un d'entre eux revient à tout reconstruire.
SparkCo, dans son guide sur l'indépendance technologique en IA, recommande une architecture en micro-services — ou au minimum en composants faiblement couplés. Le principe : chaque brique technique (le modèle, la base vectorielle, l'orchestrateur) communique avec les autres via des interfaces standardisées, et peut être remplacée ou mise à jour indépendamment. C'est le pattern « adapter » appliqué à l'IA : l'application ne connaît que l'interface, pas l'implémentation.
Concrètement, pour un système RAG par exemple, ça implique que la base de données vectorielle (Qdrant, Pinecone, Chroma…) est interchangeable derrière une couche d'abstraction, que le modèle d'embedding peut être remplacé sans modifier le pipeline de recherche, et que l'orchestrateur (n8n, LangChain, un script Python maison) est découplé du reste.
Ce que ça signifie pour une PME
Vous n'avez pas besoin de bâtir une architecture micro-services complète avec Kubernetes. L'essentiel est le principe de découplage : chaque composant doit être identifiable et remplaçable. Quand votre prestataire vous livre un système, vous devez pouvoir répondre à la question « si je veux remplacer la base vectorielle, qu'est-ce que je dois modifier ? ». Si la réponse est « tout », c'est un problème de conception.
Les standards ouverts : le ciment de la réversibilité
Les couches d'abstraction et l'architecture modulaire sont des choix de conception. Mais pour qu'ils fonctionnent dans la durée, ils doivent s'appuyer sur des standards partagés — des protocoles que toute l'industrie adopte, plutôt que des formats propriétaires.
Le meilleur exemple récent est le Model Context Protocol (MCP). Lancé par Anthropic en novembre 2024 comme standard ouvert, MCP définit un protocole universel pour connecter les agents IA aux outils et sources de données externes. En un an, il est devenu un standard de fait : OpenAI l'a adopté en mars 2025, Google DeepMind en avril 2025, et en décembre 2025, Anthropic l'a transféré à l'Agentic AI Foundation, une entité sous la gouvernance de la Linux Foundation, avec parmi ses membres fondateurs OpenAI, Google, AWS, Bloomberg et Cloudflare. Résultat : plus de 5 800 serveurs MCP sont disponibles, et les téléchargements des SDK dépassent les 97 millions par mois.
Ce que MCP change concrètement : au lieu de développer un connecteur spécifique pour chaque combinaison modèle/outil (un problème qui croît de façon quadratique avec le nombre de composants), on développe un seul serveur MCP pour chaque outil, et n'importe quel client compatible peut s'y connecter. Comme le résume Thoughtworks, MCP a joué un rôle clé dans l'accélération de l'IA agentique en rendant possible la connexion d'agents à de multiples sources de données sans investissement technique lourd.
Au-delà de MCP, d'autres standards méritent attention : ONNX (Open Neural Network Exchange) pour la portabilité des modèles entre frameworks, et le format OpenAI-compatible pour les API de chat, devenu un standard de facto que la plupart des fournisseurs (y compris ceux qui ne sont pas OpenAI) supportent.
Ce que ça signifie pour une PME
Quand vous évaluez un outil ou un prestataire, vérifiez s'il utilise des standards ouverts ou des formats propriétaires. Un système qui communique via MCP, qui stocke ses embeddings dans un format standard, qui expose une API compatible OpenAI, est un système que vous pourrez faire évoluer. Un système qui utilise des formats ou protocoles maison est un système qui vous lie à son créateur.
Le test du modèle local : reprendre le contrôle quand nécessaire
Un avantage direct de l'architecture réversible : la possibilité de basculer certaines tâches vers des modèles open-source exécutés localement. Des outils comme Ollama permettent de faire tourner des modèles performants (Llama, Mistral, Gemma) directement sur un serveur interne, sans envoyer de données vers le cloud.
C'est particulièrement pertinent pour les tâches qui impliquent des données sensibles — contrats, données financières, informations personnelles des clients. Plutôt que de faire transiter ces données par l'API d'un fournisseur externe (avec les questions de confidentialité et de souveraineté que ça pose), vous les traitez en local. Et si votre architecture est modulaire, cette bascule se fait sans modifier le reste du système.
Comme le note Swfte AI, 84 % des organisations intègrent désormais la souveraineté numérique dans leur stratégie IA. Ce n'est plus un sujet réservé aux grandes entreprises réglementées — c'est devenu un critère de choix pour tout projet qui manipule des données métier.
Ce que ça signifie pour une PME
Vous n'avez pas besoin de tout faire tourner en local. Mais votre architecture doit le permettre pour les cas où c'est nécessaire. La combinaison typique qui fonctionne bien : un modèle cloud performant (Claude, GPT) pour les tâches générales, et un modèle local via Ollama pour les tâches sensibles — le tout derrière une passerelle qui route les requêtes selon le contexte.
Ce qu'il faut retenir
La réversibilité n'est pas un luxe technique — c'est ce qui garantit que votre investissement IA conserve sa valeur dans le temps. Voici les principes à retenir :
Ne couplez jamais votre logique métier à une API spécifique. Interposez toujours une couche d'abstraction entre votre application et le fournisseur du modèle. Changer de modèle doit être une opération de configuration, pas de réécriture.
Concevez chaque composant comme remplaçable. Le modèle, la base vectorielle, l'orchestrateur, les connecteurs — chacun doit être identifiable et interchangeable. Le pattern adapter est votre allié.
Privilégiez les standards ouverts. MCP pour les connexions aux outils, le format OpenAI-compatible pour les API, ONNX pour la portabilité des modèles. Les standards partagés sont la meilleure protection contre l'enfermement propriétaire.
Gardez la porte ouverte au local. Votre architecture doit permettre de basculer certaines tâches vers des modèles auto-hébergés quand la confidentialité ou le coût l'exigent.
Un projet IA qui ne fonctionne qu'avec un seul fournisseur n'est pas un actif de l'entreprise — c'est une dépendance. Un projet IA réversible est un projet qui reste sous votre contrôle, quel que soit l'évolution du marché.
Sources
- Breaking Free: How Enterprises Are Escaping AI Vendor Lock-in in 2026 — Swfte AI
- Vendor Lock-In Prevention with TrueFoundry's AI Gateway — TrueFoundry
- Model-Agnostic Architecture — Kamil Lobinski
- Enterprise Guide to Avoiding Vendor Lock-In in AI Development — SparkCo
- The Model Context Protocol's impact on 2025 — Thoughtworks