Bonjour,

Aujourd’hui je voudrais vous parler d’un nouveau ~~bobo~~ concept d’IT – « data product ».

Ce concept se propage très rapidement : plus ou moins toutes les parties intéressées ont déjà publié ses livres blancs sur le sujet « Data is/as a product » (« Données en tant que/sont un produit »).

La logique des publications est simple : A (data) ressemble à B (produit), B possède la propriété C (valeur), donc, A doit aussi avoir la même propriété C.

Voici les liens « évidents » entre « data » et « product » :

Data Quality = Qualité de produit;
mise en place d’une solution = développement d’un produit;
les deux ont le coût de production;
les deux nécessitent des outils;
les deux peuvent être réutilisés;
etc (j’en trouve 137¼ similarités)

Il semble, donc, logique que si pour un produit nous pouvons estimer sa valeur, il est également possible d’estimer la valeur intrinsèque de données. De même, nous pouvons probablement manipuler et organiser des données comme on manipule des produits…

Par contre, si les données = un produit, il est très étrange, ce produit :

dans 99% il intéresse vous et seulement vous (produit = carte postale fabriquée par votre enfant),
il faut passer du temps pour y trouver quoi qu’il ce soit (produit = vieux garage/grenier),
souvent fait avec des pieds des stagiaires,
la « qualité » n’est pas garantie par la production (à delta des cas rares), mais par un processus de remédiation (comme si vous achetez votre burger et puis vous recevez des morceaux oubliés par courriers durant les mois qui suivent),
etc

Bref, si les données = un produit, ce dernier est souvent peu attractif, sauf si vous êtes Google, Netflix ou encore Wikipedia et vos données ont une vraie valeur pour des chercheurs… voire vos données peuvent même être monétisables (mais ce n’est pas garanti).

Vous pouvez certainement dire que la valeur existe que pour votre société et pour vos processus. Mais dans ce cas ne vous vous mentez pas – vos données ne sont pas un produit mais plutôt vos outils ou pièces détachées des systèmes.

Je pense qu’ici nous avons l’affaire avec une apophénie (i.e. « nous établissons des liens entre des éléments qui ne sont là que par hasard »). Et je peux prouver ainsi que des données sont par exemple, un œuf :

des données sont réutilisables et peuvent servir pour préparer des différents « plats », juste comme un œuf,
des données aussi bien qu’un œuf peuvent exister en différentes formes, qualité, origines et tailles,
pour s’en servir des données, il faut faire un effort, de même qu’il faut faire cuir un œuf et l’écaler avant de le manger,
vous ne savez jamais ce que vous allez trouver dedans avant l’écaler,
juste comme vous n’allez pas manger un œuf périmé, vous n’allez pas vouloir utiliser les données de mauvaise qualité,
beaucoup dépend de chef,
des œufs sont rarement suffisants pour faire un plat complet,
etc.

…d’où la conclusion : arrêtons-nous de mettre tous les œufs dans le même panier, apprécions les différences, etc…

Il me semble que ça marche aussi bien, eh ?

Cui bono ?

Les consommateurs majeurs de ces livres blancs sont :

les DSIs malins qui peuvent dire « nous ne sommes pas les centres de coût car nous produisons de la valeur… vers 2030 vos données se retrouveront dans une ligne de balance comptable – et vous allez voir… » ;
les « architectes » sortis des nombreuses « écoles d’informatique, commerce, bowling et tire-à-l’arc par correspondance » qui permettent aux éditeurs de vendre encore plus d’outils.

Autrement dit, « données est un produit » est une expression de pure marketing et n’a rien à voir avec l’ingénierie. Cela fera du bien aux éditeurs et aux ESNs de semer cette idée (mediavirus) dans les têtes de vos architectes et de vous vendre des nouveaux produits encore moins liés à la réalité.

Bonne santé à vous et à vos systèmes.