Data Gouvernance : la difficulté de définir

J’ai parlé récemment avec une société qui s’est lancé dans un projet de mise en place d’un catalogue de définitions pour l’ensemble des notions métiers employés (Dictionnaire Data Governance). C’est probablement un sujet encore plus complexe que l’analyse de données ou la gestion de la qualité de données.

Il y a bien quelque chose qui l’explique, cette complexité ? Selon moi, la raison provient de notre langage, pratiqué depuis l’enfance. Nous le prenons pour quelque chose d’acquis ou d’universel mais nous ne nous rendons plus compte à quel point cela peut être flou et imprécis.

En effet, quand nous parlons d’un dictionnaire et d’une définition, nous essayons de construire l’algorithme le plus précis possible de la définition du « mêmetude ». Par exemple, nous définissons un « client », donc notre définition s’apparente à un algorithme pour distinguer les « clients », des « prospects » ou « d’anciens clients qui ne le sont plus », etc. Nos « clients » partagent un trait qui est le « même » pour ce groupe et « différent » pour un autre.

Est-ce que c’est aussi facile de décrire ce trait de « mêmetude » ? Afin de vous vacciner contre la prise à la légère de cette opération, et, pour vous montrer quelques difficultés souvent rencontrées, j’ai préparé un certain nombre d’exemples. Commençons par le début…

L’humain

Depuis au moins 2000 ans, nous faisons face à la difficulté de nous donner une définition, voici une anecdote préservée qui l’exprime parfaitement :

Platon ayant défini l’homme comme un « bipède sans cornes et sans plumes », le jour suivant, Diogène se promena dans la ville en tenant à la main un coq déplumé aux ergots coupés, et déclarant : « Voici l’homme de Platon ! ».

Essayez vous-même ! En attendant, je vous donne d’autres exemples…

C’est à la rue…

Essayons ensemble de donner une définition à la « rue » comme un « espace de circulation qui dessert habituellement les logements… ». Chaque rue a un « type » : « rue », « ruelle », « impasse », « avenue », « boulevard », « promenade », etc. Chaque « rue » fait partie d’une région, d’un pays.

Avec une définition, nous pouvons produire et documenter un modèle de données pour l’objet « rue », définir les règles de qualité de données… Sauf qu’il existe des cas complexes – est-ce que « Waneta Hwy » (Canada) et « Northport-Waneta Rd » (Etats Unis) sont une seule et même rue ou bien deux rues différentes ?

Suivant notre définition, ce sont deux différentes rues. En revanche, sur place, si vous passez par l’une, vous ne pourrez pas forcément dire quand elle se finit et quand se commence l’autre…

On se dit rendez vous au début de la semaine prochaine ?

Avez-vous remarqué que cette expression est aussi floue ? Et bien oui, les semaines ne commencent pas toutes le même jour suivant le pays où l’on se trouve !

Ici en bleu – pays où la semaine démarre le dimanche, orange – lundi, rouge – vendredi, vert – samedi. (Données Common Locale Data Repository)

Avec cette information, et dans un contexte internationale, que veut bien dire l’expression « d’ici la fin de semaine » ou « début de la semaine » ?

My name is…

Nous avons l’habitude de nommer ce qui est important pour nous – des personnes, des animaux, des sociétés, etc.

Mais en fait, c’est quoi, un « prénom » ? Supposons que votre prénom est « Mikaël », mais si vous viviez en Norvège, en Allemagne, en Grèce, au Portugal ou encore en Estonie, cela pourrait bien être « Michael », « Mikael », « Michel », « Mikhail », « Misha », « Mitchell », « Miķelis », « Mihkel », « Mikel », etc.

Informatiquement parlant, en revanche, ce sont les lignes de caractère différentes. Que veut bien dire « avoir le même nom » dans ce cas ? Pourquoi donc « Mikaël » est le même nom que « Misha », mais « Mikaël » n’est pas « Mikaëlle » ?

