Pipeline de réutilisation des données
Réutilisation des données, Data Lake, Entrepôt de données, Data warehouse, Datamart, Feature extraction, Feature store
Pipeline de réutilisation des données
Introduction
Au cours des années 2000, les hôpitaux et établissements de santé ont accumulé une quantité massive de données cliniques, principalement grâce à l’informatisation des systèmes d’information. Ces données sont collectées à l’origine pour gérer les soins, la facturation ou les démarches administratives. Elles sont également une opportunité pour répondre à d’autres usages : recherche, évaluation de la qualité des soins, gestion hospitalière, santé publique, etc.
Pour exploiter ce potentiel, les hôpitaux se sont dotés d’entrepôts de données1,2. Pourtant, ces entrepôts ne sont qu’une pièce du puzzle, et la réutilisation efficace des données peut s’appuyer sur un enchaînement d’outils et de structures : data lake, entrepôt, datamarts, feature store… chacun ayant un rôle bien précis dans un pipeline de réutilisation des données.
Dans cet article, je vous propose une vue d’ensemble de ce pipeline. Il s’appuie sur des expériences concrètes de terrain dans le secteur de la santé, mais aussi sur des pratiques inspirées d’autres domaines plus avancés en matière de gestion de données, comme le e-commerce, les plateformes de streamings, ou les services numériques. Ces secteurs ont depuis longtemps adopté des architectures de données modulaires et performantes, et il est temps que la santé s’en inspire. L’objectif : mieux comprendre comment organiser ses données pour faciliter l’analyse, produire des résultats reproductibles, et valoriser enfin toute la richesse des données de santé.
Le Système d’Information : un potentiel… difficile à exploiter
Les données brutes générées par les hôpitaux sont dispersées dans une multitude de logiciels — dossier patient, laboratoire, imagerie, pharmacie, etc. Chaque outil utilise ses propres formats, ses propres identifiants pour les patients ou les séjours, et repose sur des technologies souvent hétérogènes. Résultat : croiser ces informations est un exercice complexe.
À cela s’ajoute une autre contrainte : les bases de données des logiciels métiers ne sont généralement pas accessibles en écriture ni en lecture libre, pour éviter de perturber leur bon fonctionnement. Ce sont des bases transactionnelles, conçues pour être précises, fiables et optimisées pour les tâches quotidiennes — pas pour l’analyse.
Et pourtant, ces bases regorgent d’informations utiles : chaque donnée est soigneusement enregistrée en ligne, accompagnée de nombreuses métadonnées (auteur de la saisie, date, appareil utilisé…).
Le Data Lake : un socle souple pour explorer ses données
Premier maillon (optionnel) du pipeline de réutilisation des données, le data lake est un espace de stockage centralisé, extensible et très souple. Il permet d’ingérer et de conserver les données brutes provenant de multiples sources — même très hétérogènes — dans leur format d’origine, sans transformation préalable, et sans avoir à se poser immédiatement la question du modèle de données. Ces données peuvent être structurées (comme des tables), semi-structurées (JSON, XML), ou non structurées (textes libres, images, signaux physiologiques, etc.).
D’un point de vue technique, on y retrouve des bases relationnelles classiques (PostgreSQL, Oracle), mais aussi des technologies issues du big data : stockage distribué (Hadoop, Apache Hudi), traitements massifs (Apache Spark, MapReduce, etc.).
Contrairement à l’entrepôt de données, le data lake ne force pas la structuration immédiate. Cette flexibilité est précieuse : elle permet aux data scientists de manipuler librement les données, de tester des hypothèses, d’adapter les extractions à des besoins très spécifiques — sans devoir redéfinir l’ensemble du pipeline à chaque fois.
Sans data lake, il faut finaliser le processus ETL (extraction, transformation, chargement) avant de pouvoir analyser quoi que ce soit. Et si, en cours de route, on s’aperçoit qu’il manque une donnée, il faut tout reprendre : adapter le modèle, reconfigurer l’ETL, recharger les données… Ce cycle peut ralentir considérablement la recherche.
En résumé
Le data lake offre un environnement souple et évolutif pour centraliser les données brutes, sans imposer de schéma de données prédéfini. C’est un outil précieux pour l’exploration, les analyses itératives et la recherche agile, notamment lorsqu’on ne connaît pas encore toutes les variables d’intérêt. Il permet de tester, d’adapter, et de retarder les choix techniques — en gagnant en rapidité et en flexibilité.
The Data Warehouse
Parmi tous les composants du pipeline, l’entrepôt de données est sans doute le plus connu. Il joue le rôle de référentiel central, capable d’agréger les données issues de plusieurs logiciels cliniques ou administratifs, qu’elles soient historiques ou récentes, à un niveau de détail très fin.
Contrairement au data lake, qui stocke les données telles quelles, l’entrepôt impose une normalisation stricte : nommage homogène des tables et des champs, identifiants cohérents entre sources, modèle relationnel stable. Tout cela repose sur un processus bien rôdé : l’ETL (Extract-Transform-Load), qui consiste à extraire les données pertinentes du système d’information (ou d’autres sources), les nettoyer, les transformer, et les charger dans un modèle unifié.
Durant cette étape, on écarte volontairement certaines métadonnées techniques (logs d’utilisation, réglages logiciels, etc.). On corrige aussi les incohérences (valeurs aberrantes, doublons…), et surtout, on harmonise les identifiants pour pouvoir relier les données entre elles, même si elles viennent de logiciels différents.
L’entrepôt repose en général sur des bases relationnelles classiques (PostgreSQL, Oracle, SQL Server…), mais certaines architectures explorent aussi des solutions NoSQL (MongoDB, Cassandra…), utiles pour manipuler des données semi-structurées à grande échelle.
Côté outils, l’ETL peut être développé en R, Python ou Java, orchestré avec des planificateurs comme Apache Airflow, ou bien conçu via des interfaces graphiques comme Talend ou Pentaho, sans besoin de coder.
Pour favoriser l’interopérabilité entre établissements, plusieurs initiatives ont vu le jour autour de modèles de données communs (CDM). C’est le cas du modèle OMOP, porté par la communauté internationale OHDSI, qui propose une nomenclature partagée et une cartographie des terminologies locales vers des vocabulaires standardisés.
En résumé
L’entrepôt fournit une base robuste, homogène et durable pour centraliser les données et les rendre accessibles à une variété d’usages : analyse, recherche, visualisation, reporting, développement d’outils ou d’algorithmes. Il suit la vision d’Inmon : une collection de données orientée “sujets”, intégrée, non volatile, et évolutive dans le temps — bref, un socle prêt à accueillir toutes les analyses futures, même celles qu’on n’a pas encore imaginées.
Les Datamarts : transformer les données en informations prêtes à l’emploi
Même si l’entrepôt centralise les données de manière structurée, il reste souvent trop complexe pour répondre directement à des questions spécifiques. C’est là qu’interviennent les datamarts : des sous-ensembles de l’entrepôt, organisés autour de cas d’usage précis (recherche clinique, suivi qualité, épidémiologie, etc.).
Le datamart permet d’extraire et de transformer les données brutes en variables exploitables, appelées features ou indicateurs. Par exemple, au lieu de conserver toutes les valeurs de potassium d’un patient, le datamart indiquera s’il a présenté une hypokaliémie pendant son séjour.
Ces transformations s’appuient sur des règles métier ou des algorithmes : seuils, combinaisons de diagnostics, tendances temporelles… L’objectif est de fournir des données immédiatement utiles pour répondre à une question donnée, dans un format déjà partiellement agrégé.
Certains datamarts sont organisés sous forme de cubes OLAP (Online Analytical Processing), qui permettent de naviguer dans les données selon plusieurs axes : temps, services hospitaliers, pathologies, etc. Ces structures facilitent les analyses multidimensionnelles, très prisées en épidémiologie ou en gestion hospitalière.
Enfin, les datamarts sont généralement hébergés sur des bases relationnelles classiques (PostgreSQL, Oracle…), mais peuvent aussi s’appuyer sur des technologies orientées analyse comme Apache Kylin.
En résumé
Le datamart sert de passerelle entre l’entrepôt et les besoins métiers. Il transforme les données brutes en variables compréhensibles et directement utilisables, selon des règles adaptées au contexte. Il permet de répondre rapidement à des questions ciblées, sans devoir tout retraiter à chaque fois.
Le Feature Store : l’outil des data scientists
Le feature store est la dernière brique du pipeline, et c’est aussi la plus orientée science des données. Son rôle ? Mettre à disposition des variables prêtes à l’analyse, dans un format simple, propre et reproductible.
Alors que les datamarts restent souvent organisés en lignes (1 ligne par événement ou par patient-séjour), le feature store pivote les données pour les présenter sous forme colonnes : 1 variable = 1 colonne, comme dans un fichier d’analyse statistique ou de machine learning.
Ce format simplifie énormément la vie des analystes : plus besoin de faire des jointures complexes, de pivoter les tables ou de retraiter les données. On accède directement à des jeux de données “flat”, souvent comparables à des questionnaires, où chaque ligne correspond à une unité d’analyse (patient, séjour, etc.).
Autre intérêt majeur : le feature store trace l’origine des variables. Il conserve les métadonnées de chaque feature (comment elle a été calculée, à partir de quelles données, selon quelle version d’un algorithme…), ce qui garantit la reproductibilité des analyses.
Enfin, il peut accueillir des features issues de règles métier (comme les datamarts), mais aussi des features issues de modèles de machine learning (par exemple : probabilité de réadmission, score de risque…).
En résumé
Le feature store fournit aux data scientists un accès direct à des variables prêtes à l’analyse, dans un format adapté aux outils statistiques ou de machine learning. Il structure les données en colonnes, trace leur provenance, et favorise la reproductibilité. C’est une brique essentielle pour passer de la donnée à la connaissance.
Conclusion : un pipeline modulable pour une exploitation efficace des données
Ce tour d’horizon avait pour but de clarifier les rôles et les articulations entre les différentes briques d’un pipeline de réutilisation des données : data lake, entrepôt de données, datamarts et feature store. Chacune apporte une réponse à des besoins spécifiques — du stockage brut jusqu’à l’analyse fine.
L’entrepôt reste une base incontournable : il consolide les données selon un modèle commun, assurant cohérence et pérennité. Mais c’est l’ajout de datamarts, pour structurer les informations selon des objectifs métiers, et de feature stores, pour les rendre immédiatement exploitables en analyse, qui donne toute sa puissance au pipeline. De son côté, le data lake permet d’amorcer les travaux plus tôt, sans attendre que le pipeline complet soit en place.
Sans data lake, chaque ajout de donnée ou modification de besoin oblige à reprendre le processus ETL et le modèle de données. C’est lourd, chronophage, et peu compatible avec une recherche agile.
Bien sûr, la composition de ce pipeline n’est pas figée. Son architecture et la présence de chacun des composants dépendent du contexte : volume de données, complexité des sources, nombre de features, types de projets, ressources humaines disponibles, et surtout besoins en reproductibilité. L’enjeu est d’adapter intelligemment le pipeline aux objectifs de chaque structure.
| Composant | Avantages | Inconvénients |
|---|---|---|
| Data lake |
|
|
Entrepôt de données |
|
|
Datamart |
|
|
Feature store |
|
|
Consultez la page À propos pour plus d’informations sur le projet.