Le signalement des incidents au titre du CRA est opérationnel : ce que les PME doivent faire

Depuis le 11 septembre 2026, les fabricants de produits comportant des éléments numériques doivent utiliser la plateforme unique de signalement de l'ENISA. Pour de nombreuses PME, c'est la première échéance du Cyber Resilience Act qu'elles doivent traiter en temps réel.

Si votre entreprise développe ou commercialise dans l'Union européenne des logiciels, des objets connectés ou d'autres produits comportant des éléments numériques, déterminez les responsabilités avant un incident. Attendre sa découverte pour le faire est trop tard.

Qu'est-ce qui a changé le 11 septembre 2026 ?

Le Cyber Resilience Act, ou CRA ( Règlement UE 2024/2847 ), introduit des exigences de cybersécurité applicables aux produits comportant des éléments numériques mis à disposition sur le marché de l'Union. La plupart de ses obligations techniques et marquages CE s'appliqueront à partir du 11 décembre 2027 , mais les obligations de signalement prévues à l'article 14 s'appliquent déjà depuis le 11 septembre 2026 .

La Single Reporting Platform (SRP) de l'ENISA est désormais le canal obligatoire pour ces notifications. Elle permet au fabricant de transmettre les informations une seule fois afin qu'elles soient communiquées à l'équipe nationale de réponse aux incidents de sécurité informatique (CSIRT) compétente et, le cas échéant, à l'ENISA.

Cette phase précoce oblige les entreprises à mettre en place leur circuit de signalement avant l'application complète des autres exigences de conformité produit du CRA.

Quelles entreprises peuvent être concernées ?

Le CRA vise en principe les fabricants qui mettent à disposition sur le marché de l'Union un produit comportant des éléments numériques . Selon les circonstances, cela peut inclure :

• Les applications logicielles et plateformes fournies dans un cadre commercial (voir notre guide sur le CRA et les éditeurs logiciels ).
• Les objets connectés et produits de l'Internet des objets (IoT).
• Le matériel intégrant des composants numériques ou microprogrammes.
• Certains produits médicaux ou industriels intégrant un logiciel, sous réserve du champ d'application et des exclusions spécifiques du CRA.
• Les entreprises établies hors de l'Union qui commercialisent des produits couverts sur le marché européen.

La qualification juridique n'est pas toujours évidente. Une entreprise peut se présenter comme fournisseur SaaS, éditeur, fabricant d'équipements, importateur ou distributeur, alors que le CRA détermine son rôle à partir de ses activités réelles et des conditions de mise sur le marché du produit.

Les logiciels libres et open source nécessitent également une analyse spécifique. Le CRA prévoit des règles particulières pour les logiciels libres et open source ainsi que pour leurs intendants. Tous les projets open source ne sont donc pas traités comme des fabricants commerciaux.

Quels événements doivent être signalés ?

L'article 14 distingue principalement deux situations soumises à notification :

Toute vulnérabilité, anomalie ou alerte de sécurité ne franchit pas automatiquement ces seuils. L'entreprise doit pouvoir analyser l'événement, consigner les informations disponibles au moment de la décision et expliquer pourquoi un signalement est nécessaire, ou ne l'est pas.

Cette analyse ne doit pas être réduite à un score générique de gravité. Les définitions et critères propres au CRA doivent être examinés directement.

Quels sont les délais de signalement du CRA ?

Le CRA prévoit une séquence de notifications échelonnées dans le temps :

