Agent IA et données de santé : HDS, pseudonymisation et architecture conforme en 2026

Ce guide ne liste pas d'outils IA médicaux : pour ce comparatif, voir les meilleurs outils IA pour le secteur médical. Il répond à une autre question : comment construire ou choisir un agent IA qui manipule des données de santé sans sortir du cadre HDS, RGPD et IA Act. Les usages métier sont décrits dans notre guide IA et secteur médical.

L'article L.1111-8 vise toute personne qui héberge des données de santé recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social. Un hébergeur qui les conserve sur support numérique doit détenir un certificat de conformité. La version en vigueur depuis le 1er juillet 2025 a été modifiée par l'article 32 de la loi n° 2024-449 du 21 mai 2024 (loi SREN).

L'article R.1111-8-8 précise ce qu'est l'hébergement : détenir des données de santé pour le compte du responsable de traitement qui les a produites ou recueillies, ou pour le compte du patient. Il prévoit une exception : recevoir brièvement des données pour les saisir, les mettre en forme, les imprimer ou les numériser ne constitue pas un hébergement. Le responsable qui externalise doit vérifier que son prestataire est certifié.

L'article R.1111-9 (version en vigueur depuis le 27 mars 2026) liste six activités d'hébergement :

1. la mise à disposition et le maintien en condition opérationnelle des sites physiques qui abritent le matériel ;
2. la mise à disposition et le maintien en condition opérationnelle de l'infrastructure matérielle ;
3. la mise à disposition et le maintien en condition opérationnelle de l'infrastructure virtuelle ;
4. la mise à disposition et le maintien en condition opérationnelle de la plateforme d'hébergement d'applications ;
5. l'administration et l'exploitation du système d'information ;
6. la sauvegarde des données de santé, archivage électronique compris.

Deux certificats sont généralement distingués : hébergeur d'infrastructure physique (activités 1 et 2) et hébergeur infogéreur (activités 3 à 6). Cette répartition est présentée par l'Agence du numérique en santé ; sa page n'a pas pu être rechargée le 15 septembre 2026, vérifiez-la sur esante.gouv.fr. Pour un agent IA, la conséquence est pratique : l'hébergeur qui fournit les serveurs n'est pas forcément certifié pour la plateforme applicative ou l'infogérance que vous lui confiez.

Qu'est-ce qu'une donnée de santé ? L'article 4(15) du RGPD la définit comme une donnée personnelle relative à la santé physique ou mentale d'une personne, soins compris, qui révèle son état de santé. La CNIL distingue trois cas : la donnée de santé par nature (dossier, diagnostic, résultat), par croisement avec d'autres données, et par sa destination. Une question libre posée à un chatbot de cabinet (« mon traitement me donne des vertiges ») entre dans la première catégorie.

Pour le 26 septembre 2026, Légifrance indique une entrée en vigueur à cette date ; certains cabinets d'avocats retiennent le 27 septembre. L'écart d'un jour ne change rien à la préparation : les contrats et la localisation doivent être prêts avant. Le calendrier complet de l'IA Act, modifié par le Digital Omnibus, est détaillé dans notre guide de l'IA Act pour les entreprises.

Le nouvel article R.1111-9-1 pose deux règles.

• Stockage : lorsque l'activité d'hébergement donne lieu à un stockage, celui-ci se fait exclusivement sur le territoire d'un État membre de l'Union européenne ou partie à l'accord sur l'Espace économique européen.
• Transferts : si l'hébergeur ou l'un de ses sous-traitants transfère ces données hors UE/EEE, y compris par un accès à distance, le transfert n'est possible qu'avec une décision d'adéquation de la Commission (article 45 du RGPD) ou les garanties appropriées de l'article 46. Dans ce second cas, le contrat d'hébergement doit mentionner l'absence de décision d'adéquation et décrire les garanties.

Le même décret modifie l'article R.1111-11 III : l'hébergeur doit publier et tenir à jour une cartographie des transferts de données hors UE/EEE, des accès à distance possibles et du risque d'accès non autorisé par des autorités de pays tiers.

