Dans cet article nous expliquerons en quoi le concept Data as a Product est un pilier structurant du Data Mesh, clé de voute dans la mise à disposition de données fiables et au plus grand nombre ! Nous vous partagerons quelques retours d’expérience sur les pratiques de mise en place de Data as a Product, notamment comment prioriser les premières briques à déployer et l’importance d’embarquer les acteurs clés de la gouvernance et de la tech dans cette approche.

Data Products : Et si notre société avait sans cesse réinventé la roue ?

Posez-vous cette question, que serait devenue notre société si nous avions réinventé la roue à chaque fois que nous en avions besoin ? Maintenant, en l’appliquant à la gestion des données, comment fonctionnerait votre organisation si vous pouviez dans la majorité des cas trouver rapidement des données qui répondent à votre besoin, déjà disponibles et prêtes à l’emploi dans votre entreprise ?

Le Data Product a pour objectif de mettre à disposition des données exploitables et de confiance, sur étagère, afin d’accélérer le processus de développement de cas d’usages – une table de données, un dashboard, un modèle de Machine Learning.

Construire des Data Products suit la même logique de rationalisation que lorsqu’un schéma directeur informatique recommande de mutualiser les efforts de développement applicatif. Ne pas réinventer la roue à chaque fois qu’un use case émerge, mais plutôt fournir un socle commun réutilisable permettant à chacun de gagner en efficacité.

Source: Adopting a product (vs a project) approach to data management, K2view, 2022

Identifier les données stratégiques et largement utilisées dans l’entreprise et les mettre à disposition dans les meilleures conditions permet de réduire le cycle de développement lorsqu’un nouveau cas d’usage voit le jour. Dans le schéma ci-dessus, le Data Product A est un actif servant 3 cas d’usages provenant de deux Business Domains différents. Ainsi, l’effort d’acquisition et de préparation des données n’est réalisé qu’une fois, contre trois fois dans une démarche Project-Driven.

Vous l’aurez compris, les bénéfices d’un Data Product sont intimement liés à sa capacité à être utilisé / réutilisé par le plus grand nombre. Pour ce faire, ses caractéristiques intrinsèques doivent favoriser son partage au sein de l’entreprise.

Une nécessaire convergence Tech x Gouvernance pour tirer les bénéfices du Data Product

Quand l’approche Data Product vise à capitaliser sur l’effort de data management , la mise en place des briques techniques et de gouvernance pour la soutenir demande, quant à elle de créer de nouvelles choses !

Un Data Product doit nécessairement répondre à plusieurs caractéristiques pour assurer une utilisation forte et pérenne dans le temps ; trouver et comprendre facilement la donnée dans au sein du SI de l’entreprise, être capable de l’utiliser facilement, avoir confiance dans la donnée, sécurité, etc. Si la donnée n’est réutilisable par un utilisateur qu’après un retraitement des données fastidieux, peut-être est-il plus pertinent de créer directement son propre use case.

La confiance dans la donnée est un facteur clé d’utilisation des Data Products. Par exemple, une équipe de Data Scientists s’appuie sur des données pour construire des prévisions. Ces prévisions se basent sur un historique dont les données les plus récentes modifient largement les résultats. Si le schéma de données est changé par le producteur de la donnée sans préavis, le modèle ne pourra pas utiliser les données les plus à jour et l’impact financier de prévisions peu précises pourra être désastreux.

Le Data as a Product : offrir les briques clés pour construire des Data Products

Vous l’aurez compris, le Data Product a pour objectif de fournir des services ou des informations à forte valeur ajoutée, sur étagère, en mettant à disposition des données exploitables et de confiance.

Pour les construire et les maintenir, les Data Domains s’appuient sur un cadre technologique et de gouvernance des données : le Data as a Product.

Le Data as a Product est un cadre favorisant la découverte, l’exploration, la confiance et l’accès aux données au plus grand nombre. Il s’inspire des techniques de développement de Produits IT (exemple : applications), en considérant la data comme un produit à part entière, fournissant des fonctionnalités permettant de mettre à disposition de la donnée de la manière la plus automatisée et simple possible.

Le Data as a Product encapsule et implémente tous les composants techniques et organisationnels nécessaires pour traiter et partager les données en tant que produit.

Les équipes Tech et Data gouvernance sont les fondateurs et garants du socle pour accompagner le déploiement du cadre Data as a Product.

Prenons l’exemple d’une composante d’un Data as a Product : le Data Contract !

Un Data Contract est un accord entre un producteur et des consommateurs de données concernant la spécification d’un produit de données ; capacité à comprendre un produit, ses usages et à identifier les interlocuteurs clés, fiabilité, interopérabilité, accès, etc. Ce contrat est écrit sous forme de code afin de mettre en place et de suivre les contrôles et la remontée d’information aux équipes de manière automatique.

Par exemple, si un producteur de données est sur le point de modifier le schéma d’une table, il sera averti que son action engendrera des impacts sur les consommateurs et brisera le contrat. Cette approche vise à détecter rapidement une anomalie à venir sur le cycle de vie de la donnée, prévenir les consommateurs et dans certains cas appliquer des sanctions au producteur si l’impact est fort sur l’activité du business.

La mise en place de ce type d’approche à l’échelle nécessite de faire intervenir de multiples acteurs, notamment les équipes Data Product, la Gouvernance des données et les équipes Tech.

Notre expérience chez plusieurs clients montre que la mise en place de briques structurantes d’un cadre Data as a Product nécessite un effort important de convergence des feuilles de routes entre les équipes Produit, Tech et Data Gouvernance, pour que chaque brique déployée puisse apporter rapidement des bénéfices.

