8 Min. temps de lecture
En 2026, FinOps sort de l’ère des tableaux de bord. 78 % des pratiques FinOps sont désormais ancrées dans l’organisation du CTO ou du CIO, et non plus dans le contrôle de gestion. Pour les équipes cloud, la question n’est plus de savoir si les coûts cloud sont visibles, mais dans quelle mesure les décisions d’ingénierie s’appuient réellement sur les données de coûts. Le passage du suivi des coûts à une discipline d’ingénierie déterminera si l’investissement dans FinOps génère le retour sur investissement promis.
L’essentiel en bref
- FinOps relève de l’organisation engineering. 78 % des pratiques sont rattachées au CTO ou au CIO, soit une progression de 18 points de pourcentage par rapport à 2023. La discipline a effectué le saut du sujet contrôle de gestion à la mission plateforme.
- Le modèle fédéré l’emporte sur le centralisé. 60 % travaillent avec des équipes centrales d’habilitation, 21 % avec des modèles hub-and-spoke. La centralisation pure ne s’adapte pas à la croissance du cloud.
- Crawl-Walk-Run reste le cœur. La FinOps Foundation n’a pas remplacé cette logique de phases en 2026. Ce qui a changé : chaque phase comporte désormais des responsabilités claires en ingénierie, et non plus seulement des indicateurs pour l’équipe FinOps.
En lienCoûts d’inférence KI : FinOps pour les workloads GPU / Opus 4.7 vs. GPT-5.4 : Inférence cloud européenne en 2026
Ce que signifie concrètement le passage du suivi des coûts à une discipline d’ingénierie
Lors de la première vague FinOps, l’enjeu était la visibilité. Tableaux de bord, alertes budgétaires, rapports mensuels d’écarts. Une étape nécessaire, mais qui a rarement permis de réaliser les économies promises, car la visibilité ne conduit pas automatiquement à l’action. Une équipe engineering qui détecte un pic de coûts dans son cluster Kubernetes un lundi doit savoir quoi modifier, qui doit valider et qui libère le temps nécessaire. Si cette chaîne fait défaut, le tableau de bord reste un simple rapport sans conséquence.
La deuxième vague (devenue mainstream en 2026) intègre FinOps directement dans les workflows d’ingénierie. Concrètement, cela signifie : les tags de coûts sont obligatoires lors du déploiement, les nouveaux services reçoivent un commentaire sur les coûts lors de la revue de PR, et les décisions d’architecture sont présentées avec un calcul de TCO. La différence ne réside pas dans l’outil, mais dans la définition de ce qu’un ingénieur doit livrer. Il s’agit d’un changement culturel qui prend trois à quatre trimestres dans de nombreuses organisations.
Un autre aspect qui devient plus visible dans la deuxième vague FinOps est l’intégration avec l’équipe Platform Engineering. Lorsqu’une organisation met en place une plateforme interne pour les développeurs, FinOps n’est pas un simple module complémentaire, mais fait partie intégrante de la discipline plateforme. Les templates Golden Path incluent dès l’origine le tagging, les limites budgétaires et les signaux de commit. Les développeurs n’ont pas besoin de pratiquer activement FinOps, car la plateforme fournit les bons paramètres par défaut. C’est la manière la plus efficace d’intégrer FinOps dans le quotidien, mais aussi la plus exigeante, car elle suppose une organisation Platform Engineering fonctionnelle.
Structures d’équipe qui fonctionnent en 2026
La FinOps Foundation distingue trois modèles principaux pour organiser la discipline. L’activation centralisée représente 60 pour cent des pratiques et constitue la configuration par défaut. Une petite équipe centrale définit les standards, les outils et les formations, tandis que la responsabilité opérationnelle incombe aux équipes produit. Le modèle hub-and-spoke, avec 21 pour cent, est courant dans les grandes entreprises : un groupe FinOps central complété par des champions dédiés par business unit. Les modèles entièrement décentralisés sont rares et ne fonctionnent en pratique que dans les organisations d’ingénierie les plus matures.
Le choix d’un modèle dépend de la taille de l’infrastructure cloud et de la culture d’ingénierie. Une entreprise avec 500 000 euros de dépenses cloud mensuelles n’a pas besoin d’un dispositif hub-and-spoke à dix champions. Une entreprise à dix millions par mois ne peut pas passer à l’échelle avec une équipe centrale sans modèle fédéré. L’erreur la plus fréquente consiste à mettre en place un modèle trop ambitieux trop tôt, car les fournisseurs FinOps ont tendance à vendre la complexité enterprise. En règle générale, une entreprise mid-market commence avec une seule personne ou une équipe de deux personnes en rôle d’enabler, puis monte en puissance lorsque les dépenses cloud le justifient.
Ce que l’on sous-estime souvent dans la structure d’équipe, c’est le rôle du partenaire Finance. Une équipe FinOps sans lien direct avec le contrôle de gestion perd son influence sur la discipline budgétaire. Inversement, un contrôle de gestion sans interlocuteur FinOps technique devient rapidement un gestionnaire de budgets sur le papier, incapable de comprendre les structures de coûts réelles du cloud. Les configurations qui réussissent en 2026 disposent d’une personne Finance dédiée, travaillant en étroite collaboration avec l’équipe FinOps, co-produisant des rapports mensuels et assumant conjointement la responsabilité des chiffres dans le reporting du management.
Un autre aspect structurel est la délimitation claire entre FinOps et les achats. L’équipe FinOps ne décide pas seule des commits, des Reserved Instances ou des contrats pluriannuels. Ces décisions impliquent les achats, la direction financière et souvent la direction générale. FinOps fournit la base de données et les simulations de scénarios ; le contrat est signé ailleurs. Les organisations qui confondent ces rôles se retrouvent soit avec des équipes FinOps disposant d’un pouvoir contractuel excessif, soit avec des services achats manquant de contexte technique. Les deux génèrent des problèmes. Une délimitation claire des rôles évite en pratique de nombreuses réunions et accélère sensiblement les décisions, car les voies d’escalade sont définies en amont. La collaboration devient alors une routine opérationnelle.
Où les pratiques FinOps bloquent en 2026
- Équipe FinOps sans pouvoir de décision sur les standards de tagging
- Tableaux de bord sans playbooks de réaction définis
- Équipes d’ingénierie sans KPIs de coûts dans leurs propres OKRs
- Absence de lien entre les contrats spéciaux et la planification des workloads
Ce qui caractérise les pratiques FinOps matures
- Politique de tagging comme gate strict au déploiement
- Métriques de coûts intégrées dans les vues d’ingénierie quotidiennes (Datadog, Grafana)
- OKRs de coûts par équipe, avec ownership direct
- Stratégie Reserved Instances et commits couplée à la roadmap des workloads
L’articulation avec les OKRs d’ingénierie est un point qui fonctionne nettement mieux en 2026 qu’en 2024. Ceux qui voient FinOps comme un frein aux coûts se heurtent à des résistances. Ceux qui traitent FinOps comme une métrique d’efficacité, au même titre que la performance, la disponibilité et la vélocité, obtiennent des équipes qui se mesurent elles-mêmes aux chiffres. La différence de formulation est minime ; la différence d’adhésion est considérable.
Les phases Crawl-Walk-Run mises en pratique concrètement
La FinOps Foundation n’a pas remplacé son modèle Crawl-Walk-Run en 2026, mais l’a affiné. Les trois phases restent, mais chacune s’est vue attribuer des responsabilités d’ingénierie plus concrètes. Crawl, c’est la prise de conscience : l’équipe comprend d’où viennent les coûts et quels services sont onéreux. En parallèle, il devient clair qui exploite quelle ressource. Durée typique : trois à six mois. Walk, c’est la prise en charge : l’équipe assume la responsabilité des ressources qu’elle exploite. Les premières décisions d’optimisation sont prises au niveau de l’équipe. Durée : six à douze mois après le début de Crawl. Run, c’est l’optimisation : les décisions basées sur les données font partie du quotidien, des politiques automatisées entrent en jeu. Les décisions de coûts s’inscrivent dans le cadre du travail d’ingénierie normal.
Dans la pratique, toutes les équipes ne traversent pas les phases au même rythme. Une équipe DevOps très sensible aux coûts peut atteindre Run en neuf mois. Une équipe produit axée sur la livraison de fonctionnalités peut parfois mettre deux ans à stabiliser Walk. Les niveaux de maturité sont attribués par équipe, et non par organisation. La fonction FinOps centrale mesure et rapporte, mais la décision concernant la vitesse appartient au responsable d’ingénierie concerné.
Une question fréquemment posée est de savoir quand les organisations atteignent Run. Les données State-of-FinOps montrent qu’en 2026, environ un tiers des pratiques se situent dans Run, avec une tendance à la hausse. La majorité continue de travailler dans la phase Walk, avec des objectifs d’optimisation clairs, mais sans intégration complète dans l’ingénierie. Le passage de Walk à Run est le moment où FinOps cesse d’être un programme à part. Il devient plutôt une composante de la discipline normale de la plateforme.
Les sujets de coûts qui font leur entrée à l’agenda en 2026
Deux sujets transforment la pratique FinOps en 2026, au-delà des catégories de coûts cloud habituelles. Le premier est la gestion des coûts liés à l’IA. Les instances GPU, la facturation à la tokenisation pour les API LLM ainsi que les coûts de stockage et de réseau pour les grands pipelines d’entraînement et d’inférence constituent une nouvelle classe de dépenses. La transparence y est moindre que pour les ressources cloud classiques, et la volatilité des prix est plus élevée. Les leviers d’optimisation diffèrent également. Intégrer les workloads IA dans un processus FinOps existant sans adaptation, c’est sous-estimer leur spécificité.
Le deuxième sujet est le Sustainability-FinOps. L’articulation entre optimisation des coûts et réduction des émissions de CO2 n’est plus un simple argument marketing : dans les rapports CSRD et les appels d’offres européens, c’est désormais un critère mesurable. Les fournisseurs cloud livrent des données d’empreinte carbone au niveau des ressources. Les tableaux de bord FinOps présentent coûts et émissions en parallèle. Pour les entreprises soumises à l’obligation CSRD, c’est une nécessité concrète, et non plus une option.
Un troisième facteur prend davantage d’importance en 2026 : l’intégration avec les achats et la gestion contractuelle. Tirer le meilleur parti des Reserved Instances, des Savings Plans et des Enterprise Discount Programs exige de planifier conjointement la roadmap des workloads, les négociations contractuelles et les décisions d’architecture. Ce n’est pas une responsabilité exclusive de l’équipe FinOps, mais une discipline partagée avec les achats et l’architecture. Les organisations qui articulent proprement ces trois dimensions économisent entre 15 et 30 % des coûts de compute purs, sans compromettre la qualité de service.
La mesure de la maturité FinOps en 2026 part des fondamentaux et aboutit à la culture d’ingénierie. Les organisations matures ne documentent pas seulement les économies mensuelles, mais la qualité de leurs processus de décision : à quelle vitesse une équipe réagit-elle à un pic de coûts ? À quelle fréquence les décisions d’architecture s’appuient-elles sur des données de coûts ? Quel est le taux de conformité du tagging dans le workflow de déploiement ? Ces méta-indicateurs révèlent si le FinOps s’est réellement ancré dans la culture d’ingénierie, ou s’il est resté un projet de tableau de bord.
Un autre aspect prend une importance croissante : l’imbrication avec le Product Management. Les décisions de fonctionnalités ont des conséquences sur les coûts qui ne se manifestent qu’en production. Un nouveau module de tableau de bord avec des analyses en temps réel sur plusieurs téraoctets de données consomme nettement plus de ressources qu’un rapport statique. Les Product Owners qui collaborent avec les rôles FinOps peuvent adresser ces arbitrages avant l’implémentation. Séparer produit et FinOps, c’est se retrouver, douze mois plus tard, avec des fonctionnalités dont personne n’avait anticipé le coût.
Pour conclure, voici un éclairage qui reste souvent dans l’ombre des rapports FinOps : en 2026, le FinOps n’est plus une discipline d’optimisation réservée aux adeptes de la frugalité, mais une compétence fondamentale de toute organisation cloud-heavy. Les entreprises qui traitent le FinOps comme un projet secondaire se feront dépasser par des concurrents qui considèrent le cost engineering comme une évidence. L’écart dans les chiffres ne se voit pas immédiatement, mais après dix-huit mois de croissance cloud, il se chiffre en dizaines de points de pourcentage dans le calcul du TCO. Le bon moment pour structurer un FinOps plus mature, ce n’est pas le prochain exercice budgétaire, c’est le trimestre en cours.
Questions fréquentes
Combien de personnes faut-il pour une équipe FinOps dans une ETI ?
Pour un budget cloud mensuel compris entre 100 000 et 500 000 euros, une personne en tant qu’animateur suffit généralement, soutenue par les architectes cloud et les équipes finance existantes. À partir d’un million d’euros par mois, une équipe de deux à trois personnes devient pertinente. Pour plusieurs millions d’euros mensuels, le modèle Hub-and-Spoke avec des champions FinOps par unité métier s’impose.
Quels outils composent le stack FinOps standard en 2026 ?
Les Cost Explorer des hyperscalers (AWS Cost Explorer, Azure Cost Management, GCP Billing) constituent la base. Au-dessus, des plateformes spécialisées comme Flexera, CloudHealth, Apptio Cloudability ou Vantage prennent le relais. Pour les coûts Kubernetes, OpenCost s’est imposé. Le choix dépend de la taille, du mix cloud et du niveau d’intégration souhaité avec les outils d’ingénierie existants.
Comment convaincre les équipes d’ingénierie de prendre au sérieux les KPI de coûts ?
La clé réside dans la visibilité au quotidien. Les données de coûts, intégrées dans le même tableau de bord que les indicateurs de performance et de disponibilité, sont prises bien plus au sérieux que des rapports mensuels isolés. L’intégration dans les OKR joue aussi un rôle : une équipe dont les objectifs trimestriels incluent une dimension coûts agit différemment de celle pour qui les coûts relèvent uniquement de FinOps.
Comment gérer les coûts de l’IA dans la pratique FinOps ?
Les coûts de l’IA nécessitent des catégories dédiées. Les budgets de tokens par équipe, l’utilisation des GPU par workload et les stratégies de routage des modèles sont les leviers opérationnels. Les approches classiques de right-sizing sont moins efficaces ici. Une sous-pratique FinOps dédiée aux coûts de l’IA, travaillant en étroite collaboration avec les ML Engineers, est recommandée.
Combien de temps faut-il réellement pour passer de Crawl à Run ?
En pratique, deux à trois ans, selon la taille et la culture de l’organisation. Ceux qui promettent moins de douze mois se concentrent souvent sur des quick wins en phase Walk et les présentent comme une phase Run. Ceux qui prévoient plus de quatre ans risquent de perdre l’attention de la direction. Le parcours réaliste consiste à afficher des progrès visibles chaque trimestre, avec des jalons clairs pour chaque équipe.
Plus d’articles du réseau MBF Media
Source de l’image à la une : Pexels / Hanna Pad (px:6801639)
