Défis du big data : stockage, qualité, coûts, compétences et conformité

Les plateformes de stockage, de calcul et de diffusion de flux sont aujourd’hui abondantes, souvent ouvertes et disponibles en service géré. Les difficultés d’un projet de big data se situent donc surtout au moment de relier des sources hétérogènes, de s’assurer que les résultats reposent sur des données fiables, de contenir une facture qui suit la consommation, de recruter des équipes rares et de rester en règle avec des textes européens de plus en plus précis. Les six V du big data (volume, vélocité, variété, véracité, valeur, variabilité) décrivent la nature des données, tandis que bien des déconvenues viennent de choix d’organisation autant que de choix d’outils.

Cet article regroupe ces difficultés selon l’endroit où elles se manifestent dans un projet : la définition des usages, l’architecture et l’ingestion, la qualité et l’intégration, les coûts, les compétences, puis la gouvernance et la conformité. Chaque section s’appuie sur la documentation des projets, des éditeurs ou des autorités concernés.

Partir des usages avant de choisir les technologies

La tentation est forte, pour une équipe technique, de commencer par la plateforme : choisir un moteur, monter un cluster ou souscrire un entrepôt cloud, puis chercher quoi y faire. Cette démarche conduit volontiers à une plateforme sans usage, car le coût d’un environnement big data est engagé bien avant que la valeur apparaisse. Il vaut mieux commencer par formuler une question à laquelle l’organisation ne sait pas répondre aujourd’hui : quels clients risquent de résilier dans les trois mois, quelles machines vont tomber en panne, quels flux de paiement sortent du schéma habituel. Le type de réponse attendu (un tableau de bord, une prédiction, une recommandation, une alerte) décide ensuite du volume utile, de la fraîcheur nécessaire et des compétences à réunir.

Un bon point de départ consiste à réaliser un ou deux cas complets, de la source à la décision, avec les vraies données et les vrais utilisateurs, avant d’envisager une plateforme générique. Ces cas servent de banc d’essai pour l’architecture, révèlent les problèmes de qualité qui bloqueraient un déploiement plus large et donnent à la direction un résultat concret sur lequel arbitrer la suite. Notre article sur l’intérêt du big data pour les entreprises donne des exemples sectoriels, et celui qui compare l’informatique décisionnelle et le big data aide à vérifier que le besoin dépasse réellement ce qu’un entrepôt de données classique peut traiter.

L’architecture et l’ingestion

Relier des sources hétérogènes

Les données d’un projet proviennent de systèmes de gestion (ERP, CRM), de journaux applicatifs, de capteurs, de partenaires et de fichiers déposés à la main. Les consolider suppose de décider, pour chaque source, si elle sera lue en lots périodiques ou en flux continu, ce qui dépend du délai acceptable entre l’événement et son exploitation. Pour les flux, les plateformes les plus répandues sont Apache Kafka, que son projet décrit comme une plateforme distribuée de diffusion d’événements, et Apache Pulsar, une plateforme de messagerie et de diffusion conçue pour le cloud qui prend en charge la multilocation et la réplication géographique. Les fournisseurs de cloud proposent leurs propres services gérés, comme Amazon Kinesis Data Streams et Pub/Sub de Google Cloud. Le choix entre un service géré et un logiciel libre exploité par ses propres équipes engage la dépendance au fournisseur autant que la performance, un point que traite la section sur les coûts.

Éviter le lac de données sans structure

Un lac de données qui reçoit tout, sans règles de nommage, sans schéma documenté et sans propriétaire, devient vite un entrepôt de fichiers que personne ne sait interroger. Les formats de tables ouverts atténuent ce risque en donnant aux fichiers déposés sur un stockage objet une structure de table que plusieurs moteurs peuvent lire. Apache Iceberg permet par exemple d’ajouter, de renommer ou de réordonner des colonnes sans réécrire la table, et d’interroger un état antérieur pour obtenir des résultats reproductibles ; Delta Lake, hébergé par la Linux Foundation, vise la même architecture de lakehouse (un entrepôt analytique bâti directement sur le stockage du lac) et est lisible par plusieurs moteurs, dont Spark, Trino, Flink ou BigQuery. L’intérêt pour un décideur est double : le contrat de lecture reste stable quand le moteur change, et l’historique des versions d’une table facilite l’audit.

