Vous construisez l’application qui va centraliser les flux et connecter l’existant. Sauf que cette application manipule des données de santé, et les règles du jeu ne sont pas les mêmes. Le RGPD (Règlement Général sur la Protection des Données) impose un régime renforcé : hébergement certifié HDS (Hébergement de Données de Santé), privacy by design, pseudonymisation, journalisation des accès, chaîne contractuelle DPA (Data Processing Agreement). Ce guide traduit ces obligations en actions techniques concrètes.
Dernière mise à jour : avril 2026
Données de santé : quelle définition exacte pour un développeur ?
Les données de santé couvrent toute information relative à la santé physique ou mentale d’une personne, passée, présente ou future.
Le RGPD (article 4.15) et la CNIL (Commission Nationale de l’Informatique et des Libertés) définissent trois catégories :
- Données de santé par nature : diagnostics, résultats d’examens, prescriptions, antécédents médicaux, données génétiques, données biométriques utilisées à des fins médicales
- Données qui deviennent des données de santé par croisement : le nombre de pas quotidien seul n’est pas une donnée de santé. Croisé avec le poids et l’IMC (indice de masse corporelle) d’un patient identifié, il le devient
- Données de santé par destination : une donnée utilisée dans un contexte médical (rendez-vous chez un spécialiste, passage aux urgences)
Pour un développeur, la règle est simple : si votre application collecte, stocke ou traite une information qui, seule ou croisée, permet d’inférer l’état de santé d’une personne identifiable, c’est une donnée de santé. Et le régime de protection renforcé s’applique.
En France, l’hébergement de ces données est encadré par l’article L.1111-8 du Code de la santé publique : tout hébergeur doit être certifié HDS. Les sanctions pour non-conformité : 3 ans d’emprisonnement et 225 000 € d’amende.
Quelles obligations RGPD sont spécifiques aux données de santé ?
Le traitement de données de santé est interdit par défaut, sauf exceptions limitées listées à l’article 9.2 du RGPD.
Les exceptions qui concernent les développeurs d’applications santé :
- Consentement explicite (art. 9.2.a) : le plus courant en B2C. Le consentement doit être libre, éclairé, spécifique et documenté. Un simple bouton “J’accepte” ne suffit pas
- Médecine préventive, diagnostic, soins (art. 9.2.h) : pour les professionnels de santé soumis au secret médical. Base légale la plus solide en contexte hospitalier
- Intérêt public en santé publique (art. 9.2.i) : recherche, pharmacovigilance, registres
Au-delà de la base légale, quatre obligations techniques s’ajoutent :
| Obligation | Ce que ça implique pour le dev | Référence |
|---|---|---|
| AIPD (Analyse d’Impact sur la Protection des Données) | Obligatoire avant mise en production si traitement à grande échelle de données de santé | CNIL, guide AIPD |
| DPA (accord de sous-traitance) | Contrat obligatoire entre responsable de traitement, prestataire et hébergeur | RGPD art. 28 |
| Registre des traitements | Documenter chaque traitement : finalité, catégories de données, durées de conservation, destinataires | RGPD art. 30 |
| Notification de violation | 72h pour notifier la CNIL en cas de fuite. Notification aux personnes concernées si risque élevé | RGPD art. 33-34 |
Privacy by design : comment l’appliquer concrètement dans le code ?
Le privacy by design signifie intégrer la protection des données personnelles dès la conception technique, pas après coup.
Le RGPD (article 25) impose la “protection des données dès la conception et par défaut”. Voici ce que ça signifie en pratique pour un développeur :
Minimisation des données : ne collecter que ce qui est strictement nécessaire à la finalité. Pas de champs “au cas où”. Si l’application n’a pas besoin de la date de naissance complète, stocker uniquement l’année.
Pseudonymisation : séparer les données identifiantes des données de santé. Stocker les identifiants patients dans une table séparée avec un UUID non prédictible. Ne jamais utiliser le NIR (numéro de sécurité sociale) comme clé primaire.
Chiffrement : AES-256 (standard de chiffrement symétrique) au repos pour les bases de données et le stockage objet. TLS (Transport Layer Security) 1.2+ en transit. Gestion des clés documentée avec rotation planifiée. Voir notre guide HDS détaillé pour les responsabilités partagées.
Journalisation des accès : chaque accès à une donnée de santé doit être tracé (qui, quand, quelle donnée, quelle action). Conservation recommandée : 6 mois minimum, 1 an en contexte hospitalier. Les logs doivent être non modifiables.
Contrôle d’accès granulaire : RBAC (Role-Based Access Control) ou ABAC (Attribute-Based Access Control). Un développeur ne doit pas accéder aux données de production. Un médecin ne doit voir que les données de ses patients.
Durées de conservation : définir et implémenter des mécanismes d’archivage et de suppression automatique. Le dossier médical se conserve 20 ans après le dernier passage (art. R.1112-7 du CSP (Code de la santé publique)). Les données de recherche : selon le protocole.
Consentement, pseudonymisation, registre : implémentation pratique
Le consentement RGPD santé doit être granulaire, révocable et documenté avec preuve horodatée. Un consentement global n’est pas valide.
Consentement : implémenter un mécanisme de consentement par finalité (pas un consentement global). Stocker la preuve : date, version du texte accepté, moyen de recueil. Prévoir un mécanisme de retrait aussi simple que le recueil. En contexte de soins, le consentement n’est pas toujours la base légale pertinente (préférer art. 9.2.h).
Pseudonymisation en pratique :
- Générer un UUID (identifiant unique universel) v4 pour chaque patient côté serveur
- Stocker le mapping identité/UUID dans une table séparée, chiffrée, à accès restreint
- Les tables de données cliniques ne référencent que l’UUID
- En cas de fuite de la base clinique, les données sont inexploitables sans la table de mapping
Registre des traitements : la CNIL fournit un modèle. Pour chaque traitement, documenter : la finalité, les catégories de données, les destinataires, les durées de conservation, les mesures de sécurité. Mettre à jour à chaque évolution fonctionnelle.
Comment HDS et RGPD s’articulent-ils ?
Le HDS est une obligation française complémentaire au RGPD, spécifique à l’hébergement de données de santé à caractère personnel.
Le RGPD fixe le cadre général (droits des personnes, obligations du responsable de traitement, sanctions). Le HDS ajoute une couche spécifique : tout hébergeur de données de santé en France doit être certifié selon le référentiel ANS.
Les deux cadres se complètent :
| Dimension | RGPD | HDS |
|---|---|---|
| Scope | Toutes données personnelles, tous secteurs | Données de santé à caractère personnel uniquement |
| Obligations techniques | Privacy by design, chiffrement, journalisation | Certification hébergeur (ISO 27001 + exigences HDS) |
| Responsabilité | Responsable de traitement + sous-traitant | Hébergeur certifié + chaîne contractuelle |
| Sanctions | Jusqu’à 4 % du CA mondial (CNIL) | 3 ans de prison + 225 000 € (Code de la santé publique) |
| Échéance | En vigueur depuis 2018 | HDS v2.0 au 16 mai 2026 (alignement ISO 27001:2022) |
En pratique, être hébergé en HDS ne rend pas automatiquement conforme au RGPD. L’hébergeur couvre l’infrastructure. Le chiffrement applicatif, la gestion des accès, les sauvegardes et le registre des traitements restent sous la responsabilité de l’équipe de développement et du responsable de traitement.
Quelles erreurs coûtent le plus cher ? (cas CNIL)
Les sanctions CNIL sur les données de santé ciblent les défauts de base légale, les failles de sécurité et l’absence de traçabilité des accès.
La CNIL a prononcé 87 sanctions en 2024 pour un total de 55,2 millions d’euros tous secteurs confondus. Les données de santé sont un axe de contrôle prioritaire. Cas récents :
- Cegedim Santé, 800 000 € (septembre 2024) : traitement de données de santé non anonymisées sans autorisation CNIL. Les données étaient pseudonymisées mais pas anonymisées, et transmises à des tiers sans base légale (décision CNIL)
- Doctissimo, 380 000 € (mai 2023) : collecte de données de santé via des questionnaires en ligne sans consentement valide, durées de conservation excessives, transferts hors UE non encadrés (décision CNIL)
Les erreurs les plus fréquentes côté développement :
- Pseudonymisation confondue avec anonymisation : la pseudonymisation est réversible (les données restent personnelles). L’anonymisation est irréversible (les données sortent du RGPD). La distinction change la base légale
- Consentement global au lieu de granulaire : un seul bouton “J’accepte tout” n’est pas un consentement valide au sens du RGPD
- Logs d’accès absents ou incomplets : en cas de contrôle, l’absence de traçabilité est un facteur aggravant
- DPA manquant dans la chaîne : si un maillon (hébergeur, prestataire, sous-traitant) n’est pas couvert par un DPA (Data Processing Agreement), le responsable de traitement est exposé
Vous n’êtes pas sûr de votre conformité ? Notre diagnostic de maturité évalue la chaîne contractuelle, la traçabilité des accès et la conformité HDS/RGPD en 3-4 semaines. Parlons-en.
Questions fréquentes
Les données anonymisées sont-elles soumises au RGPD ?
Non. Les données véritablement anonymisées (impossibilité irréversible de ré-identification) sortent du champ du RGPD. Mais la CNIL est très stricte sur ce qu’elle considère comme anonyme. Si un croisement de données permet de ré-identifier une personne, les données sont pseudonymisées, pas anonymisées, et le RGPD s’applique.
Faut-il une AIPD (Analyse d’Impact) pour toute application santé ?
Une AIPD est obligatoire quand le traitement est susceptible d’engendrer un risque élevé pour les droits des personnes. Le traitement à grande échelle de données de santé figure explicitement dans la liste CNIL des traitements nécessitant une AIPD. En pratique, toute application santé en production qui traite des données de patients identifiables doit faire l’objet d’une AIPD.
Peut-on utiliser un hébergeur cloud non certifié HDS pour le développement ?
Les environnements de développement et de test peuvent utiliser des données synthétiques ou anonymisées sur un hébergeur non certifié HDS. Dès que des données de santé réelles (même pseudonymisées) sont manipulées, l’hébergement HDS est obligatoire. Cela inclut les environnements de staging avec des copies de production.
Comment gérer le droit à l’effacement sur des données de santé ?
Le droit à l’effacement (RGPD art. 17) s’applique, mais avec des exceptions. Les données nécessaires à la prise en charge médicale ou à l’intérêt public en santé peuvent être conservées. Le dossier médical a une durée de conservation légale de 20 ans. En pratique, implémenter un mécanisme de suppression logique (soft delete) avec anonymisation irréversible plutôt qu’une suppression physique.
Un diagnostic de maturité couvre-t-il la conformité RGPD ?
Un bon diagnostic de maturité SI santé inclut un axe conformité qui évalue la chaîne contractuelle DPA, la gestion du consentement, la traçabilité des accès et la conformité HDS. Le plan d’action identifie les écarts et les actions correctives prioritaires. C’est le cas de notre diagnostic.
Prochain pas
Vous construisez une application qui manipule des données de santé et vous voulez vérifier que le socle tient ? Notre diagnostic couvre la conformité RGPD, HDS et interopérabilité en 3-4 semaines (10 000 € HT). Réservez un call de 30 minutes.
Article rédigé par Léo Gérard, Infra & Sécurité chez Yes We Dev (agence HealthTech, Bretagne).