TL;DR
Le FinOps est une discipline organisationnelle, pas un outil. Le framework de la FinOps Foundation l’articule en trois phases (informer, optimiser, opérer) et six étapes opérationnelles. La majorité des environnements cloud présente une sous-utilisation structurelle : instances surdimensionnées, environnements hors-production maintenus 24/7, snapshots oubliés, données chaudes alors qu’elles devraient être tièdes ou froides. Récupérer 20 à 30 % de la facture annuelle sans dégradation de service est donc réaliste si la méthode est appliquée. Les anti-patterns les plus coûteux sont la centralisation isolée (sans relais dans les équipes produit), l’optimisation par bridage et l’angle mort sur les coûts cachés (egress, requêtes, snapshots, transferts inter-zones).
FinOps : la définition courte
Le FinOps Foundation, organisation rattachée à la Linux Foundation, publie depuis 2019 un framework de référence [1]. Il définit FinOps comme “une discipline opérationnelle et une pratique culturelle qui maximise la valeur business des dépenses cloud en permettant la prise de décision rapide basée sur les données, avec une responsabilité partagée entre équipes d’ingénierie, finance et métier”.
Trois phases structurent la pratique [2].
Informer. Visibilité, allocation, benchmarking. C’est la phase où l’on rend les coûts compréhensibles : qui consomme quoi, pour quel produit, à quel rythme.
Optimiser. Actions concrètes : rightsizing, engagements, suppression des ressources orphelines, tiering du stockage, refactoring d’architecture quand le retour sur investissement le justifie.
Opérer. Industrialisation : politiques, automatismes, intégration dans les pipelines, gouvernance continue. Le passage de l’optimisation ponctuelle à une discipline durable.
La maturité FinOps se mesure sur trois niveaux : crawl (visibilité partielle, actions ponctuelles), walk (allocation complète, optimisations régulières), run (gouvernance industrialisée, FinOps as Code) [3].
Pourquoi 20 à 30 % d’économies sont réalistes
Le chiffre n’est pas marketing. Il s’explique par trois sources structurelles de gaspillage.
Sous-utilisation des instances de calcul. Les recommandations natives des hyperscalers (AWS Compute Optimizer, Azure Advisor, Google Active Assist) identifient régulièrement des instances dont l’usage CPU moyen ne dépasse pas 20 ou 30 %. Une instance dimensionnée à m5.4xlarge alors qu’une m5.2xlarge suffirait représente un surcoût direct de 50 %.
Services oubliés. Volumes EBS non attachés, snapshots accumulés sur des années, NAT Gateways orphelins, IP publiques réservées non utilisées, environnements de test maintenus la nuit et le week-end. Le cumul est rarement négligeable.
Engagements absents ou mal calibrés. Une charge stable payée en tarification on-demand alors qu’un Savings Plan 1 ou 3 ans aurait fait économiser 30 à 70 % selon la durée et le degré d’engagement.
Ces trois sources cumulées expliquent l’ordre de grandeur. Les hyperscalers eux-mêmes documentent ces leviers dans leurs guides d’optimisation (AWS Well-Architected Cost Optimization Pillar, Azure Cost Management documentation, Google Cloud cost optimization framework).
Étape 1 : Tagging et allocation
Sans tagging cohérent, aucune phase Informer n’est exploitable. Une politique de tagging minimale couvre cinq dimensions.
Application ou produit. Le service métier auquel la ressource contribue. Un identifiant stable, idéalement aligné sur le CMDB ou le portfolio produit.
Environnement. Production, recette, dev, test, sandbox. Permet de distinguer les charges critiques des charges éphémères.
Centre de coût ou équipe. Pour le showback ou le chargeback. Sans cette dimension, la responsabilisation est impossible.
Owner. Email ou identifiant d’une personne ou d’une équipe responsable. Sert au cleanup, aux questions, aux alertes.
Tier de criticité. Critique, standard, best-effort. Oriente les arbitrages : on n’applique pas le même niveau d’engagement ni la même tolérance d’extinction nocturne sur une charge critique et un environnement de test.
L’application se fait par convention dès la création (Terraform, ARM, Cloud Formation) avec contrôle d’admission (politiques natives type AWS Organizations SCP, Azure Policy, Google Organization Policy) qui refuse la création sans tags. Le tagging rétroactif est possible mais douloureux : autant l’imposer à la création.
Étape 2 : Visibilité par équipe et par produit
Trois modes d’allocation coexistent.
Showback. Chaque équipe voit ses coûts sans contrepartie budgétaire. Outil de prise de conscience. Suffisant dans une organisation où le budget cloud reste centralisé.
Chargeback. Les coûts sont refacturés aux équipes ou aux unités d’affaires. Modèle plus exigeant : nécessite une politique d’allocation des coûts partagés (réseau, IAM, monitoring central), un mécanisme de prévision, et une acceptation interne. Souvent réservé aux organisations matures.
Modèle mixte. Une partie en chargeback (compute, stockage applicatif), une partie en frais généraux (réseau central, sécurité, plateforme de données mutualisée). Le mode le plus courant en pratique.
Les outils natifs (AWS Cost Explorer, Azure Cost Management, Google Cloud Billing) couvrent un cas simple. Au-delà, les solutions tierces (Vantage, CloudHealth, Apptio Cloudability, ou OpenCost en open source pour Kubernetes) offrent l’allocation par namespace, le déversement vers un data warehouse pour des dashboards personnalisés, et la prévision.
Étape 3 : Rightsizing
Le rightsizing ajuste les ressources allouées au besoin réel mesuré. Il s’applique à toutes les ressources élastiques du cloud, pas seulement au compute.
Compute. Réduction de la taille d’instance quand l’usage CPU et mémoire pic ne dépasse pas un seuil (typiquement 60 à 70 %) sur une fenêtre observée (7 à 14 jours minimum). Les recommandations natives fournissent un point de départ ; elles ignorent toutefois les usages métier (pics de fin de mois, traitements batch nocturnes). Toujours valider avant application. Les familles d’instances génèrent également des opportunités : les générations récentes (m7i, m7g, t4g, n2 chez Google, Dasv5 chez Azure) offrent un meilleur ratio prix/perf que les générations précédentes, à charge équivalente.
Mémoire. Souvent oubliée parce que l’agent de monitoring par défaut ne la collecte pas sur EC2 et Compute Engine. Activer la collecte mémoire avant tout rightsizing applicatif. Les agents CloudWatch Agent (AWS), Ops Agent (Google), Azure Monitor Agent doivent être déployés systématiquement, idéalement via une politique d’infrastructure-as-code qui les pousse à la création de chaque instance.
IOPS et débit stockage. Sur EBS et Persistent Disk, les classes gp3 (AWS) et pd-balanced ou pd-ssd (Google) permettent un ajustement plus fin du débit et des IOPS que les classes historiques. Migration souvent rentable. Sur gp2, le débit et les IOPS sont liés à la taille du volume ; sur gp3, ils sont configurables indépendamment, ce qui évite de surdimensionner un volume juste pour obtenir le débit nécessaire.
Bases managées. Vérifier si la classe RDS, Cloud SQL ou Azure SQL Database est dimensionnée à la pointe ou au baseline. Les classes burstable (db.t4g, db-g1-small) sont rentables sur des charges intermittentes mais piégeuses sur des charges soutenues (consommation des crédits CPU). Les options de stockage (gp3 vs io2 sur RDS, SSD vs HDD sur Cloud SQL) offrent un levier supplémentaire. La haute disponibilité multi-AZ double quasiment le coût de la base : à activer uniquement quand la criticité le justifie.
Architectures serverless et conteneurs. Pour les workloads Lambda, Cloud Run, Cloud Functions, Azure Functions, le rightsizing consiste à ajuster la mémoire allouée (qui détermine aussi le CPU) et le timeout. Une fonction allouée à 1024 Mo alors que la consommation pic est 256 Mo représente un surcoût direct. Pour Kubernetes, le rightsizing des Resource Requests et Limits suit le même principe mais avec des outils dédiés (Vertical Pod Autoscaler en mode recommendation, Goldilocks, KubeCost).
Le rightsizing n’est pas un événement. C’est une boucle : mesure, recommandation, application, contrôle de la perf après. Une fréquence trimestrielle est un bon point d’équilibre. Sur les workloads volatils (croissance rapide, refactoring fréquent), une revue mensuelle peut se justifier.
Étape 4 : Engagements (Reserved Instances, Savings Plans)
Les engagements pré-payés ou contractuels offrent des remises de 20 à 70 % selon la durée (1 ou 3 ans) et le degré d’engagement (no upfront, partial, all upfront).
AWS. Savings Plans (Compute, EC2 Instance) plus flexibles que les Reserved Instances historiques. Un Compute Savings Plan engage un débit horaire de dépense ($/h) toutes familles d’instances confondues.
Google Cloud. Committed Use Discounts (CUD) ressource-based ou spend-based. Les spend-based CUDs (équivalent fonctionnel des Savings Plans) couvrent plusieurs services compute simultanément.
Azure. Reservations sur VM, SQL Database, Cosmos DB. Savings Plans for Compute sur les ressources de calcul.
Règles pratiques.
Calibrer sur le baseline stable, jamais sur les pics. Un workload qui consomme 100 unités en baseline et 200 en pic justifie un engagement à hauteur de 70 à 80 unités. Engager 100 % du baseline expose à un over-commitment si la consommation baisse.
Coverage cible 70 à 80 %. Au-delà, le risque de payer pour du non-consommé devient supérieur au gain marginal.
Mix 1 an et 3 ans. Les engagements 3 ans offrent le plus de remise mais réduisent la flexibilité. Une moitié 3 ans (sur le coeur stable très ancien), une moitié 1 an (sur les charges plus récentes) est un point d’équilibre fréquent.
Revue trimestrielle. Les engagements existants sont revus à chaque trimestre : marketplace AWS pour revente de RI standard, conversion possible sur les Savings Plans, échange sur les Reservations Azure.
Étape 5 : Optimisation des données
Le stockage représente une part durable de la facture, souvent négligée parce que les actions sont moins immédiates que sur le compute.
Tiering. S3, Cloud Storage, Blob Storage exposent plusieurs classes (Standard, Infrequent Access, Archive, Deep Archive ou Glacier). Une donnée écrite il y a plus de 90 jours et jamais relue mérite l’archive. Les politiques de lifecycle automatisent la transition.
Lifecycle automatique. Tout bucket de production doit avoir une politique de lifecycle. Suppression automatique des versions précédentes après n jours, suppression des incomplete multipart uploads, transition vers Infrequent Access après 30 ou 90 jours selon le profil d’accès.
Snapshots. EBS Snapshots et équivalents s’accumulent. Une politique de rétention (conserver les snapshots quotidiens 14 jours, hebdomadaires 8 semaines, mensuels 12 mois, annuels 7 ans) couvre la plupart des besoins de reprise sans accumulation indéfinie.
Bases managées. Vérifier la rétention des sauvegardes automatiques RDS/Cloud SQL/Azure SQL : par défaut 7 jours, parfois étendu à 35. Une rétention 35 jours sur toutes les bases coûte cher si elle n’est pas justifiée par des exigences de reprise.
Archives froides. Glacier Deep Archive, Archive Storage de Google, Azure Archive : remise majeure sur le stockage mais coûts de récupération non négligeables. Adaptés aux données rarement lues mais légalement conservables (logs, archives comptables, données médicales).
Étape 6 : Gouvernance continue
Sans gouvernance, les gains d’optimisation s’érodent : nouvelles ressources mal taggées, environnements de dev oubliés, instances surdimensionnées par défaut. Le rythme de drift dans un environnement cloud actif est rapide ; sans cycle de revue, un environnement optimisé en janvier peut avoir perdu 10 à 15 % de son efficacité en juin.
Revue mensuelle. Tableau de bord avec coûts par produit, écart vs prévision, top 10 des ressources les plus chères, recommandations natives ouvertes. La revue intègre les équipes produit et plateforme, pas uniquement la finance. Les écarts vs prévision supérieurs à 10 % déclenchent une investigation systématique : nouvelle feature, incident de configuration, ressource oubliée.
Objectifs trimestriels. Coverage des engagements, taux d’utilisation moyen, part du stockage en classe IA ou Archive, nombre de ressources non taggées. Chaque objectif a un porteur (FinOps practitioner, lead d’équipe produit, plateforme). Les objectifs sont publiés et leur progression suivie publiquement dans l’organisation.
FinOps as Code. Intégration des contrôles de coût dans le pipeline. Infracost estime le coût d’un changement Terraform avant merge [4]. Une PR qui augmente la facture mensuelle de 500 euros est annotée automatiquement, ce qui replace la décision dans le contexte de revue normal. Cloud Custodian applique des politiques (extinction automatique des environnements dev hors heures ouvrées, suppression des snapshots non taggés, alerte sur les ressources orphelines) sans intervention humaine [5]. OpenCost alloue les coûts par namespace et par workload Kubernetes [6], indispensable dès qu’un cluster héberge plusieurs équipes ou produits. Les trois constituent un trio open source mature, déployable sans engagement éditeur.
Comité FinOps. Représentants ingénierie, finance, métier. Cadence mensuelle. Décisions tracées : engagements à prendre, arbitrages de migration, allocation des budgets. Le comité n’est pas un organe de validation à posteriori mais un lieu de décision : tradeoffs entre vitesse de livraison et optimisation, choix d’investissement plateforme, exceptions aux politiques par défaut.
Anti-patterns fréquents
Centralisation seule. Une équipe FinOps isolée qui produit des rapports sans relais dans les équipes produit reste inopérante. Le FinOps repose sur la responsabilité partagée : la centrale fournit les outils et le cadre, les équipes produit prennent les décisions de leur périmètre.
FinOps déconnecté du business. Optimiser sans connaître les enjeux métier conduit à des arbitrages aveugles. Une migration de classe d’instance qui économise 15 % mais ajoute 100 ms de latence sur un parcours critique n’est pas une économie : c’est un transfert de coût vers le revenu.
Optimisation = bridage. Couper les environnements dev la nuit oui, brider la production non. Le FinOps maximise la valeur, pas seulement le coût.
Oubli des coûts cachés. L’egress (sortie de données), les requêtes API (S3, DynamoDB), les snapshots EBS, les transferts inter-zones, le NAT Gateway, le Cross-Region Replication : ces lignes ne sortent pas dans les top par ressource mais cumulées elles peuvent dépasser le compute. Tout audit FinOps sérieux les inclut.
Confondre dépense et valeur. Une baisse de facture peut masquer une dette technique différée (par exemple basculer en spot sans gérer l’interruption). Mesurer la valeur produite, pas seulement la dépense évitée.
FinOps, multi-cloud, souveraineté
Le FinOps précède le multi-cloud, pas l’inverse. Sans visibilité claire sur les coûts unitaires d’un fournisseur, comparer avec un second relève de la spéculation. Voir l’article dédié sur Multi-cloud : architecture résiliente et exit strategy hyperscaler.
Pour les organisations qui combinent hyperscaler et cloud souverain, le FinOps inter-cloud devient plus exigeant : les modèles tarifaires diffèrent (instance horaire vs forfait mensuel chez certains acteurs européens), les unités d’oeuvre ne sont pas comparables directement. Voir l’article dédié sur Cloud souverain France 2026 : panorama des options réelles.
À retenir
Le FinOps est une discipline d’allocation et de décision, pas un outil ou un dashboard. Le framework de la FinOps Foundation (informer, optimiser, opérer) en pose la structure ; les six étapes opérationnelles (tagging, visibilité, rightsizing, engagements, optimisation des données, gouvernance) en posent l’exécution. Une organisation qui démarre récupère typiquement 20 à 30 % de sa facture cloud sans dégradation de service, parce que la sous-utilisation est structurelle. Les leviers les plus lourds sont le rightsizing du compute, les engagements calibrés sur le baseline (70 à 80 % de coverage), le tiering du stockage et la suppression des ressources orphelines. La maturité s’industrialise via le FinOps as Code (Infracost, Cloud Custodian, OpenCost). Les pièges majeurs sont la centralisation isolée, l’optimisation par bridage et l’angle mort sur les coûts cachés (egress, requêtes, snapshots, transferts inter-zones).
[1] FinOps Foundation, FinOps Framework, finops.org/framework/. [2] FinOps Foundation, FinOps Principles, finops.org/framework/principles/. [3] FinOps Foundation, Maturity Model, finops.org/framework/maturity/. [4] Infracost, documentation officielle, infracost.io/docs/. [5] Cloud Custodian, documentation officielle, cloudcustodian.io/docs/. [6] OpenCost, documentation officielle, opencost.io/docs/.