Aller au contenu principal

Conférence · data2day 2026

Agentic Analytics: From Hype to Real Value

Fabian Biberger (Founding Engineer, Entropy Data) ·

La conférence de Fabian Biberger à data2day 2026 à Cologne, donnée en allemand sous le titre Agentic Analytics: Wie aus Hype echter Mehrwert wird. Elle retrace le parcours d’Entropy Data : d’un serveur MCP à un chatbot gouverné, le contexte dont un agent a besoin pour travailler de façon fiable sur les données, et Apache Ossie pour les ontologies et les modèles sémantiques.

Diapositive de titre : Agentic Analytics, Wie aus Hype echter Mehrwert wird, Fabian Biberger, data2day, 07.10.2026, à côté d’une capture du chatbot Entropy Data qui recommande le produit de données Orders

Un résumé remanié de la conférence, traduit de l’allemand.

TL;DR

Les cinq points clés et enseignements de la conférence.

  1. La gouvernance décide de l’adoption. Le serveur MCP a impressionné, mais les clients ne pouvaient pas l’utiliser : il rassemblait les données sur un poste personnel, hors gouvernance, et beaucoup d’entreprises n’avaient aucun client de chat validé. L’enseignement : placer l’agent dans la marketplace gouvernée, d’où le chatbot propre à Entropy Data.

  2. Décider sous quelle identité s’exécute la requête. Avec un seul compte de service, Databricks ne voit qu’un utilisateur et le journal d’audit ne montre plus qui a accédé à quoi. En transmettant chaque identité via OIDC, la plateforme vérifie de nouveau chaque accès individuellement.

  3. Le contexte rend les agents fiables. La conférence cite sept facteurs : des données de qualité silver, un modèle de données documenté, la structure de l’entreprise, le data lineage, des données d’exemple, des modèles sémantiques et des ontologies. Commencez par les bases, puis ajoutez les accélérateurs.

  4. La sémantique comble le manque. Les Data Contracts, les tests de contrat, le data lineage et les équipes couvrent déjà cinq facteurs, mais les modèles sémantiques et les ontologies restaient en suspens. Apache Ossie ancre l’ontologie dans les modèles sémantiques, et ce lien permet à l’agent de construire de meilleures requêtes.

  5. Les agents ont besoin d’une identité et d’une finalité. Les agents autonomes agissent soit au nom d’un utilisateur, soit comme un service doté de sa propre identité. Vient ensuite le Purpose-based Access : la finalité indiquée est vérifiée par rapport aux conditions d’utilisation du Data Contract et à la sémantique.

Point de départ, ce que nous faisons chez Entropy Data : une marketplace de produits de données (Data Contracts, multi-plateforme, self-service), des standards de métadonnées ouverts (métadonnées portables, synchronisation des métadonnées vers Git, outillage open source, ODCS, ODPS, Apache Ossie) et de l’automatisation (tests de contrat automatisés, scoring de la qualité des données, gouvernance assistée par IA, Data Contract CLI)

Le point de départ d’Entropy Data

  • Une marketplace de produits de données avec des Data Contracts, multi-plateforme et en self-service.
  • Des standards ouverts : ODCS, ODPS et Apache Ossie.
  • De l’automatisation : tests de contrat avec la Data Contract CLI, scoring de la qualité des données, gouvernance assistée par IA.
Motivation : 01 améliorer la recherche dans la marketplace de données, 02 permettre une IA analytique gouvernée, 03 créer un bac à sable pour de nouveaux produits de données, 04 permettre un développement de produits de données assisté par agents

Quatre raisons de passer à l’agentique

  1. Une meilleure recherche dans la marketplace de données.
  2. Une IA analytique gouvernée.
  3. Un bac à sable pour de nouveaux produits de données.
  4. Un développement de produits de données assisté par agents.
MCP : un client IA avec une question ou une tâche d’agent appelle Entropy Data, qui propose des outils MCP comme Search, Fetch et Execute Query derrière une couche de Data Governance, reliée à la marketplace (métadonnées des produits de données) et à la plateforme de données (les données elles-mêmes). Divers outils, avec prise en charge des contrôles de gouvernance et des demandes d’accès

Première étape : un serveur MCP

  • Les clients IA comme Claude ou ChatGPT se connectent à la marketplace via MCP.
  • Des outils : chercher des produits de données, récupérer des Data Contracts, exécuter des requêtes.
  • Les contrôles de gouvernance et les demandes d’accès s’intercalent.
Bulle de dialogue sur une capture de chat floue : Superbe. Mais nous ne pourrons jamais l’utiliser.

