L'inférence, pas l'entraînement, explique l'essentiel de la facture IA en production. Voici une méthode chiffrée pour suivre les coûts par cas d'usage, poser des seuils d'alerte et arbitrer entre API et hébergement interne.
Le réflexe budgétaire classique consiste à surveiller le coût d'entraînement ou de fine-tuning d'un modèle. C'est l'inverse qu'il faudrait faire une fois le modèle en production. La formation fait les gros titres, mais l'inférence constitue la facture : les analyses sectorielles de 2026 convergent sur le fait que l'inférence représente environ 80 à 90 % du coût d'exploitation d'un modèle déployé, car la formation est un événement borné alors que l'inférence commence au lancement et ne s'arrête jamais.
Trois facteurs aggravent structurellement la dérive dans les organisations qui déploient des cas d'usage agentiques : les flux agentiques déclenchent en moyenne 10 à 20 appels LLM par tâche utilisateur, la recherche documentaire gonfle les fenêtres de contexte de 3 à 5 fois, et les agents actifs en permanence consomment en continu. Résultat : une DSI qui pilotait son cloud à l'instance découvre que la FinOps traditionnelle repose sur l'hypothèse que l'usage est proportionnel à quelque chose de mesurable, alors que la FinOps IA brise cette hypothèse à trois niveaux : la consommation de tokens dépend de la longueur du prompt et du raisonnement du modèle, les workflows d'agents consomment des tokens de façon récursive, et la capacité GPU est réservée à l'avance alors que son utilisation ne l'est pas.
Autre angle mort fréquent : le sous-emploi de la capacité GPU réservée. L'idle capacity liée au surprovisionnement pèse lourd : le rapport 2026 de Cast AI sur l'optimisation Kubernetes, mesuré sur 23 000 clusters, situe l'utilisation moyenne des GPU en entreprise autour de 5 %, soit 95 % du temps GPU payé sans usage réel. Ce chiffre concerne la capacité réservée, pas les API facturées au token : l'usage d'API facturé au token ne peut pas être inactif ; votre parc GPU, lui, le peut, et l'est le plus souvent.
La première étape méthodologique consiste à identifier, cas d'usage par cas d'usage, quel poste domine la facture. Les équipes en phase de pré-lancement sont surtout consommatrices d'entraînement, celles en post-lancement sont surtout consommatrices d'inférence, et les équipes orientées API sont surtout consommatrices de tokens ; le premier travail d'un programme FinOps IA est d'identifier laquelle de ces lignes est la plus importante, pour faire suivre l'ordre d'optimisation à l'argent réellement dépensé.
Concrètement, une DSI de taille moyenne doit pouvoir répondre, pour chaque cas d'usage (assistant RAG interne, chatbot support, extraction documentaire, copilote de code), à trois questions :
C'est un changement d'unité de mesure par rapport au cloud classique. La FinOps IA exige un suivi détaillé au niveau du token, de la requête LLM et de l'utilisation GPU — des données que les tableaux de bord traditionnels n'ont jamais suivies — afin de permettre une véritable attribution des coûts par équipe, modèle, fonctionnalité ou expérimentation, et de pouvoir enfin répondre à la question du coût par 1 000 inférences sans jongler avec des tableurs. Les outils de cost management cloud classiques ne suffisent pas : des outils comme AWS Cost Explorer ou Azure Cost Management montrent où l'argent a été dépensé, mais ils manquent souvent de la granularité nécessaire pour relier cette dépense à un modèle, une charge de travail, une fonctionnalité ou une équipe spécifique.
Un exemple documenté illustre l'ampleur des écarts possibles entre budget prévisionnel et facture réelle : sur 84 charges de travail AWS Bedrock en production instrumentées au premier trimestre 2026, la facture moyenne a dépassé les prévisions de 2,8 fois dans les 60 premiers jours, presque toujours à cause de frais cachés non anticipés représentant 18 à 34 % de surcoût liés au transfert de données, aux garde-fous et au dépassement du débit provisionné. D'où l'intérêt de fixer, dès le cadrage d'un cas d'usage, des seuils d'alerte plutôt que de découvrir le dérapage à la facture.
Trois familles de seuils méritent d'être instrumentées dès la mise en production, avec un porteur clairement identifié par cas d'usage :
Ces seuils rejoignent les pratiques déjà formalisées par les éditeurs d'outils spécialisés : côté gouvernance, ces outils permettent de fixer des budgets par équipe ou par modèle, d'alerter en cas de pic de consommation de tokens, de bloquer les modèles coûteux en environnement hors production et d'imposer des workflows d'approbation pour les expérimentations coûteuses, ce qui évite les dérapages liés à une expérimentation non maîtrisée. L'essor de cette discipline se lit dans son adoption : selon le rapport State of FinOps 2026, 98 % des praticiens FinOps gèrent désormais des dépenses liées à l'IA, contre 63 % en 2025 et seulement 31 % en 2024.
Sur le plan normatif, le cadre FOCUS, référence pour la normalisation de la donnée de facturation cloud, a intégré ces spécificités récemment : FOCUS 1.2, ratifié le 29 mai 2025, a ajouté la prise en charge de la monnaie virtuelle et du cycle de vie des tokens, ce qui permet de normaliser la facturation LLM au token, et FOCUS 1.3, ratifié le 4 décembre 2025, a ajouté l'allocation de coût partagée pour les ressources mutualisées, comblant l'angle mort des clusters GPU partagés. Une DSI qui construit son reporting interne a donc intérêt à s'aligner sur ces catégories plutôt que de réinventer sa propre taxonomie.
Trois leviers concentrent la majorité des économies observées et doivent être testés dans cet ordre, en fonction du coût d'implémentation :
C'est le levier au meilleur ratio effort/gain pour démarrer une démarche FinOps IA. Le cache de prompt stocke le préfixe stable d'une requête (prompt système, définitions d'outils, documents de référence) pour éviter de le retraiter à chaque appel ; sur l'API Claude, une lecture de cache coûte environ 0,1 fois le prix d'entrée de base, et l'arithmétique est simple : dès la deuxième requête sur le même préfixe, le cache devient rentable, avec des économies pouvant approcher 90 % sur la portion mise en cache.
Plutôt que d'envoyer toutes les requêtes vers le modèle le plus performant du catalogue, un routeur qui évalue la complexité de la tâche et n'escalade vers un modèle frontier qu'en cas d'échec change fondamentalement l'équation économique. Le référentiel d'optimisation s'est stabilisé en 2026 : combinés, le routage vers le modèle le moins cher capable de traiter la requête, l'escalade vers les modèles frontier uniquement en cas d'échec, et les deux autres leviers principaux réduisent la dépense constatée de 47 à 85 % sur les charges de travail adaptées. Un cas documenté sur des charges Bedrock illustre l'effet cumulé de ces leviers combinés au cache : le coût par réponse est passé de 0,41 $ à 0,07 $, soit une réduction de 83 %, une fois le routage de modèle, le cache de prompt et l'inférence par lots appliqués.
Pour les organisations qui hébergent tout ou partie de leurs modèles, le gain vient moins du choix du modèle que de la façon dont il est servi. Le batching continu, le prefix caching et le speculative decoding augmentent le débit sur le même matériel : le batching continu seul délivre un débit 3 à 5 fois supérieur au batching statique pour un budget GPU identique. L'écart de coût par token qui en résulte est significatif : servir Llama 3.1 70B en flux unique sur un H100 coûte environ 0,60 à 0,80 $ par million de tokens ; le batching continu à une taille de lot de 8 fait tomber ce coût à 0,15-0,25 $. La quantization complète ce dispositif : la quantization et le dimensionnement adapté réduisent le coût matériel de façon significative, avec des économies estimées entre 30 et 75 % selon un bilan FinOps 2026 ; un modèle de 70 milliards de paramètres qui nécessite environ 140 Go de VRAM en FP16 ne demande plus que 35 Go en AWQ 4 bits.
C'est la décision structurante pour une DSI de taille moyenne, et elle ne doit pas être tranchée une fois pour toutes mais réévaluée cas d'usage par cas d'usage, en fonction du volume. Le seuil de bascule est documenté : pour les flux de travail basés sur des API, les coûts de réglage fin ou d'hébergement dédié dépassent les économies réalisées tant que les volumes de requêtes mensuels n'atteignent pas des centaines de milliers, voire des millions d'appels.
En dessous de ce seuil, l'API managée reste presque toujours l'option la plus rationnelle, d'autant que la baisse tendancielle des prix reste rapide : les coûts d'inférence LLM ont baissé plus vite que presque n'importe quelle autre matière première informatique de l'histoire, avec un rythme de baisse qui varie de 9x à 900x par an selon le jalon de performance considéré. Concrètement, alors que GPT-3, accessible publiquement en novembre 2021, coûtait 60 dollars par million de tokens pour un score MMLU de 42, plusieurs modèles dépassaient ce même score à moins de 0,06 dollar par million de tokens en mars 2026. Un projet d'hébergement interne lancé aujourd'hui doit intégrer cette dynamique de prix dans son calcul de retour sur investissement : le TCO d'un déploiement on-premise se compare à une cible mouvante.
Au-dessus du seuil de volume, l'hébergement hybride devient pertinent, notamment pour maîtriser la variance de coût sur les workloads soutenus. La stratégie optimale combine généralement un socle réservé couvrant le trafic de base tournant 24/7 avec un complément spot pour les pics ; pour un workload nécessitant en moyenne 4 GPU H100 avec des pics à 8, une configuration mêlant GPU réservés, on-demand et spot peut réduire le coût moyen pondéré de 45 à 55 % par rapport au tout on-demand. Mais cette option n'a de sens que si l'équipe est capable de suivre l'utilisation réelle de cette capacité réservée : le risque, documenté plus haut, est de retomber dans le piège des GPU sous-utilisés.
Le calcul d'arbitrage doit aussi intégrer le coût caché de l'attribution. Le problème central de la FinOps GPU en 2026 n'est pas la taille de la facture mais le fait que personne ne peut l'attribuer : la finance voit une seule ligne pour un nœud GPU dont le coût dépasse la plupart des dépenses cloud, tandis que les équipes qui ont réellement consommé les GPU ne voient jamais leur part. Une gouvernance FinOps IA doit donc prévoir, dès le déploiement, un mécanisme de refacturation interne par cas d'usage — faute de quoi l'arbitrage build vs API reste théorique.
Sans équipe FinOps dédiée à temps plein, une DSI de taille moyenne peut structurer sa démarche en trois temps :
Cette structuration progressive évite l'écueil classique consistant à vouloir déployer un outil de FinOps IA complet avant même d'avoir une vision claire de ses cas d'usage. Pour aller plus loin sur la structuration de ces chantiers, consultez notre offre de conseil et de formation en IA et data, ou échangez directement avec nos consultants via la page contact.