Cyber Resilience Act et extensions WordPress : vos obligations

Si vous vendez une extension ou un thème WordPress premium à des clients dans l’UE, le Cyber Resilience Act (CRA, règlement sur la cyberrésilience) s’applique déjà à vous. Depuis le 11 septembre 2026, vous devez signaler les vulnérabilités activement exploitées et les incidents graves qui touchent vos produits, à commencer par une alerte précoce dans les 24 heures. Le gros des obligations, des exigences de sécurité et de la nomenclature logicielle (SBOM) jusqu’aux mises à jour de sécurité et au marquage CE, s’applique à partir du 11 décembre 2027.

Ce guide explique qui est considéré comme fabricant, ce que l’obligation de signalement implique concrètement et ce qu’il faut faire dès maintenant. Le texte juridique est le règlement (UE) 2024/2847.

Êtes-vous fabricant au sens du Cyber Resilience Act ?

Le CRA couvre les « produits comportant des éléments numériques » mis à disposition sur le marché de l’UE dans le cadre d’une activité commerciale. Une extension ou un thème WordPress premium vendu à des clients de l’UE est un tel produit, et la personne ou l’entreprise qui le développe et le vend sous son propre nom en est le fabricant. Peu importe que vous soyez établi dans l’UE ou en dehors.

Extensions gratuites, freemium et payantes

Les logiciels libres et open source qui ne sont pas monétisés échappent en général au régime des fabricants. Une extension amateur publiée sur WordPress.org sans aucune offre payante, ou du code que vous apportez au projet de quelqu’un d’autre, en sont des exemples typiques.

Les modèles freemium sont moins nets. Les considérants du CRA énumèrent des indices d’activité commerciale : faire payer le produit, facturer une assistance au-delà du simple recouvrement des coûts, monétiser par le biais d’une plateforme ou d’autres services, exiger des données personnelles comme condition d’utilisation pour d’autres raisons que la sécurité, la compatibilité ou l’interopérabilité, et accepter des dons supérieurs aux coûts. Une extension « lite » gratuite qui sert surtout à vendre une version Pro ou un service payant peut donc être considérée comme commerciale. Si cela décrit votre activité, préparez-vous comme un fabricant et faites-vous conseiller par un juriste sur les détails.

Gestionnaires de logiciels open source

Le CRA crée aussi la figure des « gestionnaires de logiciels open source » (open-source software stewards) : des personnes morales, comme des fondations, qui soutiennent de manière systématique le développement de logiciels libres et open source destinés à des activités commerciales, sans en être le fabricant. Ces gestionnaires relèvent d’un régime allégé, et leurs obligations de signalement s’appliquent à partir du 11 décembre 2027.

Pourquoi votre site web n’est pas un produit au sens du CRA

Un site web ou un service hébergé n’est en général pas, en tant que tel, un « produit » au sens du CRA. Le traitement de données à distance n’est couvert que lorsqu’il est essentiel au fonctionnement d’un produit. Votre site d’entreprise, votre boutique et votre portail client ne sont donc en principe pas des produits relevant du CRA, et exploiter un site WordPress ne fait pas de vous un fabricant. Un service cloud sans lequel votre extension ne peut pas fonctionner est en revanche un cas à examiner de près.

Pour les propriétaires de sites, le CRA agit indirectement, à travers les obligations de leurs fournisseurs d’extensions et de thèmes. Leurs propres obligations découlent du RGPD et, pour certains, de NIS2.

Le calendrier du CRA pour les vendeurs d’extensions WordPress

• 10 décembre 2024 : entrée en vigueur du CRA.
• 11 juin 2026 : application des dispositions relatives aux organismes d’évaluation de la conformité.
• 11 septembre 2026 : application des obligations de signalement des fabricants.
• 11 décembre 2027 : application des obligations principales, dont les exigences essentielles de cybersécurité, l’évaluation de la conformité et le marquage CE.

Signalement depuis le 11 septembre 2026 : 24 heures, 72 heures, 14 jours

L’obligation de signalement porte sur deux types d’événements. Une vulnérabilité activement exploitée est une vulnérabilité pour laquelle il existe des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation de son propriétaire. Un incident grave porte atteinte à la sécurité de votre produit, par exemple parce qu’il entraîne, ou peut entraîner, l’introduction de code malveillant dans votre produit ou dans les systèmes de vos utilisateurs. Pour un éditeur d’extensions, un serveur de mises à jour ou de licences compromis qui distribue une version piégée par une porte dérobée en est un exemple clair.

L’obligation s’applique aussi aux produits mis sur le marché avant le 11 décembre 2027 (art. 69, § 3). Autrement dit, elle couvre les versions de vos extensions que vos clients utilisent aujourd’hui.

Les délais courent à partir du moment où vous avez connaissance de la vulnérabilité ou de l’incident. Les signalements passent par la plateforme unique de signalement du CRA de l’ENISA (Single Reporting Platform), opérationnelle depuis le 11 septembre 2026, et parviennent au CSIRT de l’État membre où se trouve votre établissement principal dans l’UE (d’autres règles s’appliquent si vous n’en avez pas). L’ENISA les reçoit simultanément. Vous devez aussi informer les utilisateurs touchés, et le cas échéant l’ensemble des utilisateurs, du problème et des mesures d’atténuation qu’ils peuvent prendre.

