Les 4 phases du FinOps, et pourquoi la quatrième est essentielle
Le cadre de la FinOps Foundation repose sur trois phases : Informer (rendre les coûts visibles), Optimiser (trouver les économies) et Opérer (les faire appliquer). Nous en ajoutons une quatrième : Garder le contrôle. C'est la gouvernance qui évite que le gaspillage revienne au projet suivant.
Un tagging minimaliste, relié à la CMDB
On demande souvent aux équipes de poser une dizaine de tags. Résultat : ils sont incomplets, incohérents, et personne ne les maintient. Notre approche est inverse : le moins de tags imposés possible. Selon les clients, un seul suffit parfois, par exemple un code application. Il fait le lien entre le cloud et la CMDB, et toutes les autres informations (owner, centre de coût, environnement, criticité) se retrouvent dans la CMDB.
- Tag imposé dès la création des ressources (Azure Policy, ou Service Control Policies et Tag Policies sur AWS).
- Contrôle de cohérence automatisé entre le cloud et la CMDB.
- Tagging compliance suivie dans le dashboard.
Showback, puis chargeback
Tant que les équipes ne voient pas ce qu'elles consomment, elles n'ont aucune raison d'optimiser. Le showback rend les coûts visibles par application et par entité. Le chargeback va plus loin en refacturant la consommation à chaque budget. C'est souvent le déclic : quand une équipe paie ce qu'elle consomme, une non-prod qui tourne le week-end devient tout de suite un sujet.
Quand les équipes ne paient pas leur consommation, un mandat clair de la direction prend le relais : les recommandations fiables sont appliquées sans attendre l'accord de chaque responsable applicatif.
Une comitologie légère mais régulière
- Référents FinOps dans chaque entité, premier niveau de communication avec les équipes.
- SteerCo mensuel : consommation, forecast annuel, écart au budget, savings réalisés, plan d'action.
- Budget alerts automatiques par périmètre, envoyées à l'owner.
FinOps by design : standards, building blocks et contrôles
Nous mettons en place une gouvernance FinOps qui rend le FinOps by design. Ensuite, tout ce qui arrive dans le cloud est optimisé dès le départ.
| Brique | Contenu |
|---|---|
| Standards | SKU de VM et types de disques par défaut, politiques de rétention des données et des logs, backup policy par environnement, dimensionnement pour le besoin actuel |
| Building blocks | Tag obligatoire appliqué dès la création, Stop auto + Start on demand activé par défaut en non-prod, budget alerts créées avec chaque périmètre, collecte de logs filtrée |
| Contrôles projets | Checklist FinOps dans les revues d'architecture et le CAB, policies qui bloquent les configurations non conformes, revue au passage en run |
Dans le cloud, on dimensionne pour le besoin actuel : monter en taille est facile. C'est un changement de culture par rapport à l'on-premise, et c'est ce que la gouvernance doit ancrer.
Le FinOps dans le cycle de vie des projets
Le FinOps by design se joue projet par projet. Nous l'intégrons au processus projet existant, avec un cycle simple que l'on répète : estimer, suivre, alerter, optimiser.
| Étape | Ce qui est fait |
|---|---|
| Cadrage | Première estimation du coût cloud avec les calculateurs des providers. Elle n'a pas besoin d'être exacte : elle doit identifier les composants et les options les plus coûteux. |
| Build | Composants adaptés dès la non-prod. Nouvelle estimation à mi-projet, après les tests de performance et de volumétrie. |
| Passage en run | Scoring session avec l'équipe projet et l'équipe run : score de départ, risques de coût connus, budget alerts créées. |
| Run | Suivi mensuel dans le dashboard, alertes à 80 % et 100 % du budget, analyse des hausses avec le tech lead, optimisation. |
Tout changement se réestime. Certaines options changent la facture du tout au tout : activer des logs détaillés sur une ressource très sollicitée, ajouter de la géo-redondance, lancer un transfert massif de données. Quelques jours après le changement, on vérifie son effet réel sur les coûts. Ce sont exactement les situations de nos cas réels d'incidents FinOps.
Migration vers le cloud : appliquer les règles dès le premier jour
Bien construire au moment de la migration est beaucoup plus simple que corriger des centaines de VM après coup. Nous proposons d'intégrer trois règles au processus de migration :
- Dimensionner sur la charge réelle, pas sur la configuration on-premise, souvent surdimensionnée.
- Activer le Stop automatique et le Start on demand sur chaque VM non-prod dès sa création.
- Valider avant la mise en production : un contrôle de conformité FinOps devient une étape obligatoire de chaque migration.