App Store Connect : nouvelle déclaration Apple sur les Dispositifs Médicaux – impact pour les éditeurs de santé
Apple demande désormais à certaines applications de déclarer dans App Store Connect si elles sont des dispositifs médicaux réglementés en UE/EEE, au Royaume-Uni ou aux États-Unis. Pour un éditeur de logiciel santé, ce n’est pas un simple réglage de fiche produit. C’est un point de visibilité publique qui met en regard votre promesse produit, votre finalité prévue et votre statut réel au regard du RDM.
Une nouvelle exigence Apple qui dépasse la simple conformité App Store
La nouveauté peut sembler administrative. En réalité, elle touche un sujet beaucoup plus sensible : la cohérence entre ce que votre application dit faire sur l’App Store et ce que vous êtes capable de justifier réglementairement.
Apple cible les apps disponibles dans l’UE/EEE, au Royaume-Uni ou aux États-Unis qui entrent dans certains critères, notamment lorsqu’elles sont classées en Health & Fitness ou Medical, ou lorsqu’elles déclarent un contenu médical ou de traitement fréquent dans le questionnaire d’âge.
Si l’éditeur déclare que l’application est un dispositif médical réglementé, Apple exige ensuite plusieurs informations qui seront affichées sur la fiche App Store.
Ce qu’Apple demande pour l’UE/EEE
Pour l’Union européenne, Apple demande notamment :
- le SRN du fabricant
- une URL vers les instructions d’utilisation
- un use statement, qui correspond en pratique à la finalité prévue
- des informations de sécurité issues de l’étiquetage
Ces informations deviennent visibles pour l’utilisateur final sur la page produit.
Apple précise aussi que l’exigence s’applique aux nouvelles apps concernées, puis aux apps existantes avec une échéance annoncée avant début 2027 pour rester en mesure de soumettre des mises à jour.
En UE, le vrai sujet n’est pas Apple : c’est la qualification RDM
Le point clé est simple : Apple ne qualifie pas votre logiciel à votre place.
Son mécanisme repose sur des indices de catalogue et de contenu. Le cadre européen, lui, repose d’abord sur la finalité prévue définie par le fabricant. C’est cette finalité qui détermine si un logiciel relève ou non du Règlement (UE) 2017/745.
Autrement dit, une app peut entrer dans le radar d’Apple parce qu’elle ressemble à une app santé, sans être nécessairement un dispositif médical. À l’inverse, une app réellement qualifiée comme MDSW ne peut pas être traitée comme une simple app bien-être sans créer un risque d’incohérence.
Le danger, pour l’éditeur, est là : une réponse trop rapide dans App Store Connect peut révéler des écarts entre votre marketing, votre notice, votre documentation technique et votre statut réglementaire réel.
Quand un logiciel devient un dispositif médical au sens du RDM
En contexte UE, un logiciel n’est pas un dispositif médical parce qu’il manipule des données de santé ou parce qu’il est utilisé dans un environnement clinique. Il devient un logiciel dispositif médical si sa finalité prévue entre dans le champ médical du RDM.
Le guide MDCG 2019-11 rappelle qu’un logiciel peut relever du RDM s’il est destiné, par exemple, à diagnostiquer, prévenir, surveiller, prédire, pronostiquer, traiter ou atténuer une maladie, ou à fournir des informations utilisées pour une décision médicale individuelle.
En revanche, des fonctions de stockage, d’archivage, de communication, de simple recherche, d’affichage non médical ou d’organisation administrative ne suffisent pas, à elles seules, à faire entrer un logiciel dans le champ du dispositif médical.
Avant de cliquer sur Yes ou No dans App Store Connect, la bonne question est donc la suivante : quelle est précisément la finalité prévue de notre logiciel sur le marché de l’Union ?
Pourquoi la déclaration Apple peut devenir un point de risque réglementaire
Cette nouvelle exigence Apple est utile, mais elle peut aussi devenir un révélateur de fragilité réglementaire.
D’abord, parce que répondre No n’est défendable que si l’application n’a réellement pas de finalité médicale réglementée en UE.
Ensuite, parce que répondre Yes suppose que plusieurs éléments sont déjà stabilisés : qualification, classification, stratégie de conformité, étiquetage, notice et cohérence documentaire.
Il faut aussi lire avec prudence certains repères évoqués par Apple, comme le marquage CE ou l’auto-certification. En pratique, pour de nombreux logiciels médicaux, la classification conduit à une classe nécessitant l’intervention d’un organisme notifié. L’auto-certification n’est donc pas un raccourci applicable à tous les logiciels de santé.
Autre point important : le SRN demandé par Apple n’est pas une preuve autonome de conformité. Il identifie un opérateur économique enregistré, mais ne remplace ni l’analyse de qualification, ni l’évaluation de conformité, ni la documentation technique.
Apple s’aligne partiellement sur les attentes UE
Le schéma Apple est globalement cohérent avec certaines briques du RDM.
Le use statement renvoie à la finalité prévue. L’IFU URL renvoie à la notice ou à l’eIFU. Les safety information renvoient aux avertissements, précautions et contre-indications. Le SRN contribue à l’identification réglementaire.
Mais cet affichage reste partiel au regard des attentes européennes applicables aux logiciels dispositifs médicaux mis à disposition via des plateformes.
Le guide MDCG 2025-4 va plus loin. Il recommande notamment de permettre l’accès à des informations comme l’identité complète du fabricant, l’identification claire du produit, le marquage applicable, le lien vers l’eIFU, l’UDI-DI et, selon les cas, le mandataire, le numéro d’organisme notifié, certains éléments de conformité juridique et les prérequis techniques d’utilisation.
La conclusion est claire : remplir les champs Apple ne suffit pas à démontrer la conformité au RDM.
Ce que les éditeurs de logiciels santé devraient faire dès maintenant
La bonne approche consiste à traiter la fiche App Store comme un point de sortie réglementaire, et non comme un simple support marketing.
Avant publication ou mise à jour, il est prudent de valider au minimum :
- la qualification du logiciel
- sa classification
- la voie d’évaluation de conformité applicable
- le statut CE réellement soutenable
- le SRN utilisé
- une version courte de la finalité prévue strictement alignée sur la documentation réglementaire
- une URL d’eIFU maîtrisée et pérenne
- les informations de sécurité cohérentes avec l’étiquetage
- les pays et langues visés
Concrètement, la fiche App Store ne devrait plus être validée par le seul marketing dès qu’un logiciel touche à un usage médical. Le réglementaire, la qualité et, selon le produit, le médical ou le clinique doivent être impliqués.