A Data Marketplace is What Your Agent Needs

L'intervenant

Simon Harrer est un ingénieur logiciel dans l'âme, arrivé dans le monde de la data il y a environ cinq ans avec l'essor du Data Mesh. Il est coauteur de « Java by Comparison » (qui, note-t-il avec un sourire, fait aujourd'hui partie des données d'entraînement de plusieurs grands modèles de langage), il a traduit « Data Mesh » de Zhamak Dehghani en allemand et il est l'auteur du site Data Mesh Architecture.

Il maintient la Data Contract CLI open source et siège au Technical Steering Committee qui pilote l'Open Data Contract Standard.

Au quotidien, il travaille chez Entropy Data, l'entreprise qu'il a fondée avec Jochen Christ et qui fêtait son premier anniversaire la semaine de la conférence. Six personnes, des clients dans huit pays, aucun fonds de VC et beaucoup de tokens.

Le spoiler, tout de suite

Toute la conférence en une phrase : les agents ont besoin de marketplaces de données pour deux choses, lire les données et construire des produits de données.

Tout ce qui suit sert à défendre cette affirmation, avec deux démos en direct qui montrent chaque moitié à l'œuvre. D'abord lire, ensuite construire.

C'est quoi, un agent ?

Posez la question à dix personnes et vous aurez dix réponses. Celle de Simon, imparfaite mais bien pratique : un agent est un LLM qui utilise des outils dans une boucle. Vous branchez un modèle, vous lui donnez une tâche et vous le laissez tourner en boucle : il appelle des outils, observe les résultats, en appelle d'autres, jusqu'à ce qu'il estime avoir terminé.

Cet agent peut tourner sur votre laptop ou dans le cloud. Il peut être déclenché par un humain, par un autre agent, par un événement ou par un battement qui se répète en permanence. Peu importe le déclencheur, la boucle reste la même.

Et la boucle, c'est un problème résolu : les frameworks vous la donnent gratuitement. Les modèles sont devenus une commodité (chère, mais une commodité). C'est sur les outils que vous faites la différence. Ce sont eux qui permettent à un agent de lire, d'écrire, de gérer son état et de toucher au monde extérieur. Tout ce qui est intéressant se passe là.

La méthode naïve : tout donner à l'agent

Prenons une tâche toute simple : « Qui sont nos meilleurs clients ? » Confiez-la à un agent doté d'un LLM et d'une boucle mais d'aucun outil, et vous n'obtenez rien : le modèle n'a aucune idée de qui sont vos clients. Il faut le connecter aux vraies données.

Vous pourriez donc brancher l'agent directement sur toutes vos bases internes. Il découvrirait ce qui s'y trouve, l'évaluerait, lancerait du SQL et vous rendrait une réponse. La magie de la boucle s'en occupe toute seule.

Nous sommes tous d'accord : personne ne fera ça. Donnez à un agent le passe-partout de toutes les données de l'entreprise et vous collectionnez les violations du RGPD à la minute. Un accès sans gouvernance, c'est mort d'avance.

Intercaler une marketplace

La solution, c'est une marketplace de données placée entre l'agent et les données, une couche de protection qui donne à l'agent une boîte à outils plutôt que les clés brutes :

• Découverte : quelles données existent, et où
• Sémantique : ce que les données signifient réellement
• Signaux de qualité et de confiance : les données respectent-elles leur contrat
• SLA : fraîcheur, latence, disponibilité
• Conditions d'utilisation : ce que vous avez le droit de faire, ou non, avec les données
• Gestion des accès : demander l'accès, puis l'utiliser

C'est la marketplace qui ajoute la gouvernance au milieu. Et comme chaque appel, jusqu'à la requête elle-même, transite par cette couche, la gouvernance reste active même pendant la lecture des données. Cette couche intermédiaire qui intercepte tout, c'est toute l'idée.

Un agent qui répond à une question métier

La démo fait tourner un agent embarqué dans le produit Entropy Data et relié à la marketplace. Le prompt : « Regroupe par pays les commandes des 30 derniers jours et visualise le résultat sous forme de graphique. » (Sur Haiku, pour la vitesse.)

À droite, chaque étape est visible. L'agent analyse la finalité, cherche le produit de données des commandes, filtre les 30 derniers jours, regroupe et agrège par pays, puis génère un graphique. La réponse arrive sous forme de tableau : la France en tête avec 314 commandes, les Pays-Bas ensuite avec 294, le tout en une seizaine d'appels d'outils.

La puissance est dans ces appels d'outils, pas dans la bulle de chat. L'agent n'a jamais vu la base de données brute. Il a découvert, évalué et interrogé entièrement à travers la marketplace.

Ancré dans une couche sémantique

