Le Semantic Layer dbt : une seule définition pour chaque indicateur

Voici une scène que tu as peut-être vécue. Deux personnes sortent un chiffre d’affaires de deux outils différents, et les nombres ne tombent pas pareil. À partir de là, plus personne ne fait confiance aux chiffres. Le Semantic Layer dbt existe pour régler ce problème de fond.

L’idée : définir une fois, utiliser partout

Un semantic layer, c’est une couche où tu définis chaque indicateur une seule fois, de façon centrale : sa définition métier, sa logique de calcul, ses sources et ses filtres. Ensuite, tous tes outils interrogent cette définition unique au lieu de recalculer le chiffre chacun dans son coin.

Chez dbt, le moteur derrière cette couche s’appelle MetricFlow. Tu décris dans ton projet dbt des semantic models, qui exposent des entités, des dimensions et des mesures, puis des métriques qui s’appuient dessus. MetricFlow se charge ensuite de générer le bon SQL à la volée, pour n’importe quelle combinaison d’indicateur et de découpage¹.

flowchart TD
  G["Modèles dbt (couche Gold)"] --> S["Semantic models<br/>entités, dimensions, mesures"]
  S --> M["Métriques MetricFlow"]
  M --> BI["Outils BI"]
  M --> Chat["Chatbot en langage naturel"]
  M --> API["API / autres apps"]

Quelques règles d’or

Construire cette couche demande de la rigueur, sinon les chiffres redeviennent faux. Trois principes reviennent toujours. Chaque semantic model doit avoir une clé primaire unique par ligne, sans quoi les sommes se retrouvent multipliées. Les divisions doivent être protégées contre le zéro et le nul. Et pour chaque indicateur important, on crée en général un triplet : la valeur de l’année, la valeur N-1, et la variation en pourcentage.

Le vrai intérêt aujourd’hui : nourrir un chatbot

C’est là que le sujet devient passionnant. Un semantic layer ne sert pas qu’aux tableaux de bord, il est devenu la pièce maîtresse pour poser des questions à ses données en langage naturel. Le principe est élégant : le chatbot ne voit jamais le SQL ni les tables, il ne voit que la liste des métriques définies. Il choisit la bonne métrique et le bon découpage, et c’est MetricFlow qui exécute. Résultat, beaucoup moins d’hallucinations qu’un assistant qui écrirait du SQL librement.

Un détail compte énormément dans ce cas : la qualité des descriptions. Si tu ajoutes à chaque métrique des alias, les synonymes qu’un utilisateur emploierait vraiment, comme « CA » ou « ventes » pour le chiffre d’affaires, le chatbot retrouve la bonne métrique au lieu de se tromper. Cette logique de couche structurée entre l’utilisateur et la donnée rappelle d’ailleurs ce que font les agents IA avec leurs outils.

Ce qui a changé en 2026

Si tu reprends un contenu d’il y a un an, mets à jour trois points. MetricFlow est désormais open source, sous licence Apache 2.0, dans le cadre d’une initiative d’interopérabilité des couches sémantiques². dbt a aussi introduit un nouveau moteur, dbt Fusion, écrit en Rust, qui promet une analyse et une exécution nettement plus rapides³. Enfin, sur le plan industriel, dbt Labs et Fivetran ont fusionné, opération finalisée le 1er juin 2026, ce qui rapproche l’ingestion et la transformation des données sous un même toit⁴.

L’essentiel à retenir

Le Semantic Layer dbt, c’est la fin des chiffres qui ne tombent pas pareil : une définition unique par indicateur, calculée à la volée par MetricFlow. Soigne les clés uniques, la sécurité des divisions et surtout les descriptions si tu veux brancher un chatbot dessus. Et garde en tête les nouveautés 2026, MetricFlow open source, le moteur Fusion et la fusion avec Fivetran.