Qu'est-ce qu'un Semantic Layer ?

Le Semantic Layer (ou couche sémantique) est une couche logique qui traduit vos données brutes en concepts métier partagés, comme le chiffre d’affaires, le client actif ou le taux de churn, pour que chaque outil qui consomme la donnée renvoie exactement le même résultat. Il ne remplace pas votre data warehouse : il s’installe au-dessus, une seule fois, pour que tout le monde (BI, application, agent IA) parle enfin le même langage.

Concrètement, il répond à trois questions que toute organisation data finit par se poser : comment définit-on précisément ce KPI ? Qui a raison quand deux dashboards affichent deux chiffres différents pour la même métrique ? Et comment garantir que cette définition reste valable demain, dans un nouvel outil ou pour un nouvel agent IA ?

Pourquoi le Semantic Layer est indispensable

Sans Semantic Layer, une organisation fait face à plusieurs problèmes concrets :

• Deux dashboards, deux vérités : le Comex demande le “chiffre d’affaires” en réunion. La Finance sort un chiffre, la Data un autre, le Sales Ops un troisième. Chacun a raison selon sa propre définition, écrite dans son propre outil et jamais partagée.
• La logique métier dupliquée à l’infini : la règle “client actif = au moins une commande dans les 90 derniers jours” est réécrite en SQL dans Looker, copiée dans Power BI, adaptée dans un notebook Python. Le jour où la règle change, il faut la corriger partout, et on en oublie toujours un.
• Une confiance qui s’érode : quand les chiffres se contredisent d’un outil à l’autre, les dirigeants finissent par ne plus faire confiance à la donnée du tout.
• Le nouveau risque des agents IA : un agent IA branché directement sur l’entrepôt, sans couche sémantique, génère sa propre requête SQL à chaque question, et donc sa propre définition du “churn”. Sans gouvernance, l’IA démultiplie l’incohérence au lieu de la résoudre.

Les différentes approches

On distingue généralement trois façons d’implémenter un Semantic Layer :

• Embarqué dans l’outil BI : LookML dans Looker, le modèle tabulaire de Power BI, les extraits Tableau. C’est l’approche la plus répandue historiquement, simple à démarrer, mais la définition reste prisonnière de l’outil : elle ne sert à rien pour les autres usages (notebooks, applications, agents IA).
• Virtuel / headless (ou “universel”) : le Semantic Layer devient indépendant de tout outil de présentation. Défini une fois, il est exposé via des API (SQL, REST, GraphQL) à n’importe quel client : BI, Excel, Python, chatbot. C’est l’approche portée par dbt Semantic Layer, Cube ou AtScale.
• Héritage OLAP : les cubes multidimensionnels du monde BI traditionnel (SSAS, et une partie de l’héritage AtScale) répondaient déjà à ce besoin il y a vingt ans, avec une promesse de performance plutôt que de portabilité.

La tendance de fond va clairement vers l’approche headless : un Semantic Layer pensé comme une brique d’infrastructure, pas comme une fonctionnalité d’un outil de reporting.

Comment construire un Semantic Layer

• dbt Semantic Layer (MetricFlow) : les entités, dimensions et mesures sont définies en YAML, à côté des modèles dbt qui construisent déjà les tables. MetricFlow génère ensuite le SQL à la demande, quel que soit l’outil qui interroge la métrique.
• Cube : les modèles de données sont écrits en YAML ou JavaScript, puis exposés en API REST, GraphQL et SQL, avec un moteur de cache et de pré-agrégation pensé pour la performance à grande échelle.
• AtScale : héritage OLAP fort, connexion native à Excel et Power BI via MDX/DAX, gestion automatique des agrégats, et des investissements récents pour exposer le modèle sémantique aux agents IA.
• LookML (Looker) : natif à l’outil, très mature, mais non portable : la définition reste propriétaire de Looker.

Le choix dépend surtout d’un arbitrage : jusqu’où voulez-vous découpler vos définitions métier de vos outils de restitution ?

Outils et écosystème

