A Data Marketplace Is
What Your Agents Need

Confiance, accès et responsabilité : comment les marketplaces de données rendent les agents IA opérationnels

Rendre les données fiables et trouvables reste, depuis des années, un problème non résolu de l’analytique en entreprise. Selon l’étude BARC Data Mesh and Data Fabric – From Theory to Application¹, 73 % des répondants indiquent que les données pertinentes ne sont pas faciles à trouver, et 75 % confirment que leurs données et leurs analyses manquent de fiabilité et d’interprétabilité.

Ces chiffres sont antérieurs à la vague de l’IA agentique. À mesure que les agents IA automatisent des processus métier critiques, l’enjeu monte d’un cran : les lacunes d’infrastructure qui ralentissent les Data Consumers² peuvent conduire les agents à agir sur des données incomplètes ou peu fiables. Une marketplace de données fait partie de la réponse : elle rend les données trouvables, fiables et accessibles, aussi bien pour les humains que pour les agents IA.

Humains et agents attendent les mêmes quatre conditions des données d’entreprise

Avant d’en venir à la solution proposée, approfondissons le diagnostic. Les travaux de BARC pointent invariablement quatre difficultés fondamentales auxquelles les organisations font face aujourd’hui :

• Les Data Consumers ne trouvent pas les bonnes données (découvrabilité)
• Ils ne comprennent pas ce que les données signifient, faute d’explications suffisantes (contexte et sémantique)
• Ils n’accèdent pas assez vite aux données, à cause de workflows d’accès complexes et manuels (gouvernance des accès aux données)
• Ils ne peuvent pas évaluer si les données qu’ils consultent sont fiables (signaux de qualité)

Nous soutenons que les agents IA se heurtent aux quatre mêmes obstacles, avec une bien moindre tolérance à l’erreur. Voici deux exemples :

Ce ne sont malheureusement pas des cas marginaux, mais les conséquences prévisibles du déploiement d’agents sur une infrastructure de données qui n’a pas été conçue pour l’IA agentique.

Des actifs de données quelconques ne suffiront pas

Lever ces quatre obstacles n’est pas seulement une affaire de plateforme de données ou de design d’interface. Tout commence par la façon dont les données sont conditionnées pour la consommation. Prenons une analogie : un principe actif pharmaceutique en vrac, comme l’acide acétylsalicylique, n’est pas un produit. L’Aspirine³, si : c’est la version dosée et étiquetée, conditionnée avec ses contre-indications, issue d’un fabricant responsable et accompagnée d’une notice. L’analogie est simple : si vous voulez proposer quelque chose sur une marketplace, faites-en un produit facile à évaluer, à consommer et à qui faire confiance.

Définition du produit de données, pour les curieux

Un produit de données est un actif de données standardisé, réutilisable, actif et « achetable », conçu pour délivrer une valeur mesurable en appliquant les principes du product thinking. Il regroupe un ou plusieurs artefacts enrichis de métadonnées : politiques de gouvernance, Data Contracts et, en option, un SBOM (Software Bill of Material). Aligné sur un domaine ou un cas d’usage précis, il garantit la responsabilité, l’évolution continue, le passage à l’échelle et la conformité aux exigences métier et réglementaires.

Jacqueline Bloemen et Florian Bigelmaier (tous deux chez BARC), 2025, d’après la définition Bitol des produits de données, légèrement ajustée.

Pour en savoir plus sur les produits de données : barc.com/data-products

Les produits de données réunissent tout ce dont un consommateur a besoin : des données orientées usage, des métadonnées, des SLA, une propriété clairement établie, une maintenance dans la durée et des conditions d’utilisation. Des jeux de données quelconques, sans owner ni documentation sémantique, ne créent pas de demande durable.

Cela ne se construit pas du jour au lendemain. Les travaux de BARC montrent que 49 % des organisations citent la mise en place d’une organisation et d’un état d’esprit orientés produits de données comme un défi actuel⁴, car il faut passer d’un modèle orienté service à un modèle orienté produit. Une marketplace peut jouer le rôle de catalyseur, mais la transformation culturelle que cela suppose ne doit pas être sous-estimée.

La propriété des produits de données est le levier organisationnel le plus fort dont nous disposons pour renforcer la confiance dans les données. Autrement dit : les produits de données ne réussiront que si des owners côté métier assument la responsabilité des données produites par leurs processus. Les Data Engineers et les développeurs d’applications peuvent bâtir l’infrastructure qui numérise et automatise ces processus, et être responsables des pipelines techniques qui acheminent et raffinent les données de A à B. Mais on ne peut pas leur faire porter la responsabilité du processus qui crée la donnée.

