Semantic layer et IA : comment un agent consomme une couche sémantique gouvernée

Un agent IA branché sur un entrepôt ne manque pas de données. Il manque de contexte. Il doit déduire de noms de tables et de clés étrangères ce que votre entreprise appelle un client actif ou une marge. Quand il se trompe, il ne le signale pas : il produit un nombre plausible.

• Le contexte pèse plus que la puissance du modèle. Un benchmark apparié publié en avril 2026 sur arXiv mesure un gain de 17 à 23 points d’exactitude quand le modèle reçoit une documentation sémantique de 4 Ko, à p < 0,01.
• Le protocole d’accès ne gouverne rien par lui-même. MCP (Model Context Protocol) permet de découvrir des mesures et de les demander par leur nom. Sa spécification reconnaît ne pas pouvoir imposer ses principes de sécurité.
• La fiabilité se prouve. Un jeu de questions de référence, un taux de fausse certitude et un rejeu à chaque changement de définition valent mieux qu’une promesse d’éditeur.

Une couche sémantique (semantic layer) traduit les objets techniques de l’entrepôt en concepts métier gouvernés : mesures, dimensions et relations, définis une fois et réutilisés partout, source unique de vérité (single source of truth) des définitions, détaillée dans ce qu’est une couche sémantique. Cette page traite d’autre chose : comment un agent y accède, comment on l’empêche de répondre au-delà de ses droits, et comment on le démontre par la mesure.

Contexte technique et contexte métier : ce que l’IA ne voit pas

Ce qu’un schéma de base de données dit, et ce qu’il ne dit pas

Un schéma est honnête mais muet. Il déclare une table orders, une colonne amount, une clé étrangère vers customers. Il ne dit pas laquelle des colonnes « revenue » porte le chiffre d’affaires net officiel, ni que les commandes annulées doivent être exclues, ni quelles jointures sont autorisées.

« Quels ont été nos produits les plus performants au dernier trimestre ? » Trois ambiguïtés qu’aucun schéma ne lève.

• Performant. Chiffre d’affaires, marge brute, volume, taux de réachat ?
• Dernier trimestre. Calendaire ou fiscal ? Un exercice démarrant en avril change le classement.
• Produits. Référence, gamme, famille, marque ?

Un agent sans contexte les tranche en silence, de la façon la plus probable dans son corpus d’entraînement, et produit un tableau propre, ordonné et faux.

Le benchmark apparié publié sur arXiv le 28 avril 2026 par Michael Rumiantsau et Ivan Fokeev chiffre cet écart : 45,5 % à 50,5 % d’exactitude sans documentation sémantique, 67,7 % à 68,7 % avec un document de 4 Ko. La sémantique ne rend pas le modèle plus intelligent, elle change la tâche : sélectionner un objet défini au lieu de deviner une intention. Méthode dans l’article de référence sur arXiv.

Le contexte métier est une donnée gouvernée, pas un prompt

Empiler les explications dans le prompt système fonctionne une semaine. Puis la définition du chiffre d’affaires net évolue, le prompt reste, et personne ne sait plus ce qu’il contient. Un prompt n’a ni propriétaire, ni version, ni test. Une définition métier, si.

Il y a aussi une raison mécanique. Anthropic documente deux coûts distincts dans « Code execution with MCP », publié le 4 novembre 2025 : le chargement des outils, qui fait traiter des centaines de milliers de tokens (unités de texte facturées par les modèles) avant la moindre requête, et les résultats intermédiaires, qui transitent deux fois par la fenêtre de contexte. Traiter la donnée dans un bac à sable de code fait passer un enchaînement Google Drive vers Salesforce de 150 000 tokens à 2 000, soit 98,7 % d’économie.

