Semantic layers : plus que jamais au cœur des usages IA

En février 2024, nous avons publié un guide complet sur les semantic layers. Il compte parmi les articles les plus lus du site. Depuis, le marché a beaucoup évolué : Snowflake, Databricks et dbt Labs ont placé la semantic layer au cœur de leur plateforme. Dans le même temps, les agents IA ont commencé à interroger les données à la place des équipes métier. Nous reprenons donc ce guide pour le compléter et le mettre à jour.

Nous constatons que les semantic layers sont plus que jamais d'actualité. En 2024, elles servaient surtout à harmoniser les KPI entre les outils de BI. En 2026, elles fournissent aussi le contexte métier dont un LLM a besoin pour répondre juste. Un agent qui ignore la définition exacte du chiffre d'affaires écrira une requête SQL valide et renverra un résultat faux.

Une semantic layer traduit les données techniques en langage métier

Une semantic layer (couche sémantique) traduit les tables d'un data warehouse en concepts métier : client, commande, chiffre d'affaires, taux de churn. Le data warehouse désigne l'entrepôt où l'entreprise centralise ses données analytiques. La semantic layer se place au-dessus de lui, entre les données transformées et les outils qui les consomment. Notre article de 2024 la définissait comme « une représentation business des données d'une entreprise, compréhensible par des équipes non-techniques ». Cette définition reste valable.

Concrètement, une semantic layer décrit trois types d'objets. Les métriques définissent les mesures calculées, par exemple un chiffre d'affaires net égal au montant facturé moins les remises. Les dimensions définissent les axes d'analyse, comme le pays ou le canal de vente. Les relations indiquent comment joindre les tables : une commande appartient à un client. Chaque objet porte aussi une description en langage naturel, des synonymes éventuels et un responsable.

Son premier usage consiste à harmoniser les définitions. Sans semantic layer, chaque outil recalcule ses propres KPI. Le chiffre d'affaires affiché dans Power BI diffère alors de celui du fichier Excel de la direction financière. Avec une semantic layer, l'équipe data écrit la formule une seule fois et chaque outil la réutilise. Si la règle change, elle la modifie à un seul endroit.

Elle centralise également les règles d'accès. L'équipe data définit une fois qui peut consulter quelles données. Les équipes métier gagnent ainsi en autonomie sans multiplier les risques d'exposition.

En 2024, une partie des semantic layers vivaient dans un outil de BI : LookML pour Looker, le modèle sémantique pour Power BI. Ce choix enfermait les définitions dans un seul outil et limitait son usage à un seul type de consommation. Depuis, elles migrent un cran plus haut, vers la Data Platform elle-même, notamment avec l'arrivée des agents IA.

Avec l'IA, la semantic layer devient la source de contexte des agents

Un agent IA est un programme qui utilise un LLM pour réaliser une tâche en plusieurs étapes. Pour l'analyse de données, il reçoit une question en langage naturel, la traduit en requête SQL, exécute cette requête puis commente le résultat. Les équipes métier peuvent ainsi interroger les données directement, sans attendre l'équipe data.

Le LLM ne voit pourtant que des noms de tables et de colonnes. Il ignore qu'une colonne amount inclut la TVA ou que les commandes de test doivent être exclues. Il produit donc une requête syntaxiquement correcte mais avec un risque de chiffre faux. La semantic layer comble ce manque en fournissant à l'agent les définitions validées plutôt que les tables brutes.

Plusieurs benchmarks publics mesurent ce gain. Ils comparent la précision d'un LLM qui lit le schéma seul à celle d'un LLM qui passe par une semantic layer.

Ces résultats appellent deux réserves. D'abord, dbt Labs et Cube vendent des semantic layers et publient leurs propres tests. Ensuite, les modèles progressent vite : dbt Labs note que le text-to-SQL a beaucoup gagné depuis 2023 sur un schéma simple. Pour autant, l'écart persiste dans chaque test.

