Les grandes organisations ne manquent pas de données ; ce qui leur manque, c'est l'accès à ces données. Chaque service tire ses rapports de sa propre base, l'équipe analytique doit obtenir autorisations et extractions auprès de plusieurs propriétaires de données pour chaque nouvelle question, et lorsque deux rapports affichent des chiffres différents pour un même indicateur, des semaines passent à en chercher la raison. L'entrepôt de données traditionnel a résolu une partie du problème, mais pour les données semi-structurées, les événements de capteurs, les images et le texte, ou pour les charges d'apprentissage automatique, sa structure rigide et son coût deviennent l'obstacle.
L'enjeu s'est démultiplié avec l'arrivée de l'IA dans l'entreprise. Les modèles ont besoin de données historiques, variées et de qualité connue, et doivent pouvoir accéder aux données brutes, et pas seulement aux synthèses des rapports. Les exigences d'audit et de responsabilité imposent en outre qu'une organisation puisse dire de quelle source, par quelle transformation et à quel moment un chiffre d'un rapport a été produit. Un data lake bien construit répond à ces deux besoins : un accès large pour l'analyse et la modélisation, et un lignage clair pour la confiance.
Un data lake moderne est généralement conçu en plusieurs zones successives. La zone brute conserve les données exactement telles qu'elles sont arrivées de la source, que ce soit par chargement par lots ou par flux d'événements. La zone nettoyée reconstruit les données avec un schéma explicite, des types standard et des clés de référence telles que l'identifiant de référence unique du tiers. La zone organisée construit des modèles de données thématiques, comme le client, la transaction ou la parcelle, destinés à l'analytique, aux tableaux de bord et aux modèles. En parallèle, un catalogue de données recense les jeux de données, leurs propriétaires, leur qualité et leur lignage, et une couche d'accès applique les autorisations par rôle.
La première considération pratique est la propriété et la qualité. Chaque jeu de données du data lake doit avoir un propriétaire nommément désigné au sein des métiers, responsable de sa définition, de sa qualité et de son cycle de vie. Les règles de qualité, telles que la complétude, l'unicité et les plages autorisées, doivent s'exécuter automatiquement à chaque chargement, et leur résultat être publié dans le catalogue. Par exemple, si le chargement quotidien des transactions arrive soudain avec la moitié de son volume habituel, le système doit déclencher une alerte avant l'actualisation des tableaux de bord, plutôt que de laisser les dirigeants découvrir un chiffre erroné le matin.
La deuxième considération est le lien avec le référentiel des tiers et avec les événements. Un data lake qui stocke les données sous les identifiants locaux de chaque système n'a fait que rassembler la fragmentation en un seul endroit. La véritable valeur apparaît lorsque, dans la zone nettoyée, chaque enregistrement est relié à l'identifiant partagé de la personne, du produit ou du lieu. Alimenter le data lake par la plateforme d'événements, plutôt que par extraction directe depuis les bases opérationnelles, réduit en outre la charge sur ces systèmes et fait passer la fraîcheur des données d'une actualisation nocturne à un quasi temps réel, ce qui change les usages possibles du data lake.
La troisième considération est la consommation. Un data lake utilisé uniquement par l'équipe données a échoué. La couche de restitution doit offrir des tableaux de bord et des rapports aux dirigeants, des requêtes interactives aux analystes et un accès programmatique aux data scientists et aux modèles, le tout sur une définition partagée des indicateurs. Une couche sémantique qui détient la définition officielle de chaque indicateur évite qu'un même concept soit calculé différemment selon les endroits et supprime à la racine le débat sur le rapport qui affiche le bon chiffre.
Les écueils courants sont connus. Premièrement, le marécage de données : tout déverser sans catalogue, sans propriétaires ni règles de qualité, jusqu'à ce que plus personne ne sache ce qui se trouve où ni à quoi se fier. Deuxièmement, construire le data lake comme un projet informatique sans cas d'usage métier précis, ce qui aboutit au bout d'un an à une masse de données sans consommateurs. Troisièmement, négliger le contrôle d'accès au niveau des colonnes et des lignes, ce qui fait du data lake le principal point de fuite de données sensibles de l'organisation. Quatrièmement, ignorer le coût du stockage et du traitement qui, sans politique de rétention, croît sans limite.
Chez Niadad, la plateforme Darya («دریا») est le data lake de l'entreprise : zones brute, nettoyée et organisée, catalogue de données avec propriétaires et lignage, règles de qualité automatisées et connexion à la plateforme d'événements pour une alimentation en quasi temps réel. Binesh («بینش») est la couche de business intelligence qui fournit tableaux de bord, rapports et analyses interactives au-dessus de Darya, avec des définitions d'indicateurs partagées. Les deux sont utilisées dans le projet d'agriculture intelligente de Niadad pour combiner relevés de capteurs, données météorologiques et historiques agronomiques, et la même architecture se retrouve dans les projets bancaires et urbains de Niadad.
Un data lake devient un actif lorsqu'il réunit trois éléments à la fois : la gouvernance, un lien vers une identité partagée et de véritables consommateurs. Sans gouvernance, c'est un marécage ; sans identité partagée, un entrepôt de fragmentation ; sans consommateurs, un coût. Avec les trois, il constitue le socle sur lequel reposent l'analytique, l'IA et la responsabilité de l'organisation.