EHDS et Cyber Resilience Act : quelles exigences pour les éditeurs de logiciels de santé ?

Par Olivier Berton, fondateur de CyberSanté AI. Mis à jour le 28 septembre 2026.

Pour un éditeur de logiciels de santé, la conformité se construit à plusieurs niveaux : la sécurité du produit, l'interopérabilité des données, la traçabilité des accès et, lorsqu'il assure aussi l'hébergement, la sécurité de l'exploitation. Le CRA et l'EHDS organisent une partie de ces exigences. Leur articulation permet de mutualiser certains travaux, mais ne rend pas les deux règlements interchangeables.

Cette analyse s'adresse principalement aux éditeurs, à leurs RSSI et aux responsables produit et conformité. Elle explique comment qualifier une offre, préparer sa documentation technique et réutiliser les acquis ISO 27001 et HDS. Les établissements acheteurs y trouveront aussi des questions à poser à leurs fournisseurs ; leurs obligations propres ne sont pas examinées dans leur ensemble.

À retenir

• CRA : sécuriser le produit et traiter ses vulnérabilités. EHDS : permettre l'accès et l'échange des données de santé, avec des exigences propres aux systèmes de dossier médical électronique.
• Un logiciel peut relever des deux règlements. Une procédure et une documentation communes ne suppriment pas les exigences de chacun.
• Le statut de dispositif médical, les fonctions du logiciel et son mode de fourniture doivent être examinés ensemble. Un nom commercial ou une interface web ne suffisent pas à déterminer le régime applicable.
• ISO 27001 et HDS constituent des acquis utiles. Ils ne remplacent pas la démonstration de conformité du produit.
• Les échéances sont distinctes : signalements CRA depuis septembre 2026, obligations générales CRA en décembre 2027, puis principales échéances DME de l'EHDS en 2029 et 2031.

Quatre textes, des objets différents

Texte	Objet principal	Question à poser
NIS2 — directive (UE) 2022/2555	Sécurité des organisations concernées, gestion des risques et signalement des incidents.	Quelles activités de l'organisation entrent dans son champ, compte tenu de sa taille et des cas particuliers ?
CRA — règlement (UE) 2024/2847	Cybersécurité des produits comportant des éléments numériques mis à disposition sur le marché, sous réserve des exclusions.	Quels produits, composants et traitements distants faut-il qualifier ?
EHDS / EEDS — règlement (UE) 2025/327	Accès, échange et réutilisation des données de santé ; exigences relatives aux systèmes de dossier médical électronique (DME).	Le logiciel est-il un système de DME et quelles catégories de données traite-t-il ?
AI Act — règlement (UE) 2024/1689	Systèmes et modèles d'IA, selon les risques et les rôles des acteurs.	L'éditeur est-il fournisseur d'un système d'IA, et quelles obligations en résultent ?

Un même acteur peut être concerné à plusieurs titres. Les calendriers et les responsabilités doivent être examinés séparément.

Références officielles utilisées pour cette synthèse : présentations de la Commission sur NIS2, le CRA, l'EHDS et l'AI Act.

Schéma 1 — Synthèse réalisée par CyberSanté AI. Les périmètres peuvent se cumuler. Ce schéma n'est pas une illustration publiée par les institutions européennes.

Le CRA : sécuriser le produit pendant son cycle de vie

Le Cyber Resilience Act vise à améliorer la sécurité des produits numériques et à responsabiliser leurs fabricants. Pour les produits concernés, la sécurité doit être prise en compte dès la conception et les vulnérabilités traitées pendant la période de support.

Les exigences essentielles se répartissent en deux ensembles : les propriétés de sécurité du produit et les processus de traitement des vulnérabilités. Concrètement, le fabricant doit notamment :

• analyser les risques propres au produit et à ses usages prévus ;
• prévoir, selon les risques, des protections contre les accès non autorisés, préserver la confidentialité et l'intégrité des données, limiter les interfaces exposées et fournir une configuration sûre ;
• connaître les composants logiciels et leurs vulnérabilités, notamment au moyen d'une nomenclature des composants, ou SBOM ;
• organiser le signalement des vulnérabilités, les essais de sécurité et la fourniture sécurisée des correctifs ;
• documenter ses choix, les vérifications réalisées, les informations destinées aux utilisateurs et la période de support.