Le marché parle désormais de context layer pour désigner l'ensemble du contexte transmis aux agents. DataHub la définit comme une extension de la semantic layer, enrichie du lignage, de la fraîcheur des données et des règles de gouvernance. Le lignage retrace l'origine d'une donnée et ses transformations successives. Dans tous les cas, la semantic layer reste le noyau de ce contexte. Les éditeurs l'ont bien compris et ont tous investi le sujet.

Les acteurs principaux : quatre familles de solutions

Le marché se répartit aujourd'hui en quatre familles. La première regroupe les semantic layers natives des Data Platforms, chez Snowflake et Databricks. La deuxième rattache la semantic layer à l'outil de transformation, avec dbt. La troisième la garde dans l'outil de BI, comme Power BI ou Looker. La dernière propose des solutions indépendantes, comme Cube ou AtScale.

La tendance la plus nette concerne les Data Platforms. Snowflake et Databricks stockent maintenant la semantic layer dans leur catalogue, à côté des données et des droits d'accès. Leurs agents, Cortex et Genie, la lisent directement pour répondre aux équipes métier.

Le risque d'enfermement chez un éditeur demeure. Pour le réduire, Snowflake, Salesforce, dbt Labs, BlackRock et RelationalAI ont lancé en septembre 2025 l'Open Semantic Interchange (OSI). Cette initiative open source vise une spécification commune pour décrire une semantic layer. Une quinzaine d'acteurs l'ont rejointe, dont Cube, Atlan, Hex, Sigma et ThoughtSpot. À terme, une métrique définie une fois pourrait ainsi circuler entre outils sans réécriture.

Le choix de l'outil compte cependant moins que la qualité des définitions qu'il contient.

Retour d'expérience : une migration dbt nécessaire pour la mise en place d'agents

Un de nos clients, une scale-up du e-commerce, a construit sa semantic layer à l'occasion d'une migration vers dbt. L'équipe a profité de la migration pour redéfinir chaque modèle et chaque métrique avec les équipes métier.

Cette rigueur visait une documentation qui réunit quatre qualités. D'abord, elle reste à jour : chaque modification du code entraîne celle de sa description. Ensuite, elle décrit fidèlement ce que le code calcule, ce qui la rend fiable. Elle est aussi complète, puisqu'elle couvre chaque modèle et chaque colonne exposés. Enfin, ses descriptions restent précises : au lieu d'un vague « montant de la commande », elles indiquent la devise, la TVA et les exclusions.

Aujourd'hui, ce client obtient d'excellents résultats avec ses agents IA. Les agents lisent les descriptions et les métriques validées au lieu de deviner le sens des colonnes. Les équipes métier posent leurs questions en langage naturel et obtiennent des chiffres cohérents avec leurs tableaux de bord.

Ce cas illustre un ROI différé. L'investissement dans la documentation a d'abord servi la migration et la BI. Il porte aujourd'hui des gains que personne n'avait chiffrés au départ. Encore faut-il que cette documentation reste à jour dans la durée, ce qui demande une méthode.

Construire sa semantic layer et la garder à jour

Une semantic layer perd sa valeur dès que sa documentation décroche du code. Sa construction compte donc autant que les contrôles qui la maintiennent dans la durée. Chez Modeo, nous recommandons six pratiques, de la plus simple à la plus outillée.

« Depuis six ans, la construction d'une semantic layer est devenue une nécessité pour l'ensemble de nos projets data. Cette couche est essentielle pour faire le pont entre les équipes data et les équipes métier. »

Matthieu Willot
COO de Modeo

Partir de quelques métriques critiques

Commencez par cinq à dix métriques liées à un usage précis, comme le pilotage commercial hebdomadaire. Validez chaque définition avec l'équipe métier concernée et nommez un responsable par métrique.

Écrire les définitions dans le code

Stockez les métriques et les descriptions dans des fichiers versionnés, à côté des modèles dbt. Databricks parle de « semantics as code ». Chaque modification passe alors par une revue, comme le reste du code.

Automatiser les contrôles en CI/CD

