Exemples de produits de données : 13 cas réels en entreprise

Chercher des exemples de produits de données renvoie presque toujours à des définitions. Cet article fait l’inverse : il montre des data products en service chez des entreprises nommées, avec ce qu’ils contiennent, qui les consomme et ce qu’ils ont changé. Assurance, banque, média, industrie, télécoms, transport, services, édition logicielle.

• Un actif data packagé : propriétaire, interface consommable, documentation, consommateurs identifiés. Le reste, ce sont des extractions.
• Cinq familles couvrent le terrain : jeu de données certifié, couche sémantique, tableau de bord et rapport BI, API et score, produit d’IA.
• Le gain est du temps repris aux équipes data : environ 3 heures par semaine pour le responsable de la gouvernance des données chez Garance, un premier cas d’usage opérationnel en moins de 3 mois chez CANAL+.
• L’échelle change la nature du sujet : à plus de 500 cas d’usage data et IA gouvernés comme chez Sage, on gère un portefeuille, plus des livrables.
• Le test qui tranche : si personne ne peut nommer le propriétaire ni citer un deuxième consommateur, ce n’est pas un data product, c’est un rapport.

À quoi ça ressemble, concrètement

Un produit de données est un actif data packagé pour un besoin métier récurrent. Il combine des données, des règles de calcul, une documentation et une interface par laquelle on le consomme. Pour en être un, il doit avoir un responsable désigné, une qualité contrôlée et un cycle de vie. La notion et ses composants sont détaillés dans notre article sur ce qu’est un produit de données. Ici, place aux cas concrets.

Dix cas en un coup d’œil

Deux insights ressortent. Les actifs les plus fréquents ne sont ni des API ni des modèles, mais des jeux de données et des référentiels de définitions. Et leur valeur se mesure d’abord en temps rendu aux métiers.

Cinq familles, illustrées par des cas réels

Le jeu de données certifié : l’Open Data Mart de DataLab Group

Le type de produit le plus répandu : un périmètre nettoyé, documenté, certifié et mis à disposition d’autres équipes que celle qui le produit. Les référentiels issus du master data management (gestion des données de référence) en relèvent dès lors qu’ils sont exposés avec un contrat clair.

DataLab Group (Crédit Agricole), le hub d’innovation du groupe, en donne un exemple abouti. Son Open Data Mart centralise une quinzaine de sources avec leur documentation et, lorsque c’est nécessaire, leurs licences d’utilisation. La chaîne de transformation convertit 250 données brutes en 400 indicateurs, et plus de 100 assets prêts pour l’IA y sont documentés. Le détail qui change tout : comme les licences sont attachées aux sources, un profil de data science qui explore le mart sait facilement ce qu’il a le droit d’en faire, sans ouvrir de ticket juridique.

L’indicateur et la couche sémantique partagés : le référentiel d’Onet

Quand plusieurs entités juridiques calculent le même indicateur différemment, le livrable utile n’est pas un reporting de plus. C’est la définition elle-même, publiée et opposable.

Onet, groupe de services de 66 000 collaborateurs, a construit ce référentiel : 25 concepts clés centralisés, plus de 100 termes métier documentés, 60 indicateurs structurés et plus de 130 valeurs de classification harmonisées, pour plus de 60 utilisateurs actifs. La couche sémantique devient le produit. Les tableaux de bord n’en sont que des vues.

Gartner y voit une infrastructure critique à horizon 2030, au même titre que les plateformes de données et la cybersécurité : prioriser la sémantique dans les données prêtes pour l’IA améliorerait la précision des agents jusqu’à 80 % d’ici 2027, pour un coût réduit jusqu’à 60 %.

Le tableau de bord et le rapport réutilisables : ARTE et Getlink

Un tableau de bord bascule dans cette catégorie le jour où il repose sur des définitions certifiées, sert plusieurs équipes et relève d’un responsable identifié. C’est par cette catégorie de produits analytiques que passe le plus souvent la culture data driven (pilotée par la donnée).

