Données de santé, HDS et IA : comment SuperDr protège vos patients

Vous nous confiez des informations parmi les plus sensibles qu'une personne puisse partager : antécédents, pathologies, examens, traitements. Vous avez le droit de savoir ce qu'on en fait. Cet article passe en revue les règles qui s'appliquent à ce type de données — RGPD, HDS, pseudonymisation — et explique concrètement comment SuperDr s'y conforme, y compris dans nos appels à un prestataire d'IA générative pour la génération d'observations.

Qu'est-ce qu'une donnée de santé ?

Le RGPD donne une définition large (article 4, §15) : toute donnée concernant la santé physique ou mentale d'une personne, passée, présente ou future. Concrètement, dès qu'une information est rattachée à un acte médical — antécédent, pathologie, traitement, résultat d'examen — elle entre dans cette catégorie. La Cour de justice de l'Union européenne a même reconnu, dans l'arrêt Lindqvist, qu'une mention banale comme « s'est blessée au pied et est en arrêt partiel » constitue une donnée de santé.

Ces données sont qualifiées de sensibles par l'article 9 du RGPD : leur traitement est interdit par principe, sauf exceptions strictement encadrées (consentement, soins, etc.). Elles bénéficient donc d'un régime de protection renforcé.

Le HDS : qui doit être certifié ?

Le HDS (Hébergement de Données de Santé) est le cadre légal français qui encadre le stockage des données de santé. Il est inscrit à l'article L.1111-8 du Code de la santé publique. Toute structure qui héberge des données de santé pour le compte d'un tiers doit être certifiée HDS, label délivré par l'Agence du Numérique en Santé (ANS) après audit. Le référentiel s'appuie sur les normes ISO 27001, 27017, 27018 et 20000-1, complétées d'exigences spécifiques au secteur santé.

À retenir si vous êtes médecin libéral : vous n'avez pas besoin d'être HDS vous-même. Mais dès que vous confiez des données patient à un prestataire (logiciel de cabinet, outil cloud, SaaS médical), vous devez vous assurer qu'il stocke ces données chez un hébergeur certifié HDS. Faute de quoi, votre contrat avec lui pourrait être considéré comme nul.

Côté SuperDr : nous hébergeons l'intégralité des données patient (dossiers, conversations, observations) en France, chez un hébergeur certifié HDS.

Pseudonymisation et anonymisation : deux choses différentes

Ces deux mots sont souvent confondus, mais le RGPD les distingue clairement.

Anonymisation : transformation irréversible. Une fois les données anonymisées, plus personne — pas même celui qui a fait la transformation — ne peut remonter à l'individu. Selon le considérant 26 du RGPD, les données anonymisées sortent du champ d'application du règlement. C'est extrêmement exigeant : la transformation doit neutraliser tout risque d'individualisation, de corrélation et d'inférence.

Pseudonymisation : remplacement des identifiants par des codes (tokens), avec une table de correspondance conservée séparément qui permettrait, si nécessaire, de retrouver l'identité. C'est réversible, donc les données restent des données personnelles soumises au RGPD. Mais c'est une mesure de sécurité forte, explicitement encouragée par le RGPD (articles 25 et 32) et par la CNIL.

Dans le langage courant, on parle souvent « d'anonymisation » pour désigner ce qui est, juridiquement, de la pseudonymisation. Nous utilisons le terme exact dans cet article pour être précis.

Comment SuperDr protège vos patients

Notre architecture repose sur un principe simple : sécurité technique d'abord, garanties contractuelles ensuite. Voici comment cela se traduit pour les trois flux qui touchent vos données patient.

Stockage. Tout ce qui constitue le dossier patient — contexte médical, conversations avec l'IA, observations générées — est stocké en France chez un hébergeur certifié HDS.

Reconnaissance vocale. L'audio de vos consultations est transcrit par un prestataire français certifié HDS qui ne conserve aucun enregistrement. Côté SuperDr, l'enregistrement est gardé 24 heures uniquement pour pouvoir intervenir en support technique en cas de problème, puis il est supprimé définitivement.

Génération d'observations par IA. C'est ici que se joue la difficulté : aucun fournisseur d'IA générative grand public n'est aujourd'hui certifié HDS pour ses services de LLM. Et un cadre contractuel — aussi solide soit-il (engagement de non-rétention, DPA, clauses contractuelles types) — n'est pas une garantie technique : pendant le traitement, le texte transite en clair sur les serveurs du fournisseur. Un opérateur, un sous-traitant en cascade ou une réquisition légale pourrait techniquement y avoir accès.

Notre choix d'architecture est donc de ne jamais transmettre d'information identifiante à un LLM. Avant chaque appel à notre prestataire d'IA générative, notre serveur :

1. Identifie automatiquement les éléments identifiants — nom, prénom, date de naissance, NIR, adresse, téléphone, email — à partir du dossier patient et de motifs de détection automatique.
2. Les remplace par des tokens neutres : [NOM_PATIENT_1], [DATE_NAISSANCE_1], etc. L'âge, lorsqu'il est mentionné, est transmis sous forme de tranche d'âge (par exemple « 40-50 » plutôt que « 46 ans ») afin de réduire d'autant le risque de ré-identification.
3. Envoie au prestataire un texte cliniquement utile, mais dépourvu de tout identifiant direct.
4. Reçoit la réponse (qui peut contenir ces mêmes tokens) et la dé-tokenise dans notre infrastructure HDS avant de la renvoyer au médecin.

La table de correspondance entre tokens et identités réelles ne sort jamais de nos serveurs. Elle est même éphémère : créée pour chaque requête, conservée en mémoire vive uniquement, et jetée à la fin de l'appel.

Concrètement, un opérateur du prestataire qui aurait accès au flux verrait quelque chose comme : « Quels sont les antécédents de [NOM_PATIENT_1] [PRENOM_PATIENT_1], née le [DATE_NAISSANCE_1] ? » — sans aucun moyen de relier ce texte à un patient réel.

Cette mesure technique correspond exactement à ce que la jurisprudence européenne demande depuis l'arrêt Schrems II (2020) pour tout transfert de données vers un sous-traitant : des mesures techniques supplémentaires aux clauses contractuelles, rendant les données non identifiables pour le tiers. C'est aussi la ligne défendue par la CNIL dans ses fiches pratiques sur l'IA.

Vos obligations en tant que médecin

En tant que médecin, vous restez responsable de traitement au sens RGPD pour les données de vos patients. SuperDr est votre sous-traitant.

Concrètement :

• Vous devez tenir un registre des activités de traitement (article 30 RGPD), même en cabinet individuel. La CNIL fournit un modèle simplifié.
• Vous devez informer vos patients que vous utilisez des outils numériques pour la gestion de leur dossier (article 13 RGPD) — un affichage en salle d'attente ou une mention dans la charte d'accueil suffit.
• SuperDr vous fournit un DPA (contrat de sous-traitance) qui formalise nos engagements de sécurité.

La CNIL a publié un référentiel « cabinet médical » hors recherche, qui constitue une feuille de route concrète. Et plus récemment, la CNIL et la HAS ont publié un guide commun sur l'IA en santé qui décrit les bonnes pratiques attendues.

Pour aller plus loin

• CNIL — Qu'est-ce qu'une donnée de santé ?
• ANS — Hébergement des Données de Santé
• CNIL — RGPD et professionnels de santé libéraux
• CNIL — Référentiel « cabinet »

Si vous avez des questions sur notre architecture ou notre conformité, l'équipe SuperDr est à votre disposition à l'adresse contact@superdr.care.