Retour au numéro
Vue 5 fois
22 octobre 2022

DONNEE PRODUITE, DONNEE-PRODUIT
INVERSER LA LOGIQUE DE DÉVELOPPEMENT

Bonne nouvelle : nous avons désormais le recul pour comprendre pourquoi un projet Big Data peut ne pas apporter la valeur attendue. Autre bonne nouvelle : corriger le tir n’est pas que technologique. Si on s’y mettait ?

 

 


Un ancien patron, brillant ingénieur issu d’un de nos plus prestigieux corps de l’État, m’a affirmé récemment « le numérique, je n’y connais rien, et cela ne m’intéresse pas » puis a ajouté « il me faut des outils de transformation digitale… un parapheur électronique par exemple ». Le numérique demeure décidément une zone en friche de l’intelligence collective des organisations ! Cet échange illustre aussi l’appétence continue pour une approche technologique quand le problème est ailleurs. Le monde bouillonnant du Big Data et de l’Intelligence Artificielle (IA) est particulièrement touché.

C’est entendu, la donnée est fondamentale pour tous les secteurs d’activité, et on nous assène qu’elle est en croissance si rapide que nous aurons besoin de l’IA pour en tirer quelque chose. Signe des temps, dans sa nomenclature RH version 2018, le Club Informatique des Grandes Entreprises Françaises (CIGREF) a caractérisé 5 nouveaux métiers qui lui sont consacrés.

Les ambitions sont importantes, les financements aussi. Les projets Big Data et IA abondent. Les praticiens disposent aujourd’hui de suffisamment de recul sur les succès et échecs pour identifier les règles spécifiques à suivre pour que les investissements aient une chance d’être rentables. Un chef de projet expérimenté doit les connaître, et gérer les risques associés quand elles ne sont pas respectées. Je vous en propose quelques-unes, susceptibles parfois de surprendre quelques théoriciens, et moins les praticiens. 

Une donnée partagée gérée comme une donnée-produit

Les principes et exigences du management de la qualité s’appliquent pleinement à toute donnée dont la qualité est importante pour un processus. En pratique cette donnée doit être gérée comme un produit (donnée-produit dans la suite). Cela semble une banalité. Pourtant c’est rarement le cas.

Exemple d'une donnée produit : les données de paie

Les systèmes d’information RH du ministère des armées gèrent des milliers de types d’informations différentes. Ils doivent évoluer aussi bien avec la réglementation qu’avec les besoins de gestion du ministère. Leurs données ne sont pas toutes des données-produits, à commencer par celles qui ne sont échangées avec personne.

Les données échangées avec le système de paie sont certainement des données-produits. L’exemple est un clin d’œil à la rédactrice en chef déléguée de ce numéro.  

Un chef de projet informatique a pour expérience de considérer le système résultant du projet comme un produit, et ses données les artefacts nécessaires à son fonctionnement. Pourtant, si l’objectif du projet informatique est de construire un modèle issu d’un apprentissage non supervisé, alors cela fait sens de considérer le modèle comme une donnée-produit. Le code et les données ayant servi à le construire sont ses artefacts.

Il est fondamental en début de projet d’identifier chaque donnée-produit, de la singulariser en lui donnant un nom de produit, et de la gérer comme telle, y compris en identifiant nominativement son propriétaire. La notion de propriété dépasse la durée de vie du projet car elle couvre le cycle de vie du produit.

Si des données externes sont amenées à être consommées par le système, il importe de vérifier qu’elles sont bien gérées comme des données-produits. Un risque projet et organisationnel doit être identifié et géré si ce n’est pas le cas.

Un métier responsable de ses données-produits

L’identification d’un propriétaire de donnée-produit représente une difficulté dans bien des organisations. Il ne doit portant pas être considéré que cette mission nécessite une compétence particulière, forcément rare, donc mutualisée et centrale. Et ce même si les praticiens de la Gestion des Données de Référence et du référentiel unique argumenteront en faveur d’une démarche centrale. 

 

