FinOps : -38 % de coûts cloud dans la mécanique

Un constructeur de machines de taille moyenne de Bade-Wurtemberg, avec environ 600 employés, a réduit sa facture mensuelle de cloud de 38 % en six mois. Pas de nouveau fournisseur, pas de migration, pas de suppression d’emplois dans l’informatique. Seulement quatre leviers, tirés de manière conséquente. Ce cas est une synthèse de plusieurs projets FinOps des deux dernières années, les ordres de grandeur sont typiques du secteur et correspondent aux benchmarks de la FinOps Foundation.

Les points clés en bref

• 38 % en six mois, c’est réaliste, pas spectaculaire. La FinOps Foundation cite des économies de 30 à 50 % pour des programmes complets. Le cas se situe dans la partie inférieure de la moyenne, car il a été calculé de manière conservative.
• Quatre leviers contribuent à l’économie. Plans d’économies, ajustement des ressources, arrêt des environnements de développement et de test, ainsi que nettoyage des ressources abandonnées. Aucun d’entre eux n’est nouveau.
• L’ordre des leviers est crucial. Sans transparence des coûts, chaque optimisation est vaine. L’inventaire n’est pas un préalable, c’est la première étape.

En relation :Le calcul de l’inférence que personne n’a budgétisé  /  Les dépenses en IA poussent les équipes FinOps dans de nouvelles pièges budgétaires

Le point de départ : une facture que personne ne lit plus

L’entreprise fabrique des machines spéciales, travaille en cloud depuis environ cinq ans et avait récemment une facture mensuelle d’environ 80 000 euros. La somme n’a pas augmenté à cause d’une mauvaise décision, mais à cause de nombreuses petites choses. Un workload ici, une base de données là, un environnement de test que personne n’a désactivé après le projet. La facture arrivait chaque mois, elle était payée, mais elle n’était pas lue.

C’est l’état normal, pas l’exception. Dans tous les secteurs, une partie importante des dépenses en cloud est considérée comme un gaspillage de ressources inutilisées ou surdimensionnées. Le département informatique du constructeur de machines le savait dans les grandes lignes, mais n’avait pas de mandat ni d’outil pour le quantifier. La première étape n’était donc pas technique.

Ce que FinOps signifiait concrètement dans ce cas

Qu’est-ce que FinOps ? FinOps est la discipline opérationnelle qui consiste à gérer les coûts du cloud comme une responsabilité partagée entre les équipes techniques, financières et métier. Elle associe la transparence des coûts par workload à des règles de décision claires pour déterminer quand acheter, réduire ou désactiver. FinOps n’est pas un outil, mais une routine.

Dans le cas de la construction mécanique, cela signifiait qu’une personne avait été dégagée une journée par semaine pour obtenir le mandat de détailler la facture cloud par centre de coûts et par workload. Pas d’équipe dédiée, pas de certification, pas d’achat de plateforme. Une salle de réunion, les données de facturation des fournisseurs et une feuille de calcul suffisaient pour commencer. Après trois semaines, la première affectation fiable était prête. Elle montrait que près d’un tiers des dépenses concernaient des ressources soit surdimensionnées, soit inutilisées en dehors des heures de travail.

Ce n’est que avec ce chiffre que la pression nécessaire à un programme FinOps est apparue. Une exhortation abstraite à économiser n’a aucun effet. Une ligne chiffrée qui prouve qu’un environnement de test spécifique coûte 14 000 euros par trimestre et ne sert à rien 19 heures sur 24 ne peut être ignorée.

Les quatre leviers qui ont fait la différence

Les 38 % se répartissent sur quatre mesures. L’ordre n’est pas le fruit du hasard, il suit le niveau de risque : ce qui modifie le moins l’architecture est abordé en premier.

Premièrement : Plans d’économies et Instances réservées. La plus grande contribution individuelle, environ 16 points de pourcentage. Pour une charge de base stable, l’achat à prix à la demande est la variante la plus coûteuse. Qui engage une partie de la charge pour un à trois ans, paie nettement moins selon le modèle, jusqu’à plus de 60 % sous le tarif à la demande. Le constructeur mécanique a délibérément limité l’engagement à la charge de base qu’il avait maintenue constante depuis des années. Ainsi, le risque d’engagement est resté faible.

Deuxièmement : Ajustement de la taille. Environ 10 points de pourcentage. Une grande partie des serveurs avait été commandée par excès de prudence, souvent lors de la première installation, lorsque personne ne connaissait la charge réelle. Les données d’utilisation des fournisseurs ont montré des instances fonctionnant pendant des mois avec une charge CPU inférieure à 15 %. La réduction de la taille de un à deux niveaux a fait baisser les coûts sans que les applications ne s’en aperçoivent.

Troisièmement : Désactivation des environnements de développement et de test. Environ 7 points de pourcentage. Les environnements non productifs n’ont pas besoin de fonctionner la nuit et le week-end. Un simple planning horaire qui les arrête le soir et les redémarre le matin réduit presque de moitié leur temps de fonctionnement. Cette mesure ne coûte presque rien et est pourtant celle qui est le plus souvent négligée parce qu’elle n’appartient à personne.

Quatrièmement : Nettoyage des ressources orphelines. Environ 5 points de pourcentage. Volumes de stockage non attribués, anciennes snapshots, bases de données de projets terminés, adresses IP inutilisées. Individuellement, ce sont de petites sommes. Au total, c’était l’effort d’une après-midi pour un effet mesurable.

Six mois, trois phases

Le délai n’était pas fixé de manière ambitieuse, il découlait de la séquence. Certains leviers agissent immédiatement, d’autres nécessitent une observation avant de les actionner.

L’erreur de séquence la plus fréquente dans la pratique : acheter des plans d’économies en premier lieu, parce que la remise est attrayante, puis optimiser la taille. Ensuite, l’engagement sur une taille d’instance est conclu, qui est ensuite réduite. L’engagement continue, la remise s’applique à une charge qui n’existe plus.

Ce qui annule les économies

Une économie FinOps n’est pas un effet ponctuel, c’est un état qui doit être maintenu. Ces modèles ont porté le succès dans les projets ou l’ont annulé en un trimestre.

Il est frappant de constater que la deuxième partie échoue souvent, pas la première. Réaliser des économies est un projet avec une fin claire. Les maintenir est une habitude sans fin. Le constructeur de machines a résolu cela de manière pragmatique : l’indicateur de coûts cloud figure désormais dans le rapport mensuel de la direction. Ce qui y figure est lu.

Les coûts cloud diminuent non pas grâce à un meilleur outil, mais grâce à une personne ayant un mandat et une date dans le calendrier.

Ce qui est transposable à d’autres entreprises

Les 38 % ne constituent pas une promesse. Une entreprise qui achète déjà de manière disciplinée en tirera moins de bénéfices. Une entreprise qui n’a jamais prêté attention à cela en tirera souvent plus. Ce qui est transposable, ce n’est pas le chiffre, mais la démarche.

L’entrée en matière ne coûte pas de plateforme ni d’équipe. Elle coûte une journée par semaine d’une personne capable de calculer et ayant un mandat. Les données de facturation sont disponibles chez chaque fournisseur, ainsi que les métriques d’utilisation. Celui qui commence cela a un chiffre après trois semaines. Et un chiffre est le début de toute discussion sur les coûts du cloud qui ne se termine pas dans le vague.

Foire aux questions