Ce sont des exigences de résultat et de processus : leur mise en œuvre dépend du produit. La documentation technique, l'évaluation de conformité, la déclaration UE et le marquage CE complètent cette démarche. CRA, articles 13, 28 à 32 et annexe I.

Conseil. Avant de remplir un questionnaire de conformité, déterminer si le CRA s'applique et à quels composants. Les catégories de produits importants ou critiques, dont les classes I et II des produits importants, interviennent ensuite dans le choix de la procédure d'évaluation ; elles ne remplacent pas l'analyse du périmètre. CRA, articles 7, 8 et 32, annexes III et IV.

L'EHDS : rendre les données de santé accessibles et échangeables

L'EHDS n'est pas d'abord un règlement de cybersécurité. Il organise l'accès des personnes à leurs données, leur utilisation pour les soins et leur réutilisation encadrée, notamment pour la recherche et les politiques publiques. Il ne crée pas un dossier patient unique stocké dans une base européenne centrale.

Pour les éditeurs, un volet essentiel concerne les systèmes de DME et leurs composants harmonisés d'interopérabilité et de journalisation. Il s'agit de permettre à des systèmes différents d'échanger les données concernées et de rendre les accès traçables.

Niveau du texte	Ce qu'on y trouve
Règlement EHDS dans son ensemble	Droits des personnes, utilisation des données pour les soins, réutilisation, gouvernance et infrastructures européennes.
Chapitre III de l'EHDS	Systèmes de DME, obligations des fabricants, documentation, évaluation de conformité et surveillance du marché.
Annexe II de l'EHDS	Exigences générales, interopérabilité, sécurité et journalisation.
Spécifications communes et actes d'exécution	Précisions techniques, notamment pour les composants harmonisés, sur le fondement de l'article 36 de l'EHDS.

Les exigences portent notamment sur l'import et l'export dans le format européen d'échange, l'absence d'obstacles indus aux usages autorisés, l'identification et l'authentification des professionnels, ainsi que la journalisation et l'analyse des accès. Le fabricant doit aussi constituer sa documentation technique, réaliser les vérifications requises, fournir les informations d'utilisation, établir sa déclaration de conformité et apposer le marquage CE selon le calendrier applicable. EHDS, chapitre III et annexes II–III ; Commission — systèmes de DME.

Comment lire les statuts et les références de cette analyse

Applicable désigne une obligation déjà applicable à la date de cette révision. À venir désigne une disposition adoptée dont l'échéance est ultérieure. Les considérants éclairent le texte sans créer, à eux seuls, une obligation autonome. Les guides officiels de la Commission sont non contraignants. Une proposition n'est pas une règle adoptée. Notre lecture et conseil distinguent notre analyse des obligations. Les points à clarifier appellent une vérification pour l'offre concernée, sans constituer une dispense de conformité.

Trois questions pour situer votre produit

1. Est-il un dispositif médical ? Les produits auxquels s'appliquent le règlement sur les dispositifs médicaux, ou MDR, ou celui sur les dispositifs médicaux de diagnostic in vitro, ou IVDR, sont exclus du CRA. Ils disposent d'un cadre sectoriel de sécurité. Cette exclusion ne répond pas à elle seule à la question EHDS : voir les cas A et E. CRA, article 2, paragraphe 2.
2. Est-il un système de DME ? La définition dépend des fonctions, des catégories prioritaires de données et de la destination prévue par le fabricant. Les catégories comprennent les résumés patients, prescriptions et dispensations électroniques, imagerie, résultats d'examens et comptes rendus de sortie. Un logiciel généraliste ne devient pas un DME du seul fait qu'un hôpital l'utilise. EHDS, articles 2, 14 et 25.
3. Que fournissez-vous ? Décrire les logiciels livrés, services exploités, applications, agents, connecteurs et dépendances distantes. Distinguer chaque offre et chaque rôle. L'abonnement, le navigateur ou une instance dédiée ne suffisent pas à qualifier l'ensemble.

