Votre facture data augmente. Le responsable de la plateforme propose de réduire la taille des machines. Les métiers demandent de conserver les délais de mise à jour. La finance veut savoir quel service consomme davantage. Ces trois demandes peuvent être légitimes, mais elles ne portent pas sur la même décision.
Pour maîtriser le coût d’une plateforme data, commencez par relier les dépenses à des usages et à des responsables. Vous pourrez ensuite choisir entre optimiser un traitement, changer une fréquence, arrêter un service ou accepter une hausse justifiée par l’activité.
Ce guide propose un premier exercice de FinOps data : rapprocher un périmètre de facturation, distinguer coûts directs, coûts partagés et montants encore inexpliqués, puis préparer une décision mesurable. Les chiffres sont fictifs. Aucun gain client ni benchmark de fournisseur n’est revendiqué.
Télécharger la matrice et son exemple corrigé. Le kit contient des fichiers CSV utilisables dans un tableur et un mode d’emploi. Il ne nécessite aucun accès cloud et ne modifie aucune infrastructure.
Le point de départ : un podcast sur la responsabilité des coûts
Dans FinOps Weekly, l’épisode du 20 mai 2026, « FinOps for AI and Data Workloads: Why Dashboards Are No Longer Enough », réunit Vijay Pramkumar et Kiran Jain, dirigeant de Finoptly. Le transcript complet de 41 min 48 a été lu pour cet article.
Vers 30 minutes, Vijay relie les ressources aux applications, puis aux responsables métier. Vers 39 minutes, Kiran recommande d’identifier l’usage dès la création du traitement. Ces témoignages orientent notre question : qui peut expliquer une dépense et décider de son évolution ? Le second intervenant dirige un fournisseur du secteur ; l’entretien n’est pas une étude indépendante d’économies. Épisode et transcript.
L’article ci-dessous développe notre propre méthode et un exercice fictif. Il ne présente pas cet épisode ancien comme une actualité du jour.
Coût observé, coût réparti et économie : trois résultats différents
Un coût observé répond à une question de mesure : combien a consommé une ressource, selon quel compteur et pendant quelle période ?
Un coût réparti répond à une question d’organisation : quelle part doit être rattachée à chaque équipe ? Certaines dépenses sont directement identifiables. D’autres nécessitent une convention, par exemple pour un socle partagé.
Une économie demande une comparaison : quelle dépense aurait eu lieu sans le changement, à service et activité comparables ? Affecter une facture à un responsable ne réduit pas son montant.
La FinOps Foundation distingue aussi le showback, qui rend les coûts visibles aux équipes, du chargeback, qui les réaffecte financièrement. Commencer par une restitution explicable permet de discuter les règles avant leur éventuelle traduction comptable. Terminologie FinOps.
Pour un premier périmètre, je recommande de produire trois colonnes séparées : montant directement attribué, montant réparti par convention et montant non attribué. Un total « couvert à 100 % » obtenu en répartissant arbitrairement les inconnus cache le travail restant.
Fixer le périmètre avant de calculer
Choisissez une période close et une base de coût cohérente. Dans l’exercice, il s’agit de septembre 2026, en euros hors taxes, pour les services techniques inclus dans une facture fictive de 12 000 euros.
Ce périmètre ne couvre ni les salaires ni une migration. On ne l’appellera donc pas coût complet de la fonction data. Si votre décision concerne une migration, ajoutez dans une analyse distincte l’effort d’équipe, la double exploitation et les prestations nécessaires.
Pour vos données réelles, documentez les remises, engagements et ajustements retenus avec la finance. Une consommation valorisée au tarif public n’est pas automatiquement le montant effectivement facturé. Ne mélangez pas plusieurs devises sans règle de conversion explicite, ni plusieurs mois pour faire disparaître un écart.
Conservez deux vues complémentaires :
- la vue de rapprochement, qui explique le total du périmètre de référence ;
- la vue d’usage, qui aide à comprendre les traitements, leurs volumes et leurs responsables.
La première contrôle les montants. La seconde prépare l’action. Un identifiant de facture ne dit pas quel rapport peut être rafraîchi moins souvent ; un compteur d’exécution ne prouve pas que tous les frais sont couverts.
Cas concret : répartir 12 000 euros sans masquer les inconnus
Une entreprise fictive utilise sa plateforme pour les ventes et les opérations. Les traces disponibles permettent d’identifier 7 000 euros de coûts directs. Le socle partagé coûte 3 000 euros. Les 2 000 euros restants n’ont pas encore de rattachement fiable.
| Ligne du périmètre fictif |
Montant |
Qualification initiale |
| Traitements ventes |
4 200 € |
Direct, équipe ventes |
| Traitements opérations |
2 800 € |
Direct, équipe opérations |
| Socle partagé |
3 000 € |
Règle à convenir |
| Ressources sans rattachement fiable |
2 000 € |
Non attribué |
| Total de référence |
12 000 € |
Écart de rapprochement : 0 € |
Pour cet exercice, les deux équipes acceptent de répartir le socle à 60 % pour les ventes et 40 % pour les opérations. Cette clé est une hypothèse pédagogique, pas une mesure de consommation ni une recommandation universelle.
Après répartition, les ventes portent 6 000 euros : 4 200 euros directs et 1 800 euros partagés. Les opérations portent 4 000 euros : 2 800 euros directs et 1 200 euros partagés. Les 2 000 euros inconnus restent visibles.
Le total reste 12 000 euros. Le montant rattaché aux équipes passe à 10 000 euros, mais seuls 7 000 euros proviennent d’une attribution directe. La dépense n’a pas baissé d’un centime.
Attribuez à quelqu’un l’enquête sur les 2 000 euros restants. Cette personne est responsable de l’investigation, pas nécessairement consommatrice de la ressource. Confondre ces deux rôles ferait disparaître artificiellement l’inconnu.
Quelle règle pour les coûts partagés ?
La FinOps Foundation recommande de définir les catégories d’allocation, les métadonnées nécessaires et le traitement des coûts mutualisés. Les règles peuvent évoluer avec la qualité des informations disponibles. Capacité Allocation.
Pour choisir votre première règle, posez une question précise : quel comportement cette répartition encourage-t-elle ?
Une clé fixe est lisible et stable. Elle peut convenir à un socle commun assumé collectivement, mais elle ne mesure pas l’usage. Une clé fondée sur une consommation observée peut mieux expliquer certaines variations, à condition que le compteur corresponde réellement au coût partagé. Un nombre de requêtes, à lui seul, traite de la même façon un calcul lourd et une consultation légère.
Vous pouvez aussi conserver une dépense dans un budget plateforme central. C’est une décision explicite acceptable si son responsable et sa justification sont connus. Ce n’est pas la même situation qu’une dépense dont personne ne connaît l’origine.
Écrivez la règle, son approbateur et sa date d’application. Lorsqu’elle change, gardez l’ancienne version. Sinon, une équipe peut sembler consommer moins simplement parce que la clé de répartition a été modifiée.
Snowflake : les crédits des requêtes ne sont pas toute la facture
Snowflake documente l’usage de tags de ressources pour les périmètres dédiés et de tags de requêtes pour identifier les usages d’applications partagées. Un même compte technique peut servir plusieurs équipes : son nom ne suffit donc pas à identifier le bénéficiaire. Attribution des coûts Snowflake.
La vue QUERY_ATTRIBUTION_HISTORY couvre le calcul des requêtes sur les warehouses concernés, avec jusqu’à huit heures de latence. Elle exclut notamment le temps d’inactivité, le stockage, les transferts, les services cloud, les fonctions serverless et les jetons IA. Les requêtes d’environ 100 ms ou moins et les jobs des Adaptive Warehouses n’y figurent pas ; Snowflake renvoie ces derniers vers QUERY_METERING_HISTORY. L’accélération de requêtes possède une colonne séparée. L’accès suppose un rôle disposant de USAGE_VIEWER ou GOVERNANCE_VIEWER. Référence de la vue, vérifiée le 28 octobre 2026.
Conséquence pour votre matrice : gardez les crédits comme unité technique et rapprochez séparément les montants monétaires. Ne nommez pas une somme de crédits « facture complète ». Ne transformez pas non plus une vue retardée en mécanisme d’arrêt immédiat.
Cette vérification reste documentaire : aucun compte Snowflake réel n’a été interrogé pour cet article.
Atelier : construire une première restitution explicable
1. Ouvrir les fichiers et identifier la référence
Décompressez le kit de répartition. Ouvrez 01-couts-exemple.csv dans Excel, LibreOffice ou votre tableur habituel : encodage UTF-8, séparateur point-virgule, montants entiers en euros.
Les quatre lignes totalisent 12 000 euros. La colonne type_attribution vaut direct, partage ou inconnu. Un champ responsable vide sur la ligne inconnue est volontaire. N’ajoutez pas le total comme une cinquième dépense.
Pour travailler ensuite sur vos données, copiez matrice-vierge.csv. Une ligne représente une dépense du périmètre, avec un identifiant unique. Conservez le fichier d’exemple intact comme corrigé.
2. Documenter les preuves et les responsabilités
Pour chaque ligne, renseignez la source du montant, l’usage, le responsable du service et la preuve d’attribution. Une preuve peut être un export de facturation rapproché d’un inventaire ou une métadonnée d’exécution correctement renseignée.
Dans notre exemple, ces références sont elles aussi fictives. Elles indiquent le type de pièce à rechercher, pas un export réel. Pour une ligne inconnue, inscrivez une prochaine action et un responsable d’enquête dans la matrice de décisions, sans inventer son bénéficiaire.
3. Répartir uniquement la ligne partagée
Le fichier 02-cle-partage.csv contient deux coefficients : 0,60 et 0,40. Leur somme doit être 1. Multipliez les 3 000 euros du socle par chaque coefficient : 1 800 euros pour les ventes, 1 200 euros pour les opérations.
Ajoutez chaque part au montant direct correspondant. Le fichier 03-repartition-attendue.csv donne le résultat à comparer. Ne conservez pas les 3 000 euros initiaux comme une ligne supplémentaire dans cette vue finale : cela compterait deux fois le socle.
Trois contrôles doivent passer : aucune dépense perdue, aucun double compte et conservation des 2 000 euros inconnus. Si vous remplacez 0,40 par 0,50, la clé devient invalide. Corrigez-la avant toute restitution ; ne normalisez pas silencieusement les coefficients.
4. Transformer une ligne en décision
Ouvrez 04-decisions-exemple.csv. Chaque proposition contient un responsable, une preuve à obtenir, une action à tester et un critère de service à préserver.
Exemple fictif : le reporting ventes est recalculé toutes les heures alors que son utilisation pourrait autoriser une fréquence moindre. Avant de changer quoi que ce soit, vérifiez les lecteurs, leurs horaires et les dépendances. Définissez ensuite une fréquence candidate, une période d’observation et une condition de retour arrière.
Un traitement peu consulté peut alimenter une obligation de clôture ou un autre processus. Le guide de retrait des rapports BI fournit une démarche complémentaire pour examiner ces usages.
5. Mesurer après le changement
Comparez des périodes de même périmètre, avec leurs volumes, leurs tarifs et leurs objectifs de service. Conservez la date du changement et les autres modifications intervenues pendant l’essai.
Dans un second exemple fictif, un service coûte 6 000 euros pour 20 000 dossiers traités correctement : 0,30 euro par dossier. S’il coûte ensuite 6 600 euros pour 24 000 dossiers comparables, le coût unitaire devient 0,275 euro. Le coût unitaire baisse, la dépense totale augmente. Ces deux constats sont vrais ; aucun ne suffit seul à démontrer une économie causée par une optimisation.
Si la qualité ou le périmètre des dossiers change, le ratio demande une explication supplémentaire. Si le nombre de résultats utiles manque, laissez le coût unitaire inconnu plutôt que de diviser par un compteur disponible mais sans rapport avec le service.
Trois décisions à préparer avec cette matrice
Réduire une fréquence de rafraîchissement. Faites valider la fraîcheur acceptable par le responsable métier. Mesurez les exécutions et la qualité avant et après. Une simple diminution du nombre de jobs ne prouve pas la baisse du montant facturé.
Optimiser une ressource partagée. Distinguez l’effet technique de l’effet de répartition. Une amélioration peut bénéficier à plusieurs équipes ; changer simultanément la clé rend la comparaison moins lisible. Le coût global du périmètre doit rester observable.
Comparer une migration. Séparez coût de fonctionnement futur et coût de transition. La double exécution, la recette et l’accompagnement consomment des ressources même si la nouvelle solution annonce une unité moins chère. Le guide de migration de pipeline détaille les contrôles à préparer avant une bascule.
Votre premier livrable utile est une matrice dont chaque ligne débouche sur une explication ou une investigation. Une fois les montants rapprochés, les inconnus visibles et les responsables identifiés, la discussion peut enfin porter sur le service à rendre et le changement à essayer.
