Article

Gouvernance de la donnée et réurbanisation du Système d'Information

Nombreuses sont les entreprises à réfléchir à leur stratégie data. Dans ce billet, nous revenons sur les principes qui sous-tendent la mise en place d’une gouvernance durable de la donnée. Et nous montrons la nécessité d’accompagner la démarche d’une réurbanisation du SI pour l’orienter services (SOA - Service Oriented Architecture).

Les entreprises l’ont bien compris : la donnée devient une matière première indispensable à leur activité ; et savoir l’utiliser, un atout pour se différencier. D’où leur besoin de se doter des moyens et de l’organisation qui les assurent de tirer le meilleur parti de ce patrimoine. Une gouvernance de la donnée, puisqu’il s’agit bien de cela, vise à rendre la donnée visible et accessible à tous les collaborateurs autorisés, à garantir sa qualité et sa conformité (au RGPD, par exemple) et à mettre à disposition des outils pour l’exploiter. Sa mise en place repose sur trois piliers.

Pilier n°1 : la définition des rôles et des responsabilités

Le premier – d’ordre organisationnel – consiste à instaurer les rôles et responsabilités des acteurs qui vont intervenir dans la chaîne de traitement de la donnée, de sa production jusqu’à sa fin de vie. Parmi ces rôles, on identifie :

• Data Officers, qui définissent la stratégie globale vis-à-vis de la donnée de l’entreprise et qui ont une vue sur l’ensemble de la chaîne 
• Data Owner, qui porte la responsabilité de la donnée pour un domaine (la donnée client ou la donnée de gestion, par exemple) 
• Data Steward, dont le rôle est de mettre en œuvre la politique de gestion de la donnée définie par le Data Owner.

Viennent ensuite des rôles plus techniques tels que le Data Engineer, qui va s’occuper du transport et de la mise en qualité technique des données. Les périmètres de responsabilité et dénominations des rôles peuvent varier selon les entreprises. Ces acteurs peuvent être rassemblés dans une unité créée à cet effet.

Pilier n°2 : la mise en place de processus

Le deuxième pilier, ce sont les processus mis en œuvre et les règles à appliquer pour s’assurer, comme on le disait plus haut, de la qualité et de la conformité des données produites. Ainsi, la sensibilisation des producteurs aux conséquences de la non-qualité des données, accompagnée de la diffusion d’une procédure de saisie aidera à éviter les doublons et les erreurs. Le partage de bonnes pratiques de conception des applications et des modèles de données évitera les lacunes. Au-delà des questions de qualité, il est important également de faire connaître aux utilisateurs l’existence des données disponibles et de leur fournir les moyens d’y accéder et de les utiliser.

Pilier n°3 : l'utilisation des bon outils

Le troisième pilier d’une gouvernance, c’est l’outillage associé, dont les deux pièces essentielles sont le data dictionary et le système de gestion des données de référence de l’entreprise (Master Data Management, MDM). Le premier, appelé également glossaire des données, contient toute la connaissance sur les données de l’entreprise : leur signification et leur filiation. Il recueille ainsi leur définition précise (un chiffre d’affaires s’entend hors taxes, par exemple), leurs sources ainsi que les transformations subies pour leur mise en qualité.

Le deuxième, le Master Data Management, concentre l’ensemble des données utilisées transversalement, c’est-à-dire par différents départements et applications de l’entreprise. On pense à la donnée client ou la donnée fournisseur, par exemple. Le mérite du MDM est d’assurer l’unicité et l’univocité de ces données à travers toute l’entreprise. Il reçoit les données mises à jour qu’il communique aux applications qui les utilisent.

Quel est l’enjeu d’une architecture orientée services ? 

Et c’est là qu’intervient la question de l’urbanisation du SI. Deux cas se présentent. Premier cas : le SI est organisé en silos de systèmes applicatifs. Dans cette configuration, le MDM doit connaître toutes les applications qui utilisent des données de référence et établir des connexions bilatérales avec chacune d’elles pour leur communiquer les données. Cette approche présente l’inconvénient d’être peu évolutive, puisque chaque changement dans le SI (ajout d’une application, par exemple) affecte le MDM. Et vice-versa.

Deuxième cas : l’architecture du SI est orientée service (SOA, Service Oriented Architecture). Le SI est modulaire. Il est constitué de composants qui s’échangent des services et des données par l’intermédiaire d’un nœud de communication (Enterprise Service Bus). Le nœud orchestre les relations de part et d’autre, via des interfaces normalisées appelées API (Application Programming Interface). Le MDM devient alors un composant comme un autre qui publie les mises à jour de ses données via l’Enterprise Service Bus, indépendamment des applications qui sollicitent ces mêmes données. Nous recommandons, bien sûr, la deuxième approche qui, grâce à ce couplage lâche entre le MDM et le SI, présente l’avantage d’une architecture flexible et évolutive.

On le voit donc, pour bien faire, la mise en place d’une gouvernance de la donnée dans l’entreprise, et donc d’un MDM, implique, si cela ne l’a pas déjà été fait, de revoir l’urbanisation de son SI pour l’orienter services. Les deux projets peuvent se mener en parallèle. Ils s’avèrent en fait les deux volets essentiels d’une démarche de transformation du SI qui doit conduire à le convertir en une plateforme ouverte et centrée sur la data, gage de sa réelle capacité à accompagner la digitalisation des activités de l’entreprise.