Une mission FinOps qui démarre six mois après la mise en prod, c’est un peu comme appeler un architecte une fois que la maison est construite. On peut toujours casser des murs, refaire la plomberie, déplacer la cuisine — mais ça coûte trois fois plus cher et le résultat n’est jamais aussi propre que si la question avait été posée avant le premier coup de pelle.
C’est exactement ce qui se passe avec le FinOps aujourd’hui. Et pourtant, la majorité des sollicitations arrivent encore après. Une fois que la facture pique. Une fois que la direction financière a sursauté en comité. Une fois que l’environnement est figé, avec ses choix d’architecture, ses dépendances, ses contrats déjà signés.
Le constat qui revient dans de nombreuses missions
Quand une mission FinOps est lancée en mode curatif, les marges de manœuvre sont déjà très réduites. Pas inexistantes — il reste toujours des choses à faire, c’est rare de ne pas trouver 15 à 25 % d’économies sur un environnement non optimisé. Mais on est rarement sur les leviers structurants.
On va faire du rightsizing. On va activer des Savings Plans ou des Reserved Instances. On va nettoyer des snapshots oubliés, des disques non attachés, des environnements de dev qui tournent depuis trois ans le week-end. Tout ça est utile. Mais ça reste de l’optimisation à la marge.
Les vraies économies, celles qui changent un ordre de grandeur sur la facture, elles se font ailleurs. Elles se font au moment où l’on choisit entre une VM et un managed service. Au moment où l’on décide de la stratégie de stockage. Au moment où l’on dimensionne une stratégie multi-régions. Au moment où l’on écrit l’architecture cible. Et à ce moment-là, en général, le FinOps n’est pas dans la pièce.
Pourquoi l’après coûte trois fois plus cher
Ce n’est pas un chiffre sorti du chapeau. C’est ce qui ressort assez systématiquement quand on compare deux approches sur des projets équivalents.
Optimiser après le déploiement, ça implique de revenir sur des choix d’architecture, et donc de mobiliser à nouveau les équipes dev, ops, archi. Ça implique aussi de gérer du legacy : on ne refait pas une migration vers un managed service en deux semaines quand l’application a déjà 18 mois en production. Ça implique enfin des arbitrages politiques — convaincre une équipe que son choix initial n’était pas optimal, c’est rarement une conversation facile.
Anticiper, à l’inverse, c’est intervenir sur du papier. Ou sur quelques diagrammes. Le coût de modification d’une architecture en phase de design, c’est quelques heures de réflexion. Le coût de modification de la même architecture six mois après, c’est plusieurs sprints, des risques de régression, et souvent une fenêtre de maintenance à négocier.
D’où le fameux ratio. Et encore, trois fois plus cher, c’est probablement une estimation prudente sur les cas les plus simples. Sur certains projets, on est plutôt sur du 5x ou du 10x quand il faut refaire des migrations entières.
Les erreurs que l’on rencontre souvent en amont
Le plus frustrant, c’est que la plupart des dérapages observés en aval auraient pu être évités avec quelques heures de revue en phase de cadrage.
Premier classique : aucune estimation de coût dans le dossier d’architecture. Le projet est validé sur la base d’un budget global, sans détail sur le run mensuel attendu. On découvre la facture en même temps que les utilisateurs découvrent l’application.
Deuxième classique : un choix de service par défaut, basé sur ce que l’équipe connaît, sans regarder les alternatives. Une base SQL Server sur VM parce que c’est ce qu’on faisait on-prem, alors qu’une Azure SQL Database serait moins chère et moins coûteuse à opérer. Du blob storage en hot tier pour des données qui ne seront jamais relues. Un cluster AKS surdimensionné parce que « on ne sait jamais ».
Troisième classique, et celui-là est presque systématique : aucun tagging dès le départ. On se dit qu’on tagguera plus tard. Sauf que plus tard, l’environnement contient 800 ressources réparties sur 12 équipes, et personne ne sait plus qui possède quoi. Sans tagging propre dès le jour 1, le FinOps a posteriori devient un exercice d’archéologie.
Ce que change le shift left, concrètement
Faire entrer le FinOps en amont, ça ne veut pas dire ajouter une couche de validation lourde qui va ralentir les projets. Ça veut dire intégrer la dimension coût comme un critère d’architecture au même titre que la performance, la sécurité ou la résilience.
Concrètement, ça passe par quelques points simples. Une estimation de coût intégrée au dossier d’architecture, dès la phase de design — pas une estimation au centime, mais un ordre de grandeur défendable. Une revue FinOps légère avant chaque go en production, qui valide que les choix structurants ont bien été challengés. Un référentiel de patterns d’architecture avec leur coût associé, pour que les équipes puissent comparer rapidement deux options. Et surtout, un FinOps Engineer ou un référent qui est dans la boucle dès les premières discussions, pas convoqué en pompier six mois plus tard.
Ça suppose aussi un changement de posture côté équipes projet. Le coût ne doit plus être vu comme un sujet IT ou un sujet finance, mais comme une caractéristique du produit. Au même titre qu’on discute du SLA cible ou du niveau de chiffrement, on devrait discuter du coût unitaire cible.
Le coût caché des missions tardives
Quand une mission FinOps démarre trop tard, le ROI affiché reste bon — on va trouver des économies, c’est mécanique. Mais ce ROI masque un coût bien réel : celui de tout ce qu’il aurait fallu refaire pour aller chercher les vraies économies, et qu’on ne fera pas, parce que c’est trop cher de revenir en arrière.
Ce coût caché, c’est exactement ce qui justifie le ratio évoqué plus haut. Le client paye une fois la mission d’optimisation. Mais il paye aussi, sans s’en rendre compte, le surcoût mensuel d’une architecture qui n’a jamais été pensée pour être économe. Et ce surcoût, lui, court tant que l’application est en production. Sur trois ans, ça pèse souvent bien plus lourd que les économies effectivement réalisées par la mission curative.
Le client achète de l’optimisation à la marge alors qu’il aurait pu acheter de la transformation structurelle. Et la prochaine architecture, elle, sera construite avec les mêmes biais que la précédente, parce que personne n’aura fait le travail d’éducation et de méthode en amont.
Ce qui est intéressant aujourd’hui, ce n’est plus de gratter 20 % sur une facture cloud. C’est d’aider une organisation à construire ses prochains projets avec une vraie discipline financière dès le départ. Et ça, ça ne se fait pas quand l’environnement est déjà en prod.
« Une mission FinOps qui démarre après le déploiement, c’est de l’optimisation. Une mission FinOps qui démarre avant, c’est de la transformation. »
« Le vrai gain FinOps ne se trouve pas dans les Reserved Instances. Il se trouve dans les décisions qui n’ont pas encore été prises. »
Une évolution naturelle du métier
Le FinOps tel qu’il est pratiqué aujourd’hui répond à un vrai besoin : aider les organisations à reprendre la main sur des factures cloud qui ont souvent grossi plus vite que prévu. Et les missions curatives ont leur utilité — elles permettent de stabiliser une situation, de générer des économies rapides, et souvent de déclencher la prise de conscience qui manquait.
Mais une fois cette première étape franchie, la valeur se déplace progressivement vers l’amont. Vers les phases de design, de cadrage, de revue d’architecture. C’est là que les leviers les plus structurants se trouvent, et c’est là que le métier est sans doute en train d’évoluer.
Le shift left n’est pas un concept neuf. On l’a appliqué à la sécurité (DevSecOps), aux tests, à la qualité. Le FinOps en est encore à ses débuts sur ce terrain, et c’est probablement le prochain virage du métier — pas en remplacement des pratiques actuelles, mais en complément.
C’est exactement le type d’approche défendue chez YopoConsulting — intervenir tôt, sur les phases de design et de cadrage, pour éviter que la facture devienne un sujet six mois trop tard. Pour avoir une première idée de la maturité FinOps de votre organisation, un assessment gratuit est disponible — quelques minutes suffisent pour situer vos pratiques et identifier les principaux axes de travail. Et si l’approche shift left vous parle, on peut en discuter.