GROUPE ASTEK

Gouvernance de la donnée ou architecture d’entreprise – Comment penser le futur ?

par | 9 Nov 2022 | Innovation

Data governance
Avec l’explosion de l’ère de la data, un certain nombre de concepts s’entrechoquent, tels que data governance, data lakes, data mesh, architecture d’entreprise, business architecture, protection des données… Entre peur de rater le virage, sollicitations des fournisseurs, paradoxe de la reprise économique et/ou de la crainte de la récession, les différents décideurs en matière de données sont poussés à prendre des décisions rapides sans avoir le temps de regarder dans le lointain.

Or c’est là que réside sans doute l’un des principaux risques liés au Big Data.

N’ayant pas le temps – ou plus exactement ne prenant pas le temps – de penser le futur, les décideurs tombent souvent dans la solution de facilité consistant à récupérer toute la donnée que l’on peut en se disant qu’on verra bien plus tard ce que l’on en fera.

Cette idée est même confortée par le discours même à la base des data lakes : ne sachant pas de quoi l’avenir sera fait, plutôt que de collecter uniquement les données dont on sait avoir besoin, collectons tout et on assure ainsi l’avenir.

Le syndrome du floppy disk

Mais cette idée séduisante contient un piège. La plupart d’entre nous sont – au moins sur un point – des collectionneurs compulsifs. On garde au fond du grenier des objets ou papiers dont on se dit que cela servira bien un jour peut-être – sait-on jamais. Et ce d’autant plus que le stockage nous semble « gratuit » (combien de photos numériques sur votre disque dur ?). Mais en réalité, à part pour nourrir notre nostalgie et nos souvenirs, notre collection de floppy disks n’a pas d’avenir. Car, entre retrouver comment les lire et trier ce qu’il y a dedans, nous n’irons jamais réellement les réutiliser.

Le Big Data véhicule le même risque, multiplié par un facteur google. Bien sûr les algorithmes cherchent bien plus vite que nous, mais il leur faut aussi savoir retrouver l’information utile. Et si le fichier sur la disquette de 1979 s’appelle juste save.txt il n’a plus d’autre valeur qu’une suite de 0 et de 1.

La gouvernance pour les nuls

Le principe même de la gouvernance de la donnée est d’éviter ce souci en attachant à chacune des giga données reçues chaque seconde l’information permettant de ne pas oublier ce que signifie réellement cette donnée. Historiquement les tables de bases de données et autres datawarehouses « réglaient » le problème en allant positionner chaque donnée reçue dans la bonne ligne et la bonne colonne qui définissait ce dont on parlait. Mais c’était très consommateur de ressources en prétraitement et surtout en stockage (une infinité de cases vides à conserver « au cas où »). D’où les solutions de type data lakes.

Expliqué très simplement, le principe des data lakes c’est juste de mettre toutes les données reçues les unes derrière les autres sans réel classement initial. Une sorte de log géant. En partant de l’idée que c’est a posteriori, quand on saura ce qu’on veut étudier ou calculer et qu’on rebalaiera le log pour faire les constatations nécessaires. Mais pour savoir quelle donnée relire, il faut donc, à réception, attacher immédiatement à chaque donnée un ensemble de métadonnées expliquant exactement ce qu’est cette donnée. Si cela semble « simple » techniquement, cela se complique philosophiquement.

La gouvernance pour les nuls

En effet, quand on range une donnée dans une ligne et une colonne, si à un moment la définition de la colonne ne fait plus de sens on peut sauver la table précédente, réorganiser les colonnes, etc. Mais avec les métadonnées, on ne peut pas – on ne doit pas – changer le passé. Donc la métadonnée qui avait été choisie à l’époque doit pouvoir être interprétable différemment selon la date à laquelle on la regardera dans le futur. Par exemple si une donnée représente un nombre d’employés ou de voitures à un moment donné. Qui sait ce que sera la définition de ces termes dans dix ans. De plus, avec la délocalisation et mondialisation des data lakes, les données sont utilisables de manière indistinctes sur le Cloud. Mais la notion d’employé ou de voiture peut être très locale.