Comment l'agent savait-il ce qu'est une « commande » ? Parce que chaque champ est ancré dans une couche sémantique. Dans le graphe, l'entité Order pointe vers Shipping Address, Line Item, Customer, Order ID, ainsi que vers des mesures comme Average Order Value et Contribution Margin.

Entropy Data s'appuie pour cela sur OSI, l'Open Semantic Interchange, lancé par Snowflake et devenu une large initiative qu'Entropy Data a rejointe. L'agent sait donc ce que veut dire chaque champ et comment tout s'articule, le tout sur un standard ouvert.

L'interface n'est là que pour les humains. L'agent, lui, consomme directement les mêmes métadonnées.

Produits de données, contrats et requêtes gouvernées

L'agent a choisi le produit de données Orders et a lu son Data Contract : deux tables, le schéma complet, les garanties, de quoi confirmer qu'il pouvait répondre à la question. Ensuite, il a vérifié ses accès. En l'absence d'accès, l'agent en fait la demande (et dans certains cas, cette demande est entièrement automatisée).

L'accès est fondé sur la finalité. Chaque requête doit porter une finalité, et un contrôle de gouvernance la compare au contrat : si le contrat interdit par exemple un usage marketing, la marketplace arrête la requête en vol, avant même qu'elle n'atteigne Snowflake.

« Vous devez fournir une finalité pour chaque requête. Aucun humain ne ferait jamais ça. Un agent le fait sans effort, il connaît son propre contexte, donc nous pouvons vérifier la finalité et laisser passer ou bloquer. C'est toute la puissance de la marketplace comme couche d'interception. »

Ou apportez votre propre agent

L'agent de la démo est embarqué dans le produit, mais rien ne vous y oblige. Vous pouvez construire votre propre agent dans le framework de votre choix, avec le modèle de votre choix, et le connecter à la marketplace via des outils MCP.

Sous le capot, il appelle exactement les mêmes outils : découverte, sémantique, qualité, SLA, conditions d'utilisation, accès. L'option embarquée simplifie juste le déploiement.

Pourquoi ça marche : cinq facteurs de succès

• Bâti sur des produits de données et des Data Contracts : une propriété claire, un état d'esprit orienté client et des garanties sur les données, exprimées dans l'Open Data Contract Standard.
• Ancré dans la sémantique : chaque champ est rattaché à une couche sémantique partagée (OSI), pour que l'agent sache ce que les choses veulent dire.
• Métadonnées optimisées pour les agents, sur des standards ouverts : les formats embarquent délibérément des exemples, du contexte et des synonymes. Parfait pour les agents et, il se trouve, parfait pour les humains aussi.
• Conforme par conception : la couche intermédiaire vérifie les requêtes en vol, ce qui améliore la gouvernance et permet un contrôle d'accès fondé sur la finalité.
• La marketplace comme boîte à outils : un endroit central où tout converge. Vous branchez une seule chose et vous récupérez tous les bénéfices, au lieu d'assembler la sémantique ici, la qualité là et les accès ailleurs.

« Si vous savez servir les agents, vous servez automatiquement les humains. Si vous savez servir les humains, vous ne servez pas automatiquement les agents. Un agent sans les bonnes métadonnées fait simplement la mauvaise chose, avec beaucoup d'assurance. »

Un besoin, deux consommateurs

C'est le cœur de l'étude BARC dont la conférence tire son titre : un agent IA et un analyste humain attendent en fait la même chose d'une marketplace de données, à savoir la découvrabilité, le contexte et la sémantique, la confiance et la gouvernance, les signaux de qualité. Même socle, interface différente.

Un agent suit ce qu'on lui dit et pense souvent avoir raison. Sans garde-fous ni métadonnées, il fera des choses que vous n'aviez pas prévues, sans malveillance, juste avec assurance. Les humains, eux, connaissent au moins les règles non écrites. Il faut donc être explicite, et l'effort fait pour l'agent profite gratuitement aux humains.

Construire les « shelf warmers »

Le produit de données pris en exemple, ce sont les shelf warmers, le jargon du e-commerce pour désigner le stock qui reste sur l'étagère, prend la poussière et ne se vend jamais. (Simon a travaillé chez un distributeur, d'où les exemples e-commerce.)

Le rêve, ce serait de dire à un agent de code « construis-moi un projet dbt sur Databricks pour le produit de données shelf warmers » puis de partir prendre un café. Ça ne marche pas, pour deux raisons : l'agent ne sait pas quoi construire, et il ne sait pas comment le construire à la manière de votre entreprise.

Résoudre ces deux problèmes, c'est tout le reste de l'histoire.

Étape 1, comprendre : commencer par une conversation

« Construis-le pour moi » échoue parce que personne n'a décidé ce qu'est le produit. Vous repartez donc de la feuille blanche et vous discutez avec les gens : quelle est la finalité de ce produit de données, et quel en est le périmètre ?

