Un score sur 100, par application et par entité
Le FinOps scoring traduit la maturité FinOps en un chiffre simple. Pour chaque application, nous passons en revue les bonnes pratiques qui s'appliquent à son architecture. Chacune a un poids de 1 à 3 selon son impact sur la facture, et un statut : à faire (0), en cours (25 %), fait (100 %) ou non concerné (exclu du calcul). Le score est la moyenne pondérée, ramenée sur 100.
Agrégé par entité, il devient un KPI suivi au SteerCo, à côté des économies réalisées : il montre si les bonnes pratiques s'installent, pas seulement si la facture baisse.
Une grille par service cloud
La grille couvre la gouvernance et chaque service de l'architecture. Quelques exemples de points évalués :
| Domaine | Exemples de bonnes pratiques |
|---|---|
| Gouvernance | Budget alert par périmètre, tag application relié à la CMDB, environnements non-prod inutiles supprimés, logs challengés |
| VM et EC2 | Stop auto + Start on demand, rightsizing, tailles couvertes par les réservations, Azure Hybrid Benefit, Spot en non-prod |
| Disques et stockage | Bon tier de disque, disques non attachés, lifecycle management, S3 Intelligent-Tiering |
| App Service, Beanstalk, ECS | Tier du plan, Linux par défaut, plans vides supprimés, autoscaling en prod, Fargate pour les batchs courts |
| Bases de données | Rightsizing, serverless, arrêt des bases hors prod, géo-réplication et multi-AZ challengés, IOPS provisionnés justifiés |
| Data | Besoin de Databricks challengé, job clusters, auto-termination, fréquence des pipelines Data Factory |
| Logs | Logs activés justifiés, rétention, commitment tier, daily cap |
La scoring session, avant le passage en run
Le meilleur moment pour scorer une application, c'est juste avant sa mise en production. Nous réunissons l'équipe projet et l'équipe qui va l'exploiter pendant un atelier d'une à deux heures :
- revue des composants de l'architecture et de leurs risques de coût (une option de logs, une géo-réplication, un transfert de données massif) ;
- création des budget alerts et désignation de qui les reçoit ;
- score de départ et liste d'actions priorisée, que l'équipe run reprend à son compte.
On rescore ensuite à chaque changement important. Sans scoring session, les mauvaises surprises arrivent avec la première facture : voir nos cas réels d'incidents FinOps.
Un cookbook pour rendre les équipes autonomes
Chaque point de la grille renvoie à une fiche de notre FinOps cookbook, sur Azure comme sur AWS : pourquoi ce composant coûte, comment détecter le gaspillage, comment le corriger, avec les requêtes et les réglages utiles. Les équipes applicatives restent responsables de la mise en œuvre ; nous les outillons et les accompagnons.
Faites votre auto-évaluation
Voici une version courte de notre grille. Indiquez où vous en êtes sur chaque point : le score se calcule dans votre navigateur, rien n'est envoyé.
Lire le score
| Score | Niveau | Ce que cela veut dire |
|---|---|---|
| 0 à 40 | Crawl | Les fondamentaux manquent : pas d'alerte, pas de rattachement des coûts, non-prod allumée en permanence. Les gains rapides sont nombreux. |
| 40 à 70 | Walk | Les bases sont posées, l'optimisation reste ponctuelle. Il faut un plan de remédiation suivi. |
| 70 à 90 | Run | Les bonnes pratiques sont appliquées. L'enjeu devient la réarchitecture des services les plus coûteux. |
| 90 à 100 | FinOps by design | Les standards et building blocks font le travail : chaque nouveau projet arrive déjà optimisé. |