Un scénario réaliste : un chercheur en sécurité ou un hébergeur vous signale qu’une faille de votre extension est utilisée dans des attaques. Dès cet instant, le délai de 24 heures court. Notre guide sur les extensions WordPress vulnérables montre à quelle vitesse ces failles sont exploitées une fois rendues publiques. Si des données personnelles ont également été exposées, par exemple sur votre propre serveur de licences, les règles du RGPD sur les violations de données s’appliquent en parallèle ; voir la notification des violations de données sous 72 heures prévue par le RGPD.

Ce qui s’applique à partir du 11 décembre 2027

À partir de décembre 2027, l’ensemble des obligations des fabricants s’applique aux extensions et aux thèmes que vous mettez sur le marché. Les produits mis sur le marché avant cette date ne sont concernés que s’ils font ensuite l’objet d’une modification substantielle (art. 69, § 2). Les principales obligations :

• La sécurité dès la conception, et aucune vulnérabilité exploitable connue au moment de la mise sur le marché.
• Une configuration sécurisée par défaut.
• Une période d’assistance pendant laquelle vous traitez les vulnérabilités. Elle est en général d’au moins cinq ans, sauf si la durée d’utilisation prévue du produit est plus courte, et sa date de fin (au moins le mois et l’année) doit être clairement indiquée au moment de l’achat.
• Des mises à jour de sécurité diffusées sans délai, gratuitement et accompagnées d’avis de sécurité. Vérifiez comment cela s’articule avec un modèle de licence où les mises à jour s’arrêtent à la fin de l’abonnement.
• Un processus de gestion des vulnérabilités et une politique de divulgation coordonnée des vulnérabilités (CVD), ainsi qu’un point de contact unique que les utilisateurs peuvent joindre rapidement.
• Une SBOM dans un format lisible par machine, couvrant au minimum les dépendances de premier niveau. Pour une extension, pensez aux paquets Composer et npm ainsi qu’à toutes les bibliothèques embarquées.
• Une documentation technique, une évaluation de la conformité et le marquage CE.

Certains types de produits figurent à l’annexe III en tant que « produits importants », soumis à des règles d’évaluation de la conformité plus strictes. On y trouve les logiciels qui recherchent, suppriment ou mettent en quarantaine des logiciels malveillants, les gestionnaires de mots de passe ainsi que les logiciels de gestion des identités et de gestion des accès à privilèges (classe I), de même que les pare-feu et les systèmes de détection et de prévention des intrusions (classe II). Si votre extension est un produit de sécurité, vérifiez attentivement ces catégories.

Les amendes prévues à l’article 64

Le non-respect des exigences essentielles de cybersécurité ou des obligations des fabricants, y compris l’obligation de signalement, peut entraîner des amendes allant jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Un allègement existe pour les petits éditeurs : les microentreprises et les petites entreprises ne peuvent pas être sanctionnées pour avoir manqué le délai de 24 heures de l’alerte précoce, et les gestionnaires de logiciels open source ne peuvent faire l’objet d’aucune amende au titre du CRA. Pour les micro et petits fabricants, la notification sous 72 heures et toutes les autres obligations restent sanctionnables.

Liste d’actions pour les éditeurs d’extensions WordPress

• Recensez chaque extension, thème, module complémentaire et produit freemium payant que vous proposez à des clients de l’UE, et déterminez pour lesquels vous êtes le fabricant.
• Mettez en place une réception des signalements de vulnérabilités capable de réagir en 24 heures : une adresse de contact sécurité, un fichier security.txt sur votre site, une boîte de réception surveillée et un suppléant désigné pour les congés.
• Formalisez votre procédure de signalement : qui décide si une vulnérabilité est activement exploitée, qui dépose le signalement sur la plateforme unique et qui rédige l’avis destiné aux utilisateurs.
• Préparez des modèles pour l’alerte précoce, la notification à 72 heures et le rapport final.
• Publiez une politique de divulgation coordonnée des vulnérabilités.
• Générez une SBOM pour chaque version (CycloneDX et SPDX sont des formats courants) et conservez-la avec le build.
• Protégez votre chaîne de publication : authentification multifacteur sur chaque compte autorisé à publier du code, et serveurs de mises à jour et de licences durcis.
• Définissez une période d’assistance pour chaque produit et prévoyez comment les clients dont la licence a expiré recevront les correctifs de sécurité.
• Lancez la documentation technique : architecture, flux de données, évaluation des risques et résultats des tests.
• Vérifiez si l’un de vos produits relève de l’annexe III.

Comme vérification supplémentaire avant une publication, l’extension gratuite Security Audit & Compliance de secaudit.eu propose une analyse de vulnérabilités du code des extensions et des thèmes (analyse de propagation, ou « taint analysis »). Elle complète votre propre revue de code et vos tests ; elle ne les remplace pas.

FAQ

Le CRA s’applique-t-il aux extensions gratuites de WordPress.org ?

En général non, si l’extension n’est pas monétisée. Si la version gratuite sert de porte d’entrée vers un produit ou un service payant, elle peut relever d’une activité commerciale : faites-vous conseiller.

Je ne fais que créer des sites pour mes clients. Suis-je fabricant ?

Pas pour le site lui-même : un site web en tant que tel n’est en général pas un produit au sens du CRA. Si vous vendez aussi une extension ou un thème sur le marché de l’UE, vous êtes le fabricant de ce produit.

Cet article est une information générale et ne constitue pas un conseil juridique.