Le secteur de la santé concentre à la fois un potentiel énorme pour l'IA et le cadre réglementaire le plus exigeant. Une donnée de santé n'est pas une donnée comme une autre : c'est une donnée sensible au sens du RGPD, dont le traitement par défaut est interdit sauf exceptions, et dont l'hébergement est soumis à la certification HDS en France.
Pour un directeur d'établissement, un éditeur de logiciel médical ou un cabinet, la question n'est donc jamais seulement « est-ce que l'IA peut faire ce travail ? » mais « est-ce que je peux le faire sans exposer des données patients ni sortir du cadre légal ? ». Les deux réponses sont souvent positives, à condition de concevoir le système correctement dès le départ.
Cet article fait le tour des usages réellement utiles de l'IA en santé, du régime juridique des données sensibles, de la certification HDS, des obligations RGPD propres à l'IA, et de l'architecture qui permet d'exploiter un modèle de langage sans transmettre de données patients hors de votre périmètre de confiance.
Les usages concrets de l'IA en santé
Les usages les plus matures de l'IA en santé ne sont pas le diagnostic autonome — fortement encadré et classé à haut risque — mais l'assistance administrative et documentaire, là où les professionnels perdent un temps considérable.
- Synthèse de dossiers patients — produire un résumé structuré d'un dossier volumineux pour préparer une consultation, en quelques secondes au lieu de plusieurs minutes de lecture.
- Transcription et compte rendu — transformer une consultation dictée en compte rendu médical pré-rédigé, que le praticien relit et valide.
- Codage des actes (CCAM, CIM) — proposer un codage à partir d'un compte rendu, avec validation humaine, pour fiabiliser la facturation.
- Prise de rendez-vous et tri — un agent conversationnel oriente le patient, qualifie le motif et réduit la charge du standard.
- Recherche documentaire interne — interroger en langage naturel des protocoles, recommandations ou la base documentaire de l'établissement.
Le point commun de ces usages : un humain reste dans la boucle de décision. L'IA accélère le travail, elle ne décide pas seule. C'est exactement le cadre que privilégient les régulateurs pour les usages sensibles. Beaucoup de ces fonctions relèvent d'un outil interne sur mesure plutôt que d'un produit générique.
Données de santé : un régime juridique renforcé
L'article 9 du RGPD classe les données concernant la santé parmi les catégories particulières de données, dont le traitement est interdit par principe. Il n'est autorisé que dans des cas précis : consentement explicite de la personne, finalités de médecine préventive ou de soins, intérêt public en santé, ou obligation légale.
Conséquences pratiques pour un projet IA :
- Base légale renforcée — il ne suffit pas d'un intérêt légitime : il faut s'appuyer sur l'une des exceptions de l'article 9, et la documenter.
- Analyse d'impact (DPIA) quasi systématique — un traitement de données de santé à grande échelle déclenche presque toujours l'obligation de réaliser une DPIA.
- Secret médical — au-delà du RGPD, le secret professionnel impose de restreindre strictement qui accède aux données et dans quel cadre.
- Minimisation stricte — n'envoyer au modèle que le strict nécessaire, jamais un dossier complet par réflexe.
Ce régime ne bloque pas l'innovation : il impose simplement de penser la conformité comme une composante de l'architecture, pas comme une couche ajoutée après coup. C'est la même logique que nous détaillons pour tout usage de LLM sur des données personnelles, en plus exigeant.
L'hébergement de données de santé (HDS)
En France, héberger des données de santé à caractère personnel pour le compte de tiers exige une certification HDS (Hébergeur de Données de Santé). Cette obligation est spécifique au droit français et s'ajoute au RGPD : un hébergeur conforme RGPD n'est pas automatiquement certifié HDS.
Ce que cela implique pour un projet IA :
- Toute la chaîne doit être HDS — si vos données patients transitent ou sont stockées chez un prestataire, ce prestataire doit être certifié HDS pour le périmètre concerné.
- Les API de LLM grand public ne sont généralement pas HDS — envoyer des données de santé identifiantes vers une API non certifiée est un problème de conformité majeur.
- Deux stratégies possibles — soit utiliser un hébergement et un modèle dans un environnement certifié HDS, soit pseudonymiser en amont pour que les données transmises ne soient plus identifiantes.
La voie la plus robuste consiste souvent à déployer un modèle dans une infrastructure maîtrisée et certifiée, ou à combiner pseudonymisation forte et hébergement européen. C'est un arbitrage à faire au cas par cas selon la sensibilité et le volume des données.
RGPD et IA : les obligations spécifiques
Au-delà du régime des données sensibles, l'usage d'un modèle de langage ajoute ses propres obligations. La CNIL a précisé que le RGPD s'applique pleinement aux systèmes d'IA, du développement à l'usage.
- Finalité claire — chaque usage IA doit avoir une finalité déterminée ; on ne réutilise pas des données de soins pour entraîner un modèle sans nouvelle base et information des personnes.
- Information des patients — la transparence impose d'informer que des traitements assistés par IA peuvent intervenir.
- Encadrement de la sous-traitance — tout fournisseur de modèle est un sous-traitant à encadrer par contrat (art. 28), avec interdiction de réutilisation des données.
- Supervision humaine — pour les usages à enjeu, une validation humaine doit rester systématique, ce qui rejoint les exigences de l'EU AI Act sur les systèmes à haut risque.
L'erreur classique consiste à brancher une API externe sur un logiciel métier sans se demander où partent les données. En santé, cette erreur peut constituer une violation grave. La conception « privacy by design » n'est pas un luxe : c'est le point de départ.
Quelle architecture pour rester conforme ?
L'architecture qui concilie utilité et conformité en santé combine généralement trois briques : une base documentaire interne, une couche de protection des données, et un modèle hébergé dans un cadre maîtrisé.
- RAG sur données internes — vos dossiers et protocoles restent stockés chez vous ; seuls les extraits pertinents sont transmis au modèle au moment d'une requête, ce qui minimise l'exposition. Voir notre guide RAG sécurisé en entreprise.
- Pseudonymisation automatisée — un composant détecte et masque noms, dates de naissance et identifiants avant tout envoi au modèle, puis réinjecte les vraies valeurs côté établissement.
- Modèle dans un cadre maîtrisé — modèle open source déployé on-premise ou dans un cloud certifié HDS, pour que rien ne sorte de votre périmètre.
Cette architecture transforme des obligations juridiques abstraites en mécanismes concrets. Elle est aussi celle qui rassure le plus facilement un DPO et une direction médicale, car elle rend la conformité démontrable plutôt que déclarative.
ROI et gains de temps mesurables
Le retour sur investissement de l'IA en santé se mesure surtout en temps administratif libéré et en fiabilisation des processus, pas en remplacement de l'acte médical.
- Comptes rendus — une transcription assistée peut faire passer la rédaction d'un compte rendu de plusieurs minutes à une relecture rapide, soit un gain de plusieurs heures par semaine pour un praticien à forte activité.
- Codage et facturation — une proposition de codage fiabilisée réduit les rejets et les pertes de recettes liées aux erreurs.
- Standard et prise de rendez-vous — un agent qui traite les demandes simples allège la charge du personnel d'accueil, qui se concentre sur les cas complexes.
- Recherche documentaire — retrouver un protocole en quelques secondes plutôt que de fouiller un intranet fait gagner du temps à chaque sollicitation.
Le bon réflexe est de chiffrer un usage précis sur un périmètre limité avant de généraliser : combien d'heures par semaine, sur quelle population d'utilisateurs, pour quel coût d'exploitation. Un pilote mesuré vaut mieux qu'un grand projet flou. C'est l'approche que nous appliquons en automatisation métier.
Par où démarrer un projet IA en santé
Démarrer un projet IA en santé ne consiste pas à choisir un modèle, mais à cadrer un usage à valeur, son régime juridique et son architecture cible. Voici un déroulé pragmatique.
- Identifier un usage administratif à fort volume — comptes rendus, codage, tri des demandes : là où le temps perdu est mesurable.
- Qualifier les données — sont-elles identifiantes ? peut-on pseudonymiser ? quel niveau de sensibilité ?
- Cadrer la conformité — base légale, DPIA, besoin HDS, information des patients, en lien avec votre DPO.
- Choisir l'architecture — RAG, pseudonymisation, hébergement maîtrisé ou certifié HDS.
- Lancer un pilote mesuré — un périmètre, des indicateurs, une supervision humaine, avant toute généralisation.
Cette méthode évite les deux écueils opposés : l'attentisme par peur réglementaire, et le déploiement précipité qui expose des données. Si vous portez un projet de ce type, échangeons sur votre cas pour définir l'architecture la plus adaptée à votre niveau de sensibilité.
FAQ — IA en santé : usages, RGPD et hébergement HDS
Puis-je utiliser ChatGPT ou Claude sur des données patients ?
Pas directement sur des données identifiantes. Les données de santé sont sensibles au sens du RGPD et leur hébergement en France relève de la certification HDS, que les API grand public n'ont généralement pas. Les options sûres sont de pseudonymiser fortement les données avant tout envoi, ou d'utiliser un modèle déployé dans un environnement maîtrisé ou certifié HDS, afin que rien d'identifiant ne sorte de votre périmètre.
Qu'est-ce que la certification HDS et est-elle obligatoire ?
La certification HDS encadre l'hébergement de données de santé à caractère personnel pour le compte de tiers en France. Elle est obligatoire dès que vos données patients sont stockées ou traitées par un prestataire externe. Elle s'ajoute au RGPD : un hébergeur conforme RGPD n'est pas automatiquement HDS. Toute la chaîne technique qui touche aux données de santé identifiantes doit donc être certifiée pour le périmètre concerné.
Dois-je réaliser une DPIA pour un projet d'IA en santé ?
Presque toujours. Un traitement de données de santé à grande échelle déclenche l'obligation d'analyse d'impact relative à la protection des données. Au-delà de l'obligation, la DPIA est un outil de conception : elle force à documenter la finalité, la base légale et les mesures de protection, et oriente l'architecture vers la conformité dès le départ. Elle se construit idéalement avec votre DPO en amont du projet.
L'IA peut-elle poser un diagnostic à la place du médecin ?
Les usages de diagnostic autonome sont fortement encadrés et classés à haut risque. Les usages réellement matures aujourd'hui sont l'assistance administrative et documentaire : synthèse de dossiers, comptes rendus, codage, recherche de protocoles. Dans tous ces cas, un professionnel reste dans la boucle de décision. L'IA accélère et fiabilise le travail, elle ne se substitue pas au jugement médical.
Comment garantir que les données ne quittent pas l'établissement ?
En combinant une architecture RAG, qui garde la base de connaissances chez vous, une pseudonymisation automatisée en amont du modèle, et un hébergement maîtrisé du modèle générateur, on-premise ou dans un cloud certifié HDS. Ainsi seuls des extraits pseudonymisés sont traités, et rien d'identifiant ne sort du périmètre de confiance. Cette approche rend la conformité démontrable plutôt que déclarative.