FinOps de la donnée : maîtriser la facture Snowflake, BigQuery, Databricks

La promesse des data warehouses cloud : payer ce qu'on consomme, scaler à l'infini. La réalité : factures qui doublent d'un trimestre à l'autre, copies de prod en dev qui tournent en H24, jobs Spark sur-dimensionnés, requêtes BI qui scannent la même table 60 fois par jour. Le FinOps data est devenu une discipline à part entière, à mi-chemin entre data engineering, finance et SRE. Voici les leviers qui font baisser la facture sans casser la valeur.

Pourquoi le FinOps data devient critique

• Les plateformes cloud (Snowflake, BigQuery, Databricks) facturent à l'usage réel : compute, stockage, transfert.
• L'absence de frein technique (on n'attend plus rien) couplée à l'autonomie des équipes data fait exploser la consommation.
• La donnée pèse souvent dans le top 5 des coûts cloud des grandes organisations.
• Les CFO demandent explicitement à voir le coût par dashboard, par modèle ML, par équipe.

Modèles de facturation : ce qu'il faut comprendre

Plateforme	Compute	Stockage	Pièges
Snowflake	Crédits par taille de warehouse × temps actif	Stockage compressé / mois	Warehouses qui ne s'éteignent pas, multi-cluster mal calibré
BigQuery	On-demand ($/To scanné) ou Editions (slots)	Active + long-term storage	Requêtes SELECT * sans partition, jobs non taggés
Databricks	DBU × type d'instance × cloud compute	S3 / GCS / ADLS sous-jacent	Clusters all-purpose oubliés, autoscaling mal réglé, photon vs no-photon

Les 10 leviers FinOps qui marchent

1. Tagging systématique

Chaque requête, chaque job, chaque cluster doit porter un tag : équipe, projet, dataset, environnement. Sans tag = pas de visibilité = pas de FinOps possible.

2. Warehouses / clusters dimensionnés au besoin

• Snowflake : XS pour l'ad-hoc, S/M pour la BI, L/XL pour les ELT lourds. Auto-suspend agressif (60 s).
• Databricks : job clusters > all-purpose, autoscaling activé avec min raisonnable, photon quand le coût/perf gagne.
• BigQuery : Editions + slots réservés quand le volume est prédictible, autoscaler bien borné.

3. Partitioning et clustering

• BigQuery : partitionner par date, clusterer par dimensions filtrées souvent. Une requête sur table 5 To bien partitionnée scanne 50 Mo.
• Snowflake : micro-partitions automatiques, clustering keys sur tables géantes filtrées sur peu de colonnes.
• Databricks / Iceberg / Delta : partition + z-order / liquid clustering.

4. Materialized views et caching

• Pré-calculer ce qui est requêté 100 fois par jour (KPI exécutifs).
• Snowflake result cache et query result cache.
• BigQuery materialized views, BI Engine.

5. Incrémentalité (dbt + warehouse)

• Modèles dbt incrementals : ne recalculer que ce qui a changé.
• Stratégie merge vs append vs delete+insert selon la volumétrie.
• Voir dbt & analytics engineering.

6. Lifecycle des données

• Archiver les données froides (long-term storage BigQuery, S3 Glacier pour les exports Snowflake).
• Time travel et fail-safe : utiles mais coûteux, calibrer en fonction du dataset.

7. Optimisation des requêtes BI

• Forcer les outils BI à respecter les partitions.
• Limiter les colonnes (pas de SELECT *).
• Gouverner les dashboards exécutifs qui rechargent toutes les 5 minutes.

8. Multi-environnement maîtrisé

• Pas de copies complètes prod → dev sans politique de purge.
• Zero-copy clone (Snowflake) et linkage de schémas (Databricks) pour éviter de dupliquer la donnée.
• Time travel limité sur dev / sandbox.

9. Streaming et orchestration

• Spark Structured Streaming : trigger.AvailableNow vs trigger continue selon la latence requise.
• Auto-stop des notebooks oubliés.
• Airflow / Dagster : timeouts stricts, SLA, alertes sur jobs trop longs.

10. Reporting et chargeback

• Vue coût par équipe / domaine / data product publiée chaque semaine.
• Chargeback interne pour responsabiliser les domaines (cas Data Mesh).
• Voir Data Mesh en pratique.

Patterns FinOps avancés

Workload routing

• Requêtes BI → warehouse XS dédié.
• ELT lourd → warehouse L scheduling nuit.
• Data science / notebooks → cluster séparé avec quota.

Showback vs chargeback

• Showback : on montre le coût à chaque équipe sans facturer (1ère étape).
• Chargeback : on impute réellement le coût (politique mature, demande un modèle de coût stable).

Détection d'anomalies

• Alertes sur dépassement de seuil par projet, par équipe, par dataset.
• Détection automatique des requêtes coûteuses (>X $) avec retour aux auteurs.

Optimisation continue

• Revue mensuelle des top 50 requêtes les plus coûteuses.
• Refactoring guidé par la donnée (joindre moins, filtrer plus tôt, matérialiser ce qui doit l'être).

Gouvernance FinOps data

Une démarche FinOps data mature comprend :

• Un owner FinOps data transverse (souvent côté data platform).
• Une politique : tagging, naming, quotas, conventions warehouses.
• Un comité mensuel coût avec finance, plateforme, équipes consommatrices.
• Une plateforme de visualisation (Vantage, CloudZero, Snowflake usage views, BigQuery information_schema, Databricks system tables).
• Des objectifs trimestriels (réduire de X % le coût par To analysé, par dashboard, par modèle ML).

Pièges à éviter

• Couper aveuglément les budgets : on tue des cas d'usage qui rapportent.
• Optimiser les petites factures et ignorer les gros warehouses qui tournent 24/7.
• Mettre la FinOps sur le dos d'une seule personne : c'est un sport d'équipe.
• Confondre prix unitaire et coût global : un compute moins cher mais 3× plus lent peut coûter plus cher.
• Oublier les coûts indirects (transfert egress, monitoring, observability).

Profils mobilisés

• FinOps engineer data (souvent un data engineer ou SRE qui s'est spécialisé).
• Data platform engineer : pose les contraintes structurelles.
• Analytics engineer : optimise les transformations.
• DataOps : automatise la gouvernance et le reporting.
• Architecte data : arbitre les workloads et la stratégie multi-warehouse.

Conclusion : optimiser le coût sans abîmer la valeur

Le FinOps data n'est pas un projet ponctuel de réduction de coûts, c'est une pratique opérationnelle continue. Les organisations qui réussissent installent trois choses : la visibilité (tagging + reporting), l'autonomie outillée des équipes, et la culture de revue régulière. Celles qui échouent oscillent entre laisser-faire et coupes brutales.

Pour aller plus loin :

• Iceberg vs Delta vs Hudi : open table formats
• dbt & analytics engineering
• Data Mesh en pratique
• Migration legacy → cloud data platform

ForTeam IT positionne des FinOps engineers data, data platform engineers et architectes data capables de structurer la maîtrise des coûts sur Snowflake, BigQuery et Databricks. Si c'est votre terrain, vous êtes au bon endroit.

Rejoindre ForTeam IT