Le Data Act pour les dispositifs médicaux connectés

Le règlement européen sur les données, en abrégé Data Act, est en vigueur depuis le 11 janvier 2024 et s’applique depuis le 12 septembre 2025. Depuis lors, les utilisateurs de produits connectés peuvent exiger que le détenteur de données leur fournisse les données d’utilisation ou les transmette à un tiers désigné – y compris pour des appareils déjà installés auparavant. Il doit en outre être clair, avant la conclusion du contrat, quelles données un produit génère et comment y accéder.

Le 12 septembre 2026 marque la deuxième étape : les produits connectés et services connexes mis sur le marché pour la première fois après cette date doivent permettre l’accès dès leur conception (Access by Design). Données et métadonnées doivent être disponibles par défaut, de manière simple, sécurisée et gratuite, dans un format structuré, couramment utilisé et lisible par machine – et, lorsque c’est pertinent et techniquement possible, directement pour l’utilisateur. Selon la lecture de la Commission, c’est chaque appareil qui compte, et non le type d’appareil : même un modèle marqué CE depuis des années est concerné dès qu’un exemplaire est mis sur le marché pour la première fois après l’échéance.

Les dispositifs médicaux sont expressément couverts

Le préambule du règlement cite expressément les dispositifs médicaux et, selon la FAQ de la Commission, le Data Act s’applique aussi aux produits soumis à leur propre évaluation de la conformité. Avant sa mise sur le marché, un dispositif médical doit donc respecter non seulement le MDR, mais aussi le règlement sur les données.

Qui est exempté

Les microentreprises et petites entreprises sont exemptées des obligations d’accès, à condition de ne pas être liées à une entreprise plus grande ni associées à celle-ci comme partenaires, et de ne pas fabriquer ou développer pour le compte d’autrui. Les moyennes entreprises ne bénéficient que d’un délai de grâce d’un an : durant la première année après avoir atteint cette taille, et pour chaque produit durant la première année suivant sa mise sur le marché. Indépendamment de cela, les droits d’accès de l’établissement ne peuvent pas être écartés par contrat à son détriment ; de telles clauses ne le lient pas.

Pourquoi c’est une question de sécurité

Chaque interface supplémentaire agrandit la surface d’attaque. Dans l’étude ManiMed du BSI de 2020, plus de 150 vulnérabilités ont été signalées pour dix dispositifs médicaux connectés de cinq catégories – souvent dans l’infrastructure associée, rarement dans le dispositif médical lui-même. C’est précisément là que naissent les portails, interfaces de programmation et stockages cloud destinés à l’accès aux données. En Allemagne, les manquements aux obligations de conception ou de mise à disposition sont passibles d’amendes pouvant atteindre 500 000 euros ; l’autorité compétente est la Bundesnetzagentur depuis le 30 mai 2026.

Deux subtilités comptent. D’une part, les sous-traitants au sens du RGPD ne sont pas des détenteurs de données – cela vaut pour les fournisseurs cloud comme pour le fabricant, dans la mesure où il traite les données des patients exclusivement sur instruction de l’établissement. D’autre part, le fabricant ne peut utiliser les données non personnelles des appareils à ses propres fins, comme l’amélioration du produit, que sur la base d’un contrat avec l’établissement ; dans quelle mesure cela concerne les analyses de surveillance du marché exigées par la loi est à clarifier au cas par cas.

Quelles données sont couvertes

Sont couvertes les données brutes et prétraitées disponibles sans effort disproportionné, avec leurs métadonnées ainsi que les messages d’état et d’erreur. Ce qui ne naît que d’investissements supplémentaires, comme des algorithmes propriétaires complexes, n’en relève en principe pas, sauf convention contraire – une exception qui découle du seul préambule du règlement et laisse des zones grises. La pseudonymisation ou le chiffrement ne font pas de données couvertes des données dérivées. Exploiter des failles dans la protection de l’appareil n’est pas une voie licite pour accéder aux données.

Le modèle de référence comprend quatre briques. Un appareil de diagnostic par imagerie fournit des images et des valeurs de mesure. Un logiciel de planification en déduit des paramètres thérapeutiques que le personnel médical vérifie et valide. Un appareil de thérapie exécute le plan validé et en enregistre le déroulement. S’y ajoute un cloud du fabricant, avec un espace client distinct pour chaque établissement, une gestion des utilisateurs, la distribution des mises à jour et un portail web doté d’une interface de programmation (Application Programming Interface, API).