Cinq cas

Cas A — Votre logiciel est un dispositif médical

CRA : exclusion du produit soumis au MDR ou à l'IVDR. Cette exclusion figure déjà dans l'article 2 du CRA ; elle ne signifie pas une absence d'exigences de cybersécurité.

Pour un logiciel relevant du MDR, l'annexe I, point 17.2, du règlement (UE) 2017/745 sur les dispositifs médicaux prévoit notamment l'état de l'art, la gestion des risques, la sécurité de l'information, la vérification et la validation. Le point 17.4 de cette même annexe porte sur les exigences minimales de matériel, de réseau et de sécurité informatique à préciser par le fabricant. MDR, annexe I.

EHDS : des exigences peuvent néanmoins s'ajouter. Lorsqu'un fabricant revendique l'interopérabilité du dispositif avec les composants harmonisés d'un système de DME, l'article 27, paragraphe 1, de l'EHDS impose de démontrer le respect des exigences de la section 2 de son annexe II. Les échéances sont 2029 ou 2031 selon les catégories de données. Le cumul avec un système de DME est examiné au cas E.

Proposition à suivre. La proposition de révision du MDR et de l'IVDR, COM(2025) 1023, prévoit notamment de renforcer le traitement réglementaire de la cybersécurité, avec un dispositif de signalement via EUDAMED. Il s'agit d'une proposition, pas d'une obligation applicable sur cette seule base.

Cas B — Système de DME fourni comme produit logiciel

On suppose ici que le produit répond aux critères du CRA et ne relève pas notamment de l'exclusion MDR/IVDR. Le fait qu'il soit un logiciel de santé ou qu'il soit installé localement n'est pas, à lui seul, une qualification. Ce produit peut alors relever à la fois du CRA et de l'EHDS.

• CRA : exigences essentielles de l'annexe I du CRA à partir du 11 décembre 2027, sous réserve des dispositions transitoires ; signalements de l'article 14 du CRA depuis le 11 septembre 2026.
• EHDS : exigences des systèmes de DME, documentation, déclaration et marquage selon les échéances de 2029 et 2031. L'article 44, paragraphe 7, de l'EHDS prévoit aussi le signalement des incidents graves aux autorités de surveillance du marché au plus tard trois jours après en avoir eu connaissance.
• Articulation : l'article 104 de l'EHDS modifie le CRA. Le nouvel article 32, paragraphe 5 bis, du CRA renvoie à la procédure d'évaluation du chapitre III de l'EHDS ; l'article 31, paragraphe 3, du CRA prévoit une documentation technique unique pour les produits concernés. Cette organisation ne supprime aucun des deux ensembles d'exigences. Le décalage des calendriers mérite une attention particulière, expliquée plus loin.

Le considérant 112 de l'EHDS précise que la partie de la procédure liée aux environnements d'essai n'est pas applicable à la cybersécurité. La FAQ CRA de la Commission, section 2.7, explicite l'articulation entre les deux règlements ; cette FAQ est un guide non contraignant.

Les traitements distants doivent être qualifiés. Le produit CRA comprend ses solutions de traitement de données à distance lorsque le logiciel correspondant est conçu et développé par le fabricant, ou sous sa responsabilité, et que son absence empêcherait une fonction du produit. Cela ne signifie pas que toute l'infrastructure de l'hébergeur appartient au périmètre du produit. CRA, article 3, points 1 et 2, et considérant 11.

Cas C — Système de DME fourni comme service SaaS autonome

CRA : le SaaS en tant que tel n'est pas directement couvert. Le considérant 112 de l'EHDS le précise pour les systèmes de DME. La seule appellation « SaaS » ne suffit toutefois pas à déterminer si l'ensemble d'une offre est hors du périmètre du CRA : applications installables, connecteurs et dépendances éventuelles doivent être examinés.

