Application santé et RGPD : les contraintes techniques à anticiper

Développer une application qui traite des données de santé n'est pas un projet de développement comme les autres. Le cadre réglementaire impose des contraintes techniques spécifiques qui impactent l'architecture, l'hébergement, le budget et le calendrier du projet. Les ignorer expose l'entreprise à des sanctions CNIL pouvant atteindre 20 millions d'euros ou 4 % du CA mondial. Cet article détaille chaque contrainte et son implémentation technique concrète.

#Article 9 RGPD : pourquoi les données de santé sont un cas à part

L'article 9 du RGPD classe les données de santé parmi les données sensibles, au même titre que les données biométriques, génétiques, d'orientation sexuelle ou d'opinions politiques. Le principe est l'interdiction de traitement, sauf dans des cas limitativement énumérés.

Les données de santé au sens du RGPD couvrent un périmètre large : les données relatives à la santé physique ou mentale d'une personne (diagnostic, antécédents, traitements), les données de consultations et prescriptions, les données biométriques utilisées à des fins de santé (rythme cardiaque, tension, IMC), les données génétiques, et même les données de bien-être qui, croisées, révèlent un état de santé (historique d'activité physique + alimentation + sommeil).

Les exceptions qui autorisent le traitement des données de santé dans le cadre d'une application sont le consentement explicite de la personne (article 9.2.a), la médecine préventive ou professionnelle (article 9.2.h), l'intérêt vital de la personne (article 9.2.c), et la recherche scientifique ou statistique dans l'intérêt public (article 9.2.j). Chaque exception impose des garanties techniques proportionnées. Le consentement explicite, par exemple, doit être recueilli de façon granulaire (consentement par finalité de traitement), documenté (preuve de consentement horodatée) et révocable (mécanisme de retrait du consentement accessible dans l'application).

#Hébergement HDS : obligation, certification et choix d'hébergeur

Depuis la loi du 26 janvier 2016 de modernisation du système de santé (article L1111-8 du Code de la santé publique), tout hébergement de données de santé à caractère personnel doit être réalisé par un hébergeur certifié HDS. Cette obligation s'applique aux éditeurs de logiciels, aux plateformes de télémédecine, aux applications de suivi patient, aux objets connectés santé, et à tout acteur qui stocke ou traite des données de santé pour le compte d'un tiers.

#Les 6 activités de la certification HDS

La certification HDS couvre 6 activités distinctes. Un hébergeur peut être certifié pour une ou plusieurs de ces activités.

Activité 1 : mise à disposition de locaux d'hébergement physique. Activité 2 : mise à disposition d'infrastructure matérielle. Activité 3 : mise à disposition de plateforme d'hébergement d'infrastructure virtuelle. Activité 4 : mise à disposition de plateforme logicielle applicative. Activité 5 : administration et exploitation du système d'information contenant les données de santé. Activité 6 : sauvegarde externalisée des données de santé.

Pour une application web classique hébergée sur un cloud IaaS, l'hébergeur doit être certifié au minimum pour les activités 1 à 3. Si l'hébergeur fournit également la couche applicative (PaaS), les activités 4 et 5 sont nécessaires.

#Hébergeurs certifiés HDS en France

Les principaux hébergeurs certifiés HDS en France sont OVHcloud (certifié activités 1 à 6, datacenters Gravelines, Roubaix, Strasbourg), Scaleway (certifié activités 1 à 6, datacenters Paris), Outscale (Dassault Systèmes, certifié activités 1 à 5, certifié SecNumCloud en plus), Azure France (Microsoft, certifié activités 1 à 6, datacenters Paris et Marseille) et AWS France (Amazon, certifié activités 1 à 6, datacenter Paris).

Chez Nehos, nous recommandons OVHcloud ou Scaleway pour les projets qui exigent à la fois la certification HDS et la souveraineté des données (pas de cloud act américain). Pour les projets nécessitant SecNumCloud en plus de HDS (données de santé de niveau supérieur), Outscale est le choix de référence.

#Surcoût de l'hébergement HDS

L'hébergement HDS est plus cher qu'un hébergement standard. Le surcoût vient de la certification elle-même (l'hébergeur répercute les coûts d'audit et de conformité), des mesures de sécurité renforcées (chiffrement, monitoring, sauvegarde redondante) et de la localisation française obligatoire (qui limite la concurrence).

