Couche sémantique et MCP : faire parler ses données sans exposer l'entreprise
Une couche sémantique et un serveur MCP permettent d'interroger l'entrepôt en langage naturel sans contourner les droits ni inventer de chiffres.
Les assistants d'IA savent désormais répondre à une question posée en français sur des données d'entreprise. La tentation est grande de les brancher directement sur l'entrepôt. C'est précisément ce qu'il ne faut pas faire. Il existe une façon plus sûre d'obtenir le même résultat.
Pourquoi laisser un modèle écrire du SQL librement est dangereux
Un modèle de langage (LLM, pour Large Language Model) qui reçoit la question « quelle est la marge du site Nord ce trimestre ? » et un accès direct à la base va produire une requête SQL plausible. Plausible, pas juste. Trois problèmes reviennent systématiquement sur le terrain.
Les jointures inventées. Le modèle voit des tables aux noms proches et les relie sans connaître les clés réelles. Une commande rapprochée du mauvais fournisseur, une pièce reliée au mauvais lot : le chiffre sort, il a l'air propre, il est faux.
Les définitions divergentes. « Marge », « stock disponible », « taux de rebut » n'ont pas la même définition en finance, en production et en supply. Si le modèle choisit sa propre formule à chaque fois, deux personnes obtiennent deux réponses différentes. La confiance s'effondre.
Les droits contournés. Un assistant connecté avec un compte technique voit tout. Un chef d'équipe qui demande les salaires de son atelier obtiendra une réponse. C'est un incident au regard du RGPD (Règlement général sur la protection des données), et un risque industriel si l'entrepôt contient des paramètres de procédé.
La couche sémantique : définir une fois, réutiliser partout
La réponse n'est pas d'interdire l'IA. C'est de lui donner un vocabulaire fermé et vérifié. C'est le rôle de la couche sémantique.
Concrètement, une couche sémantique est un ensemble de définitions maintenues par les équipes data avec les métiers : chaque indicateur (marge, disponibilité machine, coût de la non-qualité) est décrit une seule fois, avec sa formule, sa maille, ses filtres autorisés et son propriétaire. Les tables physiques disparaissent derrière des vues sémantiques : des objets qui exposent « chiffre d'affaires par site et par mois », et non « la table des factures jointe à la table des sites ».
Les entrepôts modernes comme Snowflake et les outils de transformation comme dbt proposent ce mécanisme. En contexte industriel, c'est aussi là que l'on réconcilie les référentiels : le numéro d'équipement de la GMAO (gestion de la maintenance assistée par ordinateur) et celui de l'historien de données capteurs.
L'assistant ne compose plus de requêtes à partir de tables brutes. Il choisit un indicateur, des dimensions, une période. Il ne peut pas inventer de jointure : il n'y en a plus à inventer.
Le serveur MCP : une passerelle outillée, pas un tuyau ouvert
Reste à relier l'assistant à cette couche. C'est là qu'intervient MCP (Model Context Protocol), un protocole ouvert qui permet à un assistant d'appeler des outils décrits de façon standard. Il est pris en charge par les principaux assistants du marché, qu'ils reposent sur Claude, GPT ou Mistral.
Un serveur MCP placé devant l'entrepôt expose un petit nombre d'outils explicites : « lister les indicateurs disponibles », « décrire un indicateur », « interroger un indicateur avec des dimensions et une période ». L'assistant ne voit pas de SQL. Il voit un catalogue et des fonctions.
Cette passerelle a trois qualités. Elle est restrictive par construction : ce qui n'est pas exposé n'existe pas pour le modèle. Elle est testable : chaque outil est du code versionné et couvert par des tests. Elle est remplaçable : changer d'éditeur d'IA ne remet pas en cause la couche de sécurité, puisque le protocole est ouvert.
Exécuter avec l'identité de l'utilisateur
Le point décisif est celui-ci : le serveur MCP ne doit jamais interroger l'entrepôt avec un compte technique omniscient. Il transmet l'identité de la personne qui pose la question, et l'entrepôt applique ses règles habituelles.
Le contrôle d'accès par rôle (RBAC, Role-Based Access Control) décide quels indicateurs et quelles vues sont accessibles. Un contrôleur de gestion voit les coûts, un chef d'atelier voit les cadences, personne ne voit ce qui ne le concerne pas.
Le masquage dynamique remplace les colonnes sensibles (identifiants personnels, salaires, tarifs négociés) par une valeur neutre pour ceux qui n'y ont pas droit, sans casser la requête.
Les politiques de lignes filtrent automatiquement : un responsable de site n'obtient que les lignes de son site, même s'il demande « tous les sites ».
Ces mécanismes existent déjà dans un entrepôt bien gouverné. L'IA en hérite. C'est le sens de la conviction qui guide ce blog : la gouvernance ne freine pas l'IA, c'est ce qui permet de lui dire oui.
Tracer chaque question
Chaque appel passé par le serveur MCP est journalisé : qui a demandé quoi, quel outil a été appelé, quel indicateur, quelle période, quel résultat. Cette traçabilité répond à la question du délégué à la protection des données (« qui a accédé à ces données, et pourquoi ? »), permet de repérer des usages anormaux et montre quels indicateurs méritent d'être enrichis. L'AI Act européen, qui impose transparence et traçabilité selon le niveau de risque, rend cette pratique d'autant plus utile.
Le parcours d'une question de contrôle de gestion
Suivons une demande banale : « Quel est l'écart entre le coût réel et le coût standard sur la ligne d'assemblage 3 en août ? ».
- Le contrôleur pose la question dans son assistant.
- L'assistant interroge le serveur MCP pour connaître les indicateurs disponibles et repère « écart coût réel / standard », défini par la finance.
- Il appelle l'outil d'interrogation avec la dimension « ligne de production », la valeur « ligne 3 » et la période « août ».
- Le serveur MCP transmet la requête avec l'identité du contrôleur. L'entrepôt applique le RBAC : uniquement les lignes de son périmètre.
- Le résultat revient avec la définition de l'indicateur et sa date de mise à jour. L'assistant répond en français et cite la source.
- L'appel est journalisé.
Le contrôleur obtient en une minute ce qui demandait un extrait et un tableur. Et le chiffre est celui du reporting officiel, parce que c'est la même définition.
Ce que cela change pour les métiers
Pour les directions métiers, la question n'est plus « peut-on faire confiance à l'IA ? » mais « nos indicateurs sont-ils définis et documentés ? ». La couche sémantique rend ce travail visible et rentable : chaque indicateur bien défini devient interrogeable par tous, en langage naturel, dans le respect des droits.
Pour la DSI, l'approche évite le débat stérile entre tout ouvrir et tout fermer : le périmètre est contrôlé, auditable, indépendant de l'éditeur choisi.
Pour les équipes data, elle transforme un risque en levier : la gouvernance déjà en place devient l'infrastructure de l'IA.
À retenir
- Laisser un modèle écrire du SQL librement produit des jointures inventées, des définitions divergentes et des droits contournés.
- La couche sémantique définit chaque indicateur une seule fois et cache les tables brutes derrière des vues métier.
- Le serveur MCP est une passerelle outillée, restrictive par construction, testable et indépendante de l'éditeur.
- L'exécution doit toujours porter l'identité de l'utilisateur : RBAC, masquage, politiques de lignes.
- La journalisation de chaque appel sert la conformité (RGPD, AI Act), la sécurité et l'amélioration continue.
Checklist
- Les indicateurs clés sont définis une fois, avec formule, maille et propriétaire.
- Les vues sémantiques exposent des notions métier, jamais des tables brutes.
- Le serveur MCP n'expose que des outils explicites, versionnés et testés.
- Aucun compte technique omniscient : chaque requête porte l'identité de l'utilisateur.
- Le RBAC, le masquage et les politiques de lignes sont actifs dans l'entrepôt.
- Chaque appel est journalisé et consultable par le délégué à la protection des données.