EHDS : ce mode de fourniture est expressément prévu. L'article 26, paragraphe 2, de l'EHDS considère un système de DME proposé comme service comme mis en service. Le chapitre III s'applique à ces systèmes à partir du 26 mars 2031, selon la disposition spécifique de l'article 105 de l'EHDS.

Un logiciel serveur livré au client peut lui aussi être utilisé par navigateur. Il faut donc examiner les conditions de fourniture et l'architecture, et non déduire le régime du seul écran d'accès. Les orientations CRA de la Commission, notamment les paragraphes 20–21 et l'exemple 5, éclairent cette distinction.

NIS2 reste une analyse distincte de l'organisation. L'activité effective, les définitions, les seuils et les exceptions doivent être vérifiés. Le renvoi du considérant 12 du CRA à NIS2 ne signifie pas que toute offre SaaS rend automatiquement son fournisseur assujetti.

Cas D — Système de DME développé en interne par un établissement

CRA : un logiciel fabriqué exclusivement pour l'usage interne, sans mise à disposition sur le marché, ne relève pas du CRA dans cette situation. Le considérant 112 de l'EHDS explicite ce cas, à lire avec les articles 2 et 3 du CRA.

EHDS : un système de DME fabriqué et utilisé dans un établissement est réputé mis en service par l'article 26, paragraphe 2, de l'EHDS. Le considérant 44 de l'EHDS précise les responsabilités du prestataire de soins qui le développe. La transition spécifique conduit au 26 mars 2031 pour le chapitre III, selon l'article 105 de l'EHDS.

Cas E — Un produit ou un ensemble comprenant un dispositif médical et un DME

Un logiciel de dossier patient peut intégrer un module dispositif médical. Il faut délimiter ce module et le reste du système : l'exclusion CRA d'un module ne doit pas être étendue automatiquement à toute la suite logicielle.

Le considérant 42 de l'EHDS prévoit l'articulation avec les réglementations sectorielles pour les composants concernés et la coordination des évaluations. L'article 27 de l'EHDS traite des allégations d'interopérabilité ; l'article 1, paragraphe 5, de l'EHDS préserve notamment l'application du MDR et de l'IVDR.

À clarifier pour les offres mixtes : lorsqu'un produit est qualifié dans son ensemble de dispositif médical et répond aussi à la définition d'un système de DME, documenter précisément les obligations EHDS retenues. La seule exclusion du CRA ne suffit pas à trancher l'étendue des obligations EHDS. Cette qualification doit être instruite avec les interlocuteurs réglementaires compétents, dont l'organisme notifié lorsqu'il intervient.

Même logiciel, même version, deux modes de fourniture

Prenons un dossier patient proposé surtout en SaaS, mais aussi livré à quelques hôpitaux pour une exploitation locale. Notre lecture : si l'offre livrée comme produit relève du CRA, son faible poids commercial ne dispense pas le fabricant de ses obligations. Le partage du code n'étend pas automatiquement ce périmètre à toute l'offre SaaS.

Conseil. Mutualiser le développement sécurisé, le suivi des composants et les correctifs est cohérent. Il reste nécessaire de vérifier les versions concernées, le déploiement dans chaque environnement et les obligations de signalement propres à l'événement. L'exemple est générique et ne qualifie pas un produit réel sans examen de son offre.

Schéma 2 — Synthèse réalisée par CyberSanté AI pour un système de DME non dispositif médical. Une base de code commune n'implique pas un périmètre juridique identique. Les références applicables sont précisées dans les cas ci-dessus.

Documentation technique : ce qui change pour un éditeur de DME

Les éditeurs de dispositifs médicaux connaissent déjà la charge d'une documentation technique réglementaire. Pour un logiciel de dossier patient, une documentation produit existe souvent, mais elle ne démontre pas nécessairement le respect de chaque exigence réglementaire.