Deux principes de conception sont répandus dans ce type de système : la connexion au cloud est établie depuis l’établissement, si bien qu’aucun accès entrant depuis Internet n’est nécessaire, et le cloud est découplé de telle sorte qu’il ne peut pas intervenir dans une thérapie en cours. Dans ce modèle, la porte d’accès aux données au sens du Data Act comprend :

• le portail web, pour consulter et télécharger les données
• l’API, pour les requêtes automatisées des systèmes de l’établissement
• des chemins d’export pour les volumes de données importants
• une fonction de délégation par laquelle l’établissement désigne des tiers comme destinataires
• le cas échéant, un accès local sur l’appareil ou sur une passerelle

Accès direct, où l’établissement récupère lui-même les données, ou accès indirect, où le fabricant les fournit sur demande : ce choix de conception a des conséquences pour la sécurité. L’accès direct exige une interface joignable en permanence et solidement sécurisée, l’accès indirect reporte les risques sur des processus manuels.

Le service cloud est-il lui-même un dispositif médical ?

Tout dépend de sa destination. Un service qui se contente de stocker et de relayer des données n’est généralement pas un logiciel dispositif médical ; un service qui procède à une évaluation médicale ou renvoie des résultats vers la planification l’est souvent. Un logiciel compagnon sans statut de dispositif médical, par exemple une application installable de maintenance ou d’export, peut selon les cas relever du Cyber Resilience Act ; les services purement web sans produit associé n’en relèvent en revanche pas.

La réserve de sécurité

L’établissement et le fabricant peuvent restreindre ou exclure par contrat l’accès aux données, leur utilisation ou leur diffusion ultérieure lorsque le traitement des données pourrait compromettre des exigences de sécurité fixées par la loi pour le produit connecté et avoir ainsi des effets négatifs graves sur la santé, la sûreté ou la sécurité de personnes. Pour les dispositifs médicaux, ce sont avant tout les exigences de cybersécurité du MDR qui entrent en ligne de compte – une lecture évidente, mais qui n’est pas expressément prévue. Le projet de clauses contractuelles types non contraignantes de la Commission, disponible pour l’heure uniquement en anglais, prévoit à titre optionnel de nommer dans le contrat l’exigence de sécurité concernée.

Si le fabricant refuse la transmission, il doit en informer l’autorité compétente – en Allemagne la Bundesnetzagentur, au moyen des formulaires qu’elle met à disposition. L’établissement peut y déposer une réclamation ou saisir un organe de règlement des litiges. Dans le modèle de référence, on pourrait aisément justifier que l’appareil de thérapie ne réponde à aucune requête en temps réel pendant un traitement en cours et que les configurations critiques pour la sécurité ne quittent pas le système. Il serait en revanche difficile de justifier qu’on refuse à l’établissement la consultation des journaux d’erreurs et d’événements. Quant à un accès en écriture à la planification ou à la commande, le Data Act ne l’exige de toute façon pas.

Les secrets d’affaires en trois niveaux

• Identifier et convenir : le fabricant identifie les secrets d’affaires, y compris dans les métadonnées, et fixe avec le destinataire des mesures de protection – par exemple des accords de confidentialité, des protocoles d’accès stricts, des normes ou des codes de conduite.
• Retenir ou suspendre : faute d’accord, si les mesures convenues ne sont pas mises en œuvre ou si la confidentialité est compromise, le fabricant peut retenir ou suspendre la transmission.
• Refuser : seulement dans des circonstances exceptionnelles et au cas par cas, s’il démontre sur la base de critères objectifs qu’il subirait très probablement un préjudice économique grave malgré les mesures de protection.

Aux deuxième et troisième niveaux, la décision doit être motivée par écrit et notifiée à l’autorité. Des secrets divulgués sans protection risquent en outre de perdre leur statut au regard de la loi allemande sur la protection des secrets d’affaires. Le modèle de menaces et le dossier de gestion des risques fournissent des justifications solides pour les deux « freins à main ».

Ce que changerait le Digital Omnibus

La proposition de modification « Digital Omnibus » présentée par la Commission en novembre 2025 créerait, pour la protection des secrets, un motif de refus supplémentaire en cas de risque élevé de fuite vers des pays tiers offrant une protection moindre ; elle laisse la réserve de sécurité inchangée. Elle n’est pas adoptée : le Parlement ne s’est pas prononcé et, au Conseil, aucun mandat de négociation n’avait été arrêté à la mi-octobre 2026 – la protection des secrets figurant justement parmi les points controversés.

RGPD et secret médical