Les équipes Produit et le Data Product Owner pour collecter et partager les besoins prioritaires

• • Collecter les besoins des consommateurs de la donnée : quelles sont les données clés, quel niveau d’agrégation / dénominateur commun sur les données pour que son usage soit optimal… pour répondre à ces questions, plusieurs solutions sont à envisager : identifier les consommateurs via les logs d’utilisation, les tickets de support et les souscriptions aux canaux de notification, puis caractériser le besoin avec ces consommateurs
  • Traduire les besoins en spécifications et en solutions techniques sur des thématiques telles que la gestion des accès aux données, la gestion des données sensibles, le contrôle de la qualité des données, la documentation de la donnée, l’exposition, moyens efficaces pour communiquer des évolutions sur le produit auprès de mes consommateurs, etc.

Les équipes Data Gouvernance pour définir les règles favorisant la cohérence du cadre Data as a Product. Les équipes Data Gouvernance travaillent en collaboration avec les équipes Produit pour assurer un équilibre entre autonomie des utilisateurs et règles centrales à respecter pour assurer une cohérence dans la gestion des données à l’échelle de l’entreprise

Les équipes Tech pour concevoir et déployer les solutions techniques : workflow de gestion des accès aux données, identification et chiffrement des données sensibles, développement d’APIs pour exposer les données, etc.

Construire une feuille de route commune entre ces 3 équipes est clé pour assurer d’engager l’effort vers un même objectif. Cela passe par la mise en place d’un programme de transformation dédié soutenu par un sponsorship de haut niveau (exemple : CIO, CDO).

L’opérationnalisation de ce programme se fera avec succès dès lors qu’une gouvernance claire sera partagée :

• Rôles et responsabilités
• Mise en place de passerelles entre ces 3 équipes: chefs de projets « couteaux-suisses » capables d’appréhender le sujet selon plusieurs prismes produit x gouvernance x tech, ateliers de convergence de feuilles de route, des comités de partage et d’alignement récurrents…

Prioriser les briques à déployer : une démarche orientée sur les besoins des utilisateurs de la donnée

• Identifier les personas : Plusieurs types de profils sont amenés à rechercher, transformer, requêter ou encore exploiter la donnée. Chacun possède ses propres objectifs et ses propres compétences, auxquels le Data as a Product devra répondre.
• Ecrire les user stories : Comprendre le besoin des personas à travers une série d’entretiens sera la fondation pour construire la backlog et la prioriser
• Approfondir le besoin par persona : cette étape permettra de bénéficier d’une liste exhaustive du périmètre fonctionnel à couvrir. Nous menons souvent cette étape par le biais d’interviews mixant deux approches : écoute active pour identifier les fonctionnalités qui sortent en “top of mind” et proposition de fonctionnalités pour balayer le besoin de manière exhaustive.

Focus sur les besoins des expertises Data Science / MLOps

Exemple de besoins

• Gagner en autonomie dans l’ouverture des environnements, accès et on-boarding outils, bonnes pratiques de développement
• Visualiser clairement le niveau de catégorisation de la donnée (personnelle notamment) et la durée maximale de conservation / durée limité d’accès lorsque j’explore les données disponibles
• Visualiser les restrictions de partage (NB : concernant le produit recherché, mais également les éventuels produits que je pourrais construire sur cette base) lorsque j’explore les données disponibles
• Pourvoir réaliser une demande de mise à disposition de nouvelles ressources en terme de puissance de calcul et / ou capacités de stockage, et à terme pouvoir paramétrer mon espace (autoscaling) moi-même. Attention : des contrôles devront être mis en place
• Disposer d’outils de labellisation qui soient collaboratifs de sorte à permettre aux data scientists d’impliquer les métiers dans ces activités lorsque cela est nécessaire (exemple donné de certains projets de Computer Vision)
• Disposer de l’ensemble des fonctionnalités me permettant de requeter, préparer, manipuler les données et/ou développer des modèles mathématiques et/ou d’IA.
• … »

Principaux facteurs à appréhender

Les « développeurs MLOps» peuvent être ajoutés dans les utilisateurs « techniciens »

Le monitoring des produits data est un prérequis au Self-Service, proposition de le faire davantage apparaitre, dès la vue haut niveau de l’offre de service.

Il est nécessaire de distinguer la fonctionnalité liée de développement d’applications (front-end / back-end, chaîne CI/CD, etc.) de celles liées aux demandes de déploiements / MEP

Cette étape de synthèse a vocation à simplifier les phases suivantes de priorisation en proposant une vue plus compréhensible.

En partant de ces besoins, la phase suivante consiste à évaluer les grands services que doivent fournir les Data as a Product pour faciliter l’exploration, la manipulation, la confiance et l’accès aux données. Dans cet exemple, 5 macro-fonctionnalités ont été définies, ainsi que deux accélérateurs à leur déploiement – portant principalement sur des actions d’accompagnement au changement et de suivi des usages, dans une optique d’amélioration continue.

En repartant des interviews réalisées avec les différents personas, il s’agit ensuite de cartographier de manière exhaustive les fonctionnalités cœur à déployer sur chaque macro-fonctionnalité et de distinguer leurs usages par person. Ici, l’utilisateur appelé “exploreur” utilisera les fonctionnalités socles ainsi que deux fonctionnalités clés lui permettant de d’utiliser des données en autonomie en utilisant des outils low code.

Contactez Quantmetry et nos experts Olivier Adriaens, Gill Morisse, Jonathan Cassaigne, Vlad Flamind et Théo Vialard pour en savoir davantage sur notre approche de déploiement de Data as a Product et de construction de Data Products.