Une facture cloud dit ce qui a été consommé : comptes, régions, familles de ressources. Elle ne dit jamais pour quel service, ni pour quelle valeur métier. C’est cet écart, plus que le montant de la facture, qui bloque la plupart des démarches FinOps après quelques mois : la finance obtient un total, la DSI obtient un détail technique, et personne ne peut répondre à la question la plus simple : ce service coûte-t-il ce qu’il devrait coûter ?
Le FinOps rend les coûts cloud visibles et pilotables. L’ITSM structure les services informatiques, leurs responsables et leurs processus. Combinés, ils permettent de passer d’une lecture comptable du cloud, une addition de ressources, à une lecture orientée service, où chaque euro dépensé se rattache à un propriétaire, un niveau de criticité et un usage identifiable. Le cadre FinOps fournit un référentiel utile pour organiser cette démarche.
Une ressource cloud peut être parfaitement optimisée et pourtant coûter trop cher
Un environnement de test créé pour un projet ponctuel, prolongé de trimestre en trimestre parce que personne n’a de mandat pour le fermer. Une politique de sauvegarde dupliquée sur trois environnements après une migration, jamais nettoyée. Une ressource dimensionnée pour un pic de charge qui ne s’est jamais reproduit. Aucune de ces dépenses n’apparaît comme une anomalie dans un tableau de bord cloud classique : chacune est une ligne parfaitement légitime, avec un tag correct et une justification d’origine. Ce qui a disparu, c’est le lien entre la ressource et le service qui la justifiait encore.
C’est là que le tagging cloud atteint sa limite. Le tagging décrit ce qu’est une ressource : à quel projet elle appartient, quel centre de coûts la porte, quelle équipe l’a créée. Il ne dit jamais si le service auquel elle était rattachée existe toujours. Le tagging répond à « à qui appartient cette ressource ? ». L’ITSM doit permettre de répondre à « ce service existe-t-il encore, qui en est responsable et quel niveau de coût est justifié ? ». Tant que seule la première question trouve une réponse, une ressource parfaitement optimisée sur le papier peut coûter cher pour un service qui n’a plus de raison d’exister.
Le véritable objet de pilotage n’est pas la ressource : c’est le service
Un cluster, une base de données, un bucket de stockage : chacun de ces éléments n’a de sens économique que rattaché à un service consommé par des utilisateurs ou par un autre service. La question posée par le FinOps seul est « combien coûte cette ressource ? ». La question que l’ITSM permet de poser est différente : « quel service consomme cette ressource, quelle est sa criticité, et qui répond de sa valeur ? ».
Cette bascule suppose de faire correspondre plusieurs niveaux d’information qui, dans la plupart des entreprises, vivent dans des outils séparés : les tags cloud, les centres de coûts, la CMDB applicative, les contrats de service et les propriétaires métier. Tant que ces niveaux ne sont pas explicitement reliés, chaque partie continue de raisonner avec sa propre vérité, la finance avec un centre de coûts, la DSI avec une architecture technique, sans jamais confronter les deux.
Ce que l’ITSM change concrètement dans une démarche FinOps
Le changement ne se joue pas dans un outil supplémentaire, mais dans les processus déjà suivis. Une demande de changement peut inclure une estimation d’impact financier avant validation, au même titre qu’une estimation d’impact technique. Un incident sur un service partagé peut documenter non seulement la durée d’indisponibilité, mais le surcoût généré par la remédiation elle-même : montée en capacité d’urgence maintenue par prudence, ressources de secours jamais redescendues. Une revue de service périodique peut intégrer l’évolution des dépenses cloud du service concerné, pas seulement sa disponibilité. Le cycle de vie d’un service, de sa création à son retrait, peut inclure un point de contrôle sur son coût réel face à sa valeur mesurée.
Les entreprises qui s’appuient sur des consultants certifiés ITIL v4 disposent généralement d’un cadre déjà rodé pour opérer ce rapprochement, parce que la structuration des services et de leurs responsables fait partie du métier plutôt que d’un chantier ponctuel.
Trier les services avant de vouloir tout cartographier
Cartographier l’intégralité des services dès le premier mois est généralement contre-productif. Mieux vaut appliquer une logique de Pareto : cartographier en priorité les 20 % de services qui concentrent la majorité de la dépense cloud, avant d’étendre progressivement la couverture. Ce tri initial peut s’appuyer sur un export de facturation par tag ou par centre de coûts, croisé avec la liste des services actifs dans la CMDB : les écarts entre les deux, ressources taguées sans service actif identifié, services actifs sans rattachement clair à un centre de coûts, indiquent précisément par où commencer.
Pour chaque service prioritaire, cinq dimensions suffisent à rendre la donnée exploitable : le service concerné, l’environnement technique, le propriétaire nommé, le niveau de criticité et le type d’usage. Ce choix n’est pas arbitraire : au-delà, la collecte devient plus lourde que ce qu’elle rapporte en capacité de décision ; en dessous, il manque l’un des éléments nécessaires pour arbitrer. Un propriétaire peut être assigné dès cette première passe, même avec une donnée encore imparfaite : il est plus simple d’affiner une information rattachée à quelqu’un que d’en retrouver une qui n’appartient à personne six mois plus tard.
Sur ce point, notre accompagnement ITSM vise justement à structurer ce tri initial pour qu’il tienne dans la durée, plutôt que de redevenir un chantier ponctuel à chaque revue budgétaire.
Les indicateurs FinOps qui servent réellement à arbitrer
Le coût cloud total reste nécessaire pour le pilotage budgétaire global, mais il ne déclenche aucune décision opérationnelle à lui seul. Cinq indicateurs suffisent déjà à déclencher des arbitrages utiles : le coût par service et son évolution mensuelle, la part de ressources non rattachées à un propriétaire, le taux d’utilisation réel des ressources provisionnées, et l’écart entre le budget prévu et la dépense constatée par service. Un indicateur qui ne conduit à aucune action, ni un arbitrage, ni une relance, ni une remise en question, n’a pas sa place dans le suivi mensuel, même s’il est facile à produire.
Ne pas confondre un nettoyage ponctuel avec une transformation durable
Supprimer des ressources oubliées produit un gain immédiat et non répété : la facture baisse un mois, puis les mêmes dérives réapparaissent progressivement. La transformation durable vient de règles qui tiennent sans intervention manuelle : tagging obligatoire dès la création d’une ressource, propriétaire assigné avant mise en production, revue de coût intégrée au cycle de vie du service plutôt qu’ajoutée après coup. Le FinOps ne doit pas devenir un nouveau rituel de gouvernance. Sa donnée doit entrer dans les rituels qui existent déjà : comité de changement, revue de service, clôture d’incident.
Ce qui change quand une entreprise franchit ce cap
Le FinOps rend la dépense visible. L’ITSM lui donne un cadre de décision. Relier les deux ne demande pas un outil supplémentaire, mais un tri priorisé sur les services les plus coûteux, des indicateurs qui déclenchent réellement une action, et l’intégration du coût dans les processus de changement et d’incident déjà en place. Une ressource n’est plus jugée seule : elle est rattachée à un service, ce service a un propriétaire, et ce propriétaire dispose enfin d’une donnée pour décider. Ressource, service, propriétaire, décision : cette chaîne de responsabilité, plus que la sophistication de l’outillage, distingue une entreprise qui pilote son cloud d’une entreprise qui se contente de le subir.
