Data Lake

Définition complète

Un data lake est un référentiel centralisé conçu pour stocker, traiter et sécuriser de grandes quantités de données dans leur format natif — qu'elles soient structurées (tables SQL), semi-structurées (JSON, XML, CSV) ou non structurées (texte brut, images, logs). L'approche fondamentale du data lake est celle du schéma à la lecture (schema-on-read) : les données sont ingérées sans transformation, et le schéma est défini au moment où les données sont consommées et analysées.

Cette philosophie contraste avec le modèle de l'entrepôt de données classique, qui impose un schéma à l'écriture (schema-on-write) et exige que les données soient structurées et transformées avant d'être chargées. Le data lake accepte les données dans leur état brut, ce qui réduit la friction à l'ingestion mais déplace la complexité vers la couche de traitement et de consommation.

Le terme a été popularisé par James Dixon, co-fondateur de Pentaho, en 2010. Il décrivait le data lake comme une alternative au data mart, qu'il comparait à une bouteille d'eau en plastique — prête à consommer, mais préemballée et donc limitée dans son usage. Le data lake, lui, était le lac naturel : on pouvait y prélever ce dont on avait besoin, au format que l'on souhaitait, au moment voulu.

Entre 2010 et 2020, le data lake est devenu le modèle dominant pour les grandes organisations cherchant à centraliser leurs données analytiques. Les plateformes Hadoop (HDFS), puis les services cloud natifs (Amazon S3, Azure Data Lake Storage Gen2, Google Cloud Storage) ont fourni l'infrastructure de stockage économique. Depuis 2020, le modèle data lakehouse — qui ajoute des couches de métadonnées ACID (Delta Lake, Apache Iceberg, Apache Hudi) au-dessus du stockage objet — a en grande partie absorbé les cas d'usage analytiques du data lake pur pour les nouvelles architectures.

Architecture et composants clés

Un data lake s'articule autour de plusieurs couches fonctionnelles. La compréhension de cette architecture est essentielle pour évaluer si le modèle est adapté à vos besoins.

La couche de stockage est typiquement un service objet cloud : Amazon S3 pour AWS, Azure Data Lake Storage Gen2 pour Azure, ou Google Cloud Storage pour GCP. Les fichiers sont stockés en formats ouverts — Parquet et ORC pour les données structurées (compression et performances de lecture optimales), JSON ou Avro pour les données semi-structurées. Le calcul est découplé du stockage : des moteurs comme Apache Spark, Presto, Trino ou Amazon Athena lisent les fichiers directement depuis le stockage objet à la demande.

Le catalogue de métadonnées est la couche critique souvent négligée. Sans un catalogue qui documente le schéma, le propriétaire, la fraîcheur et la qualité de chaque ensemble de données, le data lake devient rapidement un data swamp — un espace de stockage opaque où personne ne sait ce que contient le lac. AWS Glue Data Catalog, Apache Atlas, et des outils tiers comme OpenMetadata ou Atlan remplissent ce rôle dans les architectures cloud modernes.

Exemple concret

Une entreprise française de services financiers gère environ 15 millions de transactions par mois sur ses plateformes B2C et B2B. Elle a mis en place un data lake sur Amazon S3 pour centraliser l'ensemble de ses données opérationnelles. Le coût de stockage est d'environ 0,023 € par Go par mois — soit moins de 2 300 € par mois pour 100 To de données brutes, contre 30 000 à 50 000 € par mois pour un volume équivalent dans un entrepôt de données analytique classique.

Les équipes data ingèrent en continu les logs de transactions, les événements d'application (clics, navigations, erreurs), les données CRM, et les flux de paiement. Les données atterrissent dans la zone brute en format Parquet partitionné par date. Des pipelines Apache Spark transforment quotidiennement les données vers la zone curated, où des modèles de scoring de risque et des agrégats de revenus sont calculés. La zone analytique expose des tables Parquet lisibles par Amazon Athena pour les analystes financiers, à un coût de 5 $ par téraoctet scanné — soit quelques dizaines d'euros par mois pour les requêtes analytiques quotidiennes.

La difficulté principale rencontrée par cette organisation a été la gouvernance : après 18 mois de fonctionnement, le lac contenait plus de 4 000 tables dans la zone curated, dont environ 60 % n'étaient plus maintenues activement. Sans propriétaire défini et sans catalogue, les analystes passaient en moyenne 2 heures à identifier la bonne table avant chaque analyse. La mise en place d'un catalogue de données (OpenMetadata) et d'un processus de revue trimestrielle des tables orphelines a ramené ce délai à moins de 20 minutes.

Analyse approfondie

Le data lake a résolu un problème réel apparu dans les années 2010 : la prolifération des sources de données à des vitesses et en des volumes que les entrepôts de données classiques ne pouvaient pas absorber de manière économique. Les logs serveur, les données de capteurs IoT, les événements applicatifs produits à la milliseconde, les fichiers multimédia — aucune de ces données ne rentrait dans le modèle relationnel de l'entrepôt classique sans un travail de transformation coûteux et une modélisation extensive. Le data lake offrait une porte d'entrée simple : déposez tout, transformez plus tard.

