Pilotage du coût et de la valeur (FinOps data)

Les plateformes de données modernes facturent à l'usage : capacité de calcul, stockage, requêtes, licences par utilisateur. Un produit de données peut donc voir son coût croître sans que…

Guide≈ 8 min de lectureVérifiéLecture

Sur cette page

Pourquoi ce thème
Ce que mesure le thème
Les cinq niveaux
Jalons par niveau
Lecture détaillée par niveau
Atteinte partielle et notation
Passer au niveau suivant
Voir aussi

Niveau : 🟢→🔴 · Code thème : FIN

Pourquoi ce thème#

Les plateformes de données modernes facturent à l'usage : capacité de calcul, stockage, requêtes, licences par utilisateur. Un produit de données peut donc voir son coût croître sans que personne n'ait rien décidé : un modèle qui grossit, un rafraîchissement passé de quotidien à horaire, une requête mal écrite sur une capacité partagée. À l'inverse, une économie mal ciblée dégrade le service. Le FinOps (discipline popularisée par la FinOps Foundation) apporte trois idées : rendre le coût visible, l'attribuer à qui le cause, puis l'optimiser en lien avec la valeur. Ce thème porte sur la conduite financière du produit de données ; le coût détaillé des licences et capacités Power BI est traité en matrice BI — coût, licences et capacité, et la valeur attendue en VAL. Les offres et tarifs changent vite : vérifiez toujours auprès de l'éditeur (état 2026-10, non détaillé ici).

Ce que mesure le thème#

Axe : de l'ignorance du coût à l'arbitrage continu valeur/coût.
Indicateur clé : part du coût total attribuée à un produit de données et un propriétaire, et coût unitaire (par utilisateur actif, par requête, par To rafraîchi).
Unité : % du coût attribué ; coût par utilisateur actif et par mois ; écart budget/réalisé ; ratio valeur/coût par produit.

Les cinq niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Opaque	La facture arrive ; personne ne sait ce qui la compose ni pourquoi elle varie.	0 % du coût attribué
2	Visible	Le coût total est connu et suivi par poste (stockage, calcul, licences, personnes).	Coût mensuel par grand poste
3	Attribué	Chaque produit de données a un coût connu et un propriétaire qui en répond.	≥ 80 % du coût attribué à un produit
4	Piloté	Les budgets, alertes et optimisations sont suivis ; le coût unitaire est comparé à la valeur ; les dérives sont traitées vite.	Écart budget < 10 % ; alerte avant dépassement
5	Arbitré	Chaque euro est arbitré selon la valeur : on optimise, on investit ou on arrête, en continu.	Revue valeur/coût trimestrielle ; produits à valeur faible retirés

Jalons par niveau#

ID	Jalon	Preuve vérifiable
PD-FIN-1.1	Les postes de coût d'un projet data sont listés (personnes, infrastructure, licences, support).	Liste de postes datée.
PD-FIN-1.2	La facture de plateforme est consultable par l'équipe.	Accès à l'outil de facturation ou à un export mensuel.
PD-FIN-1.3	Un budget annuel existe, même grossier.	Document de budget.
PD-FIN-1.4	Un responsable du budget data est nommé.	Nom dans l'organisation.
PD-FIN-2.1	Le coût mensuel par grand poste est suivi dans le temps.	Tableau mensuel sur ≥ 6 mois.
PD-FIN-2.2	Les variations significatives (> 20 %) sont expliquées.	Note d'explication pour chaque variation.
PD-FIN-2.3	Les ressources inutilisées (environnements oubliés, tables obsolètes) sont recensées.	Inventaire avec décision par ligne.
PD-FIN-2.4	Le coût des personnes (temps de développement et de maintenance) est estimé par produit.	Estimation de charge par produit.
PD-FIN-3.1	Le coût de chaque produit de données (calcul, stockage, licences, temps) est calculé.	Tableau coût par produit ; méthode d'allocation écrite.
PD-FIN-3.2	Un propriétaire de coût est nommé par produit et connaît son niveau.	Entretien avec trois propriétaires.
PD-FIN-3.3	Un coût unitaire est défini (par utilisateur actif, par rafraîchissement, par To).	Indicateur calculé et publié.
PD-FIN-3.4	Les coûts de rafraîchissement et de requêtes lourdes sont attribués à leurs auteurs ou produits.	Mesure d'attribution des charges de calcul.
PD-FIN-4.1	Des budgets par produit et des alertes de dépassement sont configurés.	Alerte déclenchée et traitée sur un cas réel.
PD-FIN-4.2	Un cycle d'optimisation régulier (revue mensuelle ou trimestrielle) produit des économies mesurées.	Compte rendu avec gains chiffrés.
PD-FIN-4.3	Les arbitrages performance/coût sont documentés (fréquence de rafraîchissement, agrégats, partitionnement).	Décisions consignées avec mesure avant/après.
PD-FIN-4.4	Le rapport valeur/coût est calculé pour les principaux produits (VAL).	Tableau valeur/coût validé par un tiers métier.
PD-FIN-5.1	Le portefeuille est arbitré selon la valeur et le coût : investir, maintenir, optimiser, arrêter.	Décisions par produit sur les deux derniers trimestres.
PD-FIN-5.2	Les produits à faible valeur sont retirés et l'économie constatée.	Journal de retraits et économies réalisées.
PD-FIN-5.3	La prévision du coût à 12 mois s'appuie sur l'usage et la croissance des volumes.	Prévision comparée au réalisé à chaque trimestre.
PD-FIN-5.4	L'optimisation est intégrée au développement (coût estimé à la conception, vérifié en revue).	Rubrique « coût » dans les revues de conception.