Une couche sémantique agit sur les deux fronts : un catalogue restreint de mesures nommées au lieu du schéma complet, un calcul exécuté hors du modèle. Gartner a chiffré l’enjeu le 11 mai 2026 : d’ici 2027, les organisations qui priorisent la sémantique dans leurs données prêtes pour l’IA augmenteront la précision de leur IA agentique jusqu’à 80 % et réduiront leurs coûts jusqu’à 60 %. Ce contexte doit vivre là où vivent déjà les définitions : le glossaire métier et le catalogue de données (data catalog).

Comment un agent accède à la couche sémantique

Le protocole MCP en pratique : découvrir, sélectionner, exécuter

MCP a été publié en open source par Anthropic le 25 novembre 2024, puis confié en décembre 2025 à l’Agentic AI Foundation, fonds de la Linux Foundation. Des messages JSON-RPC 2.0 et trois rôles : l’hôte pilote le modèle, le client est le connecteur embarqué, le serveur fournit le contexte. Version en vigueur, 2026-07-28, sur le site officiel du protocole.

L’interrogation devient une boucle en trois temps, au lieu d’une génération de SQL en un coup.

• 1. Découvrir. L’agent demande les mesures disponibles, puis les dimensions compatibles, puis les valeurs d’une dimension : un catalogue, pas un schéma physique.
• 2. Sélectionner. Il compose une requête déclarative : mesure, dimensions, filtre, granularité. Il n’écrit pas de jointure et n’invente pas de colonne.
• 3. Exécuter. Le serveur compile, applique les politiques, exécute et renvoie le résultat avec le SQL compilé.

Le serveur MCP de dbt en donne un exemple public : liste des mesures, SQL compilé récupérable sans exécution, lignage et santé des modèles. Dans son Market Guide for Agentic Analytics de février 2026, Gartner prévoit néanmoins que d’ici 2028, 60 % des projets d’analytique agentique fondés sur MCP seul échoueront faute de couche sémantique cohérente.

Ce que le serveur expose, et ce qu’il ne doit jamais exposer

Un serveur MCP bien réglé publie un périmètre, pas une base de données. La frontière se décide à la configuration, ligne par ligne.

Ce que le serveur expose	Ce qu’il ne doit jamais exposer
Les mesures et dimensions certifiées, décrites en clair	Le schéma physique complet
Les valeurs autorisées d’une dimension	Les identifiants de personnes, sauf droit explicite
Le SQL compilé, pour vérification	Un SQL libre contournant le modèle
Le lignage et la fraîcheur des sources	Les objets dépréciés sans signalement
Le statut de certification et le propriétaire	Les données hors périmètre de droits

La spécification MCP exige un consentement explicite de l’utilisateur à tout accès aux données, mais ne peut l’imposer au niveau du protocole. Dans Cube, la sécurité au niveau des lignes (row-level security) repose sur des politiques adossées aux attributs utilisateur, et le comportement par défaut documenté reste permissif : toutes les lignes sont publiques tant qu’aucune politique n’est configurée. Brancher un serveur MCP sur un entrepôt ne crée aucune garantie : la gouvernance est un travail à faire, pas une propriété héritée.

Récupérer une définition n’est pas récupérer un document : sémantique et RAG

Verser les définitions de métriques dans un dispositif de RAG (Retrieval-Augmented Generation, génération augmentée par récupération) documentaire est une erreur de catégorie. Né en 2020 avec l’article de Lewis et ses coauteurs, le RAG interroge un index dense de documents : la recherche vectorielle compare des embeddings (vecteurs de représentation), qui encodent le sens approximatif d’un passage. Elle retrouve ce qu’on a dit d’un sujet, quand le modèle sémantique calcule ce qui est vrai.

Critère	RAG documentaire	Couche sémantique
Objet récupéré	Un passage de texte	Une définition exécutable et son résultat
Pertinence	Proximité approximative	Correspondance exacte à un objet certifié
Nature de la réponse	Reformulation d’un contenu existant	Valeur calculée à l’instant T
Fraîcheur	Celle du document indexé	Celle des tables sources, vérifiable
Mode d’échec	Extrait périmé, présenté avec assurance	Refus explicite hors périmètre
Vérifiabilité	Lien vers le document source	Définition, version, SQL compilé, lignage
Usage adapté	Politiques, procédures, contexte qualitatif	Chiffres, agrégats, comparaisons