ARTE a déployé 40 tableaux de bord et 32 rapports BI fiables, dans un contexte de sources dispersées : bases Oracle, API, plateformes web, outils tiers. Le référentiel a aussi servi la conformité au RGPD et donné une vision claire du stockage des données dans le cloud.

Chez Getlink, groupe de 3 500 collaborateurs propriétaire d’Eurotunnel et d’Europorte, le livrable est un rapport social consolidé entre les équipes françaises et britanniques. Il a fallu harmoniser les KPI et standardiser le vocabulaire avant de produire le moindre chiffre.

L’API, le score et la feature : les livrables documentés de FLOA

Cette famille regroupe ce qui est consommé par une machine plutôt que lu par un humain : une API, un score, une feature (variable d’entrée) exploitée par un modèle de machine learning (apprentissage automatique).

Chez FLOA, la documentation couvre explicitement ces livrables. Maxime Andrieux, Data Project Manager, décrit l’usage ainsi : « DataGalaxy a de nombreux usages pour FLOA : nous documentons nos tables de bases de données et nos tableaux de bord, nous assurons le suivi des exigences liées au RGPD, et nous documentons les fichiers transmis aux équipes métiers, comme les FAQ ou les scores. » Quatre modules sont déployés, du dictionnaire technique au glossaire métier, et les métadonnées sont synchronisées automatiquement via un connecteur Snowflake. Sans cette documentation, un score reste ingérable : personne ne sait sur quel dataset il a été entraîné, ni comment en obtenir une lecture fiable.

Le produit d’IA : la bibliothèque d’algorithmes de Swiss Life

Modèles prédictifs, assistants, moteurs de scoring : ces produits prédictifs, ou produits machine learning, sont des actifs à part entière, avec leurs jeux d’entraînement et leurs versions, par opposition aux produits analytiques qui décrivent le passé.

Swiss Life, sous l’impulsion de son Chief Data Officer Emmanuel Dubois, a constitué une bibliothèque d’algorithmes complète. Les définitions de modèles d’IA, jusque-là fragmentées entre 17 systèmes, sont centralisées et tracées de bout en bout. « Grâce à DataGalaxy, nous pouvons enfin tracer la donnée de bout en bout et identifier clairement les responsabilités », résume-t-il. La répartition des rôles entre IT, métiers, data et BI a été clarifiée dans la foulée, ce qui règle la question du « qui répond quand le modèle dérive ».

DataLab Group aborde l’objectif par l’amont : ses 400 indicateurs sont tracés depuis la donnée brute, ce qui rend auditable ce qui entre dans un modèle. Sage l’aborde par l’échelle, avec plus de 100 cas d’usage d’IA passés sous son modèle de gouvernance étendu, dans un portefeuille total de plus de 500 cas d’usage data et IA. L’équipe Data et IA de l’éditeur, présent dans 26 pays auprès de 2 millions de clients, le formule ainsi : « La traçabilité, c’est le moment où le portefeuille cesse d’être un inventaire pour devenir une stratégie. » Gartner prévoyait d’ailleurs en juillet 2024 qu’au moins 30 % des projets d’IA générative seraient abandonnés après le POC (proof of concept), faute d’une qualité suffisante en entrée.

Des exemples par secteur

Le même besoin ne produit pas le même actif selon l’industrie. Voici ce qui a été mis en place, secteur par secteur.

Ce que ces chiffres disent des avantages

Du temps repris. Chez Garance, le responsable de la gouvernance des données estime gagner environ 3 heures par semaine. Chez Getlink, les métiers sollicitent nettement moins l’équipe data : l’accessibilité de l’information et de sa définition ne dépend plus d’un intermédiaire.

De la vitesse de décision. Quand un indicateur est défini une fois pour toutes, la prise de décision ne commence plus par un débat sur le chiffre : chez Onet, 60 indicateurs structurés servent des entités juridiques multiples.

