8 min 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, cela signifie que 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.

En relationCoûts d’inférence d’IA : FinOps pour les charges de travail 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

La première vague FinOps était axée sur 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 se traduit pas automatiquement en actions. Une équipe d’ingénierie qui constate un pic de coûts dans son cluster Kubernetes un lundi doit tout de même savoir quoi modifier, qui doit donner son accord 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 (qui devrait s’imposer dans le courant en 2026) intègre directement FinOps aux workflows d’ingénierie. Concrètement, cela signifie que les tags de coûts deviennent une composante obligatoire lors du déploiement, que les nouveaux services font l’objet d’un commentaire sur les coûts lors de la revue de pull request (PR), et que les décisions d’architecture sont présentées avec un calcul du coût total de possession (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 généralement trois à quatre trimestres dans de nombreuses organisations.

Un autre aspect qui devient bien plus visible dans cette deuxième vague FinOps est l’intégration avec les équipes de platform engineering (ingénierie de plateforme). Lorsqu’une organisation met en place une plateforme interne pour les développeurs, FinOps n’est plus un simple module complémentaire, mais une composante à part entière de la discipline de plateforme. Les templates de golden path intègrent dès leur conception 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’ancrer FinOps dans le quotidien – mais aussi la plus exigeante, car elle suppose une organisation de platform engineering déjà opérationnelle.

Structures d’équipe qui fonctionneront en 2026

La FinOps Foundation distingue trois modèles principaux pour organiser cette discipline. Avec 60 % des pratiques, l’Enablement centralisé reste la norme. Une petite équipe centrale définit les standards, les outils et les formations, tandis que l’action opérationnelle relève des équipes produit. Le modèle Hub-and-Spoke, adopté par 21 % des organisations, est courant dans les grandes entreprises : un groupe FinOps centralisé, complété par des champions dédiés au sein de chaque unité métier. Les modèles entièrement décentralisés sont rares et ne fonctionnent, en pratique, que dans des organisations d’ingénierie très 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 dont les dépenses cloud mensuelles s’élèvent à 500 000 euros n’a pas besoin d’un dispositif Hub-and-Spoke avec dix champions. À l’inverse, une entreprise dépensant dix millions d’euros par mois ne peut pas évoluer avec une équipe centrale sans modèle de fédération. L’erreur la plus fréquente consiste à déployer trop tôt un modèle trop ambitieux, car les fournisseurs de solutions FinOps aiment vendre la complexité « entreprise ». En règle générale, une entreprise du mid-market commence avec une personne ou une équipe de deux personnes en tant qu’Enablement, puis évolue lorsque les dépenses cloud le justifient.

Un aspect souvent sous-estimé dans la structure d’équipe est le rôle du partenaire financier. Une équipe FinOps sans lien direct avec le contrôle de gestion perd son influence sur la discipline budgétaire. À l’inverse, un contrôle de gestion sans contact technique avec le FinOps se transforme rapidement en gestionnaire de budgets théoriques, incapable de comprendre les structures de coûts réelles du cloud. Les configurations gagnantes en 2026 intègrent une personne dédiée aux finances, qui collabore étroitement avec l’équipe FinOps, produit des rapports mensuels conjoints et partage la responsabilité des chiffres dans le reporting de gestion.

Un autre point structurel crucial est la distinction claire entre FinOps et les achats. Le FinOps ne décide pas seul des engagements, des instances réservées ou des contrats pluriannuels. Ces décisions nécessitent l’intervention des achats, de la direction financière et souvent du comité de direction. Le FinOps fournit les données et les scénarios de calcul, mais c’est ailleurs que le contrat est signé. Les organisations qui mélangent ces rôles se retrouvent soit avec des équipes FinOps dotées d’un pouvoir contractuel excessif, soit avec des services achats manquant de contexte technique. Dans les deux cas, cela génère des problèmes. Une répartition claire des rôles permet d’éviter de nombreuses réunions et accélère sensiblement les décisions, car les voies d’escalade sont définies à l’avance. La collaboration devient une routine opérationnelle.

L’articulation avec les OKR des équipes d’ingénierie est un point qui réussit bien plus souvent en 2026 qu’en 2024. Qui voit le FinOps comme un frein aux coûts rencontre des résistances. Qui le considère comme une métrique d’efficacité, au même titre que la performance, la disponibilité et la rapidité, obtient des équipes qui s’auto-évaluent sur la base de ces indicateurs. La différence de langage est minime, mais l’impact sur l’acceptation est majeur.

Les phases Crawl-Walk-Run mises en pratique concrètement

La FinOps Foundation n’a pas remplacé son modèle Crawl-Walk-Run d’ici 2026, mais l’a affiné. Les trois phases restent inchangées, mais chacune s’est vue attribuer des responsabilités d’ingénierie plus précises. La phase Crawl correspond à la prise de conscience : l’équipe comprend d’où proviennent 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. La phase Walk marque l’appropriation : 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 la phase Crawl. Enfin, la phase Run incarne l’optimisation : les décisions basées sur les données font partie du quotidien, et des politiques automatisées entrent en jeu. Les décisions relatives aux coûts s’inscrivent dans le cadre du travail d’ingénierie habituel.

Dans la pratique, toutes les équipes ne progressent pas au même rythme à travers ces phases. Une équipe DevOps très sensible aux coûts peut atteindre la phase Run en neuf mois. Une équipe produit axée sur la livraison de fonctionnalités peut parfois mettre deux ans à stabiliser la phase Walk. Les niveaux de maturité sont attribués par équipe, et non par organisation. La fonction FinOps centrale mesure et rapporte les progrès, mais la décision concernant la vitesse de progression revient au responsable d’ingénierie concerné.

Une question fréquemment posée concerne le moment où les organisations atteignent la phase Run. Les données du rapport *State of FinOps* montrent qu’en 2026, environ un tiers des pratiques se situent dans cette phase, avec une tendance à la hausse. La majorité des organisations continuent de travailler dans la phase Walk, avec des objectifs d’optimisation clairs, mais sans intégration complète dans les processus d’ingénierie. Le passage de Walk à Run marque le moment où FinOps cesse d’être un programme distinct pour devenir une composante naturelle de la discipline des plateformes.

Les enjeux de coûts qui s’invitent à l’agenda en 2026

Deux thèmes vont transformer la pratique FinOps en 2026, au-delà des catégories classiques de coûts cloud. Le premier : la gestion des coûts liés à l’IA. Les instances GPU, la facturation à la token pour les API de grands modèles de langage (LLM) et les coûts de stockage et de réseau associés aux pipelines d’entraînement et d’inférence massifs constituent une nouvelle classe de dépenses. La transparence y est moindre qu’avec les ressources cloud traditionnelles, et la volatilité des prix, plus élevée. Les leviers d’optimisation diffèrent également. Qui se contente d’intégrer les workloads IA dans un processus FinOps existant sous-estime leurs spécificités.

Le second thème est le FinOps durable. L’articulation entre optimisation des coûts et réduction des émissions de CO₂ ne relève plus du simple argument marketing : elle devient un critère mesurable dans les rapports CSRD (Corporate Sustainability Reporting Directive, directive européenne sur la publication d’informations en matière de durabilité) et les appels d’offres européens. Les fournisseurs cloud fournissent désormais des données d’empreinte carbone au niveau des ressources. Les tableaux de bord FinOps affichent en parallèle coûts et émissions. Pour les entreprises soumises à la CSRD, c’est désormais une nécessité pratique, plus une option.

Un troisième facteur prendra davantage d’importance en 2026 : l’intégration 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égociations contractuelles et les décisions d’ingénierie. Ce n’est plus une tâche réservée aux équipes FinOps, mais une discipline partagée avec les achats et l’architecture. Les organisations qui parviennent à aligner ces trois volets économisent entre 15 et 30 % sur les coûts de calcul purs, sans compromettre la qualité de service.

En 2026, la mesure de la maturité FinOps ira des fondamentaux à la culture d’ingénierie. Les organisations matures ne se contentent pas de documenter les économies mensuelles : elles évaluent la qualité de leurs processus décisionnels. À 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 réussite du tagging dans le workflow de déploiement ? Ces métriques révèlent si le FinOps est véritablement ancré dans la culture d’ingénierie ou s’il reste un simple projet de tableau de bord.

Un autre aspect gagne en importance : l’articulation avec la gestion de produit. Les décisions relatives aux fonctionnalités ont des conséquences financières qui ne se révèlent qu’en cours d’exploitation. Une nouvelle fonctionnalité de tableau de bord avec des analyses en temps réel sur plusieurs téraoctets de données consomme bien plus de ressources qu’un rapport statique. Les Product Owners qui collaborent avec les rôles FinOps peuvent anticiper ces compromis avant la mise en œuvre. Ceux qui séparent produit et FinOps se retrouvent, douze mois plus tard, avec des fonctionnalités dont personne n’avait estimé les coûts au préalable.

Enfin, un éclairage souvent négligé dans les rapports FinOps : en 2026, le FinOps ne sera plus une discipline d’optimisation réservée aux économes, mais une compétence de base pour toute organisation fortement dépendante du cloud. Les entreprises qui considèrent le FinOps comme un projet secondaire seront distancées par leurs concurrents, pour qui l’ingénierie des coûts va de soi. L’écart ne se voit pas immédiatement, mais après dix-huit mois de croissance cloud, il se chiffre en points de pourcentage à deux chiffres dans le calcul du TCO (coût total de possession). Le bon moment pour renforcer la maturité FinOps ? Pas l’année budgétaire prochaine, mais le trimestre en cours.

Questions fréquentes

Plus d’articles du réseau média MBF

Source de l’image d’en-tête : Pexels / Hanna Pad (px:6801639)