Retour aux articles

Application mobile santé et médical : ce qu'il faut savoir

Développer une app santé en France en 2026 : RGPD, hébergement HDS, certification dispositif médical, contraintes stores et budget réaliste.

Application mobile santé et médical : ce qu'il faut savoir
Youssef Attia
Youssef Attia

Fondateur d'Inyka

Publié le 17 juillet 2026

6 min

Réponse courte

Développer une application mobile santé ou médicale en France en 2026 ajoute trois couches de contraintes à un projet mobile classique : hébergement HDS pour les données de santé, conformité RGPD renforcée, et selon l'usage médical, une certification dispositif médical (DM) sous le règlement européen MDR. Le budget de base est 30 à 70 % supérieur à un MVP grand public équivalent. Les délais de livraison s'allongent souvent de 4 à 12 semaines pour les phases de conformité. Sous-estimer ces aspects est la première cause d'échec ou de blocage des projets santé.

Pourquoi le mobile santé n'est pas un mobile comme un autre

Le secteur santé impose un cadre réglementaire dense que le grand public ignore. Trois textes structurent tout :

  • RGPD (Règlement européen sur la protection des données) : tout traitement de données personnelles, mais les données de santé sont qualifiées de sensibles (article 9) avec un cadre renforcé.
  • Hébergement de données de santé (HDS) : obligation française de stocker les données de santé chez un hébergeur certifié HDS par l'ANS.
  • MDR (Medical Device Regulation, règlement européen 2017/745) : si l'app a une finalité médicale (diagnostic, traitement, prévention), elle peut être qualifiée de dispositif médical et nécessite un marquage CE.

Ignorer un de ces trois cadres expose à des sanctions CNIL, à un retrait du store par Apple ou Google, ou à l'impossibilité d'être prescrite ou remboursée.

Hébergement HDS : ce que ça change

