Les obligations de signalement du CRA s'appliquent aujourd'hui : ce que fait un éditeur de plugins

Nous sommes le 11 septembre 2026, et l'article 14 du Cyber Resilience Act s'applique donc. Son intitulé officiel est obligations de signalement du fabricant. Qu'il s'applique à partir de cette date exacte est écrit à l'article 71 du règlement (UE) 2024/2847.

Beaucoup a déjà été écrit sur le CRA, presque tout à la même hauteur : il y a une obligation de signalement, il y a des délais, préparez-vous à temps. Ce qui manque, c'est la partie qui compte quand un courriel arrive vraiment, décrivant une faille exploitée dans votre plugin. Quel organisme, quel délai à partir de quel instant, et ce que vous notez dans les heures qui suivent.

C'est de cela qu'il s'agit ici. C'est une lecture de l'état de la recherche au 21 août 2026, et ce n'est pas un conseil juridique. Là où une information était incertaine, le texte le dit.

Qui est visé au juste

Deux définitions portent toute l'affaire. Un produit comportant des éléments numériques est, selon l'article 3, point 1, un produit logiciel ou matériel avec le traitement de données à distance associé, y compris expressément les composants mis sur le marché séparément. Un plugin distribué séparément entre dans cette formulation. Est fabricant, selon l'article 3, point 13, celui qui développe de tels produits ou les fait développer et les commercialise sous son propre nom ou sa propre marque, que ce soit contre paiement, contre monétisation ou gratuitement. Un plugin gratuit publié sous votre nom dans le répertoire fait donc de vous un fabricant au sens du texte.

La part d'honnêteté : cette lecture se fonde bien sur les définitions primaires, mais il n'existe à ce jour aucune prise de position d'une autorité ni de la Commission qui nomme expressément les plugins WordPress.

Trois dates, et une seule est aujourd'hui

Le CRA arrive par étapes, et c'est la confusion la plus fréquente dans les discussions à son sujet. L'article 71 nomme trois dates :

• 11 juin 2026 : le chapitre IV s'applique, celui des organismes notifiés. Pour un éditeur de plugins sans évaluation de la conformité, rien ne change.
• 11 septembre 2026 : l'article 14 s'applique, les obligations de signalement. C'est aujourd'hui.
• 11 décembre 2027 : le reste du règlement s'applique. Cela comprend le marquage CE, la documentation technique, l'évaluation de la conformité et la nomenclature logicielle de l'annexe I, partie II.

Ce qui commence aujourd'hui, c'est l'obligation de signaler quand quelque chose arrive. Ce qui commence en 2027, c'est l'obligation de démontrer en permanence comment vous développez. Acheter aujourd'hui des outils de SBOM, c'est acheter pour dans deux ans.

Deux voies de signalement avec des délais séparés

La formule 24 heures, 72 heures, 14 jours figure dans presque tous les articles de synthèse. Elle décrit exactement un des deux cas que règle l'article 14. Le second cas partage les deux premières étapes et se termine sur un délai différent.

Voie 1 : vulnérabilité activement exploitée

Voie 2 : incident de sécurité grave

Deux choses passent à la trappe dans la formule courte. Premièrement, pour l'incident le rapport final est dû au bout d'un mois, et non au bout de 14 jours. L'autorité allemande BSI cite ce délai d'un mois sur ses propres pages. Deuxièmement, les délais ne démarrent pas tous au même endroit : les 24 et les 72 heures courent à partir du moment où vous prenez connaissance, les 14 jours courent à partir du moment où une mesure corrective est disponible, et le mois court à partir du moment où vous avez remis la notification des 72 heures.

Concrètement, le rapport final de la voie vulnérabilité peut être dû des semaines après l'alerte précoce. Son entrée d'agenda ne naît qu'une fois le correctif prêt.

Ce qui déclenche l'obligation, et ce qui ne la déclenche pas

Une vulnérabilité activement exploitée suppose des indices solides qu'un attaquant l'exploite réellement. Un incident de sécurité grave est un événement qui affecte ou peut affecter négativement la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité des données.

Un bug ordinaire ne déclenche aucun signalement, une mise à jour de routine non plus. Une faille qu'un chercheur en sécurité vous signale et que personne n'exploite relève du circuit de correction normal. En revanche, celui qui reçoit des indices d'une exploitation en cours et réfléchit trois jours a déjà manqué le premier délai. Cette distinction est la première question à laquelle vous répondez le jour venu.

La seconde obligation, celle qui disparaît souvent

L'article 14, paragraphe 8, oblige le fabricant à informer les utilisateurs du produit de la vulnérabilité ou de l'incident et, le cas échéant, des mesures que les utilisateurs peuvent prendre eux-mêmes, dans un format lisible par machine si nécessaire.

C'est une obligation autonome à côté du signalement aux autorités, et pour un éditeur de plugins c'est la partie la plus visible du règlement, parce que chaque client la voit passer. Sans préparation, c'est aussi elle qui échoue en premier : si vous diffusez votre plugin gratuitement via wordpress.org, vous ne connaissez pas vos utilisateurs. Vous avez le canal de mise à jour, les notes de version et le readme. Celui qui laisse traîner ses mises à jour ne reçoit pas l'information même si vous l'envoyez proprement, et c'est déjà un autre sujet, celui de la mise à jour des plugins WordPress.