L’IA fait monter les enjeux de la qualité des données. Les responsables métier disposent aujourd’hui d’un levier organisationnel inhabituel : les problèmes de qualité que les équipes toléraient depuis longtemps sous forme de « tableaux de bord imprécis » se traduiront, dans un monde agentique, par des automatisations cassées et des agents peu fiables. Difficile d’ignorer une telle conséquence.

Quand les produits de données ne parlent pas la même langue

Il existe une autre dimension sur laquelle des jeux de données quelconques échouent : l’interopérabilité. Un produit de données bien conditionné est utile, mais c’est en combinant deux produits ou plus que la valeur se démultiplie. Or combiner des produits issus de domaines différents suppose une sémantique partagée. Le mot « client » dans le domaine commercial désigne-t-il la même chose que « client » dans la logistique ? Le « chiffre d’affaires » obéit-il aux mêmes règles de reconnaissance en finance que dans le reporting commercial ? Conditionner les données sous forme de produit peut, paradoxalement, renforcer cette fragmentation : la propriété par domaine incite moins, et non plus, les équipes à aligner leurs définitions sur le reste de l’organisation.

Une piste consiste à travailler avec des définitions documentées de façon plus explicite. Un produit de données doit expliquer non seulement ce qu’il contient, mais aussi comment ses termes clés se rattachent aux termes équivalents d’autres produits, les étendent ou les contredisent. Une marketplace de données qui expose ces relations, en signalant explicitement où les définitions convergent et où elles divergent, transforme une découverte passive en combinaison éclairée. Consommateurs et agents peuvent alors choisir en connaissance de cause quelle définition utiliser et pourquoi, au lieu de combiner sans le savoir des représentations incompatibles d’un même concept du monde réel.

Data Contracts : la pièce manquante pour automatiser l’accès aux données

Instaurer une véritable propriété est le moyen organisationnel le plus courant de renforcer la confiance dans les données, mais il existe une façon de consolider encore la relation entre Data Producer et Data Consumer : les Data Contracts.

Un Data Contract précise ce qui est livré et à quelles conditions. Cela sert plusieurs objectifs. D’abord, le contrat formalise la relation entre producteur et consommateur. Concrètement, le consommateur sait exactement ce qu’il peut attendre d’un produit de données, qui en est responsable et qui contacter en cas de problème. Au lieu d’une dépendance informelle envers la personne qui a construit le pipeline, la relation devient explicite : un owner nommé avec des obligations définies, et un consommateur doté de droits d’usage clairement énoncés, rattachés à une finalité déterminée.

Ensuite, c’est une source d’information structurée sur le produit de données, comparable à la notice qui accompagne un médicament, pour rester dans l’analogie. Des signaux de qualité inscrits dans le contrat permettent aux consommateurs, et surtout aux agents, d’évaluer l’adéquation à l’usage avant de consommer.

Troisièmement, les contrats rendent la qualité vérifiable. Un contrat définit ce qu’un produit de données est censé livrer : format, complétude, fraîcheur attendue. Les données réelles peuvent donc être validées automatiquement au regard de ces spécifications. C’est particulièrement important pour les agents : plutôt que de propager les problèmes de qualité en aval, un agent peut vérifier l’adéquation à l’usage avant de traiter.

Quatrièmement, les contrats rendent la gestion des accès automatisable. Si les règles disant qui peut utiliser un produit de données et à quelle fin sont déjà écrites, le système peut approuver les demandes d’accès automatiquement, sans intervention humaine. Pour un humain, cela signifie accéder plus vite aux données dont il a besoin. Pour les agents, l’enjeu est encore plus grand, car ils demanderont à terme l’accès aux données bien plus souvent que les humains ne l’ont jamais fait.

Les Data Contracts ne suffisent toutefois pas à eux seuls. Comme dans le monde réel, où les contrats régissent des relations individuelles mais s’inscrivent dans un cadre juridique plus large, ils ont besoin de politiques valables pour toute l’organisation afin de leur donner un contexte. Les politiques définissent ce qui est universellement permis ou interdit et quels standards suivre ; les contrats précisent, dans ces limites, des règles supplémentaires propres à un produit de données donné.

La marketplace de données : là où tout converge

Toute plateforme de données mature dispose au minimum d’un référentiel de métadonnées techniques, comme toute bibliothèque possède un index. Ces outils aident à trouver les données. Ce qu’ils ne savent pas faire, c’est créer de la confiance. Un index de métadonnées vous dit qu’un jeu de données existe, mais pas s’il est fiable, ce qu’il signifie dans votre contexte métier, ni s’il convient à votre cas d’usage. C’est la confiance, construite par le contexte, la sémantique et les signaux de qualité, qui transforme une découverte passive en demande réelle et qui fait toute la valeur d’une marketplace de données interne.

