Application mobile santé en 2026 : contraintes RGPD et HDS expliquées

Le marché de la e-santé en France pèse 3,2 milliards d'euros en 2026. Les applications mobiles santé se multiplient : suivi patient, téléconsultation, objets connectés médicaux, gestion de parcours de soins, applications de prévention. Mais développer une application qui traite des données de santé n'est pas un projet mobile comme les autres. Le cadre réglementaire français est l'un des plus stricts d'Europe, et les sanctions pour non-conformité sont lourdes. Voici le guide complet des contraintes à anticiper dès la phase de cadrage.

#Qu'est-ce qu'une donnée de santé au sens du RGPD ?

Le RGPD (article 4, paragraphe 15) définit les données de 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 ». Cette définition est large et couvre bien plus que les dossiers médicaux.

Sont des données de santé :

• Les résultats d'analyses biologiques et d'examens médicaux
• Les prescriptions et ordonnances
• Les données de capteurs de santé connectés (rythme cardiaque, tension, glycémie, oxymétrie)
• Les données de suivi de traitement (prises de médicaments, posologie)
• Les données de téléconsultation (compte-rendus, échanges médecin-patient)
• Les données de santé mentale (scores de questionnaires psychologiques, suivi thérapeutique)
• Les données génétiques et biométriques utilisées à des fins de santé
• Les informations sur le handicap, les allergies, les antécédents familiaux

Ne sont pas des données de santé (sauf croisement) :

• Les données de bien-être non médicales (nombre de pas, qualité du sommeil sans diagnostic)
• Les données nutritionnelles générales (calories consommées, sans lien avec un régime médical)
• Les données sportives (distance de course, temps de nage) sans contexte médical

Attention : le croisement de données non médicales peut créer des données de santé. Par exemple, une application de fitness qui croise le poids, la taille, l'âge et les données de sommeil peut déduire un IMC et un risque de pathologie. À partir de ce moment, les données deviennent des données de santé au sens du RGPD.

#Hébergement HDS : obligation et certification

L'article L.1111-8 du Code de la santé publique impose que tout hébergement de données de santé à caractère personnel soit réalisé par un hébergeur certifié HDS. Cette certification est délivrée par un organisme accrédité par le COFRAC (Comité Français d'Accréditation) pour une durée de 3 ans.

La certification HDS couvre 6 activités :

1. Mise à disposition et maintien en condition opérationnelle de l'infrastructure physique
2. Mise à disposition et maintien en condition opérationnelle de l'infrastructure virtuelle
3. Mise à disposition et maintien en condition opérationnelle de la plateforme logicielle
4. Administration et exploitation du système d'information de santé
5. Sauvegarde externalisée des données de santé
6. Mise à disposition d'un portail de services sécurisé

Hébergeurs HDS certifiés en France (principaux) :

• OVHcloud (certifié HDS activités 1 à 6)
• Scaleway (certifié HDS activités 1 à 3)
• Outscale (3DS OUTSCALE, certifié HDS et SecNumCloud)
• Claranet (certifié HDS activités 1 à 6)
• Oodrive (certifié HDS pour le stockage)
• AWS (certifié HDS sur la région eu-west-3 Paris)
• Microsoft Azure (certifié HDS sur la région France Central)

Important : la certification HDS de l'hébergeur ne suffit pas. L'éditeur de l'application doit s'assurer que son architecture technique respecte les exigences de la certification. Un serveur chez un hébergeur certifié HDS mais mal configuré (ports ouverts, logs non chiffrés, backups non sécurisées) ne rend pas l'application conforme.

#Surcoût HDS : chiffres réels 2026

L'hébergement HDS coûte significativement plus cher qu'un hébergement standard. Voici les fourchettes constatées en 2026 pour une application mobile santé de taille moyenne (500 à 5 000 utilisateurs actifs).

Le surcoût annuel HDS de 8 000 à 15 000 euros par an est la fourchette la plus fréquente pour les applications mobiles B2B de taille moyenne. Pour les applications à fort volume (50 000+ utilisateurs, stockage de fichiers médicaux volumineux), ce surcoût peut atteindre 30 000 à 50 000 euros par an.

→ Vous évaluez vos options ? Utilisez notre estimateur de budget en ligne pour obtenir une fourchette en 2 minutes, ou consultez nos tarifs détaillés.

#RGPD appliqué aux applications mobiles santé : les 8 obligations clés

#1. Base légale du traitement

Pour les données de santé, le consentement explicite de l'utilisateur est la base légale la plus courante (article 9.2.a du RGPD). Ce consentement doit être libre, spécifique, éclairé et univoque. Il ne peut pas être implicite (case pré-cochée interdite) ni conditionner l'accès au service (anti-pattern « mur de consentement »).

Alternative : la base légale « intérêt vital » (article 9.2.c) ou « médecine préventive ou du travail » (article 9.2.h) peut s'appliquer dans certains contextes hospitaliers ou de médecine du travail, mais elle est rarement applicable pour une application mobile grand public.

#2. Minimisation des données

L'application ne doit collecter que les données strictement nécessaires à sa finalité. Exemple : une application de suivi de tension artérielle n'a pas besoin de collecter la géolocalisation, l'historique d'appels ou l'accès aux contacts. Chaque donnée collectée doit être justifiable devant la CNIL en cas de contrôle.

Chez Nehos, nous utilisons une matrice de données à la phase de cadrage : chaque champ de formulaire, chaque permission système et chaque tracker est listé avec sa justification métier. Les données non justifiées sont supprimées du périmètre.

