Data FinOps : maîtriser le coût du cloud data

En 2021, l'équipe data d'une fintech mid-market a fêté un cap : leur facture Snowflake avait franchi les 3 M$ par an. Pas un cap qu'ils *souhaitaient*, un cap qu'ils ont découvert quand la finance a fait remonter le sujet au board. La plateforme était techniquement excellente. Latence des requêtes faible, adoption élevée, les analystes l'adoraient. Et elle absorbait tranquillement 40 % du budget technologique total sans qu'aucun métier ne puisse expliquer un seul dollar. Le CDO avait construit une Ferrari et distribué les clés à qui la demandait, la facture de carburant partant vers une boîte mail que personne ne lisait.

C'est le piège des plateformes data cloud. L'élasticité qui les rend puissantes, stockage infini, compute à la demande, accès en self-service, est la même élasticité qui rend le coût invisible jusqu'à ce qu'il devienne structurel. Vous savez déjà construire le catalogue et faire appliquer la gouvernance. **Cette leçon porte sur la transformation de la *facture* en actif gouverné, attribuable, optimisable**, et sur la façon d'y arriver sans refaire de la plateforme le goulot d'étranglement que vous avez passé deux ans à supprimer.

L'attributionattributionUn framework qui attribue le crédit d'une conversion aux différents touchpoints y ayant contribué, afin de mesurer quels canaux et quelles interactions génèrent réellement des résultats.Voir la définition complète → est la condition préalable à tout

On n'optimise pas ce qu'on ne peut pas attribuer. Le plus gros échec en gestion des coûts data consiste à traiter la plateforme comme un centre de coût unique et indifférencié. Quand la facture est un seul chiffre, le seul levier disponible est brutal : geler la dépense, et regarder l'adoption s'effondrer.

La discipline FinOps empruntée à l'infrastructure cloud vous donne trois phases opérationnelles, Inform, Optimize, Operate, mais pour une plateforme data en particulier, tout le levier se trouve en amont, dans l'attribution. Votre première mission : rendre chaque dollar de compute et de stockage traçable jusqu'à une équipe, un workload et un résultat métier.

La stratégie de tagging et d'isolation des warehouses

L'attribution dans un data warehousedata warehouseUn référentiel central qui consolide les données de nombreux systèmes sources dans un stockage structuré et optimisé pour les requêtes, conçu pour l'analytique, le reporting et la business intelligence.Voir la définition complète → passe par deux voies, et il vous faut les deux.

L'isolation du compute consiste à séparer les workloads sur des virtual warehouses ou des pools de calcul distincts pour que leur dépense soit mesurée indépendamment. C'est votre mécanisme d'attribution principal, car le compute représente en général 70 à 85 % de la facture. Un warehouse partagé unique où les dashboards du marketing, les jobs de réconciliation de la finance et le notebook incontrôlé d'un data scientist se disputent les ressources vous donne un chiffre et aucune redevabilité. Séparez-les.

Le tagging porte le contexte métier que l'isolation seule ne peut pas fournir. Chaque warehouse, chaque job planifié, chaque dataset matérialisé doit porter des tags de centre de coût, de domaine, d'environnement et de criticité.

-- Snowflake: object-level tags that flow into cost views
ALTER WAREHOUSE mktg_analytics_wh SET TAG
  cost_center = 'MKT-204',
  data_domain = 'campaign',
  env = 'prod',
  criticality = 'tier2';

La discipline ici n'est pas la syntaxe, c'est l'*application*. Les ressources non taguées sont l'entropie qui détruit tout programme FinOps au quatrième mois. Faites du tagging une barrière de déploiement : aucun warehouse ni tâche planifiée ne part en production sans les tags requis, contrôlés dans la CI, pas dans un PDF de politique interne. C'est là que votre muscle de gouvernance existant paie : vous contrôlez déjà le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → de déploiement ; étendez le même moteur de règles aux tags de coût.

Showback avant chargeback

