En mai 2026, Arthur Mensch s'est présenté devant les députés à l'Assemblée nationale, et il a dit quelque chose que je trouve assez vertigineux quand on y pense vraiment. Il a parlé d'une « incapacité des acteurs à se dégager de ces nouveaux services ». Pas d'une difficulté, pas d'un frein, pas d'un risque potentiel... d'une incapacité. C'est-à-dire que les entreprises qui ont basculé sur les API d'OpenAI, d'Anthropic ou de Google, eh bien elles ne peuvent plus partir. Ou alors à un prix qu'elles n'ont même pas commencé à calculer, et c'est ça qui me préoccupe le plus.

« une incapacité des acteurs à se dégager de ces nouveaux services. »

Quand je lis ça, ça me rappelle quelque chose. Ça me rappelle Microsoft dans les années 2000, quand Office, Exchange et Active Directory sont entrés par la porte de la productivité et sont restés par celle de la dépendance... et à l'époque, partir de Microsoft c'était plus un choix technique, c'était un projet de plusieurs années, un plan de migration complet, une réécriture de tous les processus, une formation de toute l'organisation. Beaucoup d'entreprises n'ont jamais fini. D'autres n'ont même pas commencé. Et bien l'IA, c'est le même film, sauf que cette fois c'est pire, et je vais vous expliquer pourquoi.

Vos données ont servi à contextualiser leurs modèles

La première différence avec le lock-in Microsoft, c'est que quand vous étiez sur Office, vos données étaient dans un format fermé mais au moins elles étaient lisibles. Avec l'IA, vos données ont servi à contextualiser un modèle qui ne vous appartient pas, et c'est fondamentalement différent. Vous avez construit des bases de vectorisation pour le RAG, vous avez fait du fine-tuning sur vos documents internes, vous avez rédigé des prompts système de plusieurs milliers de caractères, testés, optimisés, versionnés... eh bien tout ce travail est lié à l'API spécifique du fournisseur que vous avez choisi.

Les formats de prompt ne sont pas portables d'un fournisseur à l'autre. Le schéma du function calling diffère entre OpenAI et Anthropic. Les vecteurs calculés par un embedding d'OpenAI ne sont pas compatibles avec ceux d'un modèle Mistral. Vous avez investi des centaines d'heures d'ingénierie pour calibrer un système sur un fournisseur, et ce capital ne voyage pas, il est cloué. Le verrou n'est plus sur le fichier comme avec Office, il est sur toute la chaîne d'inférence, et c'est ça qui change tout.

Vos workflows dépendent des capacités spécifiques de l'API

La deuxième différence, c'est que les workflows modernes ne se contentent pas d'envoyer du texte et de recevoir du texte. Ils utilisent le function calling pour que le modèle déclenche des actions, ils s'appuient sur le structured output pour obtenir des JSON valides, ils envoient des images pour de la vision, ils chaînent des appels, gèrent du context window, font du caching de prompts... et toutes ces capacités existent chez les principaux fournisseurs, mais avec des syntaxes différentes, des comportements différents, des limites différentes.

Le function calling d'OpenAI ne se comporte pas comme celui d'Anthropic. Le structured output de Google n'a pas les mêmes contraintes que celui de Mistral. Changer de modèle peut casser les pipelines, et pas proprement, pas progressivement... en production, au milieu de la nuit, sur un cas edge que personne n'avait testé. Je vois ça chez les clients qui viennent me voir : ils ont un agent qui tourne sur l'API d'un fournisseur américain, il fonctionne, il rapporte, mais ils n'osent plus toucher à la configuration parce que le moindre changement de modèle déclenche une cascade de régressions à retester à la main. Le système est devenu un monolithe implicite, et tout le monde fait semblant que c'est normal. Ce n'est pas normal.

Le coût de migration croît avec le temps

La troisième différence, c'est peut-être la plus insidieuse : le coût de migration croît avec le temps. Plus on attend, plus les intégrations sont profondes, plus les équipes sont formées sur un outil et ne connaissent que lui, plus les documents internes et les runbooks sont écrits pour une API précise, plus les contrats avec les clients embarquent des garanties liées à un modèle précis... c'est une dette qui s'accumule en silence, qui n'apparaît dans aucun bilan comptable, aucun tableau de bord, aucune revue de projet.

Mais le jour où le fournisseur change sa tarification, où il coupe l'accès sur décision gouvernementale comme Anthropic l'a fait en juin 2026, où il modifie le comportement du modèle dans une nouvelle version... ce jour-là, la dette devient payable. Et elle se paie cher. Quand votre fournisseur d'IA obéit à un autre gouvernement que le vôtre, qu'est-ce qui vous garantit que votre service tournera encore demain ? Un contrat... un contrat que l'autre partie peut suspendre.

L'open source, seul vrai rempart

Alors oui, il n'y a qu'un seul modèle qui protège réellement du verrouillage, et je ne le dis pas par idéologie, je le dis parce que c'est un fait technique vérifiable : l'open source. Le modèle est à vous, vous pouvez le faire tourner où vous voulez, aussi longtemps que vous voulez. Personne ne peut couper l'accès. Personne ne peut changer la tarification, puisque vous payez l'électricité et la machine, pas un jeton d'inférence. Personne ne peut modifier le comportement du modèle sans que vous ne le décidiez. C'est aussi simple que ça.

Arthur Mensch, toujours devant les députés :

« Dans un monde où l'open source gagne, les prix sont beaucoup plus faibles parce que la marge n'est pas faite sur les modèles. »

La marge ne se fait pas sur le modèle, elle se fait sur le service, l'intégration, l'accompagnement. C'est exactement ce que je fais avec mes clients : pas un jeton d'inférence à payer, mais la mise en place d'un modèle local, la formation des équipes, le paramétrage du RAG sur leurs documents. Le modèle, lui, est gratuit.

Le verrouillage se met en place maintenant

Le verrouillage est un processus qui se met en place maintenant, silencieusement, à chaque intégration d'API, à chaque workflow construit autour d'une capacité spécifique, à chaque formation d'équipe sur un outil propriétaire, à chaque contrat qui lie une garantie de service à un modèle précis. Chaque année de retard augmente le coût de sortie. Chaque intégration supplémentaire ajoute une barre au panier.

Au bout de trois ans, partir n'est plus un projet de migration, c'est un projet d'entreprise, avec son budget, son comité de pilotage, et sa probabilité non nulle d'échec. La question n'est pas de savoir s'il faut quitter OpenAI ou Anthropic... la question, c'est combien coûtera le départ dans deux ans, et qui paiera. Parce qu'il y aura un départ, tôt ou tard, le fournisseur changera ses conditions, un gouvernement coupera un accès, le prix deviendra intenable. Et ce jour-là, le coût de migration sera le total de toutes les intégrations qu'on a accepté d'écrire sur une API qu'on ne maîtrisait pas.

Vous écrivez la suite de ce scénario aujourd'hui, à chaque appel d'API. Alors faites très attention à ce que vous écrivez demain.