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.

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. 

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