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 un langage commun permettant de décrire les coûts et les usages indépendamment de leur origine.
Concrètement, cela signifie qu’une organisation n’a plus besoin de traiter séparément les spécificités de chaque fournisseur. Une fois les données converties au format FOCUS, elles reposent sur une structure cohérente, avec des concepts normalisés et des champs définis de manière uniforme.
Cette approche simplifie considérablement le travail des équipes FinOps. Les modèles de données deviennent réutilisables. Les tableaux de bord peuvent être construits sur des fondations communes. Les analyses développées pour un fournisseur peuvent être étendues à d’autres environnements avec beaucoup moins d’effort.
Cette standardisation présente également un avantage souvent sous-estimé : elle réduit la dépendance aux formats propriétaires des fournisseurs. Lorsqu’une nouvelle plateforme est introduite ou lorsqu’un fournisseur est remplacé, les analyses existantes peuvent être conservées beaucoup plus facilement puisque les données sont ramenées vers un modèle commun. Dans un contexte multi-cloud comme celui de GitLab, cette capacité à abstraire les spécificités des fournisseurs constitue un facteur important de pérennité de la plateforme FinOps.
L’enjeu est loin d’être uniquement technique. Dans de nombreuses organisations, les experts FinOps passent encore une part significative de leur temps à construire des pipelines de transformation, à maintenir des connecteurs spécifiques ou à réconcilier des données provenant de plusieurs sources. Cette activité est indispensable, mais elle produit relativement peu de valeur directe pour les métiers.
La promesse de FOCUS consiste justement à réduire ce travail de normalisation afin de permettre aux équipes de consacrer davantage de temps à l’analyse économique et à l’aide à la décision.
Une fondation pour le FinOps de demain
Cette standardisation devient encore plus importante à mesure que le périmètre du FinOps s’élargit.
Comme l’a rappelé Mike Fuller lors de la conférence, l’ensemble des capacités du framework FinOps repose sur les données de coûts et d’usage. L’allocation, les prévisions, les unit economics ou encore l’optimisation nécessitent tous une donnée fiable, cohérente et exploitable.
Tant que les équipes consacrent leur énergie à harmoniser les données provenant de multiples fournisseurs, elles ne la consacrent pas à produire les analyses qui guideront les décisions de l’entreprise.
FOCUS ne génère donc pas directement de valeur métier. En revanche, il réduit considérablement la friction qui empêche cette valeur d’émerger. C’est précisément cette logique qui a conduit GitLab à l’adopter comme fondation de sa plateforme FinOps.
L'architecture FinOps mise en place par GitLab
Centraliser et normaliser les données de coûts
Une fois le besoin clairement identifié, GitLab devait répondre à une question relativement simple en apparence : comment construire une vision cohérente des coûts à partir de données provenant de fournisseurs aussi différents qu’AWS, Google Cloud, Oracle Cloud, Cloudflare ou encore plusieurs plateformes SaaS ?
La première étape a consisté à créer une fondation de données centralisée. Pour cela, GitLab a construit une plateforme reposant principalement sur Snowflake pour le stockage et l’analyse des données, ainsi que sur DBT pour les opérations de transformation et de modélisation.
L’ensemble des exports de facturation provenant des différents fournisseurs est ainsi collecté puis centralisé dans un entrepôt unique. Cette approche permet d’éliminer les silos qui existent traditionnellement entre les différentes équipes et les différents environnements technologiques.
Cependant, centraliser les données ne résout qu’une partie du problème. Les fichiers de facturation restent construits selon des modèles très différents selon les fournisseurs. Avant de pouvoir réaliser la moindre analyse transverse, il est nécessaire de rendre ces données comparables.
C’est précisément à cette étape que FOCUS intervient. Les modèles DBT développés par GitLab convertissent progressivement chaque source de facturation vers le schéma défini par la spécification FOCUS. Les coûts AWS, Google Cloud ou Cloudflare peuvent alors être manipulés à travers une structure commune, ce qui simplifie considérablement les traitements analytiques réalisés en aval.
Cette phase de normalisation constitue le socle de toute la démarche. Sans elle, chaque nouveau fournisseur nécessiterait ses propres modèles d’analyse, ses propres tableaux de bord et ses propres mécanismes de calcul.
Relier les coûts à la réalité opérationnelle
La normalisation des données constitue néanmoins seulement la première couche de l’architecture.
Comme beaucoup d’organisations matures, GitLab a rapidement constaté qu’une facture cloud, même parfaitement structurée, ne permet pas à elle seule de comprendre la valeur créée par les dépenses technologiques.
Une ligne de facturation indique qu’une ressource a été consommée et combien elle a coûté. Elle ne permet généralement pas de savoir quelle fonctionnalité utilise cette ressource, quels utilisateurs en bénéficient ou quel impact elle produit sur l’activité de l’entreprise.
Pour répondre à cette problématique, GitLab enrichit les données FOCUS avec de nombreuses informations complémentaires issues de son écosystème interne. Les équipes intègrent notamment des données financières, des informations relatives aux produits, des métadonnées techniques ainsi que des métriques opérationnelles provenant de plateformes comme Prometheus ou Thanos.
GitLab enrichit également ces données avec des informations issues directement de sa plateforme produit afin de relier les coûts techniques aux fonctionnalités consommées par les utilisateurs.
Cette phase d’enrichissement joue un rôle fondamental. Elle permet de dépasser une vision purement infrastructurelle des coûts pour construire une lecture beaucoup plus proche des enjeux métier.
L’objectif n’est plus simplement de savoir combien coûte une machine virtuelle ou un service cloud. Il devient possible de comprendre quels produits consomment ces ressources, quelles équipes en sont responsables ou encore quels usages réels expliquent les dépenses observées.
Cette capacité à relier les coûts aux activités de l’entreprise constitue l’un des principaux facteurs de maturité d’une démarche FinOps. Elle transforme progressivement une logique de reporting technique en véritable outil d’aide à la décision.
Construire une vision économique commune
L’aboutissement de cette architecture est la création d’un modèle de données unifié regroupant l’ensemble des coûts technologiques de l’entreprise.
Toutes les dépenses, quel que soit leur fournisseur d’origine, sont consolidées au sein d’une même structure. Elles sont ensuite enrichies par les informations métier, produit et opérationnelles nécessaires à leur interprétation.
GitLab obtient ainsi une vue cohérente et transverse de son écosystème technologique.
Cette approche présente plusieurs avantages majeurs. Elle permet d’abord d’améliorer considérablement la qualité des analyses FinOps. Les équipes travaillent sur des données homogènes et partagent les mêmes définitions des indicateurs. Les risques d’interprétation divergente diminuent et les analyses deviennent plus reproductibles.
Elle facilite également la collaboration entre les différentes parties prenantes. Les équipes produit, engineering, finance ou FinOps peuvent s’appuyer sur les mêmes données et les mêmes modèles économiques pour prendre leurs décisions.
Enfin, cette source unique de vérité constitue le socle nécessaire à la construction de capacités plus avancées comme les prévisions de coûts, les unit economics ou encore les modèles de rentabilité par fonctionnalité.
Autrement dit, l’objectif de GitLab n’était pas uniquement de mieux comprendre ses factures cloud. L’entreprise cherchait à construire une plateforme capable de transformer des données techniques dispersées en informations économiques directement exploitables par les décideurs.
Dépasser les limites des tags grâce aux métriques opérationnelles
Pourquoi les tags ne suffisent plus
L’allocation des coûts constitue l’un des fondements historiques du FinOps. Dans la plupart des organisations, elle repose principalement sur des tags, des labels ou des conventions de nommage permettant de rattacher les ressources à une équipe, un produit ou un centre de coûts.
Cette approche fonctionne relativement bien pour identifier le propriétaire d’une ressource ou répartir une facture entre plusieurs entités. En revanche, elle montre rapidement ses limites lorsqu’il s’agit de comprendre comment une infrastructure partagée est réellement consommée.
Une base de données, un cluster Kubernetes ou un service commun peuvent être utilisés simultanément par plusieurs équipes, plusieurs produits ou plusieurs catégories d’utilisateurs. Dans ce contexte, les tags permettent de savoir qui possède une ressource, mais rarement pourquoi elle coûte ce qu’elle coûte.
Or cette distinction devient essentielle dès lors que l’on cherche à construire des unit economics ou à relier les coûts aux usages métier.
Enrichir l'allocation grâce aux données opérationnelles
Pour répondre à cette problématique, GitLab a choisi de compléter ses données de facturation par des métriques opérationnelles issues de ses plateformes d’observabilité, notamment Prometheus et Thanos.
L’objectif n’est plus uniquement d’attribuer les coûts à un propriétaire, mais de comprendre quels usages génèrent effectivement ces coûts. Cette approche permet de construire des modèles d’allocation fondés sur l’activité réelle des utilisateurs plutôt que sur une simple répartition théorique de l’infrastructure.
L’exemple présenté autour du service Gitaly illustre parfaitement cette logique. Ce composant central de la plateforme GitLab assure le stockage et la gestion des dépôts Git. Son coût dépend directement de l’activité générée par les utilisateurs.
Grâce aux métriques collectées par ses outils d’observabilité, GitLab est capable de distinguer les utilisateurs gratuits, les clients payants ou encore les utilisateurs internes. Les coûts peuvent alors être répartis en fonction de l’usage réel du service et non uniquement en fonction de la structure technique sous-jacente.
Cette approche permet à GitLab de répondre à une question beaucoup plus stratégique que la simple répartition des dépenses : quels usages, quels produits et quels utilisateurs sont réellement à l’origine des coûts observés ?
Les unit economics deviennent enfin accessibles
Quand la donnée est prête, le calcul devient simple
Les unit economics sont souvent présentés comme l’un des exercices les plus avancés du FinOps. Dans de nombreuses organisations, ils font l’objet de projets spécifiques, mobilisant plusieurs équipes pendant plusieurs mois afin de construire des modèles capables de relier les coûts techniques aux activités métier.
Le retour d’expérience de GitLab propose une lecture différente.
Selon l’entreprise, la difficulté ne réside pas réellement dans le calcul lui-même. Elle réside avant tout dans la qualité et la cohérence des données utilisées. Tant que les informations de facturation, les métriques techniques et les données produit restent dispersées dans différents systèmes, chaque analyse nécessite un travail important de réconciliation et d’interprétation.
À l’inverse, une fois ces données consolidées au sein d’une même plateforme et structurées autour d’un modèle commun, la production d’indicateurs économiques devient beaucoup plus accessible. Les calculs eux-mêmes reposent alors sur des mécanismes relativement simples de modélisation et d’agrégation.
Autrement dit, GitLab considère les unit economics comme la conséquence naturelle d’une bonne fondation de données plutôt que comme un exercice isolé.
Relier les coûts aux usages métier
Cette approche permet à l’entreprise de produire des indicateurs directement exploitables par les équipes produit, engineering et finance.
Plutôt que de raisonner uniquement en termes de ressources cloud ou de dépenses d’infrastructure, les équipes peuvent désormais analyser le coût associé à des éléments beaucoup plus proches de leur activité : un utilisateur actif, une fonctionnalité spécifique, un dépôt Git stocké ou encore certaines fonctionnalités d’intelligence artificielle.
Cette évolution change profondément la nature des conversations. Les équipes techniques ne discutent plus uniquement de consommation de ressources ou d’optimisation d’infrastructure. Elles peuvent relier leurs décisions à des impacts économiques mesurables et comprendre plus facilement comment leurs choix influencent le coût global du service.
Les équipes produit bénéficient également d’une visibilité beaucoup plus fine sur la rentabilité de certaines fonctionnalités, ce qui facilite les arbitrages entre investissement, croissance et maîtrise des coûts.
GitLab souligne enfin un effet particulièrement intéressant : lorsque ces indicateurs deviennent facilement accessibles, ils encouragent naturellement les comportements d’optimisation. Les équipes n’ont plus besoin d’attendre une analyse spécifique menée par le FinOps pour identifier certaines dérives ou certaines opportunités d’amélioration. Les signaux économiques deviennent directement visibles et peuvent être intégrés beaucoup plus tôt dans les décisions quotidiennes.
Les résultats obtenus par GitLab
Après environ dix-huit mois de travail, GitLab estime avoir porté sa couverture d’allocation des coûts de 30 % à près de 80 %. Cette progression constitue déjà un résultat significatif en soi. Une allocation plus complète améliore mécaniquement la qualité des analyses, facilite les exercices de prévision et permet d’identifier plus rapidement les opportunités d’optimisation.
L’entreprise indique également avoir généré environ 5 % d’économies trimestrielles grâce aux actions menées par les équipes. Ces résultats illustrent l’intérêt opérationnel d’une meilleure visibilité sur les coûts et démontrent qu’une donnée plus fiable contribue directement à l’amélioration de la performance économique.
Toutefois, les chiffres ne racontent qu’une partie de l’histoire.
Le bénéfice le plus intéressant semble être l’évolution de la manière dont les équipes utilisent la donnée économique au quotidien. En construisant une plateforme commune et des indicateurs partagés, GitLab a progressivement rendu les informations FinOps accessibles à un public beaucoup plus large que la seule équipe spécialisée.
Les équipes produit, finance et engineering travaillent désormais à partir des mêmes définitions, des mêmes métriques et des mêmes modèles d’allocation. Les discussions ne portent plus sur la validité des chiffres ou sur la provenance des données, mais sur les décisions à prendre à partir de ces informations.
Cette évolution est souvent l’un des marqueurs les plus fiables d’une démarche FinOps mature. Lorsque les données économiques deviennent suffisamment accessibles pour être utilisées directement par les équipes opérationnelles, le FinOps cesse d’être une fonction spécialisée chargée d’analyser les dépenses après coup. Il devient progressivement une capacité distribuée au sein de l’organisation, intégrée aux processus de décision quotidiens.
Notre analyse : la vraie valeur de FOCUS n'est pas la normalisation
Le véritable problème n'est plus l'accès à la donnée
À première vue, FOCUS peut sembler être un sujet essentiellement technique. Après tout, il s’agit avant tout d’un standard destiné à harmoniser des données de coûts et d’usage provenant de différents fournisseurs technologiques.
Pourtant, réduire FOCUS à un simple format d’échange serait probablement passer à côté de son principal intérêt.
Le retour d’expérience de GitLab met en évidence une évolution que nous observons également chez de nombreuses organisations. Le principal défi du FinOps moderne n’est plus d’obtenir des données. Les entreprises disposent déjà d’une quantité considérable d’informations issues de leurs fournisseurs cloud, de leurs plateformes SaaS, de leurs outils d’observabilité ou encore de leurs systèmes financiers.
Le problème se situe désormais ailleurs.
Ces données existent, mais elles restent souvent dispersées entre plusieurs outils, plusieurs équipes et plusieurs modèles de représentation. Chaque acteur dispose de sa propre vision des coûts, de ses propres indicateurs et parfois même de ses propres définitions. Dans ce contexte, produire un tableau de bord supplémentaire n’apporte généralement qu’une valeur limitée.
Le véritable enjeu consiste à créer une lecture cohérente capable d’être partagée par l’ensemble des parties prenantes. Autrement dit, il ne s’agit plus seulement de collecter des données, mais de construire un langage commun permettant aux équipes engineering, produit, finance et direction de parler des mêmes sujets avec les mêmes référentiels.
C’est précisément à ce niveau que FOCUS devient intéressant. Le standard ne crée pas directement de valeur métier. En revanche, il réduit considérablement la complexité nécessaire pour construire cette vision commune.
Une fondation pour le FinOps multi-technologies
L’autre enseignement important de ce retour d’expérience concerne l’évolution même du périmètre FinOps.
Historiquement, les pratiques FinOps se concentraient principalement sur le cloud public. Les modèles de données, les outils et les processus avaient été conçus pour répondre à cette problématique spécifique. Aujourd’hui, la situation est radicalement différente.
Les organisations cherchent désormais à piloter simultanément des infrastructures cloud, des plateformes de données, des services SaaS, des environnements hybrides et, de plus en plus, des usages liés à l’intelligence artificielle. Chacune de ces catégories introduit ses propres modèles de consommation, ses propres mécanismes tarifaires et ses propres sources de données.
Dans ce contexte, la question de la normalisation cesse d’être un sujet purement technique. Elle devient un sujet d’architecture de la donnée et, à terme, un sujet de gouvernance.
Le cas GitLab illustre parfaitement cette évolution. L’entreprise n’a pas adopté FOCUS dans l’objectif de produire de meilleurs rapports ou de simplifier quelques requêtes SQL. Elle l’a adopté pour construire une fondation capable de relier plusieurs univers qui restent traditionnellement séparés : l’infrastructure, les produits, les utilisateurs et la valeur économique créée par ces usages.
C’est d’ailleurs ce qui distingue souvent les démarches FinOps les plus matures. Elles ne se limitent plus à optimiser des ressources ou à produire des tableaux de bord. Elles construisent progressivement les mécanismes qui permettent à l’organisation de prendre de meilleures décisions économiques à partir de données fiables et partagées.
Dans cette perspective, FOCUS n’est probablement pas la destination. C’est l’infrastructure invisible qui rend possible tout le reste.
Conclusion
Le retour d’expérience de GitLab montre que la valeur du FinOps ne repose plus uniquement sur la visibilité ou l’optimisation des coûts.
À mesure que les organisations étendent leur périmètre au SaaS, aux plateformes de données, à l’IA ou aux environnements hybrides, le véritable défi devient la construction d’une vision économique cohérente à travers l’ensemble de ces technologies.
Dans ce contexte, FOCUS apparaît moins comme un simple standard de données que comme une fondation permettant d’unifier les coûts, les usages et les indicateurs métier. La normalisation n’est pas une finalité. Elle constitue le socle nécessaire pour construire des allocations fiables, produire des unit economics pertinents et éclairer les décisions d’investissement.
Le cas GitLab illustre finalement une tendance de fond : les pratiques FinOps les plus matures ne cherchent plus seulement à comprendre où l’argent est dépensé. Elles cherchent à comprendre pourquoi il est dépensé et quelle valeur il produit pour l’entreprise.
Chez Sudo, nous accompagnons les organisations dans cette évolution, de l’unification des données de coûts à la mise en place d’indicateurs économiques permettant de piloter efficacement le cloud, le SaaS et l’IA.