IA et secret médical : les trois verrous à poser avant de brancher vos données de santé

Oui, vous pouvez faire travailler une IA sur des données de santé sans rompre le secret médical. La condition tient en une phrase : le fournisseur du modèle ne doit jamais devenir un destinatairede l'information. Il peut la transporter et la traiter pour votre compte, il ne doit ni la lire, ni la garder, ni s'en servir.

Trois verrous permettent de le démontrer, et je les pose toujours dans cet ordre :

• le périmètre : ce que le modèle voit réellement, et qui d'autre le voit avec lui ;
• la base légale : l'article 9 du RGPD et l'analyse d'impact qui l'accompagne ;
• l'hébergement : un prestataire certifié HDS, avec des données stockées dans l'Espace économique européen.

Ce que le secret médical interdit, et ce qu'il permet

Le secret est posé par l'article L.1110-4 du code de la santé publique. Il couvre toutes les informations concernant une personne prise en charge, et il s'impose à tous les professionnels qui interviennent dans le système de santé, pas seulement aux médecins.

Il n'interdit pas le partage. Des professionnels identifiés peuvent échanger ce qui est strictement nécessaire à la coordination ou à la continuité des soins, et le patient doit être informé de son droit de s'y opposer. Le critère est double : un destinataire identifié, une information strictement nécessaire.

Un éditeur de modèle de langage ne remplit aucun des deux. Il ne soigne personne et ne fait partie d'aucune équipe de soins. S'il accède au contenu, la révélation est constituée.

Verrou 1 : maîtriser ce que le modèle voit

Le premier risque n'est pas le projet officiel. C'est le compte rendu collé dans un assistant grand public pour le reformuler. Ce geste envoie des données de santé nominatives à un tiers, sans contrat, sans hébergement certifié, parfois avec une conservation pour entraîner le modèle.

Je commence donc toujours par la cartographie des usages réels, Shadow AI compris. Ensuite, pour chaque usage retenu, vous fixez ce qui entre dans le prompt. La règle que j'applique est simple : le modèle reçoit le minimum qui lui permet de répondre, jamais le dossier entier.

Trois mesures techniques rendent ce verrou vérifiable :

• la pseudonymisation en amont : nom, numéro de sécurité sociale et dates de naissance remplacés avant l'appel au modèle ;
• la conservation nulle côté fournisseur, écrite au contrat et non supposée ;
• le cloisonnement du RAG : un soignant ne récupère que les documents des patients qu'il a le droit de voir.

Verrou 2 : la base légale et l'analyse d'impact

L'article 9 du RGPD interdit par principe le traitement des données concernant la santé. Il prévoit des exceptions, dont celle de la prise en charge sanitaire, sous la responsabilité d'un professionnel tenu au secret. Votre cas d'usage doit entrer dans l'une d'elles, et vous devez pouvoir dire laquelle.

Un outil d'aide à la rédaction utilisé par l'équipe soignante relève souvent de la prise en charge. Un projet de recherche ou d'amélioration du modèle relève d'un autre régime. Mélanger les deux finalités dans un même pipeline est l'erreur que je rencontre le plus souvent.

L'analyse d'impact n'est pas facultative. La liste publiée par la CNIL y soumet les traitements de données de santé mis en œuvre par les établissements pour la prise en charge des personnes, et elle cite les algorithmes de décision médicale en exemple.

Verrou 3 : un hébergement certifié dans l'Espace économique européen

L'article L.1111-8 du code de la santé publique impose une certification à l'hébergeur de données de santé recueillies à l'occasion d'activités de soins. Si votre fournisseur d'IA conserve ces données pour vous, même temporairement, posez-lui la question par écrit : est-il certifié HDS, et pour quelles activités ?

Le référentiel a changé. La version 2, publiée au Journal officiel le 16 mai 2024, impose une localisation physique des données dans l'Espace économique européen. Elle exige aussi une transparence sur les risques d'accès extra-européen. Les hébergeurs déjà certifiés avaient jusqu'au 16 mai 2026 pour s'y conformer : un certificat ancien format ne suffit plus.

La localisation ne règle pas tout. Un fournisseur soumis à une loi étrangère peut stocker en Europe et rester exposé à une demande d'accès. J'ai détaillé cet arbitrage dans héberger son IA dans l'Union européenne.

La méthode avant de brancher quoi que ce soit

Ces trois verrous se posent en quatre étapes. Aucune ne demande de développement : ce sont des décisions et des preuves.

L'ordre compte. Chercher un hébergeur avant d'avoir fixé ce que le modèle doit voir, c'est acheter une solution à un problème encore mal posé.

Ces verrous protègent aussi contre l'attaque. Un assistant médical exposé à une injection de promptpeut restituer un document qu'il n'aurait jamais dû lire. Moins il voit, moins il fuit.

Questions fréquentes

Le consentement du patient suffit-il ?

Rarement, et ce n'est pas la voie que je recommande en soins. Le consentement doit être libre, or un patient pris en charge est rarement en position de refuser. L'exception de prise en charge est souvent plus solide, à condition que l'usage serve réellement les soins.

Des données pseudonymisées restent-elles des données de santé ?

Oui. Une donnée pseudonymisée reste une donnée personnelle au sens du RGPD, puisque la réidentification reste possible. La pseudonymisation réduit le risque, elle ne vous sort pas du régime de l'article 9.

Que risque l'établissement en cas de fuite ?

Le risque pénal du secret et le risque administratif du RGPD se cumulent. La CNIL sanctionne surtout l'absence de mesures de sécurité élémentaires, comme je l'ai montré dans ce que la CNIL sanctionne vraiment. Le DPO a, lui, des exigences précises à poser : ce que le DPO doit exiger avant le feu vert.

Cet article expose une méthode, il ne constitue pas un conseil juridique. Si vous voulez savoir lequel de ces trois verrous manque chez vous, parlons-en trente minutes, ou consultez le détail de l'audit de sécurité et de conformité IA.