L'IA devait donner un avantage aux entreprises. Elle peut aussi créer une nouvelle dépendance
Il y a encore quelques années, la discussion sur le vendor lock-in concernait principalement le cloud, les systèmes ERP, les bases de données ou les plateformes technologiques clés.
Les entreprises se posaient des questions : Pouvons-nous déplacer l'application vers un autre fournisseur cloud ? Pouvons-nous changer de base de données ? Pouvons-nous nous éloigner d'un système particulier ?
Aujourd'hui, un nouvel élément s'ajoute à cette liste : l'intelligence artificielle.
Les organisations construisent de plus en plus de systèmes utilisant des modèles de langage, de l'IA générative, des solutions RAG, l'automatisation des processus et des agents IA. Les modèles deviennent partie intégrante des applications, des processus commerciaux, du support client, de l'analyse documentaire, des systèmes décisionnels et du travail quotidien des équipes.
En pratique, cela signifie que l'entreprise peut commencer à dépendre non seulement d'un logiciel spécifique, mais aussi du fournisseur de l'intelligence utilisée par ses systèmes.
Et c'est là que se pose le problème. Car utiliser un service d'IA n'est pas la même chose qu'en devenir dépendant.
C'est précisément la différence entre une dépendance technologique assumée et le vendor lock-in.
Qu'est-ce que le vendor lock-in en IA ?
Vendor lock-in signifie une situation où une organisation est si étroitement liée à un fournisseur de technologie qu'un passage à une solution concurrente devient difficile, coûteux, long ou risqué.
Dans le monde de l'IA, cela peut prendre beaucoup plus de formes que la dépendance classique à une API unique.
Une entreprise peut être dépendante de :
- d'un modèle d'IA spécifique,
- d'un fournisseur d'API particulier,
- d'un format de communication défini,
- d'une fonctionnalité disponible uniquement chez un fournisseur,
- d'un système d'agents,
- d'une infrastructure cloud,
- d'une méthode de stockage des données,
- d'un mécanisme d'embeddings spécifique,
- d'un système RAG particulier,
- d'une manière d'appeler des outils par les agents,
- de prompts optimisés pour un modèle donné,
- des compétences d'une équipe liées à un seul écosystème.
Donc la question : « Utilisons‑nous OpenAI ? »
est bien trop simple.
Une meilleure question est : « À quel point serait-il difficile pour nous de changer de fournisseur d'IA si nous devions le faire dans six mois ? »
Si la réponse est : « Nous ne savons pas. » - c'est peut‑être un premier signal d'alerte.
OpenAI, Anthropic, Google – le choix du fournisseur a‑t‑il de l'importance ?
Aujourd'hui, plusieurs écosystèmes puissants de modèles et de services IA coexistent sur le marché, notamment les offres d'OpenAI, d'Anthropic et de Google.
Chacun de ces fournisseurs développe ses propres modèles, API, outils et services complémentaires.
Le problème n'est pas qu'un d'entre eux soit « mauvais ». Bien au contraire.
Utiliser des modèles prêts à l'emploi et de haute qualité est souvent la meilleure décision commerciale. Toutes les entreprises ne devraient pas entraîner leur propre modèle. Toutes n'ont pas besoin d'infrastructure GPU. Toutes ne devraient pas reconstruire la pile IA de zéro.
Faire appel à un fournisseur externe permet d'arriver plus vite sur le marché, de réduire les coûts initiaux et de bénéficier d'une technologie dont le développement en interne serait hors de portée pour la plupart des organisations.
Le problème apparaît lorsque l'entreprise cesse de considérer le fournisseur comme un composant interchangeable et conçoit tout le produit comme si le fournisseur choisi resterait inchangé pendant dix ans.
Et cela ne peut pas être garanti...
Les modèles sont mis à jour, les versions anciennes sont retirées, les prix changent, les limites évoluent, les API changent, de nouveaux modèles apparaissent, les conditions de licence évoluent, la concurrence change.
C'est une partie normale du marché technologique.
C'est pourquoi l'architecture IA doit considérer non seulement : « Quel modèle est le meilleur aujourd'hui ? »
mais aussi : « Quel sera le coût si dans un an nous voulons en utiliser un autre ? »
La plus grande illusion – « on changera juste l'API »
À première vue, la migration peut sembler banale.
Nous avons une application. L'application envoie une requête au modèle. Le modèle répond. On change de fournisseur. Voilà...
En réalité, la situation peut être complètement différente.
Imaginez une application développée pendant deux ans autour d'un modèle unique.
Pendant ce temps, l'équipe a :
- créé des centaines de prompts,
- optimisé leur contenu,
- ajusté le format des réponses,
- construit un système RAG,
- configuré le tool calling,
- créé des agents,
- conçu des workflows,
- préparé des tests,
- formé les utilisateurs au fonctionnement du système.
Après deux ans, il s'avère que le modèle n'est plus disponible sous sa forme précédente.
Ou son prix augmente, ou un modèle concurrent est nettement supérieur, ou l'entreprise souhaite déplacer une partie des données vers un autre environnement.
Théoriquement, il suffirait de changer l'API. – en pratique, il peut s'avérer qu'il faille retester toute la logique du système.
Pourquoi ?
Parce que les modèles ne sont pas identiques :
- Ils diffèrent dans l'interprétation des instructions.
- Ils diffèrent par la qualité des réponses.
- Ils diffèrent dans le comportement sur de longs contextes.
- Ils diffèrent dans l'utilisation des outils.
- Ils diffèrent dans la gestion des outputs structurés.
- Ils diffèrent dans la multimodalité.
- Ils diffèrent par la latence.
- Ils diffèrent par le prix.
- Ils diffèrent également dans les comportements aux limites.
Ainsi, migrer entre modèles peut ressembler davantage à la migration d'un composant métier entier qu'à un simple changement d'URL.
Cinq niveaux de vendor lock-in en IA
Il vaut la peine d'envisager le vendor lock-in plus largement.
1. Lock‑in du modèle
Le niveau le plus basique.
L'application a été optimisée pour un modèle spécifique.
Un prompt fonctionne très bien avec un modèle, mais moins bien avec un autre.
Le système repose sur des capacités propres à ce modèle.
Changer implique de recalibrer.
2. Lock‑in de l'API
Le système utilise directement des fonctionnalités d'un fournisseur particulier.
Plus nous utilisons de fonctions spécifiques, plus la migration peut être difficile.
Il ne s'agit pas seulement de génération de texte.
Sont également importants :
- les outputs structurés,
- le function calling,
- le tool calling,
- la multimodalité,
- la gestion du contexte,
- les mécanismes de sécurité,
- les systèmes d'agents.
3. Lock‑in des données
Les données peuvent être stockées d'une manière fortement liée à un écosystème donné.
Cela concerne aussi :
- les embeddings,
- les index vectoriels,
- les métadonnées,
- l'historique des interactions,
- la configuration RAG.
La migration peut nécessiter non seulement le transfert des données, mais aussi leur retraitement.
4. Lock‑in de l'architecture
C'est un niveau beaucoup plus sérieux.
Toute l'application a été conçue autour d'un fournisseur unique.
Ses mécanismes sont présents dans de nombreux endroits du système.
Dans ce cas, on ne remplace pas un seul composant.
On reconstruit une partie de l'architecture.
5. Lock‑in organisationnel
C'est souvent le problème le moins évalué.
L'équipe connaît un seul écosystème.
Toutes les compétences sont centrées sur une seule solution.
Documentation, procédures, tests et savoir-faire sont liés à un fournisseur unique.
Même si techniquement on peut changer de modèle, l'organisation n'a pas les personnes capables d'effectuer ce changement.
Et alors le vendor lock-in cesse d'être uniquement un problème technologique.
Il devient un problème commercial.
Le multi‑model résout‑il le problème ?
La réponse instinctive est : « Puisqu'un fournisseur est un risque, utilisons plusieurs. »
Ce n'est toutefois pas toujours la meilleure stratégie.
L'architecture multi‑modèle a ses coûts.
Il faut gérer :
- plusieurs API,
- des limites différentes,
- des modèles de tarification différents,
- des niveaux de qualité différents,
- des formats de réponse variés,
- des tests,
- du monitoring,
- la sécurité.
Le système devient plus complexe.
L'objectif ne devrait pas être : « Nous devons utiliser cinq fournisseurs. »
L'objectif devrait être : « Nous devons être capables de changer de fournisseur si le business en a besoin. »
C'est la différence essentielle.
Toutes les entreprises n'ont pas besoin du Multi‑Model.
Chaque entreprise devrait cependant savoir à quoi ressemblerait une migration vers un autre modèle.
AI Gateway et Model Gateway – une couche qui sépare l'application du fournisseur
Une façon de réduire la dépendance est d'utiliser une couche intermédiaire.
Elle peut jouer le rôle d'AI Gateway ou de Model Gateway.
Schématiquement, l'architecture peut ressembler à ceci :
Application métier
↓
Couche d'abstraction IA
↓
Routage des modèles
↓
Adaptateur fournisseur
↓
OpenAI / Anthropic / Google / modèle open‑weight / modèle local
Ainsi la logique métier de l'application n'a pas à connaître directement les détails de chaque fournisseur.
On peut disposer d'une couche responsable de :
- la sélection du modèle,
- le routage,
- le fallback,
- le contrôle des coûts,
- le monitoring,
- la journalisation,
- les politiques de sécurité,
- la gestion des limites.
En cas de panne d'un fournisseur, le système peut tenter d'utiliser un autre modèle.
En cas d'augmentation des prix, on peut modifier le routage.
À l'apparition d'un meilleur modèle, on peut effectuer des tests et décider d'une migration.
Cela ne garantit pas que le changement sera indolore.
Cela signifie toutefois qu'il a été conçu comme une possibilité réelle.
Model Router – l'IA n'a pas à choisir toujours le même modèle
Une solution encore plus intéressante est le routage par modèle.
Imaginez un système qui reçoit des tâches variées.
Une tâche simple : « Résume ce texte. »
Peut être envoyée à un modèle rapide et économique.
Une tâche plus complexe : « Analyse ce document et prépare une recommandation détaillée. »
Peut être traitée par un modèle plus puissant.
Une tâche nécessitant l'analyse d'images peut être dirigée vers un modèle multimodal.
Le système peut donc sélectionner dynamiquement le modèle adapté à chaque tâche.
Cela permet d'optimiser :
- les coûts,
- la qualité,
- les temps de réponse,
- la disponibilité.
Dans ce modèle, le fournisseur d'IA cesse d'être une partie intégrante de la logique métier.
Il devient un composant d'infrastructure parmi d'autres.
Et c'est un changement architectural très important.
L'abstraction ne signifie pas que tous les modèles sont identiques
Ici il faut se garder d'une illusion.
On peut créer sa propre fonction : generateText() et penser que le problème est résolu.
Il ne l'est pas.
Les modèles ne sont pas des briques LEGO interchangeables.
Si l'application utilise des capacités spécifiques d'un modèle, une simple abstraction peut juste cacher le problème.
Une bonne architecture devrait abstraire le fournisseur, mais en même temps gérer consciemment les différences entre modèles.
Concrètement, la couche IA doit savoir qu'un modèle peut avoir des :
- capacités différentes,
- limites,
- coûts,
- niveaux de qualité,
- fonctionnalités,
- contextes,
- paramètres.
Ainsi, concevoir un système « provider‑agnostic » ne signifie pas prétendre que tous les modèles sont identiques.
Cela signifie que le système sait tirer parti consciemment des différences entre modèles.
Evals – sans eux la migration IA est de la conjecture
Un des éléments les plus importants d'une architecture résistante au changement sont les evals, c'est‑à‑dire des tests systématiques de la qualité des modèles.
Supposons que nous ayons 1000 cas d'usage réels. Nous les exécutons sur le modèle actuel. Ensuite sur le nouveau. Nous comparons les résultats.
On vérifie :
- la qualité,
- la justesse,
- l'exhaustivité,
- les hallucinations,
- la conformité aux exigences,
- le temps de réponse,
- le coût.
Ce n'est qu'à ce moment qu'on peut dire : « Le nouveau modèle est suffisamment bon. »
Sans evals la migration ressemble à une expérimentation. Avec des evals elle devient un processus d'ingénierie.
C'est pourquoi une entreprise utilisant l'IA devrait construire ses propres corpus de test. Pas seulement tester l'API, mais tester son cas d'usage métier. C'est une différence majeure.
Le prompt peut aussi être une source de vendor lock-in
On traite souvent les prompts comme du texte. En pratique, ils peuvent devenir un élément de la logique métier.
Si pendant des mois l'équipe optimise des instructions pour un modèle donné, le prompt peut commencer à agir comme un morceau de code.
Il devrait donc être :
- versionné,
- testé,
- documenté,
- monitoré.
Il est aussi utile de savoir quels prompts sont critiques pour le fonctionnement du système. Si un changement de modèle dégrade leur efficacité, il faut savoir où chercher le problème.
Ainsi, le prompt engineering, dans des systèmes mûrs, doit être de plus en plus traité comme une pratique d'ingénierie logicielle.
Open‑weight et modèles internes – est‑ce une fuite au vendor lock‑in ?
Les modèles open‑weight et la possibilité d'exécuter des modèles sur sa propre infrastructure augmentent le contrôle technologique.
Mais cela ne signifie pas automatiquement une indépendance totale.
Si l'on déplace un modèle sur sa propre infrastructure, il faut toujours :
- des GPU,
- de l'infrastructure,
- du MLOps,
- du monitoring,
- de la sécurité,
- des mises à jour,
- des compétences.
On peut réduire la dépendance au fournisseur du modèle, mais accroître la dépendance au fournisseur d'infrastructure. On peut aussi exécuter des modèles open‑weight dans le cloud. Dans ce cas, le problème réapparaît à un autre niveau. Il faut donc considérer l'indépendance technologique de manière plus large.
Il n'existe pas de système totalement dépourvu de dépendances.
Il existe en revanche un système où les dépendances sont :
- connues,
- contrôlées,
- mesurables,
- remplaçables.
Le vendor lock‑in le plus dangereux peut être dans la tête de l'équipe
Imaginez une entreprise qui utilise un seul fournisseur d'IA.
Techniquement elle peut changer de modèle. Mais personne dans l'entreprise ne sait comment le faire.
L'équipe ne connaît pas les alternatives.
Il n'y a pas de benchmarks.
Pas d'evals.
Pas de tests.
Pas d'expérience avec d'autres modèles.
Toutes les solutions ont été construites autour d'un seul écosystème.
C'est le lock‑in organisationnel.
C'est pourquoi la résistance au vendor lock‑in nécessite aussi d'investir dans les compétences.
L'équipe doit comprendre :
- comment fonctionnent les modèles,
- quelles sont les différences entre fournisseurs,
- comment construire une couche d'abstraction,
- comment tester les modèles,
- comment mesurer la qualité,
- comment gérer les coûts,
- comment mener une migration.
Il ne s'agit pas que chaque développeur connaisse chaque API.
Il s'agit d'empêcher que l'organisation devienne technologiquement aveugle en dehors d'un seul écosystème.
Quand le vendor lock‑in peut‑il être acceptable ?
Le vendor lock‑in n'est pas toujours mauvais.
Parfois une dépendance assumée est une décision commerciale raisonnable.
Si :
- le fournisseur offre une fonctionnalité exceptionnelle,
- la solution réduit fortement le time‑to‑market,
- le coût de migration est connu,
- le risque est acceptable,
- les alternatives sont moins performantes,
- le business a besoin de rapidité,
alors un lien fort avec un fournisseur peut être justifié.
Le problème n'est pas le lock‑in en soi. Le problème est le lock‑in inconscient.
L'entreprise doit savoir :
- dont elle dépend,
- pourquoi elle en dépend,
- combien coûterait le changement,
- combien de temps durerait la migration,
- quelles sont les alternatives.
Ce n'est qu'ensuite qu'on peut parler d'une décision architecturale consciente.
Comment évaluer le vendor lock‑in IA dans votre entreprise ?
Il vaut la peine de réaliser un audit simple.
Posons‑nous les questions suivantes :
Pouvons‑nous changer de modèle sans reconstruire toute l'application ?
La logique métier est‑elle indépendante du fournisseur d'IA ?
Les prompts sont‑ils versionnés ?
Avons‑nous nos propres evals ?
Avons‑nous des tests de régression pour les cas d'usage critiques ?
Pouvons‑nous exporter et déplacer nos données ?
Pouvons‑nous changer de fournisseur d'embeddings sans perdre les données ?
Les agents utilisent‑ils une couche d'orchestration ou sont‑ils liés directement à un écosystème ?
A‑t‑on la possibilité d'utiliser un modèle alternatif ?
Avons‑nous un fallback ?
Savons‑nous combien coûterait la migration ?
Savons‑nous combien de temps durerait la migration ?
Avons‑nous des personnes capables de la mener ?
Plus il y a de réponses « non », plus la dépendance est grande.
Vous pouvez aussi créer votre propre AI Portability Score. Par exemple évaluer l'organisation sur cinq domaines :
Architecture – le fournisseur est‑il interchangeable ?
Données – peut‑on les déplacer ?
Modèles – avons‑nous des alternatives ?
Évaluation – savons‑nous comparer les modèles ?
Compétences – l'équipe sait‑elle mener une migration ?
Ce score n'a pas besoin d'être une norme formelle. Il peut cependant être un très bon outil de gouvernance.
Car parfois le problème n'est pas le vendor lock‑in lui‑même. Le vrai problème est que l'entreprise ignore qu'elle en est victime.
Comment concevoir une architecture IA résistante au changement ?
Il n'existe pas d'architecture universelle. On peut toutefois appliquer quelques règles pratiques.
Règle 1 - séparez la logique métier du fournisseur d'IA
Ne concevez pas tout le système directement autour d'une API unique.
Règle 2 - utilisez une couche d'abstraction lorsque cela a du sens
Un AI Gateway ou Model Gateway peut réduire la dépendance de l'application vis‑à‑vis d'un fournisseur spécifique.
Règle 3 - versionnez les prompts
Traitez‑les comme un élément du système, pas comme des textes lâches.
Règle 4 - construisez des evals
Ne supposez pas que « le nouveau modèle fonctionne ».
Vérifiez‑le.
Règle 5 - testez les alternatives
Vous n'avez pas besoin de les utiliser en production.
Mais il est utile de savoir comment elles se comportent sur vos cas d'usage.
Règle 6 - contrôlez les données
Ne laissez pas vos données métier devenir otages d'une seule plateforme.
Règle 7 - documentez les dépendances
Savoir où le système dépend d'un fournisseur fait partie de la documentation architecturale.
Règle 8 - n'abstrayez pas à tout prix
Ne masquez pas les différences entre modèles juste pour obtenir une portabilité apparente.
Règle 9 - mesurez le coût de la migration
Il ne suffit pas de dire :
« On pourra changer de fournisseur un jour. »
Il faut savoir :
« Cela nous prendra trois mois et cinq personnes. »
Ou :
« Nous ne pouvons pas le faire sans reconstruire le système. »
Règle 10 - prenez des décisions en connaissance de cause
Parfois la meilleure solution est un fort engagement envers un fournisseur.
Mais cela doit être un risque assumé consciemment.
Pas un accident.
La question que tout CTO devrait poser
Imaginez que demain le fournisseur d'IA :
- double ses prix,
- retire le modèle que nous utilisons,
- change les limites,
- restreigne une fonction dont dépend notre produit,
- cesse de satisfaire nos exigences de conformité.
Que faisons‑nous ?
Si la réponse est : « Nous changerons de fournisseur. »
La question suivante devrait être : « Combien de temps cela nous prendrait‑il ? »
Un jour ?
Une semaine ?
Un mois ?
Six mois ?
Ou peut‑être ne le savons‑nous pas ?
C'est précisément la mesure de notre résilience technologique.
Conclusion - il ne s'agit pas de ne pas avoir de fournisseur
Construire un système entièrement indépendant des fournisseurs d'IA externes peut être coûteux, inutile ou même impossible.
Ce n'est pas l'objectif.
L'objectif n'est pas l'absence de dépendance. L'objectif est la gestion consciente des dépendances.
Nous pouvons utiliser OpenAI. Nous pouvons utiliser Anthropic. Nous pouvons utiliser Google. Nous pouvons utiliser des modèles open‑weight. Nous pouvons combiner différentes solutions.
L'essentiel est de savoir où se situe la frontière entre : « nous utilisons la technologie » et « nous en dépendons ».
Dans le monde de l'IA cette frontière peut être particulièrement difficile à discerner. Le vendor lock‑in ne se crée pas en un jour. Il se construit progressivement. D'abord on intègre une API. Puis on construit une fonctionnalité. Puis on ajoute le RAG. Puis les agents. Puis on automatise le processus. Puis toute l'équipe commence à travailler selon ce système. Et soudain il apparaît que changer de modèle n'est plus un simple changement technique : c'est un changement d'une partie de l'organisation.
C'est pourquoi l'architecture IA doit être conçue en pensant non seulement à ce qui fonctionne aujourd'hui, mais aussi à ce qui se passera si le monde technologique change demain.
Vous n'avez pas besoin de construire un système qui fonctionne sans OpenAI, Anthropic ou Google. Vous devriez cependant construire un système capable de fonctionner aussi si l'un d'eux venait à manquer.
Voilà la vraie différence entre utiliser l'IA et concevoir l'IA de manière consciente.
