Le FinOps est souvent perçu comme une démarche complexe, alors qu’une partie importante des économies des infrastructures IT reposent sur des actions simples. Les DSI n’ont souvent pas besoin de lancer de grands chantiers pour produire des résultats rapides. Ils doivent d’abord reprendre de la visibilité sur l’existant.
Ces dernières années, nous avons assisté à une explosion des coûts des infrastructures liés à des environnements et un marché de plus en plus complexes. Cela a créé une pression budgétaire intense qui a remis le concept de FinOps sur le devant de la scène.
Mais bien souvent, les organisations associent le FinOps à des démarches complexes et longues. Il faudrait analyser ses factures et ses contrats cloud en profondeur et engager du temps pour arbitrer entre les modèles tarifaires et les différents fournisseurs. Tout cela nécessitant des ressources humaines et du temps considérables. D’autant plus que beaucoup d’organisations évoluent dans des environnements hétérogènes cloud et on-premises. L’explosion des coûts post-Broadcom a aussi poussé les organisations à diversifier leurs hyperviseurs. Mécaniquement, cette diversité multiplie les consoles, les indicateurs et les équipes perdent en visibilité des usages réels et donc des gains potentiels. Cela a aussi un effet sur les coûts de licence, souvent calculés par cœur physique ou virtuel selon les éditeurs. Un redimensionnement mal anticipé sur une infrastructure hétérogène peut donc avoir un impact direct, et parfois sous-estimé, sur la facture logicielle. Tout cela a donc de quoi décourager les DSI et responsables d’infrastructures qui espèrent des économies rapides.
Pourtant, une partie des gains possibles se tient, très souvent, sous les yeux du DSI.
Commencer par les gisements les plus accessibles
Avant de chercher des optimisations complexes, les organisations peuvent déjà agir sur trois leviers simples : supprimer, redimensionner, densifier.
Par prudence, les équipes ont tendance à surprovisionner les ressources, en ajoutant davantage de CPU, de RAM ou de stockage que nécessaire pour éviter tout risque de ralentissement. Des VM créées pour des tests, des phases de qualification ou des formations restent actives alors qu’elles ne répondent plus à aucun besoin réel. Certaines ressources inactives continuent pourtant d’être supervisées, sauvegardées et maintenues, générant des coûts et de la charge opérationnelle sans créer de valeur.
À cela s’ajoutent parfois une mauvaise gestion de certains services cloud ou SaaS, des modèles de tarification mal maîtrisés, ou plus largement un manque de visibilité et de gouvernance sur les usages réels.
Supprimer ce qui ne crée plus de valeur
Le premier levier consiste donc à supprimer ce qui ne sert plus. Une VM identifiée comme inactive, n’est pas automatiquement inutile, car elle peut avoir une fonction ponctuelle ou répondre à un besoin métier spécifique. Mais elle doit être analysée. Lorsqu’elle s’avère réellement obsolète, sa suppression produit des effets immédiats. Elle permet de réduire les coûts d’infrastructure, mais aussi les coûts de supervision, de sauvegarde et de maintenance. Elle diminue la charge liée à l’ITSM, évite des alertes inutiles et contribue également à réduire la surface d’attaque cyber.
Redimensionner sans mettre la performance en risque
Le deuxième levier repose sur le redimensionnement des ressources, ou “right sizing”. Là encore, l’objectif n’est pas de réduire arbitrairement les capacités allouées, mais de les ajuster aux usages réels. Beaucoup de VM disposent de ressources supérieures à leurs besoins effectifs, souvent par crainte de dégrader la performance applicative. Pourtant, le surdimensionnement systématique n’est pas toujours synonyme de confort. Dans certains cas, il peut même produire l’effet inverse. Par exemple, attribuer trop de CPU à une VM peut générer de la latence, car l’hyperviseur doit mobiliser davantage de ressources simultanément pour exécuter la charge demandée. Ce phénomène peut paraître contre-intuitif. Il est représenté par des métriques très spécifiques à surveiller comme le lait sur le feu (le CPU ready et le co stop sur environnements VMware). Ces métriques traduisent le temps qu’une VM passe à attendre que l’hyperviseur libère des cœurs physiques pour exécuter ses instructions. Plus une VM dispose de CPU, plus cette ordonnancement devient complexe, surtout lorsque plusieurs grosses VM se partagent les mêmes ressources physiques. Une VM trop largement dimensionnée peut donc coûter plus cher, consommer davantage et ne pas mieux fonctionner.
C’est pourquoi le redimensionnement doit impérativement s’appuyer sur des données historiques et factuelles. Cela suppose d’observer non seulement la consommation moyenne, mais aussi les pics d’usage, l’activité disque et le trafic réseau : une VM qui semble inactive sur une moyenne peut très bien absorber une charge critique à un instant précis, lors d’un traitement de fin de mois par exemple. Plus l’observation s’inscrit dans la durée, plus les recommandations sont fiables : elles tiennent compte des pics d’activité, des effets de saisonnalité, des fins de mois ou des périodes critiques.
Densifier pour accompagner la croissance
Enfin, le troisième levier consiste à densifier l’infrastructure. Une fois les ressources inutiles supprimées et les VM redimensionnées, l’entreprise peut utiliser plus efficacement ses serveurs physiques existants. Elle peut héberger davantage de charges utiles sur le même socle matériel, libérer certains serveurs ou absorber de nouveaux besoins sans racheter immédiatement de machines. Dans un contexte où les coûts matériels augmentent fortement, cette capacité à accompagner la croissance à infrastructure égale devient un avantage majeur.
Mais ces démarches, et leur simplicité, n’ont de valeur que si elles reposent sur une vision réelle de l’infrastructure. Supprimer, redimensionner ou densifier ne peut pas se faire sur la base d’une intuition ou d’une photographie ponctuelle. L’optimisation doit s’appuyer sur des mesures factuelles, collectées dans la durée, capables de refléter les usages réels des VM, des serveurs et des applications.
Les gains peuvent alors être rapides et très concrets. Dans certains environnements, l’analyse des usages réels permet d’identifier jusqu’à 80 % de VM en surallocation de ressources, dont environ 10 % peuvent être inutiles donc supprimables. Dans certains cas, quelques mois de mesure et d’optimisation suffisent à libérer plusieurs serveurs physiques. Or un serveur physique représente en moyenne plusieurs dizaines de milliers d’euros par an en coûts directs et indirects. Libérer deux serveurs peut ainsi représenter entre 40 000 et 50 000 euros d’économies annuelles en prenant en compte les tarifs 2026.
Supprimer, redimensionner, densifier. La méthode est donc simple, puisque les économies les plus rapides sont souvent sous les yeux du DSI. Encore faut-il qu’il porte les bonnes lunettes.
