Anonymiser les données de santé : ce qui marche, ce qui n'existe pas

« Il suffit d'enlever le nom. » Vraiment ? Une date, un pixel, une tournure de compte-rendu ou une séquence d'ADN suffisent à réidentifier un patient. Anonymiser, structurer, protéger, héberger : ce qui marche, ce qui n'existe pas, et où le droit impose d'héberger ces données.

« Il suffit d'enlever le nom. » C'est ce qu'on croit souvent quand on parle d'anonymiser des données de santé. En réalité, une date, un pixel, une tournure de compte-rendu ou une séquence d'ADN suffisent à réidentifier un patient. Au printemps 2025, j'ai consacré une série de posts à ce sujet : ce qui marche, ce qui n'existe pas, et où le droit impose d'héberger ces données. Les voici rassemblés et remis en ordre.

« Plus on a de données, mieux c'est. » Faux.

Surtout en santé. Parce que plus on a de données :

• plus c'est complexe à anonymiser,
• plus c'est risqué juridiquement,
• plus c'est difficile à maintenir, techniquement et humainement.

Et la CNIL ne plaisante pas : jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires mondial d'amende en cas de non-respect du RGPD, y compris pour collecte excessive.

En santé, la donnée n'est pas un bonus. C'est une ressource critique : encadrée, sensible, engageante. Le vrai levier, ce n'est pas d'en collecter « un max ». C'est de cibler les données vraiment utiles, et de les transformer en valeur produit. Et ça se travaille dès la conception, pas à la fin, quand il est trop tard pour tout recadrer.

À retenir si vous travaillez sur un produit santé :

• Plus de données = plus de risques (juridiques, techniques, humains).
• La quantité ne remplace jamais la pertinence.
• Ce n'est pas à la fin qu'on « gère » la donnée : c'est dès le cadrage produit.
• Clarifier pourquoi on collecte quoi, c'est un exercice produit, pas juste juridique.

RGPD, CNIL, HDS : trois responsabilités qu'on confond

Trois sigles qu'on croise partout quand on travaille sur un produit santé. Trois responsabilités différentes… qu'on oublie de distinguer.

• Le RGPD, c'est le cadre légal (et non, il n'interdit pas l'usage des données de santé).
• La CNIL, c'est l'autorité de contrôle, pas un service d'autorisation.
• Le HDS, c'est une certification technique, pas une garantie de conformité.

