RGPD et données de santé : guide complet pour les éditeurs de logiciels (2026)
10/05/2026
Le RGPD appliqué aux données de santé est l'un des sujets sur lesquels les éditeurs e-santé se brûlent le plus en démarrage de projet. Pas parce que la réglementation est obscure — elle est plutôt bien documentée — mais parce qu'elle implique une discipline opérationnelle continue : AIPD à chaque évolution majeure, registre de traitement à jour, contrats sous-traitants signés, procédures d'exercice des droits, plan de réponse aux violations. Beaucoup d'équipes traitent le RGPD comme une formalité initiale et se retrouvent en panique au premier audit ou contrôle CNIL.
Chez Bob le développeur, on accompagne les éditeurs e-santé sur ces sujets depuis 2017 — startups MVP, scale-ups en levée, projets institutionnels avec l'AP-HP. Cet article rassemble la vue opérationnelle du RGPD côté éditeur : ce qu'il faut absolument avoir en place, comment se structurer, et où sont les pièges qui finissent en sanction.
L'essentiel en 30 secondes :
- Toute donnée traitée dans une app e-santé est une donnée de santé au sens art. 9 RGPD.
- La base légale principale pour les éditeurs côté soin est l'art. 9.2.h (médecine, soins, gestion des systèmes de santé). Le consentement art. 9.2.a est plus rare en pratique.
- L'AIPD est obligatoire pour tout traitement à risque élevé — ce qui couvre quasiment toute app e-santé.
- Les contrats sous-traitants (art. 28) doivent être en place avec tous les services tiers (hébergeur HDS, opérateur MSSanté, prestataire SMS, outil analytics).
- Les sanctions CNIL en santé sont régulièrement >100 000 € — la conformité n'est pas un coût, c'est une assurance.
Qu'est-ce qu'une donnée de santé au sens RGPD
L'article 4.15 du RGPD définit les données concernant la santé comme "les données à caractère personnel relatives à la santé physique ou mentale d'une personne physique, y compris la prestation de services de soins de santé, qui révèlent des informations sur l'état de santé de cette personne".
La CNIL en a précisé trois catégories en pratique :
1. Données de santé par nature. Diagnostic, prescription, résultat d'analyse, image médicale, mesure physiologique. Pas d'ambiguïté possible.
2. Données qui le deviennent par croisement. Une prise de poids combinée à une grossesse devient une donnée de santé. Une géolocalisation dans un service de psychiatrie devient une donnée de santé.
3. Données qui le deviennent par finalité. Si vous utilisez une donnée pour rendre un service de santé, cette donnée devient une donnée de santé même si elle ne l'est pas intrinsèquement.
L'enjeu pour un éditeur, c'est qu'il faut considérer que toute donnée traitée dans le contexte d'une application de santé est une donnée de santé. Ne jouez pas à classer finement : appliquez le régime le plus protecteur par défaut. Notre guide définition et cadre juridique des données de santé approfondit le sujet.
Choisir la bonne base légale
Le RGPD interdit le traitement des données de santé par défaut (art. 9.1). Pour traiter, il faut une base légale parmi celles listées à l'art. 9.2. Dans la pratique d'un éditeur e-santé, cinq bases reviennent.
Art. 9.2.h — médecine, soins, gestion des systèmes de santé
C'est la base légale principale pour la plupart des cas d'usage métier : DPI, plateforme de télémédecine, outil de coordination, application de suivi patient utilisée par des soignants. Elle s'applique quand le traitement est nécessaire à des fins de médecine préventive, de diagnostics médicaux, d'administration de soins ou de gestion des systèmes de santé.
Elle suppose deux conditions : la finalité doit être effectivement médicale (pas marketing déguisé), et le traitement doit être effectué par un professionnel soumis au secret médical ou sous sa responsabilité.
C'est la base la plus solide pour une app patient utilisée dans un parcours de soins, parce qu'elle ne dépend pas du consentement et résiste mieux à un retrait par l'utilisateur.
Art. 9.2.a — consentement explicite
Le consentement est plutôt utilisé pour les apps grand public sans encadrement médical (apps de wellness, suivi sport, applications de bien-être psychologique sans psychologue derrière). Il doit être explicite (pas opt-out), libre, éclairé et révocable.
Le piège du consentement : si l'utilisateur le retire, vous devez stopper le traitement. Pour un service de soin où l'utilisateur dépend de la donnée, c'est problématique. Privilégier 9.2.h chaque fois que c'est défendable.
Art. 9.2.c — sauvegarde des intérêts vitaux
Pour les cas d'urgence où la personne ne peut pas consentir (perte de connaissance, urgence vitale). Utilisée en pratique pour les applications d'urgence et certaines briques d'identitovigilance.
Art. 9.2.i — santé publique
Pour les outils de surveillance épidémiologique, signalement sanitaire, vigilance. Utilisée par des éditeurs qui travaillent avec Santé publique France ou les CRSA.
Art. 9.2.j — recherche scientifique
Pour les traitements à finalité de recherche. Encadrée par la loi française qui ajoute des obligations supplémentaires (autorisation CNIL ou méthodologie de référence).
Combiner plusieurs bases
Beaucoup de plateformes e-santé combinent plusieurs bases selon les modules : 9.2.h pour le cœur soin, 9.2.a pour des fonctionnalités optionnelles (programme de bien-être, partage social), 9.2.j si vous proposez de la recherche secondaire. Le registre de traitement doit refléter cette structure module par module.
L'AIPD : non négociable, à itérer
L'analyse d'impact sur la protection des données (AIPD ou DPIA) est obligatoire pour tout traitement à risque élevé pour les droits et libertés. La CNIL a publié une liste type qui inclut explicitement les traitements de données de santé à grande échelle.
En pratique, l'AIPD est obligatoire pour quasiment toute app e-santé. Sauf cas marginaux (outil interne mono-utilisateur sans données réelles), partez du principe que vous devez en faire une.
L'AIPD couvre cinq parties :
- Description du traitement : finalité, base légale, données traitées, destinataires, durées de conservation.
- Nécessité et proportionnalité : le traitement est-il indispensable à la finalité ? Pas de surcollecte ?
- Mesures de gestion des risques : techniques (chiffrement, audit, accès) et organisationnelles (formation, procédures).
- Évaluation des risques résiduels : accès illégitime, modification non désirée, disparition de données. Cotation par probabilité et gravité.
- Validation et suivi : avis du DPO, consultation CNIL si nécessaire, plan d'action.
Outils pratiques : la CNIL propose un outil PIA gratuit et téléchargeable. C'est largement suffisant pour démarrer. À itérer à chaque évolution structurante du produit (nouvelle intégration, nouveau profil d'utilisateur, nouveau type de donnée traité).
Registre des activités de traitement
Le registre (art. 30 RGPD) est l'inventaire de tous vos traitements. Il doit lister, pour chaque traitement :
- Identité du responsable et du DPO.
- Finalité.
- Catégories de personnes concernées.
- Catégories de données.
- Catégories de destinataires (y compris hors UE).
- Transferts hors UE le cas échéant.
- Durées de conservation par catégorie.
- Description générale des mesures de sécurité.
En tant qu'éditeur, vous tenez deux registres distincts :
- Votre registre responsable de traitement pour les données que vous traitez pour vous (employés, prospects, comptabilité).
- Le registre des traitements en tant que sous-traitant pour les données que vous traitez pour le compte de vos clients hospitaliers ou médicaux.
Les deux doivent être maintenus séparément et fournis sur demande à la CNIL.
Contrats sous-traitants (art. 28)
Toute entité qui traite des données pour votre compte est un sous-traitant au sens RGPD. Ça couvre :
- Votre hébergeur HDS (OVHcloud, AWS, Scaleway, Azure).
- Votre opérateur MSSanté Citoyen ou pro.
- Vos prestataires SMS, email transactionnel.
- Vos outils analytics qui voient passer des données identifiantes.
- Vos prestataires de monitoring si vous y envoyez des logs avec PHI (à éviter).
- Votre prestataire de support s'il a accès aux dossiers patients.
Chaque sous-traitant doit être lié par un contrat conforme à l'art. 28. En pratique, les gros prestataires fournissent un DPA (Data Processing Agreement) standard. Pour les plus petits, vous devrez parfois pousser la signature d'un DPA. Tant qu'un DPA n'est pas signé, vous êtes en non-conformité formelle.
Spécificité HDS : votre hébergeur doit fournir, en plus du DPA, son certificat HDS et son convention HDS — exigible côté hôpital client.
Information des personnes et exercice des droits
Le RGPD impose une information transparente et facile à comprendre des personnes concernées.
Information préalable (art. 13/14)
À fournir au moment de la collecte :
- Identité et coordonnées du responsable + DPO.
- Finalités, base légale.
- Destinataires.
- Durées de conservation.
- Droits (accès, rectification, effacement, portabilité, opposition, limitation).
- Droit de réclamation auprès de la CNIL.
- Existence éventuelle de décisions automatisées (rare en e-santé).
À matérialiser dans une politique de confidentialité claire, accessible depuis l'app, et dans des mentions courtes au moment de la collecte.
Exercice des droits
Les six droits applicables aux données de santé :
| Droit | Spécificité santé |
|---|---|
| Accès | Délai 1 mois (3 mois max si complexe). Doit fournir les données et les métadonnées (finalités, destinataires...) |
| Rectification | Sous réserve qu'elle ne dénature pas la donnée médicale (un diagnostic erroné se rectifie via le médecin, pas via l'utilisateur) |
| Effacement | Limité par la conservation médicale obligatoire (20 ans après la fin de prise en charge en hôpital) |
| Portabilité | Format structuré et lisible par machine. Volet de santé via le DMP/MES facilite l'exercice |
| Opposition | Sur les bases légales 9.2.a (consentement) ; plus limité sur 9.2.h |
| Limitation | Marquage technique, pas suppression |
Process indispensable : un endpoint et une procédure documentée pour traiter une demande d'exercice de droit en moins d'un mois. Sans ça, la première demande arrive et personne ne sait quoi faire.
Conservation et archivage
Trois durées de conservation à distinguer :
- Durée d'usage actif : pendant que la relation contractuelle ou le soin est en cours.
- Durée d'archivage intermédiaire : pour les besoins légaux (obligations comptables, recouvrement de créances, contentieux possibles).
- Durée d'archivage médical : 20 ans après la fin du séjour hospitalier ou 10 ans après le décès en pratique générale, mais avec des spécificités selon le type de soin.
Les données archivées ne sont plus en accès libre : elles passent dans un système d'archivage à accès restreint, idéalement chiffré avec rotation de clé. Les requêtes d'accès aux archives doivent être tracées.
Violation de données : 72 heures pour notifier
L'article 33 du RGPD impose la notification d'une violation à la CNIL dans les 72 heures. L'article 34 impose, dans certains cas, l'information directe des personnes concernées.
Le plan de réponse à un incident de sécurité doit prévoir :
- Détection et qualification : est-ce une violation au sens RGPD ?
- Évaluation des conséquences : nombre de personnes concernées, gravité, données impactées.
- Décision de notification : CNIL toujours, personnes concernées si risque élevé.
- Préparation du dossier CNIL : description, conséquences, mesures prises et prévues.
- Communication : équipe, clients, et le cas échéant utilisateurs finaux.
Préparez un template de notification CNIL et un template de communication client en avance. Le jour de l'incident, vous n'aurez pas le temps d'écrire à froid.
Le DPO en e-santé : obligatoire, et utile
Pour un éditeur e-santé, la désignation d'un DPO est obligatoire dès lors que vous traitez des données de santé à grande échelle (cas quasi systématique). Trois options :
- DPO interne : un employé désigné, formé, avec une mission clairement définie et un budget.
- DPO externe : un cabinet ou consultant qui assure la fonction. Économique pour les TPE/PME, plus de neutralité.
- DPO mutualisé : entre éditeurs partenaires, coopératives, écosystèmes.
Quel que soit le choix, le DPO doit être déclaré à la CNIL, indépendant, et associé en amont aux décisions impactant les données personnelles.
Sanctions CNIL en santé : ordre de grandeur
Pour calibrer l'enjeu, quelques sanctions récentes en e-santé :
- Dedalus Biologie (2022) : 1,5 million d'euros pour fuite de données de 500 000 patients.
- Doctolib (avertissement) : pour insuffisances dans l'information des utilisateurs.
- Plusieurs hôpitaux : 50 000 € à 200 000 € pour défaut de sécurité (mots de passe non hachés, accès trop larges).
Les sanctions financières directes ne sont pas le principal risque. La sanction de réputation et la perte de clients hospitaliers le sont. Une publication CNIL sur un éditeur en non-conformité plombe immédiatement la pipeline commerciale.
Pièges et retours terrain
Erreurs fréquentes chez les éditeurs e-santé :
Confondre RGPD et HDS. Ce sont deux régimes complémentaires mais distincts. Le HDS impose un référentiel de sécurité spécifique aux données de santé. Le RGPD impose un cadre général applicable à toutes les données personnelles. Vous devez respecter les deux.
Sous-estimer les transferts hors UE. Si vous utilisez un outil hébergé hors UE (Slack, Notion, Linear, Google Workspace), vous transférez potentiellement des données personnelles hors UE — y compris si ces données ne sont que des emails de prospects. Les clauses contractuelles types (CCT) ou un mécanisme équivalent doivent être en place.
Ne pas tenir le registre à jour. Le registre est un document vivant. Beaucoup d'éditeurs le créent au démarrage et oublient de le mettre à jour. Un registre vieux de 2 ans est presque pire que pas de registre.
Confondre anonymisation et pseudonymisation. L'anonymisation est irréversible (donnée non rattachable à une personne) — sortie du champ RGPD. La pseudonymisation est réversible (un identifiant remplace les traits) — toujours dans le champ RGPD. Beaucoup d'équipes appellent "anonymisation" ce qui est en réalité une pseudonymisation.
Demander un consentement systématique pour des traitements 9.2.h. Erreur classique : montrer une bannière de consentement à un utilisateur dont le traitement repose sur 9.2.h. Cela laisse penser que l'utilisateur peut refuser, ce qui est faux et juridiquement fragilisant.
Pas de procédure d'exercice des droits. "Pour exercer vos droits, contactez dpo@..." sans procédure documentée derrière, c'est de la conformité de façade. Première demande, panique.
Mélanger production et data analytics. Les données identifiantes en clair dans un outil BI consulté par 20 personnes : faille majeure. Pseudonymiser ou tokeniser avant tout usage analytique.
FAQ — RGPD et données de santé pour éditeurs
Faut-il déclarer son traitement à la CNIL ? Non, plus depuis le RGPD. Vous tenez un registre interne et faites une AIPD si nécessaire. Vous notifiez seulement les violations et certains traitements particuliers (recherche, fichiers de population vulnérable).
Que faire si un client hospitalier nous demande des engagements RGPD spécifiques ? C'est normal et systématique. Préparez un kit complet : DPA, certificat HDS de votre hébergeur, registre des sous-traitants, AIPD synthétique, plan de réponse aux incidents. Cela accélère les négociations.
Peut-on utiliser des outils US (Slack, Notion, Mixpanel) ? Oui pour des données non sensibles (prospects, support classique). Non pour des données de santé identifiantes. Et toujours avec un cadre de transfert hors UE (CCT, certifications type DPF si remis en place).
Les données chiffrées sont-elles soumises au RGPD ? Oui. Le chiffrement réduit le risque mais ne fait pas sortir la donnée du champ RGPD. Le seul mécanisme qui en fait sortir est l'anonymisation irréversible.
Peut-on faire du tracking marketing sur une app e-santé ? Avec beaucoup de précautions. Les outils standards (Google Analytics, Hotjar) ne sont pas adaptés aux données de santé. Privilégier des solutions hébergées HDS ou self-hosted (Matomo, Plausible).
Peut-on entraîner un modèle d'IA sur des données de santé ? Oui sous conditions strictes : base légale claire (souvent 9.2.j recherche, ou 9.2.h si finalité de soin), pseudonymisation forte, AIPD spécifique, garanties techniques. Pour entraîner sur des LLM externes (OpenAI), accord HDS spécifique requis.
Combien de temps faut-il pour mettre en conformité un projet existant ? Pour un MVP qui démarre en non-conformité : 4 à 8 semaines pour atteindre une conformité acceptable (registre, AIPD, DPA, info utilisateurs). Pour un produit en exploitation depuis 2 ans sans rien : 3 à 6 mois.
Doit-on faire un audit RGPD externe ? Pas obligatoire, fortement recommandé. Un audit externe annuel est demandé par la plupart des clients hospitaliers. Coûte entre 5 000 et 20 000 € selon le périmètre.
Aller plus loin
Le RGPD en e-santé n'est pas un obstacle insurmontable. C'est une discipline opérationnelle qui s'installe sur 4-8 semaines d'investissement initial puis se maintient avec un rythme régulier (revue trimestrielle du registre, AIPD à chaque évolution majeure, audit annuel). Les éditeurs qui réussissent traitent ce sujet comme une fondation produit, pas comme un coût juridique.
Si vous portez un projet e-santé et que vous voulez sécuriser votre conformité RGPD avant un audit ou une certification, parlons de votre projet. On peut auditer votre conformité actuelle, structurer votre registre et vos AIPD, ou intervenir comme partenaire technique CTO-as-a-Service pour intégrer ces sujets dès la conception.