Données de santé et IA, ce que la certification HDS ne couvre pas

Commençons par le mot, parce que beaucoup de gens se croient hors du sujet alors qu’ils sont dedans.

Une donnée de santé, c’est toute information relative à l’état de santé physique ou mental d’une personne. Un diagnostic, une prescription, un compte rendu opératoire, un résultat biologique, une imagerie, un antécédent.

⚠ Mais aussi, et c’est là que ça surprend, le simple fait qu’une personne soit hospitalisée. Qu’elle bénéficie d’une aide à domicile pour perte d’autonomie. Qu’elle soit suivie pour une pathologie chronique. Vous n’avez pas besoin de connaître la maladie pour manipuler une donnée de santé.

Ces données sont dites sensibles pour une raison qui n’est pas administrative. Elles touchent à l’intimité et à la vulnérabilité de quelqu’un. Quand un patient confie son histoire médicale, il confie une part de lui-même.

En France, elles ne peuvent pas être confiées à n’importe qui. ⚠ Attention à la portée exacte, on la sur-généralise tout le temps. L’obligation vise l’hébergement pour le compte d’un tiers. Dès que vous confiez vos données à un prestataire extérieur, il doit être certifié HDS, pour hébergeur de données de santé. Ce n’est pas un label commercial, c’est une obligation du code de la santé publique. Le praticien qui garde ses dossiers sur son propre serveur, lui, n’est pas concerné par le HDS. Il reste tenu par le RGPD, ce qui n’est pas rien.

LE HDS EN 4 LIGNES

  CE QUE C'EST
    Une certification obligatoire de l'HEBERGEUR,
    pas du logiciel ni du modele.

  CE QU'ELLE COUVRE
    Securite physique des centres de donnees,
    gestion des acces, tracabilite des operations,
    continuite de service.

  CE QU'ELLE NE COUVRE PAS
    Ce que fait votre application avec la donnee
    une fois qu'elle est arrivee. Et surtout, ce
    qui reste apres.

  ⚠ Le referentiel a change. La version 2, prise
    par arrete du 26 avril 2024 et publiee au JO le
    16 mai 2024, s'impose depuis le 16 mai 2026,
    fin des 24 mois de transition. Une version 2.1
    est annoncee pour la fin 2026.

Un cloud grand public ne convient pas, même s’il est performant, même s’il est pratique. La performance ne remplace pas la conformité. C’est le point de départ, et ce que deviennent les données de vos patients dans vos logiciels métier est le prolongement direct de cette question.

⭐ Et une échéance vient de tomber, que presque personne n’a vue passer.

Un décret du 24 mars 2026, publié 2 jours plus tard, a durci le cadre. Il crée un principe de territorialité du stockage et impose de la transparence sur ce qui sort d’Europe. Ses obligations les plus lourdes entrent en vigueur 6 mois après la publication, donc fin septembre 2026.

CE QUE LE DECRET DE MARS 2026 AJOUTE

  1. LE STOCKAGE RESTE EN EUROPE
     Exclusivement sur le territoire de l'Union
     ou de l'Espace economique europeen. Ce n'est
     plus une preference, c'est un principe.

  2. LES ACCES DISTANTS SONT ENCADRES
     Depuis un pays tiers, seulement dans les
     conditions du chapitre V du RGPD.

  3. LE CONTRAT DOIT DIRE CERTAINES CHOSES
     Les lois etrangeres susceptibles de
     s'appliquer, les mesures prises contre
     elles, et le risque qui reste malgre tout.

  4. LA CARTOGRAPHIE DEVIENT PUBLIQUE
     L'hebergeur publie et tient a jour ses
     transferts hors Union et ses acces distants.

  ⚠ Le 4 est le plus utile pour vous. Vous n'avez
    plus a deviner ou passent vos donnees, votre
    hebergeur doit le publier. Allez le lire.

Elle tient en une phrase, et elle ne souffre pas d’exception.

Pas de donnée patient dans un assistant grand public. Même avec un compte payant. Même avec les meilleures intentions.

La raison n’est pas la qualité du modèle, qui peut être excellente. C’est que la donnée part chez un hébergeur qui n’est pas certifié pour la recevoir, ce qui vous met en défaut sur 2 terrains à la fois, l’obligation d’hébergement et le RGPD.

