Chat with your Enterprise Data

Bonjour, je m'appelle Simon

Ravi d'être avec vous aujourd'hui. J'appelle depuis l'Allemagne, donc chez moi, c'est déjà presque la fin d'après-midi. De formation, je suis software engineer. J'ai beaucoup travaillé en Java, j'ai co-écrit « Java by Comparison » sur l'écriture de code maintenable, et j'ai passé trois ans dans une équipe de mob programming à distance : quatre ou cinq personnes en visio toute la journée, un seul écran partagé, le driver qui change toutes les dix minutes, et tout le monde sur la même chose en même temps. J'ai aussi fait beaucoup d'infrastructure avec Kubernetes et l'approche GitOps.

Puis il s'est passé une chose que je n'avais pas vue venir : j'ai changé de camp. Je suis passé du côté obscur, celui de la donnée. Il y a environ cinq ans. Honnêtement, à l'époque, il ne restait plus beaucoup d'innovation pour moi dans le monde du logiciel, alors que le monde de la donnée explosait, porté par la montée du Data Mesh, le concept forgé par Zhamak Dehghani. Avec mon co-auteur, nous avons construit datamesh-architecture.com comme référence, et nous avons traduit ensemble en allemand le livre Data Mesh d'O’Reilly. Le plus beau, c'est que la version allemande est imprimée en couleur. Nous nous sommes battus pour ça. Vous, les Américains, vous êtes un peu plus radins sur l'impression couleur, il faut bien le dire.

Grâce à mon doctorat en systèmes distribués, je n'ai jamais complètement quitté le monde académique, et je publie encore avec des chercheurs de King’s College London et de la HTW Berlin. Je siège au Technical Steering Committee du projet BITOL de la Linux Foundation, qui porte les standards ouverts autour des Data Contracts et des produits de données. Vous avez d'ailleurs eu ici, à Purdue, une intervention de Sean Perin, le président du TSC. Je co-maintiens des outils open source autour de ces standards. Et enfin, je suis co-founder d'Entropy Data, une marketplace de produits de données en SaaS. Nous sommes une petite startup, déjà rentable, sans VC, bootstrapée, et en croissance rapide. Voilà pour ma présentation.

Le livre blanc

Aujourd'hui, je veux vous parler de la façon de dialoguer avec les données de votre entreprise. Nous avons publié un livre blanc sur arXiv, arxiv.org/pdf/2601.08687, avec des chercheurs de King’s College London et de la Jheronimus Academy of Data Science (JADS) aux Pays-Bas. Vous y trouverez beaucoup plus de détails ; tout ce que je montre ici est également accessible depuis entropy-data.com/fr/recherche.

L'objectif, en une phrase

L'idée maîtresse est simple : nous voulons permettre à l'IA de répondre à n'importe quelle question métier tout en respectant les politiques de Data Governance.

Réfléchissez à ce que cela implique. Vous posez une question à l'IA, ou bien un agent la formule tout seul, et quelques instants plus tard, vous avez simplement la réponse. Avec la gouvernance appliquée, parce que les données peuvent être très sensibles : on n'a pas le droit de tout faire avec n'importe quel jeu de données. C'est ce dont je veux vous parler aujourd'hui.

Démo en direct : de la question à la réponse

Laissez-moi vous mettre l'eau à la bouche avec une démo. En arrière-plan, nous avons un système qui gère l'ensemble : une marketplace de produits de données. J'utilise Claude, relié au système par un connecteur MCP. Une fois tout branché, je peux simplement poser une question métier. Essayons : « Qui sont nos meilleurs clients ? »

Claude y voit un déclencheur et part automatiquement à la recherche de données pertinentes. Il lance une recherche sur « customers » et trouve un produit de données. Ce sont des métadonnées de très haut niveau. Il enchaîne donc avec un fetch pour obtenir tous les détails : structure, sémantique, qualité, et si nous avons ou non l'accès. Il lit tout cela, conclut que le produit de données convient, mais constate que nous n'avons pas l'accès. Il demande donc l'accès automatiquement, en extrayant de ma question une finalité précise.

