Données de santé et IA : ce que HDS et RGPD imposent aux cabinets médicaux

Un dentiste, un vétérinaire, un kiné ou un médecin qui veut automatiser ses rappels de rendez-vous ou déployer un agent IA touche presque toujours à des données de santé. Et les données de santé ne se traitent pas comme une liste d'emails marketing. Ce guide pose le cadre HDS et RGPD applicable aux cabinets, et surtout les réflexes concrets pour automatiser sans se mettre en faute. Note de prudence : nous ne sommes pas juristes, ce sont des recommandations pratiques à valider avec un DPO ou un avocat pour tout traitement sensible.

Pourquoi les données de santé sont-elles un cas à part ?

Le RGPD distingue les données personnelles classiques (nom, email, téléphone) des données sensibles, listées à son article 9. Les données de santé en font partie, au même titre que les données biométriques, génétiques ou relatives à la vie sexuelle.

La conséquence est simple : le traitement de ces données est interdit par principe, sauf exception explicite. Pour un cabinet médical, l'exception qui s'applique est généralement la fourniture de soins ou le consentement du patient. Mais cette exception ne dispense de rien : minimisation, sécurité, information du patient, registre des traitements, tout reste obligatoire et la barre est plus haute que pour une donnée ordinaire.

Une donnée de santé ne se limite pas au diagnostic. La CNIL retient une définition large. Sont concernés :

• Les données médicales directes : pathologie, traitement, antécédents, résultats d'examens.
• Les données déduisibles : le simple fait qu'une personne ait rendez-vous chez un cardiologue ou un psychiatre révèle déjà une information sur sa santé.
• Les données paramédicales : motif de consultation chez un kiné, suivi diététique, données d'un opticien sur la correction visuelle.

Pour les vétérinaires, la nuance compte : les données de santé d'un animal ne sont pas des données de santé au sens de l'article 9, qui ne vise que les personnes physiques. Mais le nom, l'adresse et les coordonnées du propriétaire restent des données personnelles classiques à protéger. Le cadre est plus souple, pas inexistant.

Le second pilier propre aux professions de santé, c'est le secret médical (ou secret professionnel pour les paramédicaux). Il est antérieur au RGPD et s'y ajoute. Faire transiter une information couverte par le secret vers un outil tiers sans encadrement, c'est un risque déontologique en plus du risque RGPD. Pour le cadre RGPD général de l'IA, notre article sur le RGPD appliqué à l'IA générative en 2026 détaille les obligations communes à toutes les structures.

Qu'est-ce que l'hébergement HDS et quand est-il obligatoire ?

HDS signifie Hébergeur de Données de Santé. C'est une certification française, encadrée par le Code de la santé publique, qui impose des exigences de sécurité, de traçabilité et de confidentialité à tout prestataire qui héberge des données de santé à caractère personnel pour le compte d'un professionnel.

L'obligation est claire : dès qu'un tiers héberge vos données de santé, ce tiers doit être certifié HDS. Cela vise les logiciels de gestion de cabinet, les solutions de prise de rendez-vous en ligne, les services de stockage cloud. Dès que vous déléguez l'hébergement à un fournisseur, la certification devient le point de contrôle.

Quelques repères pour ne pas se tromper :

• La certification HDS concerne l'hébergement, pas l'usage en interne. Stocker vos dossiers sur un serveur certifié, oui. Le médecin qui consulte le dossier n'a pas besoin d'être lui-même certifié.
• Les grands hébergeurs (OVHcloud, Scaleway, AWS, Azure, Google Cloud) proposent des offres certifiées HDS, mais toutes leurs offres ne le sont pas. Il faut vérifier la zone et le service précis.
• Un LLM grand public n'est pas un hébergeur HDS. ChatGPT, Claude.ai ou Gemini dans leur version consumer ne sont pas conçus ni certifiés pour héberger des données de santé françaises. C'est le point que la plupart des cabinets ignorent au moment de tester un agent IA.

Le tableau ci-dessous résume où se situe l'obligation selon le scénario.

Scénario	HDS requis ?	Pourquoi
Logiciel de gestion patients hébergé chez un prestataire	Oui	Hébergement de données de santé par un tiers
Solution de prise de RDV en ligne stockant motifs de consultation	Oui	Le motif est une donnée de santé
Agent IA recevant nom + date de RDV uniquement	Non, en principe	Pas de donnée de santé transmise
LLM grand public auquel on colle un compte rendu médical	Inadapté	Outil non certifié, secret médical exposé

Où passent vraiment les données quand un agent IA traite un patient ?

C'est la question que personne ne se pose avant de brancher un chatbot, et c'est la plus importante. Quand un agent IA répond à un patient ou traite une demande, le contenu de la conversation (le prompt) part vers un serveur, est traité par un modèle, et souvent journalisé quelque part.

Trois maillons à tracer :

Le prompt. Tout ce que l'agent reçoit en entrée. Si un patient écrit "je rappelle pour mes résultats d'analyse de la thyroïde", cette phrase contient une donnée de santé, même si vous ne l'aviez pas prévu. L'agent l'a en mémoire, le modèle la traite, et selon l'outil, elle peut être conservée.