Pour traiter de la donnée patient avec une IA, il faut un contrat spécifique et un hébergement certifié. Ça ne se règle pas en ouvrant un compte, et un praticien seul n’y arrive pas. Il faut passer par la direction des systèmes d’information à l’hôpital, ou se faire accompagner en libéral.

LES 4 EXIGENCES RGPD QUI DECIDENT D'UN PROJET D'IA

  FINALITE       On ne collecte pas au cas ou. On
                 collecte pour une raison definie.
                 Article 5.1.b.

  MINIMISATION   On ne recueille que le necessaire.
                 Plus n'est pas mieux. Trop de
                 donnees augmente le risque.
                 Article 5.1.c.

  CONSERVATION   La donnee ne se garde pas pour
                 toujours. C'est l'exigence qui
                 porte tout le reste de cet
                 article. Article 5.1.e.

  TRACABILITE    Savoir qui a accede a quoi, quand
                 et pourquoi. ⚠ Ce n'est PAS un
                 principe du RGPD, c'est la
                 consequence de l'article 5.2, qui
                 vous demande de PROUVER que vous
                 respectez les autres.

  ⚠ L'article 5 en pose 6 au total, plus la
    responsabilite. Ces 4 sont ceux qui tranchent
    un projet d'IA. Les 2 autres, exactitude et
    licite-loyal-transparent, comptent aussi mais
    ne sont pas ce qui bloque en pratique.

Ce quatrième principe est exactement le sujet de ce qu’il faut journaliser quand une IA travaille pour vous, et il vaut bien au-delà de la santé.

Voici le réflexe qui rassure à tort. On retire le nom, et on se dit que le problème est réglé.

Il ne l’est pas.

Anonymiser n’est pas coller l’étiquette anonyme sur un fichier. Il faut pouvoir soutenir que la personne n’est plus identifiable compte tenu des moyens raisonnablement susceptibles d’être employés. C’est une exigence beaucoup plus haute qu’un simple retrait d’identité.

L’exemple que donnent les praticiens est parlant. Vous parlez d’une pathologie rare, vous retirez le nom, mais vous gardez la zone géographique. Le patient est retrouvable. Il y a peut-être 3 personnes dans le département qui présentent ce tableau.

⚠ La conséquence pratique est contre-intuitive. Plus le cas est intéressant à soumettre à une IA, plus il est rare, et plus il est ré-identifiable. Les dossiers que vous auriez le plus envie de faire analyser sont précisément les plus dangereux à envoyer. Le versant technique de ce problème, et pourquoi l’exécution locale y répond mieux que l’anonymisation, est détaillé dans traiter vos données sensibles avec une IA souveraine.

Le Comité européen de la protection des données, qui réunit les autorités nationales dont la CNIL, a adopté le 7 juillet 2026 des lignes directrices sur l’anonymisation. Elles posent 3 critères, et il faut échouer aux 3 pour qu’un jeu de données soit vraiment anonyme. Peut-on isoler un individu, peut-on relier 2 enregistrements entre eux, peut-on déduire une information sur quelqu’un.

⚠ Ce texte est un projet, en consultation publique jusqu’au 30 octobre 2026. Ce n’est pas encore du droit stabilisé, et il faut le citer comme tel. Mais la direction est claire, et un texte adopté le même jour rappelle qu’il n’existe aucune exemption générale pour les catégories particulières de données, dont la santé fait partie. La masse ne dilue pas le statut juridique d’une ligne.

Voilà le cœur du sujet, et il est rarement posé aussi clairement.

Trois certifications reviennent systématiquement dans les appels d’offres en santé. Elles sont sérieuses, nécessaires et légitimes. Aucune ne répond à la question que pose un modèle de langage.

LES 3 CERTIFICATIONS, ET LEUR PERIMETRE REEL

  HDS
    Certifie l'HEBERGEUR. Securite physique des
    centres de donnees, gestion des acces,
    tracabilite des operations, continuite.
    -> Ne dit rien du modele qui tourne dessus.

  ISO 27001
    Certifie un SYSTEME DE MANAGEMENT. Politiques,
    processus, controles. Le controle A.8.10 de
    l'annexe A couvre bien la suppression des
    informations, avec ses methodes.
    -> Mais il ne vise que les donnees STOCKEES.
       Jamais ce qui reste en memoire vive.

  SECNUMCLOUD 3.2
    Qualifie une OFFRE DE SERVICE cloud, pas une
    entreprise. Souverainete, protection des
    donnees, securite de l'infrastructure.
    -> Une offre hebergee SUR une offre qualifiee
       n'est pas qualifiee pour autant. C'est
       l'ANSSI elle-meme qui le precise.

  ⚠ La phrase a retenir. Le HDS certifie
    l'hebergeur, il ne certifie pas ce que le
    modele fait de la donnee, ni ce qu'il en garde.

