Temps de lecture : 9 minutes — Catégorie : Innovation & Transformation
La conversation qui finit toujours mal
Le scénario, je l’ai vu plusieurs fois dans des contextes différents.
Le DAF entre dans le bureau du DSI avec un graphique. La courbe de dépenses cloud monte régulièrement depuis 24 mois. Ce mois-ci, elle a passé un seuil psychologique. Le DAF demande des explications.
Le DSI, honnête, explique : « On est sur une trajectoire de migration cloud, donc oui, ça augmente, c’était prévu ». Le DAF rétorque : « Prévu, peut-être, mais on n’avait pas projeté à ce niveau-là il y a deux ans. Et surtout, est-ce qu’on dépense bien ? »
Silence. Parce que la réponse honnête, c’est : on ne sait pas vraiment.
Cette conversation, c’est le symptôme d’un problème mal posé. Le DAF pense qu’il s’agit d’une question de coûts. C’est une erreur. La facture cloud n’est pas un problème de finance. C’est un problème de gouvernance IT.
J’ai dirigé des opérations dans des environnements à forte dépense cloud, dans la banque et dans des plateformes mutualisées multi-clients. J’en suis sorti avec une conviction : tant qu’on traite la dépense cloud comme un sujet financier, on n’arrive à rien. Quand on la traite comme un sujet de gouvernance opérationnelle, on récupère 15 à 30 % de marge sans douleur.
Pourquoi le cloud échappe naturellement à la gouvernance
Avant le cloud, l’IT avait une discipline budgétaire forte. Pour acheter un serveur, il fallait un projet, un cahier des charges, un comité d’investissement, un bon de commande, une livraison. Six mois entre l’idée et la machine en production. Cette friction, frustrante pour les équipes, avait une vertu cachée : elle imposait un arbitrage explicite à chaque décision d’engagement.
Le cloud a fait exploser cette friction. Aujourd’hui, n’importe quel développeur avec une carte bancaire de service peut provisionner en quinze minutes ce qu’il aurait fallu six mois pour acheter. C’est la promesse fondatrice du cloud — agilité, time-to-market, élasticité — et elle est tenue.
Mais cette promesse a un revers que personne n’a vu venir : toutes les décisions d’engagement sont devenues invisibles. Ce qui passait auparavant par un comité passe maintenant par un script Terraform. Ce qui faisait l’objet d’un arbitrage est désormais une consommation continue, sans signal, sans seuil, sans validation.
Et c’est ainsi qu’on se retrouve avec :
- Des environnements de dev qui tournent 24h/24, week-ends compris
- Des bases de données surdimensionnées pour pallier des problèmes applicatifs jamais résolus
- Des snapshots qui s’accumulent depuis 18 mois parce que personne n’a mis en place de politique de rétention
- Des services managés sophistiqués utilisés à 5 % de leur capacité, parce qu’au moment du choix on ne savait pas exactement
- Des architectures multi-régions pour des applications qui n’ont aucun besoin de résilience géographique
- Des engagements (Reserved Instances, Savings Plans) mal calibrés ou jamais renégociés
Aucune de ces situations n’est le résultat d’un manque de compétence. Elles sont le résultat d’un manque de gouvernance. Personne n’a décidé. C’est arrivé.
Ce qu’est vraiment le FinOps
Beaucoup de DSI traitent le FinOps comme un sujet d’outillage : « il nous faut un outil de FinOps ». Avec respect, c’est passer à côté du problème.
Le FinOps, ce n’est pas un outil. C’est une discipline.
Plus précisément, c’est une discipline qui consiste à réintroduire dans le cloud les arbitrages explicites que la friction d’achat avait auparavant rendus automatiques. Cela passe par trois choses, dans cet ordre :
- De la visibilité — savoir qui dépense quoi, pour quoi, à quel rythme.
- De la responsabilité — attribuer chaque euro dépensé à une équipe, un produit, une décision identifiable.
- De l’optimisation — agir sur les écarts entre la dépense réelle et la dépense nécessaire.
Notez que l’optimisation arrive en troisième. C’est intentionnel. Optimiser sans visibilité ni responsabilité, c’est faire de la chasse aux coûts ponctuelle qui ne tient pas dans la durée. Toutes les économies obtenues sans gouvernance reviennent dans les six mois.
Les trois maturités FinOps que je rencontre
Mission après mission, je retrouve trois grands stades de maturité. Identifier le sien est la première étape.
Maturité 1 — « On regarde la facture chaque mois »
À ce stade, la fonction finance regarde la facture cloud globale. L’IT répond aux questions au cas par cas. Personne ne sait précisément qui consomme quoi. Les optimisations sont menées à chaud quand la facture surprend.
Symptômes typiques :
- Pas de tagging systématique des ressources
- Pas d’attribution des coûts par direction métier ou par produit
- Pas de budget cloud par équipe — juste un budget cloud global
- Les équipes apprennent leur consommation a posteriori, sans signal en temps réel
C’est le stade où se trouvent encore aujourd’hui une majorité d’organisations qui ont basculé en cloud il y a moins de cinq ans.
Maturité 2 — « On sait qui consomme quoi »
À ce stade, le tagging fonctionne. Les coûts sont attribués. Chaque équipe a une visibilité sur sa propre consommation. Les revues mensuelles existent. Mais l’optimisation reste réactive — on agit quand on s’aperçoit qu’on dépense trop.
Symptômes typiques :
- Des dashboards FinOps existent, mais peu d’équipes les regardent vraiment
- Les optimisations sont faites par projets, pas en continu
- Pas de modèle de chargeback ou showback structurant les comportements
- Les engagements (Reserved Instances, Savings Plans) sont sous-utilisés ou mal calibrés
C’est le stade où une optimisation FinOps livre typiquement entre 15 et 25 % d’économies, sans changer l’architecture.
Maturité 3 — « Le FinOps est dans nos rituels »
À ce stade, le FinOps n’est plus une fonction — c’est une pratique partagée. Les équipes produit ont leurs budgets et leurs indicateurs de coût unitaire. Les architectes intègrent la dimension coût dans leurs décisions. Les engagements sont gérés activement. Les anomalies déclenchent des alertes automatiques.
Symptômes typiques :
- Le coût par transaction métier est connu et suivi
- Les sprints intègrent des « tickets FinOps » comme ils intègrent des tickets de sécurité
- Le finance et l’IT parlent de la même chose dans le même langage
- Les engagements sont automatisés et révisés trimestriellement
À ce stade, l’optimisation continue rapporte 5 à 10 % par an de manière soutenable.
Les chantiers concrets pour passer d’un stade à l’autre
De Maturité 1 à Maturité 2
Chantier 1 — Le tagging. Une politique de tagging obligatoire, déployée d’abord sur les nouveaux environnements, puis rétroactivement sur l’existant. Cinq tags suffisent : direction, produit, environnement, criticité, propriétaire. Si une ressource n’a pas ces tags, elle est arrêtée automatiquement après 30 jours.
Chantier 2 — L’attribution des coûts. Mettre en place un showback mensuel par direction métier. Pas un chargeback (refacturation comptable) — un showback (visibilité). L’objectif n’est pas de refacturer, c’est de rendre visible. La refacturation viendra peut-être après, ou pas, selon votre culture.
Chantier 3 — Les rituels de revue. Une revue mensuelle de 30 minutes par grande direction métier, avec un référent FinOps de l’IT. Pas plus. Pas un comité, pas un reporting — une conversation orientée action.
De Maturité 2 à Maturité 3
Chantier 4 — Les indicateurs de coût unitaire. Pas le coût mensuel total — le coût par utilisateur, par transaction, par client. C’est le seul indicateur qui résiste à la croissance et qui permet une vraie comparaison dans le temps.
Chantier 5 — Les engagements actifs. Une revue trimestrielle des Reserved Instances et Savings Plans, avec un objectif explicite de couverture (typiquement 60 à 80 % de la consommation stable). L’erreur classique est de tout couvrir — ce qui retire la flexibilité du cloud.
Chantier 6 — L’intégration dans les architectures. Le coût comme critère explicite de décision d’architecture, au même titre que la performance, la sécurité ou la résilience. Les architectes doivent pouvoir estimer le coût d’une option avant de la retenir, pas après.
Ce qui ne marche pas (ce que je vois échouer souvent)
L’outil seul. Acheter une plateforme FinOps sans avoir mis en place les rituels et la responsabilité, c’est acheter un dashboard. Les économies tirées d’un outil sans gouvernance plafonnent à 5 à 10 %, et reviennent en 12 mois.
Le chargeback brutal. Refacturer aux directions métier sans les avoir éduquées au préalable génère du conflit, du contournement, et parfois des décisions de « shadow IT » pour échapper à la facturation interne. Le showback doit précéder le chargeback de 6 à 12 mois minimum.
La chasse aux coûts ponctuelle. « On a un sprint FinOps en mars » — typique des organisations qui n’ont pas internalisé la pratique. Ce qui n’est pas continu n’est pas FinOps.
Le pilotage par la finance seule. Le FinOps piloté par le DAF sans co-responsabilité de la DSI échoue parce que les leviers d’action sont chez les équipes IT et produit. La finance peut sponsoriser, elle ne peut pas piloter.
Le rôle du DSI — et ce qu’il faut accepter
Pour un Directeur des Infrastructures et Opérations, le FinOps représente un changement culturel important. Les équipes ops historiques sont formées à provisionner, à fiabiliser, à sécuriser. Pas à arbitrer économiquement chaque ressource. Cette compétence se construit — elle ne s’achète pas avec un outil.
Trois acceptations sont nécessaires :
Accepter de ralentir un peu pour aller plus vite ensuite. Mettre en place le tagging et les rituels prend 6 à 9 mois. Pendant ces mois, on n’optimise pas — on construit la capacité à optimiser. C’est contre-intuitif mais structurant.
Accepter de partager la donnée avec les métiers. Le réflexe IT est de présenter une facture consolidée. Le FinOps demande de présenter une facture détaillée, par produit, par équipe — y compris quand les écarts sont gênants. C’est un changement de posture vis-à-vis du COMEX.
Accepter de remettre en cause des décisions passées. Les choix d’architecture cloud faits il y a deux ou trois ans ont parfois été optimisés pour la rapidité de migration, pas pour le coût soutenable. Les remettre en cause aujourd’hui demande du courage politique. Mais c’est souvent là que se cachent les 20 % d’économies les plus importantes.
Ce que vous pouvez faire ce mois-ci
Si vous êtes DSI, Directeur des Opérations, ou DAF en charge du suivi cloud, voici trois actions immédiates :
- Faites une cartographie tagging en une semaine. Quelle proportion de vos ressources cloud porte les tags
direction,produit,environnement? Si vous êtes en dessous de 80 %, vous êtes en Maturité 1, quelle que soit l’image que vous renvoyez en interne. - Identifiez votre Top 5 de consommation. Cinq services, cinq projets, cinq équipes — selon votre angle préféré. Sur ces cinq, vous trouverez probablement entre 60 et 80 % de votre dépense cloud. C’est là que vos optimisations auront un impact.
- Posez à un sponsor unique la question suivante : « Qui est responsable, dans notre organisation, du fait que nos dépenses cloud soient bien employées ? » Si la réponse n’est pas claire, vous avez identifié votre premier chantier.
En résumé
Le cloud n’est pas trop cher. Il est mal gouverné. Et la responsabilité de cette gouvernance n’est pas chez la finance — qui n’a ni les leviers, ni la légitimité technique. Elle est chez l’IT, et plus précisément chez la Direction des Infrastructures et Opérations.
Quand cette responsabilité est assumée, le FinOps cesse d’être un sujet de tension entre IT et finance, et devient ce qu’il devrait toujours avoir été : une discipline opérationnelle qui permet d’aller plus vite, en dépensant moins.
C’est peut-être la transformation la plus tangible qu’une direction IT peut livrer aujourd’hui à son COMEX.
Cet article fait partie de la série Innovation & Transformation. Si la maturité FinOps de votre organisation appelle un regard extérieur, le premier échange est de 30 minutes, gratuit, et vous repartez avec 3 actions actionnables dès la semaine suivante.
Voir aussi : La dette opérationnelle, plus dangereuse que la dette technique et la page Management de transition Infrastructures & Opérations.