De la capacité à absorber l’IA. DataLab Group a rendu ses datasets exploitables par des projets d’intelligence artificielle avant même leur existence, et Sage a étendu son domaine de gouvernance à plus de 100 cas d’usage d’IA sans repartir de zéro.

Ce que ces exemples ne couvrent pas

Trois secteurs manquent, faute de cas documenté de notre côté : le retail, le secteur public et l’énergie. Les livrables classiques qu’on y rencontre (référentiel produit unifié, prévision de la demande) sont des illustrations de marché, pas des exemples clients vérifiés.

Anatomie de deux cas, composant par composant

L’Open Data Mart de DataLab Group

Le besoin. Le hub d’innovation du Crédit Agricole mène des projets d’IA pour le groupe, et chaque équipe repartait de zéro pour trouver des données exploitables, vérifier leur fiabilité et s’assurer du droit de les utiliser.

Les composants. Une quinzaine de sources centralisées et documentées avec leurs licences. Une chaîne de transformation qui convertit 250 données brutes en 400 indicateurs. Plus de 100 assets prêts pour l’IA, documentés selon trois modèles réutilisables adaptés aux données structurées, aux textes et aux images. Une traçabilité complète, de la donnée d’origine à l’indicateur consommé par un modèle.

Les consommateurs. Les équipes projet du groupe, qui explorent, évaluent et réutilisent ces ressources sans repasser par l’équipe qui les a produits.

Ce qui en fait un produit et pas un entrepôt. Un entrepôt assure le stockage, un data product s’engage : format standard, méthodologie labellisée et certifiée depuis 2022, conditions d’utilisation explicites, lineage remontant la chaîne en cas de doute. La différence ne tient pas à la technologie, elle est contractuelle.

Le rapport social consolidé de Getlink

Le besoin. Piloter la fonction RH sur deux pays qui ne comptent pas de la même façon : les équipes d’Eurotunnel et d’Europorte utilisaient des définitions différentes pour des indicateurs portant le même nom, et toute consolidation produisait un écart à expliquer.

La construction. Le travail a commencé par l’harmonisation des KPI, avant toute production de chiffres ; le vocabulaire métier a été standardisé des deux côtés de la Manche, puis la documentation a été centralisée dans un référentiel partagé.

Le résultat. Une mise en service en quelques mois. L’effet rapporté par Morade El Fahsi, Head of Data, est un gain de productivité : les équipes métier sollicitent beaucoup moins la sienne pour définir un KPI. Sur tout périmètre multi-entités, l’accord sémantique représente l’essentiel de l’effort ; l’architecture technique vient après.

Le test : data product ou simple rapport ?

Beaucoup d’organisations rebaptisent leurs livrables sans rien changer aux fondamentaux. Six questions permettent de trancher.

Sur ce dernier point, les organisations citées plus haut utilisent des indicateurs simples : le nombre d’utilisateurs actifs, plus de 60 chez Onet, et le nombre d’assets réellement réutilisés, plus de 100 au DataLab Group.

Projet ou produit

Un projet a une date de fin, un budget fermé et une équipe qui se disperse à la livraison. Un produit vit : roadmap (feuille de route), versions successives, budget récurrent, product manager et équipe financés pour son amélioration continue. La recommandation qui ressort des cas ci-dessus : financer un actif de ce type, ce n’est pas financer son développement initial, c’est financer les années qui suivent, faute de quoi les consommateurs repartent vers leurs extractions maison.

Data product ou data as a product

Les deux expressions ne désignent pas la même chose. Le data product est l’objet livré. Le « data as a product » (la donnée traitée comme un produit) est un principe d’organisation : traiter la donnée analytique produite par un domaine comme un produit, et ses consommateurs comme des clients. C’est l’un des quatre principes du data mesh formulés par Zhamak Dehghani, avec la propriété décentralisée par domaine, l’architecture data en libre-service et la gouvernance fédérée et calculable.

On peut construire ces actifs sans adopter le data mesh, et beaucoup des cas cités plus haut le font. L’inverse est faux : le data mesh de Zhamak Dehghani sans actifs consommables ne donne qu’un discours.