Les deux dispositifs sont complémentaires à condition de router : une question qui appelle un nombre part vers la sémantique, une explication vers le corpus documentaire. Sur la pile de contexte, voir notre analyse des métadonnées, sémantique et ontologie.

Ancrer les réponses pour réduire l’hallucination

L’ancrage (grounding) rattache chaque élément d’une réponse à un objet vérifiable : définition, requête, source. Son premier apport n’est pas d’augmenter le taux de bonnes réponses, c’est de rendre les mauvaises détectables.

Trois erreurs typiques : mauvaise métrique, mauvais périmètre, mauvaise jointure

Les défaillances sur données structurées se rangent dans trois familles. Aucune ne ressemble à l’hallucination spectaculaire dont parle la presse : toutes produisent un résultat crédible.

Erreur	Ce que voit l’utilisateur	Ce que la sémantique impose
Mauvaise métrique. Colonne homonyme	Un chiffre proche du bon, contredisant le tableau de bord	Une mesure nommée, certifiée, avec un propriétaire
Mauvais périmètre. Annulations, tests internes ou trimestre fiscal oubliés	Un total supérieur au réel, jamais remis en cause	Des filtres attachés à la définition, un calendrier fiscal déclaré
Mauvaise jointure. Grain ignoré, lignes dupliquées	Un chiffre d’affaires multiplié par les lignes de commande	Des relations déclarées avec leur cardinalité

Rendre une réponse traçable jusqu’à sa définition et son lignage

Le rejeu 2026 du benchmark ACME Insurance par dbt Labs compare le text-to-SQL direct (génération de SQL à partir d’une question en langage naturel) et la couche sémantique : onze questions, vingt répétitions par question et par configuration, quinze tables.

L’exactitude globale du text-to-SQL passe de 32,7 % à 64,5 % entre les deux millésimes, celle de la voie sémantique de 60,5 % à 72,7 %. Sur les seules questions couvertes par le modèle, et pour le moteur le plus performant, le text-to-SQL passe de 26,9 % à 62,5 % et la voie sémantique de 83,1 % à 100 %.

Premier enseignement, le constat qualitatif compte davantage. Quand elle ne peut pas répondre, la couche sémantique renvoie une erreur, là où le text-to-SQL renvoie une réponse fausse mais plausible. Réserve d’usage : mesure d’éditeur sur son propre produit. Second enseignement : élever le niveau de raisonnement n’améliore pas la précision, déjà proche du plafond, mais fait passer la latence de huit à plus de vingt secondes.

Une réponse traçable transporte, à côté de sa valeur, la définition mobilisée et son statut, sa version, le SQL compilé récupérable sans exécution, les tables sources et leur fraîcheur, le périmètre de droits appliqué et le chemin de lignage jusqu’à la source.

Ce dernier point transforme une conversation en pièce auditable : quand un contrôleur de gestion conteste un chiffre, la discussion se termine en trois clics. C’est le rôle du lignage des données, qu’un serveur MCP sérieux expose au même titre que les mesures.

Ontologies et graphes de connaissances : du vocabulaire au raisonnement

Quand une taxonomie suffit, quand il faut un graphe

Trois niveaux d’organisation du sens se confondent souvent.

• Le glossaire métier fixe le vocabulaire : un terme, une définition, un propriétaire. Il règle les désaccords de langage.
• La taxonomie ajoute la hiérarchie : famille, gamme, référence. Elle règle les questions d’agrégation.
• L’ontologie ajoute les relations typées et les contraintes : un produit ne se vend que dans les pays où il est homologué. Elle règle les questions de raisonnement.

Le graphe de connaissances est cette ontologie peuplée. Pour la plupart des analyses chiffrées, mesures, dimensions et relations déclarées suffisent. Le graphe devient utile quand les questions cessent d’être des agrégations pour devenir des enchaînements.

