Couche sémantique : ce que dbt ne fait pas, et comment déclarer vos métriques une seule fois

La couche sémantique est le point où une métrique n'est déclarée qu'une seule fois, avec son nom, sa formule, ses filtres et son grain, avant d'être exposée à tous les outils qui la consomment. Sans elle, chaque dashboard, chaque export Sheets et chaque connecteur ERP recalcule le chiffre d'affaires ou le taux de conversion à sa façon, et deux vérités cohabitent sur la même semaine. dbt a réglé la transformation des données, pas ce chaînon-là : il produit des tables, pas des métriques partagées. Voici, avec le retour terrain de l'agence data et IA Hyperstack, ce que couvre réellement une couche sémantique, les symptômes qui trahissent son absence, et par où la construire sur une stack déjà en place.

« dbt suffit à aligner nos métriques » : la croyance qui coûte cher

dbt résout un vrai problème : il transforme des données brutes en tables propres, testées et versionnées. Ce n'est pas rien. Mais un modèle dbt produit une table, pas une métrique exposable ailleurs qu'en SQL brut. Le chiffre d'affaires recalculé dans Looker Studio, puis dans un Google Sheets, puis dans l'ERP, reste trois définitions locales d'une même intention.

La documentation officielle de dbt le confirme elle-même : un modèle est une instruction select sauvegardée en fichier .sql, qui transforme les données sans qu'elles quittent l'entrepôt. Rien dans cette étape ne garantit qu'un deuxième outil applique ensuite la même formule que le premier.

La croyance coûte cher parce qu'elle déplace le problème sans le résoudre. Chaque nouvel outil, un agent IA, une application interne, un dashboard, doit recoder la logique métier depuis zéro. Le jour où deux recodages divergent, c'est la confiance dans la donnée qui s'effondre, pas la donnée elle-même.

Trois symptômes qui prouvent que votre analyse de données est cassée

Trois signaux reviennent systématiquement quand la couche sémantique manque, quel que soit le secteur ou la taille de la stack. Ils sont d'abord vécus comme des irritants isolés, rarement nommés comme un seul problème structurel.

•Deux dashboards affichent deux chiffres différents pour la même semaine, sans qu'aucun des deux ne soit "faux" : chacun applique sa propre formule de calcul.

•Les équipes opérationnelles ne font plus confiance aux exports Sheets, parce qu'ils ne collent jamais exactement à l'ERP.

•Chaque nouvel outil, un agent IA, une application métier, une nouvelle version de dashboard, oblige à recoder la même logique de calcul depuis le début.

Nos équipes l'ont vu récemment chez une entreprise sur une stack GCP, BigQuery et dbt Core, avec près de 1 000 modèles dbt en production. Chaque dashboard Looker Studio redéfinissait sa propre formule de revenu, et aucune des deux versions ne pouvait être réutilisée dans Google Sheets ou dans l'ERP interne sans être recodée. Le sujet n'était pas de transformer plus de données, dbt le faisait déjà très bien. Le sujet était de décider où une métrique vit, et comment elle voyage jusqu'au consommateur suivant.

Ce qu'est réellement une couche sémantique

Une couche sémantique déclare une métrique une seule fois : son nom, sa formule, ses filtres, son grain d'agrégation. Elle l'expose ensuite via SQL, API REST ou protocole MCP à n'importe quel consommateur, un dashboard, un tableur, un ERP, un agent IA, sans que chacun ait à la recalculer à sa façon.

Trois familles d'outils implémentent ce principe aujourd'hui. Le dbt Semantic Layer, porté par MetricFlow, centralise la définition des métriques dans le projet dbt et les rend interrogeables en SQL depuis Tableau, Power BI, Google Sheets ou une API dédiée. Cube suit la même logique côté infrastructure indépendante, avec une exposition en SQL, REST ou GraphQL vers des dashboards comme vers des agents IA. LookML, le langage de Looker, applique un principe voisin, mais couplé à un seul outil de restitution : la métrique reste portable tant que Looker reste l'unique consommateur, pas au-delà.

Le piège classique consiste à confondre cette couche avec la couche de présentation. Un champ calculé créé dans un dashboard Power BI ou Tableau n'est pas une métrique partagée, c'est une formule locale à cet outil précis, invisible et non réutilisable ailleurs. La couche sémantique se situe en amont de tous les outils de restitution, pas à l'intérieur d'un seul d'entre eux.

Mettre en place une couche sémantique sur une stack existante : par où commencer

Le point de départ n'est pas un outil, c'est une liste. Identifiez les 3 à 5 métriques qui divergent le plus entre systèmes, en général le chiffre d'affaires, le taux de conversion et les actifs clients, et déclarez-les en priorité avant tout le reste.

Le critère de priorité est simple : une métrique présente dans plus de deux dashboards distincts est candidate immédiate. Une fois déclarée, la validation tient en une question, chaque consommateur l'appelle-t-il sans recalcul local ? Si la réponse est oui pour les 3 à 5 métriques prioritaires, le reste de la migration peut suivre au rythme des besoins, pas d'un big bang.

Chez Hyperstack, c'est le type de chantier que nos équipes opèrent sur des stacks GCP, BigQuery et dbt en production, pour des organisations qui n'ont pas le temps de lire une documentation d'outil avant de trancher. Un cabinet de conseil multi-entités a par exemple centralisé Salesforce, Napta, Payfit et Sage dans un entrepôt BigQuery versionné sous dbt, avant de garder son outil de visualisation existant. Le dashboard n'a pas changé : la définition du revenu et des marges, elle, est devenue unique et partagée. C'est la logique déjà posée dans notre comparatif sur l'architecture d'une modern data stack, et elle rejoint aussi la question du bon outil de restitution une fois la couche sémantique en place, traitée dans notre analyse du coût réel d'un outil de reporting.

La vraie question à trancher n'est donc pas quel outil choisir. C'est qui possède la définition d'une métrique dans votre organisation, et qui a le mandat de dire qu'elle est enfin unique. Nos équipes commencent toujours par cartographier les points de friction, les process et les données existantes avec les vôtres : c'est de cette carte que les cas d'usage à traiter en priorité émergent, avant de construire ce qui s'intègre réellement à ce qui existe déjà.

FAQ : couche sémantique, dbt et data warehouse

Une couche sémantique remplace-t-elle un data warehouse ?

Non. L'entrepôt de données (BigQuery, Snowflake) stocke les données, dbt les transforme, la couche sémantique déclare les métriques et les expose. Ce sont trois briques complémentaires, pas concurrentes.

Faut-il un outil dédié pour démarrer ?

Pas forcément dès le premier jour. Le dbt Semantic Layer s'ajoute directement à un projet dbt existant. Cube s'installe en complément, indépendant de l'entrepôt. Le choix dépend surtout du nombre d'outils qui doivent consommer la même métrique.

La couche sémantique sert-elle aussi les agents IA ?

Oui, et c'est un des usages qui progresse le plus vite. Un agent qui interroge un chiffre d'affaires via une API ou le protocole MCP obtient la même définition qu'un dashboard humain, sans recalculer sa propre formule à partir des tables brutes.

Par l'équipe Hyperstack, agence IA et automatisation en France, 40+ projets IA et data déployés.