Pourquoi les agents d’analyse par IA ont besoin d’une couche sémantique plutôt que de SQL brut
Le Text-to-SQL sur des tables brutes invente des métriques et ignore les règles d’accès. Une couche sémantique telle que Cube, servie via MCP, confère aux agents d’IA un sens métier contrôlé.
Sources: The Semantic Layer for AI Agents: How to Stop LLMs From Inventing Metrics
Permettre à un agent d’analyse basé sur l’IA d’écrire du SQL est le moyen le plus rapide d’obtenir une démonstration qui éblouit les gens. C’est aussi le moyen le plus rapide de créer des risques, si ce SQL est exécuté sur des tables brutes de entrepôt sans contexte métier. Ce n’est pas la syntaxe qui pose problème, c’est le sens.
Prenons le mot « revenus » et demandons-nous de quoi il s’agit :
- Brut ou net ?
- Les remboursements sont-ils déduits ?
- Quelle colonne de date détermine le trimestre ?
- « Client actif » signifie-t-il actif au moment de la commande, ou actif aujourd’hui ?
- Quelle correspondance régionale s’applique ?
- Quelle règle de conversion de devise ?
- Cet utilisateur a-t-il même le droit de voir les données de ce client ?
La conversion texte en SQL brut échoue précisément pour ces raisons. Le modèle peut générer du SQL valide, la base de données peut le exécuter sans problème, et le résultat peut néanmoins être incorrect. C’est pourquoi un agent d’analyse a besoin d’une couche sémantique entre lui et les données métier. Cube est un exemple bien conçu de ce type de couche, et il sert de cas d’étude dans ce texte.
Les schémas n’ont pas de signification
La conversion texte en SQL est une bonne idée : elle permet aux développeurs, aux analystes et aux utilisateurs métier d’avancer plus rapidement. Mais un schéma de entrepôt contient rarement la signification que l’on attend de lui.
Un tableau présente des colonnes telles que amount, status, created_at, customer_type, region_id et currency, mais personne dans l’entreprise ne formule ses questions de cette manière. Personne ne demande sum(amount) grouped by region_id where status = 'paid'. Ils demandent plutôt comment les revenus de l’entreprise ont évolué dans le sud de l’Inde au cours du dernier trimestre.
Ce seul paragraphe cache une série de décisions à prendre. Qu’est-ce que le chiffre d’affaires, et qu’est-ce qui fait d’une entreprise un client ? Quelle date marque le trimestre, et comment l’Inde du Sud est est-elle représentée ? Les remboursements et les commandes annulées sont-ils supprimés ? Quelle règle monétaire s’applique, et que peut voir la personne qui pose la question ? Un modèle peut faire des suppositions à ce sujet. Cependant, les suppositions ne constituent pas une gouvernance efficace. Si la réponse de l’agent diffère de celle affichée sur le tableau de bord, les gens cessent de lui faire confiance. S’il utilise la mauvaise table, les chiffres semblent crédibles mais sont erronés. S’il ignore les règles d’accès, la réponse devient une fuite de données.
La vraie question n’est donc pas de savoir si le modèle peut écrire du SQL. C’est plutôt de savoir s’il devrait inventer une logique métier du tout.
Quel est le rôle d’une couche sémantique
Une couche sémantique se situe entre les données brutes et ceux qui les consomment, transformant les structures techniques de base de données en concepts métier structurés. Elle définit des métriques, des mesures, des dimensions, des jointures, des segments, des hiérarchies, des règles d’accès, des règles de mise en cache, des pré-agrégations ainsi que les API utilisées pour les interroger, au lieu de mettre en évidence des tables et des colonnes.
Concrètement, orders.amount, customers.type, orders.created_at et refunds.amount deviennent Chiffre d’affaires, Client entreprise, Date de la commande et Chiffre d’affaires ajusté des remboursements. Les agents ont besoin de ce vocabulaire. Sans couche sémantique, un agent doit interpréter un schéma par lui-même ; avec une couche sémantique, il travaille à partir de définitions approuvées. L’agent n’est toujours pas parfait, mais une cause majeure d’hallucinations analytiques disparaît, car la définition des métriques n’a plus besoin d’être reconstituée à partir de tables brutes.
Il s’agit d’une catégorie plutôt que d’un produit unique. Cube, la couche sémantique dbt (construite sur MetricFlow) et LookML de Looker abordent chacun le même problème au sein de leurs propres écosystèmes. Cube attire l’attention ici car son approche pour les agents est exceptionnellement complète, bien que l’architecture compte plus que la marque.
Pourquoi Cube est un bon exemple
Cube n’est pas seulement une couche de tableau de bord. Un seul modèle géré alimente à la fois les outils de BI, les analyses intégrées, les API et les agents d’IA, construits à partir de cubes, de mesures, de dimensions, de jointures, de segments, d’hiérarchies, de pré-agrégations et de politiques d’accès. Ce sont là les éléments de base dont a besoin un agent d’analyse.
Sa propre description du design illustre bien cette idée : les agents ne consultent pas directement le entrepôt, ils consultent la couche sémantique, et le temps de exécution agit comme une barrière de protection entre l’agent et l’entrepôt.
Comparez ce que chacun fournit au modèle. Face à un tableau brut, il ne voit que les noms de colonnes et rien d’autre. Lorsqu’il dispose d’une couche sémantique, il reçoit également les concepts approuvés, le calcul sous-jacent à chacun d’eux, la manière dont ils sont liés, ce que l’utilisateur actuel peut modifier, ainsi qu’une méthode sûre pour effectuer des requêtes. Redécouvrir la logique métier à chaque question est coûteux ; par conséquent, l’agent devrait interroger une couche qui la contient déjà.
Connexion plus signification : où s’inscrit MCP
MCP est le moyen courant pour relier les assistants IA à des outils et des données externes, mais la connexion n’est pas synonyme de compréhension. Même si l’on donne à un agent un accès direct aux tableaux bruts du entrepôt via MCP, il doit encore deviner leur signification, ce qui constitue le problème initial dans ce nouveau cadre.
Un modèle plus robuste fait passer l’agent par la couche sémantique :
AI agent
→ MCP client
→ semantic-layer MCP server (e.g. Cube's)
→ semantic layer (governed metrics, dimensions, joins, policies)
→ data warehouse
MCP gère l’accès tandis que la couche sémantique s’occupe du sens. L’agent ne devrait pas demander à la base de données quels tableaux joindre pour calculer les revenus. Il devrait plutôt demander à la couche sémantique la métrique de revenus approuvée ainsi que les dimensions qu’il peut utiliser.
Deux réserves sont nécessaires pour rester honnête, car ce domaine évolue rapidement et il est facile d’exagérer. Le serveur officiel MCP de Cube, faisant partie de Cube Cloud et accessible via HTTPS avec OAuth, est différent des serveurs MCP communautaires pour Cube, tels que ceux distribués via Smithery. Leur niveau de confiance, leur support et leur maintenance diffèrent, et une utilisation en production exige la voie officielle et régulée. De plus, le support natif MCP est une nouveauté récente dans ce domaine, ajouté aux API REST, SQL et GraphQL que ces produits proposent depuis des années. Cela fonctionne, mais il s’agit d’une fonctionnalité propre à 2025-2026, il convient donc de la vérifier en fonction de la version que vous utilisez réellement.
Une architecture plus sûre de bout en bout
Lorsque tout est assemblé, le flux se présente comme ceci :
user question
→ AI analytics agent
→ MCP / tool call
→ semantic layer (approved metrics, dimensions, joins, segments, policies)
→ data warehouse
→ governed result
→ agent explanation
L’agent n’a pas de liberté totale sur les données brutes. Il dispose d’une interface contrôlée, ce qui permet à l’équipe de déterminer quels indicateurs existent, quelles dimensions sont valides, comment fonctionnent les jointures, quels filtres sont autorisés, qui peut voir quelles lignes, si les réponses proviennent du cache ou de données pré-agregées, et comment les requêtes sont exposées via des API. Cela vaut mieux que de demander à un modèle d’écrire du SQL en espérant que la logique métier soit correcte.
Exemple concret : croissance des revenus
Demander la croissance des revenus de l’entreprise au cours du dernier trimestre. Sans couche sémantique, l’agent doit déduire quelle table contient les revenus, s’il s’agit de revenus bruts, nets, enregistrés ou reconnus, si les remboursements doivent être exclus, comment les comptes d’entreprise sont identifiés, quelle colonne temporelle définit le dernier trimestre, si les devises doivent être converties, et si cet utilisateur peut consulter tous les segments. Le SQL peut bien s’exécuter, mais son exécution ne signifie pas pour autant qu’il soit correct.
Avec une couche sémantique, ces réponses existent déjà. Le chiffre d’affaires est une mesure approuvée, le client entreprise est un segment approuvé, la date de commande est une dimension temporelle approuvée ; la logique de remboursement est définie une seule fois et la politique d’accès s’applique en fonction de celui qui demande. L’agent ne crée pas de métrique, il demande une métrique approuvée. Cela distingue la génération de SQL en langage naturel de l’analyse agente gérée.
Quelles peuvent être les erreurs avec un accès brut au entrepôt
L’accès direct laisse trop de place à l’interprétation de l’agent, et les échecs sont prévisibles :
- Invention de métriques : le chiffre d’affaires est calculé différemment par rapport au tableau de bord financier.
- Jointures incorrectes : la requête s’exécute, mais une jointure duplique des lignes ou supprime des enregistrements.
- Filtres manquants : les commandes annulées, les comptes de test, les enregistrements supprimés ou les utilisateurs internes restent pris en compte.
- Fuite de permissions : une question légitime restitue des données provenant de clients, d’équipes ou de régions que la personne ne devrait pas voir.
- Logique obsolète : le schéma a changé, mais l’agent continue d’utiliser l’ancien modèle.
- Réponses fausses plausibles, dans le pire des cas, où des chiffres présentés comme fiables semblent raisonnables mais sont en réalité incorrects.
Les agents qui répondent à des questions métier ont besoin de mécanismes de contrôle plus stricts que ceux fournis par la génération de SQL. Ils ont besoin de contraintes sémantiques.
Conserver SQL sans exposer les tables brutes
Abandonner la flexibilité n’est pas le prix à payer pour la gouvernance. Une couche sémantique mature peut maintenir une porte d’accès SQL ouverte, orientée vers des objets gérés plutôt que vers des tables physiques. Dans l’API SQL de Cube, chaque cube ou vue ressemble à une table, et ses mesures, dimensions et segments ressemblent à des colonnes. Comme elle utilise le protocole et le dialecte Postgres, presque tout client compatible Postgres peut se connecter.
Les outils et les agents permettent de réaliser des requêtes de type SQL, mais le modèle détermine ce qui peut être consulté. L’agent ne parcourt pas de tables brutes ; il travaille avec des métriques et des dimensions approuvées, ce qui constitue un compromis pratique beaucoup plus proche de la manière dont les analyses en production devraient fonctionner.
Les règles d’accès sont aussi importantes que les métriques
Pour les agents conversationnels, le contrôle d’accès devient crucial, car une boîte de dialogue invite à des questions ouvertes. Quelqu’un tape « montrez-moi les revenus par client », et le système doit savoir quels clients cette personne peut consulter, quelle région ou locataire s’applique, ainsi que si des détails au niveau du client sont autorisés ou si seuls des agrégats doivent être affichés.
Cube applique des politiques d’accès et une sécurité au niveau des lignes au sein de la couche sémantique. Ce choix est délibéré : personne ne devrait compter sur un agent pour rappeler chaque règle sans sollicitation. Écrire « ne jamais révéler de données non autorisées » dans une instruction constitue une demande. Lorsque la couche restreint un utilisateur donné à certaines lignes, dimensions et mesures, il s’agit d’une mise en œuvre stricte. Cette mise en œuvre est bien plus efficace et se trouve dans la couche des données plutôt que dans l’instruction.
Le côté performance : mise en cache et agrégations préalables
Les analyses conversationnelles sont itératives. Une personne demande les revenus par région, puis les divise par produit, puis les compare au trimestre précédent, puis les limite aux clients entreprises. Si chaque étape devient une nouvelle requête complexe, la latence et les coûts augmentent rapidement.
Les pré-agrégations et le cache de Cube, gérés par son moteur CubeStore, accélèrent les requêtes analytiques courantes. Un résultat constaté a été une réduction d’environ la moitié des coûts de stockage après que les agrégations aient été stockées dans le CubeStore. Ainsi, pour les questions répétées, la couche sémantique agit à la fois comme couche de performance et comme couche de gouvernance.
Où ce modèle est particulièrement utile
Les agents qui répondent à des questions concernant les revenus, les segments de clients, l’utilisation des produits, les analyses destinées aux clients, les tableaux de bord opérationnels, les KPI ou les explications des métriques en tirent le plus grand bénéfice, tout comme tout scénario de BI en mode self-service.
Les avantages sont les plus importants lorsque des définitions récurrentes existent déjà. Définissez une fois les modèles ARR, MRR, revenus, taux de désabonnement, taux de rétention, utilisateurs actifs, taux de conversion, marge brute, temps de résolution des tickets et adoption des fonctionnalités, puis chaque agent les réutilise au lieu de les recalculer à chaque fois qu’une demande change.
Où les équipes doivent faire attention
Rien de tout cela n’est magique, et la gouvernance doit être réelle et non simplement un étiquetage. Un modèle incomplet rend l’agent incapable de fonctionner correctement. Des définitions de métriques erronées produisent des chiffres fiables mais incorrects. Des politiques d’accès trop larges exposent toujours inutilement les données. Un modèle rempli de métriques quasi identiques et confuses oblige l’agent à choisir la mauvaise. De plus, si la fraîcheur des données n’est pas visible, une réponse peut sembler à jour alors qu’elle repose sur des données obsolètes.
Ainsi, la question pertinente n’est pas de savoir s’il existe une couche sémantique, mais plutôt si cette couche est suffisamment bonne pour permettre à un agent de l’utiliser en toute sécurité. Le modèle doit être documenté, versionné, testé, soumis à un contrôle d’accès, compréhensible, en adéquation avec les tableaux de bord en which les gens ont déjà confiance, relié à des vérifications de qualité des données, et clair quant à sa fraîcheur et à ses limites. Une couche faible entraîne des réponses faibles de la part de l’agent.
De SQL brut à des analyses gérées
Ce qui différencie les approches, c’est ce que l’agent voit et ce qui peut être endommagé :
- Texte brut vers SQL : l’agent voit les tables et les colonnes du entrepôt, et le principal risque est une logique métier inventée.
- SQL accompagné de documentation du schéma : c’est une amélioration, mais les jointures et les métriques sont encore facilement mal utilisées.
- Seulement une couche sémantique : l’agent travaille avec des métriques, des dimensions, des relations et des politiques définies. C’est plus sûr, la qualité étant limitée par le modèle qui le sous-tend.
- Couche sémantique plus MCP : des analyses gérées mises à disposition sous forme d’outils pour l’agent, actuellement la solution la plus adaptée pour des analyses d’IA contrôlées.
Le texte brut vers SQL reste utile, mais pour les analyses métier, il devrait s’appuyer sur une sémantique gérée plutôt que sur des suppositions basées sur un schéma brut.
Une liste de contrôle avant que l’agent n’accède aux données métier
- Placer d’abord les métriques essentielles dans une couche sémantique.
- Préciser quelles dimensions et quelles jointures sont valides.
- Appliquer les politiques d’accès et les règles au niveau des lignes dans la couche.
- Fournir des API gérées à l’endroit où se trouvaient auparavant les tables brutes.
- Accéder à la couche via MCP uniquement à l’aide d’outils officiels approuvés.
- Conserver un journal de chaque requête de l’agent ainsi que du SQL qu’elle a généré.
- Fournir chaque réponse accompagnée de la définition de la métrique qui la sous-tend.
- Indiquer dans chaque réponse à quel point les données sont récentes.
- Réexécuter des questions métier familières et comparer les résultats avec des tableaux de bord fiables.
- Interdire l’accès direct aux tables sensibles du entrepôt.
- Décider de la procédure à suivre lorsque la métrique demandée n’a pas de définition.
- Apprendre à l’agent à répondre « non défini » plutôt que d’improviser.
- Versionner les définitions de métrique comme du code.
- Tester les règles d’accès avec des rôles d’utilisateurs réels.
- Faites attention aux requêtes qui échouent ou donnent des résultats ambigus.
La règle la plus importante : lorsque une métrique n’est pas définie, l’agent ne doit pas en inventer une. Il doit demander des précisions ou indiquer que la métrique n’est pas disponible.
Questions pour les équipes de produits
Avant de fournir à un nouvel agent d’analyse l’ensemble du schéma de votre entrepôt, prenez le temps de régler quelques points au préalable. Déterminez les questions métier auxquelles il doit répondre, les métriques approuvées, les dimensions valides ainsi que les jointures sûres à utiliser. Définissez également qui peut voir quoi, à quel point les données doivent être récentes, quelles réponses nécessitent une définition ou une citation, et quelles requêtes doivent être refusées. Ce n’est qu’alors que vous devriez exposer cette version simplifiée à l’agent.
Le cube est une façon de construire la surface, tandis que le dbt Semantic Layer, LookML et MetricFlow abordent le même problème sous d’autres angles. La leçon essentielle n’a rien à voir avec un produit en particulier : les agents ont besoin de sémantiques commerciales bien gérées avant de pouvoir traiter les données d’entreprise.
Le point clé
Considérer l’analyse par l’IA comme une simple tâche de transformation texte en SQL revient à manquer l’essentiel, car la gouvernance du sens constitue la partie la plus difficile. Un agent qui travaille sur des tables brutes peut écrire du SQL parfaitement valide et produire néanmoins des résultats erronés, grâce à des métriques inventées, à des jointures incorrectes, à des règles d’accès ignorées ou à des chiffres contraires à ceux affichés dans le tableau de bord. Une couche sémantique change l’interface : des métriques, des dimensions, des jointures, des politiques et des API approuvées remplacent un schéma brut à interpréter. MCP fournit la connexion, la couche sémantique fournit le sens, et les analyses gérées ont besoin des deux.
Lectures complémentaires
- Créer un agent de qualification des prospects avec IA en Python à l’aide de FastAPI et Pydantic — Transformer des prospects bruts en prospects qualifiés : extraction structurée par LLM, validation avec Pydantic, évaluation basée sur des règles, stockage dans PostgreSQL, files d’attente et voie de révision humaine.
- Comparaison des agents gérés : Anthropic, LangGraph et Google ADK — Qui gère le sandbox, les identifiants et les traces ? Une comparaison des agents gérés Anthropic, LangGraph et Google ADK, avec des informations sur les prix, les modes de défaillance et un guide de décision rapide.