Applications de santé mobile : sécurité, conformité et adoption

Les applications de santé se lancent vite. Une équipe de quelques personnes peut publier en un trimestre un outil de suivi de traitement, de téléconsultation ou d’autosurveillance. Elles s’abandonnent tout aussi vite : beaucoup ne sont plus ouvertes quelques semaines après leur installation. Entre ces deux moments, trois sujets décident du sort d’un projet de santé mobile. Le statut réglementaire, souvent découvert trop tard. La sécurité du téléphone, qui n’est pas celle d’un poste de travail. Et l’adoption, qu’on finance rarement autant que le développement.

Ce guide s’adresse aux ministères, hôpitaux, réseaux de soins et organismes d’assurance maladie qui envisagent de commander, de recommander ou de financer une application.

Première décision : dispositif médical ou non ?

Cette question détermine le calendrier, le budget et la responsabilité du projet. Dans l’Union européenne, un logiciel est un dispositif médical lorsque son fabricant le destine à une finalité médicale : diagnostiquer, prévenir, surveiller, prédire, traiter ou atténuer une maladie. Le règlement (UE) 2017/745, applicable depuis mai 2021, a durci la classification des logiciels : sa règle 11 place en classe IIa au minimum ceux qui fournissent des informations utilisées pour prendre des décisions diagnostiques ou thérapeutiques, ce qui impose l’intervention d’un organisme notifié.

• Finalité revendiquéece que dit la notice, le site, la boutique
• Qualificationdispositif médical ou non, selon le guide MDCG 2019-11
• Classe de risquerègle 11 pour les logiciels
• Évaluationautocertification ou organisme notifié
• Surveillanceaprès mise sur le marché, à chaque version

Le piège classique est la dérive de finalité. Une application lancée comme simple carnet de suivi se voit ajouter une alerte (« votre glycémie est trop élevée, consultez »), puis une recommandation de dose. Chaque ajout peut faire basculer le produit dans une autre catégorie. La qualification doit donc être revue à chaque évolution fonctionnelle, et pas seulement au lancement.

Hors du dispositif médical, le cadre n’est pas vide. Le règlement (UE) 2025/327 sur l’espace européen des données de santé, entré en vigueur en mars 2025, prévoit un étiquetage des applications de bien-être qui revendiquent l’interopérabilité avec les dossiers médicaux électroniques, selon un calendrier échelonné. La norme ISO/IEC 82304-2 (2021) propose par ailleurs un référentiel de qualité et de fiabilité pour les applications de santé et de bien-être, utile pour rédiger un cahier des charges ou évaluer une offre.

Le téléphone, un environnement hostile

Une application hospitalière tourne sur des postes gérés, dans un réseau surveillé. Une application de santé mobile tourne sur l’appareil personnel du patient : partagé avec un enfant, rarement mis à jour, parfois perdu dans un taxi. La sécurité doit être pensée pour ces conditions réelles.

Le référentiel de vérification de la sécurité des applications mobiles de l’OWASP (MASVS), accompagné de son guide de test, fournit une base reconnue pour formuler les exigences et les contrôler. Pour un décideur, cinq points méritent d’être exigés explicitement :

• Aucune donnée de santé dans les sauvegardes non chiffrées, les journaux, les notifications affichées sur l’écran verrouillé ni les captures du sélecteur d’applications.
• Un stockage local réduit au strict nécessaire, chiffré par les mécanismes du système d’exploitation, avec expiration ou effacement à distance.
• Une authentification adaptée au risque : code ou biométrie de l’appareil pour consulter, authentification renforcée pour partager ou modifier.
• Des échanges uniquement chiffrés avec le serveur, et des interfaces de programmation qui contrôlent les droits à chaque requête, pas seulement à la connexion.
• Aucune bibliothèque tierce de publicité ou de mesure d’audience qui transmettrait des données d’usage à des tiers.

Le dernier point est le plus souvent oublié. Les kits de développement gratuits, intégrés pour mesurer l’usage ou gérer les plantages, envoient parfois des informations qui, dans une application de santé, révèlent à elles seules une pathologie : le simple fait d’ouvrir une application de suivi de traitement antirétroviral est une donnée sensible.

Les données de santé, une catégorie à part

Le RGPD range les données de santé parmi les catégories particulières (article 9) : leur traitement est interdit sauf exception prévue par le texte, comme le consentement explicite, la prise en charge sanitaire ou un motif d’intérêt public dans le domaine de la santé. Trois conséquences pratiques s’imposent.

