Développer une application de santé en France

Cédric Millauriaux

Cédric Millauriaux

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.

Nos interventions

Cadrage réglementaire, conception et développement de votre application de santé.

Questions fréquentes

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é.