« Superbe. Mais nous ne pourrons jamais l’utiliser. »

  • Gouvernance : MCP rassemble les données sur un poste personnel, hors gouvernance.
  • Disponibilité : beaucoup d’entreprises n’ont aucun client de chat validé, ou seulement Copilot.
  • Décision : construire notre propre chatbot.
Nous construisons un chatbot : le chat Entropy Intelligence, dans la marketplace Entropy Data, indique quel produit de données utiliser pour le comportement d’achat des clients et recommande Orders. Un panneau latéral montre l’avancement, la finalité, la gouvernance, le produit de données, la sémantique, le modèle de données, la connexion et le SQL

Nous avons donc construit un chatbot

  • Entropy Intelligence vit dans la marketplace, sous la gouvernance existante.
  • Le system prompt s’ajuste aux cas d’usage d’Entropy Data.
  • Les outils MCP sont intégrés directement, et la gouvernance ne peut pas être contournée.
Interface utilisateur, maîtrise de l’interface : un panneau latéral avec le produit de données Customers et ses quatre Output Ports avec contrats, et douze concepts sémantiques comme Order, Order ID, Customer ID, Customer Email et Billing Address
Le chatbot répond à « donne-moi accès à customers » : il recommande le port Databricks sans PII en se fondant sur les AI instructions du Data Product Owner, signale que l’utilisateur n’a pas encore accès et affiche un bouton Request Access avec la mention que l’accès a été accordé

« Neue Features lassen sich einfach kommunizieren » : en maîtrisant l’interface, les nouvelles fonctionnalités se communiquent facilement.

Interface utilisateur

  • Une meilleure traçabilité grâce au panneau de contexte : produit de données, Output Ports, concepts sémantiques et finalité d’un coup d’œil.
  • De nouvelles fonctionnalités intégrées directement, par exemple un bouton Request Access au cœur de la conversation.
  • Des éléments d’interface réutilisés, comme les puces et les icônes de la marketplace, aident les utilisateurs à se repérer.
Connexion à la plateforme de données, un compte par organisation : JD (marketing), Turk (contrôle de gestion), Elliot (ventes) et Carla (data engineering) passent tous par Entropy Data et un seul compte de service entropy-data vers Databricks, qui ne voit qu’un utilisateur. Le journal d’audit affiche entropy-data SELECT orders, customers, revenue

Qui interroge réellement les données ?

  • Un seul compte de service pour toute l’organisation.
  • Databricks ne voit qu’un seul utilisateur : entropy-data.
  • Le journal d’audit ne montre plus qui a accédé à quoi.
Un compte par utilisateur avec OIDC : les quatre mêmes utilisateurs passent par Entropy Data, qui récupère leur identité auprès d’un fournisseur d’identité comme Entra ID, et chacun se connecte à Databricks avec ses propres identifiants. Databricks voit et contrôle chaque utilisateur individuellement. Le journal d’audit affiche jd, turk, elliot et carla
  • OIDC : le fournisseur d’identité, par exemple Entra ID, transmet chaque identité à la plateforme.
  • Databricks vérifie chaque accès individuellement, et le journal d’audit redevient exploitable.
  • Principe : décidez d’abord sous quelle identité s’exécute l’accès aux données.
Le bon contexte : de quoi un agent a-t-il besoin pour travailler avec succès sur les données ?
Le bon contexte : sept facteurs alimentent la performance de l’analytique IA (fiabilité, qualité, cohérence) : ontologies, modèles sémantiques (métriques et dimensions), modèle de données documenté, structure de l’entreprise, data lineage, données d’exemple et données de qualité silver au minimum

Le bon contexte : sept facteurs

  • Les bases : des données de qualité silver au minimum et un modèle de données documenté.
  • Les accélérateurs : structure de l’entreprise, data lineage et données d’exemple.
  • La sémantique : modèles sémantiques (métriques, dimensions) et ontologies (concepts partagés).
Les sept mêmes facteurs, maintenant avec les standards et les outils qui les couvrent : ODCS pour le modèle de données documenté, la Data Contract CLI pour la qualité silver, OpenLineage pour le data lineage, Entropy Data pour la structure de l’entreprise et les données d’exemple. Les ontologies et les modèles sémantiques portent des points d’interrogation

Cinq couverts, deux en suspens

  • Modèle de données et qualité silver : couverts par les Data Contracts et les tests de contrat.
  • Data lineage via les liens entre produits de données et OpenLineage, données d’exemple en partie dans les Data Contracts, structure de l’entreprise sous forme d’équipes et de domaines.
  • Encore en suspens : les modèles sémantiques et les ontologies.
