Le 11 septembre 2026, l’ENISA, l’agence de cybersécurité de l’Union européenne, a mis en ligne la plateforme unique de signalement du Cyber Resilience Act — en anglais Single Reporting Platform, SRP. C’est le guichet par lequel un fabricant doit désormais déclarer toute vulnérabilité activement exploitée, c’est-à-dire une faille dont quelqu’un se sert réellement contre ses produits, et tout incident grave touchant leur sécurité. L’obligation et l’outil sont nés le même jour. Ce qui suit décrit la plateforme telle qu’elle est en production, relevée écran par écran le 12 septembre 2026, captures à l’appui.
Deux termes à poser avant d’aller plus loin. Un « produit comportant des éléments numériques », c’est un logiciel ou un matériel connecté mis sur le marché de l’Union — un routeur, une application mobile, un automate, un objet connecté ; si vous ne savez pas encore si vos produits en font partie, commencez par notre analyse « Le CRA s’applique-t-il à votre produit ? », le reste de cet article suppose que la réponse est oui. Un CSIRT, c’est le centre de réponse aux incidents de sécurité informatique désigné par chaque État membre ; pour la France, la liste publiée par l’ENISA renvoie vers le CERT-FR, le centre gouvernemental rattaché à l’ANSSI.
Ce qui a changé le 11 septembre
Le calendrier vient du règlement lui-même. Le texte s’applique dans son ensemble à partir du 11 décembre 2027, mais l’Art. 14, celui du signalement, fait exception :
Le présent règlement est applicable à partir du 11 décembre 2027. Toutefois, l’article 14 est applicable à partir du 11 septembre 2026 et le chapitre IV (articles 35 à 51) à partir du 11 juin 2026.
Et l’Art. 14 ne laisse pas le choix du canal. Le signalement se fait simultanément auprès de deux destinataires, par un seul dépôt :
Un fabricant notifie toute vulnérabilité activement exploitée contenue dans le produit comportant des éléments numériques dont il prend connaissance simultanément au CSIRT désigné comme coordinateur conformément au paragraphe 7 du présent article, et à l’ENISA. Le fabricant notifie cette vulnérabilité activement exploitée par l’intermédiaire de la plateforme unique de signalement établie en vertu de l’article 16.
La plateforme sert les deux destinataires d’un coup : on dépose une fois, le CSIRT reçoit, l’ENISA reçoit. C’est tout l’objet de l’Art. 16, qui confie à l’ENISA la mise en place et l’exploitation de ce guichet.
Le parcours d’entrée, écran par écran
Le premier écran ne demande ni mot de passe ni entreprise : il demande qui vous êtes. Deux rôles existent, le représentant du CSIRT et le représentant désigné — en anglais Assigned Representative, AR. Le second est la personne physique qui dépose les notifications au nom du fabricant. C’est ce rôle qu’un fabricant choisit.

Le compte est personnel. Il repose sur EU Login, le système d’identification de la Commission européenne, avec la double authentification obligatoire — un code sur téléphone en plus du mot de passe. La foire aux questions de l’ENISA est explicite (question 9) : « EU Login accounts are personal, and MFA is required to access the platform. Therefore, ARs submitting notifications should use their own EU Login accounts » — les comptes EU Login sont personnels, la double authentification est requise, chaque représentant utilise donc le sien. Un fabricant a un seul représentant principal et jusqu’à vingt représentants secondaires, invités par le principal.
Le deuxième écran surprend : avant même de se connecter, il faut choisir son CSIRT coordinateur dans une liste de vingt-sept. Ce choix n’est pas une préférence, c’est une règle du règlement. En clair : le pays qui compte est celui où se prennent les décisions de cybersécurité de vos produits, pas celui du siège social. Pour une PME française sans autre établissement, c’est le CSIRT France ; le texte prévoit des critères de repli pour les groupes et les fabricants hors Union :
La notification est soumise au moyen du point final de notification électronique du CSIRT désigné comme coordinateur de l’État membre dans lequel le fabricant a son établissement principal dans l’Union et est simultanément mise à la disposition de l’ENISA. Aux fins du présent règlement, un fabricant est réputé avoir son établissement principal dans l’Union dans l’État membre où sont principalement prises les décisions relatives à la cybersécurité des produits comportant des éléments numériques.

