Comment GitLab unifie ses coûts cloud grâce à FOCUS

Agence cloud FinOps Comment GitLab unifie ses coûts cloud grâce à FOCUS Le FinOps repose sur une promesse simple : permettre aux organisations de prendre de meilleures décisions grâce à une meilleure compréhension de leurs coûts technologiques. Dans la pratique, cette promesse est souvent plus difficile à tenir qu’il n’y paraît. Les entreprises ne consomment plus uniquement des ressources AWS, Azure ou Google Cloud. Elles utilisent simultanément des plateformes de données, des outils d’observabilité, des services SaaS, des solutions d’intelligence artificielle, des infrastructures hybrides et parfois même des clouds privés. Chacun de ces fournisseurs produit ses propres données de facturation, avec ses propres conventions, ses propres métriques et son propre vocabulaire. Résultat : une part importante du travail FinOps consiste encore à collecter, normaliser et réconcilier des données avant même de pouvoir commencer à les analyser. Lors du FinOps X, GitLab a partagé son retour d’expérience sur la manière dont l’entreprise a construit une plateforme FinOps capable d’unifier ses données de coûts à travers plusieurs fournisseurs cloud et plusieurs environnements. Au cœur de cette démarche se trouve FOCUS (FinOps Open Cost and Usage Specification), le standard ouvert développé par la FinOps Foundation pour normaliser les données de coûts et d’usage cloud. Mais contrairement à ce que l’on pourrait croire, l’histoire racontée par GitLab ne concerne pas réellement un standard de données. Elle concerne la construction d’une source unique de vérité financière capable de relier les coûts techniques aux usages métier. Pourquoi GitLab avait besoin d’une source unique de vérité Un environnement multi-cloud difficile à piloter GitLab opère dans un environnement particulièrement complexe. L’entreprise s’appuie sur plusieurs fournisseurs cloud et plateformes technologiques : Google Cloud, AWS, Oracle Cloud, Cloudflare, Elastic, Grafana ou encore Anthropic pour certaines fonctionnalités liées à l’intelligence artificielle. Cette diversité est volontaire. GitLab revendique depuis longtemps une approche cloud agnostique et souhaite conserver la capacité de déployer ses services sur différents environnements sans dépendre d’un fournisseur unique. Cette stratégie présente de nombreux avantages. Elle réduit les risques de dépendance vis-à-vis d’un fournisseur, améliore la résilience globale de la plateforme et permet à l’entreprise de conserver une certaine flexibilité dans ses choix technologiques. Elle constitue également un levier de négociation important vis-à-vis des différents fournisseurs. Cependant, cette liberté a un coût. Chaque plateforme produit ses propres données de facturation, ses propres métriques d’usage et ses propres mécanismes de tarification. Plus le nombre de fournisseurs augmente, plus la compréhension globale des coûts devient complexe. Les équipes FinOps ne doivent plus seulement analyser des dépenses : elles doivent également réconcilier des modèles de données hétérogènes avant même de pouvoir commencer leurs analyses. Une maturité FinOps encore limitée Avant le lancement de son initiative FinOps, GitLab estimait que sa couverture d’allocation des coûts atteignait environ 30 %. Les analyses étaient souvent réalisées à la demande, dans le cadre d’études ponctuelles. Les équipes disposaient de peu de visibilité consolidée et les exercices de prévision ou de calcul des unit economics restaient largement manuels. Cette situation ne résultait pas d’un manque de données. Au contraire, les informations existaient déjà au sein de l’organisation. Le véritable problème provenait de leur dispersion. Chaque fournisseur exposait ses coûts selon ses propres conventions. Les données de consommation étaient réparties entre plusieurs outils. Les métriques techniques, les informations financières et les données produit vivaient dans des systèmes distincts. Dans ces conditions, répondre à une question simple comme « combien coûte réellement cette fonctionnalité ? » nécessitait souvent plusieurs jours d’analyse et de nombreuses transformations intermédiaires. Une part importante du travail FinOps était alors consacrée à préparer la donnée plutôt qu’à produire des analyses à valeur ajoutée. Construire une fondation pour les décisions économiques La situation rencontrée par GitLab est loin d’être exceptionnelle. À mesure que les organisations adoptent plusieurs clouds, multiplient les services SaaS et développent leurs usages de l’intelligence artificielle, elles se retrouvent confrontées aux mêmes difficultés. Le défi n’est plus de collecter davantage de données. Les informations existent déjà. L’enjeu consiste désormais à construire une vision économique cohérente capable de relier les coûts techniques aux usages métier. Pour GitLab, l’objectif n’était donc pas simplement d’améliorer le reporting ou de produire de nouveaux tableaux de bord. L’ambition était de bâtir une fondation de données permettant aux équipes engineering, produit et finance de travailler à partir d’une même lecture économique de la plateforme. Cette fondation devait également rendre possible la production d’indicateurs plus avancés, comme les unit economics, les prévisions de dépenses ou les analyses de rentabilité des fonctionnalités. C’est précisément dans cette logique qu’intervient FOCUS. Bien plus qu’un simple standard de données, il devient le socle sur lequel GitLab va construire sa vision économique unifiée. FOCUS : un langage commun pour les données de coûts Le problème que FOCUS cherche à résoudre Lorsque l’on découvre FOCUS pour la première fois, il peut être tentant de le considérer comme un simple format d’échange de données supplémentaire. Pourtant, son origine est directement liée à l’un des problèmes les plus récurrents rencontrés par les équipes FinOps : la fragmentation des données de coûts. À mesure que les organisations diversifient leurs fournisseurs technologiques, elles doivent composer avec une multiplication des formats de facturation, des modèles de consommation et des conventions de nommage. AWS, Google Cloud, Azure, Snowflake, Databricks ou encore les plateformes SaaS produisent chacun leurs propres exports de coûts, construits selon des logiques différentes. Cette hétérogénéité crée une difficulté structurelle. Avant même de pouvoir analyser une dépense, construire une prévision ou identifier une opportunité d’optimisation, les équipes doivent d’abord rendre les données comparables. Dans les environnements les plus complexes, cette phase de préparation représente parfois davantage d’effort que l’analyse elle-même. C’est précisément pour répondre à cette problématique que la FinOps Foundation a développé FOCUS (FinOps Open Cost and Usage Specification), un standard ouvert destiné à normaliser la représentation des données de coûts et d’usage à travers les différents fournisseurs technologiques. Standardiser la donnée pour accélérer l’analyse L’objectif de FOCUS n’est pas de remplacer les outils FinOps existants ni de produire directement des analyses. Son ambition est plus fondamentale : fournir

