Développer une application de santé en France
Fondateur de Dinno, agence de développement d'applications de santé
Révision réglementaire :
9 min de lecture
En bref
Quatre questions déterminent le coût et le calendrier d'une application de santé : traitez-vous des données de santé à caractère personnel (déclenche l'hébergement HDS), votre logiciel a-t-il une finalité médicale (déclenche le statut de dispositif médical et le marquage CE), devez-vous vous intégrer à l'écosystème français (Pro Santé Connect, INS, MSSanté, DMP) et visez-vous un remboursement (télésurveillance, PECAN, LPPR). Y répondre avant d'écrire la première ligne de code évite des reprises d'architecture qui se chiffrent en mois.
Un projet d’application de santé échoue rarement sur la technique. Il déraille sur des questions réglementaires posées trop tard : un hébergement à refaire six mois après le lancement, un statut de dispositif médical découvert quand le produit est déjà commercialisé, une intégration Pro Santé Connect ajoutée en catastrophe pour répondre à un appel d’offres.
Ces quatre questions se tranchent au cadrage, pas en cours de route. Cette page en donne la logique ; chaque dossier ci-dessous en détaille une.
1. Traitez-vous des données de santé à caractère personnel ?
C’est la question qui détermine votre architecture d’hébergement. Si votre service héberge, pour le compte de tiers, des données de santé recueillies à l’occasion d’activités de prévention, de diagnostic ou de soins, vous entrez dans le champ de la certification HDS.
En pratique, la réponse est presque toujours « oui » dès qu’un professionnel de santé ou un établissement utilise votre outil sur des patients identifiables. Elle est plus discutable pour une application grand public de bien-être — et c’est précisément là que se jouent les erreurs d’appréciation.
La bonne nouvelle : si l’obligation est identifiée au cadrage, elle ne coûte presque rien. Il s’agit de retenir un hébergeur déjà certifié plutôt qu’un hébergeur générique. Découverte après la mise en production, la même obligation impose une migration.
2. Votre logiciel a-t-il une finalité médicale ?
Le statut de dispositif médical ne dépend ni de la technologie employée, ni du fait que vous vendiez à des professionnels. Il dépend de la finalité que vous revendiquez. Un logiciel destiné au diagnostic, à la prévention, au contrôle, au traitement ou à l’atténuation d’une maladie relève du règlement (UE) 2017/745.
C’est la question la plus structurante des quatre, parce qu’elle emporte tout le reste : marquage CE, organisme notifié, système de management de la qualité, gestion des risques, surveillance après commercialisation. L’écart de budget entre un logiciel non-DM et un dispositif de classe IIa se compte en centaines de milliers d’euros.
C’est aussi celle où la tentation est la plus forte de s’auto-rassurer. Une formulation marketing suffit parfois à faire basculer un produit dans le champ du règlement.
3. Devez-vous vous intégrer à l’écosystème français ?
La France a construit un socle d’interopérabilité que la plupart des acheteurs publics et des établissements exigent désormais : identification des professionnels via Pro Santé Connect, identification des patients via l’INS, échange documentaire via MSSanté et le DMP, exigences de sécurité de la PGSSI-S, et référencement Ségur pour accéder aux financements.
Et ce ne sont pas des API ouvertes. L’accès à la plupart de ces services est conditionné à une autorisation préalable. Le CNDA, rattaché à l’Assurance Maladie, agrée les logiciels autorisés à utiliser ses téléservices — dont INSi — et délivre l’homologation permettant d’alimenter et de consulter le DMP. L’ANS, de son côté, instruit le raccordement à Pro Santé Connect, référence les opérateurs MSSanté et prononce le référencement Ségur.
Chacune de ces démarches suppose un dossier, des tests de conformité et un délai d’instruction qui ne dépend pas de vous. C’est le facteur qui fait le plus souvent déraper un calendrier : la charge de développement est modeste, l’attente ne l’est pas.
Ces briques ne sont donc pas des options techniques ajoutables en fin de projet — d’autant que l’INS conditionne la structure même de votre référentiel patient. Les intégrer au départ coûte une fraction de ce que coûte leur rattrapage, et les démarches d’autorisation se lancent en parallèle du développement, pas après.
4. Visez-vous un remboursement ?
Si votre modèle économique repose sur une prise en charge par l’Assurance maladie, les voies existent — télésurveillance médicale, prise en charge anticipée numérique, inscription à la LPPR — mais chacune impose ses propres exigences de preuve clinique et son propre calendrier. Elles se préparent en amont du développement, pas après.
Par où commencer
Les quatre dossiers ci-dessous suivent l’ordre dans lequel ces questions se posent réellement dans un projet.
- Interopérabilité & Ségur
Interopérabilité et Ségur : ce que votre application de santé doit implémenter
Pro Santé Connect, INS, MSSanté, DMP, PGSSI-S, référencement Ségur : le socle d'interopérabilité que votre application de santé doit intégrer en France, et dans quel ordre.
- Hébergement des données de santé (HDS)
Hébergement des données de santé (HDS) : ce que votre projet doit prévoir
Hébergement de données de santé : qui est soumis à l'obligation HDS, que couvre la certification, faut-il se certifier ou passer par un hébergeur certifié, et quel impact sur votre projet.
- Dispositif médical logiciel
Dispositif médical logiciel : le parcours réglementaire complet
Votre logiciel est-il un dispositif médical ? Qualification, règle 11, classes, marquage CE, organisme notifié, ISO 13485, IEC 62304 : le parcours complet pour un éditeur.
- Accès au marché & remboursement
Faire rembourser une solution numérique de santé : les voies possibles
Les voies de prise en charge d'une solution numérique de santé : droit commun LPPR et LATM, prise en charge anticipée PECAN, certificat de conformité ANS et rôle de la HAS.
Nos interventions
Cadrage réglementaire, conception et développement de votre application de santé.
-
Cadrage réglementaire d'un projet e-santé
Un cadrage écrit de votre projet de santé numérique : statut dispositif médical, obligation HDS, exigences d'interopérabilité et impact sur votre budget et votre calendrier.
-
Concevoir et développer votre application de santé
Conception et développement d'applications web et mobiles de santé, avec les contraintes d'hébergement HDS, d'interopérabilité et de dispositif médical intégrées dès la conception.
-
Mise en conformité d'un produit de santé déjà en service
Reprendre un produit de santé déjà en production pour le mettre en conformité : hébergement HDS, INS, Pro Santé Connect, référencement Ségur, exigences dispositif médical.
-
Plateformes de téléconsultation et de télésurveillance
Conception de plateformes de téléconsultation et de solutions de télésurveillance médicale : contraintes réglementaires, interopérabilité et accès au remboursement.
Questions fréquentes
Sources officielles
- Certification des hébergeurs de données de santé — Agence du Numérique en Santé
- Logiciels et applications mobiles en santé — ANSM
- Règlement (UE) 2017/745 relatif aux dispositifs médicaux — Union européenne
- Doctrine du numérique en santé — Agence du Numérique en Santé
Cadrage réglementaire
Faites cadrer votre application de santé par un expert e-santé
Statut réglementaire, obligations d'hébergement, exigences d'interopérabilité, impact sur le budget et le planning : nous vous remettons une synthèse écrite de votre situation.
Demander un cadrageÉdité par Dinno, agence de développement d'applications de santé.