• Alerte précoce (24h) : sans retard injustifié et, en tout état de cause, dans les 24 heures suivant la prise de connaissance d'une vulnérabilité activement exploitée ou d'un incident grave.
• Notification détaillée (72h) : dans les 72 heures , avec les informations disponibles concernant la vulnérabilité (gravité, mesures d'atténuation) ou l'incident (évaluation initiale, indicateurs de compromission).
• Rapport final : dans les 14 jours suivant la mise à disposition d'une mesure corrective pour une vulnérabilité exploitée ; dans un délai d' un mois après la notification initiale pour un incident grave.

Le calendrier échelonné de signalement du CRA : 24 heures, puis 72 heures, puis un rapport final.

Le délai de 24 heures constitue la principale contrainte opérationnelle. Il laisse peu de temps pour attribuer les responsabilités, recueillir les faits essentiels, sélectionner l'autorité pertinente et obtenir la validation interne.

Quelles informations une PME doit-elle préparer ?

Un dossier de signalement opérationnel devrait permettre de consigner :

• Le produit, le modèle, la version et la publication concernés.
• L'identité du fabricant et des opérateurs économiques pertinents.
• La date et l'heure exactes auxquelles l'organisation a pris connaissance de l'événement.
• La nature de la vulnérabilité ou de l'incident.
• L'exploitation connue ou suspectée dans la nature.
• La gravité et l'impact probable sur les systèmes clients.
• Les utilisateurs, systèmes, États membres ou marchés affectés, lorsqu'ils sont connus.
• Les mesures correctives ou d'atténuation prises ou envisagées.
• Les indicateurs de compromission (IoC), le cas échéant.
• Les décisions internes, validations et incertitudes non résolues.
• Les copies ou références des notifications et mises à jour ultérieures.

Le dossier doit distinguer les informations confirmées , les informations provisoires et les informations non encore disponibles . Combler les lacunes par des hypothèses pour compléter un formulaire produit un dossier moins fiable qu'un champ simplement marqué non confirmé.

Qui doit être responsable du signalement CRA ?

Même une petite organisation doit désigner des rôles précis. Le processus devrait au minimum indiquer :

• Qui reçoit les alertes de sécurité internes et externes.
• Qui apprécie si le seuil de signalement du CRA est atteint.
• Qui prépare la notification technique.
• Qui vérifie les informations factuelles.
• Qui autorise l'envoi vers la plateforme SRP.
• Qui assure le remplacement du responsable principal en cas d'indisponibilité (permanence week-end/nuit).
• Qui communique avec les clients, fournisseurs, autorités et autres parties concernées.

Les fabricants établis hors de l'Union doivent également vérifier si un mandataire européen est requis et quel rôle celui-ci joue dans la procédure de signalement.

Comment articuler le CRA avec les procédures existantes ?

Le signalement CRA ne doit pas devenir un formulaire isolé. Il doit s'intégrer aux procédures de cybersécurité, de protection des données et de continuité opérationnelle déjà en place.

Un même événement peut potentiellement relever de plusieurs régimes : le CRA, NIS2 , la notification d'une violation de données au titre du RGPD , les obligations contractuelles envers les clients ou des exigences sectorielles ( DORA ). Ces régimes n'utilisent pas nécessairement les mêmes seuils, destinataires ou délais.

Un processus solide doit répondre séparément à trois questions :

1. Que s'est-il passé sur le plan technique ?
2. Quels régimes légaux ou contractuels imposent une notification ?
3. Quelles informations peuvent être réutilisées de manière cohérente dans les différents signalements ?

Cette approche réduit le travail en double sans supposer à tort qu'une seule notification satisfait automatiquement toutes les obligations. Pour visualiser l'interaction entre ces textes, consultez notre matrice de l'écosystème de conformité UE .

Liste de contrôle pratique pour les PME

Ce qu'un outil numérique doit faire, et ne doit pas faire

Les outils numériques de conformité peuvent fiabiliser la préparation en guidant l'analyse d'applicabilité, en calculant les délais légaux, en structurant les informations, en signalant les champs manquants et en conservant une piste d'audit complète.

Ils ne doivent ni masquer les incertitudes ni transformer une classification automatisée en conclusion juridique impossible à examiner. Un processus défendable doit présenter les données brutes, la règle analysée, les éléments à valider et l'identité du signataire humain. L'automatisation ne supprime pas la responsabilité : elle donne aux équipes une base structurée et horodatée pour réagir dans les 24 heures.

Majda Skrijelj

Responsable conformité senior au sein d'une institution financière internationale, Majda cumule plus de 20 ans d'expérience à l'intersection de la gouvernance, de l'anti-corruption et du risque réglementaire européen (RGPD, AI Act, DORA).