Le bon contexte : comment représenter les ontologies et les modèles sémantiques pour les agents ?
Apache Ossie (incubating), le standard universel pour les données sémantiques : un effort de spécification à l’échelle du secteur pour normaliser l’échange des métadonnées sémantiques entre plateformes d’analyse, d’IA et de BI, anciennement connu sous le nom d’Open Semantic Interchange. 100 % neutre vis-à-vis des éditeurs, configuration YAML, Apache 2.0, AI ready

Apache Ossie

  • Anciennement Open Semantic Interchange (OSI), aujourd’hui Apache Ossie.
  • Un projet Apache en incubation pour les modèles sémantiques et les ontologies.
  • Entropy Data le prend en charge comme format pour la sémantique.
Ontologie et modèle sémantique : l’ontologie couvre les concepts métier, les relations et les règles, le modèle sémantique couvre les dimensions, les métriques et les agrégations
Ontologie, concepts et relations : un graphe avec Order, Line Item, Article, Product, Shipment, Shipping Address, Billing Address, Postal Address et B2B Customer, reliés par des relations comme places, contains, ships_to, bills_to, fulfilled_by, references, has_variant, is a et subsidiary_of

Ontologie et modèle sémantique

  • Ontologie : des concepts comme Order, avec leurs propriétés.
  • Les relations portent du sens : une commande ships to une adresse de livraison.
  • Plus de sens, c’est plus de contexte pour l’agent.
Modèles sémantiques, métriques, dimensions, agrégations : les modèles sémantiques de dbt, Power BI, Tableau, Looker et d’autres alimentent un modèle sémantique unique
  • Modèle sémantique : métriques, dimensions et agrégations sur les données.
  • Connu de dbt MetricFlow, Power BI, Tableau et Looker.
  • La logique de calcul, comme la valeur de commande, est définie en un seul endroit.
Mapping d’ontologie : les concepts métier sont ancrés dans la couche sémantique par un mapping de l’ontologie vers le modèle sémantique
  • Ossie ancre l’ontologie dans les modèles sémantiques.
  • Une couche de mapping relie chaque concept à l’endroit où il apparaît.
  • Avec ce lien, l’agent construit de meilleures requêtes.
Le bon contexte, au complet : les sept facteurs sont désormais couverts, avec Apache Ossie pour les ontologies et les modèles sémantiques

Par où commencer

  • Commencez par les bases : un modèle de données documenté et des données de qualité silver.
  • La structure de l’entreprise, le data lineage et les données d’exemple viennent en renfort.
  • Les modèles sémantiques et les ontologies apportent de meilleurs résultats et plus de traçabilité.
Identité de l’agent : on behalf of the user, l’identité vient du contexte de l’utilisateur et l’agent agit en son nom. Agent as a service : l’agent reçoit sa propre identité, et des métadonnées supplémentaires sont nécessaires

Les agents arrivent

  • Les agents autonomes ont aussi besoin d’une identité.
  • On behalf of the user : l’identité vient de l’utilisateur, comme dans le chatbot aujourd’hui.
  • Agent as a service : une identité propre, plus des métadonnées comme l’opérateur.
Perspective, purpose-based access : un analyste ou un agent demande l’accès. Le purpose-based access control demande pourquoi, dans quelle finalité. L’agent indique comme finalité le marketing direct. Le PBAC compare la finalité déclarée aux conditions d’utilisation du Data Contract et à la sémantique, et n’accorde l’accès aux données qu’ensuite

Perspective : le Purpose-based Access

  • Les analystes et les agents doivent indiquer pourquoi ils ont besoin des données.
  • La finalité est vérifiée par rapport aux conditions d’utilisation du Data Contract et à la sémantique.
  • Une idée venue des questions du public : limiter l’accès dans le temps, par exemple à la session de l’agent.
Merci ! Des questions ? Passez à notre stand, nous vous montrons tout en direct avec plaisir. Écrivez à fabian.biberger@entropy-data.com. Essayez Entropy Intelligence : lancez la démo en 1 clic sur www.entropy-data.com

À vous d’essayer

Articles associés

A Data Marketplace is What Your Agent Needs

Pourquoi les agents IA ont besoin d’une marketplace de données, pour lire les données via des outils gouvernés et pour construire de nouveaux produits de données, avec deux démos en direct.

Qu’est-ce qu’Apache Ossie ?

Le standard ouvert pour les ontologies et les modèles sémantiques, anciennement connu sous le nom d’Open Semantic Interchange.

Qu’est-ce que le Purpose-based Access Control ?

Les agents IA décident à l’exécution des données dont ils ont besoin. Le Purpose-based Access Control vérifie chaque requête par rapport aux conditions d’utilisation du Data Contract.