Beaucoup de marketplaces de données donnent l’impression d’une expérience d’achat façon Amazon, jusqu’au moment où l’on veut réellement obtenir le produit. Une fois qu’un consommateur a trouvé un produit de données digne de confiance, il attend un accès immédiat. C’est là que beaucoup d’organisations restent en retrait, avec des workflows d’approbation manuels qui prennent des jours ou des semaines. Une marketplace de données traite la partie découverte de cette boucle. Dans son principe, c’est un moteur de recherche de métadonnées curées qui expose les produits de données avec le contexte nécessaire pour juger de leur adéquation et de leur fiabilité. La plupart des marketplaces s’arrêtent là aujourd’hui. La vision plus ambitieuse, vers laquelle s’orientent les implémentations les plus mûres, consiste à étendre cela à l’attribution des accès. Au lieu de simplement orienter le consommateur vers le bon produit de données et de le laisser ouvrir un ticket, la marketplace gouvernerait et automatiserait aussi la demande d’accès elle-même.

Plus une organisation se complexifie, plus une marketplace de données a de valeur. Davantage de domaines métier, davantage de plateformes de données, davantage d’équipes qui travaillent avec la donnée : tout cela accroît le besoin de savoir quelles données existent, où les trouver et comment y accéder. Il faut un point d’entrée unique et fiable, offrant assez de contexte pour choisir et consommer le bon produit de données.

La marketplace résout aussi l’une des tensions centrales des produits de données, dans un mouvement qui vise à donner plus de pouvoir aux domaines métier : les organisations et les architectures fédérées ne sont pas totalement décentralisées. Elles doivent avoir une colonne vertébrale bien définie. Beaucoup d’organisations confient à juste titre la propriété et la création des produits de données aux domaines métier, mais deux éléments doivent rester centraux : un point unique d’accès et de découverte (car une marketplace obéit à des lois d’échelle) et un socle de politiques de gouvernance valables pour toute l’organisation et applicables à tous les produits publiés. La marketplace est le lieu naturel des deux. Elle peut valider les contrats au regard des politiques globales au moment de la publication, et évaluer les demandes d’accès au regard de ces mêmes politiques au moment de la consommation.

Accès accordé ne veut pas dire accès gouverné

Les marketplaces qui vont au-delà de la découverte, jusqu’à l’attribution des accès, gagnent une capacité qui manque aux systèmes classiques : elles peuvent consigner non seulement qui a accédé à quoi, mais aussi pourquoi. Cette dernière dimension, la finalité de la consommation de données, est généralement absente du contrôle d’accès classique, alors qu’elle conditionne l’automatisation de l’accès aux données à grande échelle.

Prenons un exemple : un grand groupe dispose de données sur la valeur vie client. Un data scientist obtient un accès pour construire un modèle de priorisation commerciale. Le modèle fonctionne très bien. Un collègue du marketing demande alors à utiliser ces mêmes données de CLV pour segmenter ses campagnes. Le data scientist les partage de façon informelle, sans nouvelle demande d’accès. Les données servent désormais à une finalité pour laquelle elles n’ont jamais été autorisées.

Chez les analystes humains, les signaux informels, les processus de revue et le jugement professionnel créent une friction naturelle face aux usages non autorisés et aux détournements manifestes. Les agents IA opèrent sans jugement moral et sans cette friction. Tenter de leur inculquer de tels scrupules ne fonctionne jamais à 100 %.

La conséquence : les organisations doivent protéger la donnée elle-même. Elles ne peuvent plus considérer l’octroi d’un accès comme le point final de la gouvernance. Le contrôle d’accès classique est une décision ponctuelle : une demande arrive, le demandeur déclare une finalité, et le système accorde ou refuse. Une fois l’accès accordé, on suppose que l’usage reste dans le périmètre déclaré. Au mieux, l’accès sera réexaminé tous les quelques années.

Reprenons l’exemple, en remplaçant cette fois le data scientist par un agent IA. Même produit de données CLV, même finalité déclarée : la priorisation commerciale. Trois mois plus tard, l’agent se met à utiliser ces données pour alimenter un modèle de risque qui détermine si un client peut acheter sur facture ou doit payer d’avance. Cela peut avoir du sens sur le plan métier, mais il s’agit clairement d’une autre finalité, qui n’a été ni déclarée ni approuvée. Lors d’un audit de conformité, personne ne peut expliquer pourquoi l’agent a traité des données clients en dehors de son périmètre initial.