Où part le signalement, et pourquoi cela coince encore

Le signalement part en même temps au CSIRT coordinateur et à l'ENISA, par la plateforme unique de signalement de l'article 16, la Single Reporting Platform. Le CSIRT destinataire répartit le signalement vers les CSIRT des autres États membres où votre produit est distribué.

Voilà pour le règlement. L'état des lieux au 21 août 2026 était le suivant :

• La plateforme n'était pas accessible au public. L'ENISA le formulait au futur : à partir du 11 septembre 2026, elle sera utilisée par les CSIRT et les fabricants pour les signalements obligatoires.
• Il n'y avait aucun lien d'inscription public. L'adresse de production de la plateforme n'était pas publiée.
• Il existait des guides de l'ENISA pour l'inscription et pour la remise des signalements, mis à jour en juillet et en août 2026, ainsi qu'une adresse d'assistance : cra-srp-helpdesk@enisa.europa.eu.
• Selon ces guides, la connexion passe par EU Login. Au premier accès sont saisis le rôle, le CSIRT compétent, un accord juridique et les données du fabricant.

Une mise à jour de l'ENISA du 3 août 2026 retire un peu de pression. La validation de votre compte par le CSIRT coordinateur n'est pas une condition pour que votre obligation de signalement soit remplie ; elle court en parallèle, un compte non encore validé ne vous met donc pas automatiquement en infraction. La transmission aux CSIRT d'autres États membres se fait manuellement. Et l'ENISA recommande de créer le compte EU Login à l'avance, mais de ne s'inscrire sur la plateforme qu'au moment où un signalement concret se présente. Ces points proviennent d'une source secondaire, les guides de l'ENISA n'étaient pas librement consultables.

Le volet national : à quel organisme vous signalez

Le signalement part au CSIRT de l'État membre de votre établissement principal. L'organisme concret change d'un pays à l'autre, puisque chaque État membre désigne le sien. Cherchez le vôtre avant d'en avoir besoin et notez-le à côté de votre adresse de sécurité.

L'Allemagne sert d'exemple, parce que la désignation y est déjà publiée : le BSI avec le CERT-Bund. Le BSI confirme sur ses propres pages l'échelle des délais, rapport final à un mois compris, et renvoie à l'ENISA pour la plateforme. La loi allemande d'application n'était pas encore en vigueur le 21 août 2026. Le projet existe comme document du Bundestag 21/6134 du 26 mai 2026, première lecture le 11 juin 2026, puis renvoi en commission de l'intérieur, sans objection du Bundesrat. Il ne crée aucune obligation nouvelle, il répartit les compétences. Dans les autres États membres, la mise en oeuvre nationale suit son propre calendrier.

La comparaison avec l'AI Act est parlante. Là, la loi allemande d'application est en vigueur depuis le 29 juillet 2026. Pour le CRA, elle est encore en procédure, alors que le règlement s'applique directement aujourd'hui. Un règlement n'attend pas la loi nationale qui l'accompagne, et cela vaut dans tout État membre où vous êtes établi.

Ce que coûte le signalement qui n'a pas lieu

L'article 64, paragraphe 2, prévoit pour les manquements aux exigences essentielles de l'annexe I ainsi qu'aux obligations des articles 13 et 14 des amendes pouvant aller jusqu'à 15 000 000 d'euros ou, pour les entreprises, jusqu'à 2,5 pour cent du chiffre d'affaires annuel mondial total de l'exercice précédent, le montant le plus élevé étant retenu. Cette dernière précision est souvent omise, et son absence inverse le sens. Ce n'est pas une option pour payer moins.

Pour situer : l'article 64, paragraphe 3, prévoit jusqu'à 10 000 000 d'euros ou 2 pour cent pour d'autres obligations, et le paragraphe 4 jusqu'à 5 000 000 d'euros ou 1 pour cent pour des informations inexactes, incomplètes ou trompeuses fournies aux organismes notifiés et aux autorités de surveillance du marché.

Et puis vient l'article 64, paragraphe 10, avec une exception que presque personne ne cite. Les amendes ne s'appliquent pas aux fabricants qui sont des microentreprises ou des petites entreprises, dans la mesure où il s'agit du non-respect du délai de l'article 14, paragraphe 2, point a, ou de l'article 14, paragraphe 4, point a. Ce sont les deux alertes précoces de 24 heures. Les administrateurs de logiciels libres, les open-source software stewards, sont également exclus des amendes au titre de cette disposition.

Cette exception est étroite, et elle est régulièrement lue trop largement. Elle porte sur le délai de l'alerte précoce. Elle ne dispense pas de l'obligation de signalement elle-même, elle ne couvre pas la notification des 72 heures et elle ne couvre pas le rapport final. Un petit éditeur qui ne signale rien du tout se situe dans le même cadre d'amende qu'un grand.

Les 24 premières heures, en pratique

