Sur Azure, AWS ou tout autre cloud, nous commençons par rendre vos coûts visibles dans un dashboard. Ensuite, nous trouvons les optimisations et nous les faisons appliquer. Enfin, nous mettons en place une gouvernance FinOps qui rend le FinOps by design : chaque nouvelle application arrive dans le cloud déjà optimisée.
✓ Une prestation qui se rembourse très souvent dès le premier mois.
Le cloud se paie à l'usage, chaque minute. C'est sa force, mais sans pilotage la facture grimpe chaque mois : des VM tournent la nuit et le week-end, d'autres sont dimensionnées pour un pic qui n'arrive jamais, et des disques restent facturés longtemps après la fin d'un projet.
Sans pilotage, une hausse de quelques pour cent par mois passe inaperçue. À 5 % par mois, la facture augmente de 80 % en un an.
Quand le tagging n'est pas maîtrisé, une partie de la facture n'est rattachée à aucune équipe. Personne ne la regarde, donc personne ne l'optimise.
Une recommandation connue mais pas appliquée continue de coûter, jour après jour. Sur un grand périmètre, cela représente vite des centaines de milliers d'euros par an.
Ces trois cas sont typiques de ce que nous trouvons à chaque audit (montants illustratifs). Multipliés par des centaines de ressources, ils représentent des centaines de milliers d'euros par an. Le FinOps sert à les trouver, à les chiffrer et à les faire corriger.
Estimer mes économiesLe 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.
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.
Illustration. Quand la non-prod dépasse la prod, il y a presque toujours des environnements allumés pour rien ou surdimensionnés.
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éÀ notre arrivée chez un client, 35 % des ressources n'étaient pas taggées. Aujourd'hui, 99,9 % le sont correctement.
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.
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.
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.
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.
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.
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.
Les ordres de grandeur ci-dessous viennent de nos missions. Ils s'appliquent à la ressource optimisée, pas à la facture totale.
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 ?
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
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.
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.
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
Unattached disks, snapshots obsolètes, licences Windows Server payées en double : supprimer ce qui ne sert plus.
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.
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.
Un Log Analytics Workspace activé par l'équipe sécurité ou une backup policy par défaut coûtent peu le jour de leur mise en place. Deux ans plus tard, avec la croissance des volumes, ils pèsent des dizaines de milliers d'euros par mois. Les services présentés ci-dessous ne sont que des exemples : la même démarche s'applique à tous les services cloud. Nous avons mené de gros chantiers sur ces services avec les experts concernés (SOC, équipes data, Ops backup). L'objectif est de réduire le volume sans rien perdre en sécurité, en conformité ou en performance.
Chaque nouvelle ressource et chaque diagnostic setting activé par défaut ajoute du volume, souvent sans que personne n'exploite ces logs.
Des coûts parfois divisés par 4, sans perdre les logs réellement exploités
Déployé par la sécurité pour un périmètre restreint, puis élargi source après source : firewalls, proxies, Entra ID, endpoints… L'ingestion explose.
Économies obtenues sans dégrader la détection, chaque filtre étant validé par l'équipe sécurité
Rétention de 10 ans, backups non-prod traités comme la prod, tout stocké en Cool : la facture suit le volume, mois après mois.
Un coût au Go qui baisse, même quand le volume augmente
Auto-scale sans plafond adapté, auto-pause trop long, UAT rafraîchie comme la prod : la plateforme data consomme bien au-delà du budget.
Chaque réglage est testé avec l'équipe data, avec un suivi de l'impact sur la performance
Les datasets et les refresh s'accumulent, la capacité monte en SKU, et personne ne sait ce qui est encore utilisé.
Le bon SKU au bon moment, sans freiner les équipes data
Sur ces services, une économie mal pensée peut faire perdre une alerte de sécurité ou une sauvegarde nécessaire. Chaque chantier se mène donc avec l'équipe qui possède le service :
Les engagements (Reserved Instances, savings plans, MACC) sont le levier le plus puissant du FinOps : jusqu'à 50 % de savings sur une VM réservée, sans modifier une seule application. Mal calibrés, ils figent pourtant du gaspillage pendant trois ans. Nous construisons et pilotons toute la stratégie, de l'analyse de la charge jusqu'au renouvellement des engagements.
Rightsizing et Stop/Start d'abord. On ne s'engage pas trois ans sur des ressources oversized ou inutiles.
Historique d'usage par famille de VM (SKU), région et service, pour réserver uniquement ce qui tourne en permanence.
Reserved Instance 1 ou 3 ans ou savings plan, scope shared ou single. Au-delà des VM : storage, bases de données, Synapse, Fabric, et engagement global avec le cloud provider (MACC, EDP).
Coverage et utilization suivis chaque jour. Exchanges et refunds quand l'architecture évolue, et renouvellements préparés en amont.
Pas de modèle générique : nous construisons chaque dashboard autour de votre organisation, de vos indicateurs et de vos outils, notamment votre CMDB. La direction voit la trajectoire globale, chaque responsable d'application voit son périmètre, et tout le monde lit les mêmes chiffres.
| Application | App owner (CMDB) | Coût / mois | Savings potentiels | CO₂ |
|---|---|---|---|---|
| Data platform | Équipe Data | 77 k€ | 14,5 k€ | 1,9 t |
| ERP Finance | IT Finance | 48 k€ | 9,2 k€ | 1,1 t |
| Portail clients | Digital | 31 k€ | 6,8 k€ | 0,7 t |
| VDI | Workplace | 22 k€ | 8,1 k€ | 0,5 t |
Les données de billing de vos cloud providers sont rechargées tous les jours. Une dérive se voit le lendemain, pas à la réception de la facture.
Indicateurs, découpages et vues sont définis avec vous. Chaque coût est rattaché à son application et à son responsable grâce à votre CMDB, quel que soit l'outil (ServiceNow ou autre).
Du comité de direction au responsable applicatif, chacun accède au niveau de détail utile : groupe, entité, application, environnement.
Chaque recommandation est suivie jusqu'à son application, et le gain est mesuré. Le budget libéré peut être réaffecté, par application ou globalement, à de nouveaux projets.
Les émissions de CO₂ sont affichées à côté des coûts, par application et par entité, avec leur évolution dans le temps.
Coverage, utilization et échéances des RI et savings plans : rien n'expire par surprise et aucun engagement ne reste sous-utilisé.
Nos dashboards reprennent le principe d'Azure Advisor ou d'AWS Trusted Advisor, en allant beaucoup plus loin. Nous collectons les métriques d'utilisation de chaque ressource, et nous les confrontons à des règles concrètes, définies avec votre DSI et adaptées à votre contexte : environnement, criticité, pics de charge attendus. Chaque recommandation est affichée, chiffrée, puis suivie jusqu'à sa mise en place.
À chaque retour, les règles s'affinent. Résultat : les recommandations appliquées tiennent leurs promesses, et le saving réel correspond au saving estimé.
| Cas | Condition (30 derniers jours) | Recommandation |
|---|---|---|
| VM oversized | CPU et RAM P95 < 50 % | Passer au SKU inférieur |
| VM inutilisée | CPU P95 < 3 %, CPU moyen ≤ 2 %, network out < 2 % | Arrêter, puis supprimer si confirmé |
| Disque oversized | % used disk < 50 % | Réduire la taille du disque |
| Unattached disk | Disque rattaché à aucune VM | Supprimer après validation |
Les seuils sont des points de départ : ils sont ajustés avec chaque client, puis affinés à partir des retours terrain.
Un dashboard montre ce qui s'est passé. Le monitoring surveille la consommation en continu, à chaque mise à jour des données de billing, et alerte dès qu'une trajectoire sort des clous. Vous réagissez à un dépassement ou à un incident FinOps avant qu'il ne coûte cher.
Un dépassement peut coûter plusieurs dizaines de milliers d'euros par jour.
Et un budget cloud alerte, il ne coupe rien : sans monitoring, l'incident se découvre à la facture, un mois plus tard. Avec une alerte, il est stoppé dans la journée.
Un pod en crash loop, avec les logs en mode debug, peut générer plusieurs To par jour. À environ 5 € le Go ingéré dans Log Analytics et Sentinel (pay-as-you-go), 5 To par jour représentent environ 25 000 € par jour.
Une nouvelle source (firewall, proxy, EDR) branchée sans filtre sur le SIEM, et l'ingestion double du jour au lendemain.
Une réplication ou une synchronisation qui tourne en boucle entre régions ou vers Internet : le data transfer est facturé au Go, et les flow logs suivent la même pente.
Une fonction serverless déclenchée par sa propre sortie, des retries sans fin. Cas public : une startup a reçu 72 000 $ de facture en environ deux heures pour un test budgété à 7 $ (The Register, 2020).
Le forecast de fin d'année est recalculé chaque jour. Dès qu'un périmètre est parti pour dépasser son budget, son owner est alerté, des mois avant la fin de l'exercice. Le plan d'action peut ainsi démarrer dès les premières semaines de l'année.
Hausse brutale d'un service ou d'une application d'un jour à l'autre ou d'un mois à l'autre : nouvelle source de logs, mauvais SKU déployé, ressource oubliée.
Les services d'IA générative peuvent s'emballer en quelques heures. Des guardrails (budgets, quotas, seuils journaliers) évitent les mauvaises surprises.
Réservation sous-utilisée, coverage en baisse ou échéance proche : chaque engagement reste rentable.
Data platform : forecast 2026 à 412 k€ pour un budget de 350 k€ (+18 %)
Owner notifié par mail et Teams · 07:42Log Analytics : ingestion ×3 depuis hier, nouvelle source de diagnostic
Analyse en cours avec l'équipe sécurité · 09:15Azure OpenAI : coût journalier ×4 par rapport à la moyenne sur 30 jours
Quota appliqué · 10:03Coverage RI / savings plans : 85 % (cible 80 %)
Aucune action requiseConstruire le budget cloud de l'année suivante est un exercice difficile : la consommation varie, les projets arrivent, les prix changent. Nous vous aidons à estimer vos coûts futurs à partir de votre consommation réelle, de vos environnements et des projets que vous nous annoncez.
Consommation réelle par application et par environnement, sa tendance et ses saisonnalités.
Nouvelles applications, migrations vers le cloud, montées en charge, décommissionnements : chaque annonce est chiffrée (SKU, volumes, environnements prod et non-prod).
Savings planifiés (plan de remédiation, réservations), échéances des engagements, évolution des prix et du taux de change USD/EUR.
Un budget N+1 par application et par entité, que la DSI peut défendre devant la direction financière, hypothèse par hypothèse.
Prudent, probable, avec ou sans optimisations : vous voyez l'impact de chaque décision avant de la prendre.
Le forecast est recalculé en continu et comparé au budget. Toute dérive déclenche une alerte, et l'écart est expliqué au SteerCo.
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.
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 standardsNos 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.
Le GreenOps applique la logique du FinOps à l'empreinte environnementale du cloud. Les deux vont dans le même sens : une VM supprimée ne coûte plus rien et n'émet plus rien. Nous intégrons les émissions carbone au même dashboard que les coûts, pour que vos équipes RSE et IT regardent les mêmes chiffres.
Les données d'émissions des cloud providers (Azure Emissions Impact Dashboard, AWS Customer Carbon Footprint Tool) sont croisées avec le billing, par application et par entité.
Une centaine de tonnes de CO₂ par an, c'est environ 50 allers-retours Paris–New York en avion, ou plus de 10 tours de la Terre en voiture. Un chiffre parlant fait plus pour la sensibilisation que dix dashboards.
Les émissions du cloud sont mises en forme, avec leur historique, pour alimenter votre bilan carbone et vos échanges avec la direction RSE.
Répartition typique des émissions d'un client Azure, d'après les données Microsoft :
Conséquence : le meilleur levier GreenOps est la sobriété. Moins de VM allumées, moins de données conservées et des ressources à la bonne taille, c'est moins de matériel à fabriquer.
| Levier | € | CO₂ réel |
|---|---|---|
| Cleaning des ressources inutilisées | Oui | Oui |
| Stop/Start non-prod et VDI | Oui | Oui |
| Rightsizing | Oui | Oui |
| Data retention policy | Oui | Oui |
| Reserved Instances / savings plans | Oui | Non |
Une réservation réduit fortement la facture, mais elle ne change rien à la consommation physique. Or certains dashboards des cloud providers affichent quand même une baisse d'émissions. Nous séparons donc les économies financières des réductions d'empreinte réelles, et nous précisons toujours la source et la date des chiffres carbone (ils sont publiés avec un à deux mois de décalage).
Indiquez votre dépense cloud annuelle pour obtenir un ordre de grandeur des économies atteignables.
Montant de la facture sur 12 mois, en euros.
Niveau de maturité FinOps actuel
Estimation indicative, fondée sur les taux observés en mission. Notre analyse donne un chiffrage précis, ressource par ressource. Les économies du premier mois couvrent très souvent le coût de la prestation.
Vous avez un export de coûts Azure ? Déposez-le dans notre outil d'analyse : il chiffre en €/mois les économies déjà visibles dans la facture, ressource par ressource, sans que le fichier quitte votre navigateur.
Analyser mon export AzurePour les PME, un accompagnement rémunéré au résultat. Pour les grands comptes, un accompagnement à la journée, au plus près de vos équipes. Dans les deux cas, nous combinons expertise FinOps et outils d'analyse et d'automatisation dopés à l'IA.
Une prestation qui se rembourse dès le premier mois.
Les économies réalisées dès le premier mois sont très souvent supérieures au coût de la prestation. En réalité, le FinOps ne vous coûte rien : il se finance avec l'argent qu'il vous fait économiser, et tout le reste est du gain.
De la stratégie d'engagement jusqu'au tuning d'un Spark pool, nous couvrons tous les leviers du FinOps, en particulier sur les services qui pèsent le plus lourd dans la facture.
Payer moins cher la même consommation.
Consommer uniquement ce qui est utile.
Les services qui dérivent avec les volumes.
Des chiffres justes, rafraîchis chaque jour.
Rendre les économies durables.
Le carbone et les nouveaux postes de coût.
Consultant FinOps et fondateur de FinOps Pilote (AB Conseil), Aymeric vient de l'infrastructure : serveurs, réseaux, migrations de datacenter. Il sait donc ce qu'implique une recommandation pour ceux qui doivent l'appliquer. Depuis huit ans, il aide de grands groupes à reprendre la main sur leurs dépenses cloud.
Une conviction guide toute notre approche : une économie ne compte que lorsqu'elle apparaît sur la facture.
Le FinOps (Cloud Financial Operations) est une discipline qui réunit la finance, la DSI et les équipes techniques pour piloter les dépenses cloud. Elle repose sur trois phases définies par la FinOps Foundation : rendre les coûts visibles (Inform), les optimiser (Optimize) et instaurer une gouvernance durable (Operate). L'objectif n'est pas de dépenser moins à tout prix, mais de dépenser juste.
Le GreenOps applique la démarche FinOps à l'empreinte environnementale du cloud : mesurer les émissions de CO₂ par application et par entité, puis réduire celles qui viennent de ressources inutiles ou oversized. Une VM supprimée ou arrêtée ne coûte plus rien et n'émet plus rien. Les réservations, elles, baissent la facture sans réduire l'empreinte physique.
Pour comprendre et maîtriser ses coûts cloud, connaître son empreinte carbone et réaliser des économies : environ 35 % de la facture en moyenne quand rien n'est encore piloté. Pour un grand groupe, cela représente des millions d'euros par an, et une mission FinOps est rentabilisée très rapidement.
En général 15 à 35 % selon la maturité FinOps de départ. Les principaux leviers sont les Reserved Instances et savings plans (environ 50 % sur les VM de prod), le Stop automatique avec Start on demand (environ 90 % sur la non-prod et les VDI), le rightsizing, le storage tiering et l'optimisation des logs (Log Analytics, Sentinel).
Oui. Nous estimons vos coûts futurs à partir de votre consommation réelle, de vos environnements et des projets que vous nous annoncez (nouvelles applications, migrations, décommissionnements), en intégrant les savings planifiés et l'évolution des prix. Vous obtenez un budget N+1 argumenté par application, avec des scénarios, puis un forecast suivi en continu.
C'est une question que nous posons systématiquement. Un service managé coûteux est parfois surdimensionné pour l'usage réel : un SKU inférieur, un autre service, ou un petit outil développé en quelques jours peut suffire. Nous comparons les options, coûts de développement et de maintenance compris, avant de recommander.
Pour les PME, nous sommes rémunérés au résultat : 20 % des économies annuelles réalisées, mesurées sur la facture. Pas d'économie, pas de facture. Pour les grands comptes, l'accompagnement est facturé à la journée, selon le périmètre. Dans les faits, les économies réalisées dès le premier mois sont très souvent supérieures au coût de la prestation : le FinOps ne vous coûte rien.
Non, pas pour démarrer. Un accès en lecture seule (Reader) aux données de billing et aux métriques d'utilisation suffit. Les modifications sont ensuite appliquées par vos équipes ou votre infogérant, selon le circuit de validation que vous choisissez.
Chaque recommandation s'appuie sur des seuils prudents, par exemple CPU et RAM P95 sous les 50 % sur 30 jours. Elle est d'abord testée sur un POC, et on surveille l'impact juste après l'application. Les applications critiques qui attendent un pic de charge sont traitées à part.
Dès le premier mois pour les Reserved Instances, le cleaning et le storage tiering, qui ne demandent aucune modification applicative. Le rightsizing et le Stop/Start suivent dans les mois qui viennent.
C'est le blocage le plus fréquent, surtout quand les équipes ne paient pas ce qu'elles consomment. Deux leviers marchent : rendre les coûts visibles et refacturés à chaque application, et obtenir un mandat clair de la direction. Nous vous aidons à mettre en place les deux.
Azure et AWS sont nos environnements de prédilection, mais nous nous adaptons à tout autre cloud provider : Google Cloud, Oracle Cloud, clouds souverains ou environnements multi-cloud. Nous avons déjà transposé notre démarche d'Azure vers AWS. La méthode (visibilité, optimisation, gouvernance) reste la même, seuls les outils et les leviers de tarification changent.
Les services d'IA générative peuvent faire grimper une facture très vite. Nous mettons en place un suivi dédié et des guardrails (budgets, alerting, quotas) pour éviter les mauvaises surprises.
Un premier échange de 30 minutes pour comprendre votre contexte et voir comment nous pouvons vous aider. Sans engagement.