Dossier	Finalité et éléments caractéristiques
MDR — dispositif médical	Décrire le dispositif et sa destination ; démontrer sa sécurité et ses performances, par la gestion des risques, les vérifications et validations, l'évaluation clinique et la surveillance après commercialisation.
CRA — produit numérique concerné	Décrire le produit, ses versions et son architecture ; justifier les mesures de cybersécurité, documenter les composants et vulnérabilités, les essais, les correctifs et la période de support.
EHDS — système de DME concerné	Décrire le système et ses composants harmonisés ; démontrer les exigences applicables d'interopérabilité, de sécurité et de journalisation, avec les spécifications utilisées et les résultats des évaluations requises.

Références : MDR, article 10 et annexes II–III ; CRA, article 31 et annexe VII ; EHDS, article 37 et annexe III.

Une documentation unique ne signifie pas un document unique ni des exigences identiques. Pour le cas B, l'article 31, paragraphe 3, du CRA, modifié par l'article 104 de l'EHDS, prévoit un dossier réunissant les informations exigées par les textes concernés. Des documents maîtrisés et reliés entre eux peuvent servir cette démonstration. La réutilisation d'un dossier MDR doit, elle aussi, être examinée exigence par exigence.

Documentation, déclaration et marquage CE : trois notions distinctes

Élément	CRA	EHDS
Documentation technique	Démonstration préparée avant la mise sur le marché : article 31 et annexe VII du CRA.	Démonstration préparée avant la mise sur le marché ou en service : article 37 et annexe III de l'EHDS.
Déclaration UE de conformité	Engagement du fabricant : article 28 du CRA.	Article 39 de l'EHDS ; son paragraphe 2 prévoit une déclaration unique lorsque plusieurs actes applicables l'exigent.
Marquage CE	Oui : articles 29 et 30 du CRA. Pour un logiciel, le marquage peut être apposé sur la déclaration UE ou sur le site internet l'accompagnant.	Oui : article 41 de l'EHDS. Le marquage CE ne concerne donc pas uniquement les dispositifs médicaux.
Principales échéances produit	11 décembre 2027, sous réserve des dispositions transitoires de l'article 69 du CRA.	26 mars 2029 ou 2031, selon les catégories et le mode de fourniture : article 105 de l'EHDS.

L'article 13, paragraphe 4, du CRA, modifié par l'EHDS, permet aussi d'intégrer l'évaluation des risques cyber à celle requise par l'autre texte. C'est une possibilité de mutualisation, à distinguer de l'obligation de documentation unique prévue pour les produits concernés.

ISO 27001 et HDS : réutiliser les acquis, compléter la démonstration

ISO 27001 encadre le système de management de la sécurité de l'information. ISO 27002 fournit des recommandations sur les mesures de sécurité. Ces acquis peuvent aider à organiser les responsabilités, la gestion des risques, les fournisseurs, les incidents et les changements. Il faut d'abord vérifier le périmètre du certificat : couvre-t-il le développement et la maintenance du produit, ou principalement l'hébergement ? ISO — 27001 et 27002.

Pour un éditeur-hébergeur, HDS couvre les activités d'hébergement certifiées et leurs engagements de sécurité. Le référentiel s'appuie sur ISO 27001 et ajoute notamment des exigences sur les accès, les audits, les contrats et la réversibilité. Il ne constitue pas une certification de conformité du produit au CRA ou à l'EHDS. ANS — certification HDS et référentiel HDS 2024.

Conseil : construire une correspondance fondée sur les preuves disponibles. Une mesure ISO ne vaut pas automatiquement satisfaction d'une exigence produit. Le tableau de travail peut relier chaque exigence CRA ou EHDS à la pratique ISO/HDS existante, au produit et à la version concernés, à la preuve disponible et à l'écart restant.

Acquis à examiner	Complément produit à vérifier
Gestion des risques et des changements	Analyse des risques du logiciel, traçabilité des choix et vérifications de sécurité.
Gestion des vulnérabilités de l'environnement	Composants intégrés au produit, SBOM, versions affectées et distribution des correctifs.
Gestion et journalisation des accès	Couverture réelle des accès au DME et aux données, y compris les interventions techniques.
Réversibilité de l'hébergement	Capacités d'export du logiciel et possibilité d'une reprise exploitable des données.

