Faire tourner des agents IA sur votre propre matériel n’est financièrement rentable que face aux modèles de pointe coûteux, et seulement au-delà d’environ 5 millions de jetons par jour. Face aux API de modèles à poids ouverts, situées autour de 0,14 à 0,50 dollar par million de jetons, le point d’équilibre est repoussé à des milliards de jetons par mois et la plupart des organisations ne l’atteindront jamais. La conclusion est simple : si le coût est la seule considération, la réponse est généralement non. Les arguments qui tiennent sont la souveraineté des données, le gel de version et la latence — et il faut les chiffrer honnêtement.
La question que posent la plupart des organisations n’est pas la bonne
La discussion s’ouvre presque toujours sur combien allons-nous économiser en hébergeant nous-mêmes. C’est une question que l’on peut calculer, ce qui la rend rassurante — mais ce n’est presque jamais la vraie raison pour laquelle une organisation fait tourner un modèle chez elle.
Trois arguments tiennent la route, et aucun n’est une économie directe. Le premier est la souveraineté des données : quand l’information qui entre dans le prompt ne peut pas sortir de l’organisation, la question économique passe après la question de l’autorisation. Le deuxième est le gel de version : un fournisseur qui met à jour un modèle modifie le comportement d’un agent calibré sur la version précédente, alors qu’un modèle tournant sur votre matériel ne change que le jour où vous le décidez. Le troisième est une latence stable à fort volume, en particulier pour des tâches de classification et d’extraction exécutées des centaines de fois par minute.
Si aucun de ces trois points ne vous concerne, l’arithmétique ci-dessous vous renverra presque toujours vers l’API.
L’arithmétique, sans magie
À la mi-2026, la location d’une seule H100 va d’environ 2 dollars de l’heure chez les fournisseurs GPU spécialisés à près de 14 dollars de l’heure chez les hyperscalers, l’accès à la demande se situant en moyenne autour de 3 dollars de l’heure. L’achat d’une carte coûte de 30 000 à 40 000 dollars et plus. Prenons un tarif réservé de 2 dollars de l’heure — soit environ 1 460 dollars par mois pour une carte qui tourne en continu.
| Ce à quoi vous comparez | Prix par million de jetons | Volume mensuel au point d’équilibre | Équivalent quotidien |
|---|---|---|---|
| Modèle de pointe coûteux | 10 $ | ~146 millions | ~5 millions |
| Modèle de pointe moins cher | 2,50 $ | ~584 millions | ~19 millions |
| API de modèle à poids ouverts | 0,25 $ | ~5,8 milliards | ~195 millions |
Le tableau se calcule directement : 1 460 dollars par mois divisés par le prix par million de jetons. La troisième ligne est celle qui met fin à la discussion dans la plupart des organisations — 195 millions de jetons par jour, c’est le volume d’un produit à l’échelle, pas d’un agent interne.
Notez que ce calcul est généreux envers le matériel. Il suppose un tarif réservé, une seule carte et un coût d’exploitation nul. Ces trois hypothèses tombent en production.
Le taux d’utilisation, c’est toute l’histoire
Une API facture au jeton. Une carte facture à l’heure, y compris les heures où personne ne lui envoie rien. C’est cette différence qui rend fausses la plupart des analyses de rentabilité de l’auto-hébergement.
Un modèle quantifié de la classe des 70 milliards de paramètres, sur une seule H100 avec un batching efficace, atteint l’ordre de 3 000 jetons par seconde. À 2 dollars de l’heure, cela se traduit ainsi.
| Taux d’utilisation moyen | Coût effectif par million de jetons | Face à une API à poids ouverts |
|---|---|---|
| 100 % | ~0,19 $ | Compétitif |
| 50 % | ~0,37 $ | Équivalent ou plus cher |
| 25 % | ~0,74 $ | Trois fois plus cher |
| 10 % | ~1,85 $ | Sept fois plus cher |
Un taux d’utilisation de 100 % n’existe pas dans le monde réel. La charge métier est cyclique — heures ouvrées, jours de semaine, fin de mois — si bien qu’un taux d’utilisation moyen de 50 à 60 % est déjà considéré comme très bon pour une charge interne. En dessous, l’auto-hébergement perd à la fois face aux API à poids ouverts et face à une partie du haut de gamme.
D’où une règle empirique simple : si vous ne pouvez pas désigner une charge continue qui remplit la carte au moins la moitié du temps, vous payez du vent.
Ce que le calcul laisse de côté
Le prix de la carte est le seul poste facile à chiffrer, et c’est pour cela que c’est le seul qui soit chiffré. Le coût complet de l’auto-hébergement en production est généralement trois à cinq fois supérieur.
- Redondance. Une seule carte est un point de défaillance unique. Un agent qui sert des clients en exige au moins deux, ou une voie de repli vers une API.
- Exploitation. Un serveur d’inférence, la supervision, la gestion des files d’attente, les mises à jour de pilotes et une requantification à chaque montée de version du modèle.
- Astreinte. Quelqu’un doit répondre quand le GPU tombe à deux heures du matin. Une API a un SLA ; votre carte, elle, vous a vous.
- Infrastructure de test. Tout changement de modèle ou de quantification impose de rejouer l’intégralité du jeu de tests, comme détaillé dans le guide des évaluations.
- Coût d’opportunité. Un modèle que vous avez figé il y a un an reste là où il est pendant que l’état de l’art avance.
L’architecture qui fonctionne vraiment : le routage par tâche
Le choix n’est pas binaire. Un agent métier typique exécute un mélange de tâches de nature très différente, et la logique économique n’est pas la même pour chacune.
| Type de tâche | Caractéristiques | Où l’exécuter |
|---|---|---|
| Classification, étiquetage, extraction de champs | Fort volume, sortie courte, besoin de constance | Petit modèle sur votre propre matériel |
| Résumé et réécriture | Volume moyen, qualité moyenne suffisante | API de modèle à poids ouverts |
| Planification, raisonnement, décisions | Faible volume, forte sensibilité à la qualité | Modèle de pointe via API |
| Données sensibles qui ne peuvent pas sortir | Contrainte réglementaire | Votre propre matériel, quel que soit le volume |
Ce routage apporte l’essentiel de l’économie sans l’essentiel du risque : les tâches à fort volume, qui sont aussi les plus simples, descendent vers un modèle local bon marché, tandis que les décisions difficiles restent au meilleur modèle disponible. D’autres techniques de réduction du coût au niveau de l’API sont traitées dans le guide de réduction du coût d’inférence, et la dernière ligne du tableau doit découler de votre classification des données d’entreprise.
Six questions avant d’acheter une carte
- Quel est votre volume quotidien de jetons aujourd’hui, mesuré et non estimé, et quel est son rythme de croissance.
- À quel prix alternatif vous comparez-vous — modèle de pointe ou poids ouverts. Les deux réponses pointent dans des directions opposées.
- Quel taux d’utilisation attendez-vous sur une journée et sur une semaine, heures sans trafic comprises.
- Qui, dans l’équipe, maintient le serveur d’inférence, et que se passe-t-il quand cette personne est en congé.
- Existe-t-il une voie de repli vers une API en cas de panne matérielle, et qui décide d’y basculer.
- Existe-t-il un argument qui ne soit pas le coût. Sinon, la décision reste presque toujours à l’API.
Cette décision ressemble à de l’infrastructure mais relève de l’architecture. Elle détermine quelles parties de l’agent peuvent évoluer et lesquelles sont figées, elle doit donc être prise au regard de la carte complète des composants décrite dans Anatomie d’un agent IA d’entreprise.
Questions fréquentes
Est-il moins cher de faire tourner un modèle IA sur notre propre serveur ?
Uniquement dans des conditions précises. Face à un modèle de pointe autour de 10 dollars par million de jetons, le point d’équilibre d’une H100 réservée se situe vers 5 millions de jetons par jour. Face à une API de modèle à poids ouverts autour de 0,25 dollar par million, il bondit à environ 195 millions de jetons par jour, un volume que la plupart des organisations n’atteignent jamais.
Quel est le point d’équilibre entre auto-hébergement et API ?
Il découle d’une division simple : le coût mensuel du matériel divisé par le prix alternatif par million de jetons. Une carte à environ 1 460 dollars par mois face à une API à 10 dollars par million s’équilibre autour de 146 millions de jetons par mois. Multipliez le résultat par trois à cinq pour refléter le coût d’exploitation complet.
Pourquoi le taux d’utilisation du GPU compte-t-il autant ?
Parce qu’une API facture au jeton tandis qu’une carte facture à l’heure, heures d’inactivité comprises. Une charge métier cyclique produit au mieux un taux d’utilisation moyen de 50 à 60 %, si bien que le coût effectif par million de jetons est presque toujours au moins le double du calcul théorique.
Quels sont les arguments non économiques en faveur de l’auto-hébergement ?
Trois principaux : la souveraineté des données quand l’information ne peut pas sortir de l’organisation, le gel de la version du modèle pour qu’un agent calibré ne dérive pas parce qu’un fournisseur a livré une mise à jour, et une latence stable sur les tâches à fort volume. Dès que l’un de ces points s’applique, la question économique devient secondaire.
Peut-on combiner les deux ?
C’est habituellement la bonne architecture. La classification et l’extraction à fort volume tournent sur un petit modèle local, le résumé sur une API à poids ouverts, et les décisions et le raisonnement sur un modèle de pointe. Ce routage supprime l’essentiel du coût sans renoncer à la qualité là où elle décide du résultat.