React Native pour les applications médicales : retour d'expérience (2026)
10/05/2026
React Native est devenu en quelques années le choix par défaut pour beaucoup d'éditeurs e-santé qui veulent un produit mobile cross-platform sans doubler leurs équipes iOS et Android. La promesse est tenue sur la productivité, mais elle s'accompagne de contraintes spécifiques au secteur médical que peu de tutoriels grand public abordent : hébergement HDS, stockage chiffré local, authentification biométrique, intégrations HealthKit/Google Fit, accessibilité RGAA et considérations dispositif médical.
Chez Bob le développeur, on développe des apps React Native médicales depuis 2018 (Zenior, Hypnolib, Surge, et plusieurs projets internes hospitaliers). Cet article rassemble les choix d'architecture qu'on referait, ceux qu'on ne referait pas, et les pièges concrets qui font perdre du temps quand on attaque un projet médical avec React Native.
L'essentiel en 30 secondes :
- React Native est adapté à 80 % des cas d'usage médicaux mobiles. Les exceptions : dispositifs médicaux temps réel critiques et calculs lourds locaux.
- Le backend doit être HDS. Le terminal mobile, lui, n'est pas hébergeur de données de santé, mais doit chiffrer toute donnée persistée.
- L'offline-first n'est pas optionnel en milieu hospitalier : le Wi-Fi tombe, la couverture cellulaire est nulle dans les sous-sols.
- HealthKit / Google Fit / Health Connect ouvrent l'accès aux constantes physiologiques mais avec des modèles de consentement différents par OS.
- RGAA mobile : VoiceOver et TalkBack se gèrent avec quelques props bien posées, pas avec une refonte tardive.
Quand React Native est le bon choix pour une app médicale
React Native s'impose dans la plupart des projets médicaux mobiles parce que les besoins fonctionnels sont assez standards : authentification, formulaires de saisie clinique, listes de patients, graphes de constantes, notifications push, capture photo, export PDF. Tout cela se fait nativement en JS via le pont React Native ou via les modules natifs maintenus par la communauté.
Les cas d'usage où on l'a déployé sans regret :
- Application patient : suivi à domicile, déclaration de symptômes, rendez-vous, accès au DMP via Mon Espace Santé.
- Application professionnelle de cabinet : prise de notes, ordonnance, secrétariat, plannings.
- Application de coordination : suivi inter-services, messagerie sécurisée, partage de comptes rendus.
- Compagnon hospitalier : tableau de bord pour un service, alertes, surveillance non-critique.
Les cas où on choisirait du natif pur :
- Dispositifs médicaux temps réel classés IIa/IIb avec exigences de latence dures (monitoring continu d'arythmies, télémétrie de bloc opératoire). Le pont JS ajoute une latence et une complexité de validation que vous ne voulez pas certifier.
- Calculs lourds locaux type traitement d'image médicale, segmentation, IA embarquée. Possible en RN avec des modules natifs, mais le coût d'intégration dépasse vite celui d'une équipe native.
- Apps Apple Watch / Wear OS standalones où RN n'est pas (ou mal) supporté.
Pour 80 % des projets éditeurs e-santé, RN reste le bon choix. La question intéressante n'est plus RN ou natif mais Expo ou bare RN.
Expo ou bare React Native ?
Expo s'est sérieusement professionnalisé. Les Dev Clients, EAS Build et Updates en font une option viable même pour des projets santé production. La règle qu'on applique :
- Expo (managed + Dev Client) : par défaut, sauf raison contraire. Vitesse de mise en route, OTA updates contrôlés, builds reproductibles via EAS, gestion fine des canaux de release.
- Bare RN : si vous avez besoin d'un module natif que personne ne maintient en config plugin Expo (rare aujourd'hui), ou si votre stack DSI exige une chaîne de build Xcode/Gradle classique.
L'erreur classique consiste à éjecter Expo trop tôt sur un FUD ("on va peut-être avoir besoin d'un module natif un jour"). Restez en Expo tant que vous le pouvez.
Hébergement HDS : ce qui change côté mobile
L'hébergement HDS concerne le stockage et le traitement des données de santé pour le compte de tiers. Côté mobile, le terminal du patient ou du professionnel n'est pas un hébergeur : c'est un dispositif d'usage. Vous n'avez donc pas à faire certifier l'iPhone du patient.
Ce qui doit être HDS :
- Tous vos serveurs, y compris API, base de données, stockage de fichiers, queues, caches, monitoring qui logge des données de santé.
- Les services tiers que vous utilisez pour traiter des données de santé : API SMS si elles transmettent du contenu santé, pipelines analytics, OCR cloud, etc.
- Les backups et environnements de pré-production qui contiennent des données réelles.
Pour le détail des hébergeurs réalistes (OVHcloud, AWS, Scaleway, Azure), voir notre comparatif HDS.
Côté mobile, ce qui s'impose c'est le chiffrement local et le contrôle de l'export :
- Stockage local chiffré : tout ce qui touche aux données de santé doit être chiffré au repos.
expo-secure-store(iOS Keychain / Android Keystore) pour les secrets ; pour les datasets plus larges, SQLite chiffré (op-sqlcipher,expo-sqlite/nextavec clé issue de Keychain). - Cache contrôlé : pas de mise en cache aveugle d'images de santé via les libs standards. Utilisez un FileSystem privé chiffré ou désactivez le cache disque.
- Logs sans données : les logs Sentry, Datadog, Firebase doivent scrubber tout ce qui peut être un identifiant patient. Mettez en place un wrapper de log qui redacte par défaut.
- Pas de screenshots :
FLAG_SECUREsur Android et masquage en multitâche sur iOS pour les écrans qui affichent des données nominatives.
Offline-first hôpital : pas négociable
Le Wi-Fi hospitalier est notoirement mauvais. Les sous-sols (radiologie, blocs, garages) n'ont pas de couverture cellulaire. Le réseau interne est segmenté avec des règles strictes. Pour qu'une app pro tourne en milieu hospitalier, elle doit fonctionner offline.
Trois choix d'architecture qu'on voit revenir :
1. Cache de lecture + queue d'écriture. Le minimum syndical. Toutes les données récupérées en ligne sont mises en cache local. Les écritures sont mises en queue et rejouées quand le réseau revient. Bon pour des cas d'usage simples : consultation d'un dossier patient, prise de notes asynchrones.
2. Sync différentielle bidirectionnelle. Vous tenez un état local complet et vous synchronisez les deltas dans les deux sens. WatermelonDB ou un build maison sur SQLite + journaling. Bon pour des apps de coordination où plusieurs utilisateurs touchent les mêmes objets, à condition de gérer les conflits (last-write-wins, CRDT, ou flag manuel).
3. CRDT. Pour les apps où la concurrence est forte et où aucun conflit ne doit être perdu. Yjs ou Automerge fonctionnent en RN avec un peu de tuning. Cas typique : annotations multi-utilisateurs sur un même document patient.
Le point le plus sous-estimé : la sécurité du cache offline. Si l'utilisateur se déconnecte explicitement, ou si le terminal est volé, votre cache local doit être détruit (ou au minimum inaccessible). Implémentez une rotation de clé de chiffrement liée à la session et un wipe au logout.
Authentification : biométrie, Pro Santé Connect, INS
Pour une app patient, l'authentification ressemble à n'importe quelle app grand public, avec quelques adaptations :
- FranceConnect+ si vous visez le catalogue Mon Espace Santé. Voir notre guide d'intégration MES éditeurs.
- Biométrie locale (Face ID, Touch ID, empreinte Android) avec
expo-local-authenticationpour réauthentifier l'utilisateur sur les actions sensibles. Toujours en complément, jamais en remplacement d'une authentification serveur. - Code PIN local pour les terminaux qui n'ont pas de biométrie disponible.
Pour une app professionnelle, c'est Pro Santé Connect qui s'impose. RN gère bien le flow OIDC via expo-auth-session ou react-native-app-auth. Le détail technique du flow PSC est dans notre guide PSC.
Quelques règles qu'on applique systématiquement :
- Refresh token rotatif côté serveur, jamais stocké en plain ; utiliser
SecureStoreavec contrainte biométrique. - Verrouillage automatique après inactivité (5-10 min selon le contexte). Plus court en milieu hospitalier que sur app patient.
- Détection d'ancienneté de l'OS : refuser les iOS / Android vraiment trop vieux qui ne supportent plus les chiffrements modernes.
HealthKit, Google Fit et Health Connect
L'accès aux constantes physiologiques du téléphone (pas, fréquence cardiaque, sommeil, glycémie, etc.) ouvre des cas d'usage très puissants pour les apps médicales. Trois écosystèmes à connaître :
- HealthKit (iOS). Le plus mature. API riche, granularité fine sur le consentement type par type. Bibliothèque maintenue :
react-native-healthou un module Expo plugin. - Google Fit (Android). En cours de dépréciation au profit de Health Connect. Encore utile pour cibler des Android plus anciens.
- Health Connect (Android). Le successeur officiel, recommandé depuis Android 14. API plus moderne, gestion des permissions repensée. Bibliothèque :
react-native-health-connect.
Les pièges classiques :
- Le consentement n'est pas global. L'utilisateur peut accorder l'accès à certaines mesures et pas à d'autres. Votre code doit gérer les permissions par type, pas en bloc.
- iOS ne dit pas si l'accès est refusé. Pour des raisons de privacy, HealthKit retourne un tableau vide au lieu d'une erreur explicite. Différenciez "pas de données" vs "permission refusée" via une heuristique (vérifier si d'autres types autorisés ont des données).
- Background delivery : possible mais coûteux en énergie. Si vous voulez des notifications déclenchées par une mesure (ex : alerte glycémie), utilisez
enableBackgroundDeliverysur HealthKit avec parcimonie. - Données médicales = dispositif médical. Si vous interprétez ces données pour donner un conseil clinique, vous tombez probablement sous MDR/SaMD (cf. dernière section).
Accessibilité RGAA / WCAG mobile
Le RGAA s'applique aussi aux applications mobiles, pas seulement au web. Pour les apps santé du secteur public et celles qui visent le catalogue Mon Espace Santé, c'est exigé. Pour les autres, c'est un bon investissement de toute façon : VoiceOver et TalkBack sont utilisés par une part non négligeable des patients âgés ou malvoyants.
Les éléments qui font 80 % du score :
accessibilityLabelsur tous les éléments interactifs sans label texte visible (icônes seules, boutons d'action).accessibilityRolecorrect (button,header,link,image,adjustable).accessibilityStatepour les composants à états (selected, checked, disabled, expanded).- Contrastes WCAG AA minimum (4.5:1 sur texte normal, 3:1 sur texte large).
- Tailles de police qui scalent avec les paramètres OS (
allowFontScaling). - Ordre de focus prévisible, sans piège clavier sur Android.
- Annonces dynamiques via
AccessibilityInfo.announceForAccessibilityquand le contenu change sans interaction utilisateur (ex : alerte serveur).
Pour le détail des critères et de l'outillage, on a couvert le sujet plus largement dans notre guide accessibilité RGAA/WCAG. La plupart des recommandations sont transposables au mobile.
Dispositif médical logiciel : RN n'est pas un blocage, l'usage l'est
La question revient à chaque kickoff : "est-ce que développer en React Native nous empêche d'avoir un marquage CE classe IIa ?". Réponse : non, le choix de framework n'est pas un facteur de classification au sens du règlement MDR. Ce qui détermine la classe, c'est la finalité du logiciel et le risque qu'il fait courir au patient.
Cela dit, RN ajoute deux contraintes pratiques quand on vise une certification dispositif médical :
- Documentation technique de la chaîne de build. Vous devez être capable de prouver la reproductibilité du build, le suivi des dépendances tierces (audit SBOM), et les contrôles qualité associés. EAS Build aide ; un fichier de lock figé et un mirror NPM privé aussi.
- Validation des modules natifs utilisés. Chaque dépendance native qui touche aux données patient ou à un calcul cliniquement significatif doit être tracée dans votre dossier qualité.
Pour les détails sur la classification SaMD, le marquage CE et les organismes notifiés, on a écrit un guide certification dispositif médical logiciel.
Stack qu'on monte par défaut sur un projet médical RN
Pour un projet qui démarre aujourd'hui, voici ce qu'on installe sans réfléchir :
| Besoin | Choix | Notes |
|---|---|---|
| Framework | Expo SDK 50+ avec Dev Client | Sauf contre-indication forte |
| Navigation | expo-router |
Convention de routes basée sur les fichiers |
| State serveur | TanStack Query | Cache, retry, pagination, offline mutations |
| State client | Zustand ou Jotai | Plus simple que Redux pour 95 % des cas |
| Stockage sécurisé | expo-secure-store + SQLCipher |
Secrets en SecureStore, datasets en SQL chiffré |
| Auth | expo-auth-session ou react-native-app-auth |
OIDC pour PSC / FranceConnect+ |
| Biométrie | expo-local-authentication |
Réauthentification d'actions sensibles |
| HealthKit / Health Connect | react-native-health + react-native-health-connect |
Permissions par type |
| Notifications | expo-notifications + APNs/FCM |
OneSignal si besoin de campagnes |
| Crash & monitoring | Sentry avec scrubbing PHI | Wrapper qui redacte par défaut |
| Tests | Jest + Maestro | E2E sur device cloud (BrowserStack, Sauce) |
| Builds | EAS Build + EAS Update | Canaux de release par environnement |
Cette stack tient en production sur les apps qu'on opère et reste raisonnable à maintenir avec une équipe de 2-3 développeurs.
Pièges et retours terrain
Quelques erreurs récurrentes qu'on voit sur les projets RN médicaux :
Pas de stratégie offline dès le jour 1. L'offline est ajouté à la fin, ça ne marche jamais. Architecture = cache et queue dès le premier sprint, même si le périmètre est minimal au départ.
Cache de données non chiffré. TanStack Query persiste par défaut en AsyncStorage non chiffré. Si vous persistez le cache pour le offline, configurez un persister chiffré (AsyncStorage ne suffit pas pour des données de santé).
OTA updates incontrôlés. EAS Update permet de pousser du JS sans repasser par les stores. Pratique, mais sur un projet médical il faut un canal de release stable et une procédure de validation. Sinon vous shippez un bug en prod sans audit.
Tester uniquement sur les flagships. Les apps patient tournent souvent sur des terminaux anciens (parents, EHPAD). Testez sur un Android d'entrée de gamme et un vieil iPhone — performance et accessibilité s'écroulent vite.
Sous-estimer l'app Store review. Apple est strict sur les apps santé : description claire de la finalité, mentions légales, politique de confidentialité, parfois validation manuelle longue. Anticipez 2-4 semaines de marge pour la première soumission.
Mélanger données pro et patient sur le même bundle. Si votre offre couvre les deux profils, séparez en deux apps distinctes. Les exigences de sécurité, d'auth et d'audit sont différentes, et un bundle unique finit par être un compromis insatisfaisant des deux côtés.
FAQ — React Native médical
Peut-on certifier une app dispositif médical en React Native ? Oui. La classification MDR ne dépend pas du framework choisi mais de la finalité et du risque. RN est compatible avec les classes I, IIa et IIb sous réserve d'une chaîne de build maîtrisée et d'une documentation technique rigoureuse.
Faut-il faire valider l'app par l'ANS ? Pas l'app en elle-même. Ce qui est validé par l'ANS, c'est votre logiciel au sens du référentiel Ségur, votre intégration MES si vous visez le catalogue, et les briques techniques (PSC, INS) si vous les utilisez. Voir notre guide Ségur Vague 2.
Combien coûte une app médicale RN ? Pour un MVP fonctionnel : 60 000 € à 150 000 € selon la complexité (auth, intégrations DMP/PSC, offline-first, dashboard pro associé). Le détail par typologie est dans notre guide budget e-santé.
Expo ou bare RN pour un projet santé ? Expo par défaut, y compris en production santé. EAS Build, Dev Client et Updates couvrent la quasi-totalité des besoins. Bare uniquement si une dépendance native critique n'a pas de plugin Expo.
Stockage local : SQLite chiffré ou Realm ? Les deux marchent. On part plutôt sur SQLite + SQLCipher pour la transparence (SQL standard, possibilité de migration), sauf si vous avez déjà des compétences Realm en interne.
Comment gérer le consentement HealthKit en RGPD ? Le consentement OS (HealthKit) n'est pas le consentement RGPD pour le traitement des données dans votre app. Il faut un second consentement explicite, tracé, avec base légale identifiée (consentement art. 6.1.a + condition art. 9.2.h pour les données de santé).
Push notifications avec données de santé : autorisé ? Le contenu d'un push transit par APNs/FCM, pas hébergés en France ni HDS. Donc jamais de données de santé identifiantes dans un push. Privilégier des notifications neutres ("Vous avez un nouveau message dans votre app") + récupération du contenu en ligne après ouverture.
Aller plus loin
React Native est un excellent choix pour 80 % des projets médicaux mobiles, à condition d'arriver avec une architecture pensée pour les contraintes du secteur : HDS côté backend, chiffrement local, offline-first, biométrie, accessibilité. Les détails techniques se gèrent ensuite — l'erreur est presque toujours dans le cadrage initial, pas dans le code.
Si vous portez un projet d'application médicale et que vous voulez sécuriser les choix techniques en amont, parlons de votre projet. On a vu ce qui marche, ce qui ne marche pas, et on peut cadrer l'architecture en fonction de votre couloir applicatif et de vos contraintes réglementaires.