Data Mesh : tout ce qu’il faut savoir sur le produit de données

Qu’est-ce qu’un produit de données ?

La notion de produit de données préexistait à l’apparition du Data Mesh.

En 2012, dans son livre Data Jujitsu : The Art of Turning Data into Product, DJ Patil, ancien data scientist, ex-CTO du gouvernement américain et investisseur, indiquait que « le produit de données est un produit qui facilite la réalisation d’un objectif final grâce à l’utilisation de données ».

Benjamin Watrin, architecte data senior chez Business & Decision, interprète cette définition comme « le fait d’exploiter des données dans un produit numérique ». Un produit de données pourrait alors correspondre à n’importe quel site Web ou application.

Simon O’Regan, alors directeur de l’innovation produit chez Mastercard – et actuel responsable monde de l’intégrité des services de paiement chez TikTok –, s’est fait la même réflexion entre 2017 et 2018.

Lui opère « une distinction entre les produits qui utilisent des données pour faciliter un objectif final et les produits dont l’objectif principal est d’utiliser des données pour faciliter un objectif final ».

Plus précisément, Simon O’Regan désigne deux grandes catégories que sont les types de produits de données et les interactions de données.

Il organise les produits de données en cinq groupes que sont :

• Les données brutes (ou légèrement nettoyées et filtrées).
• Les données dérivées, c’est-à-dire des informations augmentées par d’autres données brutes ou des catégorisations (par exemple, l’attribution d’un segment aux clients).
• Les résultats d’algorithmes accessibles à la demande par les métiers.
• Les outils de support à la décision comme des tableaux de bord ou des rapports BI personnalisés.
• Les outils de prise de décision automatisée : une vaste catégorie comprenant à la fois les algorithmes de recommandation des plateformes de streaming jusqu’aux IA qui propulsent les voitures autonomes.

Suivant les usagers, ces produits de données « fonctionnels » peuvent être distribués à travers trois systèmes d’interactions de données ou des interfaces telles des API, des tableaux de bord et des visualisations ainsi que des éléments Web. Ces éléments Web incluent les UX et les expériences de type chatbot, les applications de réalité augmentée et autres.

Ici, Simon O’Regan se place du côté du pôle de données ou de l’entité de la DSI chargé de préparer ses produits et de les livrer aux usagers, qu’ils soient des métiers ou des « spécialistes » de données.

Quelle est la différence entre Data Product et Data as a Product ?

Dans cette description, l’auteur n’envisage pas une approche décentralisée de la gestion de données, contrairement à la consultante qui a imaginé le concept de Data Mesh.

« Un produit de données fournit un ensemble de contrats de partage de données explicitement définis et faciles à utiliser », écrit Zhamak Dehghani, PDG de Nextdata, dans son fameux livre « Data Mesh Delivering Data-Driven Value at Scale » aux éditions O’Reilly.

« Chaque produit de données est autonome, et son cycle de vie et son modèle sont gérés indépendamment des autres ».

La définition de l’autrice ne permet pas de se rendre compte techniquement de ce qu’est un produit de données. Est-ce simplement un jeu de données ?

La réponse est courte : non, mais il faut expliquer pourquoi. Le concept de Data Mesh définit la manière dont ces produits de données sont constitués.

Il faut ainsi distinguer le produit de données (Data Product) du principe de données en tant que produit (Data as A product).

Dans le concept de Data Mesh, l’expression Data as a Product se réfère à une philosophie selon laquelle les données doivent être considérées comme des produits et construit suivant les préceptes du « Product Thinking ».

Zhamak Dehghani ne cite ni DJ Patil, ni Simon O’Regan, mais Marty Cagan, auteur de l’ouvrage « INSPIRED: How to Create Tech Products Customers Love », paru pour la première fois en 2008.

Selon Marty Cagan, un produit technologique à succès est « réalisable, valable et utilisable ».

Les attributs d’un produit de données dans l’approche Data Mesh

Zhamak Dehghani conserve les notions « valable et utilisable » afin de définir un ensemble de caractéristiques qu’un produit de données doit disposer.

Ainsi, un « bon » produit de données est, selon Zhamak Dehghani :

• Découvrable
• Adressable
• Compréhensible
• Digne de confiance et véridique
• Accessible de manière native
• Interopérable et composable
• Valable en soi
• Sûr

Ces attributs de base visent en premier lieu à faciliter l’accès aux produits de données aux métiers et à leurs propriétaires ou à permettre à leurs gérants de mieux les contrôler.

Selon ces préceptes, l’éditeur Zeenea considère que les data products « sont des ensembles de données autonomes et spécifiques à un domaine, conservés et gérés par des équipes individuelles ».

Ces préceptes semblent d’abord affecter l’architecture mise en place pour que les métiers puissent concevoir et consommer les produits de données.

Pour qu’un jeu de données soit découvrable, il faut qu’il soit stocké dans un espace adressable et qu’une interface comme une API, un moteur de recherche, un portail ou un catalogue de données permette de le découvrir.

Des caractéristiques techniques précises

En la matière, Zhamak Dehghani précise les attributs techniques d’un produit de données. Ainsi il reste adressable malgré ses évolutions. Le système qui le rend accessible doit mentionner les évolutions du schéma de données, la fréquence de rafraîchissement de données, exposer les nouvelles manières de sérialiser, de présenter et d’interroger les données ainsi qu’afficher des pistes d’audits concernant les SLO, les accès et les possibles bugs.

La compréhension passe par la documentation : un descriptif d’un jeu de données, par exemple.