Ces formats ne dispensent pas de concevoir le modèle de données avant d’ouvrir la plateforme à de nouvelles sources. Un schéma qui change à chaque ajout oblige les consommateurs à réécrire leurs requêtes ; versionner les schémas, annoncer les modifications à leurs utilisateurs avant de les déployer et les valider d’abord sur un périmètre limité réduit ce risque.

Placer le calcul au bon endroit

Quand la latence compte (détection de fraude au moment du paiement, maintenance prédictive d’une machine), il faut décider où s’exécutent les modèles d’analyse : dans le cloud, sur site ou au plus près des capteurs. Chaque option impose ses contraintes de bande passante, de supervision des équipements et de procédure de mise à jour des modèles, qu’il vaut mieux examiner avant l’installation des équipements.

La qualité et l’intégration des données

Des algorithmes d’analyse ou d’intelligence artificielle alimentés par des données de mauvaise qualité produisent des résultats faux avec une apparence de rigueur, et les défauts se multiplient quand on additionne les sources. Les familles de défauts sont connues : valeurs manquantes, erronées, redondantes, incohérentes d’un système à l’autre, obsolètes ou d’origine incertaine. La norme ISO/IEC 25012 propose un modèle de quinze caractéristiques (exactitude, complétude, cohérence, crédibilité, actualité, entre autres) qui sert de grille pour décider ce que « de qualité » veut dire pour un jeu de données donné.

La démarche gagne à prendre la forme d’un cycle. On détecte d’abord les anomalies par du profilage (inventaire du contenu d’un jeu de données) et par des règles de contrôle écrites avec les métiers. On remonte ensuite à la cause : une saisie défaillante, une transformation mal conçue, une source qui a changé de format. On corrige enfin le plus près possible de l’origine, car nettoyer en aval ne traite que le symptôme et recommence à chaque chargement. Les contrôles automatiques placés dans les chaînes d’ingestion, qui bloquent ou mettent en quarantaine les lots non conformes, évitent qu’une anomalie ne se propage jusqu’aux tableaux de bord.

L’intégration pose un problème d’une autre nature : un même mot recouvre souvent des définitions différentes selon les services, et le même indicateur se calcule de plusieurs manières. Un lac alimenté sans glossaire commun reproduit ces divergences à grande échelle. Lorsque chaque projet réconcilie les définitions à sa manière, le travail est refait à chaque fois ; un glossaire métier et un catalogue partagés, que décrit notre guide de la gouvernance des données, mutualisent cet effort entre tous les usages.

Maîtriser les coûts

Stocker moins, plus intelligemment

Conserver tout, indéfiniment, parce que le stockage est peu cher, est une source fréquente de dérive. Chaque donnée gardée coûte en stockage, en sauvegarde, en temps de traitement et en exposition en cas d’incident, et celles qui perdent leur pertinence encombrent les analyses. Une politique de conservation par catégorie, appliquée automatiquement, règle le problème à la racine. Pour les données personnelles, elle est d’ailleurs une obligation : le RGPD interdit de les conserver au-delà de ce que la finalité exige, et la CNIL distingue trois phases (base active, archivage intermédiaire, archivage définitif). L’article sur les données redondantes, obsolètes ou inutiles détaille la manière de les repérer.

Plafonner la consommation de calcul

