Réduire les coûts cloud sans casser l'analytique : le playbook du CDO

Les budgets cloud data ont connu une croissance à deux chiffres pendant plusieurs années, portés par la démocratisation des entrepôts de données managés comme Snowflake, BigQuery ou Redshift. En 2026, le retour de bâton est là : les CFO examinent ligne par ligne les factures de compute et de stockage, et le CDO se retrouve à devoir justifier chaque téraoctet. Le problème n'est pas l'usage du cloud, c'est la façon dont la consommation s'est structurée, souvent sans gouvernance, au fil de projets successifs qui ont laissé derrière eux des tables orphelines, des pipelines redondants et des clusters surdimensionnés.

Ce que les équipes ressentent concrètement : des requêtes analytiques qui tournent sur des warehouses full-size à 3h du matin pour actualiser un tableau de bord que personne ne consulte avant 9h. Ou des copies de données dupliquées entre l'environnement de production, de staging et de sandbox, chacun facturé séparément. Le coût est réel. D'après Gartner, plus de 30 % des dépenses cloud des entreprises sont gaspillées en ressources non optimisées ou inutilisées. Le CDO qui s'attaque à ce problème méthodiquement peut récupérer 20 à 40 % de son budget sans dégrader un seul cas d'usage analytique.

La séquence d'action : six étapes pour reprendre le contrôle

Étape 1 : cartographier la consommation réelle, pas déclarée

Avant toute décision, il faut une vue de qui consomme quoi. Sur Snowflake, la vue `QUERY_HISTORY` combinée à `WAREHOUSE_METERING_HISTORY` permet d'identifier les warehouses les plus coûteux heure par heure. Sur BigQuery, les tables `INFORMATION_SCHEMA.JOBS` et les exports de billing vers BigQuery lui-même donnent une granularité par projet, par utilisateur et par requête. L'objectif de cette étape est de produire un classement : les 10 requêtes ou jobs qui consomment 60 à 70 % du compute. Dans la plupart des organisations, ce chiffre est atteint très vite et il surprend toujours les équipes.

Étape 2 : séparer les workloads par criticité

Un entrepôt unique pour tout faire est l'erreur la plus répandue. Les workloads exploratoires des data scientists, les pipelines ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète → nocturnes et les tableaux de bord executives n'ont pas les mêmes exigences de latence ni de disponibilité. Snowflake permet de crcrThe percentage of visitors or prospects who complete a desired action (purchase, sign-up, contact form), calculated as conversions divided by total opportunities.Voir la définition complète →éererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Voir la définition complète → des virtual warehouses distincts avec des tailles adaptées et des auto-suspend configurés indépendamment. Redshift Serverless ajuste automatiquement la capacité selon la charge. Séparer les workloads permet de dimensionner chaque environnement au plus juste et d'appliquer des politiques de suspension agressives là où la tolérance à la latence le permet.

Étape 3 : mettre en place des budgets et des alertes avant de toucher au code

Avant de refactoriser quoi que ce soit, instrumenter. Sur GCP, les budgets BigQuery avec alertes à 50 %, 80 % et 100 % empêchent les dépassements non anticipés. Sur AWS, Cost Anomaly Detection envoie une alerte dès qu'un service dépasse son comportement historique. Sans ces garde-fous, toute optimisation risque d'être annulée par un nouveau projet qui arrive sans concertation.

Étape 4 : auditer et éliminer les données froides

Le stockage représente souvent 30 à 40 % de la facture totale dans les architectures data lakedata lakeA data lake is a centralized repository that stores large volumes of raw data in its native format, from structured tables to unstructured files, until needed.Voir la définition complète →. La règle est simple : les données non consultées depuis plus de 90 jours doivent migrer vers un tier froid. Sur S3, le passage de Standard à Glacier Instant Retrieval divise le coût de stockage par un facteur proche de 4 pour un accès qui reste acceptable pour des besoins analytiques ponctuels. Sur Azure, Blob Storage propose un tier Archive à moins de 0,002 $ le Go par mois. Une politique de lifecycle automatisée, déployée en quelques heures via Terraform ou les consoles natives, produit des économies immédiates et récurrentes.

Étape 5 : refactoriser les requêtes les plus coûteuses

L'étape 1 a produit une liste. Il faut maintenant traiter les 10 pires cas. Les patterns les plus fréquents : des `SELECT *` sur des tables partitionnées qui ignorent le partitionnement, des jointures sans filtre préalable, ou des sous-requêtes non matérialisées recalculées à chaque exécution. Sur BigQuery, activer le column-level partitioning et le clustering réduit le volume scanné, donc le coût, souvent de 40 à 70 % sur des tables volumineuses. Ce travail prend deux à trois semaines pour une équipe de deux ingénieurs data.

Étape 6 : introduire une gouvernance FinOps dans le cycle analytique

Les optimisations ponctuelles s'érodent sans processus. Un comité FinOps data mensuel, réunissant le CDO, un représentant de la finance et les tech leads, suffit à maintenir la pression. Le coût par cas d'usage devient un indicateur de pilotage au même titre que la fraîcheur des données ou la disponibilité des pipelines. Databricks (éditeur de la plateforme LakehouseLakehouseA hybrid architecture combining the flexibility of a data lake with the analytical capabilities of a data warehouse, on a single storage layer.Voir la définition complète →, chiffres issus de leur documentation commerciale, à croiser avec des retours terrain indépendants) estime que les équipes qui adoptent ce modèle réduisent leur drift de coût de 25 % sur douze mois.

Les pièges qui font échouer cette démarche

Le premier piège est de couper trop vite sans mesurer l'impact analytique. Réduire la taille d'un warehouse de production sans vérifier les SLA des pipelines en aval peut casser des rapports critiques à 7h le lundi matin, ce qui crée une crise et un retour en arrière immédiat.

Le deuxième piège est de déléguer l'initiative entièrement à l'équipe FinOps cloud centrale, qui ne comprend pas les dépendances analytiques. L'optimisation des coûts data doit rester pilotée par le CDO ou un data architect senior qui connaît la valeur de chaque workload.

Le troisième : négliger les coûts d'egress. Déplacer des données entre régions ou vers un outil tiers (un outil de BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète → comme Tableau ou Looker qui tire depuis BigQuery dans une autre région) génère des frais de transfert qui peuvent effacer les économies réalisées sur le compute.

Enfin, éviter de traiter cette démarche comme un projet à durée déterminée. Les coûts cloud data croissent structurellement avec le volume de données et le nombre d'utilisateurs. Sans gouvernance continue, les économies réalisées sont recyclées par de nouveaux usages non contrôlés dans les six mois.

Pour commencer cette semaine

• Extraire le rapport de consommation par warehouse ou par projet sur les 30 derniers jours et identifier les trois postes dominants.
• Activer les alertes de budget sur le compte cloud principal si ce n'est pas dé