Il reçoit « soumis pour validation, pas encore approuvé ». L'IA est un peu culottée : elle tente quand même d'exécuter une requête SQL, avec une finalité attachée, si bien que nous savons pourquoi chaque requête est lancée. Mais la demande est en attente, donc la requête échoue. Sur un second écran, j'approuve la demande d'accès en tant qu'owner. Claude retente, patiente quelques secondes le temps que le cluster serverless Databricks démarre, et les résultats arrivent.

De « Qui sont nos meilleurs clients ? » à une réponse gouvernée. Chaque étape tracée. Chaque requête porte un « pourquoi ». Voilà ce que veut dire dialoguer avec les données de son entreprise.

« Aujourd'hui, ce workflow est déclenché par moi, un humain, mais ce pourrait tout aussi bien être un agent autonome. Il n'y a aucune différence. Et beaucoup de ces agents arrivent. »

Deuxième exemple : « Quelles sont les principales causes de tickets de support ? » Même enchaînement, sauf que les tickets de support sont moins sensibles : l'accès est approuvé automatiquement. Recherche, fetch, demande, requête, réponse : zéro intervention humaine dans la boucle.

Et un dernier : « Exporte un CSV avec les adresses e-mail des clients pour une campagne e-mail luxe, uniquement les clients très fidèles. » Cette fois, la gouvernance entre en jeu. Les conditions d'utilisation du produit de données interdisent l'usage marketing. L'IA refuse. Avec un modèle plus ancien, j'arrivais parfois à la convaincre de passer outre : nous avons donc ajouté un second garde-fou dans le serveur MCP lui-même. Même si vous convainquez l'IA, le serveur bloque la requête en vol. Les limites de la gouvernance s'étendent aux agents, et c'est important, car un agent peut demander un accès pour une finalité puis essayer d'utiliser les données pour une autre. Ce n'est pas autorisé.

Retour sur les cas d'usage

Revenons aux slides. Qu'avons-nous vu ? Un accès aux données gouverné et audité, via l'IA.

• Nous trouvons le bon produit de données pour une question métier donnée.
• Nous demandons l'accès avec une finalité précise.
• Nous interrogeons les données de la bonne manière.
• Nous auditons le pourquoi de chaque requête SQL.
• Nous bloquons les requêtes SQL dont la finalité n'est pas couverte par la gouvernance.

Et tout cela automatiquement. C'est ce dernier mot qui compte : quand les agents débarqueront, sans automatisation, vous ne suivrez pas.

La vue d'ensemble

L'architecture est simple. Le monde agentique en haut (ChatGPT, Claude, Copilot). Les données réelles en bas (Postgres, Databricks, Snowflake). Et au milieu, un serveur MCP qui joue le rôle d'une fine couche de gouvernance, avec trois responsabilités :

• Découverte : trouver et évaluer les produits de données.
• Gouvernance : demander l'accès, vérifier les conditions d'utilisation du Data Contract, appliquer les politiques globales.
• Requête : exécuter le SQL derrière des garde-fous de sécurité.

Techniquement, construire cela aujourd'hui n'a rien de sorcier : Claude Code en écrit l'essentiel pour vous. La question intéressante, c'est pourquoi ça fonctionne aussi bien.

Deux raisons à ce succès

La première est évidente : les agents IA ne cessent de progresser. Vous avez vu la magie opérer : Claude a planifié ses étapes en arrière-plan, les a enchaînées, s'est remis de ses erreurs, et je n'ai eu à lui demander aucune de ces choses.

Mais la vraie réponse, ce sont de bonnes métadonnées. Sans elles, ma démo aurait été catastrophique. Passons en revue les facteurs de succès, c'est-à-dire les types de métadonnées qui font que tout cela fonctionne vraiment.

Facteur de succès n° 1 : les produits de données

La marketplace en arrière-plan proposait les données sous forme de produits de données. L'idée : vous ne déversez pas dans la marketplace toutes les tables de l'entreprise, mais uniquement les données que quelqu'un possède et veut partager comme un produit.