Dans le cloud, le coût d’une analyse dépend de ce qu’elle consomme, et une requête mal écrite sur un grand jeu de données peut coûter très cher en quelques secondes. Les plateformes proposent des garde-fous qu’il faut activer dès le départ. Pour BigQuery, la documentation de Google décrit la limite d’octets facturés par requête (une requête qui la dépasse échoue sans frais), les quotas personnalisés par projet ou par utilisateur, la simulation préalable (dry run) qui estime les octets lus avant exécution, et les budgets avec alertes. Elle distingue aussi la tarification à la demande, facturée au volume de données interrogé, de la tarification par capacité, où l’on plafonne le coût en limitant les ressources réservées (voir les bonnes pratiques de maîtrise des coûts). Snowflake propose pour sa part des moniteurs de ressources qui suivent la consommation de crédits par entrepôt de calcul et déclenchent, à des seuils choisis, une notification ou la suspension de l’entrepôt.

Ces mécanismes techniques ne remplacent pas une pratique de gestion. Le référentiel de la FinOps Foundation décrit une démarche qui associe l’ingénierie, la finance et les métiers selon trois phases (informer, optimiser, exploiter) et part du principe que chaque équipe répond de sa consommation technique. Dans un projet big data, cela se traduit par des coûts attribués par produit ou par équipe, visibles en continu, et par une estimation du coût d’usage dès la conception, car les ordres de grandeur d’un système de production n’ont que peu de rapport avec ceux d’un prototype.

Garder la possibilité de partir

Un entrepôt ou un service de flux propriétaire est confortable, et il crée une dépendance dont le coût apparaît à la sortie. Le Data Act a modifié ce calcul : depuis le 12 septembre 2025, les fournisseurs de services de traitement de données doivent faciliter le changement de fournisseur, et l’article 29 du règlement (UE) 2023/2854 supprime les frais de changement à compter du 12 janvier 2027, après une période où ils sont limités aux coûts directement liés au changement. L’enjeu de souveraineté qui en résulte est analysé dans notre article sur le Tech Sovereignty Package. Choisir des formats ouverts pour les données et la description des tables réduit en pratique le coût d’une migration.

Des compétences rares à recruter et à fidéliser

Un projet big data réunit des ingénieurs de données qui construisent les chaînes d’ingestion, des analystes et des data scientists qui exploitent les résultats, et des experts du métier qui en valident le sens, des profils tous recherchés. Eurostat recense plus de 10 millions de spécialistes des TIC en emploi dans l’Union européenne en 2025, soit 5,0 % de l’emploi total, et rappelle l’objectif de la décennie numérique d’en atteindre 20 millions en 2030. Cette statistique couvre l’ensemble des métiers des technologies de l’information, bien au-delà des profils de la donnée, mais elle donne la mesure de la tension, puisque l’objectif revient à doubler à peu près ces effectifs d’ici 2030.

Plusieurs pratiques réduisent l’exposition. Cartographier avec les ressources humaines les compétences présentes, repérer les écarts et former en interne des développeurs, des analystes ou des administrateurs de bases de données vers les métiers de la donnée fidélise des personnes qui connaissent déjà l’organisation. Le recours à une société de services permet de démarrer plus vite, à condition de prévoir au contrat un transfert de compétences, faute de quoi la dépendance s’installe. La documentation (catalogue, glossaire, lignage) protège enfin le projet contre les départs : une plateforme que seules deux personnes comprennent reste fragile quel que soit son niveau technique. Le cadre de travail (outils actuels, temps de formation, visibilité sur l’usage des livrables) fait lui aussi partie de la stratégie de fidélisation.

Gouvernance et conformité

À mesure que les sources se multiplient et que les données sont conservées sous leur forme brute, les champs sensibles (identifiants, adresses, données de santé) se retrouvent dans des tables que personne n’a prévu de protéger. Le RGPD impose pourtant, pour chaque traitement, une finalité déterminée, la minimisation des données, une durée de conservation et, pour les traitements à risque élevé, une analyse d’impact. Le registre des traitements que la CNIL demande de tenir recense ces éléments par activité ; pour un projet big data, il doit couvrir aussi les traitements dérivés (jeux d’entraînement, tables d’agrégats, extractions pour des tiers).

