Pourquoi les outils natifs ne suffisent pas
Azure Cost Management et AWS Cost Explorer sont utiles, mais ils restent génériques : ils ne connaissent pas votre organisation, ne rattachent pas les coûts à vos applications ni à leurs owners, et ne suivent pas les économies réalisées. Résultat : chacun regarde un chiffre différent, et personne ne se sent responsable de sa consommation.
Ce que contient le dashboard
- Vue d'ensemble : consommation du mois, forecast annuel comparé au budget, savings réalisés depuis le début de l'année, savings potentiels réaffectables.
- Par application : coût mensuel, owner issu de la CMDB, savings potentiels, émissions de CO₂.
- Recommandations : chaque action chiffrée, avec son statut, jusqu'à la mesure du saving réel.
- Réservations : coverage, utilization et échéances des Reserved Instances et savings plans.
- GreenOps : émissions par application et par entité, avec leur évolution.
Les vues sont définies avec vous : la direction voit la trajectoire globale, chaque responsable d'application voit son périmètre, et tout le monde lit les mêmes chiffres. Une maquette interactive est présentée plus bas sur cette page.
Recommandations et alerting
Le dashboard intègre un moteur de recommandations plus fiable que les outils natifs, et un monitoring avec alertes sur le forecast, les anomalies, les services d'IA et les engagements. Les deux sont détaillés plus bas, avec une maquette interactive.
Comment il est construit
- Exports de billing quotidiens (Azure Cost Management, AWS Data Exports ou Cost and Usage Report).
- Rattachement aux applications et aux owners via votre CMDB, quel que soit l'outil (ServiceNow ou autre).
- Métriques d'usage (Azure Monitor, CloudWatch) pour le moteur de recommandations.
- Restitution dans Power BI, avec des requêtes KQL quand c'est utile.
Le SteerCo FinOps mensuel
Le dashboard alimente chaque mois un SteerCo court, avec la DSI, la finance et les référents FinOps. Le déroulé est toujours le même :
- Consommation du mois, par entité ou par région, et chaque variation expliquée : savings obtenus d'un côté, nouvelles ressources de l'autre.
- Projection annuelle face au budget, avec le coût moyen par VM et son évolution.
- Savings depuis le début de l'année, par levier (Stop/Start, rightsizing, cleaning, logs, data, réservations), et le potentiel restant.
- KPI FinOps face à leurs cibles, et le suivi des recommandations.
- Un focus du mois : la croissance du backup, la consommation des services d'IA, une migration à venir.
- GreenOps : émissions du mois et intensité carbone.
Les KPI que nous suivons
| KPI | Ce qu'il mesure | Cible indicative |
|---|---|---|
| Tagging | Part des coûts rattachés à une application de la CMDB | ≥ 95 % |
| Couverture RI / savings plans | Part du compute éligible couverte par un engagement | ≥ 80 % |
| Rightsizing | Part des VM correctement dimensionnées | ≥ 90 % |
| Couverture des métriques | Part des VM qui remontent leurs métriques d'usage : sans elles, pas de recommandation | 100 % |
| Stop/Start non-prod | Part des VM non-prod allumées moins de la moitié du temps | ≥ 80 % |
| Stop/Start VDI | Même indicateur, sur les postes virtuels | ≥ 80 % |
| Coût moyen par VM | Coût mensuel complet d'une VM, disques compris | En baisse |
| FinOps scoring | Maturité FinOps de chaque entité, sur 100 | En hausse |
Chaque KPI se lit au global et par entité : c'est l'écart entre entités qui montre où agir.
Le suivi des recommandations, jusqu'à la facture
Une recommandation n'a de valeur que si elle est appliquée. Nous suivons chacune d'elles avec un statut : réalisée (et mesurée sur la facture), en cours, à exécuter, en attente de validation, refusée ou non assignée. Une recommandation refusée n'est pas un échec : son motif est noté, et il sert à affiner les règles du moteur. Les montants non assignés ou en attente sont présentés au SteerCo, pour que la décision remonte au bon niveau.