8 min de lecture<\/p>\n
En 2026, FinOps sort de l’\u00e8re des tableaux de bord. 78 % des pratiques FinOps sont d\u00e9sormais ancr\u00e9es dans l’organisation du CTO ou du CIO, et non plus dans le contr\u00f4le de gestion. Pour les \u00e9quipes cloud, cela signifie que la question n’est plus de savoir si les co\u00fbts cloud sont visibles, mais dans quelle mesure les d\u00e9cisions d’ing\u00e9nierie s’appuient r\u00e9ellement sur les donn\u00e9es de co\u00fbts. Le passage du suivi des co\u00fbts \u00e0 une discipline d’ing\u00e9nierie d\u00e9terminera si l’investissement dans FinOps g\u00e9n\u00e8re le retour sur investissement promis.<\/strong><\/p>\n L’essentiel en bref<\/p>\n En relation<\/span>Co\u00fbts d’inf\u00e9rence d’IA : FinOps pour les charges de travail GPU<\/a> \/<\/span> Opus 4.7 vs GPT-5.4 : Inf\u00e9rence cloud europ\u00e9enne en 2026<\/a><\/p>\n La premi\u00e8re vague FinOps \u00e9tait ax\u00e9e sur la visibilit\u00e9. Tableaux de bord, alertes budg\u00e9taires, rapports mensuels d\u2019\u00e9carts. Une \u00e9tape n\u00e9cessaire, mais qui a rarement permis de r\u00e9aliser les \u00e9conomies promises, car la visibilit\u00e9 ne se traduit pas automatiquement en actions. Une \u00e9quipe d\u2019ing\u00e9nierie qui constate un pic de co\u00fbts dans son cluster Kubernetes un lundi doit tout de m\u00eame savoir quoi modifier, qui doit donner son accord et qui lib\u00e8re le temps n\u00e9cessaire. Si cette cha\u00eene fait d\u00e9faut, le tableau de bord reste un simple rapport sans cons\u00e9quence.<\/p>\n La deuxi\u00e8me vague (qui devrait s\u2019imposer dans le courant en 2026) int\u00e8gre directement FinOps aux workflows d\u2019ing\u00e9nierie. Concr\u00e8tement, cela signifie que les tags de co\u00fbts deviennent une composante obligatoire lors du d\u00e9ploiement, que les nouveaux services font l\u2019objet d\u2019un commentaire sur les co\u00fbts lors de la revue de pull request (PR), et que les d\u00e9cisions d\u2019architecture sont pr\u00e9sent\u00e9es avec un calcul du co\u00fbt total de possession (TCO). La diff\u00e9rence ne r\u00e9side pas dans l\u2019outil, mais dans la d\u00e9finition de ce qu\u2019un ing\u00e9nieur doit livrer. Il s\u2019agit d\u2019un changement culturel qui prend g\u00e9n\u00e9ralement trois \u00e0 quatre trimestres dans de nombreuses organisations.<\/p>\n Un autre aspect qui devient bien plus visible dans cette deuxi\u00e8me vague FinOps est l\u2019int\u00e9gration avec les \u00e9quipes de platform engineering (ing\u00e9nierie de plateforme). Lorsqu\u2019une organisation met en place une plateforme interne pour les d\u00e9veloppeurs, FinOps n\u2019est plus un simple module compl\u00e9mentaire, mais une composante \u00e0 part enti\u00e8re de la discipline de plateforme. Les templates de golden path int\u00e8grent d\u00e8s leur conception le tagging, les limites budg\u00e9taires et les signaux de commit. Les d\u00e9veloppeurs n\u2019ont pas besoin de pratiquer activement FinOps, car la plateforme fournit les bons param\u00e8tres par d\u00e9faut. C\u2019est la mani\u00e8re la plus efficace d\u2019ancrer FinOps dans le quotidien – mais aussi la plus exigeante, car elle suppose une organisation de platform engineering d\u00e9j\u00e0 op\u00e9rationnelle.<\/p>\n La FinOps Foundation distingue trois mod\u00e8les principaux pour organiser cette discipline. Avec 60 % des pratiques, l\u2019Enablement centralis\u00e9 reste la norme. Une petite \u00e9quipe centrale d\u00e9finit les standards, les outils et les formations, tandis que l\u2019action op\u00e9rationnelle rel\u00e8ve des \u00e9quipes produit. Le mod\u00e8le Hub-and-Spoke, adopt\u00e9 par 21 % des organisations, est courant dans les grandes entreprises : un groupe FinOps centralis\u00e9, compl\u00e9t\u00e9 par des champions d\u00e9di\u00e9s au sein de chaque unit\u00e9 m\u00e9tier. Les mod\u00e8les enti\u00e8rement d\u00e9centralis\u00e9s sont rares et ne fonctionnent, en pratique, que dans des organisations d\u2019ing\u00e9nierie tr\u00e8s matures.<\/p>\n Le choix d\u2019un mod\u00e8le d\u00e9pend de la taille de l\u2019infrastructure cloud et de la culture d\u2019ing\u00e9nierie. Une entreprise dont les d\u00e9penses cloud mensuelles s\u2019\u00e9l\u00e8vent \u00e0 500 000 euros n\u2019a pas besoin d\u2019un dispositif Hub-and-Spoke avec dix champions. \u00c0 l\u2019inverse, une entreprise d\u00e9pensant dix millions d\u2019euros par mois ne peut pas \u00e9voluer avec une \u00e9quipe centrale sans mod\u00e8le de f\u00e9d\u00e9ration. L\u2019erreur la plus fr\u00e9quente consiste \u00e0 d\u00e9ployer trop t\u00f4t un mod\u00e8le trop ambitieux, car les fournisseurs de solutions FinOps aiment vendre la complexit\u00e9 \u00ab entreprise \u00bb. En r\u00e8gle g\u00e9n\u00e9rale, une entreprise du mid-market commence avec une personne ou une \u00e9quipe de deux personnes en tant qu\u2019Enablement, puis \u00e9volue lorsque les d\u00e9penses cloud le justifient.<\/p>\n Un aspect souvent sous-estim\u00e9 dans la structure d\u2019\u00e9quipe est le r\u00f4le du partenaire financier. Une \u00e9quipe FinOps sans lien direct avec le contr\u00f4le de gestion perd son influence sur la discipline budg\u00e9taire. \u00c0 l\u2019inverse, un contr\u00f4le de gestion sans contact technique avec le FinOps se transforme rapidement en gestionnaire de budgets th\u00e9oriques, incapable de comprendre les structures de co\u00fbts r\u00e9elles du cloud. Les configurations gagnantes en 2026 int\u00e8grent une personne d\u00e9di\u00e9e aux finances, qui collabore \u00e9troitement avec l\u2019\u00e9quipe FinOps, produit des rapports mensuels conjoints et partage la responsabilit\u00e9 des chiffres dans le reporting de gestion.<\/p>\n Un autre point structurel crucial est la distinction claire entre FinOps et les achats. Le FinOps ne d\u00e9cide pas seul des engagements, des instances r\u00e9serv\u00e9es ou des contrats pluriannuels. Ces d\u00e9cisions n\u00e9cessitent l\u2019intervention des achats, de la direction financi\u00e8re et souvent du comit\u00e9 de direction. Le FinOps fournit les donn\u00e9es et les sc\u00e9narios de calcul, mais c\u2019est ailleurs que le contrat est sign\u00e9. Les organisations qui m\u00e9langent ces r\u00f4les se retrouvent soit avec des \u00e9quipes FinOps dot\u00e9es d\u2019un pouvoir contractuel excessif, soit avec des services achats manquant de contexte technique. Dans les deux cas, cela g\u00e9n\u00e8re des probl\u00e8mes. Une r\u00e9partition claire des r\u00f4les permet d\u2019\u00e9viter de nombreuses r\u00e9unions et acc\u00e9l\u00e8re sensiblement les d\u00e9cisions, car les voies d\u2019escalade sont d\u00e9finies \u00e0 l\u2019avance. La collaboration devient une routine op\u00e9rationnelle.<\/p>\n O\u00f9 les pratiques FinOps bloquent en 2026<\/p>\n Ce qui caract\u00e9rise les pratiques FinOps matures<\/p>\n L\u2019articulation avec les OKR des \u00e9quipes d\u2019ing\u00e9nierie est un point qui r\u00e9ussit bien plus souvent en 2026 qu\u2019en 2024. Qui voit le FinOps comme un frein aux co\u00fbts rencontre des r\u00e9sistances. Qui le consid\u00e8re comme une m\u00e9trique d\u2019efficacit\u00e9, au m\u00eame titre que la performance, la disponibilit\u00e9 et la rapidit\u00e9, obtient des \u00e9quipes qui s\u2019auto-\u00e9valuent sur la base de ces indicateurs. La diff\u00e9rence de langage est minime, mais l\u2019impact sur l\u2019acceptation est majeur.<\/p>\n La FinOps Foundation n’a pas remplac\u00e9 son mod\u00e8le Crawl-Walk-Run d’ici 2026, mais l’a affin\u00e9. Les trois phases restent inchang\u00e9es, mais chacune s’est vue attribuer des responsabilit\u00e9s d’ing\u00e9nierie plus pr\u00e9cises. La phase Crawl correspond \u00e0 la prise de conscience : l’\u00e9quipe comprend d’o\u00f9 proviennent les co\u00fbts et quels services sont on\u00e9reux. En parall\u00e8le, il devient clair qui exploite quelle ressource. Dur\u00e9e typique : trois \u00e0 six mois. La phase Walk marque l’appropriation : l’\u00e9quipe assume la responsabilit\u00e9 des ressources qu’elle exploite. Les premi\u00e8res d\u00e9cisions d’optimisation sont prises au niveau de l’\u00e9quipe. Dur\u00e9e : six \u00e0 douze mois apr\u00e8s le d\u00e9but de la phase Crawl. Enfin, la phase Run incarne l’optimisation : les d\u00e9cisions bas\u00e9es sur les donn\u00e9es font partie du quotidien, et des politiques automatis\u00e9es entrent en jeu. Les d\u00e9cisions relatives aux co\u00fbts s’inscrivent dans le cadre du travail d’ing\u00e9nierie habituel.<\/p>\n Dans la pratique, toutes les \u00e9quipes ne progressent pas au m\u00eame rythme \u00e0 travers ces phases. Une \u00e9quipe DevOps tr\u00e8s sensible aux co\u00fbts peut atteindre la phase Run en neuf mois. Une \u00e9quipe produit ax\u00e9e sur la livraison de fonctionnalit\u00e9s peut parfois mettre deux ans \u00e0 stabiliser la phase Walk. Les niveaux de maturit\u00e9 sont attribu\u00e9s par \u00e9quipe, et non par organisation. La fonction FinOps centrale mesure et rapporte les progr\u00e8s, mais la d\u00e9cision concernant la vitesse de progression revient au responsable d’ing\u00e9nierie concern\u00e9.<\/p>\n Une question fr\u00e9quemment pos\u00e9e concerne le moment o\u00f9 les organisations atteignent la phase Run. Les donn\u00e9es du rapport *State of FinOps* montrent qu’en 2026, environ un tiers des pratiques se situent dans cette phase, avec une tendance \u00e0 la hausse. La majorit\u00e9 des organisations continuent de travailler dans la phase Walk, avec des objectifs d’optimisation clairs, mais sans int\u00e9gration compl\u00e8te dans les processus d’ing\u00e9nierie. Le passage de Walk \u00e0 Run marque le moment o\u00f9 FinOps cesse d’\u00eatre un programme distinct pour devenir une composante naturelle de la discipline des plateformes.<\/p>\n Deux th\u00e8mes vont transformer la pratique FinOps en 2026, au-del\u00e0 des cat\u00e9gories classiques de co\u00fbts cloud. Le premier : la gestion des co\u00fbts li\u00e9s \u00e0 l’IA. Les instances GPU, la facturation \u00e0 la token pour les API de grands mod\u00e8les de langage (LLM) et les co\u00fbts de stockage et de r\u00e9seau associ\u00e9s aux pipelines d’entra\u00eenement et d’inf\u00e9rence massifs constituent une nouvelle classe de d\u00e9penses. La transparence y est moindre qu’avec les ressources cloud traditionnelles, et la volatilit\u00e9 des prix, plus \u00e9lev\u00e9e. Les leviers d’optimisation diff\u00e8rent \u00e9galement. Qui se contente d’int\u00e9grer les workloads IA dans un processus FinOps existant sous-estime leurs sp\u00e9cificit\u00e9s.<\/p>\n Le second th\u00e8me est le FinOps durable. L’articulation entre optimisation des co\u00fbts et r\u00e9duction des \u00e9missions de CO\u2082 ne rel\u00e8ve plus du simple argument marketing : elle devient un crit\u00e8re mesurable dans les rapports CSRD (Corporate Sustainability Reporting Directive, directive europ\u00e9enne sur la publication d’informations en mati\u00e8re de durabilit\u00e9) et les appels d’offres europ\u00e9ens. Les fournisseurs cloud fournissent d\u00e9sormais des donn\u00e9es d’empreinte carbone au niveau des ressources. Les tableaux de bord FinOps affichent en parall\u00e8le co\u00fbts et \u00e9missions. Pour les entreprises soumises \u00e0 la CSRD, c’est d\u00e9sormais une n\u00e9cessit\u00e9 pratique, plus une option.<\/p>\n Un troisi\u00e8me facteur prendra davantage d’importance en 2026 : l’int\u00e9gration avec le sourcing et la gestion des contrats. Pour exploiter pleinement les Reserved Instances, les Savings Plans et les Enterprise Discount Programs, il faut planifier conjointement la feuille de route des workloads, les n\u00e9gociations contractuelles et les d\u00e9cisions d’ing\u00e9nierie. Ce n’est plus une t\u00e2che r\u00e9serv\u00e9e aux \u00e9quipes FinOps, mais une discipline partag\u00e9e avec les achats et l’architecture. Les organisations qui parviennent \u00e0 aligner ces trois volets \u00e9conomisent entre 15 et 30 % sur les co\u00fbts de calcul purs, sans compromettre la qualit\u00e9 de service.<\/p>\n En 2026, la mesure de la maturit\u00e9 FinOps ira des fondamentaux \u00e0 la culture d’ing\u00e9nierie. Les organisations matures ne se contentent pas de documenter les \u00e9conomies mensuelles : elles \u00e9valuent la qualit\u00e9 de leurs processus d\u00e9cisionnels. \u00c0 quelle vitesse une \u00e9quipe r\u00e9agit-elle \u00e0 un pic de co\u00fbts ? \u00c0 quelle fr\u00e9quence les d\u00e9cisions d’architecture s’appuient-elles sur des donn\u00e9es de co\u00fbts ? Quel est le taux de r\u00e9ussite du tagging dans le workflow de d\u00e9ploiement ? Ces m\u00e9triques r\u00e9v\u00e8lent si le FinOps est v\u00e9ritablement ancr\u00e9 dans la culture d’ing\u00e9nierie ou s’il reste un simple projet de tableau de bord.<\/p>\n Un autre aspect gagne en importance : l’articulation avec la gestion de produit. Les d\u00e9cisions relatives aux fonctionnalit\u00e9s ont des cons\u00e9quences financi\u00e8res qui ne se r\u00e9v\u00e8lent qu’en cours d’exploitation. Une nouvelle fonctionnalit\u00e9 de tableau de bord avec des analyses en temps r\u00e9el sur plusieurs t\u00e9raoctets de donn\u00e9es consomme bien plus de ressources qu’un rapport statique. Les Product Owners qui collaborent avec les r\u00f4les FinOps peuvent anticiper ces compromis avant la mise en \u0153uvre. Ceux qui s\u00e9parent produit et FinOps se retrouvent, douze mois plus tard, avec des fonctionnalit\u00e9s dont personne n’avait estim\u00e9 les co\u00fbts au pr\u00e9alable.<\/p>\n Enfin, un \u00e9clairage souvent n\u00e9glig\u00e9 dans les rapports FinOps : en 2026, le FinOps ne sera plus une discipline d’optimisation r\u00e9serv\u00e9e aux \u00e9conomes, mais une comp\u00e9tence de base pour toute organisation fortement d\u00e9pendante du cloud. Les entreprises qui consid\u00e8rent le FinOps comme un projet secondaire seront distanc\u00e9es par leurs concurrents, pour qui l’ing\u00e9nierie des co\u00fbts va de soi. L’\u00e9cart ne se voit pas imm\u00e9diatement, mais apr\u00e8s dix-huit mois de croissance cloud, il se chiffre en points de pourcentage \u00e0 deux chiffres dans le calcul du TCO (co\u00fbt total de possession). Le bon moment pour renforcer la maturit\u00e9 FinOps ? Pas l’ann\u00e9e budg\u00e9taire prochaine, mais le trimestre en cours.<\/p>\n Pour des d\u00e9penses cloud mensuelles comprises entre 100 000 et 500 000 euros, une seule personne en tant que facilitateur suffit g\u00e9n\u00e9ralement, soutenue par les architectes cloud et les \u00e9quipes finance existantes. \u00c0 partir d’un million d’euros par mois, une \u00e9quipe de deux \u00e0 trois personnes devient pertinente. Pour des budgets d\u00e9passant plusieurs millions par mois, le mod\u00e8le en hub-and-spoke s’impose, avec des champions FinOps dans chaque unit\u00e9 m\u00e9tier.<\/p>\n<\/details>\n Les outils natifs des hyperscalers – AWS Cost Explorer, Azure Cost Management et GCP Billing – constituent la base. Au-dessus, des plateformes sp\u00e9cialis\u00e9es comme Flexera, CloudHealth, Apptio Cloudability ou Vantage prennent le relais. Pour les co\u00fbts Kubernetes, OpenCost s’est impos\u00e9. Le choix d\u00e9pend de la taille de l’entreprise, du mix cloud et du niveau d’int\u00e9gration souhait\u00e9 avec les outils d’ing\u00e9nierie existants.<\/p>\n<\/details>\n La cl\u00e9 r\u00e9side dans la visibilit\u00e9 au quotidien. Les donn\u00e9es de co\u00fbts, int\u00e9gr\u00e9es dans le m\u00eame tableau de bord que les indicateurs de performance et de disponibilit\u00e9, sont prises bien plus au s\u00e9rieux que des rapports mensuels isol\u00e9s. Autre levier : l’int\u00e9gration dans les OKR (*Objectives and Key Results*). Une \u00e9quipe dont les objectifs trimestriels incluent une dimension co\u00fbt adopte une approche diff\u00e9rente de celle qui consid\u00e8re les co\u00fbts comme une pr\u00e9occupation exclusive de FinOps.<\/p>\n<\/details>\n Les co\u00fbts de l’IA n\u00e9cessitent des cat\u00e9gories d\u00e9di\u00e9es. Les budgets par token et par \u00e9quipe, l’utilisation des GPU par charge de travail et les strat\u00e9gies de routage des mod\u00e8les sont les principaux leviers op\u00e9rationnels. Les approches classiques de *right-sizing* sont moins efficaces ici. Il est judicieux de cr\u00e9er une sous-pratique FinOps sp\u00e9cialis\u00e9e dans les co\u00fbts de l’IA, travaillant en \u00e9troite collaboration avec les ing\u00e9nieurs ML (*Machine Learning*).<\/p>\n<\/details>\n En pratique, comptez deux \u00e0 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 \u00ab\u00a0Walk\u00a0\u00bb et les pr\u00e9sentent comme un stade \u00ab\u00a0Run\u00a0\u00bb. \u00c0 l’inverse, ceux qui tablent sur plus de quatre ans risquent de perdre l’attention de la direction. Le parcours r\u00e9aliste consiste \u00e0 afficher des progr\u00e8s visibles chaque trimestre, avec des jalons clairs pour chaque \u00e9quipe.<\/p>\n<\/details>\n\n
Ce que signifie concr\u00e8tement le passage du suivi des co\u00fbts \u00e0 une discipline d’ing\u00e9nierie<\/h2>\n
Structures d’\u00e9quipe qui fonctionneront en 2026<\/h2>\n
\n
\n
Les phases Crawl-Walk-Run mises en pratique concr\u00e8tement<\/h2>\n
Les enjeux de co\u00fbts qui s’invitent \u00e0 l’agenda en 2026<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Combien de personnes faut-il pour constituer une \u00e9quipe FinOps dans une ETI ?<\/strong><\/summary>\n
Quels outils feront r\u00e9f\u00e9rence dans la stack FinOps en 2026 ?<\/strong><\/summary>\n
Comment convaincre les \u00e9quipes d’ing\u00e9nierie d’accorder de l’importance aux KPI de co\u00fbts ?<\/strong><\/summary>\n
Comment g\u00e9rer les co\u00fbts li\u00e9s \u00e0 l’IA dans la pratique FinOps ?<\/strong><\/summary>\n
Combien de temps faut-il r\u00e9ellement pour passer du stade \u00ab\u00a0Crawl\u00a0\u00bb \u00e0 \u00ab\u00a0Run\u00a0\u00bb ?<\/strong><\/summary>\n
Plus d’articles du r\u00e9seau m\u00e9dia MBF<\/h2>\n