RGPD et données de santé : guide complet pour les éditeurs de logiciels (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 : startups MVP, scale-ups en levée, projets institutionnels avec l'AP-HP. Nos fondateurs travaillent dans la e-santé depuis 2017. 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 :

Par prudence, traitez toute donnée d'une app e-santé comme une donnée de santé au sens de l'art. 9 RGPD : la qualification s'apprécie au cas par cas, mais le régime le plus protecteur évite les erreurs de classement.

Il faut une base légale de l'art. 6 et une exception de l'art. 9.2. L'exception 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 €, et 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 deux choses : une base légale de l'art. 6 (consentement, contrat, obligation légale, intérêts vitaux, mission d'intérêt public ou intérêt légitime) et une des exceptions listées à l'art. 9.2. Les deux se justifient et se documentent. Dans la pratique d'un éditeur e-santé, cinq exceptions 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.

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 agences régionales de santé (ARS).

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 exceptions 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. Le RGPD l'impose pour le traitement à grande échelle de données de santé (art. 35.3.b). La liste publiée par la CNIL vise en plus, nommément, les traitements de données de santé des établissements de santé et médico-sociaux pour la prise en charge des personnes, et les entrepôts de données de santé.

En pratique, l'AIPD est obligatoire pour quasiment toute app e-santé. L'obligation pèse sur le responsable de traitement. Si vous êtes sous-traitant de vos clients, vous devez leur fournir votre aide et les informations nécessaires. Si vous éditez une app grand public dont vous êtes responsable, c'est à vous de la mener. Seule exception notable : la CNIL en dispense le professionnel de santé qui exerce à titre individuel pour la prise en charge de ses patients.

Le RGPD impose au moins quatre éléments (art. 35.7). En pratique, on déroule l'AIPD en cinq étapes :

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 de messagerie sécurisée MSSanté.
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 un contrat d'hébergement conforme à l'article R. 1111-11 du code de la santé publique, qui indique le périmètre du certificat. Vos clients hospitaliers vous les demanderont.

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 général d'un mois, prolongeable de deux mois si la demande est complexe. Pour le dossier médical détenu par un professionnel ou un établissement de santé : 8 jours au plus, 2 mois si les informations ont plus de cinq ans (art. L. 1111-7 du code de la santé publique). 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é, couramment utilisé et lisible par machine. Ne s'applique que si le traitement repose sur le consentement ou sur un contrat, pas pour une mission d'intérêt public
Opposition	S'exerce quand le traitement repose sur une mission d'intérêt public ou sur l'intérêt légitime (art. 6.1.e ou f). Ne joue pas pour un traitement fondé sur le consentement : la personne retire alors son consentement
Limitation	Marquage technique, pas suppression

Process indispensable : un endpoint et une procédure documentée pour traiter une demande dans les délais : un mois en règle générale, huit jours pour un accès au dossier médical. 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 en établissement de santé (art. R. 1112-7 du code de la santé publique) : 20 ans à compter du dernier séjour ou de la dernière consultation externe, prolongés jusqu'au 28e anniversaire du patient si le délai s'achève avant, et 10 ans à compter du décès si le patient décède moins de dix ans après son dernier passage.

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 au responsable de traitement de notifier une violation à la CNIL dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes. Si vous êtes sous-traitant, votre obligation est d'alerter votre client dans les meilleurs délais : c'est lui qui notifie. 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 dès qu'il existe un risque pour les personnes, personnes concernées si le risque est élevé, inscription au registre des violations dans tous les cas.
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. L'éditeur, sous-traitant de laboratoires, a été sanctionné après la fuite des données de près de 500 000 patients.
Un éditeur de logiciels de gestion pour médecins (2024) : 800 000 € pour avoir constitué un entrepôt de données de santé sans autorisation de la CNIL.
Hôpital privé de la Loire (2026) : 500 000 € pour un dossier patient informatisé insuffisamment sécurisé (accès externes sans VPN ni authentification multifacteur, habilitations trop larges). Auparavant, la CNIL avait surtout procédé par mises en demeure d'établissements.

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. Vérifiez que le fournisseur est certifié Data Privacy Framework. À défaut, des clauses contractuelles types (CCT) 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), donc sortie du champ RGPD. La pseudonymisation est réversible (un identifiant remplace les traits), donc 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 de déclaration systématique depuis le RGPD. Vous tenez un registre interne et faites une AIPD si nécessaire. Mais la loi Informatique et Libertés maintient des formalités pour certains traitements de données de santé : recherches, études et évaluations, entrepôts de données de santé, vigilances sanitaires. Dans ces cas, vous déposez une déclaration de conformité au référentiel ou à la méthodologie de référence de la CNIL, ou à défaut une demande d'autorisation. Un éditeur a été sanctionné de 800 000 € en 2024 pour un entrepôt constitué sans autorisation.

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 : la décision d'adéquation États-Unis (Data Privacy Framework, en vigueur depuis le 10 juillet 2023) si le fournisseur y est certifié, des clauses contractuelles types sinon.

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. La CNIL (fiche du 5 mars 2026) qualifie l'entraînement d'un système d'IA en santé de recherche, étude ou évaluation dans le domaine de la santé : il faut une base légale (art. 6), une exception de l'art. 9 et, dans la majorité des cas, une formalité préalable, déclaration de conformité à la MR-001, MR-003 ou MR-004 ou demande d'autorisation. Ajoutez une pseudonymisation forte et une AIPD spécifique. OpenAI ne figure pas sur la liste des hébergeurs certifiés HDS de l'ANS : vérifiez, service par service, que le modèle tourne chez un hébergeur certifié.

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.

Côté hébergement, le cadre a bougé en 2026 : référentiel HDS v2 obligatoire depuis le 16 mai et décret du 24 mars sur la localisation du stockage, dont l'obligation de stockage dans l'UE ou l'EEE et les nouvelles mentions du contrat s'appliquent depuis le 26 septembre 2026. Voir notre point complet sur le HDS en 2026.

Si vous portez un projet e-santé et que vous voulez sécuriser votre conformité RGPD avant un audit ou une certification, consultez notre offre RGPD & données de santé ou 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.

Sources

Faits relevés le 13 octobre 2026.

Règlement général sur la protection des données, texte publié par la CNIL : articles 6, 9, 20, 21, 28, 33 à 35
Formalités pour les traitements de données de santé et listes des traitements soumis ou non à une AIPD, CNIL
Répondre à une demande de droit d'accès, CNIL, et article L. 1111-7 du code de la santé publique
Violations de données personnelles : les règles à suivre, CNIL
Sanctions prononcées par la CNIL et sanction de l'Hôpital privé de la Loire
IA et santé : développer et évaluer des systèmes conformes, CNIL, 5 mars 2026
Adéquation des États-Unis, CNIL