Lecture détaillée par niveau#

🟢 Niveau 1 — Opaque#

Signes : « c'est le service informatique qui paye » ; une hausse de facture se découvre à la clôture.
Gain : aucun effort de suivi.
Ne garantit pas : que le budget tienne ; on ne peut pas arbitrer ce qu'on ne voit pas.
Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Visible#

Signes : un tableau mensuel ; les variations sont expliquées ; les ressources oubliées sont listées.
Gain : la première économie vient souvent d'un environnement oublié.
Ne garantit pas : l'attribution ni le lien avec la valeur.
Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Attribué#

Signes : un coût par produit ; un propriétaire par produit ; un coût unitaire ; les rafraîchissements lourds sont attribués.
Gain : la discussion passe de « c'est trop cher » à « ce produit coûte X pour Y utilisateurs ».
Ne garantit pas : que le coût soit optimisé (il est seulement compris).
Difficulté : 3/5 · Effort : 3/5.

🧪 Exemple

Un modèle sémantique rafraîchi toutes les heures pour 40 utilisateurs, dont 6 actifs. Coût attribué : 3 jours d'équivalent calcul par mois sur la capacité partagée. Au niveau 3, le propriétaire voit le chiffre ; au niveau 4, la fréquence passe à quotidienne après vérification que l'usage ne l'exige pas (économie d'environ 90 % du calcul de ce modèle, ordre de grandeur) ; au niveau 5, le produit est comparé à sa valeur et fusionné avec un autre.

🟡 Niveau 4 — Piloté#

Signes : budgets et alertes ; revue mensuelle d'optimisation ; arbitrages de performance consignés ; ratio valeur/coût calculé.
Gain : des dépenses prévisibles ; des économies récurrentes sans dégrader le service.
Ne garantit pas : la bonne répartition : on peut optimiser très bien un produit qui ne sert plus.
Difficulté : 4/5 · Effort : 4/5.

🔴 Niveau 5 — Arbitré#

Signes : revue trimestrielle valeur/coût ; retraits actés ; prévision fiable ; le coût figure dans chaque revue de conception.
Gain : chaque euro de la plateforme est justifiable.
Ne garantit pas : l'exactitude de la valeur, toujours discutable (voir VAL).
Difficulté : 5/5 · Effort : 4/5.

Atteinte partielle et notation#

Évaluez sur le portefeuille des cinq produits les plus coûteux : un jalon vaut 1 si tous le satisfont, 0,5 si la majorité, 0 sinon. Les jalons d'économie exigent une mesure avant/après, pas une estimation.

Un « 5 partiel » : un arbitrage trimestriel a conduit à deux retraits (5.1 et 5.2 à 1), la prévision à 12 mois est faite mais écartée du réalisé de 25 % (5.3 à 0,5), le coût n'est pas encore un critère de revue de conception (5.4 à 0).

⚠️ Piège

Économiser au détriment du service : réduire la fréquence d'un rafraîchissement dont dépend une décision quotidienne. Symptôme : économie constatée, plaintes. Remède : toute optimisation consulte le propriétaire du produit et vérifie le SLA (EXP).

⚠️ Piège

L'attribution arbitraire : répartir le coût commun au prorata du nombre d'utilisateurs punit les petits produits utiles. Remède : écrivez la règle d'allocation et réexaminez-la annuellement ; une règle simple et stable vaut mieux qu'une précision illusoire.

💡 Astuce d'expert

Le meilleur indicateur d'un produit à retirer est le coût par utilisateur actif : un produit à 40 utilisateurs inscrits et 3 actifs coûte, en réalité, treize fois plus par tête que son affichage.

Passer au niveau suivant#

Moyens possibles (facultatifs)

Passage	Leviers possibles
1 → 2	Exporter la facture chaque mois ; lister les ressources ; nommer un responsable.
2 → 3	Étiqueter les ressources par produit ; choisir une règle d'allocation ; calculer le coût unitaire.
3 → 4	Budgets et alertes sur la plateforme ; revue mensuelle ; tableau de bord de coût par produit (métriques et reporting).
4 → 5	Comité valeur/coût trimestriel ; règle de péremption ; critère de coût en revue de conception.

Pièges transverses : (1) Faux positif — un coût attribué à 100 % mais par une règle arbitraire. (2) Goodhart — minimiser le coût pousse à supprimer les environnements de test ou les contrôles (QUA). (3) Coût caché — le coût humain (support, corrections) dépasse souvent celui de la plateforme ; ne l'omettez pas.

🤖 IA

Elle résume une facture, repère des anomalies de coût, propose des optimisations de requête. Elle ne connaît pas la valeur métier et peut recommander une économie qui dégrade un service critique ; elle consomme elle-même de la capacité (tokens, calcul) : son coût entre dans le tableau, et ses usages en production se budgètent.

Voir aussi#

Même matrice : 01 Valeur · 06 DataOps · 10 Exploitation · 05 Modélisation · README
Autres matrices : PI — budget, valeur et bénéfices · DL — performance et scalabilité · BI — coût, licences et capacité · BI — performance et volumétrie
Pratique : comparatif OneLake / SQL Server · OneLake — architecture · SQL Server SaaS — architecture · méthodes spécifiques data
Glossaire · Notation

✻ Rédigé par Claude Sonnet 5.5