La raison est simple et elle n’est reprochable à personne. Ces référentiels ont été rédigés avant que des modèles de langage tournent en production dans des établissements de santé. C’est le même décalage que celui qui traverse la réglementation de l’IA souveraine, écrite pour des logiciels, appliquée à des modèles. Une certification décrit ce qu’on a su vérifier au moment où on l’a écrite.

Un établissement peut donc cumuler les 3 et ne pas être capable de répondre à la question suivante. Après que votre modèle a traité un dossier patient, où est passée cette donnée.

Quand un programme traite une donnée, il la charge en mémoire vive. Le fichier peut être effacé du disque, la session peut être fermée, la donnée, elle, peut rester dans la mémoire de la machine jusqu’à ce que cet espace soit réutilisé par autre chose.

C’est vrai de tout logiciel depuis toujours. Ce qui change avec les modèles de langage, c’est le volume et la nature de ce qui transite, et le fait que plusieurs clients partagent souvent la même machine.

Le test se fait par jetons témoins. On injecte des valeurs reconnaissables, on lance un traitement, on déclenche la purge annoncée, puis on regarde ce qui reste.

LE PRINCIPE DU TEST PAR JETONS TEMOINS

  1. On injecte des valeurs uniques et
     reconnaissables a la place des vraies
     donnees. Nom, identifiant, diagnostic,
     numero de securite sociale.

  2. On fait traiter le dossier par le systeme,
     exactement comme en production.

  3. On declenche la purge annoncee par le
     fournisseur, et on note qu'elle est
     declaree conforme.

  4. On relit la memoire et on cherche les
     jetons. Tas applicatif, cache de pages,
     tampons du noyau, espace d'echange.

  ⚠ Le resultat est binaire. Zero jeton retrouve,
    l'effacement est prouve. Un seul jeton
    retrouve, il ne l'est pas.

Les jetons, vous pouvez les fabriquer vous-même. Ils doivent être uniques, improbables dans un texte normal, et faciles à rechercher.

#!/usr/bin/env bash
# jetons-temoins.sh
# Fabrique un jeu de valeurs temoins a la place des
# vraies donnees patient, pour un test de purge
# SUR VOS PROPRES SYSTEMES, avec accord ecrit.
set -euo pipefail

SEL=$(head -c 8 /dev/urandom | od -An -tx1 | tr -d ' \n')

cat > jetons.json <<JSON
{
  "nom":        "TEMOIN-NOM-$SEL",
  "identifiant":"TEMOIN-IPP-$SEL",
  "diagnostic": "TEMOIN-DIAG-$SEL",
  "nir":        "TEMOIN-NIR-$SEL"
}
JSON

echo "Jetons ecrits. Sel du jour : $SEL"
echo "Apres traitement et purge, cherchez ce sel"
echo "dans le vidage que votre fournisseur remet :"
echo "  grep -c \"$SEL\" vidage-fourni.bin"

La règle de lecture est simple. Zéro occurrence, la purge est prouvée. Une seule occurrence, elle ne l’est pas. Et le sel change à chaque test, donc un résultat ne peut pas être rejoué.

⚠ Une précaution d’honnêteté, et elle compte. La démonstration publique de ce test vient d’un éditeur qui vend l’outil d’audit correspondant. Ce n’est pas une étude indépendante et il faut la lire comme un argument commercial. En revanche, le phénomène sous-jacent, lui, n’a rien de nouveau ni de contesté, c’est de l’analyse de mémoire classique.

⚠ Et il faut être précis sur ce qui manque, sinon on se fait reprendre. La technologie qui répond au problème existe et elle est mature, c’est le chiffrement de la mémoire pendant le traitement, avec une attestation vérifiable à distance. Elle tourne en production chez de grands fournisseurs. Ce qui manque n’est donc pas la solution, c’est l’obligation d’en apporter la preuve. Aucune des 3 certifications n’exige de votre fournisseur qu’il vous montre, test à l’appui, qu’il ne reste rien après le traitement. Et rien ne l’oblige à vous dire s’il chiffre la mémoire ou non.