Le travail fondateur reste celui de Juan Sequeda, Dean Allemang et Bryon Jacob, publié en novembre 2023 : sur un schéma d’assurance d’entreprise, un modèle de l’époque interrogeant la base SQL en zero-shot atteignait 16 % d’exactitude, contre 54 % sur un graphe de connaissances. Ce résultat date d’une génération de modèles antérieure, et l’affirmation selon laquelle la sémantique rendrait l’IA « trois fois plus précise » n’en est que la reprise.

Le raisonnement multi-sauts, ce que le graphe donne à l’agent

Une question multi-sauts exige de traverser plusieurs relations. « Quelle est notre exposition au risque de change sur les contrats signés par des filiales hors zone euro et arrivant à échéance dans les six mois ? » Le chemin passe par le contrat, la filiale signataire, l’entité juridique, sa devise de facturation et l’échéancier. Sans structure, l’agent devine les clés de jointure d’après les noms de colonnes ; avec un graphe, il les parcourt.

Gartner le résume dans son Market Guide for Agentic Analytics : ontologies, couches sémantiques et graphes de connaissances fournissent ensemble le contexte permettant aux agents de produire des analyses fiables. Trois briques, pas une.

Évaluer la fiabilité d’un agent adossé à la sémantique

Ce chantier décide du passage en production, et presque personne ne le mène. Un agent d’analyse est non déterministe, et son échec le plus dangereux est silencieux : il faut un protocole, pas une démonstration.

Construire un jeu de questions de référence

Le corpus s’écrit par les métiers, pas par l’équipe data. Un premier domaine se couvre avec quelques dizaines de questions, en cinq catégories.

• Questions dans le périmètre. Réponse chiffrée connue et validée : elles mesurent l’exactitude nominale.
• Questions hors périmètre. Données non modélisées : la bonne réponse est un refus explicite.
• Questions ambiguës. « Nos meilleurs clients », sans critère : la bonne réponse est une demande de précision, ou l’hypothèse retenue affichée.
• Questions pièges. Grain de jointure, année fiscale, devise, consolidation, homonymie : elles révèlent les erreurs structurelles.
• Questions sensibles. Données auxquelles l’utilisateur de test n’a pas droit : refus ou résultat filtré, jamais de fuite.

Chaque question porte une réponse attendue en trois parties : la valeur, la mesure qui aurait dû être choisie et les dimensions attendues. Sans les deux dernières, une bonne réponse obtenue par hasard passe pour une réussite.

Ce qu’on instrumente : bonne réponse, bonne source, refus légitime

Huit indicateurs suffisent à décider d’une mise en production.

Indicateur	Ce qu’il mesure	Pourquoi il compte
Exactitude de la valeur	Chiffres conformes à la référence	Le score visible, nécessaire mais insuffisant
Exactitude de la sélection	Réponses mobilisant la bonne mesure et les bonnes dimensions	Détecte les bonnes réponses par mauvais chemin
Taux de refus légitime	Questions hors périmètre correctement refusées	La maturité du système
Taux de fausse certitude	Réponses fausses délivrées sans réserve	Le risque réel, à surveiller d’abord
Traçabilité	Réponses livrées avec leur définition et leur SQL	Conditionne l’auditabilité
Respect des droits	Réponses dépassant le périmètre de l’utilisateur de test	Tolérance zéro, un cas bloque la production
Couverture	Questions métier dans le périmètre modélisé	Pilote la feuille de route
Latence et coût en tokens	Temps de réponse et consommation par question	Décide de l’usage quotidien

Détecter les régressions quand une définition change

Une définition de marge évolue, un filtre est ajouté, une dimension est renommée. Chaque changement est légitime, et chacun peut casser silencieusement des dizaines de réponses. D’où l’approche metrics-as-code (définitions versionnées comme du code) : dépôt, revue de chaque modification, rejeu du jeu de questions avant publication. Deux signaux d’alerte méritent d’être câblés.

