La simplicité de déploiement de l’infrastructure cloud a déplacé une grande partie du problème du simple approvisionnement vers la gestion économique. Créer des machines virtuelles, des clusters Kubernetes, du stockage, des bases de données ou des services d’intelligence artificielle peut prendre quelques minutes ; déterminer ensuite qui les utilise, combien ils coûtent réellement et quelle valeur ils produisent est beaucoup plus complexe. C’est là qu’intervient FinOps, une discipline visant à intégrer le coût dès la phase de décision technique afin d’éviter que la facture devienne une surprise.

Les clés de FinOps et des dépenses cloud en 30 secondes

• 40 % des organisations considèrent la gestion des coûts cloud comme l’un de leurs principaux défis, et estiment qu’environ 29 % des dépenses en IaaS et PaaS sont gaspillées.
• FinOps combine ingénierie, finance et stratégie commerciale pour faire le lien entre consommation technologique et valeur apportée.
• Les pratiques fondamentales incluent la taille adéquate (rightsizing), l’étiquetage, la budgétisation, les engagements de consommation et la suppression des ressources inutilisées.
• La prochaine étape consiste à analyser les économies unitaires : mesurer le coût par client, transaction, service ou même token d’IA.
• Une infrastructure stable oblige également à comparer les options : cloud public, privé, dédié ou hybride, avant d’optimiser une architecture mal choisie.

Il est particulièrement frappant de constater que, même après des années d’efforts, le rapport State of the Cloud 2026 de Flexera, basé sur les réponses de 753 professionnels et responsables cloud, indique que la dépense gaspillable en IaaS et PaaS atteint en moyenne 29 %, après cinq ans de diminution. De plus, 85 % des répondants citent la gestion des coûts comme l’un de leurs défis majeurs, en dépassant même la sécurité, évoquée par 82 %.

L’intelligence artificielle complique encore davantage la donne. GPU, inférence, stockage, API, bases de données vectorielles et nouveaux services PaaS introduisent des unités de consommation différentes de celles traditionnelles. La facture ne dépend plus uniquement du nombre de machines virtuelles en fonctionnement.

C’est pourquoi FinOps évolue, passant d’une simple économie à une question bien plus pertinente : qu’obtient réellement l’entreprise en échange de l’argent qu’elle investit dans la technologie ?

FinOps commence avant la réception de la facture

La FinOps Foundation définit aujourd’hui ses cadres autour de capacités telles que la compréhension de l’utilisation et du coût, la quantification de la valeur commerciale et l’optimisation de la consommation et du prix. Parmi celles-ci figurent la planification, la prévision, le budget, les indicateurs, unit economics, l’architecture, le placement des charges, les licences et la durabilité.

Cela change la manière d’appréhender le problème.

Une facture cloud de 100 000 euros par mois n’est pas nécessairement plus mauvaise qu’une autre de 70 000 euros. Si la première supporte dix fois plus de clients, de transactions ou de revenus, elle peut représenter une infrastructure plus efficiente économiquement.

D’où l’importance des économies unitaires.

Au lieu de se limiter à demander combien coûte AWS, Azure, Google Cloud, un cloud privé ou une plateforme Kubernetes, l’entreprise peut mesurer des indicateurs comme le coût par client, commande, transaction, machine virtuelle, API utilisée ou service fourni.

La Unit Economics est précisément intégrée par la FinOps Foundation comme une capacité à faire le lien entre usage, coût et valeur produite par les services et activités d’une organisation.

Cette tendance se manifeste déjà dans les entreprises. Selon Flexera, le pourcentage de structures utilisant des métriques d’économies unitaires est passé de 40 % à 49 % en un an.

C’est une évolution significative.

Réduire les coûts cloud de 10 % peut sembler une réussite, mais si cela entraîne une augmentation de la latence, une baisse de disponibilité ou limite un produit en pleine croissance, l’économie réalisée pourrait en réalité détruire davantage de valeur qu’elle n’en génère.

Visibilité : savoir qui dépense

Avant d’optimiser, il faut pouvoir attribuer la consommation.

Cela nécessite une politique cohérente d’étiquetage, de gestion des comptes, des projets, des responsables et des centres de coûts. Un ressource doit pouvoir répondre à des questions essentielles : qui en est responsable, à quelle application appartient-elle, dans quel environnement elle fonctionne, et quel centre de coût la finance.

L’étiquetage manuel a tendance à se dégrader rapidement. C’est pourquoi les organisations plus matures intègrent ces règles dès le processus d’approvisionnement et dans l’infrastructure en tant que code.

