Dépendance fournisseur en IA : 7 réflexes pour ne pas vous retrouver pieds et poings liés

Le piège qui se referme sans bruit

Imaginez la scène. Il y a 14 mois, votre équipe a branché une IA générative sur votre support client. Le projet a livré vite, l'usage a décollé, vos conseillers gagnent 35 % de temps sur les réponses standards. Vous êtes fier du résultat, et à juste titre.

Aujourd'hui, votre fournisseur change ses conditions tarifaires. Le coût mensuel triple. Quand vous regardez ce qu'il faudrait pour passer à un concurrent, vous tombez sur la mauvaise surprise : tout le système — la logique métier, les prompts, les connecteurs, la mémoire des conversations — a été écrit pour cette plateforme. Migrer ne veut plus dire changer un outil. Ça veut dire refaire le projet, en plus dur, sans pouvoir l'arrêter parce qu'il tourne déjà en production.

Cette situation, on la voit déjà chez plusieurs PME et ETI françaises. Pas parce qu'elles ont mal choisi leur fournisseur initial, mais parce que personne n'avait anticipé le coût de sortie. Le piège du lock-in IA est silencieux : il se met en place mois après mois, et il devient visible au pire moment.

Cet article passe en revue où ce piège se cache, pourquoi il est plus difficile à défaire qu'un changement de logiciel classique, et donne 7 réflexes concrets pour rester libre de changer demain — sans payer ce que vous n'avez pas voulu payer aujourd'hui.

Pourquoi votre IA d'aujourd'hui devient le piège de demain

Tant que vous êtes en phase pilote, tout est réversible. Vous testez un modèle, un autre, une autre plateforme. Si ça ne marche pas, vous jetez. Personne ne dépend de la décision.

Le basculement se fait au moment où un cas d'usage entre en production. Du jour au lendemain, une décision métier dépend du modèle. Un agent IA répond à vos clients sans passer par un humain. Une partie de votre back-office est tributaire d'une API que vous ne contrôlez pas. À ce moment-là, le moindre changement chez votre fournisseur — mise à jour de modèle, hausse tarifaire, conditions d'usage, suppression d'une fonctionnalité — devient un risque opérationnel.

Et ce risque arrive vite. Le marché de l'IA bouge plus vite que les cycles de décision d'une PME. Un modèle de référence aujourd'hui peut être dépassé dans 9 mois. Un fournisseur leader peut perdre 30 % de performance face à un nouveau venu. Une plateforme peut modifier ses prix unilatéralement. Si votre architecture vous oblige à tout reconstruire pour vous adapter, vous n'avez plus le luxe de saisir les opportunités du marché.

La bonne nouvelle, c'est qu'il existe quelques principes simples pour ne pas tomber dans le piège. Et ils n'exigent pas d'être DSI d'un CAC 40 pour les appliquer.

Les 4 endroits où la dépendance s'installe sans qu'on la voie

Quand on parle de dépendance fournisseur, on pense d'abord au modèle. C'est trompeur : ce n'est jamais l'endroit le plus piégeux. Voici les 4 zones où le verrouillage se construit, en pratique.

Le modèle lui-même est en réalité la couche la plus facile à remplacer. Aujourd'hui, les grands LLM (Claude, GPT, Mistral, Gemini) se ressemblent fonctionnellement et offrent des API comparables. Changer de modèle est faisable en quelques semaines pour la plupart des cas d'usage — à condition que le reste soit propre.

L'orchestration et les workflows sont l'endroit où le lock-in fait le plus mal. Si vous avez construit vos enchaînements — un agent qui qualifie un lead, demande des compléments, déclenche une action dans le CRM — sur une plateforme propriétaire, vous êtes lié à cette plateforme. La logique métier que vous y avez injectée n'est pas exportable. Migrer, c'est tout réécrire.

La couche données — les embeddings, les index vectoriels, les pipelines RAG — encapsule souvent des mois de travail sur votre patrimoine documentaire. Si ces données vivent dans un format propriétaire ou un service qu'on ne peut pas exporter, recommencer ailleurs coûte presque aussi cher que le projet initial. C'est l'un des coûts cachés les plus systématiquement sous-estimés.

La mémoire métier, enfin, est l'angle mort le plus pernicieux. Vos prompts affinés sur 6 mois, vos règles métier injectées au fil de l'eau, les garde-fous mis en place après chaque incident : tout ça vit souvent dans les configurations d'une plateforme, sans documentation propre. Le jour où vous voulez changer, vous découvrez qu'aucun cahier des charges ne décrit comment votre IA est vraiment censée se comporter. La connaissance opérationnelle a été absorbée par l'outil.

Pourquoi c'est plus piégeux qu'un changement de CRM

Vous avez déjà vécu un projet de changement de CRM. C'est long, coûteux, douloureux. Mais c'est prévisible. On exporte des contacts, des opportunités, des historiques. On les recharge dans le nouveau système. On retrain les utilisateurs. Trois à six mois de chantier, et c'est fait.

Avec une stack IA en production, ce n'est pas la même histoire. Trois différences majeures rendent la migration nettement plus risquée.

La valeur n'est pas dans les données, elle est dans le système. Sur un CRM, ce qui compte, ce sont les contacts et les historiques. Sur une stack IA, ce qui compte, c'est la manière dont vos agents, prompts, garde-fous et règles métier interagissent. Cette logique est souvent répartie entre 5 ou 6 endroits différents, et n'est presque jamais formalisée dans un document unique.