• Une réponse de référence change alors qu’aucune définition n’a bougé. Le problème vient des données ou du modèle, pas de la sémantique.
• Une définition change et aucune réponse ne bouge. Soit la modification est sans effet, soit elle n’est pas appliquée à l’exécution.

Ajoutez un seuil de publication explicite : en deçà d’un taux d’exactitude fixé, ou au premier manquement sur les questions sensibles, la version ne part pas en production.

Gouverner le contexte fourni aux modèles

Qui écrit une définition, qui la valide, qui la publie

Trois couches sont régulièrement confondues : le modèle sémantique (entités, relations, dimensions), les définitions de métriques (formules et règles) et la gouvernance (qui décide, qui valide, qui a le droit de voir). Elles cohabitent dans le même outil sans partager ni responsables ni rythmes.

Le circuit minimal tient en quatre temps. Un expert métier propose la définition, seul à connaître la règle réelle. Un data steward la met en forme et la relie aux objets techniques. Un propriétaire de domaine la valide et engage sa responsabilité. Un mécanisme de publication la rend visible aux agents avec un statut explicite : proposée, certifiée, dépréciée. Un agent qui ignore ce statut utilisera une mesure dépréciée.

Ce circuit est un contrat : le producteur s’engage sur une définition stable et sur la fraîcheur, le consommateur, humain ou agent, à ne pas la contourner par une requête maison. Personne n’écrit d’ailleurs une couche sémantique à la main : on la dérive de l’existant, puis on la soumet aux métiers, alignement décrit dans notre article sur un langage commun entre métiers et data.

Un agent ne doit jamais répondre au-delà des droits de son utilisateur

Deux architectures s’opposent. Le post-filtrage exécute une requête large, rapatrie le résultat, puis retire ce que l’utilisateur n’a pas le droit de voir : les données interdites ont déjà traversé la fenêtre de contexte et les journaux. La gouvernance à la compilation injecte au contraire les règles dans la requête au moment où elle est générée : la sécurité au niveau des lignes restreint les enregistrements visibles selon les attributs de l’utilisateur, celle au niveau des colonnes masque les champs sensibles. Rien d’interdit n’est extrait. C’est le seul schéma compatible avec le principe de minimisation du RGPD.

Deux exigences en découlent. L’identité de l’utilisateur final doit être propagée jusqu’au moteur : un compte de service ayant tous les droits annule le dispositif. Et les politiques doivent être en refus par défaut.

Côté conformité, l’article 12 du règlement (UE) 2024/1689, l’AI Act, impose l’enregistrement automatique des événements pour les systèmes à haut risque : les journaux d’un agent d’analyse sont des pièces réglementaires potentielles. Les obligations de transparence de l’article 50 s’appliquent depuis le 2 août 2026, celles de l’annexe III ont été reportées au 2 décembre 2027 par le règlement dit Digital Omnibus. Ce report n’est pas une dispense.

Versionner le contexte et suivre les dérives

Versionner le contexte, c’est pouvoir dire quelle définition du chiffre d’affaires net l’agent a utilisée le 14 mars. Quatre pratiques y suffisent : dépôt versionné, revue avant fusion, tests automatiques par définition, horodatage de la version mobilisée dans chaque réponse. Des pratiques de développement logiciel, absentes d’une BI où une définition se modifie d’un clic.

La portabilité progresse aussi. Open Semantic Interchange, lancée le 23 septembre 2025 par Snowflake, Salesforce, dbt Labs, BlackRock et RelationalAI, a publié sa spécification v1.0 fin janvier 2026 sous licence Apache 2.0 : un modèle neutre pour jeux de données, métriques, dimensions et relations. Depuis juin 2026, elle est incubée à l’Apache Software Foundation sous le nom Apache Ossie. Objectif : faire passer les métriques d’un système à l’autre sans les réécrire.

Quatre signaux de dérive méritent enfin d’être instrumentés : définitions orphelines, synonymes contradictoires, métriques certifiées que personne n’interroge, hausse du taux de refus qui signale des questions hors du périmètre modélisé.

