Dès le premier mois
Les premiers savings
- Réservations et savings plans sur la baseline
- Cleaning des ressources oubliées
- Storage tiering et pricing tiers des logs
Notre approche
Une démarche FinOps en 4 phases, pour réduire puis garder le contrôle
Une méthode pragmatique, forgée en huit ans de missions dans de grands groupes : rendre les coûts visibles, trouver les économies, les faire appliquer, puis faire en sorte que le gaspillage ne revienne pas.
Le FinOps, concrètement
Rendre chaque euro du cloud visible, utile et assumé
Le FinOps (Cloud Financial Operations) réunit la finance, la DSI et les équipes techniques autour d'un objectif commun : dépenser juste. Nous couvrons les trois phases du cadre de la FinOps Foundation, et nous en ajoutons une quatrième, essentielle : garder le contrôle dans la durée.
1 · Informer
Comprendre ses dépenses
- Lecture de la facture : quels services, quels postes de coût, quelles tendances
- Allocation de chaque euro à une application, une entité et un environnement
- Dashboard sur mesure, rafraîchi chaque jour : coûts, forecast, CO₂, alerting sur les variations
2 · Optimiser
Trouver les économies
- Recommandations fondées sur l'usage réel de chaque composant
- Stratégie de réservation : Reserved Instances et savings plans
- Réarchitecture des services les plus coûteux, après analyse approfondie
- Ateliers avec les équipes des applications les plus coûteuses, pour converger vers une solution moins chère
- Chaque action chiffrée et priorisée par gain
3 · Opérer
Faire appliquer, mesurer
- Pilotage du plan de remédiation avec les équipes Ops
- Mesure des gains réels après application
- Suivi des savings au SteerCo mensuel
4 · Garder le contrôle
Éviter que le gaspillage revienne
- Gouvernance FinOps durable : showback / chargeback, règles, comitologie
- FinOps by design : standards et building blocks, pour que de nouvelles optimisations n'aient plus à apparaître
- Monitoring et alerting sur le forecast
Aligné sur le FinOps Framework
Notre démarche couvre les 4 domaines du FinOps Framework
Le FinOps Framework de la FinOps Foundation est la référence de la discipline. Il organise le FinOps en domaines, les résultats attendus, et en capabilities, la manière de les atteindre. Voici ce que nous livrons concrètement dans chacun.
1
Understand Usage & Cost
Comprendre l'usage et les coûts
Data IngestionAllocationReporting & AnalyticsAnomaly Management
Ce que nous livrons
- Dashboard sur mesure rafraîchi chaque jour, relié à votre CMDB
- Tagging minimal, souvent un seul tag : ≈ 100 % des coûts rattachés à une application
- Monitoring et alerting sur les dérives, avant qu'elles ne coûtent des dizaines de milliers d'euros
2
Quantify Business Value
Mesurer la valeur
Planning & EstimatingForecastingBudgetingKPIs & BenchmarkingUnit Economics
Ce que nous livrons
- Forecast et suivi budgétaire par application et par entité
- Estimation du coût des nouveaux projets, et arbitrage build vs buy
- KPIs FinOps suivis en SteerCo, savings mesurés sur la facture
3
Optimize Usage & Cost
Optimiser l'usage et les coûts
Architecting & Workload PlacementUsage OptimizationRate OptimizationLicensing & SaaSSustainability
Ce que nous livrons
- Rightsizing, Stop automatique et Start on demand, cleaning, filtrage des logs
- Stratégie Reserved Instances et savings plans, Azure Hybrid Benefit
- Réarchitecture des services les plus coûteux, avec les équipes applicatives
- GreenOps : empreinte carbone suivie à côté des coûts
4
Manage the FinOps Practice
Piloter la pratique FinOps
Executive Strategy AlignmentGovernance, Policy & RiskInvoicing & ChargebackFinOps AssessmentEducation & EnablementAutomation, Tools & Services
Ce que nous livrons
- Gouvernance FinOps, comitologie, showback puis chargeback
- FinOps scoring et guide des bonnes pratiques pour les équipes
- FinOps by design : standards, building blocks et moteur de recommandations
Avec qui nous travaillons
Le FinOps est collectif. Nous tenons le rôle de FinOps practitioner : nous outillons, nous animons, et nous faisons le lien entre toutes les parties prenantes.
Équipes techniquesFinance et contrôle de gestionDirectionAchatsOwners d'applicationsITAMITSMSécuritéRSE
Crawl, Walk, Run
Notre FinOps scoring mesure la maturité de chaque entité selon les étapes du framework, et fixe la marche suivante. On ne vise pas « Run » partout : on vise le bon niveau, là où l'enjeu financier le justifie.
- Crawl
- Walk
- Run
Source : FinOps Framework, FinOps Foundation, sous licence CC BY 4.0. Les noms des domaines et des capabilities sont ceux du framework ; la correspondance avec nos livrables est la nôtre.
Visibilité & tagging
Le socle du FinOps : que chacun voie ce qu'il paie
On n'optimise pas ce qu'on ne voit pas. Le premier pilier, c'est un tagging rigoureux rattaché à la CMDB, et un dashboard clair où le responsable d'application et celui qui paie voient précisément leur consommation. C'est souvent eux qui repèrent en premier ce qui ne va pas.
Les questions auxquelles chacun doit pouvoir répondre seul
- Est-ce que ce que je paie correspond aux ressources dont j'ai besoin aujourd'hui ?
- Y a-t-il des ressources oubliées ou inutilisées à cleaner ? Une VM de test, un disque d'un projet terminé, un environnement de POC…
- Est-ce normal que ma non-prod coûte plus cher que ma prod ? En phase de run, la réponse est presque toujours non.
- Qui est le owner de chaque euro dépensé ?
- Mon coût évolue-t-il comme prévu d'un mois à l'autre ?
Exemple de signal d'alerte
Application en run, mars
Prod
18 k€
Non-prod
24 k€
Illustration. Quand la non-prod dépasse la prod, il y a presque toujours des environnements allumés pour rien ou surdimensionnés.
Une tagging policy minimaliste et appliquée
Le moins de tags imposés possible. Selon les clients, un seul suffit parfois : il fait le lien entre le cloud et la CMDB, et toutes les autres informations se retrouvent dans la CMDB.
app-codeCMDBowner · centre de coût · environnement · criticité- Tag imposé dès la création des ressources (Azure Policy)
- Contrôle de cohérence automatisé entre le cloud et la CMDB
- Suivi de la tagging compliance dans le dashboard
À notre arrivée chez un client, 35 % des ressources n'étaient pas taggées. Aujourd'hui, 99,9 % le sont correctement.
Notre méthodologie
Une méthode pragmatique, forgée sur le terrain
Notre méthode n'a pas été écrite dans un bureau. Elle s'est construite en huit ans de missions dans plusieurs grands groupes, chacun avec son organisation et son niveau de maturité FinOps. Elle a été confrontée aux approches des grands cabinets de conseil, puis enrichie par les retours d'expérience d'autres groupes du CAC 40.
8 ans
D'expérience terrain
Des recommandations appliquées en production et des économies mesurées sur la facture. Nous ne livrons pas un rapport pour le laisser dans un tiroir.
Toutes
Les maturités
Des organisations centralisées ou décentralisées, avec ou sans chargeback, qui débutent ou qui sont déjà avancées : la démarche s'adapte au point de départ de chaque client.
Challengée
Par les grands cabinets
La méthode a été confrontée aux approches des grands cabinets de conseil. On a gardé ce qui produit des résultats concrets et abandonné le reste.
Co-construite
Avec les pairs du CAC 40
Elle s'enrichit des échanges avec d'autres grands groupes, en particulier au sein du CRIP, la communauté des responsables d'infrastructure et de production.
Notre démarche
Du diagnostic aux économies sur la facture
Trouver une recommandation ne suffit pas, il faut qu'elle soit appliquée. Une grande partie de notre travail consiste à lever ce qui bloque entre l'idée et la mise en production.
01
Diagnostic et visibilité
Semaines 1 à 3- Accès en lecture seule (Reader) aux données de billing, sans intervention sur vos systèmes
- Cartographie des coûts par service, application et environnement
- Audit du tagging et du rattachement des ressources à la CMDB
- Premier chiffrage du coût de l'inaction
02
Quick wins
Dès le premier mois- Reserved Instances et savings plans sur la baseline
- Cleaning : unattached disks, snapshots obsolètes, IP publiques, environnements oubliés
- Azure Hybrid Benefit : réutiliser les licences Windows Server et SQL Server déjà détenues
- Access tiers du storage (Hot, Cool, Cold, Archive) et pricing tiers des logs adaptés à l'usage réel
03
Plan de remédiation piloté
Mois 2 à 6- Tous les services cloud sont couverts : compute, bases de données, stockage, réseau, logs, data, IA…
- Un plan d'action par service, priorisé par gain et piloté avec les équipes qui l'exploitent
- Règles de recommandation fiables (CPU et RAM P95 sur 30 jours) pour ne jamais dégrader la production
- Priorisation : 90 % des gains se concentrent souvent sur une dizaine d'entités
- Stop automatique chaque soir et Start on demand pour les VM non-prod et les VDI
- Rightsizing, validé d'abord sur un POC, puis déployé à grande échelle
04
Gouvernance durable
En continu- Showback puis chargeback : chaque équipe voit et assume sa consommation
- Référents FinOps et comitologie adaptée (opérationnel, DSI, direction)
- Budget alerts automatiques par périmètre
- FinOps by design : une checklist intégrée aux revues d'architecture et au CAB
05
Mesure et reporting
Chaque mois- SteerCo mensuel : consommation, forecast annuel, écart au budget
- Savings réels mesurés (coût avant / coût après), pas seulement estimés
- KPI suivis : coverage RI / savings plans, rightsizing, Stop/Start, tagging
- Suivi du carbone évité, intégré au même dashboard
Les leviers
Où se cachent les économies
Les ordres de grandeur ci-dessous viennent de nos missions. Ils s'appliquent à la ressource optimisée, pas à la facture totale.
≈ −90 %
Stop auto + Start on demand
Pour les VM non-prod et les VDI : arrêt automatique chaque soir, redémarrage uniquement quand quelqu'un en a besoin. Pourquoi pas un Stop/Start classique ?
≈ −50 %
Réservations & savings plans
S'engager sur 1 ou 3 ans sur la baseline. C'est le levier clé de la prod, le plus rapide à mettre en place, et il ne touche pas aux applications. Voir la stratégie
−50 %
Rightsizing
Les VM dont le CPU et la RAM restent sous 50 % (P95 sur 30 jours) passent au SKU inférieur. Dans le cloud, on dimensionne pour le besoin actuel, puisque monter en taille est facile.
−50 %
Backup & storage
Backup policy revue : durée de rétention adaptée à chaque environnement et au besoin réel, backups long terme passés de l'access tier Cool à Cold. Le coût de stockage est environ divisé par deux.
Jusqu'à ÷4
Logs & monitoring
Filtrage pour ne collecter que les types de logs nécessaires, durée de rétention adaptée, pricing tiers ajustés (Azure Monitor, Log Analytics, Sentinel). Les coûts peuvent parfois être divisés par 4. Voir les chantiers par service
−100 %
Cleaning & licences
Unattached disks, snapshots obsolètes, licences Windows Server payées en double : supprimer ce qui ne sert plus.
Build vs buy
Le bon service pour le besoin réel
Avant d'optimiser un service, nous vérifions qu'il est le bon. Un service managé haut de gamme ou un SKU premium choisi « au cas où » coûte souvent bien plus que le besoin réel. Parfois, un petit outil développé en deux jours, d'autant plus vite aujourd'hui grâce à l'IA, remplace un service coûteux pour une fraction du prix. Nous chiffrons les deux options, coût de développement et de maintenance compris, avant de recommander.
Idée reçue
« Le Stop/Start, c'est forcément rentable »
Prenons une VM non-prod à 30 € par jour. Avec une Reserved Instance ou un savings plan, elle coûte environ 50 % de moins. Avec un Stop/Start classique (arrêt planifié le soir, redémarrage planifié le matin), on gagne 50 à 60 %.
Mais les deux ne se cumulent pas : une VM réservée qui est arrêtée continue de payer sa réservation. Le Stop/Start classique demande donc beaucoup d'efforts pour un gain à peine supérieur à celui d'une simple réservation.
Ce qui fait la différence : un Stop automatique chaque soir et un Start on demand. La VM ne redémarre que lorsque quelqu'un en a besoin, et on atteint environ 90 % de savings.
En prod, la VM tourne en continu : c'est la réservation qui s'applique, pas le Stop/Start.
Résultats
Des économies mesurées sur la facture, pas des promesses
Nos missions se déroulent dans de grands groupes internationaux, sur Azure et AWS, souvent sur plusieurs années. La confidentialité fait partie de notre métier : nous ne publions ni nom de client, ni donnée de consommation.
20 M€+d'économies réalisées pour nos clients
~35 %de la facture cloud en moyenne : c'est ce que représentent ces économies
≈ 100 %des ressources taggées : identifiées, rattachées à une application et refacturées
Budget tenules dépenses restent dans le budget, et libèrent même du budget pour d'autres projets, comme la formation
En quelques mois
Le plan de remédiation appliqué
- Rightsizing validé sur POC puis déployé
- Stop auto + Start on demand en non-prod
- Chantiers sur tous les services : logs, Sentinel, backup, data…
Dans la durée
Des économies qui tiennent
- Tagging, showback puis chargeback
- Monitoring et alerting sur le forecast
- FinOps by design dans les projets
Gouvernance FinOps
Réduire, puis garder le contrôle dans la durée
Optimiser l'existant ne suffit pas : sans garde-fous, chaque nouveau projet recrée le gaspillage qu'on vient de supprimer. Notre promesse, c'est de réduire vos coûts et surtout de les garder sous contrôle. Pour cela, nous mettons en place une gouvernance FinOps qui rend le FinOps by design : des standards, des building blocks et des contrôles intégrés aux projets. Ensuite, tout ce qui arrive dans le cloud est optimisé dès le départ.
- 1ComprendreFacture, allocation des coûts par application et par owner, dashboard
- 2RéduireRecherche d'optimisations, plan de remédiation appliqué et mesuré
- 3Garder le contrôle dans la duréeGouvernance FinOps : standards, building blocks, monitoring
Des standards qui intègrent le FinOps
- SKU de VM et types de disques par défaut (Standard ou Premium selon le besoin réel)
- Politiques de rétention des données et des logs
- Backup policy adaptée à chaque environnement
- Dimensionnement pour le besoin actuel, pas pour un pic hypothétique
Des building blocks prêts à l'emploi
- Le tag obligatoire (souvent un seul) 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
- Diagnostic settings et collecte de logs filtrés dès le départ
Des contrôles dans les projets
- Checklist FinOps dans les revues d'architecture et le CAB
- Azure Policy pour bloquer les configurations non conformes
- Revue au passage en run : suppression des ressources de projet devenues inutiles
- Recommandations FinOps suivies dans le dashboard
Résultat : chaque nouvelle application respecte dès son arrivée les recommandations FinOps, et les économies obtenues ne se reperdent pas au projet suivant.
Parlons de vos standards
Premier échange
Combien perdez-vous chaque mois avec un cloud mal optimisé ?
Un premier échange de 30 minutes pour comprendre votre contexte et voir comment nous pouvons vous aider. Sans engagement.