La solution n’est pas de réexaminer les définitions d’accès plus souvent. Elle consiste à faire passer la logique de gouvernance d’un accès vu comme une approbation ponctuelle à un accès vu comme un état contrôlé en continu. Une marketplace de données détient à la fois le contrat et le contexte permettant d’évaluer si une requête donnée reste dans les clous. Elle peut aussi montrer si les garanties inscrites dans un Data Contract sont effectivement tenues. C’est donc le lieu naturel pour capter le « pourquoi » de chaque octroi d’accès et faire respecter la conformité lorsque les requêtes s’écartent de la finalité déclarée.

Gouverner l’accès aux données n’est qu’une pièce d’un puzzle bien plus vaste, celui de l’AI Governance. Cette discipline couvre aussi le comportement des modèles, la qualité des sorties, l’explicabilité, l’observabilité, la supervision humaine, l’usage éthique, la gestion des risques et la conformité réglementaire, pour n’en citer que quelques-uns. Et même sur le volet données, le contrôle d’accès ne dit pas tout : pensez aux biais, au consentement, aux politiques de rétention. Cet article se concentre sur un aspect très important : la gouvernance de l’accès des agents aux données.

Quatre actions pour démarrer

La voie à suivre n’est pas un déploiement big bang de la marketplace. C’est bien davantage une transformation organisationnelle, portée par la mise en ligne d’un produit de données à la fois et par la conviction, équipe après équipe, que l’effort en vaut la peine.

Les organisations qui investissent dans l’infrastructure de données tout en négligeant les marketplaces de données, les contrats et le product thinking découvriront que leurs agents IA héritent du même déficit de confiance qui handicape les analystes humains depuis des années. L’infrastructure nécessaire à l’analytique humaine et à l’automatisation par agents est, dans son socle, la même. Les conséquences d’un échec, elles, ne le sont pas.

À propos d’Entropy Data

Entropy Data propose une marketplace de produits de données, garantie par des Data Contracts, qui fonctionne aussi bien pour les analystes humains que pour les agents IA.

Elle repose sur des standards ouverts, avec une prise en charge native de l’Open Data Contract Standard (ODCS), de l’Open Data Product Standard (ODPS) et d’Open Semantic Interchange (OSI), auxquels nous contribuons activement pour les faire progresser. Ensemble, ces standards rendent les produits de données trouvables, contextualisés par une sémantique métier et accessibles via des workflows d’accès automatisés, tout en exposant les signaux de qualité dont les consommateurs ont besoin pour faire confiance à ce qu’ils trouvent. Les contrats eux-mêmes sont appliqués par notre Data Contract CLI open source, largement adoptée.

Trois briques la font fonctionner :

Ensemble, elles offrent aux agents un point d’entrée fiable via API et via le Model Context Protocol (MCP), et aux personnes une marketplace sur laquelle elles peuvent compter.

Entropy Data s’intègre à toutes les grandes plateformes de données et est disponible en SaaS hébergé dans l’UE, en bring your own cloud ou en déploiement on-premises.

Entropy Data est certifié ISO 27001 et déployé en production par de grands groupes dans de nombreux secteurs (logistique, pharmacie, médias, télécoms) et sur plusieurs zones géographiques, dont les États-Unis, l’Australie, la Suisse et l’Union européenne. Preuve que notre marketplace de produits de données garantie par contrat passe largement le cap du pilote.

À propos de BARC

BARC est le principal cabinet d’analystes en data & analytics, IA, pilotage de la performance (CPM) et ESG, reconnu pour la neutralité et la fiabilité de ses conseils. Nos analystes produisent une large gamme d’études, d’événements et de missions de conseil pour la communauté data & analytics. Nos travaux évaluent rigoureusement les logiciels, les éditeurs et les prestataires, mettent en lumière les tendances du marché et livrent des enseignements qui permettent à nos clients d’innover avec la donnée, l’analytique et l’IA. Les 25 ans d’expérience de BARC en stratégie et culture de la donnée, architecture, organisation et sélection de logiciels aident nos clients à devenir des organisations véritablement pilotées par la donnée.

---

Notes

1. Enquête BARC « Data Mesh and Data Fabric » 2024, tailles d’échantillon : n=197 pour l’ensemble de l’enquête, n=197 pour les questions citées ↩
2. « Data Consumers » désigne simplement les personnes qui ont besoin de données pour faire leur travail ↩
3. Aspirine® est une marque déposée de Bayer AG. Ce rapport est indépendant, sans lien avec Bayer ni approbation de sa part. ↩
4. Enquête BARC « Data Mesh and Data Fabric » 2024, tailles d’échantillon : n=197 pour l’ensemble de l’enquête, n=121 pour les questions citées ↩

BARC Spotlight: A Data Marketplace Is What Your Agents Need © BARC 2026. Reproduit avec autorisation. Mis à disposition par Entropy Data.