Pour un agent IA, l'accès à distance est le point le plus souvent oublié. Une équipe de support basée hors UE qui peut consulter les journaux, un outil d'observabilité américain qui reçoit les traces des prompts ou un sous-traitant d'infogérance offshore sont tous concernés. Demandez la cartographie à chaque hébergeur et vérifiez que les outils branchés sur l'agent y figurent.

Chaque composant d'un agent IA a un statut différent au regard de l'hébergement : certains conservent les données, d'autres ne font que les voir passer.

L'index vectoriel est le composant le plus souvent sous-estimé. Dans un RAG, la base ne contient pas seulement des vecteurs : elle conserve aussi les passages de documents qui seront renvoyés au modèle. Si ces documents sont des comptes rendus ou des courriers patients, la base vectorielle stocke des données de santé. Notre guide du RAG en entreprise détaille son fonctionnement, et le cas du tri de dossiers patients montre un flux type.

Nous n'avons trouvé, au 15 septembre 2026, ni texte ni position de l'ANS ou de la CNIL qui dise si l'envoi d'un prompt contenant des données de santé à une API de modèle constitue un hébergement. Les points qui suivent relèvent de notre analyse.

• L'exception de R.1111-8-8 vise la réception brève pour saisir, mettre en forme, imprimer ou numériser. Une inférence ressemble à un traitement bref, mais elle n'entre dans aucune de ces quatre catégories.
• Si le fournisseur conserve les requêtes et les réponses (journaux, surveillance des abus, historique de l'assistant), il détient des données pour le compte du client, ce qui correspond à la définition de l'hébergement.
• Depuis le 26 septembre 2026, un fournisseur qui traite ou conserve ces données hors UE/EEE ajoute la question du transfert au sens de R.1111-9-1.

Conséquence pratique : tant que la question n'est pas tranchée, faites valider l'appel à une API externe par un avocat ou votre DPO, et privilégiez les architectures 1 ou 2 décrites plus bas. Les engagements de conservation et de sous-traitance des fournisseurs de modèles se lisent dans leurs contrats de traitement, comparés dans notre guide RGPD et DPA d'OpenAI, Anthropic et Mistral. Notre guide sécurité des agents IA liste les garde-fous techniques côté agent.

Chez les grands clouds, le périmètre HDS suit la liste des services certifiés ISO/IEC 27001 et une liste de régions. Un calcul certifié ne veut pas dire que le service d'IA managé l'est aussi : il faut lire le certificat, la liste de services et le contrat signé.

Deux lectures à retenir. D'abord, « certifié HDS » sur la page d'un cloud concerne un ensemble de services et de régions, jamais tout le catalogue. Ensuite, aucun fournisseur de modèles relevé ne publie de certificat HDS pour son API directe. Si vous passez par une intégration Claude ou un autre modèle pour des usages santé, le choix du canal (API directe, cloud certifié, modèle auto-hébergé) se fait avant d'écrire la première ligne de code.

1. Modèle open-weight auto-hébergé en zone HDS

Le modèle tourne sur des instances GPU d'un hébergeur dont le certificat couvre ces instances (Scaleway liste explicitement les GPU Instances dans son périmètre HDS). Toutes les données restent dans la zone certifiée : orchestrateur, index vectoriel, historique, journaux et inférence. C'est l'option la plus simple à défendre juridiquement. Les contreparties : l'exploitation des GPU et des mises à jour du modèle, et un choix limité aux modèles dont les poids sont publiés.

2. Pseudonymiser avant tout appel à un modèle externe

Une passerelle, hébergée en zone HDS, remplace noms, numéros de sécurité sociale, dates de naissance, adresses et identifiants de dossier par des jetons avant l'appel. La table de correspondance ne quitte jamais la zone HDS, et la réponse du modèle est ré-identifiée à son retour. Deux limites : un texte médical libre contient des indices indirects (profession rare, commune, date d'hospitalisation), et des données pseudonymisées restent des données personnelles, comme le rappellent les lignes directrices 01/2025 de l'EDPB et la sanction IQVIA. Le RGPD, le contrat de traitement et l'analyse de transfert s'appliquent toujours.