Ce tableau est une proposition de travail, pas une équivalence réglementaire. Les exigences d'interopérabilité de l'EHDS, en particulier, demandent des capacités du produit qu'une certification de management ne démontre pas à elle seule.

Télémaintenance et télé-exploitation : coordonner les équipes

Le SaaS décrit un mode de fourniture. La télémaintenance et la télé-exploitation décrivent des interventions et des prestations : elles peuvent concerner un logiciel installé chez le client. Elles ne se confondent pas non plus avec le traitement de données à distance défini par l'article 3 du CRA.

L'ANS précise, pour l'activité HDS d'administration et d'exploitation, la sécurisation des accès, la conservation des traces et de leurs motifs et la validation des interventions. La répartition effective des prestations doit être vérifiée dans les contrats ; le certificat du fournisseur d'infrastructure ne couvre pas automatiquement tout ce que fait l'éditeur. ANS — activité 5.

L'annexe II, point 3.2, de l'EHDS vise la journalisation des accès aux données par des professionnels de santé ou d'autres personnes. Notre analyse pratique : lorsque développement et infrastructure sont séparés, ils doivent vérifier ensemble les comptes utilisés, les droits, les accès aux données et les traces disponibles. Un journal applicatif peut ne pas couvrir une intervention directe en base. Un journal de connexion au serveur ne démontre pas, à lui seul, quels dossiers ont été consultés.

Cette activité peut aussi conduire à examiner le statut de fournisseur de services gérés au titre de NIS2. L'article 6, point 39, de NIS2 couvre l'administration ou la maintenance sur place comme à distance ; l'assujettissement dépend ensuite des critères de son article 2. Ce n'est pas une conséquence automatique du seul recours à la télémaintenance. NIS2.

Réversibilité : HDS, EHDS et Data Act se rencontrent

HDS prévoit des engagements contractuels de restitution en fin de prestation. L'EHDS interdit aux composants harmonisés de faire indûment obstacle à l'export autorisé des données lors du remplacement du système de DME. Ces exigences ne sont pas identiques, mais elles invitent à coordonner les modalités de sortie et les capacités du logiciel. Référentiel HDS, exigence 27 ; EHDS, annexe II, point 2.6.

La réversibilité doit également être examinée au regard du Data Act — règlement (UE) 2023/2854. Pour les services de traitement de données concernés, dont certaines offres SaaS de santé, son chapitre VI encadre le changement de fournisseur et la portabilité des données : les engagements contractuels de sortie doivent être cohérents avec les capacités techniques d'export et de migration. Data Act, chapitre VI.

Le calendrier : distinguer les obligations déjà applicables et les suivantes

Date	Conséquence principale pour les offres concernées
11 septembre 2026	Signalements prévus à l'article 14 du CRA : vulnérabilités activement exploitées et incidents graves répondant aux critères.
26 mars 2027	Application générale de l'EHDS, avec des échéances spécifiques pour plusieurs dispositions, dont celles relatives aux systèmes de DME.
11 décembre 2027	Application générale du CRA, dont documentation, évaluation et marquage CE, sous réserve des dispositions transitoires de l'article 69 du CRA.
26 mars 2029	Échéance EHDS pour les systèmes de DME mis sur le marché traitant les résumés patients, prescriptions et dispensations.
26 mars 2031	Échéance EHDS pour l'imagerie, les résultats d'examens et les comptes rendus de sortie ; chapitre III pour les systèmes proposés comme services ou développés en interne visés à l'article 26, paragraphe 2, de l'EHDS.

Références : CRA, articles 69 et 71 ; EHDS, articles 14, 26 et 105.

Dès maintenant : vérifier le circuit de signalement CRA. L'article 14 du CRA prévoit une alerte précoce sous 24 heures, puis une notification sous 72 heures après la prise de connaissance ; les rapports finaux suivent des délais distincts selon l'événement. Toute faille n'est pas à notifier. L'article 69, paragraphe 3, du CRA étend ce dispositif aux produits concernés mis sur le marché avant décembre 2027. Cela n'avance pas à 2026 l'ensemble des obligations produit de 2027.

Les points à suivre avant de finaliser une démonstration de conformité