Une fois la dépense attribuée, vous faites face à un choix politique : showback (dire aux équipes ce qu'elles coûtent) ou chargeback (le facturer à leur P&L). Ne sautez pas directement au chargeback. Un chargeback sans période de showback mature produit du gaming : les équipes déplacent leurs workloads pour échapper à l'allocation, ou accaparent de la capacité pour la protéger. Faites tourner le showback pendant au moins deux trimestres. Publiez un rapport mensuel de coût par domaine qui nomme les propriétaires. Le simple fait de rendre visible réduit en général 15 à 20 % de la dépense, parce que l'essentiel du gaspillage vient de l'absence de regard, pas d'une intention malveillante. Passez au chargeback seulement quand les chiffres sont fiables et que l'unit economics est stable.

La métrique qui compte le plus ici n'est pas la dépense totale, c'est le coût unitaire : coût par requête, coût par exécution de pipeline, coût par utilisateur actif, coût par chargement de dashboard. Une dépense totale qui augmente pendant que le coût unitaire baisse, c'est une plateforme *saine* qui scale avec l'activité. Une dépense totale stable pendant que le coût unitaire monte, c'est une plateforme qui pourrit de l'intérieur. Remontez l'unit economics à votre direction, pas les dollars bruts, sinon vous perdrez le récit face à une équipe finance qui ne voit que la facture qui grimpe.

Compute : là où l'argent brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ûle vraiment

Avec l'attribution en place, c'est sur le compute que vous trouverez les économies les plus rapides et les plus importantes. Trois leviers, par ordre d'impact.

L'optimisation des requêtes est un problème de gouvernance déguisé en problème technique

Les pires contrevenants sur n'importe quelle plateforme suivent une loi de puissance : une poignée de requêtes consomme une part disproportionnée du compute. Le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → classique est le SELECT * sur une table de plusieurs téraoctets qu'un outil de BIBITechnologies et processus qui transforment des données brutes en insights actionnables via du reporting, des dashboards et de l'analyse, pour que les équipes décident sur des faits plutôt qu'à l'intuition.Voir la définition complète → relance toutes les quinze minutes parce que quelqu'un a laissé l'auto-refresh activé. Ou un scan non partitionné qui lit tout l'historique d'une table pour répondre à une question sur la semaine dernière.

Votre moteur de requêtes journalise déjà tout cela. Le QUERY_HISTORY de Snowflake, l'INFORMATION_SCHEMA.JOBS de BigQuery, les tables système de Databricks, chacun expose les octets scannés et le compute consommé par requête. Le geste consiste à construire un rapport récurrent des requêtes les plus coûteuses et à le router vers le domaine propriétaire, pas vers votre équipe centrale. Centraliser le correctif recrée le goulot d'étranglement ; le domaine qui a écrit la requête est propriétaire du correctif, et votre équipe plateforme est propriétaire de la visibilité du coût et de la bibliothèque de patterns.

Les patterns techniques à plus fort levier à faire appliquer :

• Pruning par partition et clustering : assurez-vous que les tables sont partitionnées sur les colonnes que les requêtes filtrent réellement. Une table bien clusterisée peut réduire les octets scannés d'un ordre de grandeur.
• Discipline de matérialisation : recalculer le même agrégat des centaines de fois par jour est un impôt. Matérialisez-le une fois. Mais surveillez l'inverse : des vues matérialisées qui se rafraîchissent en permanence pour des données que personne ne lit sont du pur gaspillage.
• Result caching : des requêtes identiques doivent taper dans le cache, pas recalculer. C'est souvent une configuration que les équipes ont désactivée sans en mesurer le coût.

Right-sizing et auto-suspend

Le compute au repos est la ligne la plus gênante d'une facture data, parce qu'elle n'achète littéralement rien. Un warehouse configuré pour rester chaud « pour la réactivité » alors qu'il est inactif 80 % de la journée est un radiateur d'appoint. Réglez un auto-suspend agressif : 60 secondes se défend pour la plupart des warehouses interactifs. Le compromis se joue entre latence de démarrage à froid et coût d'inactivité ; mesurez-le au lieu de rester en always-on par peur.

Le right-sizing est le jugement le plus difficile. Les warehouses plus gros vont plus vite mais coûtent proportionnellement plus ; la question est de savoir si le coût *total* (taille × durée d'exécution) baisse. Fréquemment, un warehouse plus grand termine une transformation lourde tellement plus vite qu'il est globalement moins cher, c'est contre-intuitif et cela mérite d'être mesuré workload par workload. Ne supposez pas que plus petit veut dire moins cher.

Achats d'engagement

Dès que votre consommation de base est prévisible, et c'est l'attribution qui la rend prévisible, négociez des remises d'engagement d'usage. Les contrats de capacité réservée et de dépense engagée délivrent régulièrement 20 à 40 % de remise sur les tarifs on-demand. Le risque est de sur-engager une capacité que vous n'utiliserez pas. La règle : engagez-vous sur votre *plancher*, la consommation dont vous êtes sûr, et laissez les pics flexer en on-demand. Ne vous engagez jamais sur votre pic.

Stockage : la fuite lente

Le stockage représente en général une part plus faible de la facture que le compute, mais c'est la fuite qui grossit silencieusement et se cumule. La discipline centrale est le tiering : aligner le coût de stockage d'une donnée sur sa fréquence d'accès et sa valeur.

Le framework de tiering

Raisonnez en trois tiers, définis par le pattern d'accès, pas par l'âge seul :

• Hot : interrogé fréquemment, sensible à la latence, conservé dans le stockage performant natif du warehouse. Cher au téraoctet, mais l'accès le justifie.
• Warm : interrogé occasionnellement, tolérant à une latence un peu plus élevée. Candidat à un object storage moins cher interrogé via des tables externes.
• Cold : conservé pour la conformité ou un audit rare, pratiquement jamais interrogé. Sa place est dans les tiers d'archivage (S3 Glacier ou équivalent) à une fraction du coût.

L'erreur est de faire le tiering par âge. « Tout ce qui a plus de 90 jours passe en cold » échoue dès qu'une équipe de machine learning a besoin de trois ans d'historique pour l'entraînement. Faites le tiering sur l'*accès réel*, que vos logs de requêtes vous indiquent déjà. Une table non scannée depuis 90 jours est candidate au tiering quel que soit son âge ; une table de deux ans interrogée quotidiennement reste en hot.

Les trois tueurs de stockage

Trois patterns expliquent l'essentiel du gaspillage de stockage, et aucun ne concerne les données que votre activité utilise réellement :

1. Time-travel et failsafe avec des rétentions trop longues. Ces fonctions permettent de récupérer des données supprimées ou modifiées, et c'est formidable, jusqu'au moment où vous payez pour conserver 90 jours d'historique de changements sur des tables entièrement reconstruites chaque nuit. Réglez la rétention selon la criticité de chaque table, pas avec un défaut global unique.
2. Datasets orphelins. La sortie d'une expérimentation terminée il y a dix-huit mois, la table « temp » crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éée par quelqu'un en 2022, la copie complète de la production qu'un data scientist a faite « par sécurité ». Votre catalogue peut les retrouver : croisez l'inventaire des actifs avec les logs d'accès et signalez les datasets à zéro lecture sans lineage aval.
3. Petits fichiers non compactés. Dans les architectures data lakedata lakeUn data lake est un référentiel centralisé qui stocke de grands volumes de données brutes dans leur format d'origine, des tables structurées aux fichiers non structurés, jusqu'à ce qu'on en ait besoin.Voir la définition complète →, les écritures en streaming et en micro-batch produisent des milliers de fichiers minuscules qui gonflent à la fois le stockage et le coût des requêtes. La compaction planifiée est ingrate et indispensable.

C'est là que le lineage, sujet de ce module, devient un instrument de *coût*, et pas seulement de gouvernance. Un dataset sans lineage aval et sans lecture est candidat à la suppression. Le lineage vous dit ce qui casse si vous archivez quelque chose ; sans lui, les équipes accumulent tout parce que supprimer paraît dangereux. Le catalogue que vous avez construit pour la confiance est aussi la carte d'une réduction de coût sans risque.

Faire vivre la discipline : l'ancrer dans le temps

Un nettoyage de coûts est un projet. Le Data FinOps est un modèle opérationnel. Ce qui distingue les deux, c'est la survie des économies au contact de la croissance du trimestre suivant. La plupart des initiatives de coûts livrent une baisse spectaculaire unique, puis la facture remonte aussitôt, parce que les incitations et les rituels n'ont jamais changé.

Le rythme opérationnel transverse

Le FinOps ne fonctionne qu'en responsabilité partagée entre l'équipe plateforme du CDO, la finance et les domaines consommateurs. Mettez en place un groupe de travail FinOps léger, à cadence mensuelle. L'équipe plateforme apporte la dépense attribuée et l'unit economics. La finance apporte le contexte budgétaire et la prévision. Les domaines sont propriétaires de leur consommation et de leur backlog d'optimisation. Votre rôle de CDO est de présider les arbitrages, pas de policer chaque requête, ce qui vous remettrait en position de goulot d'étranglement, mais de trancher quand la croissance du coût d'un domaine dépasse sa valeur.

L'artefact clé est une vue budget contre réel par domaine avec alerting sur anomalies. Un domaine dont la dépense triple d'une semaine sur l'autre doit déclencher une alerte vers *le propriétaire de ce domaine*, automatiquement, avant que la finance n'en ait vent. Attendre la facture mensuelle pour détecter un pipeline incontrôlé, c'est ainsi que se produit la surprise à 3 M$.

Des garde-fous, pas des barrières

L'instinct après une frayeur sur les coûts est de tout verrouiller : workflows d'approbation pour chaque nouveau warehouse, quotas qui bloquent le travail. Cela détruit la culture self-service que vous avez bâtie et pousse les équipes vers du shadow IT. Préférez les garde-fous : des limites automatisées qui évitent la catastrophe tout en laissant l'autonomie.

Concrètement : définissez des resource monitors qui suspendent un warehouse dès qu'il dépasse un seuil de crédits, pour qu'un job incontrôlé plafonne au lieu de tourner tout le week-end. Fixez des timeouts par requête. Définissez des tailles de warehouse par défaut que les équipes peuvent surcharger avec justification, plutôt que d'exiger une approbation pour provisionner quoi que ce soit. La philosophie : faire du chemin sûr le chemin par défaut et rendre le chemin coûteux visible, mais ne jamais obliger les gens à demander la permission de faire leur travail.

Relier l'efficience au récit de valeur

Le piège à éviter est de laisser le FinOps devenir un pur exercice de réduction de coûts. Le travail d'une plateforme data est de générer de la valeur, et certains workloads valent leur coût élevé. Un modèle de détection de fraude qui exécute de l'inférence temps réel coûteuse et évite des millions de pertes n'est pas un candidat à l'optimisation, c'est un candidat à l'*investissement*. Le cadrage par unit economics vous protège ici : quand vous rapportez le coût à la valeur générée par chaque domaine, vous pouvez défendre les workloads coûteux qui se justifient et couper les workloads bon marché qui ne produisent rien. C'est cette conversation qui vous maintient à la table de la stratégie plutôt qu'à celle de la défense budgétaire.

À retenir

• L'attribution, c'est toute la partie. Isolez le compute par workload et imposez les tags de coût comme barrière de déploiement. Les ressources non taguées sont l'entropie qui tue tout programme FinOps : faites du non-tagué l'exception qui fait échouer la CI, pas la norme.
• Remontez l'unit economics, pas la dépense brute. Coût par requête, coût par utilisateur et coût par résultat vous disent si la plateforme scale sainement ou pourrit. Une dépense totale qui monte avec un coût unitaire qui baisse, c'est un succès ; défendez ce récit devant votre board.
• Attaquez le compute d'abord, le stockage ensuite. La loi de puissance des requêtes coûteuses et les warehouses inactifs, c'est là que se trouve l'argent rapide. Routez le rapport des requêtes coûteuses vers le domaine propriétaire : vous fournissez la visibilité, il porte le correctif.
• Faites le tiering du stockage par accès, pas par âge, et servez-vous de votre graphe de lineage pour identifier les datasets orphelins à zéro lecture comme candidats à une suppression sans risque. Le catalogue que vous avez construit pour la confiance est aussi votre carte de réduction de coût sans risque.
• Construisez des garde-fous, pas des barrières. Resource monitors, timeouts de requêtes et alertes d'anomalie vers les propriétaires de domaines préservent le self-service tout en plafonnant le désastre. Un rythme mensuel transverse transforme un nettoyage ponctuel en modèle opérationnel durable.