Le constat

Dans beaucoup d’organisations, le FinOps arrive après coup. Les projets tournent depuis des mois, la facture grossit, et on découvre qu’une bonne partie des ressources n’a ni propriétaire ni centre de coût. Il faut alors retrouver qui a créé quoi, poser des labels à la main, et reconstruire l’historique.

L’idée de ce PoC est simple : traiter le FinOps comme une propriété de la plateforme, au même titre que la sécurité ou le réseau. Si chaque projet naît avec ses labels, son budget et ses garde-fous, la question « qui dépense quoi ? » a une réponse dès le premier jour.

La Landing Zone

Une Landing Zone, c’est le socle sur lequel les équipes déploient leurs projets : la hiérarchie, les droits, les règles communes. Ici, tout est en Terraform et appliqué par la CI.

flowchart TB
  gh["GitHub Actions"] -- "sans clé (WIF)" --> seed
  subgraph org["Organization GCP"]
    seed["Projet seed
state Terraform, identité de la CI"]
    subgraph envs["Folder environments"]
      dev["dev"]
      staging["staging"]
      prod["prod"]
    end
    subgraph shared["Folder shared"]
      mon["poc-monitoring
données et outils FinOps"]
    end
  end
  billing[("Compte de facturation
budget global + budget par projet")]
  dev & staging & prod & mon -. "coûts" .-> billing

Quelques choix et leur raison :

• Une vraie Organization, créée gratuitement avec Cloud Identity sur un domaine perso. Sans elle, pas de folders ni d’org policies, donc pas de gouvernance réaliste.
• Personne ne crée de projet à la main. Le droit de création est retiré à tout le domaine et réservé à l’équipe plateforme, via Terraform. Un projet hors Terraform est un projet hors FinOps.
• Des règles qui évitent les mauvaises surprises : une seule région autorisée, les services coûteux non utilisés bloqués, et des petites machines uniquement en dev. Le moins cher reste la ressource qu’on ne peut pas créer par erreur.
• Des groupes plutôt que des personnes. Les humains n’ont que de la lecture, les changements passent par une PR.
• Pas de clé de service account. La CI s’authentifie par fédération d’identité : rien à faire tourner, rien à fuiter.

Le FinOps as code

Des labels obligatoires

Toute ressource porte quatre labels : env, owner, cost-center et app. Ils sont posés par défaut dans chaque stack, et un contrôle en CI lit le plan Terraform avant l’apply : s’il manque un label, le plan n’est jamais appliqué.

C’est le point le plus important du projet. Le showback ne vaut que ce que vaut l’allocation, et l’allocation ne tient que si elle est imposée au moment de la création, pas corrigée après.

Un budget par projet

Chaque projet est créé avec son budget, et un budget global protège le compte de facturation. Le global protège la facture, les budgets par projet disent qui dérive. Un budget alerte, il ne coupe rien : c’est un signal, pas un frein.

Le pipeline de données

Toutes les données FinOps convergent vers un seul projet, poc-monitoring, dans le folder shared.

flowchart LR
  billing[("Compte de facturation")] -- "export natif" --> bq[("BigQuery
données de facturation")]
  bq --> views["Vues SQL
allocation par labels"]
  views --> showback["Dashboard Showback"]

  sched["Cloud Scheduler"] -- "chaque jour" --> anomaly["Fonction anomalies"]
  views --> anomaly
  anomaly -- "log" --> alert["Alerte Cloud Monitoring
email"]

  sched -- "chaque lundi" --> rs["Fonction rightsizing"]
  recommender["API Recommender
projets dev, staging, prod"] --> rs
  rs --> reco[("BigQuery
recommandations")]
  reco --> dash2["Dashboard Recommandations"]

Le principe : GCP sait déjà exporter sa facturation dans BigQuery et produire des recommandations. Plutôt que d’acheter un outil, on assemble ces briques natives, et on ajoute la seule chose qui manque : la logique d’allocation de l’organisation.

L’allocation

La vue centrale lit chaque ligne de coût et cherche son cost-center sur la ressource, sinon sur le projet, sinon la marque « non alloué ». Ce « non alloué » est volontairement visible : c’est l’indicateur de la qualité de la gouvernance. S’il monte, quelque chose échappe à la Landing Zone.

Les anomalies

Chaque matin, une fonction compare le coût moyen des 7 derniers jours à celui des 4 semaines précédentes, par projet, centre de coût et service. Au-delà de +20 %, une alerte part.

Deux détails ont compté :

• Comparer des semaines entières. Les environnements hors prod sont quasi éteints le week-end : comparer des jours isolés produit des faux positifs.
• Comparer le coût brut, avant remises. Un engagement d’usage donne une remise d’un montant fixe chaque jour. Prenons 100 € de coût par jour, dont 80 € couverts par la remise : il reste 20 € à payer. Si l’usage augmente de 5 %, le coût passe à 105 €, la remise reste à 80 €, et il reste 25 € à payer. L’usage a pris 5 %, mais le coût net a pris 25 %. Sur les données du PoC, 5 % d’usage en plus en prod apparaissait ainsi comme une hausse de 22 %, assez pour déclencher une fausse alerte.

La fonction se contente d’écrire un log, et c’est Cloud Monitoring qui alerte. Pas de webhook ni de serveur mail à gérer. Une seconde alerte signale si la détection elle-même échoue : une surveillance qui tombe en silence ne protège de rien.

Les dashboards

Les deux dashboards sont dans Looker Studio, gratuit et branché directement sur BigQuery.

Note : les projets du PoC ne consomment presque rien, et l’export de facturation ne contient pas d’historique avant son activation. Les dashboards tournent donc sur des données synthétiques, au schéma exact de l’export GCP. Changer de source ne change ni les vues ni les dashboards.

Showback

Le showback répond à « qui consomme quoi », sans refacturer. On y lit le coût par centre de coût et l’origine de l’allocation (ressource, projet ou non alloué), le coût par environnement, les services les plus chers, et la tendance dans le temps. Le pic début octobre est l’anomalie injectée en dev, celle que la fonction de détection doit attraper.

Le bas du dashboard suit les engagements d’usage (CUD). Il faut deux indicateurs pour les lire : le taux de couverture dit quelle part de l’usage profite d’une remise, l’économie nette dit si l’engagement rapporte. Un engagement couvert à 100 % mais en économie négative est un engagement surdimensionné, typiquement en staging où l’usage tombe le week-end alors que l’engagement se paie tous les jours.

Recommandations

Chaque lundi, une fonction récupère les recommandations de l’API Recommender : VM surdimensionnées ou inactives, disques non attachés, IP réservées inutilisées. Elles sont historisées pour suivre dans le temps l’économie potentielle (ACTIVE), réalisée (SUCCEEDED) ou écartée (DISMISSED).

Le tableau trie les actions par gain mensuel. Il rend aussi visible un problème de gouvernance : les recommandations du projet legacy-sandbox, sans labels ni propriétaire, ne sont jamais traitées. Personne ne se sent concerné par une ressource qui n’appartient à personne.

Ce que j’en retiens

• Le FinOps commence à la création des ressources, pas dans le dashboard. Les labels imposés en CI font tout le travail en amont.
• Les briques natives suffisent pour un premier niveau de maturité : export de facturation, BigQuery, Recommender, Monitoring et Looker Studio, pour un coût quasi nul.
• Le « non alloué » est un indicateur, pas un résidu : c’est lui qui mesure si la gouvernance tient.
• Une alerte doit être juste avant d’être fréquente. Les deux faux positifs évités (week-end et remises) auraient suffi à faire ignorer les alertes.