La CI/CD (intégration et déploiement continus) soumet chaque modification à des contrôles automatiques avant sa mise en production. Pour une semantic layer, ces contrôles vérifient trois points : les tests de données passent, chaque modèle exposé possède une description et chaque métrique se calcule sans erreur. Par exemple, le package dbt_project_evaluator signale les modèles sans documentation. Une règle simple consiste à bloquer la fusion du code tant que la documentation manque.

Suivre la complétude de la documentation

Mesurez le taux de modèles et de colonnes documentés, puis suivez-le dans un rituel régulier. Ce suivi rend visibles les zones d'ombre avant qu'un agent ne les rencontre. Il donne aussi un indicateur concret aux sponsors du projet.

Utiliser l'IA pour pré-remplir la documentation

Un LLM peut rédiger un premier jet de description à partir du code SQL et d'un échantillon de données. L'équipe data relit puis corrige ce brouillon. Ce fonctionnement réduit fortement le temps de documentation. La validation humaine reste cependant indispensable car une description fausse générée par une IA tromperait ensuite les agents.

Tester la semantic layer avec un jeu de questions

Constituez une liste de questions métier associées à leur réponse attendue. Relancez-la à chaque évolution de la semantic layer ou du modèle d'IA. Vous reproduisez ainsi, à votre échelle, les benchmarks cités plus haut et vous détectez les régressions avant vos utilisateurs.

Ces pratiques supposent un socle technique commun : la Data Platform.

La Data Platform, socle de la semantic layer et des usages IA

Une semantic layer vaut ce que valent les données qu'elle décrit. Une Data Platform désigne l'ensemble des briques qui collectent, stockent, transforment, gouvernent et exposent les données de l'entreprise. Sans elle, les définitions s'appuient sur des données dispersées, en retard ou non testées.

Chaque brique de la Data Platform conditionne la qualité des réponses d'un agent. L'ingestion garantit la fraîcheur des données. La transformation avec dbt produit des modèles testés et documentés. Le catalogue applique les droits d'accès, y compris aux agents. La semantic layer traduit enfin l'ensemble en langage métier pour la BI comme pour l'IA.

Les éditeurs suivent cette logique, puisque Snowflake et Databricks rapprochent la semantic layer du stockage et des droits. Un projet IA lancé sans Data Platform solide hérite donc de ses défauts. À l'inverse, une Data Platform bien construite réduit le coût de chaque nouvel usage IA et améliore son ROI.

La Data Platform constitue le cœur de métier de Modeo. Nous accompagnons aussi nos clients sur leurs usages IA : choix des cas d'usage, construction de la semantic layer, mise en place des agents et suivi de leur fiabilité. Notre accompagnement couvre ainsi toute la chaîne, de la donnée brute à la réponse fournie à l'équipe métier.

Omni + DBT : le combo gagnant pour construire sa Semantic Layer

Omni est une plateforme de business intelligence (BI), c'est-à-dire un outil d'exploration et de visualisation des données destiné aux équipes métier. Depuis début 2026, elle se connecte nativement au dbt Semantic Layer. Les définitions écrites une seule fois dans le projet dbt sont ainsi reprises automatiquement dans le modèle de données d'Omni (dbt Labs).

Concrètement, l'intégration traduit les objets dbt en objets Omni. Les métriques simples, ratios ou dérivées deviennent des mesures Omni, sans réécrire la logique de calcul. Les dimensions restent des dimensions. Les entités deviennent des relations, avec des jointures générées automatiquement. Enfin, les descriptions et les libellés des fichiers YAML s'affichent directement dans l'interface d'Omni.

Ce couplage supprime le risque de divergence entre l'outil de BI et la semantic layer. L'équipe data maintient une seule définition par métrique dans dbt. Les équipes métier consultent ensuite dans Omni les mêmes chiffres que ceux exposés aux agents IA. dbt Labs présente d'ailleurs cette intégration comme une mise en pratique de la spécification OSI citée plus haut. Pour autant, l'article de dbt Labs ne chiffre pas encore les gains obtenus.

Modeo est certifiée sur Omni Analytics. Quentin Renaud, Country Manager France & Espagne d'Omni Analytics, décrit notre accompagnement :