3. Service IA d'un hyperscaler couvert par son certificat

Un service de modèle managé est utilisable s'il entre dans le périmètre du certificat HDS du cloud, dans une région EEE, avec les conditions contractuelles HDS signées. Chez AWS, Bedrock entre dans le périmètre selon la règle publiée ; chez Microsoft et Google, la couverture du service IA doit être confirmée. Vérifiez aussi où tourne l'inférence : un routage inter-régions qui sortirait de l'EEE contredirait R.1111-9-1.

Dans les trois cas, l'agent lui-même se conçoit comme un agent IA sur mesure : les composants de stockage, les journaux et la passerelle se choisissent selon cette carte dès la conception.

Une instance n8n qui traite les messages des patients d'un cabinet ou d'une clinique garde des données de santé dans sa base, ses fichiers, ses journaux et ses sauvegardes. Le serveur qui la fait tourner, la base et le stockage doivent être chez un hébergeur certifié HDS pour les activités qu'il assure. L'appel au modèle se règle à part.

Par défaut, n8n enregistre chaque exécution. Selon sa documentation, EXECUTIONS_DATA_SAVE_ON_SUCCESS et EXECUTIONS_DATA_SAVE_ON_ERROR valent « all », et EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS vaut « true » : les exécutions réussies, en erreur et lancées à la main sont gardées. Une exécution enregistrée contient les données traitées par chaque nœud, donc le message du patient, la réponse du modèle et le texte extrait d'un document.

La purge est active par défaut (EXECUTIONS_DATA_PRUNE). Elle supprime les exécutions terminées depuis plus de 336 heures, soit 14 jours (EXECUTIONS_DATA_MAX_AGE), et les plus anciennes au-delà de 10 000 (EXECUTIONS_DATA_PRUNE_MAX_COUNT). Deux exceptions comptent pour un agent santé. Une exécution en attente, par exemple arrêtée sur un nœud Wait jusqu'à une validation humaine, n'est pas purgée. Une exécution annotée d'une étiquette ou d'une note ne l'est jamais.

Ces réglages réduisent le volume et la durée de conservation. Une exécution gardée reste une copie de données de santé, à placer en zone HDS. Pour un workflow santé, nos réglages de départ sont EXECUTIONS_DATA_SAVE_ON_SUCCESS=none et EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false, les exécutions en erreur gardées pour le dépannage et EXECUTIONS_DATA_MAX_AGE aligné sur la durée fixée dans l'analyse d'impact. Les mêmes choix se font aussi dans les paramètres de chaque workflow.

Le masquage des données d'exécution, réservé à l'offre Enterprise et disponible depuis la version 2.16.0, ne change rien à l'hébergement. La documentation de n8n précise qu'il ne chiffre ni ne modifie les données en base : il les cache à l'affichage, et quiconque accède directement à la base peut les lire.

Les fichiers suivent le même chemin. n8n garde les données binaires en mémoire par défaut. Avec N8N_DEFAULT_BINARY_DATA_MODE=filesystem, il les écrit sur disque, et en mode queue la documentation demande le mode « database ». La variable N8N_EXECUTION_DATA_STORAGE_MODE permet d'écrire les données d'exécution sur disque ou dans un stockage objet S3 ou Azure, ces deux derniers réservés aux offres Business et Enterprise auto-hébergées. Le bucket qui reçoit les ordonnances et les comptes rendus fait partie de la zone HDS au même titre que la base.

Les identifiants de connexion (agenda, logiciel métier, messagerie) sont chiffrés en base avec une clé que n8n génère au premier lancement et range dans ~/.n8n, sauf si vous la fournissez par N8N_ENCRYPTION_KEY. Avec SQLite, la base et la clé sont dans ce même dossier : une copie du dossier permet de déchiffrer les identifiants. Fournissez la clé par le gestionnaire de secrets de l'hébergeur et gardez-la hors des sauvegardes de la base.

