FinOps : maîtriser la dépense cloud

La scène est fréquente. La direction financière découvre que la facture mensuelle du fournisseur de cloud a doublé en un an. La direction technique explique que les usages ont augmenté. Personne ne sait dire quelle part de cette hausse correspond à de nouveaux services utiles, et quelle part à des serveurs oubliés, des environnements de test jamais éteints ou des volumes de stockage que plus personne ne consulte. Le FinOps est né de cette situation.

Ce que recouvre le FinOps

Le terme désigne une pratique de gestion financière du cloud, qui réunit les équipes techniques, financières et métiers autour d’un objectif commun : tirer le maximum de valeur de chaque euro dépensé. La FinOps Foundation, rattachée à la Linux Foundation, en a formalisé le cadre et les principes, largement repris.

Le point de départ est un changement de modèle. Dans l’informatique traditionnelle, la dépense se décidait en amont : on achetait des serveurs, une fois par an, après validation budgétaire. Dans le cloud, n’importe quel ingénieur peut créer en quelques minutes une ressource facturée à l’heure. La décision de dépense est décentralisée, et souvent invisible. Le FinOps ne cherche pas à recentraliser ces décisions, ce qui ferait perdre l’agilité du cloud, mais à les rendre visibles et responsables.

Le cadre de la FinOps Foundation décrit un cycle en trois phases qui se répètent.

• Informerrendre la dépense visible et l’attribuer
• Optimiserréduire ce qui ne sert pas, payer moins cher ce qui sert
• Exploiterinstaller les règles, les rôles et la routine

Informer : savoir qui dépense quoi

Aucune discussion utile n’est possible tant que la facture reste un total. La première étape consiste à pouvoir répondre, pour chaque ligne de dépense, à trois questions : quelle application, quelle équipe, quel environnement (production, test, développement).

L’outil principal est l’étiquetage des ressources : chaque serveur, base de données ou espace de stockage porte des étiquettes normalisées (application, centre de coût, environnement, responsable). Une règle simple s’impose : une ressource non étiquetée n’a pas de propriétaire, et une ressource sans propriétaire est candidate à l’arrêt. Les fournisseurs permettent d’imposer des étiquettes à la création ; il faut en profiter dès le départ, car étiqueter après coup un parc existant est fastidieux.

Viennent ensuite les rapports : par équipe, par application, par environnement, avec leur évolution mensuelle. Pour les organisations qui utilisent plusieurs fournisseurs, la spécification FOCUS (FinOps Open Cost and Usage Specification), publiée en version 1.0 en juin 2024, propose un format commun pour les données de facturation, ce qui facilite la consolidation.

Enfin, des alertes budgétaires par équipe et par application préviennent les dérives avant la facture du mois suivant. Elles coûtent peu à mettre en place et évitent les surprises les plus douloureuses.

Optimiser : réduire, puis payer moins cher

Les leviers d’optimisation se répartissent en deux familles : consommer moins, et payer moins cher ce que l’on consomme. L’ordre compte : s’engager sur des volumes avant d’avoir réduit l’usage revient à figer le gaspillage.

Supprimer ce qui ne sert à rien. Serveurs arrêtés mais dont les disques restent facturés, instantanés de sauvegarde accumulés, adresses réservées non utilisées, environnements de projets terminés. C’est souvent le gisement le plus rapide.

Éteindre ce qui ne sert pas en permanence. Les environnements de développement et de test n’ont souvent pas besoin de tourner la nuit et le week-end. Un arrêt automatique en dehors des heures de travail réduit fortement leur coût, puisque ces heures représentent la majorité de la semaine.

Ajuster la taille. Les ressources sont souvent surdimensionnées par prudence au moment de leur création. Les mesures d’utilisation réelles (processeur, mémoire) permettent de choisir une taille adaptée, avec une marge raisonnable.

Choisir le bon type de stockage. Les données rarement consultées peuvent être déplacées vers des classes de stockage moins chères, selon des règles de cycle de vie automatiques. Attention aux frais de récupération de ces classes, et aux frais de sortie de données vers l’extérieur, souvent oubliés dans les estimations.