REX FinOps X Day Londres : le FinOps change de nature​

Agence cloud FinOps REX FinOps X Day Londres : le FinOps change de nature La conférence inaugurale du FinOps X Day Londres 2026 a donné le ton dès les premières minutes : le FinOps n’est plus seulement une discipline de maîtrise des coûts cloud. Il devient progressivement une capacité d’aide à la décision qui s’étend à l’IA, au SaaS, aux plateformes de données, au datacenter et, plus largement, à la valeur économique de la technologie. Ce déplacement du centre de gravité est majeur. Pendant plusieurs années, le FinOps a surtout été perçu comme un ensemble de pratiques dédiées à la visibilité, à l’optimisation et à la responsabilisation autour du cloud public. Désormais, le sujet dépasse largement la réduction de facture. Il s’invite dans la stratégie technologique, les arbitrages d’investissement, la gouvernance produit, les choix d’architecture et les discussions au niveau des dirigeants. Ce qui ressort de cette matinée londonienne n’est donc pas simplement une accumulation de tendances. C’est une reconfiguration de la place du FinOps dans l’entreprise. L’enjeu n’est plus seulement de mieux voir les coûts. Il est de mieux gouverner la valeur. Le FinOps change de périmètre Du Cloud aux autres catégories de dépenses technologiques L’un des messages les plus forts de l’événement est la confirmation d’un mouvement déjà visible depuis plusieurs mois : le FinOps ne s’arrête plus au cloud. L’IA, le SaaS, les licences logicielles, les plateformes de données et même certaines briques de datacenter entrent désormais dans le périmètre de nombreuses équipes. Cette évolution n’est pas marginale. Elle traduit un changement profond de la manière dont les entreprises consomment la technologie. Le cloud a ouvert la voie à des modèles de coûts variables, granulaires et dynamiques. L’IA et le SaaS prolongent ce mouvement, souvent en l’intensifiant. Là où les dépenses logicielles étaient autrefois relativement prévisibles et forfaitaires, elles deviennent de plus en plus dépendantes des usages, des volumes, des appels, des capacités réservées ou des modèles consommés. Dans ce contexte, les anciennes frontières entre cloud, logiciel, data et infrastructure se brouillent. La conséquence est simple : piloter chaque silo séparément réduit la capacité à comprendre la réalité économique globale. Le FinOps est appelé à jouer un rôle de liant entre ces catégories. Le rôle croissant de l’IA et du SaaS L’IA occupe désormais une place centrale dans les priorités des praticiens. Ce n’est plus un sujet périphérique ou expérimental. Il devient un poste de dépense, un levier d’innovation et un nouveau terrain de gouvernance. Ce qui frappe, c’est la rapidité avec laquelle la question est montée dans les préoccupations des organisations. Gérer les coûts de l’IA n’est plus réservé à quelques pionniers. C’est déjà un sujet très largement répandu. Le SaaS suit une trajectoire similaire, même si sa complexité est d’une autre nature. Là où le cloud public a habitué les équipes à des modèles relativement normalisés, le SaaS additionne encore trop souvent des logiques d’abonnement, de licences, d’options, de consommation variable et de surcoûts mal visibles. Dans beaucoup d’entreprises, ces dépenses restent fragmentées, parfois mal attribuées, et encore plus difficiles à rapprocher d’indicateurs de valeur. Ce que révèle la conférence londonienne, c’est donc un basculement : le FinOps ne traite plus uniquement une facture cloud. Il devient une méthode de lecture économique de la technologie dans son ensemble. De l’optimisation à la valeur Pourquoi l’optimisation devient une commodité Un autre enseignement important de la matinée est que l’optimisation, bien qu’encore indispensable, tend à devenir un prérequis plutôt qu’un facteur différenciant. Les pratiques de rightsizing, de gestion des engagements, d’arrêt des environnements non utilisés ou d’automatisation de certaines corrections sont désormais largement connues. Elles restent nécessaires, mais elles ne suffisent plus à distinguer une pratique FinOps mature. Autrement dit, réduire les coûts n’est plus le sommet de la montagne. C’est la base. La discussion se déplace donc vers un niveau supérieur : comment s’assurer que chaque euro, chaque dollar ou chaque unité de consommation technologique produit une valeur cohérente avec la stratégie de l’entreprise ? Cette question est plus difficile, car elle oblige à relier les coûts à des décisions métier, à des produits, à des usages et à des arbitrages. Elle implique aussi de sortir d’une logique purement réactive. L’importance des unités économiques L’exemple présenté par Barclays est particulièrement éclairant sur ce point. L’intervention a montré que les responsables technologiques et métiers ne peuvent pas arbitrer sérieusement à partir de simples rapports de coûts. Pour choisir entre plusieurs fournisseurs, services ou canaux, il faut traduire la dépense en unités compréhensibles et comparables. C’est ce qu’illustre le passage d’un suivi de coûts bruts à une lecture du coût par message ou du coût par interaction. Ce changement paraît simple, mais il transforme complètement le niveau de discussion. On ne parle plus seulement d’une dépense globale, mais d’un choix de modèle économique. On ne se demande plus seulement si la facture augmente. On se demande quel canal, quel produit ou quel fournisseur crée le meilleur rapport entre coût et valeur. C’est précisément ici que le FinOps devient stratégique. Il cesse d’être un dispositif de contrôle pour devenir un instrument d’arbitrage. Le FinOps se déplace dans l’organisation Une discipline désormais portée plus haut Un élément particulièrement intéressant de la keynote est la description du positionnement organisationnel du FinOps. Dans de nombreuses entreprises, la pratique remonte désormais sous des leaders technologiques de niveau CTO, CIO ou responsables transverses de portefeuilles technologiques. Cela peut sembler anecdotique, mais c’est en réalité un signal fort. Lorsque le FinOps n’est perçu que comme un sujet d’optimisation opérationnelle, il reste souvent cantonné à des équipes spécialisées qui produisent des rapports ou poursuivent les ingénieurs avec des recommandations. Lorsqu’il est porté à un niveau plus élevé, il peut influencer les priorités, les investissements, les arbitrages inter-technologies et la cohérence d’ensemble. Le message est clair : la maîtrise de la valeur technologique ne peut plus être dissociée de la gouvernance technologique. Le rôle du central enablement Autre point récurrent dans plusieurs interventions : les équipes FinOps centrales ne sont pas censées tout faire elles-mêmes. Leur