L’absence de responsable attribué est en réalité un indicateur précieux. Une machine virtuelle, un volume, un snapshot, une adresse IP ou un load balancer oublié doit faire l’objet d’une révision, même si son coût individuel semble modeste.

Le vrai problème apparaît avec la accumulation de ces ressources inutilisées.

Rightsizing : payer pour ce qui est réellement nécessaire

Une autre pratique classique est le rightsizing, c’est-à-dire adapter les ressources à la consommation réelle.

Une machine avec 32 vCPU et 128 Go de RAM qui utilise en permanence une faible partie de sa capacité peut être surdimensionnée.

Mais il ne faut pas se limiter à regarder la moyenne CPU, car d’autres paramètres entrent en jeu : mémoire, stockage, IOPS, bande passante, latence, pics de demande, réserves, haute disponibilité, marges opérationnelles, etc.

Une base de données, par exemple, peut consommer peu de CPU mais dépend fortement de la mémoire et du stockage. Un service peut rester presque inactif durant des heures et connaître une multiplication de charge à certains moments.

FinOps demande donc des métriques techniques précises, pas uniquement des données de facturation.

Les ressources oubliées ont aussi un coût

Les infrastructures inactives prennent diverses formes : machines en développement tournant la nuit ou le week-end, disques restant après suppression d’une instance, snapshots anciens, IP publiques inutilisées, load balancers vides, clusters surdimensionnés ou environnements de test oubliés.

Dans ces cas, il est souvent possible de réaliser des économies simplement en supprimant ce qui ne sert plus.

Il faut également examiner le stockage. Données actives, sauvegardes, archives à long terme : tout ne nécessite pas le même type de stockage ni les mêmes coûts.

Certains coûts sont plus subtils : transferts inter-zones ou régions, egress, passerelles NAT, observabilité, support, licences commerciales ou services managés facturés en fonction du volume de requêtes.

La facture d’infrastructure va bien au-delà du CPU et de la RAM.

Kubernetes et IA : des défis accrus pour la gestion des coûts

Kubernetes illustre parfaitement la nouvelle complexité économique.

Une facture peut indiquer le coût global d’un ensemble de nœuds, mais une entreprise doit pouvoir faire la répartition par namespace, application, équipe ou client.

Des projets open source comme OpenCost proposent une méthode indépendante du fournisseur pour mesurer et répartir les coûts d’infrastructure et de conteneurisation au sein de Kubernetes.

L’intelligence artificielle complique encore cette gestion.

OpenCost 1.121.0, publié en août 2026, a ajouté des fonctionnalités pour relier les coûts Kubernetes aux charges d’inférence. L’intégration avec llm-d et vLLM permet d’estimer des métriques telles que le coût par modèle et par token, en tenant compte de l’utilisation effective des ressources.

Une distinction clé apparaît alors : le coût de disponibilité versus le coût d’utilisation.

Un modèle de langage chargé sur une GPU peut être prêt à répondre immédiatement tout en restant inactif une grande partie du temps. Même sans générer de tokens, il occupe de la mémoire et de la capacité qui ont un coût.

Ce coût peut être justifié si l’application exige une latence extrêmement faible.

Ce qui importe pour FinOps, c’est de rendre cette consommation visible.

Une plateforme IA pourrait mesurer précisément le coût de disponibilité de chaque modèle, le coût réel par million de tokens traités et la part due à la capacité inutilisée maintenue pour respecter des délais de réponse précis.

C’est un exemple clair qui montre que l’optimisation des coûts ne consiste pas toujours à réduire les ressources.

Changer d’architecture : une solution FinOps efficace

Une question fondamentale doit être posée avant même le rightsizing :

Chaque charge est-elle exécutée sur le modèle d’infrastructure le plus adapté ?

Le paiement à l’usage offre des avantages indéniables en cas de demande imprévisible. Une application devant multiplier sa capacité quelques heures peut tirer parti de l’élasticité.

Mais si une charge nécessite des ressources quasi constantes tout au long de l’année, la situation est différente.

Une base de données d’entreprise, un ERP, un cluster de virtualisation ou une plateforme interne stable peuvent justifier une comparaison entre le coût réel du cloud public et des alternatives comme le cloud privé, les serveurs dédiés ou une architecture hybride.

La comparaison ne doit pas se limiter au coût d’une vCPU.

Il faut inclure stockage, trafic, licences, support, sauvegardes, redondance, opérations, personnel, sécurité, récupération après sinistre et coûts de capacité inutilisée.

Flexera souligne notamment que, face aux défis des migrations, la comparaison économique entre infrastructure locale et cloud devient stratégique, et que de plus en plus d’organisations adoptent une approche early shift — le fameux shift-left FinOps — intégrant la gestion des coûts dès la conception architecturale.