« Modeo maîtrise en profondeur les sujets de data platform et de data engineering. Certifiée sur Omni Analytics, son équipe est compétente et réactive. Elle sait aussi transmettre ses connaissances aux équipes métier, ce qui accélère l'adoption de l'outil. Nous recommandons Modeo aux entreprises qui veulent déployer Omni sur des bases solides. »

Quentin Renaud
Country Manager France & Espagne, Omni Analytics

Snowflake Semantic Views : une semantic layer stockée dans son DataWarehouse

Snowflake propose une autre approche avec les semantic views, qui stockent la semantic layer directement dans une base. Une semantic view est un objet de schéma, au même titre qu'une table ou une vue. Elle décrit les entités métier, leurs relations et les métriques. Snowflake la traite comme des métadonnées : elle ne copie aucune donnée.

Une semantic view assemble cinq types d'objets.

L'équipe data dispose de plusieurs façons de créer une semantic view. Elle peut l'écrire en SQL avec CREATE SEMANTIC VIEW ou la décrire dans un fichier YAML. Elle peut aussi partir de Semantic View Autopilot, un assistant IA intégré à Snowsight. Cet assistant importe notamment un fichier Tableau ou Power BI existant, ce qui accélère la reprise d'un modèle déjà en place.

Les agents IA de Snowflake exploitent directement ces définitions. Un Cortex Agent reçoit la semantic view comme un outil : il lit ses définitions puis génère le SQL sur les tables physiques. Les applications passent par l'API REST de Cortex Analyst. Les outils de BI et les requêtes SELECT classiques s'appuient sur les mêmes métriques. Enfin, une semantic view se partage via les listings du Snowflake Marketplace.

Le principal gain tient à la proximité avec les données : la définition vit dans l'entrepôt, sans outil supplémentaire à opérer. En revanche, elle lie la semantic layer à Snowflake. Une entreprise qui utilise plusieurs plateformes, ou qui maintient déjà ses métriques dans dbt, gardera plutôt dbt comme source unique. La spécification OSI vise justement à rendre ces définitions portables d'un outil à l'autre.

Notre recommandation : auditer la documentation avant de lancer un agent

Avant de déployer un agent IA, mesurez l'état de votre documentation. Listez les dix métriques les plus utilisées par vos équipes métier et vérifiez que chacune possède une définition unique et un responsable. Calculez ensuite le taux de documentation de vos modèles exposés. Ces deux indicateurs suffisent à estimer l'effort nécessaire.

Si vous préparez une migration, profitez-en pour reconstruire votre semantic layer, comme notre client l'a fait avec dbt. Le surcoût reste limité pendant la migration, alors que les gains se mesurent ensuite sur chaque usage IA. Pour cadrer cette démarche, l'équipe Modeo réalise un diagnostic de votre Data Platform et de votre maturité sur les usages IA.

Sources

• Modeo, Guide complet : Semantic Layer (couche sémantique), février 2024
• Databricks, Semantic Layer Architecture: Components, Design Patterns, and AI Integration, mars 2026
• DataHub, Context Layer vs Semantic Layer: What the Debate Gets Right and What It Misses, avril 2026
• FullStack, Semantic layers for AI agents: Architecture, benefits, and implementation, octobre 2026
• Axel Schwanke, Semantic Layers: The Missing Link Between AI and Business Insight, Medium, 2025
• Sequeda, Allemang et Jacob (data.world), A Benchmark to Understand the Role of Knowledge Graphs on LLM's Accuracy for Question Answering on Enterprise SQL Databases, arXiv, novembre 2023
• dbt Labs, Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, avril 2026
• Cube, Why semantic layers make LLM analytics reliable: a paired benchmark across three frontier models, avril 2026
• Snowflake, Open Semantic Interchange (communiqué), septembre 2025
• Snowflake, Overview of semantic views, documentation
• Databricks, Unity Catalog semantics, documentation
• Microsoft, Prepare your data for AI to improve Copilot results, documentation
• Google Cloud, Conversational Analytics in Looker overview, documentation