La flexibilité du schema-on-read est à la fois la force et la faiblesse principale du data lake. Elle permet d'ingérer des données dont le schéma n'est pas encore connu ou dont la structure change fréquemment — ce qui est très courant dans les premières phases de collecte de données. Mais cette même flexibilité transfère la charge de la définition du schéma vers chaque consommateur individuel. Dans une organisation avec 50 analystes, cela signifie potentiellement 50 définitions différentes du même champ — une recette pour la fragmentation des métriques et les désaccords sur les chiffres lors des réunions de direction.

La comparaison avec l'entrepôt de données mérite une nuance importante : ces architectures ne sont pas mutuellement exclusives. Dans de nombreuses organisations, le data lake coexiste avec un entrepôt de données. Le lac reçoit les données brutes et les flux en temps réel ; l'entrepôt contient les modèles dimensionnels curatés utilisés pour le reporting. Cette architecture hybride est souvent appelée "lake-house" dans sa forme la plus intégrée, ou simplement "lac + entrepôt" dans les architectures plus classiques avec des pipelines ETL entre les deux.

L'émergence des formats de table ouverts — Apache Iceberg en tête depuis 2022, avec Delta Lake (Databricks) et Apache Hudi comme alternatives — a fondamentalement modifié le paysage. Ces formats ajoutent des garanties ACID, la gestion des schémas, les time-travel queries (possibilité de lire l'état des données à un point précis dans le passé) et l'optimisation automatique des fichiers directement sur le stockage objet. En pratique, ils transforment un data lake passif en data lakehouse actif. La plupart des nouvelles architectures analytiques construites depuis 2022 utilisent Iceberg ou Delta Lake plutôt qu'un data lake pur, sauf pour les cas d'usage spécifiques où la flexibilité maximale sur le format prend le dessus.

Pour les équipes opérationnelles françaises — COOs, directeurs financiers, responsables revenue ops — le data lake est une notion d'infrastructure de données qui influence indirectement la qualité des indicateurs accessibles. Un data lake bien gouverné avec des pipelines de transformation robustes produit des données opérationnelles fiables, rapidement disponibles et facilement connectables à des outils analytiques comme Fairview. Un data lake mal gouverné — le data swamp — produit des délais de traitement, des divergences de définitions et des chiffres impossibles à réconcilier entre les outils. La question opérationnelle pertinente n'est pas "avons-nous un data lake ?" mais "nos données sont-elles fiables, fraîches et accessibles sans dépendre d'une requête ad hoc à l'équipe data ?"

Erreurs fréquentes

• ✗

  Ingérer sans gouverner. L'erreur la plus courante est de mettre en place un data lake avec une stratégie d'ingestion active mais sans gouvernance parallèle. Sans catalogue de données, sans propriétaires définis par domaine, et sans standard de nommage appliqué dès le premier jour, le lac se transforme en data swamp en moins de 12 mois. Les données s'y accumulent sans qu'il soit possible de savoir ce qu'elles représentent, à qui elles appartiennent, ni si elles sont encore fraîches.

• ✗

  Utiliser un data lake pur pour le reporting opérationnel. Le data lake est conçu pour la flexibilité et le stockage économique, pas pour les requêtes analytiques rapides et répétées. Pointer un outil de BI directement sur des fichiers Parquet dans un data lake sans couche de transformation ni modèle dimensionnel produit des requêtes lentes, des résultats inconsistants et une expérience utilisateur dégradée. La couche de transformation (Spark, dbt, SQL dans un entrepôt) est non négociable pour le reporting opérationnel.

• ✗

  Confondre "tout stocker" avec "tout analyser". Le data lake encourage l'ingestion large et peu sélective, ce qui est pertinent pour l'archivage et la flexibilité future. Mais toutes les données stockées ne méritent pas d'être modélisées et exposées aux analystes. L'accumulation de tables non maintenues crée du bruit, ralentit la découverte des données utiles et dilue la confiance dans l'ensemble du lac. Une revue trimestrielle des tables actives et une politique de cycle de vie des données (rétention, archivage, suppression) sont indispensables.

Comment Fairview s'intègre avec vos données

Fairview n'exige pas que vous disposiez d'un data lake pour fonctionner. La plateforme se connecte directement à vos sources opérationnelles — CRM (HubSpot, Salesforce, Pipedrive), comptabilité (QuickBooks, Xero), ERP — et normalise les données pour produire vos indicateurs opérationnels clés sans infrastructure analytique intermédiaire. Pour les organisations qui disposent déjà d'un data lake ou d'un entrepôt de données, Fairview peut s'y connecter via des connecteurs SQL standards pour y lire les modèles déjà construits par l'équipe data.

L'avantage pour les équipes opérationnelles est de ne pas dépendre de la qualité de gouvernance du data lake pour accéder à leurs indicateurs. Si votre lac contient des données bien curatées, Fairview les utilise. S'il contient des données partiellement fiables, Fairview peut travailler en parallèle depuis les sources directement pour les indicateurs critiques — et alerter sur les divergences. L'objectif est que les COOs, directeurs financiers et responsables revenue ops disposent toujours d'indicateurs réconciliés et fiables, quelle que soit l'architecture de données sous-jacente.

Questions fréquentes