L'essentiel sur le développement d'applications mobiles santé conformes HDS
Toute application mobile qui collecte, stocke ou traite des données de santé à caractère personnel en France doit être hébergée sur une infrastructure certifiée HDS (Hébergement de Données de Santé). Cette obligation légale, issue de l'article L.1111-8 du Code de la santé publique et renforcée par le décret n°2018-137, s'applique sans exception : appli de suivi patient, plateforme de téléconsultation, logiciel de gestion de cabinet, application pharmacie, outil de coordination soins. La certification HDS est délivrée par des organismes accrédités par le COFRAC sur la base du référentiel de l'ANS (Agence du Numérique en Santé, ex-ASIP Santé). OVHcloud est certifié HDS depuis 2019 sur les 6 activités du référentiel — c'est l'hébergeur que Nehos recommande et utilise pour tous les projets santé.
Le RGPD s'applique en surcouche avec des exigences renforcées pour les données de santé (article 9 du RGPD — catégorie spéciale). Consentement explicite du patient, registre de traitement spécifique, AIPD (Analyse d'Impact relative à la Protection des Données) obligatoire, DPO (Délégué à la Protection des Données) désigné, droit d'accès et de portabilité renforcés, notification de violation dans les 72 heures à la CNIL et aux patients concernés. Notre approche : le Privacy by Design n'est pas un ajout post-développement — il est intégré dans l'architecture technique dès le premier sprint.
Stack technique Nehos pour les applications santé. Frontend mobile : Flutter (Dart) pour les applications nécessitant une UI complexe et du offline-first, React Native (TypeScript) quand l'écosystème npm et le partage de code avec le web sont prioritaires. Backend : API REST sécurisée (Node.js/NestJS ou Python/FastAPI selon contexte), base de données chiffrée au repos (PostgreSQL avec pgcrypto ou MongoDB avec encryption at rest), hébergement OVHcloud Private Cloud HDS. Sécurité : chiffrement bout en bout (TLS 1.3 en transit, AES-256 au repos), authentification forte (OAuth 2.0 + biométrie mobile), journalisation des accès aux données de santé (audit trail HIPAA-grade), tests de pénétration avant mise en production.
Tarification selon périmètre fonctionnel : 212 k€ HT pour une application de suivi patient mono-pathologie (iOS + Android via Flutter, 4 à 6 mois), jusqu'à partir de 51 k€ HT pour une plateforme de télémédecine multi-praticiens avec intégration DMP, agenda, prescription, paiement et visioconférence sécurisée (8 à 14 mois). L'audit conformité HDS/RGPD initial (5 à 10 jours, à partir de 873 € HT) est déductible du projet si engagement dans les 60 jours.
Applications Mobiles Santé — Conformité HDS et RGPD de Bout en Bout
Depuis 2018, l'hébergement de données de santé à caractère personnel est soumis à la certification HDS délivrée par l'ANS (ex-ASIP Santé). Nehos développe vos applications mobiles santé (suivi patient, téléconsultation, gestion cabinet, pharmacie) sur Flutter ou React Native, hébergées sur infrastructure OVHcloud certifiée HDS, avec chiffrement bout en bout et conformité RGPD intégrée dès la conception. Intégration DMP, interopérabilité SNDS, audit CNIL-ready. 212 k€ HT.
Adapté à toute taille de structure
#Certification HDS — Ce que la loi exige pour votre application mobile santé
La certification HDS (Hébergement de Données de Santé) n'est pas une option ni une bonne pratique — c'est une obligation légale en France pour tout hébergeur de données de santé à caractère personnel. L'article L.1111-8 du Code de la santé publique, modifié par la loi de modernisation de notre système de santé (2016) puis précisé par le décret n°2018-137 du 26 février 2018, est sans ambiguïté : toute personne qui héberge des données de santé à caractère personnel recueillies lors d'activités de prévention, de diagnostic, de soins ou de suivi médico-social doit être certifiée HDS.
#Le référentiel HDS de l'ANS — 6 activités certifiables
Le référentiel de certification HDS, défini par l'ANS (Agence du Numérique en Santé, ex-ASIP Santé), couvre 6 activités distinctes. Activité 1 : mise à disposition et maintien en condition opérationnelle de l'infrastructure matérielle du SI de santé. Activité 2 : mise à disposition et maintien en condition opérationnelle de la plateforme d'hébergement du SI de santé. Activité 3 : administration et exploitation du SI de santé. Activité 4 : sauvegarde externalisée des données de santé. Activité 5 : mise à disposition et maintien en condition opérationnelle des sites physiques. Activité 6 : mise à disposition et maintien en condition opérationnelle de l'infrastructure réseau. Un hébergeur peut être certifié sur une ou plusieurs de ces activités. OVHcloud est certifié sur les 6 activités — c'est la raison pour laquelle Nehos l'utilise comme socle d'infrastructure pour tous les projets santé.
La certification HDS repose sur les normes ISO 27001 (management de la sécurité de l'information), ISO 27018 (protection des données personnelles dans le cloud), ISO 27017 (sécurité du cloud), et ISO 20000 (gestion des services IT). L'audit de certification est réalisé par un organisme accrédité par le COFRAC (Comité français d'accréditation) et renouvelé tous les 3 ans avec un audit de surveillance annuel.
#Sanctions en cas de non-conformité
L'hébergement de données de santé sans certification HDS expose à des sanctions pénales : jusqu'à 3 ans d'emprisonnement et 45 000 euros d'amende (article L.1115-2 du Code de la santé publique). En pratique, la CNIL et les ARS (Agences Régionales de Santé) intensifient les contrôles depuis 2024. Plusieurs startups e-santé ont reçu des mises en demeure pour hébergement de données de santé sur des infrastructures non certifiées. Le risque n'est pas théorique — c'est un risque opérationnel et juridique réel pour tout éditeur d'application santé.
#RGPD et données de santé — Exigences renforcées article 9
Les données de santé sont classées dans les « catégories particulières de données personnelles » par l'article 9 du RGPD. Leur traitement est interdit par défaut, sauf exceptions limitées : consentement explicite de la personne concernée, nécessité pour les soins de santé, intérêt public dans le domaine de la santé publique, ou recherche scientifique encadrée. Pour une application mobile santé destinée aux patients, c'est le consentement explicite qui s'applique dans la majorité des cas.
#AIPD obligatoire — Analyse d'Impact relative à la Protection des Données
Toute application qui traite des données de santé à grande échelle doit faire l'objet d'une AIPD (anciennement PIA — Privacy Impact Assessment) conformément à l'article 35 du RGPD. L'AIPD identifie les risques pour les droits et libertés des personnes concernées, évalue la nécessité et la proportionnalité du traitement, et définit les mesures pour atténuer les risques identifiés. Chez Nehos, l'AIPD est réalisée en Phase 0 du projet, avant le premier sprint de développement — elle conditionne les choix d'architecture technique. La CNIL publie un guide AIPD spécifique au secteur santé et un logiciel libre (PIA) pour structurer l'analyse.
#Privacy by Design — Pas un slogan, une méthode de conception
Le Privacy by Design (protection des données dès la conception, article 25 du RGPD) se traduit concrètement dans l'architecture de l'application mobile santé. Minimisation des données : on ne collecte que les données strictement nécessaires à la finalité déclarée — pas de « on collecte large et on verra plus tard ». Pseudonymisation : les données de santé sont dissociées des données d'identification directe dans la base de données — un identifiant technique remplace le nom/prénom dans les tables médicales. Chiffrement systématique : AES-256 au repos (base de données, fichiers, sauvegardes), TLS 1.3 en transit (API, websockets, push notifications). Journalisation des accès : chaque accès à une donnée de santé est tracé (qui, quand, quelle donnée, depuis quelle IP/device) — audit trail consultable et exportable pour les contrôles CNIL. Durée de conservation limitée : les données de santé sont purgées automatiquement à l'expiration de la durée légale de conservation (variable selon le type de donnée et la finalité).
#Architecture technique — Flutter/React Native + OVHcloud HDS
Le choix du framework mobile et de l'infrastructure d'hébergement est dicté par les contraintes réglementaires autant que par les besoins fonctionnels.
#Flutter pour les applications santé complexes
Flutter (Dart) est le choix Nehos pour les applications santé qui nécessitent une UI riche et personnalisée, un mode offline-first (médecins en zones blanches, visites à domicile sans connexion), ou des performances graphiques élevées (visualisation de données médicales, imagerie). Flutter compile en code natif ARM — pas de bridge JavaScript entre le runtime et les API natives du device. Avantage concret pour la santé : accès direct aux API biométriques (FaceID, TouchID, empreinte Android) pour l'authentification forte, accès aux capteurs (accéléromètre, gyroscope pour les applications de rééducation), accès Bluetooth Low Energy pour les dispositifs médicaux connectés (glucomètres, tensiomètres, oxymètres). Le mode offline-first de Flutter repose sur une base de données locale chiffrée (Hive ou Isar avec chiffrement AES) synchronisée avec le backend OVHcloud HDS dès que la connectivité est rétablie — les données de santé ne transitent jamais en clair, même en local.
#React Native pour le partage de code web/mobile
React Native (TypeScript) est pertinent quand l'éditeur possède déjà une application web React/Next.js et souhaite maximiser le partage de code entre web et mobile. Les composants métier (logique de validation, transformations de données, services API) sont partagés via des packages TypeScript monorepo (Turborepo). L'UI mobile utilise les primitives React Native (View, Text, ScrollView) tandis que l'UI web utilise les composants HTML/CSS — mais la logique métier est strictement identique. Pour les projets santé, React Native offre un écosystème npm mature pour les intégrations tiers (visioconférence via Twilio/Vonage, paiement via Stripe Connect, notifications push via Firebase Cloud Messaging avec chiffrement payload).
#Hébergement OVHcloud Private Cloud HDS
L'infrastructure cible pour les applications santé Nehos repose sur OVHcloud Private Cloud certifié HDS. Architecture type : cluster Kubernetes managé (OVHcloud Managed Kubernetes) pour l'orchestration des containers applicatifs, base de données PostgreSQL managée (OVHcloud Managed Databases) avec chiffrement at rest activé, stockage objet (OVHcloud Object Storage S3-compatible) pour les documents médicaux (ordonnances, résultats d'analyses, imagerie), réseau privé (vRack) isolant le SI de santé du reste de l'infrastructure, WAF (Web Application Firewall) et anti-DDoS OVHcloud en frontal. Les backups sont chiffrés et répliqués dans un second datacenter OVHcloud en France — conformité activité 4 du référentiel HDS (sauvegarde externalisée).
#Cas d'usage — Suivi patient, téléconsultation, gestion cabinet, pharmacie
#Application de suivi patient
L'application de suivi patient est le cas d'usage le plus fréquent en e-santé mobile. Fonctionnalités types : saisie des constantes (poids, tension, glycémie, douleur EVA), rappels de prise de médicaments (notifications push), journal de bord patient (symptômes, effets secondaires, bien-être), partage des données avec le médecin traitant via le DMP (Dossier Médical Partagé), alertes automatiques si dépassement de seuil (glycémie hors range, tension anormale). L'enjeu technique : le mode offline-first est critique (patients en zone rurale, en déplacement, en salle d'attente sans Wi-Fi). Les données saisies offline sont stockées en local dans une base chiffrée et synchronisées automatiquement dès retour de connexion.
#Plateforme de téléconsultation
La téléconsultation a été pérennisée par la loi de financement de la sécurité sociale 2023 après l'explosion des usages pendant la crise sanitaire. Les exigences techniques sont élevées : visioconférence chiffrée de bout en bout (WebRTC avec SRTP), partage d'écran et de documents médicaux en temps réel, prescription électronique intégrée (connexion à l'Ordonnance Numérique via le DMP), paiement sécurisé (tiers payant ou paiement patient via Stripe Connect), archivage du compte-rendu de consultation dans le DMP. La latence vidéo doit rester sous 150 ms pour un échange fluide — l'infrastructure OVHcloud avec des points de présence en France garantit cette performance.
#Gestion de cabinet médical
L'application de gestion de cabinet couvre l'agenda praticien (prise de RDV en ligne, synchronisation avec les plateformes type Doctolib via API), la gestion du dossier patient (antécédents, traitements en cours, allergies, correspondances), la facturation et télétransmission SESAM-Vitale, et le suivi comptable simplifié. L'intégration avec la carte CPS (Carte de Professionnel de Santé) est requise pour l'authentification du praticien lors de la télétransmission.
#Application pharmacie
Les applications pharmacie couvrent la gestion des ordonnances (scan, envoi sécurisé, préparation anticipée), le suivi des traitements chroniques (renouvellements, alertes d'interactions médicamenteuses), les services de click-and-collect pharmaceutique, et la connexion au DP (Dossier Pharmaceutique) via les web services de l'Ordre des Pharmaciens. La conformité HDS est obligatoire dès que l'application stocke ou transmet des données d'ordonnances.
#Intégration DMP et interopérabilité SNDS
Le DMP (Dossier Médical Partagé), devenu « Mon espace santé » depuis février 2022, est le pivot de l'interopérabilité du système de santé français. Toute application mobile santé ambitieuse doit s'y connecter via les API de l'ANS. Les formats d'échange standardisés sont CDA-R2 (Clinical Document Architecture) pour les documents médicaux structurés et HL7 FHIR (Fast Healthcare Interoperability Resources) pour les échanges de données entre systèmes.
Le SNDS (Système National des Données de Santé) agrège les données de l'Assurance Maladie, des hôpitaux, et des causes de décès. L'accès au SNDS pour les éditeurs d'applications santé nécessite une autorisation CNIL après avis du CESREES (Comité éthique et scientifique pour les recherches, les études et les évaluations dans le domaine de la santé). Nehos accompagne les éditeurs dans la constitution du dossier d'autorisation et l'implémentation technique des flux SNDS.
#Audit CNIL — Préparation et anticipation
La CNIL peut contrôler sur place ou en ligne toute application traitant des données de santé. La préparation à un contrôle CNIL se fait dès la conception du projet, pas la veille de l'audit. Les éléments que Nehos intègre systématiquement : registre des traitements à jour (article 30 du RGPD), AIPD documentée et signée, contrats de sous-traitance conformes article 28 du RGPD (notamment avec l'hébergeur HDS), procédure de notification de violation de données (72 heures), preuves de consentement explicite des patients (horodatées, versionnées), politique de durée de conservation avec mécanisme de purge automatique, documentation technique de la sécurité (chiffrement, contrôle d'accès, journalisation).
L'audit de sécurité pre-production Nehos inclut un test de pénétration (pentest) réalisé par un prestataire certifié PASSI (Prestataires d'Audit de la Sécurité des Systèmes d'Information, qualification ANSSI), un audit de code statique (SonarQube, Snyk) ciblant les vulnérabilités OWASP Mobile Top 10, et une revue de la configuration OVHcloud (groupes de sécurité, chiffrement, accès IAM, logs).
#Chiffrement bout en bout — Architecture de sécurité
Le chiffrement n'est pas une couche ajoutée — c'est l'ossature de l'architecture de sécurité d'une application santé conforme.
En transit : TLS 1.3 obligatoire sur toutes les communications (API REST, WebSocket, push notifications). Certificate pinning dans l'application mobile pour prévenir les attaques MITM (Man-in-the-Middle). Mutual TLS (mTLS) entre les microservices backend sur le cluster Kubernetes OVHcloud.
Au repos : AES-256 pour le chiffrement des bases de données PostgreSQL (pgcrypto ou Transparent Data Encryption), AES-256 pour les fichiers stockés en Object Storage S3 (server-side encryption SSE-S3), chiffrement des backups avec rotation de clés trimestrielle. Les clés de chiffrement sont gérées via un KMS (Key Management Service) — OVHcloud KMS ou HashiCorp Vault hébergé sur l'infrastructure HDS.
Sur le device mobile : base de données locale chiffrée (SQLCipher pour SQLite, ou Hive/Isar chiffré pour Flutter), keychain iOS / Android Keystore pour le stockage des tokens d'authentification, biométrie (FaceID/TouchID/empreinte) comme facteur d'authentification additionnel.
#Méthodologie Nehos — Phases projet santé HDS
Phase 0 — Audit conformité HDS/RGPD et cadrage (5 à 10 jours, 5 000 à160 000 € HT déductibles du projet). Cartographie des données de santé traitées par l'application. Identification des obligations légales spécifiques (HDS, RGPD article 9, AIPD). Revue de l'existant SI de santé (DMP, DPI, LAP/LAD, passerelles). Rédaction de l'AIPD. Spécifications fonctionnelles et techniques incluant les exigences conformité. Chiffrage définitif du projet.
Phase 1 — Architecture et socle technique (3 à 5 semaines). Provisionnement infrastructure OVHcloud HDS. Configuration Kubernetes, PostgreSQL chiffré, Object Storage, WAF. Setup CI/CD (GitHub Actions : lint, tests, scan sécurité Snyk, build, déploiement). Initialisation du projet Flutter ou React Native avec la couche de chiffrement. Mise en place du monitoring (Sentry, Datadog, alertes sécurité).
Phase 2 — Développement par sprints (3 à 12 mois selon périmètre). Sprints de 2 semaines avec démo métier. Chaque fonctionnalité est développée avec les tests unitaires, les tests E2E Maestro ou Detox, et la documentation conformité associée. Revue de sécurité continue (SonarQube en CI, dépendances auditées via npm audit/pub audit).
Phase 3 — Audit sécurité, pentest et mise en production (3 à 4 semaines). Pentest par prestataire PASSI. Remédiation des vulnérabilités identifiées. Soumission aux stores (App Store et Google Play — avec les justificatifs de conformité HDS requis par Apple pour la catégorie Santé). Documentation CNIL-ready remise au client.
#Tarification — 40 à 1920 k€ HT
Application suivi patient mono-pathologie (iOS + Android Flutter) : 40 à 880 k€ HT sur 4 à 6 mois. Inclut l'audit Phase 0, le socle OVHcloud HDS, le développement Flutter, les tests, le pentest, et la soumission stores.
Application gestion cabinet / pharmacie avec intégrations métier (SESAM-Vitale, DP, agenda) : 55 à 1360 k€ HT sur 6 à 10 mois. Inclut les intégrations tiers, la formation utilisateurs, et 3 mois de maintenance corrective post-déploiement.
Plateforme télémédecine multi-praticiens avec visio, prescription, DMP, paiement : 85 à 1920 k€ HT sur 8 à 14 mois. Inclut l'architecture micro-services, les intégrations DMP/SNDS, le pentest étendu, et 6 mois de TMA (Tierce Maintenance Applicative).
Tous les tarifs incluent l'hébergement OVHcloud HDS pour la première année et l'audit conformité initial. Estimation précise en 30 minutes via RDV : Calendly projet santé HDS.