Le data lake s'est imposé dans les projets de Business Intelligence sur une promesse simple : stocker d'abord, décider ensuite. C'est exactement ce qu'il fait, et c'est aussi précisément là qu'est le piège, parce que la décision reportée finit toujours par revenir.
Le principe technique tient en une phrase : le lac « repose sur une architecture schema on read qui permet de stocker n'importe quelle donnée à bas coût ». L'entrepôt fait l'inverse, en schema on write, « ce qui garantit que le modèle est optimisé pour la consommation décisionnelle ».
Pourquoi le lac est apparu
Il n'est pas né d'une mode mais d'un mur. « Des pans entiers de données étaient non structurés et l'entrepôt ne savait ni les stocker ni les interroger » : journaux applicatifs, capteurs, textes, images. La deuxième génération de plateformes a donc « déversé les données brutes dans des lacs de données, c'est-à-dire des systèmes de stockage bon marché à interface fichier ».
Le socle a ensuite changé : « à partir de 2015, les lacs dans le nuage comme S3, ADLS et GCS ont remplacé HDFS ». Le stockage objet a rendu le coût au téraoctet négligeable devant celui d'un entrepôt, ce qui a achevé de généraliser le modèle.
Ce que le schema on read a réellement fait
C'est la phrase qui manque à presque toutes les présentations du sujet, et elle vient d'un papier académique : en contrepartie de sa souplesse, le lac « a reporté en aval le problème de la qualité et de la gouvernance des données au lieu de le traiter ».
Reporté, pas résolu. Là où l'entrepôt imposait de modéliser avant d'écrire, le lac laisse écrire n'importe quoi et renvoie la question à celui qui lira. Le coût ne disparaît pas, il change de porteur et de moment, et il arrive généralement au pire endroit : dans l'équipe analytique, deux ans plus tard, sur un jeu de données que plus personne ne sait interpréter.
La conséquence technique est du même ordre : les lacs « restent dépourvus des fonctions de gestion de base comme les transactions ACID et les index ». Ce qu'un entrepôt garantit nativement doit être réimplémenté à la main au-dessus du lac.
L'architecture à deux étages, et son prix
La réponse du marché a été de garder les deux : « l'architecture à deux étages, lac plus entrepôt, est devenue dominante dans l'industrie ». En pratique, « les données sont d'abord chargées dans le lac puis rechargées dans l'entrepôt, ce qui crée de la complexité, des délais et de nouveaux modes de panne ».
Le jugement porté sur ce montage est explicite : cette architecture « est très complexe pour les utilisateurs ». Chaque donnée existe en deux exemplaires, dans deux formats, avec deux calendriers de rafraîchissement, et toute question un peu fine commence par « laquelle des deux copies fait foi ».
C'est ce constat qui a donné naissance au data lakehouse, qui cherche à porter les garanties de l'entrepôt directement sur le stockage du lac. À noter, pour lire ces sources avec la bonne distance : le papier qui décrit cette généalogie émane d'un acteur partie prenante du marché, ce qui n'enlève rien à la description du mécanisme mais invite à ne pas en tirer de verdict produit.
La distinction que tout le monde résume mal
Opposer lac et entrepôt sur le mode « brut contre structuré » rate le point. La différence porte sur le moment où la donnée devient persistante par rapport au moment où elle est préparée.
Dans le monde du Big Data, « la donnée est stockée immédiatement dans sa forme d'origine avant toute préparation ». Dans un entrepôt classique, à l'inverse, « le stockage persistant intervient après la préparation des données ».
Tout le reste en découle : le coût, la souplesse, la dette de gouvernance et la difficulté d'audit.
La contrainte que la documentation technique ignore
Voilà le point que ne mentionne aucune page technique sur le sujet, et qui décide pourtant de la légalité d'un lac : dès qu'il contient des données personnelles, le RGPD impose qu'elles soient limitées « à ce qui est nécessaire au regard de la finalité », et interdit de les conserver « plus longtemps que nécessaire au regard de la finalité poursuivie ».
La CNIL le rappelle sans ambiguïté, les données personnelles ne peuvent pas être conservées indéfiniment.
Or « on garde tout au cas où » est le principe même du lac. Les deux logiques sont frontalement incompatibles dès qu'un identifiant client, une adresse ou un log applicatif nominatif entrent dans le périmètre. Un lac de données personnelles sans durée de conservation par source n'est pas un choix d'architecture, c'est un manquement.
La conséquence pratique est simple à formuler et coûteuse à rattraper après coup : la finalité et la durée doivent être décidées à l'entrée, source par source, alors même que le lac a été choisi pour ne pas avoir à décider à l'entrée.
Ce qu'il faut trancher avant de creuser
Trois questions déterminent si un lac est le bon outil. Les données non structurées représentent-elles un volume réel, ou l'entrepôt suffirait-il. Qui portera la gouvernance reportée, avec quels moyens et à quelle échéance. Et quelles sources contiennent des données personnelles, donc une durée de conservation à fixer dès l'entrée.
Aucune des trois n'est un choix d'outil, et c'est bien pour ça qu'elles se règlent avant. Une fois posées, l'écart de prix se lit : dans notre catalogue de 26 logiciels de business intelligence publiés, les 21 offres facturées au mois vont de 11 € à 1 925 € HT.
Ce que ces solutions d'informatique décisionnelle ne feront pas à votre place, c'est décider quelle donnée mérite d'être conservée : notre comparateur sert à voir lesquelles documentent au moins la traçabilité des sources.