La confiance est assurée par des objectifs de niveau de service comme les intervalles de changements des jeux de données, le temps entre la création de données et leur accès par un métier, la « complétude » des données, la « forme statistique des données » (distribution, volume, portée, etc.), le lineage (un historique des transformations effectuées), la précision et l’exactitude à travers le temps et des indicateurs de « qualités opérationnelles » (fraîcheur, disponibilité, performance) des produits de données.

Concernant l’accessibilité, l’autrice met en avant des solutions techniques (API, connecteurs, liens URL, etc.) permettant à différents rôles d’accéder aux mêmes données.

Quant à l’interopérabilité, elle nécessite de standardiser ou d’harmoniser la manière dont les produits de données sont constitués par les propriétaires des domaines.

Les entités parties prenantes doivent s’entendre sur les types de champs, des identifiants universels, sur la confection d’une méthode d’accès unique à chaque produit de données, sur des métadonnées communes, la possibilité de lier et de réutiliser des schémas de données définis par d’autres « data products », sur la cartographie des liens entre des données à travers plusieurs produits de données, et enfin sur l’élaboration de schémas de données rétrocompatibles.

Pour autant, un produit de données « doit se suffire à lui-même ». En clair, son utilisateur ne doit pas avoir besoin de recourir à un autre produit de données afin de l’expliquer.

L’accessibilité comme la sûreté passent aussi par des couches de gestion des rôles et des accès, des méthodes de chiffrements (en transit ou au repos, sur disque ou en mémoire, au niveau d’un champ de données ou d’une table, etc.), par une politique de rétention de données, et par le respect des législations et normes en vigueur (RGPD, CCPA, CSRD, BCBS 239, etc.).

Ce que devrait contenir un produit de données

Les attributs techniques décrits ci-dessus ne sont que les reflets des « caractéristiques de base » (découvrabilité, interopérabilité, accessibilité, etc.) d’un data product.

D’après la PDG de Nextdata, un produit de données inclut « trois types de composants structurels » : du code, les données et leurs métadonnées, et « les spécifications des dépendances de l’infrastructure ».

Le code correspond aux transformations de données, au code des connecteurs ou des API, ou encore aux manifestes d’exécution des transformations. Un produit de données « doit inclure le code » nécessaire aux transformations et les moyens nécessaires pour « l’exécuter dans un contexte de calcul spécifique ».

La grande différence entre produit de données et artefact de données

La présence du code et des moyens de l’exécuter dans un produit de données, d’après Zhamak Dehghani, le distingue d’un « artefact de données comme des fichiers ou des tables qui, eux, sont passifs ».

Les données sont accompagnées de leur modèle, de leur description, de SLO, de leur lineage sous forme de métadonnées.

Ces indicateurs peuvent être accessibles à travers des API qui permettent de récupérer ou de visualiser ces métriques d’observabilité.

Quant aux dépendances de l’infrastructure, l’autrice insiste sur le fait que toutes les ressources associées à un produit de données peuvent être exécutées sur une infrastructure centralisée, mais dans un espace isolé, afin qu’un traitement n’en affecte pas un autre. Le produit de données doit indiquer les politiques d’exécution et de rétention de données pouvant être liées à des instances spécifiques de l’infrastructure, qui sont alors perçues comme des dépendances.

Mise en pratique

Voilà pour la théorie. La mise en œuvre d’un produit de données comme l’entend l’autrice réclamerait une maîtrise totale des infrastructures, de l’architecture et des logiciels déployés par l’entreprise. Pour diverses raisons techniques, légales, pratiques et commerciales, peu d’organisations peuvent obtenir un tel niveau de granularité sans un déploiement conséquent et à façon.

D’autant que les éditeurs ont chacun leur interprétation de ce qu’est un produit de données. Pour sa part, Starburst, éditeur d’une distribution commerciale de Trino, prend en compte tous les attributs, mais considère que les data products incluent, dans sa plateforme, des tables et des vues matérialisées, des patterns d’accès aux données et du code SQL.

Chez Snowflake, un produit de données est, par défaut, composé de code, de données et de métadonnées. Or le fournisseur entend permettre à ses clients de vendre leurs produits de données, ce qui n’est pas l’objectif final de la philosophie « Data as a Product ». Dans ce cadre, sa marketplace permet aux utilisateurs de « définir exactement ce qu’ils offrent – métadonnées, tables de données, logique métier, applications complètes ou toute combinaison de ces éléments – et préciser à qui, à quel prix, pour quelle période et dans quel but ».

Databricks offre peu ou prou les mêmes fonctionnalités avec deux méthodes d’accès différentes, suivant si le produit de données est interne ou public. L’éditeur précise qu’il ne se limite pas aux données tabulaires et qu’il peut fournir l’accès aux notebooks dans un produit de données. 

Les entreprises, elles, s’appuient ou non sur ces solutions, mais commencent à mettre en place ce type de logique. C’est le cas des entités interrogées par Quantmetry qui sont en train de standardiser les formats et les méthodes d’exposition des données, mais « sur un nombre restreint de domaines de données ».

« Le Data Mesh est avant tout une transformation organisationnelle visant à décentraliser le data management (self-service, autogestion des données par le métier…), tout en offrant la cohérence nécessaire pour que les données circulent sans entrave à travers l’organisation (standards, socles communs, interopérabilité…) », rappelle Quantmetry. « D’un point de vue technologique, le Data Mesh ne repose pas sur des composants d’architecture particulièrement innovants (ex. : catalogues de données, ETLs, Datalakes…). C’est l’alignement entre les choix technologiques et la transformation organisationnelle qui représente la réelle innovation ».