FinOps : comment arrêter de pleurer devant sa facture cloud (et reprendre le contrôle)

Le cloud, cette arnaque... ou pas

Soyons honnêtes : quand on a vendu le cloud à tout le monde il y a dix ans, on a oublié de préciser un petit détail. Oui, c'est flexible. Oui, c'est scalable. Mais c'est surtout incroyablement facile de dépenser de l'argent sans s'en rendre compte. Une instance qu'on oublie d'éteindre, un volume de stockage orphelin, un load balancer qui tourne pour rien depuis huit mois... et paf, la facture double.

C'est exactement pour ça que le FinOps (contraction de Finance et DevOps) est devenu un sujet brûlant en 2024-2025. Ce n'est pas juste un mot à la mode pour remplir des slides de conférence tech : c'est une vraie méthodologie pour reprendre la main sur ses coûts cloud, sans pour autant sacrifier la performance ou la vélocité des équipes.

Le FinOps, c'est quoi concrètement ?

Le FinOps, ce n'est pas un outil qu'on installe et qui règle tout par magie. C'est une culture, une façon de faire collaborer trois mondes qui, historiquement, ne se parlaient pas vraiment :

• Les devs/ops, qui créent et consomment les ressources cloud
• La finance, qui doit prévoir et justifier les dépenses
• Le business, qui veut savoir combien coûte réellement chaque fonctionnalité ou chaque client

La Fondation FinOps (oui, ça existe officiellement, rattachée à la Linux Foundation) résume ça en trois phases qui tournent en boucle : Inform, Optimize, Operate. En gros : on comprend où part l'argent, on optimise, on opère en continu, et on recommence. Pas de "on a réglé le problème une fois pour toutes", désolé.

Pourquoi votre facture cloud explose (les coupables habituels)

1. Les ressources zombies

Des instances EC2 qui tournent depuis un POC abandonné en 2022. Des snapshots EBS qu'on garde "au cas où". Des IP publiques réservées mais non attachées. Ces petites choses coûtent individuellement pas grand-chose, mais multipliées par 200 ressources oubliées sur plusieurs comptes... ça chiffre vite.

2. Le sur-provisionnement

Par peur de manquer de ressources, on prend large. Très large. Résultat : des instances en m5.2xlarge qui tournent à 8% de CPU en moyenne. Le cloud provider vous remercie, votre budget beaucoup moins.

3. L'absence de tagging

Sans tags cohérents sur vos ressources, impossible de savoir quel projet, quelle équipe ou quel client consomme quoi. C'est un peu comme recevoir une facture de restaurant sans détail des plats : on sait juste que ça fait mal au portefeuille.

# Exemple de tagging AWS basique mais efficace
aws ec2 create-tags \
  --resources i-0123456789abcdef0 \
  --tags Key=Project,Value=app-ecommerce \
         Key=Environment,Value=production \
         Key=Team,Value=backend \
         Key=CostCenter,Value=CC-4521

4. Les instances on-demand partout

Utiliser uniquement des instances à la demande, c'est comme payer le prix public plein pot à chaque fois alors qu'il existe des abonnements. Les Reserved Instances, Savings Plans ou instances Spot peuvent réduire la facture de 30 à 70% sur les charges prévisibles.

Les leviers concrets pour reprendre le contrôle

Le right-sizing, votre meilleur ami

L'idée est simple : analyser l'utilisation réelle des ressources (CPU, RAM, I/O) et ajuster la taille des instances en conséquence. Les outils natifs comme AWS Compute Optimizer ou Azure Advisor font ce travail automatiquement et vous proposent des recommandations chiffrées.

# Exemple avec AWS CLI pour lister les recommandations
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:eu-west-3:123456789012:instance/i-0123456789abcdef0

L'autoscaling intelligent

Pourquoi payer pour une capacité maximale 24h/24 si votre trafic n'est fort que de 9h à 18h ? Les groupes d'autoscaling permettent d'ajuster dynamiquement le nombre d'instances selon la charge réelle.

// Exemple de config Kubernetes HPA (Horizontal Pod Autoscaler)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

Les budgets et alertes proactives

Plutôt que de découvrir le drame en fin de mois, configurez des budgets avec seuils d'alerte. AWS Budgets, Azure Cost Management ou GCP Budgets permettent d'être notifié avant que ça dérape vraiment.

{
  "BudgetName": "Budget-Mensuel-Production",
  "BudgetLimit": {
    "Amount": "5000",
    "Unit": "EUR"
  },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST",
  "NotificationsWithSubscribers": [
    {
      "Notification": {
        "NotificationType": "ACTUAL",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 80
      }
    }
  ]
}

Le choix du bon service, pas forcément le plus "cool"

Kubernetes, c'est génial pour l'orchestration à grande échelle. Mais si votre app ne traite que quelques milliers de requêtes par jour, un bon vieux serverless (AWS Lambda, Cloud Run) ou même un PaaS simple comme Render peut coûter dix fois moins cher et vous éviter de gérer un cluster entier pour trois bouts de ficelle.

Les outils FinOps qui valent le détour

Au-delà des dashboards natifs de chaque cloud provider (qui restent indispensables), plusieurs outils tiers se sont taillé une belle réputation :

• CloudHealth (VMware) : pour une vision multi-cloud consolidée
• Kubecost : spécialisé dans l'allocation des coûts Kubernetes, très utile pour savoir quel namespace ou quel pod plombe votre budget
• Infracost : qui s'intègre directement dans votre pipeline Terraform pour estimer le coût d'une infra avant de la déployer

# Exemple d'utilisation d'Infracost dans un pipeline CI
infracost breakdown --path . \
  --format table \
  --out-file infracost-report.txt

Le FinOps, une histoire de culture plus que de technique

Le point le plus important à retenir : aucun outil ne remplacera une vraie culture de responsabilisation. Chaque équipe dev doit avoir une visibilité sur le coût de ce qu'elle déploie, un peu comme on apprend aux enfants à éteindre la lumière en sortant d'une pièce. Ça passe par des dashboards accessibles, des revues de coûts régulières (mensuelles, voire hebdomadaires sur les projets sensibles), et surtout par le fait de ne plus traiter le cloud comme une ressource infinie et gratuite.

En résumé

Le cloud n'est ni une arnaque, ni une solution magique : c'est un outil puissant qui demande une vraie discipline pour être rentable sur le long terme. Entre right-sizing, autoscaling, tagging rigoureux et choix d'instances adaptés, les leviers d'optimisation sont nombreux et souvent sous-exploités. Chez YouOnline, on accompagne régulièrement nos clients dans l'audit et l'optimisation de leur infrastructure cloud — parce qu'une infra performante, c'est bien, mais une infra performante et maîtrisée côté budget, c'est encore mieux.