Lorsque les données croissent au point de ne plus tenir ni de pouvoir être traitées sur une seule machine, on parle de Big Data. Il ne s'agit pas seulement d'une question de taille : le défi se résume classiquement aux cinq V — volume, vélocité, variété, véracité et valeur — et oblige à repenser la façon dont l'information est stockée, traitée et gouvernée. Cet article parcourt les paradigmes de traitement distribué (de MapReduce à Spark), les architectures de stockage (data lake, data warehouse et lakehouse), le traitement par lots face au traitement en flux, et les obligations de gouvernance et de protection des données qu'aucun projet sérieux ne peut ignorer.
Les cinq V du Big Data
Le volume est la dimension évidente : des téraoctets ou des pétaoctets qui dépassent la capacité d'un serveur conventionnel. La vélocité renvoie au rythme de génération et d'ingestion — capteurs IoT, clics, transactions — qui exige souvent un traitement en temps quasi réel. La variété englobe les données structurées (tables), semi-structurées (JSON, logs) et non structurées (texte, images, vidéo). La véracité vise la qualité et la fiabilité : des données sales produisent des conclusions fausses avec une apparence de rigueur. Et la valeur est l'épreuve de vérité : aucune donnée ne vaut par elle-même, seulement par la décision qu'elle permet de prendre. Concevoir en pensant aux cinq V à la fois évite l'erreur d'optimiser le volume et de négliger la qualité.
Du paradigme MapReduce à Apache Spark
Le traitement distribué est né avec MapReduce, le modèle popularisé par Hadoop : une phase map qui transforme et filtre les données en parallèle sur de nombreux nœuds, et une phase reduce qui agrège les résultats. Sa force est la tolérance aux pannes sur du matériel bon marché ; sa faiblesse, la lenteur, car il écrit sur disque entre chaque étape. Le stockage sous-jacent, HDFS (Hadoop Distributed File System), répartit et réplique les blocs de données pour survivre à la défaillance de nœuds individuels.
Apache Spark a supplanté MapReduce en traitant en mémoire, ce qui le rend plusieurs ordres de grandeur plus rapide sur des charges itératives comme l'entraînement de modèles. Spark offre une API unifiée pour le SQL (DataFrames), le traitement de flux (Structured Streaming), les graphes et l'apprentissage automatique (MLlib), de sorte qu'un même moteur couvre tout le cycle analytique. Son modèle d'exécution paresseuse (lazy evaluation) construit un graphe d'opérations et l'optimise avant de l'exécuter, en évitant le travail inutile.
Où stocker les données : lake, warehouse et lakehouse
Le data warehouse stocke des données structurées, nettoyées et modélisées pour des requêtes analytiques rapides ; il suit le schéma à l'écriture (schema-on-write) et convient idéalement aux rapports métier. Le data lake conserve des données brutes de tout format à faible coût, en appliquant le schéma à la lecture (schema-on-read) ; il offre de la flexibilité mais, sans gouvernance, dégénère en data swamp (marécage de données) où personne ne trouve quoi que ce soit ni n'a confiance en rien.
L'architecture lakehouse, dominante en 2026, combine le meilleur des deux : la flexibilité et le faible coût du lake avec les garanties transactionnelles et la performance du warehouse, grâce à des formats de table ouverts comme Delta Lake, Apache Iceberg ou Hudi. Ces formats apportent des transactions ACID, le contrôle de versions (time travel) et l'évolution du schéma sur des fichiers en stockage objet, ce qui élimine la duplication des données entre lake et warehouse.
Tableau comparatif des architectures de stockage
| Critère | Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| Type de données | Structurées | Quelconques | Quelconques |
| Schéma | À l'écriture | À la lecture | Flexible + transactionnel |
| Coût de stockage | Élevé | Faible | Faible |
| Transactions ACID | Oui | Non | Oui |
| Idéal pour | Rapports métier | Données brutes, ML | BI et ML unifiés |
Traitement par lots et en temps réel
Il existe deux modes fondamentaux de traitement. Le traitement par lots (batch) opère sur des jeux de données complets à intervalles programmés ; il est efficace et simple pour des rapports quotidiens ou des chargements historiques. Le traitement de flux (streaming) analyse les événements à mesure qu'ils arrivent, avec une latence de quelques secondes ou millisecondes, indispensable pour la détection de fraude, les alertes ou la personnalisation en direct. Des outils comme Apache Kafka servent de colonne vertébrale pour l'ingestion d'événements, et des moteurs comme Apache Flink ou le Structured Streaming de Spark consomment ces flux.
Le grand schéma architectural à connaître est le débat entre l'architecture Lambda (deux chemins, batch et streaming, qui se réconcilient) et l'architecture Kappa (un seul chemin de streaming qui retraite aussi l'historique). La tendance penche vers Kappa pour sa moindre complexité opérationnelle, mais le choix dépend des exigences de latence et d'exactitude de chaque cas.
Qualité de la donnée : la véracité comme fondement
Des cinq V, la véracité est la plus facile à négliger et la plus coûteuse à ignorer. Une analyse irréprochable sur des données sales produit des conclusions erronées avec une apparence de rigueur scientifique, ce qui est pire que de n'avoir aucune analyse. La qualité de la donnée se gère en mesurant plusieurs dimensions concrètes : l'exactitude (la donnée reflète-t-elle la réalité ?), la complétude (manque-t-il des champs ou des enregistrements ?), la cohérence (les valeurs coïncident-elles entre systèmes ?), la ponctualité (la donnée arrive-t-elle à temps pour la décision ?) et l'unicité (y a-t-il des doublons qui gonflent les comptages ?).
Dans les architectures modernes, ces contrôles s'automatisent sous forme de tests de qualité exécutés à chaque étape du pipeline, de sorte qu'un lot qui ne respecte pas les seuils est bloqué ou signalé avant de contaminer les zones de consommation. Un schéma courant organise le lakehouse en couches (brute, raffinée et de consommation), en appliquant des validations croissantes à chaque saut, de manière que seules parviennent à l'analyse les données ayant passé le filtre de qualité. Traiter la qualité comme une caractéristique du produit de données, et non comme un nettoyage ponctuel, est ce qui distingue un programme de données durable d'un effort qui se dégrade avec le temps.
Gouvernance de la donnée et conformité réglementaire
Un projet de Big Data sans gouvernance est un risque juridique en attente de se matérialiser. Le Règlement général sur la protection des données (RGPD) impose des principes qui affectent directement l'architecture : minimisation (ne pas accumuler de données personnelles « au cas où »), limitation de la finalité, limitation de la durée de conservation et droit à l'effacement, qui, dans un data lake immuable, oblige à concevoir des mécanismes de suppression sélective. La pseudonymisation et le chiffrement au repos et en transit sont des mesures techniques exigibles. La gouvernance de la donnée ajoute des catalogues, le lignage (savoir d'où vient chaque donnée et ce qui en a été fait) et le contrôle d'accès fondé sur les rôles, le tout alignable sur des cadres comme la norme ISO/IEC 27001 de sécurité de l'information. Lorsque les données alimentent des modèles d'IA, il faut en outre considérer les obligations de qualité et de traçabilité du Règlement européen sur l'IA.
Mise en œuvre par phases
Un programme de données ordonné progresse ainsi : (1) définir les questions métier et les cas d'usage concrets avant de déplacer le moindre octet ; (2) concevoir l'ingestion et le catalogue avec le lignage dès le premier jour ; (3) établir les zones du lakehouse (brute, raffinée, consommation) avec des règles de qualité à chaque saut ; (4) appliquer la gouvernance et le contrôle d'accès avant d'ouvrir l'accès, et non après ; (5) choisir le mode de traitement (batch ou streaming) selon la latence dont la décision a réellement besoin ; et (6) mesurer le coût par requête et la valeur livrée, car le stockage bon marché incite à accumuler des données que personne n'utilise.
Erreurs courantes à éviter
La première est le data swamp : déverser des données sans catalogue ni qualité jusqu'à ce que le lake devienne inutilisable. La deuxième est d'opter pour le streaming quand un batch nocturne suffit, multipliant la complexité opérationnelle sans valeur réelle. La troisième est d'ignorer le RGPD dans l'architecture, en découvrant trop tard qu'on ne peut pas effacer les données d'un utilisateur qui exerce son droit à l'effacement. La quatrième est de mesurer le succès en téraoctets stockés plutôt qu'en décisions améliorées. Et la cinquième est de sous-estimer le coût du cloud : une requête mal conçue sur des pétaoctets peut générer une facture surprenante.
Questions fréquentes
À partir de quand ce ne sont plus des « données normales » mais du Big Data ?
Il n'y a pas de seuil fixe en gigaoctets. Le point de bascule survient lorsque le volume, la vélocité ou la variété dépassent ce qu'une seule machine ou une base de données relationnelle traditionnelle peuvent gérer efficacement, imposant un traitement distribué.
Spark remplace-t-il complètement Hadoop ?
Spark remplace le moteur de traitement MapReduce par sa rapidité en mémoire, mais il coexiste généralement avec un stockage distribué (HDFS ou, plus couramment aujourd'hui, le stockage objet dans le cloud). Hadoop en tant qu'écosystème a perdu de l'importance face au lakehouse.
Qu'est-ce qu'un lakehouse et pourquoi s'est-il imposé ?
C'est une architecture qui apporte des transactions ACID, le versionnement et la performance d'un warehouse sur les données bon marché et flexibles d'un data lake, au moyen de formats de table ouverts. Il s'est imposé parce qu'il élimine la duplication entre lake et warehouse et unifie l'analytique métier et le machine learning.
Comment le RGPD affecte-t-il un data lake ?
Il exige de pouvoir localiser et effacer des données personnelles précises (droit à l'effacement), d'appliquer la minimisation, la pseudonymisation et le chiffrement, et de maintenir la traçabilité. Cela oblige à concevoir le lake avec catalogue, lignage et mécanismes de suppression sélective dès le départ.
Conclusion
Le Big Data ne consiste pas à stocker tout ce qui est possible, mais à convertir de grands volumes en décisions fiables sans perdre en chemin la qualité, le coût ni la conformité juridique. L'architecture lakehouse et des moteurs comme Spark ont résolu une bonne partie du problème technique, mais le facteur différenciant reste la gouvernance : un catalogue avec lignage, des règles de qualité dans chaque zone et une conception compatible avec le RGPD dès le premier jour séparent un actif de données d'un passif juridique. Accumuler des pétaoctets que personne ne consulte n'est pas une victoire ; c'est un coût récurrent déguisé en stratégie. Chez Summum Marketing, nous partons toujours de la question métier vers l'infrastructure, et non l'inverse, car la valeur d'une donnée se mesure à la décision qu'elle habilite, jamais à sa taille.