Data / IA
Trois bonnes pratiques pour faire décoller les projets autour d’un datalake
Par La rédaction, publié le 21 juin 2019
Un datalake n’est réellement pratique et efficient que s’il fournit des informations de confiance. Encore faut-il savoir le bâtir en ce sens. Voici quelques conseils à garder bien en vue…
Par François Bouteyre, directeur conseil en charge de l’offre Data chez CGI Business Consulting
Pour qu’il soit réussi, un datalake doit garantir aux utilisateurs que les données sont de confiance. L’expérience du terrain montre que l’application de trois bonnes pratiques permet d’obtenir cette garantie. Elles concernent l’urbanisation du datalake qui doit se faire en couches, sa gouvernance qui doit mettre en oeuvre un véritable langage d’entreprise et, enfin, sa responsabilité qui doit sortir du giron de l’informatique pour mieux coller aux attentes des métiers.
Une urbanisation en quatre couches pour sécuriser les données dès le départ
L’enjeu d’urbaniser un datalake en quatre couches est de faciliter la gestion des données et de sécuriser au plus tôt les informations. La sécurité est essentielle pour connecter un écosystème de partenaires aux applications des métiers et ainsi ouvrir les vannes d’une multitude de projets. D’ordinaire, les premiers projets bâtis sur un datalake ne tiennent pas vraiment compte de la sécurité, car les équipes ont surtout vocation à valider la faisabilité technique. Le problème est que tous les projets suivants se construiront sur le modèle des premiers et il sera alors particulièrement difficile d’introduire a posteriori des processus comme la gestion des droits d’accès.
Un datalake se compose traditionnellement de deux couches : la première est celle qui reçoit les données brutes, la seconde celle qui contient des données raffinées (avec un format normalisé pour toutes les données de même nature et élimination des doublons).
Mais pour passer véritablement au stade industriel, il faut aller plus loin en sécurisant ces données puis en les présentant au format de l’utilisateur. Ainsi, une troisième couche devrait contenir des données enrichies, qui découlent de traitements, tandis que la quatrième présentera des informations directement utilisables par les applications métier.
L’intérêt de procéder ainsi est que les couches 3 et 4 ne se sécurisent pas de la même façon que les précédentes. On bénéficiera donc d’un choix plus large de points d’accès aux données et on pourra offrir le niveau de raffinage le plus adapté aux divers cas d’usage.
Certains opposeront à cette structure en quatre couches le défaut de stocker des informations redondantes. Néanmoins, le prix du stockage a tellement chuté que, finalement, il est économiquement bien plus rentable de créer de la redondance pour rendre les données plus rapidement exploitables.
Des règles pour cataloguer les informations afin d’éviter les dérives locales
La seconde bonne pratique à appliquer est de cataloguer systématiquement les données qui arrivent dans le datalake selon un vocable commun à toute l’entreprise. Grâce à cette gouvernance, toutes les personnes qui exploitent les données pourront toujours les réinjecter facilement dans leurs processus métier.
La difficulté d’élaborer un langage commun pour cataloguer l’information est que tout le monde veut produire un indicateur selon l’angle qui l’intéresse le plus. Il faut donc unifier et clarifier à la fois les règles et les définitions, et définir un langage unique transverse à l’entreprise.
La solution pour résoudre les conflits entre les services qui veulent imposer leurs règles locales pour cataloguer l’information est d’en appeler au sponsoring de la direction générale, qui édictera la règle.
Un Chief Data Officer juge de paix entre l’IT et les métiers
La troisième bonne pratique consiste à sortir la donnée du monde de l’IT pour la faire entrer dans celui des métiers. Pour battre la mesure entre l’IT et les métiers, et éduquer sur l’utilisation des données, la solution usuelle est de nommer un Chief Data Officer. Celui-ci s’interfacera avec une quantité de fonctions au sein de l’entreprise : des data managers (qui décident de l’utilisation des données), des data owners (qui décident qui accède aux données), des data stewards (qui mettent en oeuvre les règles de gouvernance) et des data architects (qui structurent les données).
L’une des questions principales est de savoir à qui reporte le CDO. Tout dépend de la valeur que l’entreprise accorde au patrimoine informationnel : plus elle juge que les données sont critiques pour son activité, plus le CDO incarnera une vraie direction opérationnelle. De même, selon la culture de l’entreprise, le CDO aura soit un poste hiérarchique, soit un rôle transversal. Encore une fois, il s’agit de trouver le compromis qui stimule le plus la confiance des métiers.
