Un data warehouse qui grossit n'est pas forcément un data warehouse qui sert. Voici une méthode outillée pour repérer les tables et pipelines orphelins, et transformer ce gaspillage en chiffre présentable en comité budgétaire.
Les directions financières scrutent les factures de compute cloud depuis des années, mais le stockage et les pipelines analytiques restent souvent hors radar. Pourtant, la part des données jamais exploitées est massive : 55% des données d'une organisation sont aujourd'hui dormantes, inexploitées ou inconnues selon l'étude Splunk Global Survey de 2025. Dans un data warehouse d'entreprise, cela se traduit concrètement par des tables créées pour un projet abandonné, des copies de staging jamais nettoyées, des pipelines dbt ou Airflow qui tournent chaque nuit pour alimenter un tableau de bord que plus personne ne consulte.
Le FinOps appliqué au cloud public a généré ses propres pratiques de gouvernance budgétaire. La même rigueur doit désormais s'appliquer à la donnée : le FinOps pour la donnée applique les pratiques de responsabilité financière aux dépenses des plateformes cloud de données, en créant une responsabilité partagée entre les équipes d'ingénierie, de finance et métier sur les coûts de compute, de stockage et de transfert de données. L'enjeu n'est plus seulement de réduire une facture, mais de distinguer, table par table et pipeline par pipeline, ce qui crée de la valeur de ce qui ne fait que consommer du budget.
Un audit FinOps data commence par une question simple : quand une table a-t-elle été lue pour la dernière fois, et par qui ? La plupart des entrepôts modernes exposent cette information nativement.
Snowflake expose plusieurs vues système qui permettent de reconstituer l'usage réel des objets. Snowflake fournit les données de coût via la vue QUERY_ATTRIBUTION_HISTORY pour les coûts au niveau requête, METERING_HISTORY pour la consommation des entrepôts virtuels par heure, et RESOURCE_MONITOR_HISTORY pour l'usage face aux limites fixées. En croisant ces vues avec ACCESS_HISTORY, on identifie les tables dont la dernière lecture remonte à plus de 90 ou 180 jours, ainsi que les requêtes dont le coût en crédits ne correspond à aucun usage en aval identifiable.
Côté Google Cloud, l'approche est similaire via les métadonnées de stockage. L'analyse de la table INFORMATION_SCHEMA.TABLE_STORAGE permet de distinguer le stockage actif du stockage long terme et de repérer les jeux de données à fort volume jamais requêtés récemment, une étape que plusieurs guides techniques recommandent pour arbitrer entre facturation logique et physique.
Une table ou un pipeline est considéré comme orphelin lorsqu'il réunit plusieurs signaux :
Cette cartographie doit être rejouée régulièrement, pas une fois par an. Les métriques à suivre dans la durée incluent le coût par requête, le coût par exécution de pipeline, le taux d'utilisation des entrepôts, le taux de croissance du stockage, le coût par unité métier, la variance de dépense mois sur mois et un ratio de gaspillage mesurant les ressources inactives ou inutilisées.
Une fois la liste des tables orphelines établie, le calcul du coût de stockage repose sur les tarifs publics des fournisseurs, appliqués au volume réel identifié.
Le stockage Snowflake est facturé indépendamment du calcul. Le tarif publié de Snowflake en 2026 est de 23 dollars par téraoctet et par mois en on-demand, un chiffre à retenir pour toute table orpheline identifiée : chaque téraoctet compressé dormant coûte environ 23 dollars par mois, soit environ 276 dollars par an, avant même de compter le Time Travel ou le Fail-safe qui peuvent multiplier ce volume sur des tables à forte rotation historique.
BigQuery applique une dégressivité automatique selon l'ancienneté de la donnée. BigQuery facture le stockage actif, pour les tables ou partitions modifiées dans les 90 derniers jours, à environ 0,02 dollar par Go et par mois, et le stockage long terme, pour la donnée non modifiée depuis 90 jours, à environ la moitié de ce tarif, automatiquement. Concrètement, une table orpheline de 5 To, non modifiée depuis plus de trois mois, bascule seule en tarif long terme à environ 10 dollars par téraoctet et par mois, soit 50 dollars par mois pour les 5 To : la facture baisse automatiquement, mais elle ne tombe jamais à zéro tant que la table existe.
Le stockage n'est souvent que la partie visible. Le vrai gaspillage se cache dans le calcul : des pipelines d'ingestion ou de transformation qui continuent de tourner chaque nuit pour alimenter des tables qui, elles, ne sont plus consommées en aval.
Sur Snowflake, la combinaison de WAREHOUSE_METERING_HISTORY et de l'attribution par requête permet d'isoler les crédits consommés par les tâches planifiées (tasks, streams, pipelines dbt) qui écrivent dans des tables orphelines. Deux indicateurs sont particulièrement utiles pour ce diagnostic : les crédits par téraoctet scanné, qui suivent l'efficacité du scan de données, et le pourcentage d'efficacité de l'entrepôt, qui est le ratio entre le temps d'exécution des requêtes et le temps total d'activité de l'entrepôt, révélateur du gaspillage de crédits en inactivité. Un pipeline qui tourne sur un entrepouse virtuel dédié avec un taux d'efficacité très bas, parce qu'il alimente une table plus lue par personne, représente un gaspillage de crédits pur.
Sur BigQuery, le même raisonnement s'applique aux jobs planifiés et aux vues matérialisées. Si une requête scanne 2 To chaque nuit pour rafraîchir une table jamais consultée, le coût mensuel se calcule directement au tarif de scan en vigueur.
Prenons un cas représentatif d'une entreprise de taille intermédiaire après un audit FinOps data :
Côté stockage : au tarif long terme de 0,01 dollar par Go et par mois, soit 10 dollars par téraoctet, 15 To coûtent 150 dollars par mois, soit 1 800 dollars par an, uniquement pour héberger des données que personne ne consulte.
Côté calcul : au tarif on-demand de 6,25 dollars par téraoctet scanné en régions américaines, trois pipelines scannant 500 Go par jour consomment environ 45 To par mois (3 × 0,5 To × 30 jours), soit environ 281 dollars par mois, 3 375 dollars par an, pour alimenter des tables mortes.
Total annuel de ce seul lot de tables orphelines : environ 5 175 dollars. Extrapolé à l'échelle d'un entrepôt de plusieurs centaines de téraoctets avec des dizaines de pipelines hérités, ce type de calcul fait régulièrement apparaître des dizaines de milliers d'euros de dépense annuelle sans aucune valeur métier en face. Les retours d'expérience de terrain confirment l'ordre de grandeur : l'application de techniques d'optimisation de la charge de travail permet de réduire les coûts d'un data warehouse cloud de 20 à 50%, et d'améliorer la performance des requêtes de 30 à 50%.
Un audit ponctuel produit un chiffre pour un comité budgétaire, mais ne change rien structurellement si la gouvernance ne suit pas. Trois leviers permettent de pérenniser la démarche :
Le standard ouvert FOCUS, porté par la FinOps Foundation, facilite désormais cette industrialisation sur plusieurs fournisseurs à la fois. FOCUS 1.3, ratifiée en décembre 2025, a ajouté l'allocation de coûts partagés, des jeux de données de contrats d'engagement et des signaux de fraîcheur de donnée, ce qui en fait la première version de la spécification rendant réellement praticable le FinOps multi-entrepôt. Pour une entreprise qui opère à la fois Snowflake et BigQuery, c'est la première brique permettant de consolider un seul tableau de bord de gaspillage plutôt que deux audits séparés.
Le chiffrage du coût des tables et pipelines orphelins n'a de valeur que s'il débouche sur des décisions d'archivage, de suppression ou de réaffectation de budget. La difficulté n'est généralement pas technique, les vues système existent sur tous les entrepôts modernes, mais organisationnelle : il faut un sponsor capable d'arbitrer entre la prudence de conserver une table « au cas où » et le coût réel de cette prudence, année après année.
C'est l'un des chantiers que nous accompagnons régulièrement avec les équipes data de nos clients, de l'audit initial jusqu'à la mise en place d'une gouvernance FinOps data récurrente. Si votre organisation souhaite objectiver ce que coûte réellement son data warehouse, notre offre de conseil en gouvernance data détaille la méthodologie d'intervention, et notre équipe reste joignable via la page contact pour discuter d'un premier audit.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus