Votre facture cloud augmente de 30% par an. C’est normal ?
Non. Et pourtant, c’est la réalité de la majorité des entreprises. Les dépenses cloud mondiales dépassent les 700 milliards de dollars, et selon les études du FinOps Foundation, 30 à 35% de ces dépenses sont du gaspillage.
Le problème n’est pas le cloud. Le cloud est un modèle économique brillant : vous payez ce que vous consommez. Le problème, c’est que personne ne regarde ce qui est consommé.
C’est là qu’intervient le FinOps.
Le FinOps, ce n’est pas du cost-cutting
Première confusion à dissiper. Le FinOps n’est pas une directive de la direction financière pour réduire les coûts. C’est une discipline opérationnelle qui aligne les dépenses cloud avec la valeur business générée.
La nuance est fondamentale. Le cost-cutting coupe aveuglément. Le FinOps optimise intelligemment. Parfois, la bonne décision FinOps est de dépenser plus — sur un service qui génère du revenu, par exemple.
Le FinOps ne demande pas combien vous dépensez. Il demande combien de valeur chaque euro dépensé génère.
Les 3 phases du FinOps
Le framework FinOps Foundation structure la démarche en trois phases itératives. Ce n’est pas un projet one-shot, c’est un cycle continu.
Phase 1 : Inform (Visibilité)
Vous ne pouvez pas optimiser ce que vous ne mesurez pas. Cette phase consiste à :
- Taguer systématiquement chaque ressource cloud (équipe, projet, environnement, cost center)
- Centraliser les données de facturation dans un outil unique
- Attribuer chaque euro à une équipe ou un service (showback)
- Visualiser les tendances et anomalies
Le tagging est la fondation. Sans tags cohérents, tout le reste est du bruit. Notre recommandation : 4 tags obligatoires minimum — team, project, environment, cost-center. Automatisez leur application avec des policies (AWS SCP, GCP Organization Policies).
Phase 2 : Optimize (Optimisation)
C’est la phase où les économies se matérialisent. Les leviers sont nombreux et cumulatifs.
Right-sizing — Le levier le plus simple et le plus rentable. 70% des instances cloud sont surdimensionnées. Une instance m5.xlarge qui utilise 10% de son CPU devrait être une m5.large ou une t3.medium. Les outils natifs (AWS Compute Optimizer, GCP Recommender) identifient ces opportunités automatiquement.
Reserved Instances / Committed Use Discounts — Pour les workloads stables et prévisibles, les engagements 1 ou 3 ans offrent 30 à 60% de réduction. La stratégie : couvrir votre baseline avec des réservations, garder le on-demand pour les pics.
Spot / Preemptible — Pour les workloads tolérants aux interruptions (batch, CI/CD, dev, data processing), les instances spot offrent 60 à 90% de réduction. Le risque d’interruption est réel mais gérable avec une architecture adaptée.
Nettoyage des ressources orphelines — Disques non attachés, snapshots oubliés, load balancers sans backend, IP élastiques non utilisées, environnements de dev qui tournent H24. Ce gaspillage silencieux représente souvent 10 à 15% de la facture.
Stockage intelligent — Les politiques de lifecycle sur S3/GCS (passage automatique en Infrequent Access puis Glacier/Archive) réduisent les coûts de stockage de 60 à 80% sur les données froides.
Phase 3 : Operate (Gouvernance)
L’optimisation sans gouvernance est éphémère. Les mauvaises habitudes reviennent en 3 mois. Cette phase met en place :
- Des budgets et alertes par équipe et par projet
- Des revues FinOps mensuelles avec les tech leads
- Des KPIs FinOps suivis en comité de direction
- Des politiques automatisées (arrêt des environnements de dev la nuit, suppression des ressources non taguées après 7 jours)
Quick wins : les 5 actions à faire cette semaine
Pas besoin d’un programme FinOps complet pour commencer. Ces 5 actions génèrent des résultats immédiats.
1. Identifier les ressources inutilisées
Connectez-vous à votre console cloud et cherchez :
- Les instances EC2/VMs éteintes mais avec des disques attachés
- Les snapshots de plus de 90 jours
- Les load balancers sans target healthy
- Les IP publiques non associées
Sur un compte AWS typique, cette recherche révèle entre 500 et 2 000 euros par mois de gaspillage.
2. Activer les recommandations natives
AWS Compute Optimizer, GCP Recommender, Azure Advisor — ces outils sont gratuits et donnent des recommandations de right-sizing immédiatement actionnables. Activez-les, lisez les recommandations, appliquez celles à faible risque.
3. Planifier l’extinction des environnements non-production
Vos environnements de dev, staging, QA tournent 24/7 ? Ils ne devraient tourner que pendant les heures de bureau. Un simple scheduler (AWS Instance Scheduler, GCP VM Schedule) réduit leur coût de 65%.
4. Vérifier la couverture de réservations
Si vos workloads de production sont 100% on-demand, vous payez le prix fort. Même un engagement flexible (Savings Plans AWS, CUD GCP) sur 1 an avec un commit modeste génère 20 à 30% d’économie immédiate.
5. Mettre en place des alertes budgétaires
Configurez une alerte à 80% et 100% du budget mensuel attendu. C’est basique, mais la majorité des entreprises ne l’ont pas. L’alerte ne réduit pas les coûts, mais elle évite les mauvaises surprises en fin de mois.
Les outils du FinOps
Outils natifs des cloud providers
- AWS Cost Explorer + AWS Budgets — Gratuits, suffisants pour commencer
- GCP Billing + BigQuery export — L’export vers BigQuery permet des analyses avancées
- Azure Cost Management — Bien intégré à l’écosystème Microsoft
Outils tiers
- Infracost — Estime le coût des changements d’infrastructure avant le déploiement, directement dans les pull requests. Indispensable pour une approche shift-left du FinOps
- Kubecost / OpenCost — Spécialisé Kubernetes. Attribue les coûts par namespace, deployment, pod. Open source
- CloudHealth (VMware) — Plateforme complète multi-cloud. Pour les grandes organisations
- Spot.io (NetApp) — Automatisation de l’utilisation des instances spot avec fallback intelligent
Infrastructure as Code + FinOps
L’IaC (Terraform, Pulumi) est le meilleur allié du FinOps. Quand toute l’infrastructure est codée :
- Les changements de sizing passent par des pull requests revues
- Infracost estime l’impact financier de chaque changement
- Les policies as code (OPA, Sentinel) bloquent les instances surdimensionnées
- Le drift detection identifie les ressources créées hors process
Le changement organisationnel
L’aspect le plus sous-estimé du FinOps est l’aspect humain. Les outils ne suffisent pas.
Showback vs Chargeback
Le showback montre à chaque équipe combien elle dépense, sans conséquence financière directe. C’est la première étape — créer la visibilité et la responsabilité.
Le chargeback impute les coûts cloud au budget de chaque équipe. C’est plus impactant mais plus complexe. Notre recommandation : commencer par le showback pendant 6 mois, puis passer au chargeback quand la culture FinOps est installée.
Le rôle du FinOps Practitioner
Quelqu’un doit porter le sujet. Pas nécessairement un poste dédié au début, mais une personne identifiée qui :
- Anime les revues FinOps mensuelles
- Maintient le dashboard de suivi
- Chasse les anomalies et les gaspillages
- Forme les équipes aux bonnes pratiques
La culture de la responsabilité
Le FinOps fonctionne quand les équipes de développement se sentent responsables de leurs dépenses cloud. Cela passe par :
- Des dashboards accessibles à tous (pas cachés dans un outil finance)
- Des objectifs FinOps dans les OKRs des équipes
- Des game days FinOps (challenge d’optimisation entre équipes)
- La célébration des optimisations réussies
Exemples concrets de résultats
E-commerce — Réduction de 42%
Un client e-commerce avec une facture AWS de 18 000 euros par mois. Après audit : 4 000 euros de ressources inutilisées, 3 000 euros récupérables en right-sizing, 2 500 euros avec des Savings Plans. Résultat : facture ramenée à 10 500 euros. Même performance, même disponibilité.
SaaS B2B — Réduction de 35%
Un éditeur SaaS sur GCP. Les environnements de dev représentaient 40% de la facture et tournaient 24/7. Le scheduling + le passage en preemptible VMs a réduit ce poste de 75%. Combiné au right-sizing de la production, la facture mensuelle est passée de 12 000 à 7 800 euros.
Startup — Évitement de 60%
Une startup en phase de scale. Avant le déploiement d’une nouvelle architecture, Infracost dans le CI a détecté que la configuration Terraform prévue coûterait 8 000 euros par mois au lieu des 3 000 estimés. Le right-sizing anticipé a évité un surcoût de 60 000 euros sur l’année.
Pièges à éviter
Optimiser trop tôt — N’achetez pas de Reserved Instances sur un workload qui n’est pas stabilisé. Attendez 3 mois de données avant de vous engager.
Ignorer le coût du temps ingénieur — Passer 2 jours à économiser 50 euros par mois n’est pas du FinOps, c’est de la perte de temps. Concentrez-vous sur les gros postes.
Confondre cheap et optimisé — Une instance sous-dimensionnée qui dégrade les performances coûte plus cher qu’une instance correctement dimensionnée. Le FinOps optimise le ratio coût/valeur, pas le coût absolu.
Négliger le réseau — Le data transfer entre régions et vers internet est souvent le poste oublié. Sur certains projets, il représente 20 à 30% de la facture.
Par où commencer
Le FinOps est un marathon, pas un sprint. Voici un plan en 90 jours :
- Mois 1 : Visibilité. Mettre en place le tagging, activer les outils natifs, identifier les quick wins
- Mois 2 : Optimisation. Appliquer le right-sizing, nettoyer les ressources orphelines, mettre en place le scheduling
- Mois 3 : Gouvernance. Installer les budgets et alertes, lancer la première revue FinOps, définir les KPIs
Au bout de 90 jours, la facture a baissé de 25 à 40% et les fondations sont posées pour une optimisation continue.
FAQ
Le FinOps concerne-t-il uniquement les grandes entreprises ?
Non. Toute entreprise qui dépense plus de 1 000 euros par mois en cloud bénéficie d’une approche FinOps. Les quick wins (ressources inutilisées, right-sizing, scheduling) sont accessibles à toutes les tailles d’organisation. La différence est dans la formalisation : une startup peut faire du FinOps avec un dashboard et une revue mensuelle, là où une grande entreprise aura une équipe dédiée et des outils spécialisés.
Quels sont les premiers outils à mettre en place ?
Commencez par les outils gratuits intégrés à votre cloud provider : AWS Cost Explorer, GCP Billing Reports ou Azure Cost Management. Ajoutez Infracost dans votre CI/CD pour estimer le coût des changements d’infrastructure avant déploiement. Si vous utilisez Kubernetes, installez OpenCost (gratuit, open source) pour la visibilité par service. N’investissez dans un outil tiers payant que lorsque vous avez épuisé les capacités des outils natifs, généralement au-delà de 50 000 euros par mois de dépenses cloud.
Comment convaincre la direction d’investir dans le FinOps ?
Chiffrez le gaspillage actuel. Faites un audit rapide (2-3 jours) pour identifier les ressources inutilisées et les opportunités de right-sizing. Présentez le montant récupérable et le ROI de la démarche. En général, un programme FinOps se rembourse en moins de 2 mois. L’argument qui porte : le FinOps ne réduit pas les capacités, il élimine le gaspillage. Chaque euro économisé peut être réinvesti dans l’innovation.
Quelle est la différence entre Reserved Instances et Savings Plans ?
Les Reserved Instances (AWS) ou Committed Use Discounts (GCP) sont liés à un type d’instance spécifique dans une région donnée. Les Savings Plans (AWS) offrent plus de flexibilité : vous vous engagez sur un montant horaire de dépense, applicable à n’importe quel type d’instance dans n’importe quelle région. Le discount est légèrement inférieur (30-40% vs 40-60%), mais la flexibilité réduit le risque de sous-utilisation. Notre recommandation : privilégiez les Savings Plans pour la production générale, et les Reserved Instances pour les workloads très stables dont le sizing ne changera pas.