Dès qu’on parle FinOps, le réflexe est le même : “c’est pour réduire la facture cloud”. C’est un raccourci qui rate l’essentiel. Le FinOps n’est pas une technique d’optimisation, c’est une démarche, au même titre que le DevOps l’a été pour le déploiement. Le DevOps a mis en dialogue le développement et l’exploitation. Le FinOps met en dialogue la technique, la finance et le produit, avec le coût comme langage commun.

Le coût comme outil de décision, pas comme problème à minimiser

Réduire les coûts cloud est un sous-produit du FinOps, pas son objectif. L’objectif, c’est de donner à une organisation la visibilité et le langage nécessaires pour prendre des décisions éclairées face aux coûts qu’elle engage.

Concrètement, ça veut dire être capable de répondre à des questions simples, qui restent pourtant sans réponse dans beaucoup d’entreprises : combien coûte cette feature à faire tourner, combien de temps humain a t’elle nécessité pour être livrée, et quelle valeur business génère t’elle en retour ? Sans ces réponses, une équipe ne décide pas, elle subit une facture en fin de mois.

Estimer un ROI, ce n’est pas seulement regarder la ligne “infra” d’une facture cloud. C’est mettre en face le coût humain (temps de dev, de review, de run, de support) et le coût infra (compute, stockage, réseau, licences) d’un côté, et la valeur générée de l’autre (chiffre d’affaires, rétention, réduction de charge opérationnelle). Une feature qui coûte 500€/mois d’infra mais qui a mobilisé trois développeurs pendant deux mois pour un usage marginal n’est pas rentable, même si la ligne cloud paraît négligeable.

Un révélateur d’inefficiences, au delà du financier

Ce qui rend une démarche FinOps utile va bien au delà du financier. Dès qu’une organisation commence à tagger ses ressources, à les rattacher à des équipes ou des produits, et à regarder ce que ça coûte vraiment, des inefficiences remontent qui n’ont souvent rien à voir avec le cloud en lui même :

• Produit : des features maintenues alors que personne ne les utilise, des environnements de staging qui tournent 24/7 pour un usage ponctuel.
• Process : des validations qui allongent le time to market sans réduire le risque, des équipes qui redéveloppent la même brique faute de visibilité sur l’existant.
• Vélocité d’équipe : le coût humain d’une feature, rapporté à sa valeur, révèle souvent des frictions organisationnelles avant de révéler un problème d’infra.

Le FinOps sert alors de miroir. Il ne dit pas seulement “ça coûte trop cher”, il dit “voilà où l’énergie de l’organisation part, et voilà si elle part au bon endroit”.

Une maturité encore faible

La plupart des entreprises que j’ai croisées sont encore peu matures sur ces sujets. Le budget cloud est souvent suivi au niveau global, sans granularité par équipe ou par produit. Les tags de ressources, quand ils existent, sont incomplets ou incohérents. Le sujet FinOps est porté par une seule personne ou une petite cellule, sans relais côté équipes produit, ce qui en fait un exercice de reporting plutôt qu’une culture partagée.

Cette immaturité n’est pas un problème en soi, c’est un point de départ. Le risque, c’est de vouloir aller trop vite.

Ne pas transformer l’organisation, itérer

Comme pour toute démarche de transformation, il ne faut pas chercher à tout changer d’un coup. Plaquer un cadre FinOps complet (gouvernance, allocation, forecast, chargeback) sur une organisation qui n’a même pas de tagging fiable est voué à l’échec. Une approche itérative, par paliers de maturité, fonctionne mieux dans la grande majorité des cas.

Le FinOps Framework formalise ça en trois phases, qui se répètent en boucle plutôt que de se dérouler une seule fois :

1. Collecter (Inform) : mettre en place les tags de ressources, connecter les exports de facturation (idéalement au format FOCUS), construire des dashboards par équipe ou produit. Sans cette étape, tout le reste repose sur des estimations.
2. Optimiser (Optimize) : une fois la visibilité en place, agir sur l’allocation de ressources (rightsizing), les réservations et engagements sur le long terme, le nettoyage des ressources orphelines, et le décommissionnement de ce qui ne sert plus.
3. Opérer (Operate) : installer l’amélioration continue, suivre l’usage dans la durée, faire du FinOps un réflexe dans les revues de conception plutôt qu’un audit ponctuel.

Chaque itération renforce la suivante : plus la collecte est fiable, plus l’optimisation est pertinente, plus l’opération devient un réflexe partagé plutôt qu’une contrainte imposée d’en haut.

Le cas particulier de l’IA

L’essor des usages LLM ajoute une dimension que beaucoup de stratégies FinOps ne couvrent pas encore, alors que la facture peut grimper très vite et de façon peu prévisible. Trois points méritent une attention particulière :

• Gouvernance des modèles : savoir quels modèles sont utilisés, par quelles équipes, pour quels cas d’usage, plutôt que de laisser chaque projet choisir son fournisseur et son modèle sans coordination.
• Gestion des tokens : suivre la consommation de tokens comme n’importe quelle autre ressource cloud, avec des budgets et des alertes, plutôt que de découvrir la facture en fin de mois.
• Fallback vers des modèles moins coûteux : basculer automatiquement sur un modèle moins cher en cas de dépassement de budget ou d’indisponibilité, sans bloquer l’usage ni changer le code applicatif.
• Tracking par équipe/produit : rattacher chaque appel à une clé d’équipe ou de produit, pour garder la même granularité que sur le reste de l’infra.

J’ai détaillé une mise en œuvre concrète de ces principes avec LiteLLM, qui permet de proxifier les appels aux LLM pour appliquer justement ce type de stratégie.

Conclusion

Le FinOps n’est pas un projet qu’on lance et qu’on referme une fois la facture réduite. C’est une démarche continue qui met les coûts, humains et infra, au centre du dialogue entre technique, finance et produit. Bien menée, elle ne se contente pas de faire baisser une facture cloud : elle révèle où l’énergie de l’organisation part réellement, et permet enfin d’estimer un ROI sur des bases concrètes plutôt que sur une intuition.