FinOps en 2025 - Comprendre les scopes FinOps, vers une cartographie fonctionnelle des coûts IT

Les directions informatiques modernes ne pilotent plus un système d'information centralisé. Elles orchestrent un maillage de services qui fonctionnent selon des modèles techniques et économiques radicalement différents.

FinOps en 2025 - Comprendre les scopes FinOps, vers une cartographie fonctionnelle des coûts IT

<FinOps en 2025 - Le passage à l'ère du Cloud+

Les directions informatiques modernes ne pilotent plus un système d'information centralisé. Elles orchestrent un maillage de services — clouds publics, plateformes SaaS, infrastructures on-premise, clouds privés, clusters Kubernetes, outils d’IA — qui fonctionnent selon des modèles techniques et économiques radicalement différents. Dans ce paysage fragmenté, la discipline FinOps est attendue pour apporter clarté, responsabilité et alignement stratégique. Mais pour cela, elle doit se réinventer.

La réponse que propose aujourd’hui la FinOps Foundation s’appelle le modèle par scopes. Derrière ce mot, une idée structurante : découper le SI non pas en briques technologiques, mais en périmètres homogènes de pilotage économique. Chaque scope devient un cadre d’analyse, de décision et de gouvernance, avec ses propres règles, ses propres indicateurs, et ses propres responsabilités.

Dasn cet article, je vous en propose une lecture approfondie, en la traduisant en principes opérationnels, cas d’usage concrets et recommandations.


Pourquoi découper ? Une réalité de terrain

La discipline FinOps s’est d’abord développée autour du cloud public, terrain d’expérimentation privilégié pour ses données accessibles et sa tarification granulaire. Cette expérience, bien que fondatrice, ne permet plus de couvrir les réalités actuelles des systèmes d'information. L’entreprise numérique en 2025 ne fonctionne pas dans un seul cloud, ni même dans le cloud uniquement. Elle compose avec :

  • Des workloads conteneurisés sur des infrastructures mutualisées ;
  • Des applications SaaS aux logiques de licence multiples ;
  • Des serveurs on-prem encore critiques pour certaines chaînes de valeur ;
  • Des services d’IA dont les coûts sont aussi imprévisibles que les usages.

Chaque environnement a ses propres temporalités, ses propres modalités contractuelles, ses propres métriques. Le FinOps, pour rester pertinent, doit reconnaître cette diversité. D’où la nécessité d’un découpage.


Le modèle des scopes : une segmentation fonctionnelle

La FinOps Foundation distingue aujourd’hui plusieurs scopes majeurs. Ce sont des périmètres de consommation homogènes, qui appellent des pratiques spécifiques.

Scope 1 : Cloud Public

Le plus établi. Il s’agit ici de la consommation des hyperscalers (AWS, Azure, GCP, etc.). Les équipes ont accès à des outils de visualisation, de prévision, d’allocation native. Mais plusieurs défis persistent :

  • Gouvernance multi-comptes complexe ;
  • Difficulté d'appropriation et d'optimisation des recommandations (RIs, Savings Plans) ;
  • Difficulté d’alignement entre les coûts et les métiers.

Une pratique FinOps mature consiste ici à industrialiser les mécanismes d’optimisation, et à renforcer la traçabilité via des politiques de tagging rigoureuses, liées à des référentiels internes (produits, équipes, clients).

Scope 2 : SaaS

Longtemps ignoré des pratiques FinOps, le SaaS représente pourtant une part croissante des dépenses IT. Le problème n’est pas tant le volume que la dispersion :

  • Des achats réalisés hors DSI (shadow IT) ;
  • Des licences non utilisées ou sous-utilisées ;
  • Des modèles tarifaires complexes (par palier, user-based, volume-based).

L’approche FinOps dans ce périmètre passe par la reconstruction d’un inventaire, le rapprochement usage/contrat, et l’optimisation des engagements. Elle impose aussi une collaboration étroite avec l’ITAM et les achats.

Scope 3 : Data Center / On-Premise

Ce périmètre reste central dans de nombreuses entreprises, notamment dans les secteurs réglementés ou industriels. Mais les coûts sont rarement suivis en temps réel, ni reliés aux usages.