Les journaux du serveur partent par défaut vers la console au niveau « info » (N8N_LOG_OUTPUT, N8N_LOG_LEVEL), donc vers l'outil qui collecte les journaux des conteneurs. La documentation ne dit pas qu'ils recopient le contenu des exécutions : vérifiez-le sur votre instance avant la mise en production. Si un message de patient y apparaît, l'outil de collecte entre dans la zone HDS et dans la cartographie des accès à distance. La CNIL recommande de limiter les données personnelles dans les journaux et de les conserver de six mois à un an (délibération n° 2021-122 du 14 octobre 2021).

Les sauvegardes de la base et des volumes relèvent de l'activité 6 de l'article R.1111-9, la sauvegarde des données de santé. Elles restent dans l'UE ou l'EEE (article R.1111-9-1), chez un hébergeur certifié pour cette activité.

Pour n8n Cloud, la page sécurité de n8n indique au 4 novembre 2026 un hébergement sur Microsoft Azure, des données stockées dans l'UE et un programme de sécurité aligné sur SOC 2. Elle ne mentionne aucune certification HDS. Le certificat HDS d'Azure couvre l'infrastructure. n8n, qui exploite et administre la plateforme, assure les activités 4 et 5 et devrait, selon notre lecture, être certifié lui-même. Tant que n8n ne produit pas ce certificat, nous n'utilisons pas n8n Cloud pour un workflow qui stocke des données de santé.

Un autre flux part vers un modèle : l'assistant intégré à l'éditeur. Selon la documentation de n8n, n8n Assistant peut traiter des détails d'exécutions et d'erreurs choisis pour le dépannage, et sur une instance auto-hébergée il passe par le compte du fournisseur de modèle que vous configurez. Sur une instance qui traite des données de santé, il suit la même règle que les nœuds de modèle.

L'appel au modèle dans nos workflows

Le nœud qui appelle le modèle envoie le prompt hors de l'instance et reçoit la réponse du fournisseur. La section sur les API de modèles explique pourquoi ce point n'est pas tranché. Dans les workflows n8n que Lumyniq livre pour la santé, aucun nœud n'envoie de donnée de santé identifiante à une API dont le fournisseur ne produit pas un certificat HDS couvrant ce service. Nous ne présentons aucun fournisseur de modèle comme certifié HDS.

Le workflow suit l'une des trois architectures décrites plus haut. Dans la première, le modèle open-weight tourne sur des instances GPU de la zone HDS et n8n l'appelle par un nœud HTTP Request sur le réseau privé. Dans la deuxième, un nœud de pseudonymisation exécuté dans la même instance remplace les identifiants avant le nœud de modèle, et la table de correspondance reste dans la base HDS. Dans la troisième, le modèle est servi par un cloud dont le certificat HDS couvre ce service, confirmé par écrit.

Le choix se fait à l'audit, avec l'hébergeur. Notre page agence n8n décrit la façon dont nous construisons et exploitons ces workflows. Les usages concernés, de la prise de rendez-vous au renvoi au 15 sur un signe d'alerte, sont détaillés sur notre page agent IA pour cabinet médical.

Pseudonymiser consiste à remplacer les identifiants directs tout en gardant la possibilité de ré-identifier, avec une information conservée à part. Anonymiser suppose que la ré-identification ne soit plus possible par des moyens raisonnables ; les données sortent alors du RGPD. Les lignes directrices 01/2025 de l'EDPB, adoptées le 16 janvier 2025 et soumises à consultation jusqu'au 14 mars 2025, détaillent des exemples médicaux ; nous n'avons pas trouvé de version finale au 15 septembre 2026.

Ce que ces décisions impliquent pour un agent IA :

• ne qualifiez pas d'« anonymes » des prompts dont seuls les noms ont été retirés ;
• activez l'authentification multifacteur sur toute console donnant accès aux journaux ou à l'index ;
• relisez régulièrement les journaux d'accès et alertez sur les consultations anormales ;
• limitez l'accès aux conversations à l'équipe qui prend en charge le patient.