La conclusion utile n’est donc pas d’accuser un fournisseur, c’est de lui poser une question qu’il n’a pas l’habitude d’entendre. Et le sujet dépasse la santé, il rejoint ce qu’il faut journaliser quand une IA travaille pour vous.

Elle tient en une phrase, et la réponse sera probablement non. Ce n’est pas un reproche à lui faire.

Avez-vous un rapport prouvant que votre système efface réellement les données patient de la mémoire après chaque traitement ?

Posez-la par écrit. La réponse, quelle qu’elle soit, a de la valeur. Un non honnête vous dit où vous en êtes. Un oui vous engage à demander le rapport.

⚠ Et posez-la pour tous vos outils, pas seulement celui que vous avez choisi. Ceux que personne n’a recensés échappent à la question, et c’est tout le sujet de l’IA de l’ombre.

Et pendant que vous y êtes, mettez à jour le document qui rend tout le reste opposable, et que presque personne ne tient à jour.

⚠ Une croyance à évacuer tout de suite. Beaucoup de petites structures pensent être dispensées de registre en dessous de 250 salariés. Cette dispense ne joue pas pour les données de santé. Un cabinet de 3 personnes y est tenu comme un CHU.

Le registre n’a pas de forme imposée. Une ligne par traitement suffit, et elle prend 10 minutes.

{
  "traitement": "aide a la redaction de comptes rendus",
  "finalite": "gain de temps de saisie, pas d'aide au diagnostic",
  "responsable": "Dr. X, cabinet Y",
  "categories_personnes": ["patients"],
  "categories_donnees": ["etat de sante", "identite"],
  "destinataires": ["editeur Z", "hebergeur HDS W"],
  "hors_ue": false,
  "duree_conservation_mois": 24,
  "base_legale": "article 9.2.h du RGPD",
  "aipd_realisee": true,
  "mise_a_jour": "2026-08-16"
}

Trois champs méritent qu’on s’y arrête. hors_ue est celui que le décret de mars 2026 rend vérifiable, puisque votre hébergeur doit désormais publier ses transferts. duree_conservation_mois est celui qu’on laisse vide et qui coûte cher. Et aipd_realisee renvoie à l’analyse d’impact, qui est obligatoire pour un traitement de données de santé à grande échelle, et que presque personne ne fait avant d’avoir été rattrapé.

⚠ Le RGPD n’impose pas une révision annuelle, c’est une bonne pratique. Il impose un registre tenu à jour, ce qui est plus exigeant. Le cas qu’on oublie est le plus fréquent, brancher une IA sur un logiciel métier est un nouveau traitement, et il s’inscrit au registre le jour où on l’installe.

Terminons par le conseil le plus utile de tout cet article, et il vient de praticiens qui l’ont appris à leurs dépens.

Ne commencez pas par le dossier patient.

C’est le cas d’usage le plus excitant, c’est celui dont tout le monde parle, et c’est le meilleur moyen de tout arrêter au premier contrôle. Il demande un contrat spécifique, un hébergement certifié, une analyse d’impact, et un accompagnement. Rien de tout ça ne se fait en une semaine.

Or il existe une quantité d’usages qui ne touchent aucune donnée patient, et qui font gagner du temps immédiatement.

LES USAGES SANS DONNEE PATIENT

  RECHERCHE BIBLIOGRAPHIQUE
    Chronophage, sans aucun risque, et c'est le
    gain le plus cite par les praticiens.

  COURRIERS ADMINISTRATIFS
    Reponses aux organismes, demandes de
    materiel, relances. Zero donnee de sante.

  DOCUMENTS INTERNES
    Protocoles, notes de service, comptes rendus
    de reunion, supports de formation.

  VEILLE ET SYNTHESE
    Lecture de recommandations, resumes de
    publications, preparation de staffs.

  ⚠ Aucun de ces usages ne demande de HDS, parce
    qu'aucun ne fait sortir une donnee de sante.
    Vous prenez l'outil en main sans rien risquer.

L’ordre compte plus que l’outil. Vous formez l’équipe sur ce qui ne risque rien, vous découvrez où l’IA vous fait réellement gagner du temps, et ensuite vous traitez la question de l’hébergement, avec une idée précise de ce que vous voulez en faire.

Et si le sujet devient sérieux, la bonne question n’est plus quel modèle choisir, c’est où il tourne. C’est tout l’enjeu de traiter des données sensibles avec une IA souveraine, et la réponse tient en un principe. La donnée ne doit pas avoir à quitter la maison.