Par Florian BEAURAIN
Florian Beaurain est Group FinOps Leader d’EDF et Expert Advisor Hubadviser. Il pilote la stratégie FinOps à l’échelle du Groupe, une pratique bâtie en partant de zéro, certifiée FinOps Foundation, aujourd’hui relayée par une communauté mondiale d’une vingtaine de praticiens. Ce guide prolonge le webinar Hubadviser du 7 juillet 2026, animé aux côtés d’Ismail Charkaoui, co-fondateur d’Hubadviser.
FinOps appliqué à l’intelligence artificielle
Par Hubadviser – Guide pratique
SYNTHÈSE EXÉCUTIVE
1. FinOps : la discipline qui donne le droit d’accélérer
Le FinOps, contraction de Finance et DevOps, est une discipline opérationnelle et collaborative qui vise à maximiser la valeur créée par les technologies, à favoriser des décisions éclairées par les données en temps réel et à responsabiliser l’ensemble des acteurs, grâce à une coopération étroite entre IT, Finance et Métiers. Le cadre de la FinOps Foundation s’organise autour de 4 domaines et 22 capacités mesurables, adossés à un modèle de maturité.
Notez la formulation : maximiser la valeur, pas minimiser la dépense. Un FinOps bien conduit ne dit pas « non » aux usages : il rend le « oui » défendable devant la direction financière. C’est toute la différence entre un DSI qui subit les arbitrages budgétaires et un DSI qui les mène.
Longtemps cantonné au cloud public, le périmètre du FinOps s’est considérablement élargi. Les données de la FinOps Foundation montrent l’ampleur du mouvement :
- 98 % des pratiques FinOps couvrent désormais les usages IA
- 90 % intègrent les environnements SaaS et éditeurs
- 64 % couvrent le licensing
- 57 % le cloud privé
- 48 % le datacenter en propre
Deux familles de leviers, pleinement activables sur l’IA
Optimisation des taux : réduire le montant payé pour une ressource nécessaire, en agissant sur le prix :
- Engagements long terme : Reserved Instances, Savings Plans, Committed Use Discounts, avec jusqu’à 70 % de remise sur 1 à 3 ans.
- Négociations contractuelles : remises sur volume, Enterprise Agreements.
Indicateur : baisse de la facture mensuelle à périmètre constant.
Optimisation des traitements : empêcher une dépense de se produire, en agissant sur l’usage :
- By design : architectures serverless, processeurs ARM/AMD dès la conception.
- Rightsizing & auto-scaling : ajuster les capacités au besoin réel.
- Instances spot / préemptibles : jusqu’à 90 % de réduction sur les traitements batch et analytiques.
Indicateur : écart entre trajectoire prévue et dépense constatée (Forecast Accuracy Rate).
Pour un DSI, la conséquence est structurante : la gouvernance des coûts ne peut plus se penser silo par silo. IA, SaaS, licences, cloud privé et datacenter relèvent d’une même démarche. Les leviers éprouvés sur le cloud classique restent valables sur l’IA, à condition d’y ajouter une couche de pilotage spécifique.
2. FinOps for AI : le token change les règles du jeu
La métrique centrale des consommations IA est le token, l’unité de représentation du texte traité et généré par les modèles. Elle introduit une rupture avec le cloud classique : la dépense devient fonction du contexte transmis, des usages, du raisonnement demandé et du passage à l’échelle. Résultat : des dépenses volatiles et difficilement prévisibles, avec des profils de consommation inadaptés aux référentiels existants, un empilement de coûts, une forte sensibilité aux choix de modèles et des grilles tarifaires mouvantes.
La réponse n’est pas de freiner les usages, mais de monter en rigueur : là où le cloud se pilotait par revues mensuelles, les consommations IA exigent un monitoring en quasi temps réel. Et un changement de focale : la question n’est plus « combien consomme-t-on ? » mais « pourquoi consomme-t-on, et quelle valeur métier cela produit-il ? »
Le triptyque d’arbitrage : performance, coût et valeur métier
Chaque cas d’usage doit être évalué selon trois piliers : le niveau de performance attendu (qualité de raisonnement, vitesse, multimodalité), le coût du modèle mobilisé et la valeur business générée. C’est ce ratio, et non le prestige du modèle, qui détermine si un usage est bien dimensionné. Cette logique de pilotage par la valeur est portée au niveau international par la Tokenomics Foundation (Token Economics), initiée sous l’égide de la Linux Foundation et de la FinOps Foundation.
Les indicateurs à mettre sous contrôle
- Coût par requête / par inférence, en précisant modèle, version et volumes associés ;
- Coût par cas d’usage, par utilisateur, par projet ou par entité, la granularité qui permet la refacturation ;
- Taux de conformité aux budgets (soft limits) et écart prévisionnel ;
- ROI et gains de productivité, en temps monétisé ou en valeur business générée ;
- Indicateurs techniques d’optimisation, comme le cache hit ratio.
À retenir : l’objectif final est de corréler ce que représente l’ensemble de la stack d’un point de vue coût avec la valeur business apportée. Une meilleure visibilité, non pas seulement sur les consommations, mais sur la valeur.
À utiliser dès cette semaine : les 3 questions à poser à votre DAF
- « Si notre consommation IA double le mois prochain, au bout de combien de jours le savons-nous, et qui décide quoi ? »
- « Quel usage IA accepterions-nous de couper demain, et sur quel critère objectif ? »
- « Sur quel cas d’usage sommes-nous capables de démontrer un ROI aujourd’hui, chiffres à l’appui ? »
Si aucune des trois ne trouve de réponse en moins d’une minute, la suite de ce guide est votre priorité du trimestre.
3. Le modèle économique de l’IA : raisonner en ratios, pas en euros
Les grilles tarifaires des fournisseurs évoluent chaque mois ou trimestre : raisonner en prix absolus, c’est être périmé avant d’avoir arbitré. Ce qui reste stable : les ordres de grandeur entre classes de modèles et la mécanique du token. Et le vrai coût dépasse toujours la facture du modèle, car il inclut la donnée, l’orchestration, l’observabilité, la sécurité et l’exploitation.
Comprendre le token, l’unité qui fait la facture
Un token est l’unité de découpage du texte par les modèles : un mot court vaut un token, un mot long deux ou trois. Chaque échange se facture en deux temps : les tokens soumis (l’input : la question et son contexte) et les tokens générés (l’output : la réponse). Or générer coûte 3 à 4 fois plus cher que soumettre, car le modèle produit sa réponse token par token, le calcul le plus intensif, là où la lecture du contexte se traite en une seule passe. Exemple concret : à question identique, demander une synthèse d’une page plutôt qu’un rapport de dix pages divise le coût de sortie par dix.
Quatre réflexes qui agissent directement sur la facture :
- Limiter les sorties inutilement longues en calibrant la longueur attendue dès la consigne ;
- Privilégier des réponses synthétiques quand l’usage le permet ;
- Surveiller les usages générant de gros volumes de texte (rédaction, comptes-rendus, code) ;
- Intégrer des KPI de consommation par usage et une gouvernance associée (quotas, formats de sortie).
La grille de lecture : trois classes, un rapport de 1 à 30
| Classe de modèle | Ratio de coût (output) | Type d’usage cible | Règle d’attribution |
|---|---|---|---|
| Léger / rapide | 1× | Classification, extraction, tâches simples à fort volume | Par défaut pour tous : c’est le modèle qu’on quitte sur justification, pas l’inverse |
| Milieu de gamme | ≈ 3–5× | Production généraliste, assistants internes | Attribué par population ou par usage cartographié |
| Premium (raisonnement) | ≈ 10–30× | Tâches complexes, workflows agentiques, raisonnement avancé | Arbitré au cas par cas, sur besoin réel démontré |
Ordres de grandeur à date de juillet 2026 : output ≈ 0,25–4,60 €/M tokens (léger), 0,75–13,75 € (milieu de gamme), 11–27,50 € (premium) ; input ≈ 0,05–0,75 / 0,40–2,75 / 1,85–4,60 €/M tokens. Ces montants évoluent vite ; les ratios, beaucoup moins.
Trois voies d’accès aux modèles
- Via API, la porte d’entrée naturelle : paiement à l’usage au token, remises négociables sur engagement (typiquement au-delà de 50 k$/an), en choisissant des régions d’inférence conformes à vos exigences réglementaires ;
- Via GPU hébergé, pour amortir la ressource : le coût par token devient (amortissement GPU + réseau + stockage + exploitation) ÷ tokens produits ; le tarif GPU se négocie (environ 2,75 €/h pour un H100 à date) et des optimisations comme vLLM en maximisent l’utilisation ;
- En local (datacenter), pour la souveraineté et la conformité, en tenant compte de la pénurie actuelle de GPU ; contre-intuitivement, le coût complet amorti sur 3 ans peut s’avérer inférieur à l’approche API sur certains profils d’usage.
4. Multi-modèles et routage : la fin du LLM unique
Conséquence directe de cette grille : une organisation mature ne pilote pas « un LLM », elle pilote un portefeuille de modèles. Cela suppose une cartographie à jour croisant trois dimensions : les populations (qui utilise ?), les usages (pour quoi faire ?) et les modèles autorisés (avec quelle classe de performance et de coût ?).
Le risque n°1 identifié : laisser des populations entières utiliser au quotidien un modèle premium, jusqu’à 30 fois plus cher qu’un modèle léger, pour des tâches qu’un modèle rapide traiterait aussi bien. La règle saine : le léger par défaut, le premium sur justification, et non l’inverse.
Du routage statique au routage dynamique
Le premier niveau de maturité est le routage statique : on fixe le modèle adapté à chaque cas d’usage selon le triptyque performance, coût et valeur. Le niveau supérieur est le routage dynamique, programmatique : les appels sont orientés en temps réel selon la latence mesurée, voire selon des plages horaires. Un usage critique conserve un modèle rapide aux heures de pointe ; les usages moins sensibles basculent vers des modèles moins coûteux.
Des modèles légers qui rattrapent les modèles frontière
Deux familles cohabitent sur le marché. Les modèles légers (par exemple GPT-4o mini, Claude Haiku ou Mistral Small) sont conçus pour aller vite et traiter de gros volumes à moindre coût : ils conviennent très bien au tri, à l’extraction ou à la classification. Les modèles frontière (par exemple GPT-5.5, Claude Opus ou Gemini Pro) embarquent la plus grande capacité de raisonnement disponible à un instant donné : ils excellent sur des tâches complexes, mais coûtent 10 à 30 fois plus cher en sortie.
On observe de plus en plus la fin des tarifs subventionnés, avec une convergence des prix entre fournisseurs et un rapprochement du ratio performance/coût des modèles légers vers celui des modèles frontière sur des cas d’usage bien circonscrits. Concrètement : ce qu’un modèle frontière savait faire seul il y a un an, un modèle léger le fait aujourd’hui presque aussi bien, pour une fraction du prix. Le réflexe « toujours le plus gros modèle » devient donc chaque trimestre un peu plus coûteux, et un peu moins justifié.
L’open source comme solution de repli stratégique
D’un côté, les modèles propriétaires (GPT d’OpenAI, Claude d’Anthropic, Gemini de Google) ne sont accessibles que via l’API du fournisseur, sous ses conditions et sa juridiction. De l’autre, des modèles ouverts comme Llama (Meta), Mistral (Mistral AI) ou DeepSeek publient leurs poids : n’importe quelle organisation peut les héberger sur sa propre infrastructure et les faire tourner sans dépendre d’un fournisseur unique.
À retenir : on a déjà vu certains modèles coupés du jour au lendemain, et on n’est pas à l’abri demain d’un export control activé sur des modèles très largement utilisés. Avoir un modèle open source en alternative à votre modèle industriel, en solution de repli, c’est vraiment important.
Au-delà du coût, cette dépendance constitue un risque de continuité d’activité, particulièrement sensible pour le secteur public et les opérateurs d’importance vitale, où il rejoint les exigences de souveraineté. Mais ce choix a un prix technique : héberger un modèle open source exige des compétences que l’appel à une API ne demande pas, comme le MLOps ou la sécurisation de l’infrastructure GPU. Pour une DSI de taille intermédiaire, le bon compromis est souvent de confier cet hébergement à un partenaire ou un hyperscaler plutôt que de tout internaliser : l’essentiel est de garder la main sur le choix du modèle et la capacité à basculer rapidement.
Envie d’en savoir plus?
Vous avez maintenant le cadre conceptuel : le token, les classes de modèles, la fin du LLM unique. Vous savez où se jouent les vrais leviers d’optimisation. Mais le grand écart se creuse ici : comprendre les principes, c’est une chose. Passer à l’action, c’en est une autre.
La suite du guide vous donne exactement cela.
D’abord, une grille en sept couches qui structure l’intégralité de votre architecture de coûts, du GPU jusqu’aux workflows métier. Pas pour impressionner, mais pour savoir où agir quand la facture dérive, et par où commencer dès lundi matin.
Ensuite, le dispositif « minimum viable » : un plan 90 jours calibré pour une DSI de 20 à 100 collaborateurs, calibré aussi pour le secteur public. Zéro délire de greenfield, zéro pré-requis d’expert interne. Simplement : qu’est-ce que vous devez voir les 30 premiers jours, mesurer les 30 suivants, et arbitrer le mois d’après.
Et surtout, l’auto-diagnostic en 10 questions qui vous positionne honnêtement. Pas pour vous noter, pour vous dire : « Voilà où vous en êtes, voilà votre première étape à haut impact. »
Téléchargez la suite. C’est là que vous décidez enfin qui paie quoi, et pourquoi.