Pour développer ou évaluer un modèle sur des données de santé, la page de la CNIL « IA et santé » du 5 mars 2026 renvoie aux formalités préalables (méthodologies de référence MR-001, MR-003, MR-004 ou autorisation) et recommande minimisation, analyse d'impact et durées de conservation définies.

Les trois critères de l'ANSM (page mise à jour le 6 janvier 2026) : un logiciel est un dispositif médical s'il a une finalité médicale, produit un résultat propre à un patient et crée une information médicale nouvelle, au-delà du stockage, de la communication ou de la simple recherche de données. Un agent de prise de rendez-vous, un outil administratif ou un stockage de dossiers ne sont pas des dispositifs médicaux.

La règle 11 du règlement (UE) 2017/745, en résumé : un logiciel qui fournit des informations utilisées pour prendre des décisions de diagnostic ou de traitement est en classe IIa, en IIb si une erreur peut entraîner une détérioration grave ou une intervention chirurgicale, et en III si elle peut causer un décès ou un dommage irréversible. Le guide MDCG 2019-11 donne les détails de qualification.

Depuis le 2 août 2026, l'article 50 impose d'informer une personne qu'elle échange avec une IA ; seul le marquage lisible par machine des contenus générés (article 50, paragraphe 2) bénéficie d'un délai jusqu'au 2 décembre 2026 pour les systèmes déjà sur le marché. Voir l'obligation de transparence des agents IA.

Pour un agent de prise de rendez-vous, la frontière entre renvoi vers le 15 et tri clinique est détaillée dans notre page sur les mots d'alerte et le renvoi au 15 en cabinet médical.

Le 30 octobre 2025, la HAS a publié « Premières clefs d'usage de l'IA générative en santé », destiné aux professionnels du sanitaire, du social et du médico-social. Il repose sur la méthode A.V.E.C. : Apprendre, Vérifier, Estimer, Communiquer. Chaque sortie de l'IA y est traitée comme une proposition susceptible de contenir des erreurs. Dans un agent, cela se traduit par une validation humaine avant tout message à portée médicale.

La HAS et la CNIL ont soumis à consultation, du 5 mars au 16 avril 2026, un projet de guide « Accompagner le bon usage des systèmes d'IA en contexte de soins » (PDF daté de février 2026). Il compte 10 fiches sur les étapes de déploiement, de l'achat au retrait du système, et 2 fiches sur la gouvernance et l'IA générative. Au 15 septembre 2026, nous n'avons pas trouvé de version finale.

Ce minimum de support s'ajoute au calcul, au stockage, aux sauvegardes et, pour l'architecture 1, aux instances GPU.

1. Cartographier chaque composant de l'agent et noter lesquels stockent des données de santé.
2. Obtenir le certificat HDS v2.0 de chaque hébergeur, avec les activités (1 à 6) et les services couverts.
3. Vérifier que les régions de stockage et d'inférence sont dans l'UE ou l'EEE.
4. Demander la cartographie des transferts et accès à distance prévue à l'article R.1111-11 III.
5. Mettre à jour le contrat d'hébergement avant le 26 septembre 2026 (clauses de transfert).
6. Faire valider par un avocat ou le DPO le statut des appels à une API de modèle externe.
7. Expurger ou pseudonymiser les journaux, traces et outils d'observabilité.
8. Sur n8n, régler EXECUTIONS_DATA_SAVE_* et EXECUTIONS_DATA_MAX_AGE, et placer la base, les fichiers et les sauvegardes en zone HDS.
9. Réaliser l'analyse d'impact (AIPD) et fixer les durées de conservation des conversations.
10. Activer l'authentification multifacteur et la revue des journaux d'accès.
11. Afficher l'information « vous échangez avec une IA » (article 50) et prévoir la reprise par un humain.
12. Qualifier le statut de dispositif médical selon les trois critères de l'ANSM.

Lumyniq, agence d'automatisation IA basée à Paris, conçoit des agents IA sur mesure, des intégrations Claude et des workflows n8n, notamment pour le secteur de la santé. Chaque projet commence par un audit du processus et des données concernées, qui fixe l'architecture et les hébergeurs avant tout devis.