L’argument bien entendu serait de dire que c’est au « propriétaire » de la donnée de fixer la métadonnée, mais on voit tout de suite le risque. Chacun a son propre vocabulaire, son propre agenda. L’idée sous-jacente étant que, de fait, il y aurait un data lake par propriétaire, chacun gérant sa propre sémantique. Et qu’on bénéficierait de la capacité d’aller interroger les data lakes des autres.

Mais on risque de mélanger les pommes et les poires. Aujourd’hui, un simple IoT compteur de passage peut envoyer son flux de données à cinq data lakes différents, qui vont « tagger » ces données différemment. Et si un tiers interroge ces différents data lakes comment va-t-il éviter les doublons si les « langages » ne sont pas communs ? La solution actuelle consiste à développer en gros des tables de traduction entre data lakes. On a déplacé le problème.

La valeur de la donnée tue-t-elle la donnée ?

Par ailleurs, chacun étant désormais conscient de la valeur de la donnée, il peut y avoir des freins à mettre trop d’informations – même cryptées – dans les métadonnées (environnement militaire ou financier, protection des données personnelles…).

Dans de nombreux départements d’entreprise, on est encore réticent à mélanger données personnelles des employés, données produits, données financières et données clients par exemple, et chaque « propriétaire » de données n’expose qu’une partie des données qu’il gère en interne. Dans le monde de l’ERP tous les processus d’entreprise sont plus ou moins silotés en symbiose avec des tables protégées donnant une information partielle plus ou moins historisée à chacun. Le basculement dans une vision métadonnées orientées vers le futur n’est pas réellement envisagé.

Data lakes ou data fakes ?

Autre écueil : qui est le propriétaire en charge d’associer la métadonnée, et en a-t-il le temps ou l’envie, pour la masse de plus en plus importante de données reçues en streaming continu, issue des réseaux sociaux ou des IoT.

Peut-on imposer à chaque internaute d’associer à chaque contenu une information descriptive exacte ? Et comment vérifier cette exactitude ? La plupart des contrôles étant désormais faits post stockage, quel sera le niveau de corruption de nos grands lacs de données ?

En matière d’IoT, la question de la propriété de la donnée est encore plus sensible. Si le GPS de votre voiture de fonction envoie une information à votre entreprise, qui est en charge de rajouter la métadonnée, sachant que chacun aura son propre vocabulaire, lié à sa propre vision du futur et de ce qui pourrait lui servir plus tard : l’équipementier qui a construit le GPS, le constructeur de la voiture, vous-même, votre entreprise…

Data visionnaire, un métier d’avenir

Malheureusement, les nouveaux métiers « à la mode », tels que l’Architecture d’Entreprise ou la Business Architecture sont encore très orientés court terme. On réalise des modèles descriptifs des métiers pour documenter la performance opérationnelle et mettre en place des plans d’actions (pas uniquement IT) pour l’améliorer. On reste dans l’analyse de l’existant ou du besoin et pas dans la prospective.

De même, les data analysts, data scientists et autres sont souvent dans l’optimisation des process data (collecte, nettoyage, traitement…) en vue d’optimiser le résultat courant ou de répondre à un besoin exprimé plus que dans la réflexion sur ce que devrait être à terme une sémantique universelle et pérenne de la métadonnée.

Le risque est connu : les grands du Metavers, afin de proposer à chacun un accès aisé aux data lakes des autres, finiront par nous imposer à tous une nomenclature unique. On est prévenu, la notion d’employé ou de voiture sera ce que les GAFAM en feront, ce qui de fait poussera nos décisionnaires, qui verront les chiffres générés par ces définitions, dans certaines directions. A moins de développer un vrai savoir-faire prospectif sémantique universel.

En attendant, allons relire les étiquettes de nos floppy disks pour nous rappeler à quel point prédire ce que seront nos besoins de tris dans dix ans nécessite sans doute plus de temps que l’on y consacre réellement.