Data Product — Produit de données

Définition complète

Un data product est un dataset — ou une interface de données — traité selon les mêmes standards qu'un produit logiciel. Il possède un propriétaire clairement désigné (une personne ou une équipe), des consommateurs identifiés, un contrat de service (SLA de fraîcheur, de disponibilité et de qualité), une documentation à jour, un historique de versions, et des processus formels de support et de signalement d'anomalies. La définition formelle, popularisée par Zhamak Dehghani en 2019–2020 dans le cadre du data mesh, identifie six propriétés fondamentales : découvrable, adressable, digne de confiance, auto-descriptif, interopérable, et sécurisé.

La distinction fondamentale entre un data product et un dataset ordinaire est avant tout organisationnelle et contractuelle, pas technique. Un dataset classique existe en sortie d'un pipeline — souvent sans documentation, sans propriétaire, sans garantie. Un data product est un engagement : quelqu'un est responsable de sa qualité, s'engage sur sa fraîcheur et répond aux questions des consommateurs. Cette responsabilité explicite est ce qui rend les données analytiques dignes de confiance à l'échelle.

Dans la pratique, un data product peut prendre plusieurs formes : une table dimensionnelle dans un entrepôt de données, un flux de données temps réel, une API exposant des métriques calculées, une sortie de reverse-ETL envoyant des données enrichies vers un CRM, ou un feature store ML exposant des signaux de propension à l'achat. Ce qui les unit est l'application des pratiques produit — et non la forme technique qu'ils prennent.

Comment implémenter un data product

