7 min de lecture

Aujourd’hui, presque toutes les organisations ont adopté FinOps, une discipline visant à maîtriser les coûts du cloud. Pourtant, les entreprises continuent de gaspiller 25 à 35 % de leurs dépenses cloud dans des ressources inutilisées. Ce chiffre reste stable depuis des années, malgré l’amélioration constante des outils. Le problème ne vient pas d’un manque de visibilité. Il vient du fait que la visibilité n’équivaut pas au pouvoir de désactiver une ressource.

En lien :VMware VCF 9.1 et la question de la souveraineté  /  800 volts en courant continu pour les racks IA

Ce que FinOps est censé accomplir

Qu’est-ce que FinOps ? FinOps, contraction de *Financial Operations*, désigne la pratique consistant à rendre transparents les coûts du cloud et à les piloter entre les équipes techniques, financières et métiers. L’objectif est que chaque dépense soit attribuée à un responsable et que les décisions concernant les coûts soient prises là où se situe le contrôle technique.

En théorie, FinOps comble une ancienne lacune. Autrefois, la facture cloud arrivait en fin de mois, personne ne pouvait l’imputer à une équipe spécifique, et l’optimisation relevait de la devinette. FinOps apporte de la transparence : quelle équipe engendre quels coûts, quelle ressource tourne à vide, où une réservation serait judicieuse. Le marché des outils FinOps s’est donc développé, et selon le *State of FinOps Report*, 98 % des praticiens gèrent désormais aussi les dépenses liées à l’IA, et 90 % les coûts SaaS.

Les outils existent donc, et ils sont performants. C’est précisément ce qui rend ce taux de gaspillage stable si remarquable. Si la visibilité s’améliore mais que le gaspillage persiste, c’est que la visibilité n’est pas le goulot d’étranglement. Le rapport met le doigt sur le problème avec précision, mais lire un rapport n’équivaut pas à agir.

Pourquoi ce chiffre ne baisse pas

La raison est organisationnelle, pas technique. Les équipes FinOps ont presque toujours la visibilité, mais rarement le pouvoir de décision. Elles peuvent préciser qu’une base de données tourne à vide depuis trois mois ou qu’une instance est surdimensionnée d’un facteur trois. Ce qu’elles ne peuvent pas faire : l’éteindre purement et simplement. Car la ressource appartient à une équipe de développement qui, en cas de doute, affirmera en avoir encore besoin – et qui devrait assumer la responsabilité en cas de panne liée à cette suppression.

Ainsi se crée une situation de blocage. FinOps recommande, l’équipe hésite, personne ne tranche. La ressource inutilisée continue de tourner, car son extinction comporte un petit risque, tandis que son maintien ne coûte que de l’argent, noyé dans une facture globale. Un argent qui ne fait mal à personne, et qui, en cas de doute, l’emporte sur un risque que quelqu’un devrait assumer personnellement. C’est humainement compréhensible, mais coûteux au final.

La vague de l’IA accentue cette dynamique. Les instances GPU et les points de terminaison d’inférence coûtent plusieurs fois le prix d’une VM classique, et elles sont souvent lancées pour des expérimentations que personne ne nettoie ensuite. Si déjà personne n’éteint une base de données standard inutilisée, un cluster GPU oublié restera d’autant plus en place. Les 98 % qui pilotent désormais les coûts de l’IA contrôlent ainsi un poste qui croît plus vite que l’ancienne situation de blocage ne le réduit.

Ce qui fait réellement baisser ce taux

Le levier n’est pas un nouvel outil, mais une autorité. FinOps doit passer du rôle de rapporteur à celui de décideur, au moins dans le cadre de règles claires. Une forme éprouvée est le mandat avec délai : une ressource identifiée comme inutilisée est automatiquement éteinte après une période de carence définie, sauf si l’équipe responsable s’y oppose activement. La charge de la preuve s’inverse. Ce n’est plus à FinOps de justifier l’extinction, mais à l’équipe de justifier le maintien en fonctionnement.

Le deuxième levier est l’imputation au bon budget. Tant que les coûts cloud atterrissent dans une enveloppe centrale IT, aucune équipe ne ressent concrètement la dépense. Si les coûts sont directement attribués à l’équipe à l’origine de la consommation, le comportement change de lui-même. Ce qui figure dans son propre budget est éteint bien avant que FinOps n’ait à le rappeler.

Un rapport FinOps sans pouvoir d’agir est une coûteuse carte météo. Il prédit avec précision où il va pleuvoir, et personne n’a de parapluie.

Pour les ressources IA, un troisième point s’ajoute : une date d’expiration dès le départ. Celui qui lance un cluster GPU pour une expérimentation lui fixe une échéance, après laquelle il s’éteint automatiquement. Cela évite la catégorie de gaspillage la plus coûteuse : la ressource haute performance oubliée. Aucun de ces trois leviers n’est techniquement complexe. Tous trois sont organisationnellement inconfortables, car ils déplacent la responsabilité là où il n’y avait jusqu’ici que du confort.

C’est précisément pour cette raison que ce chiffre bouge si peu. De meilleurs outils résolvent un problème qui n’a jamais été un problème d’outil. Celui qui veut réduire ces 25 à 35 % n’achète pas une nouvelle plateforme FinOps. Il donne un mandat à celle qui existe déjà. C’est la réponse inconfortable, mais la seule qui ait fait bouger ce taux ces dernières années.

Foire aux questions

Pourquoi le gaspillage cloud ne diminue-t-il pas malgré le FinOps ?

Parce que le problème est organisationnel, pas technique. Les équipes FinOps ont la visibilité, mais rarement le pouvoir de désactiver une ressource. Tant que personne ne prend de décision, la ressource inutilisée continue de tourner.

Qu’est-ce que l’IA change dans la structure des coûts ?

Les ressources GPU et d’inférence coûtent plusieurs fois plus cher que les instances classiques et sont souvent lancées pour des expérimentations que personne ne nettoie ensuite. Cela amplifie précisément la catégorie qui était déjà la plus difficile à contrôler.

Comment le FinOps peut-il obtenir un mandat pour désactiver ?

Via une règle avec délai : une ressource marquée comme inutilisée est automatiquement désactivée après un délai de carence, sauf si l’équipe s’y oppose. La charge de la preuve s’inverse, passant de la justification de la désactivation à celle de la poursuite de l’exécution.

Une autre répartition des coûts peut-elle aider ?

De manière significative. Tant que les coûts cloud restent regroupés dans une position centrale, aucune équipe ne ressent la consommation. Lorsqu’ils sont directement imputés à l’équipe responsable, le comportement de désactivation change automatiquement.

A-t-on besoin de nouveaux outils pour cela ?

Non. Les outils FinOps existants offrent déjà la visibilité nécessaire. Ce qui manque, c’est le pouvoir décisionnel et l’imputation des coûts. Un nouvel outil ne résoudrait pas un problème qui n’a jamais été technique.

Source de l’image : générée par IA (juin 2026), certificat C2PA intégré à l’image