Coût d'inférence : modèles ouverts sur vos GPU ou API propriétaire

La question qu'un directeur financier pose tôt ou tard, une fois passé l'effet de la démonstration, est simple : combien cette IA va-t-elle coûter une fois en production, tous les jours, et est-ce que la facture dérape quand les usages se multiplient ? Elle est saine, et la réponse dépend d'un choix d'architecture qu'on tranche trop tard dans la plupart des projets. Faire tourner les modèles via une API propriétaire facturée à l'usage, ou servir des modèles ouverts sur une infrastructure que vous maîtrisez, ce ne sont pas deux variantes du même service. Ce sont deux structures de coût, et deux risques, qui n'ont presque rien en commun.

Le prix par million de tokens affiché sur une page tarifaire ne suffit pas à les départager. Ce qui décide, c'est la façon dont chaque option se comporte à mesure que l'usage monte, et le risque qu'elle vous fait porter sur vos données.

Deux structures de coût qui n'ont rien en commun

Une API propriétaire se paie au token. Chaque requête, chaque réponse, chaque document analysé consomme des tokens facturés. Le coût est nul à l'arrêt et croît à mesure que l'usage monte. C'est confortable au démarrage : aucun investissement, vous payez ce que vous consommez. C'est aussi ce qui le rend difficile à prévoir une fois que les usages s'installent et se diffusent dans l'entreprise. Une charge variable se budgète mal, parce qu'elle suit l'adoption, et l'adoption est précisément ce que vous cherchez à provoquer.

Servir des modèles ouverts sur vos GPU, en colocation européenne ou sur un cloud souverain, inverse la logique. Vous payez une infrastructure dont le coût est largement fixe : le matériel, l'hébergement, l'exploitation. Ce coût existe que vous traitiez dix requêtes par jour ou plusieurs millions. Il ne grossit pas avec l'usage, il s'amortit dessus. Plus le système tourne, plus le coût de chaque réponse baisse, jusqu'à devenir marginal sur du volume soutenu.

Le résumé tient en une phrase pour un comité : l'API est une charge variable, le parc de modèles ouverts est une charge fixe qui s'amortit. Presque tout le reste de la comparaison découle de cette différence.

Le point de bascule

Si ces deux courbes se croisent, c'est qu'il existe un seuil d'usage à partir duquel servir vos propres modèles revient moins cher que louer une API. En dessous de ce seuil, l'API l'emporte : peu de volume, usage sporadique, rien à investir ni à exploiter. Au-dessus, l'infrastructure dédiée l'emporte, parce que la charge fixe se répartit sur un volume qui la dilue.

L'arbitrage ne se joue donc pas sur le prix unitaire affiché, mais sur votre trajectoire d'usage. Un cas isolé, déclenché une fois par semaine, ne justifie pas un parc GPU. Une base de connaissance interrogée toute la journée par des dizaines de collaborateurs, un agent qui tourne en continu, un pipeline qui traite des milliers de documents par mois, font basculer le calcul. Le volume soutenu et durable est ce qui penche la balance, et il faut le projeter avant de choisir, pas le constater une fois la facture arrivée.

C'est exactement ce qu'on chiffre au cadrage, sur vos volumes réels et votre montée en charge prévue, plutôt que sur une moyenne de marché qui ne dit rien de votre cas. Le bon seuil n'est pas une constante du marché, c'est une propriété de votre usage.

Les coûts que personne ne met dans le tableur

La comparaison honnête ne s'arrête pas au prix d'inférence. Chaque option traîne des coûts qu'on oublie au moment de décider et qu'on découvre en exploitation.

Du côté de l'API propriétaire, le premier coût caché est la sortie de données. Si vos requêtes embarquent de la donnée régulée, contrats, dossiers clients, pièces financières, vous ne payez pas que des tokens, vous engagez une mise en conformité et un risque que nous traitons plus bas. Vient ensuite la perte de maîtrise sur le prix : un fournisseur peut faire évoluer sa grille ou déprécier le modèle sur lequel vos intégrations sont calées, et vous subissez le changement sans levier. La dépendance, enfin, a un coût bien réel le jour où il faut migrer : prompts, intégrations et garde-fous réécrits pour un autre fournisseur, c'est un projet, pas un paramètre.