Ce choix a une conséquence visible dans la barre d’adresse : une fois connecté, on n’est plus sur le portail commun mais sur une instance par pays — fr.cra-srp.enisa.europa.eu pour le CSIRT France. C’est l’architecture prévue par l’Art. 16 § 1, qui demande que la plateforme « permette aux États membres et à l’ENISA de mettre en place leurs propres points finaux de notification électronique ». Se tromper de pays, c’est donc se retrouver sur la mauvaise instance.
Viennent ensuite, dans l’ordre du manuel utilisateur de l’ENISA (version 1.1, septembre 2026) : l’authentification EU Login, un accord juridique à accepter, l’identité pré-remplie à confirmer, le nom du fabricant à saisir. Le compte devient « Active » immédiatement. Le rattachement entre le représentant et le fabricant est ensuite vérifié par le CSIRT, en parallèle, et cette vérification ne bloque pas : la foire aux questions précise qu’un représentant non encore vérifié « may submit up to 20 notifications for that manufacturer before verification becomes mandatory » — peut déposer jusqu’à vingt notifications avant que la vérification ne devienne obligatoire. Pour une PME, cela veut dire une chose : la vérification n’est jamais ce qui vous empêche de notifier.

Une précision qui compte : l’ENISA demande de ne pas s’inscrire par avance, pour ne pas charger les CSIRT de vérifications inutiles. La formule exacte (question 9) : « manufacturers […] are advised to register and initiate the validation process only when they need to submit a notification. Provided that the AR already has an active EU Login account, registration on the SRP takes just a few minutes » — il est conseillé de s’enregistrer seulement au moment de notifier ; avec un compte EU Login déjà actif, l’inscription prend quelques minutes. Ce que l’on prépare à froid, c’est donc le compte EU Login avec sa double authentification, pas l’inscription sur la plateforme.
Le formulaire à 24 heures, tel qu’il est
Le bouton « Submit new notification » ouvre un parcours en trois étapes, affichées en haut de page comme une barre de progression : alerte précoce (Early Warning), notification à 72 heures, rapport final, plus un onglet facultatif de notes. C’est la structure de l’Art. 14 § 2 et § 4, rendue en interface. À chaque étape, on peut enregistrer un brouillon ou soumettre.

Ce que le règlement exige à 24 heures tient en une ligne : l’alerte précoce indique, « le cas échéant, les États membres sur le territoire desquels il a connaissance que son produit comportant des éléments numériques a été mis à disposition » (Art. 14 § 2, point a). Le formulaire, lui, refuse de partir sans sept champs, marqués « Required » à l’écran le 12 septembre 2026 :
- Le type de notification : incident grave ou vulnérabilité activement exploitée. Le choix modifie la suite du formulaire.
- Un titre, 255 caractères au plus.
- Un résumé, 4 000 caractères au plus. C’est le champ de rédaction humaine que l’on ne peut pas pré-remplir : il faut savoir, en une page, ce qui se passe.
- Le fabricant, choisi dans la liste des entreprises rattachées au compte.
- Les États membres où le produit est disponible — le seul champ que le règlement impose lui-même à ce stade.
- Le nom du produit.
- La version du produit. Pas « la gamme », la version : il faut savoir laquelle est touchée, à 24 heures.
Pour un incident grave, un huitième champ est obligatoire : dire si l’incident est soupçonné de résulter d’un acte illicite ou malveillant — le règlement le demande expressément à 24 heures pour les incidents (Art. 14 § 4, point a). Tout le reste est facultatif à ce stade : mesures correctives prises ou à la disposition des utilisateurs, description de la gravité et de l’impact, acteur malveillant, date et heure de détection.