Dès que des données à caractère personnel sont concernées, le droit de la protection des données prime ; le Data Act ne crée pas de base juridique propre. Si l’établissement est l’utilisateur et le patient la personne concernée, la mise à disposition requiert une base juridique au titre du RGPD et, pour les données de santé, en plus l’une des exceptions prévues pour les catégories particulières. L’établissement reste en règle générale responsable du traitement, doit assurer la protection des données dès la conception et a le plus souvent besoin d’une analyse d’impact relative à la protection des données pour les systèmes thérapeutiques connectés.

S’y ajoute le secret médical, pénalement sanctionné, que le Data Act ne lève pas. Sauf levée du secret par le patient ou autorisation légale, les données des patients ne peuvent être transmises à des prestataires que dans la mesure nécessaire, et uniquement à ceux qui agissent pour le compte de l’établissement et se sont engagés à la confidentialité. Selon notre appréciation, les finalités d’analyse propres au fabricant n’en relèvent pas.

L’IEC 81001-5-1 exige pour les logiciels de santé un modèle de menaces propre au produit, sans imposer de méthode. Le point de départ est un diagramme de flux de données de l’ensemble du système avec ses frontières de confiance (trust boundaries). Le Data Act y ajoute une frontière avec des destinataires externes choisis par l’établissement. La frontière qui appelle la protection la plus forte reste celle qui entoure l’appareil de thérapie. Le guide MDCG 2019-16 attend de toute façon, pour les produits connectés, une vue d’ensemble complète des flux de données réseau.

La méthode STRIDE examine chaque flux de données au regard de six catégories de menaces : usurpation d’identité (Spoofing), falsification (Tampering), répudiation (Repudiation), divulgation d’informations (Information Disclosure), déni de service (Denial of Service) et élévation de privilèges (Elevation of Privilege). En complément, un arbre d’attaque décompose un objectif d’attaquant tel que « des données de planification manipulées parviennent à l’appareil de thérapie » en étapes intermédiaires.

Évaluer et reporter dans le dossier de gestion des risques

Pour les systèmes dont le cloud relie de nombreux établissements, le guide de cybersécurité de l’autorité américaine Food and Drug Administration (FDA) de février 2026 recommande une vue architecturale dédiée aux préjudices touchant simultanément de nombreux patients ; il classe les risques de sécurité selon leur exploitabilité plutôt que selon une probabilité difficile à estimer. Les menaces pouvant entraîner une situation dangereuse sont consignées comme causes dans le dossier de gestion des risques selon ISO 14971. Lorsque des interfaces ou de nouveaux types de destinataires s’ajoutent, le modèle doit être mis à jour.

Le MDR n’emploie pas le terme de test d’intrusion. Le guide MDCG 2019-16 désigne toutefois les tests comme le moyen le plus important de vérifier la sécurité et cite expressément les tests des fonctions de sécurité, le fuzzing avec des entrées erronées, les analyses de vulnérabilités et les tests d’intrusion. L’IEC 81001-5-1 exige que les testeurs soient suffisamment indépendants. Le périmètre du test découle des surfaces d’attaque, des limites du système et des scénarios du modèle de menaces.

Points de contrôle prioritaires à la porte d’accès

• Cloisonnement entre clients : avec des comptes de test pour deux établissements, l’équipe vérifie si des identifiants modifiés permettent de récupérer les enregistrements d’un autre client – l’absence d’autorisation au niveau des objets occupe la première place de l’OWASP API Security Top 10 de 2023.
• Authentification et sessions dans le portail et l’API, y compris durée de validité, liaison et réutilisabilité des jetons d’accès.
• Droits fonctionnels : un accès en lecture peut-il être étendu à des fonctions d’écriture ou de commande ?
• Délégation à des tiers : un attaquant peut-il s’inscrire comme destinataire ou élargir le périmètre de données validé ?
• Chemins d’export : les paquets de données sont-ils complets et correctement pseudonymisés, et les secrets d’affaires y sont-ils marqués ?
• Traitement des entrées : comment l’API et les fonctions d’import réagissent-elles à des formats erronés ou préparés de manière malveillante (fuzzing) ?
• Journalisation : validations et requêtes sont-elles enregistrées de manière complète et infalsifiable ?
• Limites de charge et découplage : la planification et le fonctionnement des appareils restent-ils disponibles en cas de requêtes massives ?

Conditions-cadres et rapport

Le test est mené en boîte grise (grey box), avec une connaissance partielle du système, des jeux de données synthétiques et dans un environnement identique à la production – jamais sur un appareil en service auprès de patients. Comme l’attend la FDA, le rapport indique l’indépendance, le périmètre, la période, la méthodologie et les résultats, et justifie les vulnérabilités restées ouvertes. Le classement se fait selon l’exploitabilité et l’impact possible sur les patients ; la correction suit le processus d’actions correctives et préventives (Corrective and Preventive Action, CAPA), avec un nouveau test et un archivage dans la documentation technique et la surveillance après commercialisation (SAC). Répété régulièrement, le test démontre aussi l’efficacité des mesures de protection qu’exigent le RGPD et la loi BSI.

