Metric Views dans Unity Catalog : définissez le KPI une fois, utilisez-le partout

En presque deux décennies d'ingénierie des données, j'ai appris à reconnaître un symptôme qui apparaît dans presque toute entreprise qui grandit : la même métrique calculée de plusieurs façons différentes. Le « chiffre d'affaires » du tableau de bord exécutif ne correspond pas au « chiffre d'affaires » du rapport financier, qui à son tour ne correspond pas au « chiffre d'affaires » que l'équipe de data science a utilisé pour entraîner le modèle de churn. Personne ne s'est trompé exprès — chaque personne a réimplémenté la même logique dans un SQL légèrement différent, et les petites divergences (un filtre en plus ici, un DISTINCT en moins là) se sont accumulées.

Les Metric Views d'Unity Catalog, mises en avant par Databricks au Data + AI Summit 2026 dans le cadre de la nouvelle couche sémantique, s'attaquent précisément à ce problème. L'idée est simple et puissante : vous définissez la métrique une seule fois, de manière gouvernée, et chaque consommateur — SQL, BI, API ou agent d'IA — lit la même définition.

Le problème avec la vue traditionnelle

Une vue SQL classique résout la réutilisation de la requête, mais pas de la métrique. Quand vous écrivez :

CREATE VIEW ca_par_pays AS
SELECT pays, SUM(total) AS ca
FROM ventes
GROUP BY pays;

vous avez figé la granularité au moment de la création. Cette vue ne sert que pour le chiffre d'affaires par pays. Si demain quelqu'un a besoin du chiffre d'affaires par mois, ou par produit, ou par pays et par mois, il devra écrire une autre vue — et c'est là que les définitions commencent à diverger. L'agrégation (SUM(total)) et la dimension (pays) sont collées au même objet.

La Metric View sépare ces deux choses. Vous définissez la mesure (le calcul) indépendamment des dimensions (par quoi on regroupe), et vous décidez de la granularité seulement au moment de la requête.

Étape 1 — Définir la métrique en YAML

Une Metric View est déclarée en YAML et enregistrée dans Unity Catalog comme s'il s'agissait d'une vue. En SQL, vous enveloppez le YAML dans un CREATE VIEW ... WITH METRICS, avec la définition entre les délimiteurs $$ :

CREATE VIEW ventes.ca_mv
WITH METRICS
LANGUAGE YAML
AS $$
version: 1.1
source: ventes.commandes
dimensions:
  - name: pays
    expr: pays
  - name: mois
    expr: date_trunc('MONTH', date_commande)
measures:
  - name: ca
    expr: SUM(total)
  - name: clients
    expr: COUNT(DISTINCT client_id)
$$;

Remarquez la structure : source est la table (ou une requête) d'origine ; dimensions sont les axes selon lesquels vous allez découper ; measures sont les calculs agrégés. La définition de ca comme SUM(total) existe désormais à un seul endroit — Unity Catalog.

Étape 2 — Interroger avec MEASURE() et regrouper par n'importe quelle dimension

Voici la différence pratique par rapport à la vue traditionnelle. Vous interrogez la Metric View avec la fonction MEASURE() et vous regroupez par n'importe quelle dimension disponible — le moteur génère la bonne agrégation à chaque requête :

-- chiffre d'affaires par pays
SELECT pays, MEASURE(ca) AS ca
FROM ventes.ca_mv
GROUP BY pays;

-- la MÊME métrique, désormais par pays et par mois
SELECT pays, mois, MEASURE(ca) AS ca
FROM ventes.ca_mv
GROUP BY pays, mois;

Il n'y a pas de deuxième définition du chiffre d'affaires. La règle de calcul est la même ; seul le GROUP BY change. C'est le cœur de la couche sémantique : la métrique est immuable, la granularité est libre.