#3. Chiffrement des données

Le chiffrement est obligatoire à trois niveaux pour une application mobile santé :

En transit : TLS 1.3 minimum pour toutes les communications entre l'application mobile et le serveur. Pas de fallback TLS 1.2 sauf pour les appareils obsolètes (< 2 % du parc en 2026). Certificate pinning recommandé pour prévenir les attaques man-in-the-middle.

Au repos côté serveur : chiffrement AES-256 de la base de données et des fichiers stockés. Les clés de chiffrement doivent être gérées par un KMS (Key Management Service) certifié, séparé du serveur de données.

Au repos côté mobile : les données de santé stockées localement sur le smartphone (cache offline, données de synchronisation) doivent être chiffrées via les mécanismes natifs : Keychain + Data Protection sur iOS, EncryptedSharedPreferences + Android Keystore sur Android. En Flutter, le package flutter_secure_storage utilise ces mécanismes automatiquement.

#4. Consentement granulaire et traçable

Le consentement de l'utilisateur doit être recueilli de manière granulaire : chaque finalité de traitement (suivi médical, statistiques anonymisées, partage avec le médecin traitant, notifications de rappel) doit faire l'objet d'un consentement séparé. L'utilisateur doit pouvoir retirer son consentement à tout moment, avec la même facilité qu'il l'a donné.

Techniquement, cela implique un écran de gestion des consentements accessible en permanence dans les paramètres de l'application, avec un historique horodaté des consentements accordés et retirés, stocké côté serveur.

#5. Droit à l'effacement et portabilité

L'utilisateur doit pouvoir demander la suppression de toutes ses données de santé. La suppression doit être effective (pas uniquement logique mais aussi physique) dans un délai de 30 jours maximum. Les backups doivent également être purgées, ce qui complexifie l'architecture de sauvegarde.

Le droit à la portabilité oblige à fournir à l'utilisateur l'ensemble de ses données dans un format structuré, couramment utilisé et lisible par machine (JSON ou CSV). Un bouton « Exporter mes données » doit être accessible dans l'application.

#6. Analyse d'impact (AIPD / DPIA)

Le traitement de données de santé à grande échelle nécessite obligatoirement une Analyse d'Impact relative à la Protection des Données (AIPD, ou DPIA en anglais). Cette analyse doit être réalisée avant la mise en production de l'application et documentée. Elle identifie les risques pour les droits et libertés des personnes et les mesures de mitigation mises en place.

Chez Nehos, nous réalisons l'AIPD en parallèle du développement, pendant la phase de cadrage et de conception. Le coût de cette prestation est de 3 000 à 5 000 euros selon la complexité du projet.

#7. DPO et registre des traitements

Si votre organisation traite des données de santé à grande échelle, la désignation d'un DPO (Délégué à la Protection des Données) est obligatoire. Le DPO peut être interne ou externe. Le registre des traitements doit documenter chaque traitement de données de santé avec sa finalité, sa base légale, les catégories de données, les destinataires, les durées de conservation et les transferts hors UE.

#8. Notification des violations de données

En cas de violation de données de santé (fuite, accès non autorisé, perte), la CNIL doit être notifiée dans les 72 heures. Si la violation présente un risque élevé pour les droits des personnes, les personnes concernées doivent également être notifiées directement. L'application doit donc intégrer un mécanisme de détection des accès anormaux et un plan de réponse aux incidents documenté.

#Architecture technique recommandée pour une app santé

Voici l'architecture que nous recommandons chez Nehos pour les applications mobiles santé conformes RGPD et HDS :

Frontend mobile : Flutter ou React Native avec flutter_secure_storage ou react-native-keychain pour le stockage sécurisé local. Certificate pinning activé. Biométrie pour l'authentification locale (Face ID, Touch ID, empreinte Android).

Backend API : Node.js ou Python (Django) hébergé sur un serveur HDS. API REST avec authentification OAuth 2.0 + PKCE. Rate limiting et détection d'anomalies. Logs d'accès chiffrés et archivés pendant 1 an minimum.

Base de données : PostgreSQL chiffré AES-256 sur un hébergeur HDS. Séparation logique des données de santé et des données d'identité (pseudonymisation). Backups chiffrés quotidiens avec rotation des clés.

Stockage fichiers : Object storage HDS (OVH Object Storage HDS, ou AWS S3 région Paris avec contrat HDS). Chiffrement côté serveur (SSE-S3 ou SSE-KMS).

Monitoring : Stack de monitoring sécurisée (pas de logs de données de santé en clair). Alertes en cas d'accès anormal. Audit trail complet pour la traçabilité des accès.

#Coûts de développement d'une application mobile santé

Le surcoût de conformité RGPD et HDS s'ajoute au coût de développement standard. Voici la décomposition sur un projet type :

Le surcoût de conformité représente 15 à 25 % du budget de développement. C'est un investissement qui protège l'entreprise contre des sanctions pouvant atteindre plusieurs millions d'euros et qui renforce la confiance des utilisateurs et des professionnels de santé.

Pour un chiffrage précis de votre projet santé, consultez notre guide combien coûte une application mobile sur mesure en 2026 ou prenez rendez-vous avec notre équipe via notre page développement d'applications mobiles.

Pour le choix technologique de votre application santé, consultez notre comparatif Flutter vs React Native 2026. L'ensemble de nos services de développement est disponible, y compris nos solutions d'agents IA pour les cas d'usage d'assistance médicale automatisée.