De la BI à l’IA : ce qui change dans le modèle sémantique

Synonymes, périmètre par domaine et signaux de confiance

Le terme « modèle sémantique » désigne d’abord un objet de business intelligence (informatique décisionnelle) : Microsoft a renommé le contenu Power BI « dataset » en « semantic model » en novembre 2023, sans changement technique. La sémantique était là, au service d’un humain qui clique. Ce qui change avec un agent tient à six différences.

Dimension	Pour la BI et le libre-service humain	Pour un agent IA
Mode de sélection	L’humain choisit dans une liste visible	La machine interprète une formulation libre
Vocabulaire	Un libellé par mesure suffit	Synonymes, formulations alternatives, exemples
Périmètre	Un catalogue large convient	Un périmètre restreint par domaine
Confiance	Implicite, portée par le rapport certifié	Explicite, lisible par la machine : certifiée, dépréciée, en validation
Rythme	Quelques requêtes par session	Volume machine : la latence et le coût en tokens deviennent contraignants
Gestion de l’échec	L’humain voit qu’il manque une mesure	Refus explicite plutôt qu’improvisation

Les implémentations récentes intègrent ces exigences : vues sémantiques de Snowflake interrogeables en SQL standard depuis mars 2026, metric views d’Unity Catalog chez Databricks en avril 2026, en YAML et portant des synonymes.

Faut-il réutiliser le modèle sémantique existant

Oui comme point de départ, non tel quel. Un modèle Power BI ou un projet LookML constituent un capital considérable : la logique de calcul y est déjà arbitrée. Mais un modèle conçu pour la restitution humaine est rarement prêt pour un agent. Six vérifications mesurent l’écart.

• Descriptions. Chaque mesure porte-t-elle une description en clair, ou un nom technique abrégé ?
• Synonymes. Les formulations employées par les métiers sont-elles rattachées aux objets ?
• Grain. Les relations sont-elles déclarées avec leur cardinalité, pour interdire une jointure dupliquante ?
• Exposition. Le modèle est-il accessible par une API ou un serveur MCP, ou seulement depuis l’outil de restitution ?
• Droits. Les politiques s’appliquent-elles à la compilation sur tous les canaux, ou seulement dans l’outil de reporting ?
• Versionnage. Les définitions sont-elles versionnées et testées, ou modifiables sans trace ?

Les trois dernières sont généralement celles qui manquent. Elles relèvent de l’architecture d’accès et de la gouvernance, pas de la modélisation.

Par quel cas d’usage commencer

Cinq critères désignent le premier cas d’usage (use case) : définitions stables, métriques peu nombreuses mais disputées, sponsor métier qui tranchera, données amont de qualité acceptable, questions récurrentes antérieures au projet. Ce dernier critère est le plus discriminant : si personne ne posait ces questions avant, personne ne les posera à un agent.

Six cas d’usage fréquents, situés en valeur et en faisabilité

Les six situations qui reviennent le plus souvent ne se valent ni en valeur ni en effort de mise en place.

Cas d’usage	Ce que fait l’agent	Valeur	Faisabilité
Libre-service (self-service) sur un domaine	Répond aux questions chiffrées récurrentes	Élevée, il absorbe les demandes ad hoc	Élevée, l’usage natif de la couche sémantique
Réconciliation d’un écart entre rapports	Compare les définitions, expose SQL compilé et lignage	Moyenne à élevée, fin des réunions de contestation	Élevée si le lignage est exposé
Explication d’une variation	Décompose l’évolution par dimension	Élevée, le travail d’analyse le plus répétitif	Moyenne, dimensions modélisées et grain contrôlé
Préparation de revue d’activité	Assemble des mesures certifiées, versionnées et datées	Moyenne, gain de temps, périmètre figé	Élevée, requêtes sauvegardées et statuts suffisent
Questions sur les définitions elles-mêmes	Explique un terme, qui en répond, quelles règles s’appliquent	Moyenne, forte valeur pour les arrivants	Élevée, glossaire et RAG documentaire suffisent
Analyse multi-sauts sur graphe	Traverse contrats, entités juridiques, devises et échéanciers	Élevée sur le risque et la conformité	Faible, suppose une ontologie et un graphe peuplé

