Dépendance aux fournisseurs d'IA : cessez d'acheter un modèle, construisez votre couche d'orchestration
L'écart entre les modèles ouverts et la frontière propriétaire est un intervalle, pas un gouffre. La réponse sensée est architecturale : logez le coût de changement dans une couche d'orchestration que vous maîtrisez, et laissez un cas d'usage chiffré, pas un classement, décider quel modèle y brancher.
Posez la question de la dépendance à un fournisseur d'IA et la plupart des réponses partent vers les clauses contractuelles et les conditions de sortie. C'est le mauvais niveau de défense. Dans les systèmes d'IA, la dépendance est architecturale bien plus que juridique : une fois que vos prompts, vos intégrations d'outils, vos évaluations et les habitudes de vos équipes se sont façonnés autour de l'API d'un seul fournisseur, la clause de sortie n'est plus que décorative, car le vrai coût de changement a déjà été payé en temps d'ingénierie. La Competition and Markets Authority britannique a fait un constat voisin dans son étude sur les modèles de fondation en IA, qui pointait les barrières au changement de fournisseur et les rapprochements verticaux comme les mécanismes les plus susceptibles de figer le marché. En Europe, le règlement sur l'IA (AI Act) et la vigilance de la CNIL sur les pratiques de données des fournisseurs vont dans le même sens. La vraie question n'est donc pas de savoir si vous paierez un coût de changement, mais où vous choisissez de le loger.
Pourquoi la prime des modèles propriétaires est-elle sous pression ?
Le prix des modèles propriétaires se fixe sur un écart : la distance entre ce que la frontière facturée à l'usage sait faire et ce que le reste du marché propose pour moins cher. Une analyse d'Epoch AI estime que les meilleurs modèles ouverts accusent environ un an de retard sur la frontière propriétaire, un écart qui varie selon les tests et se déplace à chaque nouvelle sortie. Que cet intervalle se resserre reste une question réellement ouverte, et un acheteur honnête doit la traiter comme telle. Ce qui compte, c'est sa forme : un intervalle, pas un gouffre, et un intervalle, cela se chiffre.
L'essentiel du travail d'IA en entreprise relève de la classification, de l'extraction, de la rédaction, du résumé et de la plomberie d'agents. Dès qu'un modèle en retard sur la frontière franchit le seuil requis pour une tâche donnée, le critère d'achat pour cette tâche passe du « meilleur » au « suffisant », et il revient rarement en arrière, car peu de directions achats paieront une prime pour une capacité que le cas d'usage ne sait pas exploiter. Cette affirmation appelle une réserve à énoncer clairement : la suffisance se juge tâche par tâche. Un modèle suffisant pour résumer des tickets peut être très loin du compte pour relire un contrat, ce qui explique pourquoi tout l'argument repose sur l'évaluation et non sur l'intuition.
Que fait-on réellement économiser en changeant de modèle ? Un cas chiffré
Le discours abstrait sur la banalisation des modèles ne convainc personne qui tient un budget ; partons donc d'un cas d'usage documenté. Klarna a indiqué que son assistant IA avait traité 2,3 millions de conversations de service client dès son premier mois, un volume que l'entreprise a jugé équivalent à 700 postes à temps plein. Ce sont les chiffres de Klarna elle-même, et ils méritent la prudence habituelle réservée aux succès autoproclamés, mais c'est le volume qui importe ici : environ 28 millions de conversations par an.
Faites maintenant le calcul avec une grille tarifaire actuelle sous les yeux. Les volumes de tokens ci-dessous sont des hypothèses posées pour la clarté de la démonstration, pas les chiffres de Klarna ni le devis d'un fournisseur. Supposons qu'une conversation de support courante consomme environ 3 000 tokens en entrée et 300 tokens en sortie, contexte et appels d'outils compris. Sur 28 millions de conversations par an, cela représente environ 84 milliards de tokens en entrée. Facturés 10 $ par million de tokens, la seule facture d'entrée avoisine 840 000 $ par an ; facturés 1 $ par million sur un modèle moins cher qui réussit la même suite d'évaluation, elle tombe à environ 84 000 $. Les grilles tarifaires publiées ont récemment affiché plus d'un facteur dix entre les niveaux haut de gamme et les niveaux économiques, mais vérifiez les chiffres en vigueur avant de bâtir votre dossier : ils bougent chaque trimestre, et c'est bien là tout l'intérêt. Un écart de cette ampleur, soutenu sur un seul cas d'usage à fort volume, finance une quantité sérieuse d'ingénierie de couche d'orchestration.
Quand une couche d'orchestration agnostique ne se justifie-t-elle pas ?
L'honnêteté impose l'autre colonne du calcul. Reprenez la même arithmétique à 20 000 conversations par mois : un facteur dix ne vaut plus que quelques centaines d'euros par mois, de quoi ne même pas couvrir la maintenance d'un seul connecteur, encore moins d'une couche de routage. Une couche d'orchestration peine aussi à se justifier quand le cas d'usage dépend d'une capacité réellement propre à un fournisseur : un modèle affiné sur mesure, une remise de mise en cache autour de laquelle votre architecture est bâtie, ou un comportement d'usage d'outils que la concurrence ne sait pas encore reproduire. Dans ces cas-là, la prime achète quelque chose de réel, et la portabilité reviendrait à y renoncer. Les comparaisons doivent aussi se faire à armes égales : opposer le modèle vedette d'un fournisseur au niveau économique d'un autre renseigne sur les gammes, pas sur les fournisseurs ; comparez des modèles qui franchissent le même seuil d'évaluation, hébergement, résidence des données et conditions de support inclus, sous peine de bâtir un tableur de fiction. La couche d'orchestration se justifie quand le volume est élevé, les tâches bien spécifiées, plusieurs modèles franchissent votre seuil, et vous disposez des évaluations pour le prouver. En l'absence de ces conditions, se standardiser sur un seul fournisseur peut être le choix rationnel, et prétendre le contraire relèverait lui aussi d'un argumentaire commercial.
Il vaut aussi la peine de relativiser les différenciateurs les plus doux. Les fournisseurs vendent du ressenti : tel modèle serait posé et réfléchi, tel autre rapide et mordant. Dans les faits, une bonne part de ce caractère perçu tient à une couche remplaçable d'instructions et de réglages par défaut posée sur les poids du modèle, et une part surprenante de ce caractère se transporte quand on déplace les mêmes instructions vers un autre modèle. Un trait de caractère qu'on peut reproduire pour l'essentiel avec une page d'instructions est un argument bien mince pour justifier une prime. Le même scepticisme s'applique à la rareté organisée : les niveaux en rupture de stock et les inscriptions au compte-gouttes, pour un produit facturé au token, relèvent plus probablement de la gestion de la demande que d'une preuve de qualité, et se lisent d'abord comme des signaux marketing tant que le fournisseur n'a pas expliqué la contrainte réelle.
Comment éviter la dépendance à un fournisseur d'IA ?
On cesse de chercher à désigner le vainqueur permanent, et l'on rapatrie le coût de changement dans une couche que l'on possède. Concrètement, cela signifie que la gestion des prompts et du contexte, les définitions d'outils, les règles de routage, la journalisation et l'évaluation vivent dans votre couche d'orchestration, derrière une abstraction qui traite chaque API de modèle comme une simple prise. Quand le rapport prix-capacité évolue, changer de modèle devient un paramétrage plutôt qu'une réécriture, et le cas chiffré ci-dessus devient une décision qu'on prend en comité budgétaire plutôt qu'une migration qu'on redoute.
La couche d'orchestration mérite aussi son rôle de surface de contrôle. Les modèles déclarent parfois un travail terminé alors qu'il ne l'est pas ; la revue croisée entre fournisseurs, faire auditer la sortie d'un modèle par celui d'un autre laboratoire, est l'un des contrôles les plus praticables qu'une entreprise puisse mettre en place, et il n'est possible que si l'architecture est agnostique dès le départ. Nous traitons le volet gouvernance de ce sujet dans nos articles sur la sécurisation des systèmes agentiques et sur le maintien d'un contrôle humain sur l'IA opérationnelle.
Si les classements sont biaisés, sur quoi évaluer ?
Le classement en tête des benchmarks publics a cessé d'être utile pour les achats : les suites de tests les plus courantes sont saturées et l'incitation à les optimiser artificiellement est considérable. Ce qui les remplace est plus prosaïque, et vous appartient en propre : l'évaluation sur vos tâches, avec vos données, selon le coût réel de vos erreurs. Le cadre de gestion des risques liés à l'IA du NIST pose l'idée sous-jacente en langage de normalisateur : une mesure n'a de sens que si ses indicateurs correspondent au contexte et à l'usage prévu du système. Un classement ne peut pas vous dire si un modèle sait faire votre travail. Un après-midi avec votre propre suite d'évaluation, si.
Cette suite est elle-même l'infrastructure anti-dépendance. Si vous pouvez noter n'importe quel modèle candidat sur votre travail rapidement, changer de modèle cesse d'être effrayant et devient une décision de coût ordinaire, ce qui est précisément l'enjeu. C'est un travail de préparation, à mener avant la construction : nous détaillons cette logique dans notre article sur la préparation à l'IA avant de construire, et c'est exactement ce que permet une mission de stratégie technique indépendante. Les fournisseurs vendent des moteurs ; achetez le carburant au mérite chaque trimestre, et gardez le moteur dans votre propre garage.
Questions fréquentes
Un modèle ouvert est-il assez bon pour un usage en entreprise ?
Pour la plupart des cas d'usage, la réponse honnête est : testez-le. Définissez ce que « bon » signifie pour la tâche précise, puis notez les modèles candidats sur vos propres données. Si un modèle ouvert moins cher franchit votre seuil, la prime de la frontière propriétaire achète une capacité que votre cas d'usage ne sait pas exploiter. Les questions restantes, hébergement, résidence des données, support, relèvent de l'ingénierie et des achats, pas de la capacité du modèle.
Que contient concrètement une couche d'orchestration IA agnostique vis-à-vis des fournisseurs ?
Un dépôt de prompts et de contexte, des définitions d'outils et de fonctions, une logique de routage et de repli, la journalisation et l'observabilité, un harnais d'évaluation, et un fin connecteur qui fait de chaque API de modèle une simple prise. Le test est simple : si changer le modèle sous-jacent revient à modifier un paramétrage plutôt qu'à réécrire le système, vous possédez votre couche d'orchestration. Si cela revient à tout réécrire, c'est le fournisseur qui vous possède.
Faire tourner plusieurs modèles d'IA coûte-t-il plus cher que de se standardiser sur un seul fournisseur ?
Il y a un vrai surcoût : des connecteurs à maintenir, davantage d'évaluations à faire tourner, et parfois une fonctionnalité propre à un fournisseur à laquelle il faut renoncer. Que cela soit rentable relève de l'arithmétique, pas du dogme : multipliez votre volume mensuel de tokens par l'écart entre les grilles tarifaires des modèles qui franchissent votre seuil d'évaluation. Les cas d'usage à fort volume rentabilisent en général le surcoût dès qu'un modèle moins cher franchit le seuil ; les cas à faible volume peuvent ne jamais y arriver, et le dire d'emblée fait partie de la rigueur de la démarche.
À lire aussi
- Déqualification par l'IA : le risque de réversibilité que votre conseil n'a pas chiffré
- L'oligopole de la mémoire qui fait grimper la facture de l'IA
- Le moindre privilège pour les agents IA : un principe de 1975 que votre pilote court-circuite
- AI & Automation
Rédigé par un persona éditorial IA du système éditorial propriétaire d'Abyshire et relu par notre équipe.