Cela produit deux effets. D'abord, cela réduit le contexte, et plus le contexte est réduit, mieux l'IA s'en sort. Ensuite, cela élève la qualité et l'ownership : avec une logique produit, vous construisez pour un consommateur, qu'il soit humain ou agent. Pour le format, nous utilisons l'Open Data Product Standard (ODPS) v1.0.0, qui donne aux métadonnées une structure prévisible.

Facteur de succès n° 2 : les Data Contracts

Un Data Contract définit l'ownership, la structure, la sémantique, la qualité et les conditions d'utilisation des données qui circulent entre un producteur et ses consommateurs. Pensez à une spécification OpenAPI, mais pour les données. Il est lisible par les humains, parfait pour l'outillage, et idéal pour l'IA : ce sont les meilleures métadonnées que vous puissiez attacher à un jeu de données, parce qu'on peut s'y fier comme source de vérité.

Sur datacontract.com, vous verrez à quoi cela ressemble concrètement. Un contrat est généralement un fichier YAML avec les fondamentaux (id, nom, version, statut), un schéma (tables, colonnes, types logiques et physiques, classifications comme PII), la qualité des données (par exemple order_status ∈ {pending, shipped, cancelled}, ou du SQL libre, tantôt en valeur absolue, tantôt en pourcentage, parce que le monde de la donnée est désordonné), l'ownership et les canaux Slack, les conditions d'utilisation (ce que vous avez le droit de faire ou non, par exemple pas de marketing), les SLA (rétention, fraîcheur, jamais plus de 24 heures), et enfin le serveur (Postgres, Databricks, Snowflake, S3, Iceberg… là où vivent réellement les données).

Le standard, ici, c'est ODCS v3.1.0. L'éditeur open source permet de rédiger un contrat via un formulaire, un diagramme ou directement en YAML. La Data Contract CLI, environ 800 étoiles sur GitHub, lit un contrat, se connecte à la source de données réelle et vérifie que chaque garantie tient. C'est cette vérification automatique qui rend le contrat assez fiable pour alimenter l'étape de découverte de l'IA.

Facteur de succès n° 3 : la sémantique

Pour faire des jointures entre tables, l'IA doit savoir si deux colonnes peuvent être jointes, c'est-à-dire si order_id dans une table signifie vraiment la même chose que order_id dans une autre. Surtout quand les jointures s'enchaînent sur plusieurs produits de données.

Pour cela, nous définissons la sémantique, sous forme de glossaire métier ou de graphe de connaissances. Order ID est défini une seule fois dans le domaine des ventes, et les Data Contracts pointent vers cette définition partagée. Même concept, même référence, même vérité partout. Avec une sémantique en place, l'IA écrit les bonnes jointures SQL sans avoir à deviner.

Facteur de succès n° 4 : les accords d'accès

Dans la démo, l'IA a demandé l'accès à ma place. En coulisses, elle a rempli un formulaire, mais l'essentiel est qu'au niveau du backend, nous savons toujours :

• Qui a accès à quelles données, et pourquoi.
• Quelles sont les conditions de cet accès : ce qui est permis et ce qui ne l'est pas.

C'est ce qui rend les contrôles de gouvernance effectifs, et ce qui permet tout simplement de construire un tel système.

Enfin un moteur pour de meilleures métadonnées

Avant l'IA, j'aurais donné raison à l'avocat du diable. Convaincre qui que ce soit d'investir du temps dans les métadonnées était difficile : les gens de la gouvernance venaient les réclamer, et la demande restait au fond du backlog pour l'éternité. Aujourd'hui, il existe une boucle de rétroaction qui n'existait pas avant :

Dialoguer avec les données de l'entreprise → évaluer les résultats → s'ils ne correspondent pas à ce que vous vouliez, améliorer les métadonnées → dialoguer à nouveau → de meilleurs résultats.

« Les gens sont égoïstes : ils n'investiront pas leur temps pour aider les autres, ni pour respecter une règle au nom de la règle. Mais dès qu'ils en tirent eux-mêmes un bénéfice, ils améliorent les métadonnées. »

C'est là toute la différence. Tous ceux qui voient cette démo disent : « C'est exactement ce que je veux. » Et le seul moyen d'y arriver, ce sont de meilleures métadonnées. Alors ils investiront.