La mise en œuvre d'un data product suit une approche en plusieurs étapes. La première consiste à identifier les consommateurs réels et leurs besoins précis — pas les consommateurs hypothétiques, mais les équipes ou systèmes qui utilisent ces données aujourd'hui. La deuxième étape définit le contrat : fraîcheur (actualisé toutes les heures, chaque nuit, à J+1 ?), complétude (quels champs sont garantis, lesquels sont optionnels ?), et disponibilité (temps maximal d'indisponibilité toléré). La troisième étape désigne un propriétaire — une personne ou une équipe qui répond aux incidents et pilote l'évolution.

La plupart des équipes commencent par identifier leurs deux ou trois datasets les plus critiques — ceux utilisés quotidiennement par plusieurs équipes — et leur appliquent ces standards en priorité. Vouloir transformer tous les datasets en data products dès le départ conduit à l'échec : la surcharge opérationnelle dépasse les bénéfices. La progression est logique : cataloguer les usages existants, prioriser par impact, et étendre progressivement.

Exemple concret

Prenons une entreprise SaaS B2B française avec 2 500 clients actifs. Son équipe data produit une table clients_enrichis utilisée simultanément par : l'équipe commerciale (segmentation pour les campagnes d'upsell), le service client (score de santé affiché dans l'outil de ticketing), le CFO (réconciliation avec le MRR dans le reporting mensuel), et deux modèles ML de propension au churn. Cette table est critique — une anomalie ou un retard affecte immédiatement quatre équipes.

Sans approche data product, cette table existe mais personne n'est formellement responsable. Quand un bug survient à 7 h du matin un lundi — les chiffres du reporting CFO semblent incorrects — personne ne sait qui appeler, ni quelle est la définition officielle du champ mrr_client. L'équipe commerciale a sa propre définition, qui diverge de celle du CFO de 3 000 €.

Avec une approche data product, la table clients_enrichis a un SLA documenté (actualisée à 6 h 30 chaque matin, disponibilité garantie à 99,5 %), un propriétaire (Marie, data engineer senior), une définition formelle de chaque champ dans le catalogue de données, et une alerte automatique en cas de retard ou d'anomalie de qualité. Le coût annuel de maintenance explicite de ce data product — environ 15 000 € de temps ingénieur — est largement compensé par la réduction des incidents et du temps perdu à réconcilier des chiffres divergents estimé à plus de 40 000 € par an.

Analyse approfondie

Le data product est avant tout une réponse à un problème organisationnel, pas un problème technique. La plupart des stacks analytiques modernes disposent d'outils suffisamment puissants pour produire des données de qualité. Ce qui fait défaut, c'est la responsabilité — la désignation claire de qui est propriétaire de quelle donnée, avec quel engagement de service. Sans propriétaire explicite, les datasets se dégradent progressivement : la documentation devient obsolète, les tests de qualité ne sont plus maintenus, les consommateurs développent des contournements locaux qui créent des définitions divergentes. C'est le processus de dégradation que les partisans du data product appellent le "data swamp" — une accumulation de données dont personne ne sait si elles sont fiables.

Le lien entre data product et data mesh est important à comprendre correctement. Le data mesh, popularisé par Zhamak Dehghani dans son livre "Data Mesh" (2022), propose une organisation décentralisée où chaque domaine métier est propriétaire de ses données et les expose sous forme de data products à des consommateurs internes. Le data product est le concept central — c'est l'unité de base du data mesh. Mais adopter le concept de data product ne nécessite pas une transformation complète vers le data mesh. Des équipes data centralisées peuvent — et devraient — appliquer les mêmes standards à leurs datasets les plus critiques, sans restructuration organisationnelle majeure.

Les six propriétés fondamentales définies par Dehghani — découvrable, adressable, digne de confiance, auto-descriptif, interopérable, sécurisé — constituent un cadre d'évaluation utile. "Découvrable" signifie que les consommateurs potentiels peuvent trouver le data product dans un catalogue sans avoir à demander à quelqu'un. "Adressable" signifie qu'il possède une adresse permanente — une URI, un nom de table versionné — que les consommateurs peuvent référencer durablement. "Digne de confiance" implique des tests de qualité automatisés et un historique de fiabilité. "Auto-descriptif" signifie que la documentation est intégrée, pas stockée ailleurs. "Interopérable" signifie qu'il suit des standards partagés (formats, nomenclature, sémantique) pour être utilisé par plusieurs consommateurs. "Sécurisé" signifie que les contrôles d'accès sont gérés au niveau du data product, pas laissés à chaque consommateur.

L'écosystème outillage autour du data product s'est rapidement structuré. Les catalogues de données (Atlan, Castor, DataHub, OpenMetadata) fournissent la couche de découverte et de documentation. Les outils de transformation (dbt) permettent de versionner les définitions et d'exécuter des tests de qualité automatisés. Les plateformes de monitoring de données (Monte Carlo, Datafold) détectent les anomalies et alertent les propriétaires. Les plateformes de données modernes (Databricks, Snowflake) offrent des primitives de contrôle d'accès granulaire. Ensemble, ces outils permettent d'opérationnaliser les principes du data product sans développement custom excessif.

La question du seuil — à partir de quel moment un dataset mérite-t-il d'être traité comme un data product — est pratique et stratégique. Un critère simple : dès qu'un dataset est utilisé par plus d'une équipe ou plus d'un système, il doit avoir un propriétaire et un SLA minimal. Dès qu'il entre dans un processus décisionnel critique — reporting financier, calcul de commission, pilotage des stocks — il doit avoir la totalité des propriétés d'un data product. Tout le reste peut rester dans l'état de "dataset exploratoire" sans les coûts de maintenance associés. Cette hiérarchisation évite le piège de la perfection qui paralyse l'adoption.

Erreurs fréquentes dans la mise en œuvre des data products

• ✗

  Vouloir tout transformer en data product simultanément : appliquer les standards data product à l'intégralité du catalogue analytique dès le départ génère une charge opérationnelle insoutenable. Une organisation avec 300 tables qui tente de toutes les "productiser" en trois mois crée plus de bureaucratie qu'elle n'en supprime. La bonne approche consiste à identifier les 5 à 10 datasets les plus critiques — ceux dont la qualité affecte directement des décisions à forte valeur — et à leur appliquer rigoureusement les standards data product en premier.

• ✗

  Désigner un propriétaire sans lui donner l'autorité correspondante : la propriété d'un data product ne signifie rien si le propriétaire ne peut pas décider des modifications de schéma, refuser des demandes inconsistantes avec le SLA, ou allouer du temps de maintenance. Confier la "propriété" à quelqu'un sans autorité réelle produit un résultat pire que l'absence de propriétaire — une fausse responsabilité qui masque l'absence de gouvernance réelle.

• ✗

  Confondre data product et documentation : ajouter des descriptions dans un catalogue de données ne suffit pas à créer un data product. La documentation est une propriété nécessaire mais insuffisante. Ce qui distingue un data product, c'est la combinaison de la responsabilité opérationnelle (quelqu'un répond aux incidents), du SLA de qualité (des tests automatisés vérifient en continu), et du processus de gouvernance des évolutions (les modifications de schéma sont communiquées aux consommateurs avant déploiement).

Comment Fairview produit des data products opérationnels

Fairview applique les principes du data product à chaque vue opérationnelle qu'il produit. Les métriques exposées — MRR réconcilié, marge de contribution par ligne de produit, score de santé client — sont calculées à partir de définitions centralisées et versionnées, avec une fraîcheur garantie et des tests de qualité automatisés exécutés à chaque mise à jour. Si une source de données est en retard ou présente une anomalie, une alerte est déclenchée avant que l'impact soit visible dans les tableaux de bord.

Cette architecture signifie que les données que vous voyez dans Fairview sont des data products au sens strict : propriétaire identifié (l'équipe Fairview), SLA de fraîcheur documenté, définitions consultables, alertes de qualité automatisées. Vous n'avez pas à vous demander si le chiffre de MRR affiché est le bon — la définition est exposée et la fraîcheur est garantie. C'est précisément ce que le concept de data product cherche à accomplir : transformer la confiance dans les données d'un acte de foi en un engagement contractuel.

Questions fréquentes