Le comportement change tout seul. Un CRM se comporte de la même manière du lundi au vendredi. Un système IA peut donner deux réponses différentes à la même question selon le contexte, et son comportement peut dériver après une simple mise à jour du modèle. Vous ne pouvez pas tester une migration comme vous testeriez un changement de logiciel classique. Il faut tester en continu, avec des jeux de données représentatifs, et accepter qu'il existe une bande d'incertitude irréductible.

Les coûts de sortie ne sont pas linéaires. Sur un SaaS traditionnel, migrer coûte à peu près 1× le projet initial. Sur une stack IA fortement intégrée, on observe des coûts de migration de 2 à 5× le projet initial, parce qu'il faut à la fois reconstruire la logique, retester en continu, et garantir la continuité de service pendant la transition. C'est cet écart qui crée l'effet de blocage.

Les 7 réflexes pour rester libre

Aucune de ces 7 décisions ne coûte cher à mettre en place dès le départ. Toutes changent radicalement votre marge de manœuvre à 18 mois.

1. Ne câblez jamais un modèle en dur dans votre code. Mettez systématiquement une couche d'abstraction entre votre application et le LLM. Concrètement, vos appels passent par votre propre service interne, qui décide quel modèle interroger. Le jour où vous voulez changer de fournisseur, vous modifiez ce service unique, pas 40 endroits dans l'application.

2. Documentez vos prompts comme du code. Versionnez-les dans un référentiel (Git, Notion, peu importe), avec leur date de dernière modification, leur intention, et les cas qu'ils couvrent. Sans ça, votre logique métier disparaît avec la personne qui les a écrits.

3. Exigez la portabilité des embeddings. Avant de signer avec un fournisseur de base vectorielle ou d'IA managée, posez la question : « Comment j'exporte mes vecteurs si je veux partir ? » Pas de réponse claire, pas de signature.

4. Maintenez en permanence un fournisseur secondaire. Pas par indécision, mais pour garder un point de comparaison. Faites passer 5 à 10 % de votre volume sur un modèle alternatif. Vous savez en temps réel si votre fournisseur principal dérive ou si un concurrent prend l'avantage. Et le jour où vous devez basculer, vous avez déjà toute la plomberie en place.

5. Anticipez les scénarios de panne. Posez-vous trois questions et écrivez les réponses : qu'est-ce qui se passe si l'API tombe pendant 4 heures ? Si le modèle se met à mal répondre sans qu'on s'en aperçoive ? Si le prix double demain matin ? Si vous n'avez pas de réponse claire à ces trois questions, vous les découvrirez dans la pire situation possible.

6. Mettez en place un jeu de tests stable. Construisez 30 à 100 questions représentatives de votre cas d'usage, avec la réponse attendue. Faites-les tourner chaque semaine, sur votre IA actuelle et sur 1 ou 2 alternatives. Vous détectez les régressions avant vos clients, et vous avez une base de comparaison objective quand un nouveau modèle sort sur le marché.

7. Mesurez le coût de sortie tous les 6 mois. Combien de jours-hommes pour migrer ailleurs aujourd'hui ? Combien dans 6 mois si l'on continue sur la trajectoire actuelle ? Si ce chiffre grossit, c'est que la dépendance s'installe. Mieux vaut s'en apercevoir avant que la facture n'arrive.

Vitesse de mise en route contre liberté future

Soyons honnêtes. Tout ce qui est décrit plus haut a un coût. Mettre une couche d'abstraction, maintenir un fournisseur secondaire, documenter, tester… c'est du travail en plus, qui ralentit la livraison initiale.

Le réflexe naturel d'une PME pressée par les résultats, c'est de dire : « On fait simple, on optimisera plus tard. » Cette logique est rationnelle à court terme. Le problème, c'est que ce « plus tard » coûte 3 à 5 fois plus cher que le « tout de suite ».

L'arbitrage, en pratique, ressemble à ceci. Pour un POC ou un cas d'usage isolé, foncez sans surinvestir dans l'architecture : si ça ne marche pas, vous jetez et la dépendance ne fait pas de mal. Pour un cas d'usage destiné à passer en production, prenez le temps d'appliquer les 7 réflexes ci-dessus — ça représente 10 à 20 % d'effort en plus au démarrage, et ça peut diviser par 5 votre coût de sortie au bout de 18 mois.

Le bon moment pour décider, ce n'est pas quand le piège se referme. C'est quand vous démarrez.

Ce qu'il faut retenir

Le lock-in IA n'est pas une crainte théorique : il s'installe à chaque déploiement, dans 4 endroits invisibles au démarrage (modèle, orchestration, données, mémoire métier). Il devient visible au moment où vous voulez bouger — c'est-à-dire au pire moment.

Vous ne contrôlerez jamais le marché. Mais vous pouvez contrôler la facilité avec laquelle vous y répondez. Une architecture qui sépare clairement votre logique métier de celle du fournisseur vous permet de changer en quelques semaines plutôt qu'en plusieurs trimestres. Cette différence-là est un avantage compétitif réel, surtout pour une PME ou une ETI qui doit s'adapter vite.

Si vous voulez auditer votre stack IA actuelle — ou celle que vous êtes en train de bâtir — pour identifier les zones de dépendance critique avant qu'elles ne se referment, hIAppy Vision propose un diagnostic structuré en 2 à 3 semaines, avec une feuille de route concrète à la clé. Et si vous démarrez un cas d'usage et voulez le faire dans les règles dès le départ, hIAppy Lab prototype en 5 à 15 jours, avec l'architecture pensée pour rester portable.