Et parce que la Metric View vit dans Unity Catalog, vous pouvez aussi l'interroger de façon programmatique avec spark.sql() (dans des notebooks sur DBR 17.2+ ou via un SQL warehouse) — toujours en passant par MEASURE(). Le même chiffre, désormais disponible pour les pipelines en PySpark :

df = spark.sql("""
    SELECT pays, MEASURE(ca) AS ca
    FROM ventes.ca_mv
    GROUP BY pays
""")
df.show()

Un détail qui piège beaucoup de monde : la Metric View ne répond qu'à travers MEASURE(). Un SELECT * — ou un spark.read.table(...).show() brut — n'est pas pris en charge, justement parce que la mesure n'a pas de granularité prédéfinie tant que vous n'indiquez pas par quoi regrouper.

Étape 3 — Un seul chiffre, consommé partout

Le gain stratégique apparaît quand on regarde qui consomme la définition. Comme elle vit dans le catalogue, le même KPI est lu de façon identique par :

• SQL et Warehouses — les analystes écrivent des requêtes sans réinventer le calcul.
• Power BI et outils de BI — le tableau de bord hérite de la définition officielle, pas d'une copie.
• API — les applications consomment la métrique gouvernée derrière un endpoint.
• Agents d'IA — et c'est le point le plus actuel de 2026 : quand un LLM doit répondre « quel a été le chiffre d'affaires du trimestre ? », il interroge la définition officielle au lieu d'improviser un SQL. La couche sémantique devient le grounding qui empêche l'agent d'inventer le calcul.

Gouvernance : la métrique hérite d'Unity Catalog

Un détail que les ingénieurs des données apprécient : parce qu'elle est un objet Unity Catalog, la Metric View hérite de tout le modèle de gouvernance — permissions par groupe, masquage de colonnes, lignage (lineage) et audit. Vous contrôlez qui peut interroger la métrique avec les mêmes outils que vous utilisez déjà pour les tables, et vous pouvez remonter l'origine de chaque chiffre jusqu'à la table de base. La cohérence cesse de dépendre de la discipline humaine et devient garantie par la plateforme.

Quand l'utiliser — et quand non

Les Metric Views brillent quand l'objectif est de standardiser les KPI centraux du métier — chiffre d'affaires, marge, churn, utilisateurs actifs — et de garantir que tous les consommateurs voient le même chiffre. Elles sont la bonne réponse à la question classique « pourquoi ces deux rapports ne concordent-ils pas ? ».

Mais il est important d'être honnête sur les limites :

• Les Metric Views ne remplacent pas la modélisation dimensionnelle. Elles se posent au-dessus des tables déjà nettoyées et traitées. Vous avez toujours besoin de votre ETL, de vos dimensions conformées et de vos tables de faits. La Metric View standardise le calcul final, pas la préparation de la donnée.
• Ce n'est pas un raccourci pour sauter l'ingénierie. Si la table d'origine est sale ou mal modélisée, la métrique ne fera que propager le problème de façon plus cohérente.
• La spécification évolue encore. La syntaxe YAML (des clés comme source, fields — l'ancien dimensions —, measures, filter, joins, window measures) mûrit vite — il vaut mieux consulter la référence officielle avant de concevoir quelque chose de complexe, car de nouvelles fonctionnalités continuent d'être ajoutées.

Conclusion

Après des années à voir des équipes débattre de quel tableau de bord a le « bon » chiffre, il est difficile de ne pas voir les Metric Views comme une correction de trajectoire nécessaire. Le problème n'a jamais été un manque de SQL — c'était un excès de SQL, avec la même métrique réimplémentée des dizaines de fois. Transformer le KPI en un objet gouverné, défini une fois et consommé par SQL, BI, API et agents d'IA, est le type de simplification qui redonne confiance dans la donnée.

Si, dans votre entreprise, le mot « chiffre d'affaires » signifie des choses légèrement différentes selon qui pose la question, une expérimentation avec les Metric Views en vaut la peine. La probabilité que vous finissiez par supprimer des définitions dupliquées — au lieu d'en créer une de plus — est réelle.