Data lake et déchetterie

Les projets de Data Lake favorisent la centralisation de la donnée : le concept dominant détermine que chaque système source déverse ses données étiquetées dans le Data Lake sans plus s’en préoccuper, et à partir de là une organisation qualifiée prend la main pour en tirer quelque chose : Data Steward, Data Engineer, etc.

Un Data Lake opéré ainsi est à la valorisation de la donnée ce que la déchetterie est à la valorisation des déchets. Il est utile d’avoir ce parallèle en tête pour comprendre pourquoi les projets de Data Lake ont un mauvais retour sur investissement. L’usage est en cause, pas la technologie. 

Il est toujours préférable pour un chef de projet de s’assurer que son client nomme un propriétaire disponible, connaissant le métier représenté par les données, et intéressé par la qualité de sa donnée-produit. S’il est débutant, sa formation peut relever d’une démarche centrale. L’absence de nomination doit être gérée comme un risque projet et un risque organisationnel à long terme, que les archivistes connaissent bien.

Une gouvernance imposant des règles simples ou informatiquement applicables

Les données-produits ayant vocation à être consommées, il importe de standardiser la façon de les décrire et de les consommer. Cette standardisation est le fruit d’une gouvernance qui peut être centrale ou fédérée.

Quels que soient les produits de cette gouvernance, il importe que les règles qui s’appliquent aux organisations et chefs de projets soient simples ou, pour celles qui ne le sont pas, informatiquement outillées. Les règles complexes portent typiquement sur les listes de métadonnées descriptives, types de données, ontologies, formats, protocoles, politiques d’accès, mesures de qualité.

Pour le chef de projet et le propriétaire de donnée-produit, il s’agit d’utiliser les règles quand elles existent, et à défaut de documenter celles mises en place. Le fait de documenter les règles permet de les faire évoluer en maîtrisant l’impact sur les données-produits.

Une plateforme facilitant la standardisation des données-produits

Il n’existe pas de standard de l’industrie en matière de gestion de données-produits, et donc pas de plateforme sur étagère immédiatement utilisable pour faciliter le travail des propriétaires de données (les catalogues de données centralisés ne sont ni nécessaires, ni suffisants). De nombreuses initiatives émergent, y compris au niveau européen. Au sein du MINARM, le projet Artemis.IA, plateforme de traitement massif de données et d’intelligence artificielle, comporte un volet structurant de gestion des données-produits et de leur sécurité.

L’absence de plateforme n’est ni un obstacle au respect des règles indiquées plus haut, ni un prétexte pour avoir une approche technologique à une question avant tout organisationnelle.

Vers le Data Mesh

Les règles précédentes sont documentées dans l’ouvrage Data Mesh, publié par Zhamak Dehghani en 2019. Sa lecture est recommandée à toute personne abordant un projet data, car cet article n’a fait qu’en survoler les motifs fondamentaux.

Pour en savoir plus :https://martinfowler.com/articles/data-mesh-principles.html 

 

 Data mesh

Dernier né des concepts d’architecture, le Data Mesh remédie aux défauts aussi bien du data warehouse, dans lequel la gestion des données issues de grands systèmes est confiée à des spécialistes, et le data lake, dans on peut accéder à l’ensemble des données, mais sans disposer d’outils de gestion performants. Créé en 2019, deviendra-t-il le prochain standard ? 

 

 

 

 Fabrice Lefebvre, ICA, consultant

Fabrice Lefebvre a 30 ans de carrière au profit de l’informatique du ministère des armées, où il a occupé successivement des fonctions de direction de projets, d’établissement, du Système d’Information (DIRISI). Il a été Directeur des Systèmes d’Information du CEA. Il conseille ATHEA, co-entreprise THALES et ATOS, créatrice d’une solution de Big Data Souverain de portée européenne.

Auteur

Commentaires

Commentaires

Vous devez être connecté pour laisser un commentaire. Connectez-vous.