Ce risque n'a rien de théorique. Le 12 juin 2026, Anthropic a coupé l'accès à ses modèles Fable 5 et Mythos 5 pour l'ensemble de ses clients, du jour au lendemain, afin de se conformer à une directive du gouvernement américain restreignant l'accès à ces modèles pour tout ressortissant étranger. Ils venaient d'être lancés quelques jours plus tôt. Une entreprise européenne qui avait bâti un service sur l'un d'eux s'est retrouvée sans recours, parce que la décision lui était extérieure et qu'elle visait précisément sa qualité de non-américaine. Un modèle ouvert que vous servez sur vos propres GPU ne peut pas être éteint à distance par un tiers. C'est là toute la différence entre louer une capacité et la maîtriser, et elle ne se voit sur aucune grille tarifaire.

Du côté des modèles ouverts servis chez vous, les coûts cachés sont d'une autre nature. Il y a l'exploitation, qui ne se résume pas à brancher une carte : supervision, mises à jour, disponibilité. Il y a le taux d'utilisation du matériel : un GPU à l'arrêt reste une charge fixe payée pour rien, donc la rentabilité suppose un usage qui le remplit. Il y a le rythme de rafraîchissement des modèles, car l'open source avance vite et un parc se tient à jour. Aucun de ces postes n'est rédhibitoire, mais les ignorer fausse la comparaison autant qu'oublier la sortie de données du côté de l'API.

La règle que nous tenons sur les chiffres vaut ici aussi : un coût d'exploitation ne s'estime pas à la louche, il se modélise sur vos volumes. La projection de coût d'un déploiement est un calcul déterministe, pas une intuition, et c'est ce qui sépare une promesse commerciale d'un budget tenable.

La souveraineté n'est pas une ligne de coût, c'est un risque

Réduire le débat à des euros par token escamote la dimension qui décide souvent à elle seule. Quand votre IA traite de la donnée régulée, l'envoyer vers une API hébergée hors de l'Union européenne n'est pas un détail d'architecture, c'est un transfert qui vous expose au titre du RGPD et, selon votre métier, du secret professionnel. Le coût de ce choix ne se lit pas sur une facture, il se matérialise le jour d'un contrôle, d'un incident ou d'une question d'un client sur l'endroit où vivent ses données.

Servir des modèles ouverts sur vos GPU ou sur un cloud souverain en UE supprime le transfert à la racine : la donnée ne sort pas. C'est aussi ce qui rend le système défendable devant un comptable, un associé ou un fonds, qui ne signeront pas sur une réponse dont ils ne maîtrisent pas le chemin. Quand le niveau d'exigence l'impose, l'hébergement peut se faire chez un opérateur qualifié SecNumCloud. Nous détaillons cette posture, les hébergeurs et la réversibilité sur notre page sécurité et hébergement. La souveraineté n'est pas un argument moral ajouté après coup, c'est une ligne de risque qui pèse dans l'arbitrage au même titre que le coût.

Ce que nous opérons, et pourquoi nous en parlons

Nous ne tenons pas ce discours depuis une diapositive. Nous opérons notre propre infrastructure d'inférence GPU et nos systèmes RAG souverains en production, sur nos propres usages, et c'est cette expérience qui nourrit nos recommandations. Servir un modèle ouvert chez soi, le tenir disponible, mesurer son coût réel à l'usage, ce n'est pas un schéma théorique pour nous, c'est notre quotidien d'exploitation.

Le déploiement que nous proposons repose sur des modèles ouverts, sous licence permissive, servis sur vos GPU ou sur une infrastructure souveraine en UE. Vous n'êtes pas enfermé chez un fournisseur, le coût se décompose en un setup puis un run prévisible, et la donnée reste chez vous. C'est l'objet de notre brique déploiement souverain sur vos GPU, qui s'articule presque toujours avec une base RAG souveraine pour que vos agents et vos réponses s'appuient sur votre connaissance interne sans la faire sortir.

