L’IA générative a franchi un cap. Elle n’est plus un sujet d’exploration ou d’innovation marginale, mais un enjeu structurant pour les organisations.
Ce basculement change profondément la nature des questions à se poser. Il ne s’agit plus de comprendre comment utiliser les LLM (modèles de langage), mais de savoir comment en maîtriser les conséquences économiques, techniques etcstratégiques dans la durée.
Car derrière la facilité d’accès apparente se dessinent des dépendances et des effets d’échelle encore largement sous-estimés.
La tension centrale est simple à formuler, mais difficile à résoudre :
« Comment concilier performance, coût et souveraineté dans un contexte où les usages explosent et où les dépendances se renforcent. »
1. Le modèle des API : une simplicité qui masque une dépendance
Les géants de l’intelligence artificielle, comme OpenAI, Anthropic ou Gemini, ont créé un business modèle extraordinaire (pour eux).
En permettant à n’importe quel utilisateur de se connecter, via API, à leurs modèles de langage, ils ont radicalement simplifié l’accès à des capacités auparavant réservées à quelques acteurs disposant de moyens considérables.
En supprimant la nécessité d’entraîner des modèles, de gérer des infrastructures lourdes, et en introduisant un modèle de paiement à l’usage, les acteurs des modèles d’IA ont permis aux organisations de toute taille d’expérimenter rapidement.
Cette promesse de simplicité est réelle, et c’est précisément ce qui explique la vitesse d’adoption. Mais elle repose sur un compromis implicite que beaucoup d’organisations sous-estiment au départ.
En effet, chaque appel à une API renforce une dépendance, non seulement technique, mais aussi économique et stratégique. Et ladite dépendance porte à la fois sur les coûts, les performances, les limitations fonctionnelles et l’évolution des modèles.
Attention, elle ne se manifeste pas immédiatement. Elle s’installe progressivement, comme une grenouille plongée dans l’eau froide. Au fur et à mesure que les usages se multiplient et que les systèmes deviennent critiques, cette dépendance est insidieuse : elle s’installe sans rupture visible, jusqu’au moment où elle devient difficilement réversible.
2. Une adoption sans précédent qui accélère tous les effets
La dynamique d’adoption de l’IA générative est sans équivalent dans l’histoire récente des technologies. Atteindre 100 millions d’utilisateurs en deux mois, comme l’a fait ChatGPT, là où TikTok a mis neuf mois et Instagram plus de deux ans, traduit un phénomène d’appropriation extrêmement rapide.
Cette accélération a une conséquence directe : les organisations n’ont pas le temps de stabiliser leurs architectures ou leurs modèles économiques. Les usages passent très rapidement du stade expérimental à des déploiements à grande échelle, avec des impacts immédiats sur les coûts, les processus internes et les attentes des utilisateurs.
Autrement dit, les entreprises entrent dans des logiques d’industrialisation avant même d’avoir pleinement compris les implications structurelles de ces technologies.
3. Le point de rupture : le passage à l’échelle
Le véritable enjeu ne se situe pas dans les phases de test ou de démonstration. Il apparaît lorsque les usages sont généralisés et intégrés dans les processus métiers.
Pour illustrer ce propos, prenons le cas fictif de l’entreprise SICADIEL qui a choisi de s’équiper d’un assistant RH. Cette ETI, de 8 000 personnes, déploie des outils d’IA de manière progressive.
Dans une première phase, où seul un chatbot est déployé pour répondre aux questions RH des collaborateurs, le volume étant limité à quelques centaines d’interactions quotidiennes avec des consommations de tokens modestes, les coûts restent marginaux. À ce stade, l’illusion d’un coût négligeable est forte.
Mais dès que l’assistant est enrichi, connecté au système d’information, doté de mémoire et de capacités d’action, les volumes changent d’ordre de grandeur. Le nombre d’interactions quotidiennes augmente fortement, combiné à une augmentation du nombre de tokens consommés par interaction. La facture mensuelle passe alors de quelques centaines d’euros à plusieurs dizaines de milliers.
Et dans le cas d’une architecture agentifiée, avec des interactions plus nombreuses, des contextes plus riches et des chaînes d’appels multiples, la logique devient exponentielle. Dans le cas présenté, le coût atteint 175 000 euros par mois pour 25 000 interactions / jour.
Ce qui est déterminant ici, ce n’est pas le coût unitaire du token, mais la combinaison entre le volume, la complexité des interactions et la fréquence d’usage. Le système devient structurellement consommateur.
4. Les mécanismes profonds de l’explosion des coûts
Trois dynamiques se combinent et expliquent pourquoi cette trajectoire n’est pas conjoncturelle, mais structurelle.
D’abord, la nature même des agents IA transforme la logique des requêtes. Là où un chatbot classique repose sur un échange simple, les architectures modernes impliquent des chaînes d’appels, des interactions avec des outils, des boucles de raisonnement et parfois des systèmes multi-agents. Un seul cas d’usage peut ainsi générer plusieurs dizaines d’appels à un modèle.
Ensuite, les contextes s’allongent. L’intégration de mémoire conversationnelle, de documents via RAG (pour Retrieval Augmented Generation, ou en français génération augmentée de récupération) et d’instructions système complexes augmente mécaniquement le nombre de tokens traités à chaque interaction. Le passage de quelques milliers à plusieurs centaines de milliers de tokens par requête n’est plus exceptionnel.
Enfin, les usages s’industrialisent. Les assistants deviennent des composants intégrés aux workflows métiers, aux outils de production, aux systèmes de support ou aux chaînes de traitement de données. Le volume global de requêtes atteint alors des niveaux qui n’étaient pas envisagés lors des phases initiales.
À cela s’ajoute très certainement un prix du token qui n’est pas encore mature : les acteurs de l’IA se livrent à une guerre d’investissement colossale, dans une phase de conquête du marché où les coûts marginaux des tokens sont très certainement plus élevés que leur coût de vente (si l’on regarde les pertes des acteurs, année après année).
Même si le coût unitaire diminue, la croissance des volumes est beaucoup plus rapide. Le résultat est une augmentation globale des dépenses.
5. Le paradoxe de Jevons : pourquoi les optimisations aggravent le problème
L’idée selon laquelle les optimisations techniques permettraient de stabiliser ou de réduire les coûts est séduisante, mais elle repose sur une intuition erronée.
Le paradoxe de Jevons, formulé au XIXe siècle, montre que les gains d’efficacité sur une ressource conduisent généralement à une augmentation de sa consommation globale. Appliqué aux LLM, ce mécanisme est particulièrement visible.
« Quand une technologie devient plus efficace, sa consommation totale augmente au lieu de diminuer. »
La baisse du coût du token, l’amélioration des performances des modèles et la simplification des outils d’accès rendent ces technologies plus accessibles. Cette accessibilité ouvre de nouveaux cas d’usage, qui n’auraient pas été économiquement viables auparavant.
Les optimisations comme le caching, la compression ou l’amélioration des pipelines RAG jouent effectivement un rôle. Elles réduisent certains coûts marginaux et améliorent les performances. Mais elles agissent surtout comme des catalyseurs d’usage.
Le gain d’efficacité ne réduit pas la facture globale, il contribue à l’augmenter.
Ce phénomène est renforcé par trois effets : l’effet rebond, la logique produit qui pousse à enrichir les fonctionnalités, et le passage à l’échelle organisationnelle qui multiplie les usages.
6. Au-delà des coûts : souveraineté et maîtrise des LLMs
Attention, se focaliser uniquement sur les coûts des LLMs consommés par API fait passer à côté d’autres enjeux.
Déjà, la question de la souveraineté est centrale. L’utilisation d’API implique souvent que les données transitent hors des environnements maîtrisés par l’entreprise, parfois dans des juridictions différentes (coucou le Patriot Act). Même si les éditeurs américains vous promettent de ne pas utiliser vos données à des fins d’entraînement, vous ne savez pas où elles circulent, combien de temps elles sont conservées, ni quels sont les logs associés.
Au-delà de la perte de souveraineté, les LLMs propriétaires sont des boîtes noires : la traçabilité, l’auditabilité et la compréhension des traitements ne sont pas possibles (ce qui est contraire aux directives européennes de l’AI Act).
À cela s’ajoute une perte de maîtrise opérationnelle. Les entreprises dépendent des capacités et des contraintes imposées par les fournisseurs d’API, qu’il s’agisse de latence, de personnalisation ou d’évolution des modèles. Dans certains cas métier, la personnalisation des modèles et leur performance est un point clé.
Enfin, le lock-in devient un risque stratégique. Une fois les systèmes construits autour d’un fournisseur, le coût de sortie peut devenir prohibitif, tant sur le plan technique qu’économique.
En résumé, les LLM sont faciles à consommer, mais difficiles à contrôler et impossibles à quitter.
7. L’open source : une réponse séduisante, mais incomplète
Face à ces limites, l’option de l’open source apparaît comme une alternative naturelle. Elle promet davantage de contrôle, une meilleure maîtrise des données et, en apparence, une réduction des coûts.
Mais cette lecture est incomplète.
Il faut distinguer les modèles réellement open source des modèles dits « open weight », dont les poids sont accessibles, mais dont les données d’entraînement et les méthodes restent propriétaires. Et, de très nombreux modèles dits « Open Source » sont, de fait, « Open Weight ». En gros, vous pouvez utiliser le modèle chez vous, mais les données et la méthode d’entraînement restent secrètes.
D’autre part, l’auto-hébergement des modèles Open Source ou Open Weight introduit une nouvelle couche de complexité. Il nécessite des investissements en infrastructure, notamment en GPU (pour Graphics Processing Unit ou en français processeur graphique), ainsi qu’une capacité à opérer des systèmes de machine learning à grande échelle.
Les coûts ne disparaissent pas, ils se déplacent. Ils prennent la forme de dépenses d’infrastructure (CapEx) et de coûts opérationnels (OpEx), incluant des besoins de ressources humaines en MLOps (l’équivalent du DevOps pour l’IA), sécurité, monitoring et maintenance.
Dans l’exemple SICADIEL utilisé plus haut, la progression des coûts selon les 3 phases du projet est bien plus linéaire, mais bien plus coûteuse pour les premières étapes du projet :
En phase 1, le coût pour déployer et maintenir l’infra est de 35K€ en investissement (amorti sur 3 ans, ce qui pourrait être discutable vu l’accélération de l’obsolescence matérielle) et près de 15K€ en frais de fonctionnement, soit plus de 100 fois plus cher que dans l’utilisation d’API.
En phase 2, le coût est de l’ordre de 60K€ /an (amortissement CapEx + frais de fonctionnement), soit 3 fois plus cher que l’usage des API.
Et c’est en phase 3 que l’auto-hébergement devient intéressant, avec un coût annualisé 1,6 fois moins cher.
Autre point de vigilance : les budgets estimatifs en coûts MLOps sont souvent sous-estimés. Des études récentes indiquent en effet qu’ils peuvent être multipliés par deux à cinq par rapport aux estimations initiales.
8. Le point de bascule économique
La question de la rentabilité de l’auto-hébergement ne peut pas être traitée de manière abstraite. Elle dépend essentiellement du volume.
Les ordres de grandeur observés indiquent que le self-hosting devient pertinent lorsque les volumes atteignent plusieurs centaines de millions, voire des milliards de tokens par jour. En dessous de ce seuil, les API restent généralement plus économiques et surtout plus simples à opérer.
Faisons une analyse du point de bascule économique pour l’exemple de notre société fictive SICADIEL. Au-delà de 1 000 M de tokens par jour, il devient plus intéressant d’auto-héberger ses modèles.
Un autre critère déterminant est la capacité à amortir l’infrastructure sur une période courte, typiquement inférieure à un an. Sans cela, les coûts fixes viennent annuler les gains potentiels.
Enfin, autre sujet parfois minoré dans les infrastructures auto-hébergées, la friction opérationnelle générée par la nécessaire adaptation de l’infrastructure à la consommation et à l’évolution des modèles. Pendant que vous passez plusieurs semaines et beaucoup de temps avec des ingénieurs MLOps pour faire passer une infrastructure de 5 à 30 millions de tokens par jours, une migration vers une API aurait pris 4h et coûté 0€…
9. Les questions à vous poser pour choisir
Pour déterminer s’il vous faut héberger vous-même ou non vos modèles de langage, posez-vous 4 questions :
- Est-ce que mes données sont fortement réglementées ?
Si oui, typiquement santé ou équivalent SecNumCloud/HDS en Europe, il faut aller vers du self-host en cloud privé. - Est-ce que j’ai des volumes massifs, plus de 500 millions de tokens par jour ?
Si oui, là aussi, le self-host peut devenir rentable. - Est-ce que j’ai une vraie équipe MLOps en interne ? Et des besoins forts de fine-tuning (entraînements sur données métier) ?
Si la réponse est non, il ne faut pas se mentir et utiliser une API, sous peine que les coûts RH annulent tous les gains. - Est-ce que j’ai des contraintes de latence très fortes, sous 200 millisecondes ? Dans ce cas de figure, l’attente doit être imperceptible, comme avec des agents conversationnels vocaux, des applis de santé connectée, etc.
Ainsi, un modèle auto-hébergé dans votre infrastructure offre des latences plus faibles pour des requêtes, en plus d’une intégration dans les workflows complexes plus flexible sans les limitations des APIs publiques (rate limits, context length, etc.).
Si vous êtes dans ce cas, vous pouvez vous tourner vers des GPU dédiés.
Dans tous les autres cas, la réponse est simple : API managée.
10. L’hybridation : une réponse pragmatique
Attention, opposer API et open source est une simplification excessive. Dans la pratique, les architectures les plus matures combinent les deux approches.
Les entreprises commencent généralement avec des API propriétaires comme OpenAI, Anthropic ou Google Gemini pour leur simplicité, puis évoluent vers des approches multi-fournisseurs avec des outils comme LiteLLM ou LangChain pour limiter la dépendance et optimiser les coûts, éventuellement en utilisant des providers comme OpenRouter.
Elles peuvent ensuite s’appuyer sur des modèles open via API hébergés chez OVH (c’est ce qu’a fait France Travail) ou Scaleway pour des hébergeurs européens ou des fournisseurs optimisés comme Groq et Cerebras qui proposent des modèles plus légers pour améliorer performance et latence.
À maturité, les architectures deviennent hybrides (Dify, LlamaIndex) ou basculent vers du self-host cloud (AWS, Azure, vLLM) voire on-premise (Nvidia DGX), au prix d’une complexité et de coûts fortement accrus.
Cette hybridation permet de répartir les usages en fonction de leur criticité, de leur coût et de leurs contraintes.
Les modèles légers, souvent auto-hébergés, sont utilisés pour les tâches à fort volume et à faible complexité. Les modèles les plus performants, accessibles via API, sont réservés aux cas criques qui nécessitent une forte précision.
En bref, l’hybridation permet d’optimiser les coûts tout en maintenant un niveau de qualité élevé là où c’est réellement nécessaire.
11. Les tensions structurantes des architectures LLM hybrides
Trois arbitrages structurent les choix d’architecture.
Le premier oppose la précision/pertinence au coût.
Les modèles les plus performants sont aussi 10 à 100 fois plus chers, ce qui impose de réserver leur usage aux situations où la valeur métier le justifie. Or, dans 80 % des cas, les requêtes ne nécessitent pas un modèle premium. Il faut donc engager un routage intelligent : les tâches simples aux petits modèles, et les tâches plus complexes et critiques aux modèles récents et puissants via API propriétaires.
Le deuxième concerne la généralisation et la spécialisation.
Les modèles généralistes offrent une couverture large, mais limitée en profondeur métier, tandis que les approches spécialisées nécessitent des investissements supplémentaires en données, en intégration et en maintenance. Aussi, mieux vaut utiliser le modèle généraliste pour la compréhension et le dialogue (notamment les réponses finales aux questions posées), mais utiliser les modèles spécialisés pour la constitution du RAG, l’appel d’API métier, etc.
Le troisième arbitrage porte sur la vitesse et la qualité.
Les architectures complexes, impliquant plusieurs étapes de raisonnement et d’appel à des outils, améliorent la qualité des réponses, mais dégradent la latence et augmentent les coûts. Aussi, l’enjeu est de prévoir plusieurs modes de réponse : des réponses rapides, mais potentiellement moins fiables, et des réponses complexes, qui peuvent activer des agents et des outils, mais qui sont plus lentes.
La réponse à ces tensions n’est pas technologique, mais architecturale. Elle repose sur la capacité à adapter dynamiquement le niveau de sophistication du traitement en fonction du besoin.
12. Le changement de paradigme : passer d’une logique d’un choix de modèle à un choix d’orchestration
Le véritable changement introduit par les LLM ne réside pas dans les modèles eux-mêmes, mais dans la manière de les orchestrer.
La performance d’un système ne dépend plus uniquement de la qualité du modèle utilisé, mais de la manière dont les tâches sont décomposées, routées et supervisées.
Cela implique de mettre en place des mécanismes de :
- cost routing (router les requêtes vers le modèle le moins cher possible selon le besoin) ;
- gestion des fallbacks (escalader vers un modèle plus performant si le modèle est en échec ou avec un fort niveau d’incertitude) ;
- décomposition fonctionnelle des tâches (répartir les sous-tâches à différents modèles, avec par exemple, dans le cas d’un agent qui fait appel à une API, la génération du JSON d’appel à un modèle spécialisé permettant d’éviter les hallucinations).
La performance dépend désormais de l’orchestration et non du modèle pris isolément.
En pratique, trois constats s’imposent donc.
D’abord, la croissance des coûts liés aux LLMs n’est pas un phénomène temporaire. Elle est structurelle, portée par des dynamiques profondes qui ne vont pas s’inverser.
Ensuite, l’open source ne constitue pas une solution universelle. Il apporte des avantages réels, mais introduit également des contraintes et des coûts récurrents souvent sous-estimés.
Enfin, l’hybridation apparaît comme la seule approche viable à moyen terme. Elle permet de concilier performance, maîtrise des coûts et souveraineté, à condition de disposer d’une architecture capable d’arbitrer en permanence entre ces dimensions.
Le véritable enjeu n’est donc plus technologique. Il est stratégique. Il réside ainsi dans la capacité des organisations à concevoir des systèmes capables d’évoluer, de s’adapter et de rester maîtrisables dans un environnement où la transformation est rapide.
Source : article « Self-Hosted LLMs vs API-Based LLMs: Cost & Performance Analysis » du 10 mars 2026.
Crédit photo : Alex Cristi
20 avril 2026
10 minutes
