ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Architecture de la couche sémantique

Fonctionnement des couches sémantiques dans le modern data stack — implémentations concurrentes (MetricFlow, Snowflake Semantic Views, Databricks Metric Views), l'initiative OSI, et pourquoi la couche sémantique détermine la précision de l'IA.

Planté
dbtbigquerysnowflakeanalyticsdata modeling

Une couche sémantique se situe entre votre entrepôt de données et vos consommateurs — outils BI, agents IA, applications personnalisées, notebooks — et fournit un endroit unique et gouverné où les métriques et les dimensions sont définies. Au lieu que chaque consommateur écrive son propre SQL pour calculer le « revenu » ou les « utilisateurs actifs », la couche sémantique détient la définition canonique et la traduit en SQL natif de l’entrepôt au moment de la requête.

Le concept existe depuis des décennies (couches de métadonnées Cognos, univers Business Objects). En 2025-2026, trois implémentations concurrentes prêtes pour la production coexistent, et un standard d’interopérabilité est en cours d’émergence.

Pourquoi la couche sémantique est importante maintenant

Sans couche sémantique gouvernée, différents analystes qui écrivent des requêtes pour la même métrique produisent des résultats différents : l’un exclut les remboursements, l’autre utilise la date de facturation au lieu de la date de transaction, le troisième filtre sur un ensemble de devises différent. Cette dérive des métriques érode la confiance dans les données.

L’infrastructure pour résoudre ce problème a mûri sur plusieurs plateformes simultanément. L’essor des analytics pilotées par IA a ajouté de l’urgence : un copilote IA générant du SQL sans couche sémantique gouvernée produira des définitions de métriques incohérentes à grande échelle.

Les trois implémentations concurrentes

dbt MetricFlow

MetricFlow est la couche sémantique de dbt Labs, mise en open-source sous Apache 2.0 après la fusion Fivetran-dbt Labs. Il définit les métriques en YAML aux côtés de votre projet dbt, faisant des définitions de métriques une partie du même codebase versionné et testé en CI/CD que vos transformations.

Une définition de métrique MetricFlow ressemble à ceci :

semantic_models:
  - name: orders
    defaults:
      agg_time_dimension: order_date
    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
    measures:
      - name: order_total
        agg: sum
        expr: amount
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: status
        type: categorical


metrics:
  - name: revenue
    type: simple
    type_params:
      measure: order_total
    filter: |
      {{ Dimension('order_id__status') }} = 'completed'


  - name: revenue_per_customer
    type: derived
    type_params:
      expr: revenue / count_customers
      metrics:
        - name: revenue
        - name: count_customers

Les décisions architecturales clés : les métriques sont construites au-dessus de « mesures » (agrégations sur des colonnes) et de « modèles sémantiques » (le mapping entre vos tables d’entrepôt et les entités métier). Les métriques dérivées composent d’autres métriques avec de l’arithmétique. Les filtres utilisent une syntaxe de type Jinja qui référence les dimensions via leur chemin d’entité.

Début 2026, le moteur dbt Fusion modernise la spec MetricFlow pour dbt Core v1.12. Le changement majeur : supprimer le concept séparé de « mesures » et intégrer les annotations sémantiques directement dans les entrées YAML des modèles. Cela simplifie considérablement l’expérience d’authoring — vous définissez un modèle et sa signification sémantique en un seul endroit au lieu de maintenir des blocs YAML parallèles.

MetricFlow est multi-cloud. Il génère du SQL pour BigQuery, Snowflake, Databricks, Redshift et PostgreSQL. L’API dbt Cloud Semantic Layer expose les métriques via JDBC, GraphQL et REST, que n’importe quel outil aval peut interroger.

Snowflake Semantic Views

La couche sémantique native de Snowflake, intégrée à la plateforme elle-même. Plutôt que de définir les métriques dans des fichiers YAML externes, vous créez des vues sémantiques comme des objets de base de données de première classe en utilisant le DDL SQL :

CREATE SEMANTIC VIEW revenue_metrics AS
  TABLES (
    orders AS o,
    customers AS c
  )
  RELATIONSHIPS (
    o.customer_id = c.customer_id
  )
  METRICS (
    total_revenue AS SUM(o.amount),
    avg_order_value AS AVG(o.amount)
  )
  DIMENSIONS (
    c.region,
    o.order_date
  );

L’avantage est une intégration étroite avec l’optimiseur de requêtes et le modèle de gouvernance de Snowflake — les permissions, la sécurité au niveau des lignes et le masquage des données s’appliquent aux vues sémantiques de la même façon qu’aux vues ordinaires. L’inconvénient est le vendor lock-in : ces définitions ne fonctionnent que sur Snowflake.