L'intérêt de cette structure pour vous est qu'elle nous permet de vous dire la vérité sur le seuil. Comme nous ne vendons pas de licence à reconduire, nous n'avons aucun intérêt à vous pousser vers l'option la plus chère pour vous. Si votre volume ne justifie pas un parc, nous vous le dirons.

Comment trancher pour votre cas

Le bon réflexe n'est pas de choisir l'architecture d'abord, c'est de qualifier l'usage et de chiffrer les deux scénarios sur vos volumes. C'est la logique de notre méthode. Elle commence par un diagnostic gratuit de trente minutes en visio, où l'on qualifie le besoin et l'ordre de grandeur des volumes. Vient ensuite le cadrage, à 1 900 euros, livrable écrit déductible du build si le projet continue, qui pose l'architecture et chiffre le coût d'inférence sur votre cas plutôt que sur une moyenne. Puis le build sur devis, à partir de 25 000 euros pour un premier cas en production, et le run mensuel avec engagement de service. Vous savez ce que vous payez à chaque étape, et vous décidez d'avancer à chaque palier.

La question de départ, combien cette IA va-t-elle coûter en production, a donc une réponse, mais elle n'est pas universelle. Elle dépend de votre volume, de votre exposition réglementaire et de votre trajectoire. Le travail consiste à la calculer honnêtement, des deux côtés, avant d'engager le moindre euro de build.

Questions fréquentes

À partir de quel volume servir ses propres modèles devient-il rentable ?

Il n'existe pas de seuil universel, parce qu'il dépend de votre usage réel et non d'une moyenne de marché. La logique est constante : en dessous d'un certain volume l'API facturée au token reste moins chère, au-dessus l'infrastructure dédiée s'amortit et passe devant. Le rôle du cadrage est de calculer ce seuil sur vos volumes et votre montée en charge prévue, pas de le supposer.

Une API n'est-elle pas toujours moins chère puisqu'il n'y a rien à acheter ?

Au démarrage et sur de faibles volumes, souvent oui. La charge variable de l'API est imbattable tant que l'usage reste modeste. Le raisonnement s'inverse dès que l'usage devient soutenu et durable, car la charge fixe d'un parc se dilue sur le volume et fait baisser le coût unitaire, là où la facture d'API continue de monter avec l'adoption.

Les modèles ouverts sont-ils moins performants que les modèles propriétaires ?

Pour beaucoup de cas métier, l'écart utile s'est resserré, et un modèle ouvert bien servi et bien outillé répond au besoin. La performance d'un système en production ne tient pas qu'au modèle brut, elle tient surtout à l'architecture autour de lui, recherche, citation des sources, garde-fous. C'est cet ensemble qui décide de la qualité ressentie, pas seulement le classement d'un modèle sur un comparatif générique.

Mes données régulées peuvent-elles transiter par une API hors UE ?

C'est précisément le risque à examiner avant tout choix. Envoyer de la donnée régulée vers une API hébergée hors de l'Union européenne constitue un transfert qui vous expose au titre du RGPD et, selon votre métier, du secret professionnel. Servir des modèles chez vous ou sur un cloud souverain en UE supprime ce transfert, parce que la donnée ne sort pas.

Faut-il acheter des GPU ou peut-on louer une infrastructure souveraine ?

Les deux sont possibles, et le choix dépend de votre profil. Acheter le matériel maximise la maîtrise et l'amortissement sur la durée si le volume est là. Louer une infrastructure souveraine en UE évite l'investissement initial tout en gardant la donnée sur le territoire. Le cadrage tranche selon votre volume, votre horizon et vos contraintes de conformité.

Comment estimer le coût avant de s'engager ?

Par le cadrage, qui modélise le coût d'inférence sur vos volumes réels et compare les deux scénarios chiffrés. Nous tenons à ce que ce calcul soit déterministe et non une estimation au doigt mouillé, parce qu'un budget d'exploitation se défend devant une direction financière. C'est l'objet du livrable écrit remis à l'issue du cadrage.