Deux réglementations de l'UE, deux missions différentes
Il est facile de mettre dans le même panier le RGPD et le Cyber Resilience Act (CRA) de l'UE — les deux sont des réglementations européennes, les deux comportent des amendes sérieuses, et les deux sont mentionnés dans les mêmes conversations de « checklist de conformité ». Mais ils régulent des choses réellement différentes, et les traiter comme interchangeables laisse de vraies lacunes.
Le RGPD concerne les données : quelles informations personnelles vous collectez, pourquoi, combien de temps vous les conservez, et quels droits ont les personnes derrière ces données. Le CRA concerne la sécurité logicielle : à quel point un produit numérique est construit de manière sécurisée, comment les vulnérabilités sont divulguées, et comment les mises à jour de sécurité sont livrées pendant la durée de vie du produit.
Un site WordPress peut être entièrement conforme au RGPD — consentement aux cookies en règle, politique de confidentialité claire, accords de traitement des données — et n'avoir rien de ce que le CRA attend. L'inverse est également vrai. Ce ne sont pas des cases qui se chevauchent sur la même liste ; ce sont deux listes séparées.
Ce que le RGPD couvre réellement
Le Règlement général sur la protection des données, en vigueur depuis 2018, régit la façon dont les données personnelles sont collectées, stockées, traitées et partagées. Pour un site WordPress typique, cela concerne :
- Le consentement aux cookies — les cookies d'analyse, de publicité et de suivi nécessitent un consentement explicite (opt-in) avant de se charger, pas seulement une bannière d'information.
- La politique de confidentialité — une explication claire et accessible de ce que vous collectez (formulaires de contact, commentaires, analyses, commandes e-commerce) et de ce que vous en faites.
- Les droits des personnes concernées — des mécanismes pour que les visiteurs demandent leurs données, en demandent la correction, ou en demandent la suppression.
- Les accords de traitement des données — des contrats avec tout service tiers qui traite des données en votre nom (fournisseurs d'e-mail, outils d'analyse, hébergement).
- La notification de violation — un processus de signalement des violations de données à l'autorité compétente dans les 72 heures, si des données personnelles sont exposées.
Rien de tout cela ne concerne la sécurité de votre code, de vos plugins, ou la façon dont les vulnérabilités sont signalées. Le RGPD ne se préoccupe pas de savoir si votre plugin de formulaire de contact a une faille d'injection SQL non corrigée — il se préoccupe de ce qui arrive aux données qui y transitent une fois collectées.
Ce que le CRA couvre réellement
Le Cyber Resilience Act, dont l'application sera mise en place progressivement jusqu'en 2027, régit la sécurité des produits à éléments numériques vendus sur le marché de l'UE. Il vise principalement les fabricants — y compris les éditeurs de logiciels, ce qui inclut les développeurs de plugins et de thèmes WordPress — plutôt que chaque opérateur de site. Pour un développeur ou un éditeur, cela signifie :
- Un développement sécurisé par conception (secure-by-design) — construire un logiciel en prenant en compte la sécurité dès le départ, et non en l'ajoutant après coup.
- Une politique de divulgation des vulnérabilités — un processus documenté et public permettant aux chercheurs en sécurité de signaler des vulnérabilités (c'est là que security.txt entre en jeu).
- Des mises à jour de sécurité — un engagement à corriger les vulnérabilités connues pendant une période de support définie, et à notifier les utilisateurs lorsqu'une mise à jour de sécurité est disponible.
- Une nomenclature logicielle (SBOM) — pour de nombreux produits, une liste documentée des composants logiciels et dépendances utilisés, afin que les utilisateurs et les régulateurs puissent évaluer l'exposition lorsqu'un composant présente une vulnérabilité connue.
- Le signalement d'incidents — notifier les autorités compétentes (ENISA) des vulnérabilités activement exploitées dans des délais serrés.
Si vous êtes un opérateur de site qui se contente d'installer des plugins depuis WordPress.org plutôt que quelqu'un qui construit et distribue des logiciels, les obligations directes du CRA pèsent davantage sur les développeurs de plugins que sur vous — mais si votre entreprise construit et vend un plugin, un thème, ou tout produit numérique avec des clients dans l'UE, cela s'applique directement à vous.
Comparaison côte à côte
| RGPD | Cyber Resilience Act de l'UE | |
|---|---|---|
| Ce qui est régulé | Le traitement des données personnelles | La sécurité du produit logiciel |
| À qui cela s'adresse | Quiconque traite des données de résidents de l'UE | Les fabricants de produits à éléments numériques |
| Documents clés | Politique de confidentialité, accords de traitement | Politique de divulgation des vulnérabilités, SBOM |
| Exigence centrale | Base légale pour le traitement des données | Sécurisé par conception, mises à jour de sécurité continues |
| Application | Jusqu'à 20 M€ ou 4 % du CA mondial | Jusqu'à 15 M€ ou 2,5 % du CA mondial |
| En vigueur depuis | 2018 | Mise en place progressive jusqu'en 2027 |
Pourquoi les deux comptent pour une activité WordPress
Si vous gérez une agence WordPress, développez des plugins ou des thèmes, ou exploitez un site qui traite des données de visiteurs de l'UE, les deux réglementations sont réalistiquement pertinentes — juste pour des parties différentes de votre activité :
- La collecte de données de votre site web (formulaires de contact, analyses, e-commerce) relève du RGPD.
- Tout logiciel que vous construisez et distribuez — un plugin, un thème, un produit SaaS — relève du CRA.
De nombreuses entreprises WordPress ont déjà géré le volet RGPD, puisqu'il est appliqué depuis 2018 et que la plupart des agences l'ont intégré à leur processus il y a des années. Le CRA est plus récent et bien moins souvent traité, ce qui est exactement là où se trouve généralement la lacune.
Combler la lacune du CRA
Si vous développez et distribuez un plugin ou un thème WordPress, le point de départ pratique pour être prêt pour le CRA est la documentation : une politique de divulgation des vulnérabilités, un fichier security.txt, et idéalement un SBOM listant vos dépendances. Erdo CRA Compliance analyse un site WordPress par rapport aux exigences du CRA, du RGPD et de NIS2, et génère la documentation attendue par le CRA — politique de divulgation des vulnérabilités, SBOM, security.txt — en une seule passe, plutôt que de construire chaque élément manuellement.
En résumé
Le RGPD et le CRA ne sont pas des réglementations concurrentes ni deux versions de la même exigence — ils couvrent des risques entièrement différents. Traiter « nous sommes conformes au RGPD » comme preuve d'une conformité plus large laisse le volet sécurité logicielle complètement non traité. Si votre entreprise WordPress construit ou distribue des logiciels, les deux méritent une attention séparée, une documentation séparée, traitant des risques séparés.