Commencez par les lignes à faisabilité élevée, gardez la dernière pour un second temps : meilleure valeur unitaire, coût de mise en place le plus lourd.

L’ordre de mise en œuvre

Cinq étapes limitent le risque.

• 1. Cadrer par les questions. Collecter les questions réellement posées au domaine, en extraire les mesures et dimensions à modéliser. Ce corpus servira de jeu d’évaluation.
• 2. Modéliser et certifier. Dériver les définitions de l’existant, les faire valider par le propriétaire du domaine, les publier avec leur statut.
• 3. Exposer avec les droits. Brancher le serveur MCP sur ce périmètre restreint, propager l’identité de l’utilisateur, vérifier que les politiques s’appliquent à la compilation.
• 4. Évaluer avant d’ouvrir. Rejouer le jeu de questions, mesurer exactitude, refus légitimes et fausse certitude, fixer le seuil de publication.
• 5. Ouvrir à un cercle restreint, puis élargir. Instrumenter les questions posées, celles qui tombent hors périmètre désignent le domaine suivant.

Deux anti-modèles : commencer par le domaine le plus complexe, la difficulté prouvera la lenteur, pas la valeur ; brancher un agent sur l’entrepôt entier dès le premier jour, surface ingérable et évaluation impossible. Pour visualiser une métrique définie une fois et réutilisée partout, voir cet exemple concret de couche sémantique.

Reste l’endroit où vivent ces définitions. Un moteur exécute des calculs, il ne porte ni responsabilité métier ni traçabilité de bout en bout. C’est le rôle du référentiel de contexte : un glossaire métier collaboratif où les définitions sont écrites, validées et versionnées par ceux qui en répondent, adossé à un catalogue de données qui les relie aux objets techniques, avec le lignage au niveau colonne pour remonter à la source d’un champ contesté.

Gouvernance des données et gouvernance de l’IA cessent alors d’être deux chantiers parallèles : définitions, droits, lignage, journaux et évaluation forment un seul dispositif, celui qui permet de gouverner données et IA dans un cadre unifié.

Points clés à retenir

• Routez la question avant de la traiter. Un nombre part vers la couche sémantique, une explication vers le corpus documentaire. Le routage est lui-même un point d’évaluation.
• Mesurez par répétition, pas par démonstration. Vingt exécutions par question dans le protocole dbt Labs. Sans répétition, une réponse juste obtenue par hasard compte comme une réussite.
• Les droits s’appliquent à la compilation, jamais après coup. Filtres de lignes et de colonnes injectés dans la requête, identité de l’utilisateur propagée jusqu’au moteur, politiques en refus par défaut.
• Traitez les définitions comme du code. Dépôt versionné, revue avant fusion, rejeu automatique du jeu de questions, seuil de publication fixé à l’avance plutôt qu’arbitré sous pression.
• Les journaux sont des pièces réglementaires. L’article 12 de l’AI Act impose l’enregistrement automatique des événements pour les systèmes à haut risque. Le report de l’annexe III au 2 décembre 2027 ne dispense pas de concevoir la traçabilité dès la construction.
• Un chiffre isolé ne prouve rien. Le rapport de 16 % à 54 % souvent cité vient d’un seul benchmark de 2023, et les mesures les plus favorables sont publiées par des éditeurs. Rejouez le protocole sur vos propres données.

Un agent fiable n’est pas un agent plus intelligent. C’est un agent à qui l’on a donné, sous une forme gouvernée, ce que votre entreprise sait déjà.

À propos de l'auteur: Max Faivre

Product Marketing Manager

Partager sur les réseaux

X (Twitter)LinkedInFacebook