S’engager sur la part stable. Les fournisseurs proposent des remises importantes en échange d’un engagement d’usage sur un ou trois ans. Elles sont intéressantes pour la charge de base, stable et prévisible ; risquées pour ce qui peut diminuer, migrer ou disparaître.

Revoir l’architecture. À plus long terme, certains choix d’architecture coûtent cher par nature : transferts de données entre régions, services gérés surdimensionnés, traitements qui tournent en permanence alors qu’ils pourraient être déclenchés à la demande. Ces sujets relèvent de la conception, et se discutent avec les équipes de développement.

Exploiter : une routine plutôt qu’un projet

Une campagne d’optimisation ponctuelle produit des gains réels, qui s’érodent en quelques mois si rien ne change dans la manière de travailler. La dernière phase consiste à installer une routine.

Elle repose sur quelques rôles. Les équipes techniques sont responsables de la dépense de leurs applications, avec la visibilité pour la piloter. La finance prévoit, alloue et suit, en comprenant que la dépense cloud varie avec l’usage. Les métiers arbitrent entre coût et valeur : un service plus rapide ou plus disponible coûte plus cher, et c’est à eux de dire si cela en vaut la peine. Une fonction FinOps, qui peut être une personne à temps partiel dans une organisation moyenne, anime le dispositif, tient les règles et produit les rapports.

La routine type est une revue mensuelle par équipe : évolution de la dépense, écarts au budget, recommandations d’optimisation en attente, décisions prises. Les indicateurs les plus utiles relient la dépense à l’activité : coût par usager servi, par dossier traité, par transaction. Ils permettent de distinguer une hausse liée à la croissance d’une hausse liée à l’inefficacité.

Les particularités du secteur public

Pour une administration, le cloud pose une difficulté propre : le budget est voté à l’avance, alors que la dépense varie avec l’usage. Quelques pratiques aident à concilier les deux. Prévoir une marge et des alertes plutôt qu’un plafond rigide qui bloquerait un service en fin d’année. Passer par des marchés qui permettent d’ajuster les volumes. Suivre la dépense par service public rendu, ce qui facilite la justification devant les instances de contrôle. Et intégrer dès le départ les coûts de sortie et de réversibilité dans le calcul, comme pour tout achat numérique.

Par où commencer

• Une règle d’étiquetage est définie et imposée à la création des ressources
• La facture peut être lue par application, par équipe et par environnement
• Des alertes budgétaires sont configurées pour chaque équipe
• Les ressources inutilisées ont été identifiées et supprimées
• Les environnements hors production s’arrêtent automatiquement hors des heures de travail
• Une revue mensuelle réunit technique, finance et métiers
• Les engagements de consommation ne portent que sur la charge stable, après optimisation

Le FinOps prolonge une réflexion plus large sur la maîtrise de son architecture, que nous avons développée dans notre dossier sur les données et le cloud, et rejoint la question des modèles de licences. Pour installer cette discipline au sein de vos équipes jusqu’à ce qu’elles la conduisent seules, notre façon de travailler en équipes déployées est adaptée.

Questions fréquentes

Le FinOps est-il réservé aux grandes entreprises ?

Non. Les principes s'appliquent dès que la dépense cloud devient significative ou difficile à expliquer. Pour une petite organisation, quelques règles d'étiquetage, une revue mensuelle de la facture et des alertes budgétaires suffisent souvent à éviter les mauvaises surprises.

Faut-il acheter un outil de FinOps ?

Pas au départ. Les consoles des fournisseurs de cloud offrent des rapports de coûts, des budgets et des recommandations. Un outil dédié devient utile quand l'organisation utilise plusieurs fournisseurs ou a besoin de répartitions fines entre équipes. L'essentiel est l'organisation, pas l'outil.

Les engagements de consommation sont-ils toujours rentables ?

Ils réduisent le prix unitaire en échange d'un engagement d'usage sur une ou plusieurs années. Ils sont rentables pour une charge stable et prévisible, risqués pour une charge qui peut diminuer ou migrer. Il vaut mieux optimiser l'usage d'abord, puis s'engager sur ce qui reste.