Si vous pensez que vous n’avez pas besoin de vous poser cette question – imaginez un instant que vous mettez en place un outil (MDM) vous offrant la possibilité de rapprocher les données d’un patient A de l’hôpital de la Timone à Marseille, du patient 2 de Georges Pompidou à Paris. Intéressant, mais pour quelle utilité ? Retrouver le passé. Comme par exemple, le résultat de ce test fait à la Timone, réalisé 2 ans auparavant, sous le prénom de « Misha » (au lieu de « Mikaël »). L’information était cruciale pour la réussite d’une opération chirurgicale complexe et le rapprochement a permis à l’équipe d’accéder à ce test et d’en tenir compte. Moralité : « Misha » et « Mikaël » sont la même personne. Avec un MDM, que ce soit dans une mutuelle ou un hôpital, les règles d’identification des adhérents / patients nécessitent des définitions très claires.

Un autre exemple de « nom », cette fois plus complexe… Chaque société juridique en France a un code TVA. Ce code TVA nous permet de distinguer une société d’une autre (même si elles ont le même « nom » aka « raison sociale »). Nous pouvons dire donc dire que le code TVA est le nom (l’identifiant) de la société.

En même temps, nous pouvons définir la société par les collaborateurs qui y travaillent. Nous pouvons faire la liste de tout personnel de la société et définir la société en faisant la liste des collaborateurs.

Supposons maintenant que la société change sa forme juridique – et je connais quelques exemples – par conséquent, son code TVA aussi, pourtant rien n’a changé pour les collaborateurs. Ils peuvent même ne pas percevoir le changement. Est-ce que nous parlons toujours de la « même » société ou pas ? Que mettrez-vous dans la définition dans votre dictionnaire pour une « société » ?

C’est le même client

Nous avons déjà vu deux types de problèmes : problème de définition « être X » et le problème de distinction entre « être X » et « ne pas être X ». Je vous propose un exemple plus complexe – comment le CRM a raté la possibilité de remplacer le MDM.

Considérons l’une des solutions les plus connues du monde CRM – Salesforce. Vous pouvez facilement trouver la documentation et dedans le modèle de données suivant :

Regardez bien – et vous trouverez deux objets qui vont nous intéresser :

• account (compte), qui, suivant la documentation « représente » un compte individuel, i.e. une organisation ou une personne physique liée à votre business (client, compétiteur ou partenaire),
• contact, qui « représente » un contact, i.e. personne liée au compte.

Nous faisons face ici aux premiers problèmes avec les définitions : visiblement, une personne physique peut être à la fois un contact et un compte, mais comment faire la différence ? Une organisation (une filiale par exemple), suivant ce modèle, peut donc faire partie d’une autre organisation ?

Mais en fait, ce n’est pas le plus grand problème ici. Ce que sera important pour nous se trouve plus loin dans le modèle, notamment un compte dispose d’un attribut OwnerId :

Dans ce cas, il faut lire qu’il existe un « propriétaire ou créateur » de chaque « compte » (ou client). Dit autrement, cela signifie que si nous avons le moindre problème avec le « propriétaire » du « compte », les utilisateurs vont créer un autre « compte ». Désormais, dans votre CRM, vous avez deux organisations qui sont « identiques, mais en même temps, différentes ». Cela implique qu’au moins à cause de ce type de problème, les données CRM seraient inutilisables pour faire de l’analyse financière qui nécessite en effet un niveau de détail « par société », par exemple.

Vous pouvez penser que ce problème est « imaginaire », mais en fait ce n’est pas le cas – cela peut bloquer des grands projets de modernisation de SI.

Nous nous retrouvons donc dans la situation d’une définition « implicite » donnée par le modèle de données et par les processus fonctionnels qui sont liés aux limitations de ce modèle. Etrange, n’est-ce pas ?

J’espère que j’ai réussi partager avec vous ce sentiment que le dictionnaire Data Gouvernance ne se construit pas facilement entre deux réunions mais nécessite une vraie réflexion de fond.

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