Et l'erreur classique, c'est de penser qu'un hébergeur HDS « couvre » le reste. Trois questions à garder en tête : quels sont les cas autorisés de traitement de données de santé, ce que la CNIL vérifie concrètement, et ce qu'un hébergeur HDS garantit vraiment (et ce qu'il ne garantit pas).

Anonymiser des dates

Une date seule, c'est rarement identifiant. Mais dès qu'on en a deux, par exemple une date de naissance et une date de décès, le risque de réidentification augmente considérablement. On peut imaginer d'autres combinaisons : une date de diagnostic et une date d'IRM. Et si, en plus, on connaît le lieu… jackpot. L'identité devient assez facile à deviner.

Ça a été démontré : le triplet code postal + date de naissance + sexe est unique pour 80 % de la population des États-Unis.

Alors, on fait quoi ?

1. On vérifie si on a vraiment besoin de la date pour l'analyse. Sinon, on ne la collecte pas, tout simplement.
2. On réduit la précision de la date. Pour une date de naissance, on peut supprimer le jour, voire le mois. On dilue l'information, ce qui limite les risques de réidentification.
3. Si la cohérence par individu n'est pas nécessaire, on mélange les dates entre les personnes (randomisation). Les stats globales restent correctes, mais l'information n'est plus exploitable individuellement.
4. Si on doit conserver la cohérence par individu, on ajoute du bruit : c'est le dateshift. On attribue à chaque individu un décalage aléatoire, appliqué à toutes ses dates. On masque l'info brute, mais on garde la logique temporelle.

Bonus : parfois, c'est l'inverse. Il nous manque de la donnée… alors on l'invente. Exemple : on a des dates de biopsie au format JJ-MM-AAAA, mais pour un patient on n'a que MM-AAAA. Deux options : l'exclure (dommage, ce n'est pas simple de trouver les patients qui répondent aux critères d'un projet), ou fixer arbitrairement un jour (le 15 du mois). Sinon, on ne peut pas comparer les dates entre elles. Mais c'est un autre sujet : la qualité de la donnée.

Anonymiser les métadonnées d'une image (DICOM)

Anonymiser des images médicales, c'est d'abord comprendre ce qu'il y a autour des pixels.

Les images médicales sont stockées au format DICOM (Digital Imaging and Communication in Medicine). Ce format contient à la fois les données d'image (pixels) et une en-tête riche en métadonnées : nom, dates, type d'examen, machine utilisée…

Chaque type d'image a son SOP Class :

• DICOM-CT pour les scanners,
• DICOM-MR pour l'IRM,
• DICOM-SEG pour les segmentations (souvent issues de l'IA),
• DICOM-RT pour la radiothérapie,
• DICOM-SR pour les rapports structurés…

Il y a des champs communs à tous les fichiers DICOM, mais aussi des champs spécifiques selon le type. Et bien sûr… les private tags, où les fabricants et les utilisateurs peuvent mettre ce qu'ils veulent (sinon ce serait trop facile). Un champ DICOM typique, c'est par exemple (0010,0010) Patient's Name, (0010,0020) Patient ID, (0008,0060) Modality ou (0008,1030) Study Description.

Pour anonymiser, DICOM propose un profil de confidentialité :

1. Le Basic Application Level Confidentiality Profile, qui supprime toutes les informations directement identifiantes, pseudonymise les dates, numéros de série et UID, et supprime les champs privés (sauf si on décide de les conserver).
2. Selon les cas d'usage, on active des Named Options pour ajuster ce qu'on garde :

• Retain Patient Characteristics : garder l'âge, le sexe, le poids (utile en recherche clinique).
• Retain Longitudinal Temporal Info : conserver la chronologie (J+2, J+5) sans garder les vraies dates.
• Retain Safe Private Attributes : garder certains tags privés considérés comme non identifiants.
• Retain Device/Institution Info : analyser les performances des équipements ou des centres.
• Retain UIDs : conserver les identifiants techniques DICOM (pour la cohérence entre fichiers).
• Clean Pixel Data : supprimer le texte incrusté directement dans les images (on y revient).

DICOM apporte donc un process clair pour l'anonymisation des métadonnées. Mais il faut tout de même regarder chaque champ en détail selon le projet. Quel que soit le type de données, on revient toujours à la même chose :

Reduce re-identification risk while maintaining the usefulness of the data.

La vraie question, c'est toujours : qu'est-ce qui permet encore de réidentifier le patient ?

Anonymiser les pixels d'une image

Anonymiser une image médicale… à la main ? Les fichiers DICOM contiennent deux types d'informations : les pixels de l'image (ce que voit le radiologue… ou l'IA), et les métadonnées (nom, date, ID patient, appareil, protocole…). Les métadonnées, j'en ai parlé juste avant. Ici, on parle des pixels.

Oui, l'image elle-même peut contenir du texte embarqué, directement visible à l'écran (nom du patient, ID, service…). On appelle ça du burned-in text. Trois difficultés :

1. Identifier le texte embarqué

Est-ce du texte identifiant (à supprimer) ou clinique (à conserver, comme le nom des organes) ? Certains types d'image sont connus pour être à risque, les échographies par exemple. Il faut extraire le texte des pixels (OCR), le croiser avec une base de mots sensibles (nom, ID, lieu…) et décider quoi masquer. Des outils spécialisés existent : DCMTK, Microsoft Presidio DICOM Redactor, Google Cloud Healthcare API…

2. Masquer sans biaiser

Un rectangle noir, c'est simple à poser. Mais en IA, ça peut créer un biais d'apprentissage : si toutes les images d'un hôpital ont un coin masqué, le modèle risque de l'utiliser comme indice.

3. Prévenir la réidentification par reconnaissance faciale

Certaines IRM cérébrales 3D permettent de reconstruire un visage identifiable. Et on veut justement anonymiser ces données pour les analyser (oui, ça paraît absurde). Des approches sont en cours d'évaluation : DeepDefacer (deep learning supervisé), GANs conditionnels pour générer un visage artificiel mais structurellement fidèle.

Et donc ? Une revue humaine reste indispensable, au moins sur un échantillon représentatif.

A human quality control process to confirm the efficacy of the de-identification process should be used.

Anonymiser un compte-rendu médical ? Je ne recommande pas.

Un nom, une date ? Ok, on sait faire. Mais un « résident de la maison de retraite Sainte-Anne », un « frère hospitalisé à Purpan », ou un « suivi post-greffe depuis 10 ans » ? Là, ça se complique.

Ce qu'on anonymise, c'est du texte libre. Non structuré. Bourré d'implicites. Dicté à la volée. Et chaque mot peut être un indice pour réidentifier un patient (rappel : 10 % des patients d'un projet de recherche peuvent être réidentifiés). Les comptes-rendus croisent tout :

• infos administratives,
• contexte clinique,
• éléments sociaux et familiaux,
• parfois même l'adresse du patient ou le nom de son pharmacien.

Les techniques possibles ?

• Regex / règles expertes : utile, mais fragile.
• NER (Named Entity Recognition) : repère les noms, dates, lieux… si on reste dans le cadre.
• NER médical (Spark NLP, medSpaCy) : plus précis, mais dépend de corpus annotés de qualité.
• LLMs locaux (Mistral, Llama-3) : prometteurs sur le contexte, mais peuvent supprimer des informations non sensibles, restent sensibles aux biais sémantiques si mal encadrés, et sont coûteux à déployer.

Et aucune de ces approches ne gère vraiment les cas limites : les références indirectes, les recoupements implicites, les biais métiers, les fautes d'orthographe.

Ma recommandation ? Ne pas anonymiser. Structurer. Plutôt que de lancer des modèles pour « nettoyer » un texte libre, mieux vaut structurer les infos utiles : extraire, mapper, qualifier. Résultat : moins de données sensibles à gérer, plus de robustesse analytique, et surtout une chaîne de traitement plus maîtrisable. On n'a pas besoin de tout savoir. On a besoin de savoir ce qui sert, et de le structurer.

Le génome, on ne l'anonymise pas. On le protège.

Un génome, ce n'est pas une donnée. C'est une signature. Et une signature, ça ne s'anonymise pas. Ça se protège. Un génome est unique, stable dans le temps, corrélable avec d'autres bases, et donc suffisant pour réidentifier une personne, voire ses proches.

Pour info : une donnée génétique, c'est une info ciblée (mutation BRCA1 pour le cancer du sein, variant CFTR pour la mucoviscidose…). Une donnée génomique, c'est la séquence complète du génome, en A, C, G, T. C'est comme la différence entre un résultat d'analyse… et une empreinte digitale.

Même avec des données génétiques désidentifiées, la réidentification est possible :

• Lin (2004) : avec au maximum 80 SNP (petites variations dans l'ADN, ~0,0000025 % du génome entier), on peut identifier un individu dans une base génétique.
• Gymrek (2013) : on retrouve des participants « anonymes » en croisant le profil de leur chromosome Y et des bases de généalogie en ligne.
• Erlich (2018) : on utilise des liens familiaux pour réidentifier des personnes à partir de bases ouvertes (GEDMatch).
• Ney (2020) : on peut faire fuiter des données génétiques en uploadant de fausses infos sur des sites de généalogie génétique.

Cette dernière publication est incroyable :

1. Vous créez un faux profil ADN (un fichier que vous contrôlez).
2. Vous l'uploadez sur un site qui propose de « retrouver des proches génétiques ».
3. Le site compare votre fichier à sa base… et vous indique les correspondances.
4. Si le fichier est bien construit, vous pouvez déduire des fragments génétiques de profils déjà stockés.

Conclusion : non, on n'anonymise pas les données génétiques et génomiques. On les protège. Concrètement : on n'expose jamais la séquence complète dans des outils standards ; on extrait seulement les mutations d'intérêt, quand c'est justifié ; on cloisonne les accès et on trace tout.

Une alternative : ne pas déplacer les données, mais déplacer les algorithmes. Le federated learning permet d'entraîner des modèles directement sur site, sans transfert de donnée brute. Ça limite le risque par design.

Le Health Data Hub : le choix d'hébergeur qui coince

Pour ceux qui ne connaissent pas, le HDH (Health Data Hub), c'est la plateforme française qui rend accessible (en tout cas sur le papier) tout un tas de données pour la recherche, globalement les données de facturation, et c'est déjà très utile à analyser.

En 2023, la CNIL valide l'hébergement du HDH chez Microsoft Azure, une entreprise américaine, donc soumise au Cloud Act. Ok, tout le monde peut se tromper : la CNIL elle-même reconnaît que ce choix était compliqué. Ce n'est pas fou de mettre des données sensibles chez un hébergeur obligé de fournir un accès à nos données quand la justice américaine le demande.

Et donc, on part sur un contrat de 3 ans, en promettant que d'ici fin 2025, on aura migré vers un cloud souverain. On est en mai 2025. Il y a eu une question à l'Assemblée nationale en avril. Il y a une discussion autour d'une « solution intercalaire ». Mais concrètement, est-ce que quelque chose avance ? Je ne me rends pas bien compte.

To be HDS or not to be

Il y a aujourd'hui 336 hébergeurs certifiés HDS en France. Mais qui est obligé d'en utiliser un ? Et dans quel cadre ?

Rappel réglementaire :

• L'obligation d'hébergement HDS est définie par l'article L1111-8 du Code de la santé publique.
• Elle concerne toute entité qui héberge des données de santé à caractère personnel pour le compte d'un tiers.

Mais aussi : dès que vous externalisez l'hébergement de données de santé personnelles, vous devez passer par un prestataire certifié HDS, même si vous êtes le responsable de traitement. En clair :

• Vous traitez les données d'un hôpital ? → HDS obligatoire.
• Vous éditez un logiciel santé en SaaS ? → HDS obligatoire.
• Vous stockez des données chez un cloud provider externe (même français) ? → HDS obligatoire.
• Vous traitez uniquement vos propres données, hébergées en interne ? → HDS non requis.
• Vous travaillez sur des données anonymisées (au sens RGPD) ? → HDS non requis.

Ce que ça change en pratique : utiliser un hébergeur certifié HDS, ce n'est pas un label marketing. C'est une obligation légale, encadrée par l'ANS, auditée chaque année, avec une validité de 3 ans.

En résumé

Un fil rouge traverse cette série : anonymiser des données de santé, ce n'est presque jamais « enlever le nom ». C'est un arbitrage permanent entre réduire le risque de réidentification et garder la donnée utile. Selon le type de donnée (une date, un pixel, un texte libre, une séquence d'ADN), la bonne réponse change. Et pour certaines, comme le génome, l'anonymisation n'existe pas : il ne reste que la protection. Le tout dans un cadre (RGPD, CNIL, HDS, HDH) qu'on gagne à ne pas confondre.

À lire ensuite

Build in Public

J'ai voulu construire mon app sans savoir coder

IA & Santé

L'IA en santé : chronique d'un été