Vous avez un projet d’application santé connectée : un dispositif de suivi de patients, un capteur médical, une app de télésurveillance. Et vous découvrez rapidement que la santé ne se développe pas comme un autre secteur : règlement européen sur les dispositifs médicaux (MDR), hébergement certifié HDS, RGPD renforcé. Obtenir une vision claire des obligations et de leur impact réel sur un projet relève du parcours du combattant, entre les cabinets juridiques qui parlent réglementation sans parler produit, et les agences qui parlent produit sans parler réglementation.
Chez Playmoweb, nous développons depuis plus de 12 ans des applications mobiles et des produits IoT pour le secteur médical : capteurs connectés, dispositifs de suivi à domicile, applications de télésuivi. La conformité fait partie de nos projets au même titre que le code. Ce guide vous donne les repères concrets : quand votre application devient un dispositif médical, ce que l’hébergement HDS implique, et comment intégrer la conformité dans votre projet sans la subir.
Sommaire
C’est la première question à trancher, avant toute ligne de code. Le règlement européen MDR (2017/745) qualifie de dispositif médical tout logiciel destiné à une finalité médicale : diagnostic, surveillance d’un paramètre physiologique, aide à la décision thérapeutique. On parle alors de SaMD (Software as a Medical Device).
La règle 11 de l’annexe VIII du MDR classe les logiciels selon les conséquences des décisions qu’ils influencent. En pratique, la grande majorité des SaMD tombent en classe IIa ou IIb : dès qu’un logiciel interprète des données pour une finalité médicale, il dépasse le simple stockage et sort de la classe I.
| Classe | Critère | Exemple | Procédure |
|---|---|---|---|
| I | Stockage, archivage, communication de données | Carnet de santé numérique simple | Auto-certification, quelques mois |
| IIa | Finalité diagnostique ou thérapeutique sans risque grave | App de suivi de paramètres avec alertes | Organisme notifié (audit ISO 13485) |
| IIb | Décisions pouvant causer une détérioration grave | Aide au dosage de traitement | Organisme notifié, exigences renforcées |
| III | Décisions pouvant causer la mort ou un dommage irréversible | Algorithme de diagnostic critique | Organisme notifié, délai moyen supérieur à 18 mois |
À l’inverse, une application de bien-être (activité physique, sommeil, nutrition) sans finalité médicale revendiquée échappe au MDR. La frontière se joue souvent sur la formulation de votre promesse produit : « suivez votre sommeil » et « détectez l’apnée du sommeil » ne relèvent pas du même cadre réglementaire. C’est un arbitrage stratégique à poser dès la phase de cadrage, car il conditionne le calendrier, le niveau d’exigence documentaire et le discours commercial.
Deuxième pilier : l’hébergement. L’article L.1111-8 du Code de la santé publique impose que toute donnée de santé à caractère personnel hébergée pour le compte d’un tiers le soit chez un hébergeur certifié HDS (Hébergeur de Données de Santé). Héberger des données de santé sans cette certification est une infraction pénale.
La bonne nouvelle : vous n’avez pas à vous certifier vous-même. Plus de 130 hébergeurs sont certifiés en 2026, dont des acteurs français comme OVHcloud et Scaleway (certifié HDS depuis juillet 2024), aux côtés des hyperscalers américains. Chez Playmoweb, nous privilégions les hébergeurs français certifiés HDS : ils combinent la conformité santé et la souveraineté des données, un critère de plus en plus décisif dans les appels d’offres hospitaliers et médico-sociaux.
Attention toutefois : la certification HDS couvre six activités distinctes, du datacenter physique à l’infogérance applicative. Vérifiez que votre hébergeur est certifié pour les activités qui correspondent réellement à votre architecture, pas seulement pour la mise à disposition de serveurs.
Les données de santé sont des données sensibles au sens du RGPD. Concrètement, cela ajoute trois exigences à votre projet. Une analyse d’impact (AIPD) est obligatoire avant la mise en production : c’est un livrable à part entière, à intégrer au planning. Le consentement ou une base légale spécifique doit être documenté pour chaque traitement. Et la minimisation s’applique strictement : ne collecter que les données nécessaires à la finalité, ce qui influence directement la conception de votre architecture et de vos capteurs.
Notre conviction, forgée sur le terrain : la conformité RGPD santé se conçoit dans l’architecture, pas dans une annexe juridique. Le chiffrement de bout en bout, la pseudonymisation, la séparation des données d’identification et des données médicales sont des choix techniques qui se prennent au cadrage. Les rattraper après coup, sur un produit en production, est un chantier lourd qui immobilise les équipes et retarde la feuille de route.
L’erreur classique consiste à traiter la conformité comme une étape finale, entre la recette et la mise sur le marché. Sur un projet santé, elle est une composante du projet dès le premier jour, avec ses propres livrables et son propre calendrier.
| Chantier | Livrables clés | Quand le lancer |
|---|---|---|
| Qualification et classification MDR | Analyse de la finalité, choix de classe, stratégie réglementaire | Au cadrage, avant l’architecture |
| Documentation technique | Analyse de risques ISO 14971, évaluation clinique, système qualité ISO 13485 | En parallèle du développement |
| Hébergement et sécurité | Choix HDS, architecture de chiffrement, politique d’accès | À la conception de l’architecture |
| RGPD | AIPD, registre des traitements, parcours de consentement | Avant la mise en production |
| Surveillance post-marché | Processus de matériovigilance, rapports périodiques | Avant le lancement commercial |
Deux repères de calendrier à garder en tête. Pour un dispositif de classe I, l’auto-certification se boucle en quelques mois ; pour les classes supérieures, le passage par un organisme notifié allonge sensiblement les délais, jusqu’à plus de 18 mois en moyenne pour une classe III. Ces délais se pilotent : plus la documentation avance en parallèle du développement, moins l’attente finale est longue. C’est exactement le type de trajectoire que nous construisons en phase de cadrage, et qu’un audit technique permet d’objectiver sur un produit existant.
Si votre application santé embarque de l’IA (détection d’anomalies, aide au diagnostic, prédiction), un troisième texte entre en jeu : l’AI Act. Les systèmes d’IA à usage médical sont classés à haut risque, et les obligations correspondantes s’appliquent à partir d’août 2026 : qualité de conception, traçabilité, supervision humaine, documentation technique comparable à celle des dispositifs médicaux.
La logique est cohérente avec le MDR : si vous structurez votre documentation et votre gestion des risques pour l’un, vous préparez l’autre. C’est aussi un argument pour les architectures d’IA embarquée : traiter les données de santé en local sur le dispositif réduit à la fois la surface réglementaire et les risques de fuite.
En plus de 12 ans de projets médicaux, voici les erreurs que nous voyons le plus souvent :
Ces questions se traitent en phase de cadrage : c’est précisément le rôle de notre accompagnement, du choix d’architecture à la feuille de route réglementaire, en passant par le développement du capteur à l’application. Découvrez notre approche des projets IoT santé.
Vous avez un projet de santé connectée ? Contactez-nous pour un échange gratuit et sans engagement. 👉 playmoweb.com/nous-contacter