Data swamp

Définition simple : qu'est-ce qu'un data swamp ?

Un data swamp désigne un lac de données mal gouverné, devenu difficile à exploiter par manque d'organisation, de métadonnées et de qualité. L'expression décrit l'échec d'un data lake qui accumule des données brutes sans catalogue, sans règles de gestion ni documentation suffisante. Autrement dit, c'est un "lac de données devenu marécage" : les données existent, parfois en grand volume, mais elles sont mal identifiées, peu fiables ou difficiles à retrouver, ce qui limite leur valeur pour l'analyse, la décision ou l'IA.

Définition technique du data swamp

D'un point de vue technique, un data swamp apparaît lorsqu'un environnement de stockage de données accepte des flux multiples mais sans management ni gouvernance suffisants. Dans cette situation, les utilisateurs ne savent plus clairement d'où viennent les données, à quoi elles correspondent, si elles sont à jour, si elles sont fiables, ni comment elles doivent être protégées. Cette dérive favorise l'apparition de dark data, c'est-à-dire des données collectées et stockées mais jamais réellement exploitées ni analysées.

En pratique, un data swamp se caractérise souvent par :

• des données difficiles à localiser ou à comprendre
• des copies multiples et non synchronisées
• une absence de métadonnées exploitables
• un manque de traçabilité, de protection ou de qualité
• une absence de contrôles d'accès clairs, rendant difficile la maîtrise de qui peut consulter ou modifier quelles données

Data swamp vs data lake : quelles différences ?

Un data lake est un référentiel central conçu pour stocker de grandes quantités de données dans leur format natif, afin de les réutiliser ensuite pour l'analytique, la BI ou le machine learning. Un data swamp correspond à un data lake mal gouverné, devenu trop désordonné ou peu fiable pour rester utile.

Le data lakehouse est une évolution architecturale qui cherche justement à éviter ce basculement en apportant au monde du data lake des mécanismes de fiabilité, gouvernance, performance analytique, gestion des métadonnées et transactions plus proches des entrepôts de données. Cette architecture hybride limite ainsi le risque qu'un lac de données se transforme en marécage informationnel.

Pour maintenir un data lake fonctionnel, des outils de gouvernance jouent un rôle central : catalogage (Collibra, Alation), gestion des métadonnées, contrôle d'accès et traçabilité permettent d'éviter la dérive vers le data swamp.

Problèmes et enjeux juridiques du data swamp pour les organisations

Le premier enjeu du data swamp est la perte de valeur de la donnée. Lorsque les utilisateurs passent l'essentiel de leur temps à chercher, nettoyer, rapprocher ou vérifier les données avant de pouvoir les exploiter, cette situation ralentit les projets, accroît les coûts et réduit la confiance dans les analyses produites. Dans une collectivité comme dans une entreprise, cette désorganisation compromet directement la prise de décision éclairée, car les responsables ne peuvent plus s'appuyer sur des données fiables pour orienter leurs politiques publiques ou leurs stratégies.

Le deuxième enjeu est celui de la gouvernance. Un data swamp traduit souvent l'absence d'un cadre suffisamment structuré sur les métadonnées, la qualité, la responsabilité sur les données, la sécurité, la conformité et la documentation. Or, sans cette  gouvernance, les données sont stockées mais demeurent peu exploitables à l'échelle de l'organisation. Cette accumulation incontrôlée favorise également l'apparition de dark data, qui alourdissent les infrastructures sans produire de valeur.

Le troisième enjeu est opérationnel et réglementaire. Des données mal qualifiées, mal tracées ou mal protégées compliquent la conformité au RGPD, y compris lorsqu'il s'agit de sécurité, de contrôles d'accès appropriés, de partage interservices ou de gestion de données sensibles. Dans les organisations publiques comme dans les entreprises, cela peut fragiliser des projets de plateforme de données, d'hyperviseur, d'open data ou d'IA si la gouvernance n'est pas structurée dès le départ.

Enfin, le data swamp pose un enjeu de souveraineté et d'efficacité collective. Que ce soit dans une entreprise ou une collectivité, une organisation peut techniquement stocker beaucoup de données, mais si elles ne sont pas fiables, compréhensibles, documentées et accessibles dans un cadre maîtrisé, elles ne soutiennent ni la décision ni l'innovation.

Exemples concrets de data swamp dans les collectivités

Dans une collectivité, un data swamp peut apparaître lorsque plusieurs services versent des fichiers, flux ou exports dans un même espace de stockage sans modèle commun, sans catalogue, sans dictionnaire de données ni règles de mise à jour. Au bout de quelques mois ou années, personne ne sait plus exactement quelle version utiliser, quelles colonnes font référence aux mêmes objets, ni si les données sont encore fiables.

Les rapports annuels produits par différents services se retrouvent alors en versions multiples et non consolidées : le service urbanisme publie son rapport, le service environnement le sien, sans coordination ni métadonnées permettant de les rapprocher. Ces jeux de données deviennent progressivement du dark data, c'est-à-dire des informations stockées mais inexploitables faute de documentation ou de traçabilité.

Dans un projet de plateforme de données territoriales, le risque de data swamp apparaît si l'on centralise massivement les données de bâtiments, mobilités, eau, éclairage, capteurs ou SIG sans travail préalable sur l'interopérabilité, la gouvernance et les spécifications d'usage. La plateforme existe techniquement, mais elle ne produit pas la valeur attendue parce que les données sont trop peu maîtrisées pour être utilisées de façon transverse. Ce phénomène touche aussi les entreprises partenaires des collectivités qui alimentent le data lake territorial sans cadre commun.

Dans des projets d'IA ou de machine learning, le data swamp devient particulièrement problématique : les équipes perdent du temps à identifier les bonnes sources, à nettoyer les jeux de données et à vérifier leur fiabilité au lieu de produire des modèles robustes.