Le décalage CRA–EHDS. Le CRA devient généralement applicable en décembre 2027, alors que les principales échéances DME de l'EHDS arrivent en 2029 ou 2031. Pour un produit soumis aux deux textes, il faut vérifier comment utiliser la procédure EHDS à laquelle renvoie le CRA pendant cette période, notamment la disponibilité des moyens d'évaluation. Ce point de mise en œuvre ne constitue pas une dispense de CRA jusqu'en 2029.

Les produits mixtes DM/DME. La qualification d'un module médical et celle du système de dossier patient doivent être articulées, comme expliqué au cas E. Une exclusion applicable au premier ne tranche pas automatiquement les obligations du second.

Les précisions techniques. Les spécifications communes prévues par l'article 36 de l'EHDS et les environnements d'essai de son article 40 doivent être suivis pour préparer les vérifications. Les actes sur les échanges transfrontières de données ne doivent pas être confondus avec les spécifications propres aux composants harmonisés des DME.

Les normes harmonisées du CRA. Une norme harmonisée dont la référence est publiée au Journal officiel de l'Union européenne peut donner une présomption de conformité aux exigences qu'elle couvre. Il faut examiner sa version, son champ et les éventuelles restrictions. Il ne s'agit pas d'une unique norme ISO garantissant toute la conformité CRA. Les travaux comprennent des normes transversales et des normes par catégories de produits. Commission — normalisation CRA.

Ce qu'un éditeur peut faire dès maintenant

Conseils de préparation :

1. Délimiter chaque offre. Produits, services, modules médicaux, composants, dépendances distantes et catégories de données. Conserver les hypothèses de qualification.
2. Rassembler les acquis ISO 27001 et HDS. Vérifier leur périmètre, puis relier chaque exigence produit aux pratiques et aux preuves existantes, sans présumer d'équivalence.
3. Commencer la documentation technique. Décrire versions, architecture, interfaces, flux, composants, risques, choix de conception, essais et maintenance. Une documentation d'utilisation seule ne suffit pas à démontrer la conformité.
4. Tester les situations concrètes. Correctif affectant plusieurs offres, intervention en base, accès d'un prestataire, export en fin de contrat : identifier qui intervient et ce qui permet de vérifier le résultat.
5. Vérifier le circuit de signalement CRA pour les produits concernés. Responsabilités, qualification des événements, délais et informations disponibles.
6. Planifier les compléments. Répartir les travaux entre produit, développement, infrastructure, RSSI et conformité, avec des responsables et des critères de validation.

Vous êtes un établissement de santé ?

Demandez au fournisseur une réponse sur l'offre et les versions que vous utilisez : quels produits et composants sont concernés par le CRA ? Quelle période de support est prévue ? Comment prépare-t-il les exigences EHDS ? Comment sont réparties les responsabilités d'hébergement et de télémaintenance ? Dans quelles conditions les données peuvent-elles être récupérées ?

Une mention générale de conformité ne remplace pas cette réponse documentée. Pour un système développé en interne, les responsabilités particulières de l'établissement sont présentées au cas D.

Textes et références

• CRA — règlement (UE) 2024/2847, notamment articles 2, 3, 13, 14, 28 à 32, 69 et 71, annexes I et VII. Ses modifications par l'EHDS doivent être lues avec l'article 104 de ce dernier.
• EHDS — règlement (UE) 2025/327, notamment chapitre III, articles 104 et 105, annexes II et III, considérants 42, 44 et 112.
• MDR — règlement (UE) 2017/745, notamment annexe I, points 17.2 et 17.4, et annexes II–III. IVDR — règlement (UE) 2017/746.
• FAQ CRA de la Commission et orientations CRA de la Commission : documents explicatifs non contraignants.
• NIS2 — directive (UE) 2022/2555 ; référentiel HDS 2024 ; Data Act — règlement (UE) 2023/2854.

Cette analyse distingue les dispositions des textes, les indications des guides et nos conseils de préparation. La qualification précise reste à établir pour chaque offre, son architecture et ses conditions de fourniture.