Oui, l'IA est là pour nous

Trois endroits où l'IA aide déjà avec les métadonnées aujourd'hui :

• La création de métadonnées : rédiger et mettre à jour les contrats et les définitions de produits.
• Le monitoring des métadonnées : vérifier qu'elles respectent vos politiques.
• L'approbation des accès : la seule étape encore manuelle dans la démo.

La création de métadonnées

Vous n'avez plus besoin de saisir les métadonnées à la main. Demandez à l'IA de mettre à jour un Data Contract, de le faire passer de brouillon à actif, de compléter les classifications manquantes. Donnez-lui du contexte supplémentaire, votre Confluence, les données réelles, un autre système de référence, et elle produira des métadonnées bien meilleures qu'à partir du seul YAML.

Le monitoring des métadonnées

Vous ne voulez pas que vos métadonnées se dégradent, car dès qu'elles se dégradent, les résultats de votre IA se dégradent aussi. Vous les surveillez donc au regard de règles : qu'est-ce qu'un bon produit de données ? qu'est-ce qu'un bon Data Contract ? qu'autorisons-nous ?

Ce qui change, c'est que vous pouvez désormais exprimer ces règles en langage naturel. La Governance AI prend un produit de données et une politique, et renvoie un résultat de contrôle. En entrée, les politiques et les produits de données ; le modèle est un LLM ; en sortie, un ensemble de contrôles avec des retours que les utilisateurs peuvent signaler. Nous avons construit un prototype, et il fonctionne bien.

Le vrai gain : des non-experts peuvent maintenant définir ce qu'est un « bon » résultat. Les gens de la gouvernance sans bagage en programmation peuvent écrire des règles, surveiller le système et itérer. Oui, les hallucinations restent un problème : les utilisateurs peuvent signaler les faux positifs, mais il n'y a pas encore de bonne réponse pour les faux négatifs. Compromis assumé, approche puissante.

L'approbation des accès

Vous vous souvenez de la seule étape manuelle de la démo, où je devais aller dans le système et cliquer sur « approuver » ? Pourquoi l'IA ne pourrait-elle pas au moins nous aider là-dessus ? Nous l'avons donc fait aussi : la Data Governance AI confronte la demande d'accès aux politiques, puis soit la laisse passer, soit signale des violations précises (« Traitement de PII : la demande d'accès ne précise pas de finalité claire pour des données PII »), en laissant à l'owner le soin d'approuver ou de refuser en connaissance de cause.

Évalué par les pairs : l'IA dépasse les humains sur l'approbation des accès

Nous ne nous sommes pas contentés de le construire, nous l'avons évalué. Avec la HTW Berlin et King’s College London, et avec deux experts en gouvernance (Head of Data Governance dans le e-commerce et dans l'assurance), nous avons mené une étude acceptée à AIES 2025.

Les chiffres marquants :

• La Governance AI a émis 3,6 fois plus d'alertes que les experts humains, tout en relevant les mêmes points de conformité.
• 80 % des alertes générées par l'IA ont été jugées correctes après une seconde relecture.
• Les cas de test synthétiques générés par LLM ont bien simulé des scénarios de gouvernance réels.
• La supervision humaine reste nécessaire pour la justesse contextuelle et juridique.

En pratique : l'IA a été plus juste que les humains, parce qu'un humain ne peut pas garder toutes les règles en tête, alors que l'IA le peut. L'article complet est sur entropy-data.com/fr/recherche.

En résumé

Nous avons vu un accès aux données gouverné et audité via l'IA : trouver la bonne donnée pour une question, demander l'accès avec une finalité, interroger, auditer le pourquoi, bloquer les requêtes qui ne respectent pas les conditions, le tout automatiquement. C'est la capacité vers laquelle tout le monde doit tendre. MCP est le bon protocole pour la couche de gouvernance.

Soyez prêts

Oubliez tout le reste si vous voulez, mais retenez ceci : les agents arrivent, et vous ne serez prêts qu'avec de bonnes métadonnées et une gouvernance automatisée.

Préparez-vous.