Cela met en évidence une idée importante : une organisation peut faire un rightsizing parfait, mais continuer à payer excessivement si l’architecture initiale ne correspond pas au comportement de la charge.

Inversement, déplacer une application variable sur une infrastructure fixe, simplement parce que le coût mensuel paraît inférieur, peut conduire à un surdimensionnement pour gérer ses pics.

FinOps doit aider à choisir le modèle d’architecture adapté à chaque charge, plutôt que de défendre un seul paradigme par défaut.

De la visibilité à la responsabilité financière

L’attribution des coûts peut également transformer la relation entre départements.

Avec showback, chaque équipe connaît ses consommations, même si le budget reste centralisé. Un département peut découvrir que ses environnements représentent 18 000 euros par mois, même si la facture est toujours consolidée par le service informatique.

Le chargeback va plus loin : ces coûts sont imputés directement à son budget.

Les deux approches modifient la dynamique décisionnelle, rapprochant la décision technique de ses implications économiques.

Mais l’attribution doit être fiable. Répartir de façon arbitraire les coûts d’une plateforme partagée entre vingt applications, en se basant sur des estimations approximatives, risque de produire des indicateurs erronés ou peu pertinents.

Les économies unitaires apportent une solution à cette étape intermédiaire.

Par exemple, une entreprise de commerce électronique peut mesurer ses coûts d’infrastructure par commande, une plateforme SaaS par client actif, une application IA par conversation ou par million de tokens, ou une plateforme interne par environnement ou service.

Ainsi, il devient possible de distinguer : une croissance qui entraîne davantage de dépenses, et une augmentation des coûts liée à une moindre efficacité de l’infrastructure.

L’intelligence artificielle ouvre un nouveau front pour FinOps

Les données de 2026 révèlent pourquoi cette question gagnera encore en importance.

58 % des répondants de Flexera utilisent déjà des services d’IA générative dans le cloud public, et le pourcentage de gaspillage estimé en IaaS et PaaS remonte à 29 %.

Une étude conduite par la même société, axée sur la gestion des actifs technologiques, indique que seulement 31 % des organisations disposent d’une visibilité claire sur leur software d’IA, tandis que 59 % constatent une augmentation des dépenses gaspillées associées à l’IA au cours de la dernière année.

Cela soulève de nouvelles questions pour les équipes en charge de l’infrastructure :

• Quel est le coût réel de chaque modèle ?
• Quelle GPU est sous-utilisée ?
• Cela vaut-il la peine de maintenir un modèle chargé pour réduire la latence ?
• Est-il plus économique d’utiliser une API externe ou de réaliser une inférence en interne ?
• Quel département génère les tokens ?
• Quel est le coût par requête, en tenant compte de la GPU, du stockage, du réseau et de la plateforme ?

Ce sont des problématiques FinOps, mais qui ne ressemblent plus du tout à la simple vérification d’une facture de machines virtuelles.

La discipline évolue parce que l’infrastructure elle-même change constamment.

L’objectif reste simple : que le coût ne soit plus une surprise après la décision technique.

Quand architecture, ingénierie, opérations, business et finance peuvent anticiper le coût d’une décision et mesurer la valeur qu’elle génère, FinOps devient une démarche intégrée, non une action isolée pour réduire la facture.

Il s’intègre désormais dans la conception même de l’infrastructure.

Questions fréquentes

Qu’est-ce que FinOps ?

FinOps est une pratique de gestion qui relie la consommation technologique à ses coûts et à la valeur créée pour l’organisation. Elle nécessite une collaboration entre ingénierie, opérations, finances et business et ne se limite pas à réduire la facture cloud.

Quels coûts cloud devraient être examinés en plus du CPU et de la mémoire ?

Stockage, snapshots, transfert de données, egress, adresses IP, load balancers, services gérés, observabilité, support et licences peuvent représenter une part importante. En Kubernetes et IA, il est également crucial d’attribuer des ressources partagées comme la capacité GPU aux applications, équipes ou modèles spécifiques.

Qu’est-ce que les économies unitaires en FinOps ?

Ce sont des indicateurs liant le coût technologique à une unité utile pour le business, par exemple : coût par client, transaction, commande, service, conversation IA ou million de tokens traités.

FinOps est-elle aussi pertinente pour le cloud privé et les centres de données ?

Absolument. Le cadre actuel de FinOps se concentre sur la valeur apportée par la technologie et peut s’appliquer à la comparaison entre différents modèles d’infrastructure. Une organisation mature peut combiner cloud public, privé, dédié ou infrastructure interne, selon l’élasticité, l’utilisation, les exigences techniques et le coût total.