Le FinOps en une définition
La FinOps Foundation définit le FinOps comme un cadre opérationnel et une pratique culturelle qui maximisent la valeur métier de la technologie. Le mot réunit Finance et DevOps. Il désigne une façon de travailler : ni un poste, ni un outil.
La fondation insiste : le FinOps ne se résume pas à économiser. Une entreprise peut serrer ses dépenses une année et investir davantage la suivante. L’important est que les équipes arbitrent entre vitesse, coût et qualité avec des données fiables et des responsabilités claires.
Né avec le cloud public, le FinOps couvre aujourd’hui toute la dépense technologique, dont le SaaS, les licences et les centres de données. Le cadre de la fondation décrit des rôles qui vont de l’ingénierie à la finance, en passant par le produit, les achats et la direction.
Les six principes
Le cadre repose sur six principes. Les voici en mots simples :
- Les équipes travaillent ensemble : ingénierie, finance et métier partagent les mêmes chiffres.
- La valeur métier guide les décisions. Une facture qui monte peut être une bonne nouvelle.
- Chacun répond de son usage : qui exploite un service assume ce qu’il coûte.
- Les données de coût restent faciles d’accès, récentes et justes.
- Une équipe centrale outille la pratique, fixe les standards et aide les autres.
- Les équipes tirent parti du coût variable du cloud.
Inform, Optimize, Operate : les trois phases
Le cadre 2026 range ses capacités en quatre domaines : comprendre l’usage et le coût, quantifier la valeur métier, optimiser l’usage et le coût, piloter la pratique FinOps. Il définit aussi des périmètres (scopes), c’est-à-dire des segments de la dépense, comme un produit ou un centre de coût. L’approche Crawl, Walk, Run invite à commencer petit et à grandir quand la valeur le justifie.
Le travail suit trois phases, en boucle :
- Inform : comprendre les coûts, l’usage et l’efficacité, et les relier à des responsables.
- Optimize : trouver des gains, sur ce que vous consommez comme sur le prix que vous payez.
- Operate : appliquer les changements, puis relancer le cycle.
Pourquoi Kubernetes complique le FinOps
Une facture cloud liste des machines. Kubernetes partage ces machines entre de nombreuses équipes. Le groupe de travail de la fondation sur les conteneurs le rappelle : un conteneur n’a pas de coût direct, et rien ne relie simplement une ligne de facture à un workload. L’allocation demande donc une règle.
Décidez aussi qui porte la capacité inoccupée et les coûts partagés. Le groupe de travail cite les nœuds de gestion, le stockage de l’état du cluster, les licences, les sauvegardes et la reprise après sinistre. Namespaces et labels font le lien avec les équipes, centres de coût, applications et environnements.
Premier choix, la base de répartition :
- Les requests : tout le coût du cluster trouve un responsable, et les équipes ont intérêt à demander le nécessaire. Le risque : des requests trop basses, ou absentes.
- L’usage réel : chaque équipe paie ce qu’elle consomme. Reste à savoir qui paie le temps inoccupé, et des équipes peuvent réserver large sans en porter le coût.
Commencer avec un cluster
Une équipe FinOps n’est pas nécessaire pour démarrer. Un seul périmètre suffit à une première boucle.
Traitez l’usage avant le tarif. Requests trop hautes, workloads inactifs et environnements allumés la nuit passent avant les engagements, sinon vous figez le gaspillage. Suivez un coût unitaire dès que possible, par exemple un coût par client.
Une première boucle ressemble à ceci :
- Choisissez un périmètre : un produit ou un cluster de production.
- Nommez un responsable par namespace et ajoutez les labels manquants.
- Fixez la règle d’allocation avec la finance et écrivez-la.
- Passez en revue quelques coûts avec les ingénieurs, à rythme fixe.
- Choisissez une action, notez le résultat attendu, vérifiez-le ensuite.
Ce qu’apporte Onicost à cette boucle
Onicost couvre Kubernetes et le cloud dans deux espaces séparés. Pour Inform, il montre des coûts estimés par cluster, nœud, namespace, workload et label. Il sépare ce qui fait tourner vos applications, ce qui soutient le système et ce qui reste inutilisé. Les prix viennent des tarifs publics d’AWS, Azure, Google Cloud, OVHcloud et Scaleway, ou des vôtres pour des nœuds sur site.
Pour Optimize, les recommandations portent sur les requests, les nœuds, la santé et le gaspillage, avec des économies estimées et sans garantie. L’espace Cloud propose des engagements. Pour Operate, le scheduler arrête des environnements selon votre calendrier, et les exports CSV et rapports PDF nourrissent vos revues. Votre équipe applique les recommandations avec ses outils.
Les données restent en France, chez Scaleway, en région de Paris, pendant 13 mois. Free couvre 1 cluster, 32 cœurs et 2 membres. Team débute à 39 € HT par mois et Business à 99 € HT par mois, avec un essai Team de 14 jours sans carte.
Questions fréquentes
Le FinOps sert-il seulement à réduire les coûts ?
Non. La FinOps Foundation le présente comme un moyen de tirer plus de valeur de la technologie. Selon la période, cela mène à dépenser moins ou à investir davantage.
Faut-il une équipe FinOps dédiée ?
Pas au départ. La fondation décrit un groupe central qui soutient la pratique, pendant que chaque équipe répond de son usage. Dans une petite structure, une personne peut tenir ce rôle à temps partiel.
Quelle différence avec DevOps ?
DevOps rapproche développement et exploitation. Le FinOps ajoute la finance et le métier à cette discussion, autour du coût et de la valeur.
Comment répartir le coût d’un cluster entre équipes ?
Choisissez une base, requests ou usage réel, puis une règle pour la capacité inoccupée et les coûts partagés. Commencez simple et écrivez la règle avant de comparer les équipes.