• Semantic layers headless : dbt (MetricFlow), Cube, AtScale.
• BI avec semantic layer intégré : Looker (LookML), Power BI (modèle tabulaire), Tableau.
• Standards émergents : le protocole MCP (Model Context Protocol), qui commence à être utilisé pour exposer un Semantic Layer directement aux agents IA de façon standardisée.

Semantic Layer et Data Governance

Le Semantic Layer est un pilier de la Data Governance : c’est l’endroit où la définition métier d’une métrique devient un contrat, pas une opinion. Dans une architecture Data Mesh, il joue un rôle clé de médiation : chaque domaine reste propriétaire de ses données, mais s’engage sur des définitions partagées au niveau des métriques transverses (revenu, client, churn).

C’est en général l’Analytics Engineer qui porte la construction et la maintenance de cette couche, à la frontière entre l’ingénierie des données et les besoins métier.

Semantic Layer et agents IA autonomes

Le sujet a pris une nouvelle dimension avec la montée des agents IA capables de mener des investigations data en autonomie. Juliette Duizabo, Head of Data chez Photoroom, en a fait la démonstration lors du Hymaday Agentic Analytics (voir le replay) : chez Photoroom (3 personnes pour 140 collaborateurs), le Semantic Layer vit directement dans la codebase : versionné, testé en pre-push, en CI et en production, avec des alertes en cas d’anomalie. Ce n’est pas un détail technique : c’est ce qui permet à un agent IA de savoir exactement dans quelle table aller chercher avant de lancer, seul, une centaine de requêtes SQL pour répondre à une question complexe (“pourquoi l’ARR dérive-t-il ?”).

Sans cette fondation, l’automatisation agentique ne réduit pas les erreurs : elle les multiplie, à la vitesse d’un LLM. Chez Photoroom, un simple fichier glossary.md centralise les définitions et sert de référence à tous les agents et rapports générés. C’est la version la plus légère et la plus “code-native” du Semantic Layer, aux antipodes des plateformes dédiées, mais elle remplit exactement la même fonction : garantir que l’agent, comme l’humain, ne réinvente jamais la définition d’un “client actif” ou d’un “churn”.

Sur chaque dimension, les deux visions du Semantic Layer divergent nettement :

• Implémentation. L’approche traditionnelle s’appuie sur une plateforme dédiée (Cube, AtScale, dbt Semantic Layer) qui expose une API. Chez Photoroom, c’est un simple fichier dans la codebase (glossary.md), traité comme du code.
• Objectif principal. L’approche traditionnelle vise la cohérence entre outils BI pour des utilisateurs humains. Chez Photoroom, l’objectif devient une fondation de confiance pour des agents IA autonomes.
• Gouvernance. L’approche traditionnelle s’appuie sur un comité, un Data Steward, un catalogue de données. Chez Photoroom, la gouvernance passe par des tests automatisés : pre-push, CI, production, alertes.
• Bénéfice recherché. L’approche traditionnelle vise un seul chiffre partagé entre Tableau, Power BI et les notebooks. Chez Photoroom, il s’agit de sécuriser l’automatisation : sans cette fondation, les agents multiplient les erreurs au lieu de les réduire.

Créer des agents IA est devenu simple ; ce qui fait la différence, c’est que la donnée sous-jacente soit propre, testée et documentée. Le Semantic Layer n’est plus seulement un outil de cohérence BI : c’est la condition de sécurité de toute automatisation IA sur la donnée.

Cas d’usage concrets

• Cohérence multi-outils : la même définition de “revenu net” alimente un dashboard Tableau, un rapport Power BI et un notebook Python, sans un seul copier-coller de SQL.
• Self-service sans risque : les équipes métier interrogent la donnée en langage business (“montre-moi le churn par région”) sans écrire de requête, et sans pouvoir se tromper de définition.
• Agents IA fiables : un assistant IA interrogé sur “notre churn ce mois-ci” passe par le Semantic Layer plutôt que par une requête SQL générée à la volée : la réponse est gouvernée, pas hallucinée.
• Migration d’outil BI sans perte de mémoire : changer de Tableau à Power BI, ou l’inverse, sans redéfinir des dizaines de métriques métier au passage.