À la porte d’accès aux données se croisent le Data Act, le MDR, le RGPD, la loi BSI et la loi allemande sur la protection des secrets d’affaires. Si affaires réglementaires, sécurité de l’information, protection des données et service juridique tiennent des catalogues et des échelles de risque séparés, les contradictions apparaissent au plus tard lors de l’audit ou de l’incident. Le système de management de la qualité selon ISO 13485, qui pilote déjà fournisseurs, risques, vigilance et modifications, s’impose comme point d’ancrage. Comme l’ISO 13485 ne suit pas la structure harmonisée des autres normes ISO de systèmes de management, ISO/IEC 27001, ISO/IEC 27701 et, le cas échéant, ISO/IEC 42001 y sont rattachées au moyen d’une table de correspondance.

Coordonner les circuits de notification parallèles

Un incident à la porte d’accès peut déclencher simultanément plusieurs obligations de notification, que coordonne une équipe de réponse aux incidents de sécurité produit (Product Security Incident Response Team, PSIRT) : au titre de la loi BSI, 24 heures, 72 heures et un mois auprès du guichet commun de notification du BSI et de l’Office fédéral de la protection civile (BBK) ; au titre du RGPD, 72 heures auprès de l’autorité de contrôle et, en tant que sous-traitant, sans délai auprès de l’établissement ; au titre du MDR, 2, 10 ou 15 jours en cas d’incident grave. Si le fabricant suspend ensuite des transmissions de données, il doit en informer la Bundesnetzagentur ; pour les logiciels compagnons, des notifications au titre du Cyber Resilience Act peuvent s’y ajouter.

Selon la loi BSI, la direction répond de la mise en œuvre et de la surveillance des mesures de sécurité. La personne chargée de veiller au respect de la réglementation, imposée par le MDR (Person Responsible for Regulatory Compliance, PRRC), n’assume pas le rôle de responsable de la sécurité des systèmes d’information (RSSI) ni celui de délégué à la protection des données ; une fonction dédiée à la sécurité des produits (Product Security) a fait ses preuves comme trait d’union. Si un établissement désigne par exemple un service d’IA comme destinataire, on peut ainsi clarifier en une seule fois quelles données circulent, sur quelle base juridique et contractuelle, avec quel risque résiduel et quelle preuve.

1. 1
   Déterminer si l’on est concerné

   Recenser les produits et services connectés, vérifier les exemptions applicables aux PME et identifier les appareils mis sur le marché pour la première fois après le 12 septembre 2026.

2. 2
   Établir le catalogue de données

   Recenser toutes les données disponibles du produit et du service et les classer en données à fournir, dérivées, personnelles ou à protéger au titre du secret.

3. 3
   Remplir les obligations d’information

   Compléter offres, contrats et notice d’utilisation de sorte que la nature, le volume, le format et le mode d’accès des données soient clairs avant la conclusion du contrat.

4. 4
   Préparer les contrats

   Rédiger des contrats d’utilisation des données pour les analyses propres ainsi que des clauses sur la réserve de sécurité et la protection des secrets ; le projet de clauses contractuelles types sert d’orientation.

5. 5
   Concevoir la porte d’accès

   Définir la voie d’accès, séparer plan de données et plan de commande, spécifier le cloisonnement entre clients, la délégation et la journalisation comme exigences de sécurité.

6. 6
   Mettre à jour le modèle de menaces

   Analyser avec STRIDE les nouvelles frontières de confiance et les nouveaux flux de données, reporter les causes pertinentes pour la sécurité dans le dossier de gestion des risques et documenter la justification des « freins à main ».

7. 7
   Tester et prouver

   Réaliser un test d’intrusion axé sur l’autorisation, la délégation et les chemins d’export ; clore et documenter les constats via le processus CAPA.

8. 8
   Coordonner modification et notifications

   Aborder tôt l’interface avec l’organisme notifié et s’entraîner, lors d’un exercice de simulation, aux circuits de notification vers la Bundesnetzagentur, le BSI, l’autorité de protection des données et l’autorité de vigilance.

Cette page reflète l’état d’octobre 2026. Elle ne remplace pas un conseil juridique ; les questions d’interprétation, notamment la délimitation des données dérivées et le traitement des dispositifs hérités, doivent être clarifiées au cas par cas.