Trois textes européens récents ajoutent des exigences qui touchent directement ces projets. Le Data Governance Act (règlement (UE) 2022/868), applicable depuis le 24 septembre 2023, encadre la réutilisation de données protégées du secteur public et les intermédiaires de partage de données. Le Data Act, applicable depuis le 12 septembre 2025, ouvre aux utilisateurs l’accès aux données de leurs produits connectés, ce qui crée de nouveaux flux à gérer pour les industriels. L’AI Act (règlement (UE) 2024/1689) impose, par son article 10, des pratiques de gouvernance pour les jeux d’entraînement, de validation et de test des systèmes d’IA à haut risque, avec une application repoussée au 2 décembre 2027 pour les systèmes de l’annexe III. Notre guide de la gouvernance des données détaille ces obligations. Lorsque les jeux d’entraînement contiennent des données personnelles, les fiches pratiques IA de la CNIL précisent comment appliquer la finalité, la minimisation et la durée de conservation.

Le data mesh, formalisé par Zhamak Dehghani en décembre 2020, propose une répartition des rôles qu’une organisation peut adopter en partie : chaque jeu de données est confié à l’équipe du domaine métier qui le connaît, laquelle répond de sa qualité et de sa documentation, tandis qu’une plateforme commune applique automatiquement les règles partagées. Cette répartition évite de faire passer chaque demande d’accès par une équipe centrale unique. Les mesures de protection qui doivent accompagner cet accès (chiffrement, habilitations, journalisation) sont décrites dans l’article sur la gestion de la sécurité des données.

Séquencer le déploiement : un cas d’usage, une architecture minimale, des garde-fous

Les difficultés précédentes se traitent mieux dans l’ordre où elles se présentent que toutes à la fois. Le premier cas d’usage fixe la question métier et l’indicateur de réussite ; il détermine les sources à relier et le niveau de qualité nécessaire, qu’on mesure dès le premier chargement. L’architecture initiale se limite à ce que ce cas exige (un stockage avec un format de table ouvert, une ingestion en lots ou en flux selon le besoin, un catalogue minimal), mais elle active dès l’origine les plafonds de coût et la politique de conservation, qui sont plus difficiles à imposer après coup. Le registre des traitements et la désignation d’un propriétaire pour chaque jeu de données accompagnent la mise en production plutôt que de la suivre.

Les cas d’usage suivants réutilisent ces fondations et en repoussent les limites au rythme des besoins, ce qui permet de justifier chaque extension de la plateforme par un usage réel. Pour la stratégie d’ensemble, notre article sur les bonnes pratiques d’une stratégie big data complète cette approche, et celui sur l’organisation des données en équipe traite de l’échelle plus modeste des fichiers partagés.

Sources et références 21 sources

Textes et pages officielles de l'Union européenne

1. [1] Règlement (UE) 2016/679 (RGPD)
2. [2] Règlement (UE) 2022/868 (Data Governance Act)
3. [3] Règlement (UE) 2023/2854 (Data Act)
4. [4] Règlement (UE) 2024/1689 (AI Act)
5. [5] Commission européenne : calendrier d'application de l'AI Act
6. [6] Commission européenne : Data Act
7. [7] Eurostat : ICT specialists in employment

CNIL

1. [8] Les durées de conservation des données
2. [9] Le registre des activités de traitement
3. [10] Les fiches pratiques IA

Normes et référentiels

1. [11] ISO/IEC 25012:2008, modèle de qualité des données
2. [12] FinOps Foundation : FinOps Framework
3. [13] Zhamak Dehghani : Data Mesh Principles and Logical Architecture (3 décembre 2020)

Documentation des projets et des éditeurs

1. [14] Apache Kafka
2. [15] Apache Pulsar
3. [16] Apache Iceberg
4. [17] Delta Lake (Linux Foundation)
5. [18] Amazon Kinesis Data Streams
6. [19] Pub/Sub de Google Cloud
7. [20] BigQuery : bonnes pratiques de maîtrise des coûts
8. [21] Snowflake : moniteurs de ressources