En pratique, le surcoût se situe entre 30 et 80 % par rapport à un hébergement standard équivalent. Pour une application web de taille moyenne, cela représente 200 à 500 euros par mois supplémentaires. Ce surcoût est incompressible et doit être intégré au budget prévisionnel du projet.

#Le référentiel CNIL santé : les bonnes pratiques opposables

La CNIL a publié un référentiel spécifique pour les traitements de données de santé qui fait office de doctrine technique. Ce référentiel précise les mesures techniques et organisationnelles attendues.

Parmi les mesures techniques, on retrouve le chiffrement des données au repos avec un algorithme AES-256 minimum, le chiffrement des données en transit avec TLS 1.3 (TLS 1.2 toléré avec les suites cryptographiques recommandées), la pseudonymisation des données dans tous les traitements qui ne nécessitent pas l'identification directe du patient, la journalisation des accès aux données de santé (qui, quand, quoi, depuis où), la gestion des habilitations (principe du moindre privilège), et la réalisation d'une PIA (Privacy Impact Assessment / Analyse d'Impact sur la Protection des Données) obligatoire pour tout traitement de données de santé à grande échelle.

Parmi les mesures organisationnelles, on retrouve la nomination d'un DPO (Data Protection Officer), la tenue d'un registre des traitements (article 30 RGPD), la mise en place de procédures de notification de violations de données (72 heures maximum après constatation), et la formation des équipes aux enjeux de protection des données de santé.

#Architecture technique type : les couches de sécurité

Une application santé conforme doit implémenter une architecture en couches de sécurité. Voici l'architecture type que nous déployons chez Nehos.

#Couche 1 : chiffrement bout en bout

Toutes les données de santé sont chiffrées au repos dans la base de données (PostgreSQL avec pgcrypto ou chiffrement applicatif via Symfony). Les fichiers médicaux (ordonnances, résultats d'examens, imagerie) sont chiffrés dans le stockage objet (S3 compatible avec server-side encryption). Les communications entre le client (navigateur, app mobile) et le serveur utilisent TLS 1.3 avec des certificats Let's Encrypt ou DigiCert.

Le chiffrement applicatif (en plus du chiffrement au repos de l'hébergeur) est recommandé pour les données les plus sensibles. Il garantit que même un accès non autorisé à la base de données ne permet pas de lire les données en clair. Chez Nehos, nous utilisons une bibliothèque de chiffrement symétrique (libsodium via paragonie/halite en PHP) avec rotation des clés tous les 90 jours.

#Couche 2 : pseudonymisation

La pseudonymisation consiste à remplacer les identifiants directs (nom, prénom, numéro de sécurité sociale) par des pseudonymes (identifiants internes non signifiants) dans tous les traitements qui ne nécessitent pas l'identification directe. Concrètement, les logs applicatifs contiennent des identifiants pseudonymisés, jamais des noms de patients. Les environnements de développement et de test utilisent des données pseudonymisées (ou synthétiques). Les exports statistiques et les rapports sont pseudonymisés par défaut.

La pseudonymisation n'est pas l'anonymisation. Les données pseudonymisées restent des données personnelles au sens du RGPD (car la correspondance pseudonyme-identité existe). L'anonymisation irréversible supprime cette correspondance et sort les données du champ du RGPD — mais elle est rarement applicable dans un contexte de suivi médical.

#Couche 3 : audit trail (journalisation)

L'audit trail est un journal immuable qui enregistre chaque accès aux données de santé. Pour chaque accès, il enregistre l'identifiant de l'utilisateur, la date et l'heure, l'action réalisée (lecture, écriture, suppression), les données concernées (identifiant du dossier patient), et l'adresse IP et le user-agent.

L'audit trail doit être stocké séparément des données applicatives (base de données dédiée ou service de logging externe comme Elasticsearch) pour éviter qu'une compromission de l'application ne permette de modifier les logs. La rétention des logs d'accès aux données de santé est typiquement de 5 ans (alignée sur la durée de conservation des dossiers médicaux).

Chez Nehos, nous utilisons un middleware Symfony dédié qui intercepte automatiquement tous les accès aux entités Doctrine marquées comme « données de santé ». Le développeur n'a pas à penser à la journalisation : elle est automatique et exhaustive.

#Couche 4 : gestion des consentements

L'application doit intégrer un module de gestion des consentements qui permet de recueillir le consentement explicite du patient pour chaque finalité de traitement, d'horodater et d'archiver la preuve de consentement, de permettre au patient de retirer son consentement à tout moment, et de bloquer automatiquement les traitements pour lesquels le consentement a été retiré.

Le consentement doit être granulaire : un patient peut consentir au suivi médical mais refuser l'utilisation de ses données à des fins de recherche. L'application doit respecter ces choix de façon technique, pas seulement déclarative.

#Couche 5 : portabilité et droit à l'effacement

Le patient a le droit de récupérer ses données dans un format structuré et lisible par machine (droit à la portabilité, article 20 RGPD) et de demander la suppression de ses données (droit à l'effacement, article 17 RGPD). L'application doit fournir un mécanisme d'export des données du patient en format standardisé (JSON, CSV ou FHIR pour les données médicales interopérables) et un mécanisme de suppression complète (données, fichiers, logs nominatifs, sauvegardes). Le droit à l'effacement peut être limité par des obligations légales de conservation (durée de conservation des dossiers médicaux : 20 ans après la dernière consultation pour les médecins).

#PIA : l'analyse d'impact obligatoire

Toute application santé qui traite des données de santé à grande échelle doit faire l'objet d'une PIA (Privacy Impact Assessment / Analyse d'Impact relative à la Protection des Données) avant la mise en production. La PIA est un document structuré qui décrit les traitements envisagés et leurs finalités, évalue la nécessité et la proportionnalité des traitements, identifie les risques pour les droits et libertés des personnes, et décrit les mesures prises pour atténuer ces risques.

La PIA n'est pas un exercice théorique. C'est un document opposable que la CNIL peut demander à tout moment. Il doit être tenu à jour à chaque évolution significative de l'application. Chez Nehos, nous réalisons la PIA en collaboration avec le DPO du client (ou un DPO externalisé que nous recommandons). Le travail technique de la PIA représente 3 à 5 jours, en parallèle du développement.

#Budget réel : le surcoût HDS et conformité RGPD santé

Le surcoût de conformité RGPD santé se décompose comme suit.

Ce surcoût représente 10 à 20 % du budget de développement d'une application santé de taille moyenne (80 000 à 150 000 euros). Il n'est pas négociable : c'est le prix de la conformité réglementaire. Ne pas le prévoir, c'est s'exposer à une refonte coûteuse après la mise en production — ou pire, à une sanction CNIL.

#Les erreurs fréquentes à éviter

Première erreur : utiliser un hébergeur non certifié HDS « en attendant ». La CNIL ne reconnaît pas les situations transitoires. Dès que l'application traite des données de santé en production, l'hébergement HDS est obligatoire. Pas « bientôt ». Maintenant.

Deuxième erreur : confondre chiffrement de l'hébergeur et chiffrement applicatif. L'hébergeur HDS chiffre les disques au repos. Mais si l'application stocke des données en clair dans la base de données, un accès non autorisé à l'application (faille SQL injection, par exemple) expose les données. Le chiffrement applicatif ajoute une couche de protection indépendante.

Troisième erreur : utiliser les données de production dans les environnements de test. Les développeurs et testeurs ne doivent jamais accéder à des données de santé réelles. Les environnements de développement et de test doivent utiliser des données pseudonymisées ou synthétiques. C'est une exigence du référentiel CNIL.

Quatrième erreur : ne pas prévoir la PIA dès le début du projet. La PIA doit être réalisée avant la mise en production, pas après. Si la PIA révèle des risques non couverts (ce qui arrive dans 40 % des cas), il faut modifier l'architecture — ce qui est beaucoup plus coûteux après le développement qu'avant.

#Conclusion : la conformité est un investissement, pas un coût

Développer une application santé conforme au RGPD est plus complexe et plus cher qu'une application standard. Mais cette conformité est un prérequis légal non négociable et un avantage concurrentiel : les professionnels de santé et les patients font confiance aux applications qui respectent visiblement la protection de leurs données.

Chez Nehos, nous accompagnons les startups medtech, les établissements de santé et les éditeurs de logiciels dans le développement d'applications santé conformes. Notre expertise couvre l'architecture technique, l'hébergement HDS, la PIA et l'accompagnement CNIL.

Pour évaluer les contraintes techniques de votre projet santé, prenez 15 minutes avec notre CTO. Il vous donnera une vision claire des contraintes, du budget et du planning.