Choisir la base légale avant d’écrire le code. Le consentement est souvent retenu par réflexe, alors qu’il est fragile : il doit être libre, retirable à tout moment, et son retrait doit être techniquement possible. Pour une application prescrite dans un parcours de soins, une autre base peut être plus solide. Ce choix détermine les écrans, les textes et la gestion des droits.

Héberger au bon endroit. Plusieurs pays encadrent l’hébergement des données de santé ; en France, il doit être confié à un hébergeur certifié. Ailleurs, la réglementation nationale peut imposer une localisation. La question se pose dès le choix de l’architecture, pas au moment de la mise en production.

Mener l’analyse d’impact. Une application qui traite des données de santé à grande échelle, ou qui suit des personnes vulnérables, appelle presque toujours une analyse d’impact relative à la protection des données. Bien conduite, elle sert aussi de document de conception.

L’adoption : la variable que l’on finance le moins

Une application sûre et conforme que personne n’utilise ne protège personne. Les projets qui durent partagent quelques caractéristiques.

Elles sont prescrites. Une application recommandée par le soignant, dans le cadre d’un parcours, est beaucoup plus utilisée qu’une application découverte seule dans une boutique. Plusieurs pays ont tiré cette leçon en organisant un circuit d’évaluation et de prise en charge : l’Allemagne permet ainsi, depuis 2020, la prescription et le remboursement d’applications évaluées et inscrites dans un répertoire public.

Elles s’insèrent dans le travail des soignants. Si les données saisies par le patient n’apparaissent pas dans le dossier que consulte le médecin, il ne les regardera pas, et le patient cessera de les saisir. L’interopérabilité avec le système d’information de santé, par des standards comme HL7 FHIR, n’est pas un raffinement : c’est une condition d’usage.

Elles sont conçues pour leurs vrais utilisateurs. Personnes âgées, malvoyantes, peu à l’aise avec l’écrit, équipées de téléphones d’entrée de gamme ou d’un réseau intermittent. Le respect des règles d’accessibilité (WCAG), un fonctionnement hors connexion et, dans certains contextes, un canal complémentaire par SMS ou serveur vocal élargissent considérablement le public atteint. L’Organisation mondiale de la santé a d’ailleurs consacré une part de ses recommandations sur les interventions numériques en santé, publiées en 2019, aux communications ciblées vers les patients.

Avant de signer : la grille du décideur

Pour un financeur ou un établissement qui commande une application, la décision peut se résumer à quatre questions, à poser par écrit au porteur du projet. Quelle est la finalité revendiquée, et quelle qualification réglementaire en découle ? Où sont les données, sur quelle base légale, et que se passe-t-il quand un téléphone est perdu ? Comment les données du patient arrivent-elles dans le dossier du soignant ? Qui a été associé à la conception, et comment l’usage sera-t-il mesuré après six mois ?

Une réponse floue à l’une de ces questions est un signal d’arrêt, ou au moins de cadrage complémentaire. C’est la démarche de notre expertise santé numérique : partir du parcours de soins et des données qui doivent circuler, avant de choisir les outils. Notre plateforme Betz répond pour sa part à la question de la circulation du dossier patient entre établissements, à laquelle une application mobile doit pouvoir se raccorder.

Questions fréquentes

Comment savoir si mon application est un dispositif médical ?

Tout dépend de la finalité revendiquée par le fabricant. Un logiciel destiné à diagnostiquer, prévenir, surveiller, prédire ou traiter une maladie relève du règlement (UE) 2017/745 sur les dispositifs médicaux. Une application de bien-être général ou de prise de rendez-vous n'en relève pas. Le guide MDCG 2019-11 de la Commission européenne détaille la démarche de qualification ; en cas de doute, un avis réglementaire écrit vaut mieux qu'une hypothèse.

Une application de santé doit-elle stocker les données sur le téléphone ?

Le moins possible. Les données strictement nécessaires au fonctionnement hors connexion peuvent y rester, chiffrées et protégées par les mécanismes du système d'exploitation ; le reste a vocation à être conservé chez un hébergeur adapté aux données de santé. Il faut aussi prévoir l'effacement à distance ou l'expiration des données en cas de perte de l'appareil.

Peut-on utiliser une application grand public pour échanger avec des patients ?

C'est déconseillé pour des données de santé : ces outils ne sont pas conçus pour leur hébergement, la traçabilité des accès ou la gestion du consentement, et les échanges échappent au dossier du patient. Une messagerie sécurisée intégrée au système d'information de santé est préférable.