Si ton app stocke ou traite des données de santé (résultats d'analyses, antécédents médicaux, ordonnances, données de suivi de pathologie), ces données doivent être hébergées sur une infrastructure certifiée HDS.

Hébergeurs HDS certifiés couramment utilisés en France :

  • OVHcloud (offre HDS dédiée).
  • Outscale (Dassault Systèmes).
  • Scaleway (offre Healthcare).
  • AWS via une offre cadrée HDS.
  • Azure via Microsoft Cloud for Healthcare.
  • Google Cloud Platform via certaines régions.

Conséquences pratiques :

  • Tu ne peux pas utiliser Supabase ou Firebase tels quels pour la prod (ils ne sont pas HDS en France). Tu peux les utiliser en MVP de validation, mais tu devras migrer avant la mise en marché réelle.
  • Coût d'hébergement HDS : 200 à 1 500 €/mois minimum pour une infrastructure basique, contre 30 à 100 €/mois sur Supabase ou Firebase.
  • Délais administratifs : signer un contrat HDS prend généralement 4 à 8 semaines, à anticiper dans le planning.

RGPD renforcé pour les données santé

Les données de santé étant des données sensibles au sens du RGPD, leur traitement demande :

  • Une base légale solide : consentement explicite de l'utilisateur, ou nécessité pour la médecine préventive et l'assistance médicale (article 9.2.h).
  • Une analyse d'impact sur la protection des données (AIPD) obligatoire avant la mise en service.
  • Un délégué à la protection des données (DPO) désigné si tu traites des données de santé à grande échelle.
  • Des mesures de sécurité techniques renforcées : chiffrement au repos et en transit, contrôle d'accès strict, journalisation, pseudonymisation si possible.
  • Une politique de confidentialité spécifique mentionnant explicitement le traitement des données santé, l'hébergeur HDS et la durée de conservation.

Côté contrats, tu dois aussi signer un accord de traitement (DPA) avec ton hébergeur, et potentiellement avec tes prestataires techniques s'ils ont accès aux données.

Dispositif médical : faut-il un marquage CE ?

Si ton application a une finalité strictement informationnelle (annuaire de médecins, prise de rendez-vous, suivi nutritionnel non personnalisé), elle n'est généralement pas un dispositif médical.

Si ton application :

  • Aide au diagnostic d'une pathologie.
  • Recommande un traitement personnalisé.
  • Calcule un dosage de médicament.
  • Suit l'évolution d'une maladie chronique avec alerte au praticien.
  • Détecte ou prédit un événement médical (chute, crise, arythmie).

Alors elle entre probablement dans le périmètre du règlement MDR. Tu dois la qualifier en classe (I, IIa, IIb ou III selon le risque), passer un audit par un organisme notifié pour les classes II et III, obtenir le marquage CE, et la déclarer auprès de l'ANSM en France.

Coût et délai d'une certification CE médicale : 30 à 300 k€ et 6 à 18 mois selon la classe. Cette procédure se mène en parallèle du développement, pas après.

Si tu n'es pas sûr de la classification de ton app, fais-le qualifier par un expert affaires réglementaires en début de projet. C'est l'expertise la plus rentable du projet.

Contraintes spécifiques App Store et Google Play

Apple et Google ont des règles supplémentaires pour les apps santé :

Apple (App Store).

  • Section 1.4 des guidelines : interdiction des claims médicaux non prouvés.
  • Pour les apps qui agissent comme dispositif médical : Apple peut demander une preuve de marquage CE et le numéro d'agrément.
  • HealthKit nécessite des justifications très précises sur l'usage des données collectées.
  • Politique de confidentialité publique obligatoire avec mention spécifique santé.

Google (Play Store).

  • Politique sur les apps de santé : nécessite déclaration claire de l'usage et des bases scientifiques.
  • Health Connect (équivalent HealthKit) demande aussi des justifications détaillées.
  • Demande Data Safety renforcée avec mention explicite des données santé.

Les rejets de soumission sont fréquents sur les apps santé. Prévois 2 à 4 cycles de soumission au lieu de 1 à 2 pour une app grand public.

Cas d'usage et complexité associée

App d'annuaire et de prise de rendez-vous (type Doctolib basique). Pas de dispositif médical, RGPD standard renforcé sur données contact et motif, hébergement HDS si tu stockes le motif médical. Budget MVP : 15 à 30 k€.

App de suivi de pathologie chronique (diabète, hypertension). Souvent qualifiée dispositif médical classe I ou IIa. HDS obligatoire. Budget MVP : 40 à 90 k€ hors certification.

App d'aide au diagnostic. Dispositif médical classe IIa minimum. Procédure CE longue. Budget MVP : 60 à 200 k€ hors certification.

Téléconsultation. Cadre légal spécifique (avenant à la convention médicale, agrément). HDS obligatoire. Budget MVP : 80 à 250 k€.

App de bien-être pur (méditation, sommeil) sans claim médical. Pas de dispositif médical, RGPD standard. Budget MVP : 10 à 25 k€.

Le bon ordre des étapes

L'erreur la plus fréquente est de coder d'abord et de découvrir les contraintes après. Le bon ordre :

  1. Qualifier l'app : dispositif médical ou non, données santé ou non, finalité médicale ou informationnelle.
  2. Choisir l'hébergeur HDS si nécessaire, signer le contrat.
  3. Rédiger l'AIPD RGPD et la politique de confidentialité.
  4. Si dispositif médical : démarrer la procédure CE en parallèle, choisir un organisme notifié.
  5. Cadrer le MVP avec ces contraintes intégrées.
  6. Développer sur la stack HDS depuis le début, pas après coup.
  7. Tester avec des protocoles cliniques si dispositif médical.
  8. Publier sur les stores avec dossier de conformité prêt.

Sauter une étape coûte généralement 2 à 4 fois plus à la rattraper plus tard.

Le piège de la migration depuis Supabase ou Firebase

Beaucoup de projets santé démarrent en MVP sur Supabase ou Firebase pour valider l'usage, en se disant "on migrera vers du HDS quand on aura des utilisateurs". Cette stratégie est risquée pour deux raisons :

  • Dès qu'un utilisateur réel saisit ses données santé sur Supabase, tu es déjà en infraction RGPD (hébergement non HDS de données sensibles).
  • La migration de Supabase vers une stack HDS prend 4 à 12 semaines et coûte 15 à 40 k€ supplémentaires.

Si ton MVP doit collecter des données santé réelles dès le premier utilisateur, démarre directement sur du HDS. Si ton MVP teste l'usage sans collecter de données médicales sensibles (ex : maquette interactive, simulation), Supabase est ok.

Inyka ne prend pas ce type de projet

Soyons clairs : Inyka ne fait pas les apps fortement régulées (santé certifiée, banque, assurance). Les contraintes réglementaires (HDS, marquage CE dispositif médical, conformité ANSM, accords ARS) sortent de notre format 4 à 6 semaines à prix fixe. Faire ce type de projet correctement demande une expertise affaires réglementaires que nous n'avons pas, et un calendrier compatible avec les délais administratifs (8 à 18 mois pour une certification CE). Le mal-faire expose les utilisateurs finaux à des risques sanitaires inacceptables.

Si ton projet est purement santé/médical, oriente-toi vers des agences spécialisées en mobile santé ou des consultants en affaires réglementaires (Medical Device Regulation, ANSM). Cet article te donne le cadre pour bien les briefer dès le premier appel.

Si ton projet a un lien tangentiel avec la santé sans contrainte réglementaire (annuaire de prestataires sans données médicales, app bien-être pure sans claim médical, outil interne pour un cabinet, app de coordination administrative), il peut entrer dans notre périmètre.

Youssef Attia

À propos de l'auteur

Youssef Attia

Youssef Attia est le fondateur d'Inyka, studio spécialisé dans les applications mobiles React Native pour iOS et Android. Il accompagne les porteurs de projet du cadrage jusqu'à la publication sur les stores, avec un prix fixe annoncé avant signature.

À lire ensuite