Le modèle et son hébergement. Un LLM en version API peut être configuré en zone UE avec garantie de non-entraînement, mais ce n'est pas le cas par défaut sur les versions grand public. Et même configuré proprement, un fournisseur d'IA standard n'est pas certifié HDS pour de l'hébergement de données de santé.

La journalisation. Logs de conversation, mémoire conversationnelle, sauvegardes. C'est souvent l'angle mort : on configure bien l'API mais on oublie que les conversations sont stockées indéfiniment dans un outil tiers non conforme.

Le risque concret n'est pas théorique. Un agent mal cadré crée un point de fuite où des données sensibles circulent et stagnent hors de tout cadre HDS. C'est exactement le mécanisme du shadow IA, ces outils adoptés sans validation, qu'on détaille dans notre article sur les risques du shadow IA en entreprise. Avant même de parler hébergement, sécuriser ce qui entre dans l'agent est une discipline en soi, abordée dans nos 12 règles pour sécuriser les prompts Claude et GPT.

Comment concevoir un agent IA qui évite les données sensibles ?

Voici la bonne nouvelle, et elle change tout sur le plan budgétaire et juridique. Une grande partie des cas d'usage utiles à un cabinet ne nécessite aucune donnée de santé.

Un rappel de rendez-vous a besoin d'un nom et d'une date. Pas du motif, pas du diagnostic. Une relance de patient qui n'a pas reconfirmé a besoin d'un prénom et d'un créneau. Conçu ainsi, l'agent ne fait transiter aucune donnée sensible, et le sujet HDS sur la partie IA disparaît presque entièrement. C'est le cas d'un de nos déploiements détaillé dans notre cas client rappels de vaccins en cabinet vétérinaire, où l'agent ne manipule que des coordonnées et des échéances, jamais de données médicales.

Trois principes de conception :

Minimisation. Ne jamais envoyer à l'agent plus que strictement nécessaire. Si le rappel fonctionne avec "Bonjour Mme Durand, rappel de votre RDV jeudi 14h", inutile d'y joindre le motif.

Pseudonymisation. Quand un identifiant est nécessaire, utiliser une référence interne plutôt qu'un nom complet, et garder la table de correspondance dans votre système métier conforme, pas dans l'agent.

Cloisonnement. La donnée sensible reste dans le logiciel de gestion certifié HDS. L'agent IA ne fait que déclencher des actions (envoyer un rappel, transférer à un humain) sans accéder au fond du dossier.

Le tableau suivant classe les cas d'usage courants par niveau de sensibilité et la précaution adaptée.

Cas d'usage	Niveau de sensibilité	Précaution principale
Rappel de RDV (nom + date)	Faible	Minimisation, pas de motif transmis
Relance patient sans confirmation	Faible	Pseudonymisation possible
Réponse aux questions horaires / tarifs	Faible	Aucune donnée patient en jeu
Prise de RDV avec motif de consultation	Élevé	Hébergement HDS + DPA + cloisonnement
Triage de symptômes par chatbot	Très élevé	HDS, DPIA, supervision humaine, avis juridique
Synthèse de comptes rendus médicaux	Très élevé	HDS, DPA, validation DPO obligatoire

La règle pratique : commencer par les cas d'usage à faible sensibilité, qui apportent déjà un vrai gain de temps, et ne traiter les cas sensibles qu'avec un cadrage complet.

Quelles précautions concrètes avant de se lancer ?

Une checklist en six points, à dérouler avant tout déploiement.

1. Cartographier les données. Lister précisément ce que l'agent va recevoir et produire. Tant qu'aucune donnée de santé n'apparaît, le chantier reste léger. Dès qu'il y en a une, le cadre se durcit.

2. Vérifier l'hébergement. Si des données de santé transitent ou sont stockées par un tiers, ce tiers doit être certifié HDS. Demander l'attestation, vérifier la zone géographique du service.

3. Encadrer par un DPA. Le Data Processing Agreement (contrat de sous-traitance RGPD) avec chaque prestataire est obligatoire dès qu'un sous-traitant traite des données pour votre compte. Il précise les finalités, la sécurité, le sort des données en fin de contrat.

4. Vérifier les transferts hors UE. Si le modèle ou l'hébergement sort de l'Union européenne, il faut un encadrement (clauses contractuelles types, déploiement zone UE). Pour des données de santé, privilégier un hébergement et un traitement en UE.

5. Tenir le registre des traitements. Tout traitement de données de santé doit figurer au registre : finalité, base légale, durée de conservation, mesures de sécurité. Une DPIA est généralement attendue dès qu'on traite des données sensibles à une certaine échelle.

6. Valider avec un professionnel. Pour tout traitement sensible, faire relire le dispositif par un DPO ou un avocat spécialisé. Le coût d'un avis est sans commune mesure avec celui d'une fuite ou d'une sanction CNIL.

Ces points rejoignent largement les obligations de l'AI Act qui s'applique aussi aux cabinets, détaillées dans notre checklist de conformité AI Act pour PME.