React Native pour les applications médicales : retour d'expérience (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 (Hypnolib, 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 en JS, avec des modules natifs appelés directement par JSI depuis la nouvelle architecture de React Native, ou via les modules 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 runtime JavaScript ajoute une couche à valider et à documenter 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 avec builds de développement : par défaut, sauf raison contraire. Les dossiers natifs sont générés par npx expo prebuild et personnalisés par des config plugins. Vitesse de mise en route, OTA updates contrôlés, builds reproductibles via EAS, gestion fine des canaux de release.
Projets natifs maintenus à la main : 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 à sortir de ce modèle 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é : expo-sqlite avec l'option useSQLCipher et une clé tirée de SecureStore, ou @op-engineering/op-sqlite compilé avec SQLCipher.
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_SECURE sur 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 (dernière version stable en avril 2025 : testez-la sur votre version de React Native avant de vous engager) 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, FranceConnect+

Pour une app patient, l'authentification ressemble à n'importe quelle app grand public, avec quelques adaptations :

FranceConnect+ ou l'appli carte Vitale : le référentiel d'identification électronique des usagers de la PGSSI-S demande un moyen de niveau eIDAS substantiel, que vous visiez ou non 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-authentication pour 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. Le flux OIDC ne se joue pas dans l'app : le référentiel PSC impose de garder le client ID et le secret sur un serveur et d'ouvrir un navigateur extérieur à l'application, sans webview. L'app ouvre donc le navigateur du téléphone vers votre backend, qui mène l'échange avec PSC puis renvoie l'utilisateur dans l'app avec votre propre session. 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 SecureStore avec 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 : @kingstinct/react-native-healthkit. react-native-health, longtemps la référence, n'a plus reçu de version depuis octobre 2024.
Google Fit (Android). À écarter pour un nouveau projet : Google n'accepte plus d'inscription à ces API depuis le 1er mai 2024 et annonce la fin de leur prise en charge pour fin 2026.
Health Connect (Android). Le successeur officiel. Intégré au système à partir d'Android 14, disponible par l'application du Play Store d'Android 9 à 13. 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 enableBackgroundDelivery sur 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, c'est une obligation légale. Le référentiel du catalogue Mon espace santé demande, lui, de justifier d'une méthode d'évaluation de l'accessibilité. 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 :

accessibilityLabel sur tous les éléments interactifs sans label texte visible (icônes seules, boutons d'action).
accessibilityRole correct (button, header, link, image, adjustable).
accessibilityState pour 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.announceForAccessibility quand 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 en cours de support) avec build de développement	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	Flux OIDC porté par le backend, navigateur système ouvert avec `expo-web-browser`	PSC : client ID et secret côté serveur, pas de webview
Biométrie	`expo-local-authentication`	Réauthentification d'actions sensibles
HealthKit / Health Connect	`@kingstinct/react-native-healthkit` + `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 garde son cache en mémoire et ne l'écrit sur disque que si vous ajoutez un persister. L'exemple de sa documentation pour React Native passe par AsyncStorage, qui n'est pas chiffré : si vous persistez le cache pour le offline, branchez le persister sur un stockage chiffré.

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, et pas tout auprès de l'ANS. L'ANS référence les logiciels au titre du Ségur et gère le raccordement à Pro Santé Connect. L'appel au téléservice INSi demande une autorisation du CNDA, côté Assurance maladie. Le référencement au catalogue Mon espace santé est instruit par une commission de référencement et décidé par le ministre chargé de la santé. 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, les builds de développement et Updates couvrent la quasi-totalité des besoins. Projet natif maintenu à la main uniquement si une dépendance native critique n'a pas de plugin Expo.

Stockage local : SQLite chiffré ou Realm ? SQLite chiffré. MongoDB a déprécié les SDK Realm en septembre 2024, avec une fin de vie au 30 septembre 2025. La base locale subsiste en projet open source, sans nouvelle version npm depuis août 2025. On part sur SQLite + SQLCipher : SQL standard, migrations maîtrisées.

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 de l'article 6.1.a et, pour les données de santé, consentement explicite de l'article 9.2.a).

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, notre agence React Native peut cadrer l'architecture avec vous : 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.