Le bloc produit montre deux choses. D’abord, la plateforme demande de classer le produit selon les trois régimes du règlement — « par défaut », « important » ou « critique » — sans le rendre obligatoire : le fabricant doit déjà savoir où se situe son produit. Ensuite, elle accepte deux identifiants de faille, l’identifiant CVE, le numéro unique attribué à chaque faille connue dans le référentiel mondial, et l’identifiant EUVD, celui de la base européenne de vulnérabilités tenue par l’ENISA. On peut ajouter plusieurs produits à une même notification.
Ce que la plateforme ne fait pas
Quatre limites de la version ouverte le 11 septembre, toutes documentées par l’ENISA elle-même, et toutes lourdes de conséquences pour l’organisation d’un fabricant.
- Pas d’interface de programmation. Question 15 : « no Application Programming Interface (API) will be provided at the initial release of the SRP, so notifications must be submitted through the platform interface » — aucune API à l’ouverture, tout se dépose à la main dans le formulaire. Un outil interne peut préparer le contenu ; une personne le recopie.
- Anglais seulement. Question 24 : « At launch, the platform will be available in English only. » Le résumé de 4 000 caractères s’écrit en anglais, à 24 heures.
- Un compteur qui sonne trop tôt. Question 26 : dans la version actuelle, le compteur des 72 heures affiche une échéance « 48hrs after submission of the 24-hour Early Warning » — 48 heures après la soumission de l’alerte précoce — si bien qu’une notification peut apparaître en retard avant que 72 heures ne se soient écoulées depuis la prise de connaissance. L’ENISA annonce une correction ; en attendant, c’est votre propre horloge qui fait foi, pas celle de l’écran.
- Pas de plan B en cas de panne. Question 25 : si la plateforme est temporairement indisponible, « manufacturers should wait until it becomes available again and then submit the required notification » — attendre qu’elle revienne, puis soumettre. La même réponse ajoute une soupape : si une communication immédiate est nécessaire avant le retour de la plateforme, le fabricant peut contacter directement son CSIRT ; la notification formelle devra malgré tout repasser par la plateforme dès qu’elle est rétablie.
Deux règles de visibilité complètent le tableau, tirées du manuel utilisateur : un brouillon n’est visible que par la personne qui l’a créé, et un représentant secondaire ne voit que ses propres notifications. Un seul représentant inscrit, en congés ou injoignable, c’est une notification que personne d’autre ne peut ouvrir. Enfin, le signalement volontaire de l’Art. 15 — celui d’une faille sans preuve d’exploitation — n’est pas encore disponible : la plateforme n’accepte que les notifications obligatoires.
Les cinq gestes de la semaine
- Créer deux comptes EU Login avec double authentification, aujourd’hui. Un pour le futur représentant principal, un pour un secondaire. C’est la seule étape que l’ENISA invite à faire par avance, et la seule qui prenne du temps quand tout va mal. L’inscription sur la plateforme elle-même attendra la première notification.
- Trancher le CSIRT coordinateur, et l’écrire quelque part. Le critère est le pays où se prennent les décisions de cybersécurité de vos produits (Art. 14 § 7). Pour une entreprise française sans autre établissement, c’est le CSIRT France. Pour un groupe, la question mérite dix minutes maintenant plutôt qu’à 3 heures du matin.
- Préparer les sept champs pour chaque produit couvert : nom, version, fabricant, États membres de disponibilité. Quatre des sept se remplissent à froid, à condition de savoir quels produits sont dans le périmètre — notre analyse « Le CRA s’applique-t-il à votre produit ? » traite les critères un par un.
- Décider qui écrit le résumé de 4 000 caractères, en anglais, en moins de 24 heures. Ce n’est pas un champ technique, c’est un texte. La personne qui qualifie « exploité ou pas » et celle qui rédige doivent être nommées avant l’incident.
- Tenir sa propre horloge. La plateforme compte mal les 72 heures, et ne compte pas du tout le rapport final pour une vulnérabilité. Le délai court depuis la prise de connaissance, pas depuis la soumission : notez l’heure de la découverte, c’est elle qui fait foi.
Une dernière précision de calendrier. L’amende prévue pour un manquement à l’Art. 14 — jusqu’à 15 000 000 EUR ou 2,5 % du chiffre d’affaires annuel mondial (Art. 64 § 2) — n’est applicable, comme le reste du règlement, qu’à partir du 11 décembre 2027. Nous l’avons détaillé dans « Ce qui devient obligatoire le 11 septembre 2026 » : ce décalage n’est pas un délai de grâce. L’obligation, elle, court depuis le 11 septembre 2026, et la plateforme qui la reçoit est ouverte.