Un bon outil pour ça, c'est le Data Product Canvas gratuit du site Data Mesh Architecture : remplissez-le en atelier collectif, esquissez quelques variantes, et vous en ressortez en connaissant la valeur, les entrées et la forme de ce que vous voulez construire.

Étape 2, spécifier : écrire le contrat

Une fois que vous savez ce que vous voulez, vous spécifiez le contrat : ce que votre produit offrira à ses consommateurs, et ce à partir de quoi l'agent peut réellement travailler. Pour les shelf warmers, c'est une seule table : une unité de gestion de stock (le SKU), le nom de l'article, la date de la dernière vente et l'heure de traitement à laquelle la ligne a été insérée.

Libre à vous de le saisir comme votre équipe le préfère. Le modèle Excel ODCS existe à la demande générale, pas parce que quelqu'un l'avait prévu, et se convertit en YAML ensuite. Ou utilisez le Data Contract Editor open source pour écrire rapidement un contrat conforme au standard.

Dans les deux cas, vous obtenez du YAML ODCS, que vous pouvez aussi visualiser, puis vous le stockez dans la marketplace.

Étape 3, construire : l'agent lit le contrat

L'agent de code peut maintenant récupérer le contrat depuis la marketplace et se mettre au travail : il connaît la table cible et ses champs. Mais le contrat ne représente que la moitié de ce que la marketplace lui apporte.

L'autre moitié : l'agent se sert de la marketplace pour trouver d'où les données doivent venir. Il découvre les produits de données existants, évalue lesquels peuvent alimenter les quatre champs, les combine et demande même les accès. Ce sont les mêmes outils gouvernés que ceux de l'agent de lecture, cette fois au service de la construction du pipeline.

Savoir comment : des skills dans un plugin

Le contrat et la marketplace couvrent le quoi construire et l'endroit où vivent les données. Ils ne couvrent pas le comment : vos conventions, votre processus interne, les bonnes pratiques dbt, les technologies que vous utilisez. Pour ça, vous ajoutez des skills issues d'un dépôt de plugins.

Le dbt Data Product Builder open source regroupe des skills comme dataproduct-bootstrap (générer un projet dbt neuf à partir d'un modèle), dataproduct-implement (traduire le schéma du contrat en modèles dbt et les construire) et dataproduct-exampledata (extraire des lignes d'exemple, retirer les données personnelles signalées par le contrat et les synchroniser).

Vous l'installez comme plugin, ici dans Claude, et vous êtes prêt. Les skills sur l'agent de code, la marketplace connectée, le prompt lancé.

Un seul prompt, puis on s'éloigne

L'agent de code, ici, c'est Claude Code, avec le plugin data product builder installé et la marketplace connectée. Toute l'instruction tient en une ligne :

« Implémente un produit de données qui satisfait le Data Contract dont l'ID est shelf-warmers. »

À partir de là, il se débrouille seul. Le tout est montré en capture d'écran enregistrée : la construction en direct prend une dizaine de minutes, alors on passe en avance rapide.

Le résultat

L'agent a déclenché la skill implement, réfléchi un bon moment, puis écrit un projet dbt complet : Input Ports, Output Ports et la transformation qui joint les articles au stock actuel et à la dernière vente.

À l'exécution, le projet dbt a créé la base, le schéma et la table SHELF_WARMERS dans Snowflake. Une dizaine de minutes, et pas une seule question de relance.

En chemin, il a déterminé qu'il lui fallait deux produits de données en amont, a demandé les accès automatiquement (les données n'étaient pas sensibles, l'approbation a donc été automatique), puis a publié le produit Shelf Warmers terminé dans la marketplace, là où les agents de lecture de la première moitié de la conférence peuvent désormais le trouver.

Étape 4, publier : retour au point de départ

La publication boucle la boucle. Le nouveau produit atterrit dans la marketplace, où d'autres agents, et des humains, peuvent le découvrir et demander l'accès, exactement comme dans la démo de lecture du début.

Construire, publier, lire. La marketplace qui permet aux agents de lire les données est la même que celle qui leur permet de les construire.

Bonus : traiter une demande d'évolution

Que se passe-t-il quand un consommateur en demande plus, par exemple « il manque le nom de la marque, ajoutez-le » ? Vous modifiez d'abord le contrat : vous ajoutez une colonne brand_name, ancrée au concept brand qui existe déjà dans la couche sémantique.

Le contrat ne correspond alors plus à Snowflake : vous retournez voir l'agent de code, « implémente le produit de données shelf-warmers », et il met à jour le projet dbt pour aller chercher et exposer le nouveau champ, automatiquement, en deux ou trois minutes. (Montré uniquement en description, faute de temps.)