Par où commencer

Les cas d’usage les plus fréquents, en valeur et en faisabilité

Le premier choix n’est pas technique, il est d’arbitrage. Voici les livrables que l’on retrouve le plus souvent en début de démarche, avec une analyse croisée de la valeur et de la faisabilité.

Les cases valeur élevée et faisabilité élevée se traitent d’abord : ce sont presque toujours des référentiels de définitions, pas des modèles. Pour séquencer plusieurs actifs sur un an, l’exercice consiste à construire une roadmap de produits de données en croisant ces deux axes.

Choisir un besoin déjà exprimé

L’expérience des organisations citées le montre : elles ont démarré par ce que les métiers réclamaient déjà. CANAL+ a mis son premier cas d’usage en service en moins de 3 mois, Getlink son rapport consolidé en quelques mois. Bouygues Telecom a procédé en deux temps : un métamodèle d’entreprise, puis des cas d’usage ciblés. Ces quick wins créent la crédibilité qui financera la suite.

Nommer le propriétaire avant de construire

L’ordre des opérations varie peu. Désigner le responsable et les stewards, comme Garance l’a fait avant de centraliser ses règles de gestion. Définir l’interface, lister les consommateurs, s’accorder sur le vocabulaire avec l’aide d’un glossaire métier tenu à jour. Documenter l’actif dans un catalogue de données, avec son lineage, ses règles de qualité et ses conditions d’utilisation. Puis mesurer l’adoption, seule façon d’arbitrer entre faire évoluer l’actif et le retirer.

Adosser la gestion à un cadre existant

Inutile d’inventer une organisation dédiée : la gouvernance des données (data governance) en place fournit les rôles, les instances d’arbitrage et les processus de validation. Il reste à y ajouter un propriétaire par actif, un cycle de vie explicite et un suivi d’adoption efficace. Les composants et les phases sont détaillés dans le modèle de gestion des produits de données.

Au-delà d’une dizaine d’actifs, l’enjeu devient l’industrialisation, traitée dans notre guide sur une plateforme de produits de données. DataGalaxy permet de gérer vos produits data et IA dans un portefeuille unique, avec leurs propriétaires, leur cycle de vie et leur traçabilité, et de les exposer via une marketplace de produits de données où chacun explore le catalogue et obtient l’information utile. Cette approche data intégrée, dite Data & AI Governance, se joue là : gouverner données et usages d’IA dans le même référentiel, pas dans deux solutions séparées.

Points clés à retenir

• Cinq familles cartographient l’existant : jeu de données certifié, couche sémantique, tableau de bord et rapport BI, API et score, produit d’IA.
• Les cas réels valent mieux que les définitions : DataLab Group, Onet, ARTE, Getlink, FLOA, Swiss Life, Sage, Garance, CANAL+ ou Roche montrent ce que contient l’actif, qui le consomme et sous quelle forme.
• Les référentiels de définitions passent avant les modèles : les livrables les plus fréquents sont des jeux de données et des glossaires, pas des API ni des algorithmes.
• Le test tient en deux questions : nommez le propriétaire, citez un deuxième consommateur.
• Le gain se lit en temps rendu aux métiers : 3 heures par semaine pour le responsable de la gouvernance chez Garance, 75 % de rapports hérités en moins chez Sage.
• Commencez par un besoin déjà exprimé : un indicateur qui diverge entre entités, un reporting consolidé à la main, et nommez le propriétaire avant d’écrire la première ligne.

Reste le test le plus simple pour savoir où vous en êtes. Nommez le propriétaire de votre dernier livrable data, puis citez son deuxième consommateur. Si les deux réponses viennent sans hésitation, vous avez déjà un produit de données.

Title : Exemples de produits de données : 13 cas réels | DataGalaxy

Meta-description : 13 exemples de produits de données en entreprise : ce qu’ils contiennent, qui les consomme, les gains observés et par quel cas d’usage démarrer.

À propos de l'auteur: Max Faivre

Product Marketing Manager