Ce qui suit est un modèle de travail, pas la reproduction d'un formulaire légal. Le règlement nomme des délais et des destinataires. Quels champs le formulaire de la plateforme demande réellement n'était pas consultable publiquement le 21 août 2026. Ce qui figure ici, c'est la matière que vous devez rassembler de toute façon.

Heure zéro. Le signalement arrive, par courriel à votre adresse de sécurité, par le forum d'assistance ou par une plateforme de divulgation. Notez la date et l'heure à la minute près. C'est le début du délai, et c'est la seule donnée que vous ne pourrez pas reconstituer plus tard.

Première heure. Une personne décide de la voie. Y a-t-il des indices d'exploitation réelle, entrées de journal, installations compromises, exploit public ? Alors voie 1. S'est-il passé quelque chose qui atteint la fonction protectrice du produit, une mise à jour trafiquée ou une intrusion dans votre infrastructure de compilation ? Alors voie 2. Les deux à la fois sont possibles, et dans le doute c'est la voie la plus stricte qui vaut. La décision est consignée par écrit.

Jusqu'à la quatrième heure. Déterminer la portée : quel produit, quelles versions, depuis quand, quelle configuration est touchée, s'il existe une parade sans mise à jour. En parallèle, garder le contact avec la personne qui a signalé pour qu'elle ne publie pas entre-temps.

Jusqu'à la vingt-quatrième heure. Remettre l'alerte précoce. Elle s'appelle alerte précoce et pas analyse, et elle a le droit de comporter des points ouverts.

Ce dont vous avez besoin pour l'alerte précoce

• Nom du produit, versions concernées, données du fabricant.
• Moment et source de votre connaissance.
• Brève description de ce qui s'est passé et de ce qui vous fait conclure à une exploitation.
• Première appréciation de l'impact et de la diffusion des versions concernées.
• Les États membres où le produit est disponible. Pour un plugin du répertoire ouvert, c'est toute l'Union.
• Ce qui est déjà en cours, et quand vous attendez un correctif.

Ce qui doit figurer dans votre propre journal

Le journal est la moitié la moins spectaculaire et la plus utile du travail. C'est lui qui répondra plus tard à la question de savoir si vous avez tenu les délais. Un fichier texte dans le dépôt suffit, tant que quelqu'un le tient.

• Moment et source de la connaissance.
• La décision sur la voie retenue, avec deux phrases de motivation.
• Moment de l'alerte précoce, de la notification des 72 heures et du rapport final, chacun avec son destinataire.
• Moment à partir duquel une mesure corrective était disponible. C'est de là que vous comptez les 14 jours dans la voie vulnérabilité.
• La version de l'information client telle qu'elle est partie, et à quelle date.
• Versions concernées et version qui contient le correctif.

À quoi ressemble l'information client

Courte, factuelle, sans propos rassurants. Nommer les versions concernées, dire ce qu'un utilisateur doit faire maintenant, dire à partir de quelle version le problème est corrigé. S'il existe une mesure intermédiaire, elle passe tout en haut. Pour un plugin WordPress, l'endroit pour cela est le readme avec son entrée de changelog et la mise à jour elle-même, plus la page de sécurité et, si vous avez une liste de clients, un courriel. La partie lisible par machine de l'article 14, paragraphe 8, se réduit pour un plugin à l'indication de version dans le canal de mise à jour.

Ce qui doit exister avant, pour ne pas chercher le jour venu

• Un contact de sécurité publié, de préférence une boîte dédiée plutôt que le forum d'assistance.
• Un /.well-known/security.txt conforme à la RFC 9116, pour que les personnes qui signalent trouvent le chemin sans deviner.
• Une politique de divulgation coordonnée : ce que vous promettez, ce que vous demandez, quel est le périmètre.
• Un moyen d'atteindre tous les utilisateurs concernés. Pour les plugins gratuits du répertoire, c'est le canal de mise à jour avec le readme, pour les produits payants la liste de clients.
• Un emplacement fixe pour le journal, créé avant d'en avoir besoin.

Tout cela ne prend pas un week-end. En plein incident, cela prend trop de temps. Quels outils aident à surveiller vos installations relève d'un autre comparatif des plugins de sécurité.

Où nous en sommes nous-mêmes

Parce qu'un guide qui se contente d'exiger vaut peu de chose : nous avons une page de sécurité avec un contact de sécurité publié, des délais de réponse annoncés, un périmètre défini et notre politique de divulgation coordonnée, ainsi qu'un /.well-known/security.txt conforme à la RFC 9116 qui renvoie à cette page. Derrière se trouve la déclaration du fabricant, rédigée pour que la personne qui signale n'ait pas à demander par où entrer.

Ce qui n'est pas encore en place chez nous a sa place dans le même paragraphe. Pour nos plugins gratuits du répertoire WordPress, par exemple Wellenbrecher, nous ne connaissons pas les installations. Notre chemin vers ces utilisateurs est le canal de mise à jour et le readme, rien d'autre. L'inscription sur la plateforme de signalement n'est pas encore possible, seul le compte EU Login peut être préparé. Et notre journal des incidents reste interne, ce n'est pas une page publique.

Questions fréquentes