Databricks Metric Views

L’approche de Databricks est lakehouse-centrique, intégrant Unity Catalog pour la gouvernance. Les Metric Views définissent des métriques qui sont découvrables via le catalog et interrogeables par n’importe quel outil connecté à Databricks SQL. Comme l’approche Snowflake, cela lie la gouvernance des métriques au modèle de permissions existant de la plateforme.

Le problème d’interopérabilité et OSI

Avoir trois couches sémantiques concurrentes crée un problème évident : si vos métriques sont définies dans MetricFlow mais qu’un outil natif Snowflake ne lit que les Semantic Views, vous devez soit maintenir des définitions parallèles (ce qui annule l’objectif) soit choisir un camp.

L’initiative Open Semantic Interchange (OSI), lancée par dbt Labs, Snowflake, Salesforce, Atlan et ThoughtSpot, vise à créer des standards neutres vis-à-vis des éditeurs pour l’échange de données sémantiques. L’objectif est un format commun que n’importe quel outil peut lire et écrire, afin que les définitions de métriques soient portables entre plateformes.

Une interopérabilité significative est attendue en 2026-2027. En attendant, le choix pratique dépend de votre stack :

  • Équipes dbt-centriques : MetricFlow. Vos métriques vivent aux côtés de vos transformations, revues dans les mêmes PRs, testées dans les mêmes pipelines CI.
  • Équipes Snowflake-native sans dbt : Snowflake Semantic Views. Zéro dépendance externe.
  • Équipes Databricks-native : Metric Views intégrées avec Unity Catalog.
  • Équipes multi-cloud : MetricFlow est la seule option qui génère du SQL à travers différents entrepôts aujourd’hui.

La couche sémantique détermine la précision de l’IA

Tous les grands outils BI embarquent désormais des fonctionnalités IA : langage naturel vers SQL, insights automatisés, analytics conversationnelles. Power BI a Copilot. Tableau a Einstein AI. Looker a Gemini. ThoughtSpot a Spotter. Lightdash a les AI Agents. La liste s’allonge.

Les praticiens rapportent le même constat : le modèle IA n’est pas le goulot d’étranglement — c’est la couche sémantique. Quand un utilisateur demande « quel était le revenu du dernier trimestre ? », l’IA doit savoir :

  1. Quelle table contient les données de revenu
  2. Quelle colonne représente le montant
  3. Quels filtres définissent le « revenu » (commandes complétées uniquement ? en excluant les remboursements ?)
  4. Ce que « dernier trimestre » signifie (trimestre fiscal ? calendaire ? quel fuseau horaire ?)

Sans couche sémantique gouvernée, l’IA choisit des colonnes vraisemblables et applique des filtres qui semblent raisonnables, produisant du SQL qui a l’air correct mais calcule un mauvais chiffre.

Une couche sémantique bien définie contraint le vocabulaire de l’IA à des définitions de métriques connues, des dimensions valides et des filtres autorisés. Cela réduit le problème de « inférer ce que revenu signifie » à « traduire une question utilisateur en requête contre des définitions connues ».

Couche sémantique et Headless BI

La puissance de la couche sémantique se multiplie quand elle est exposée via des APIs plutôt qu’enfermée dans un seul outil BI. C’est le pattern headless BI : votre couche sémantique devient un service de métriques que n’importe quel frontend peut interroger. Un dashboard React, un bot Slack, un rapport e-mail planifié et un agent IA consomment tous les mêmes métriques gouvernées depuis la même API.

Cube.dev et l’API Semantic Layer de dbt sont les implémentations leaders. L’insight clé est que la couche sémantique est une infrastructure, pas une fonctionnalité de votre outil BI. La découpler de la visualisation signifie que vous pouvez changer d’outil BI frontend sans redéfinir les métriques, et vous pouvez servir les métriques à des applications qui ne sont pas des outils BI du tout.

Propriétés d’une implémentation mature

  • Définitions de métriques dans le contrôle de version, revues via pull requests, avec des tests validant la correction
  • Une définition canonique par métrique — pas de définitions parallèles dans différents outils
  • Hiérarchies de dimensions pour le drill-down sans SQL personnalisé
  • Contrôles d’accès hérités du modèle de permissions de l’entrepôt
  • Accès API pour n’importe quel consommateur aval, pas seulement l’outil BI
  • Documentation générée automatiquement depuis les métadonnées de métriques

Le travail difficile est organisationnel : parvenir à un accord sur les définitions de métriques, les maintenir à mesure que la logique métier évolue, et imposer que tous les consommateurs interrogent la couche sémantique plutôt qu’écrire du SQL ad hoc.