Il s’agit ici de transposer les principes FinOps à des environnements amortis :

  • Identifier les composants de coût (matériel, énergie, support) ;
  • Répartir ces coûts sur les workloads hébergés (via des clés d’allocation) ;
  • Comparer les coûts internes avec ceux du cloud public (TCO).

Certaines entreprises construisent pour cela des extensions maison du modèle FOCUS, afin d’unifier la lecture budgétaire dans les tableaux de bord FinOps.

Scope 4 : Cloud Privé / Conteneurs

Les environnements Kubernetes ou OpenStack posent un défi d’imputation. Ce sont des environnements dynamiques, mutualisés, multitenants. On ne peut pas y assigner directement un coût par ressource. L’allocation se fait en cascade :

  • Coût de l’infrastructure hôte ;
  • Répartition par cluster, puis par namespace, pod, container ;
  • Attribution au service ou à l’équipe concernée.

Des outils comme OpenCost ou Kubecost sont indispensables. Mais l’allocation doit aussi être validée par les équipes métier, qui comprennent les logiques d’usage.

Scope 5 : Intelligence Artificielle

Les services IA sont encore difficiles à cadrer. Entre les modèles open source hébergés en interne, les API payantes des hyperscalers (Vertex AI, Bedrock, Azure OpenAI), et les solutions SaaS spécialisées, il n’y a pas de norme. Les coûts sont liés :

  • au volume (nombre d’appels, tokens, images générées),
  • à la puissance (type de GPU utilisé),
  • au mode d’entraînement ou d’inférence.

Construire un scope IA revient à poser les bases d’un pilotage différencié : coût par usage, suivi des dérives, quotas, refacturation aux métiers, gestion du cache.


Gouvernance distribuée : un modèle par périmètre

L’intérêt du découpage en scopes n’est pas seulement analytique. Il permet d’organiser une gouvernance distribuée et cohérente :

  • Chaque scope est attribué à une équipe responsable (FinOps cloud, ITAM pour le SaaS, "Infra" pour le on-prem…)
  • Les KPIs sont adaptés au périmètre (coût par utilisateur, par transaction, par produit…)
  • Les processus de revue, d’optimisation et d’arbitrage sont spécifiques à chaque domaine

Cela permet une montée en maturité progressive, périmètre par périmètre, sans attendre un modèle unique et parfait.


Recommandations stratégiques

  1. Commencer par une cartographie complète de vos périmètres de dépense IT.
    Classez-les par modèle économique, source de facturation, niveau d’usage.
  2. Associer des responsables à chaque scope.
    Pas uniquement des responsables techniques : inclure finance, achats, produit.
  3. Construire des tableaux de bord par scope.
    Même si le modèle de données est encore hétérogène, il est crucial d’avoir une visibilité propre par périmètre.
  4. Déployer les outils adaptés à chaque contexte.
    Outils pour les containers, outils de gestion contractuelle pour le SaaS, pour l’on-prem…
  5. Identifier les zones de friction et de recouvrement.
    Une application peut toucher plusieurs scopes. Il faut alors définir une hiérarchie des imputations.

En synthèse

Le découpage par scopes est plus qu’une nouvelle terminologie : c’est un cadre de pilotage pour les SI complexes. Il permet aux entreprises de ne pas subir l’hétérogénéité de leurs environnements, mais de l’organiser. C’est aussi une réponse à un défi fondamental du FinOps : faire émerger une lecture économique à partir d’une diversité technologique.

Il ne s’agit pas de réduire la complexité. Il s’agit de lui donner une forme gouvernable, alignée sur les responsabilités internes, et capable d’éclairer les décisions.

Un FinOps par scope, c’est un FinOps à la fois plus granulaire et plus stratégique.

Cet article fait partie de la série "FinOps en 2025, FinOps à l'ère Cloud+"

Génial ! Vous vous êtes inscrit avec succès.

Bienvenue de retour ! Vous vous êtes connecté avec succès.

Vous êtes abonné avec succès à WENVISION.

Succès ! Vérifiez votre e-mail pour obtenir le lien magique de connexion.

Succès ! Vos informations de facturation ont été mises à jour.

Votre facturation n'a pas été mise à jour.