Qu'est-ce que le Cyber Resilience Act de l'UE ?
Le Cyber Resilience Act de l'UE (CRA) est une réglementation qui établit des exigences de cybersécurité obligatoires pour les produits comportant des éléments numériques vendus dans l'Union européenne. Il a été formellement adopté fin 2024 et devient pleinement applicable en décembre 2027.
Contrairement au RGPD, qui se concentre sur le traitement des données personnelles, le CRA se concentre sur la sécurité du produit lui-même — comment il est conçu, comment les vulnérabilités sont divulguées, et comment les mises à jour logicielles sont gérées pendant toute la durée de vie du produit.
Si vous vendez des extensions WordPress, des thèmes, des produits SaaS, ou tout produit numérique connecté à des clients de l'UE, cette réglementation s'applique probablement à vous.
Qui le CRA concerne-t-il ?
La réglementation cible les « fabricants » et « distributeurs » de produits comportant des éléments numériques. En pratique, cela inclut :
Les développeurs d'extensions et de thèmes WordPress vendant des produits payants sur le marché de l'UE. Si votre extension traite des données, se connecte à des services externes, ou fait partie d'un écosystème logiciel plus large, elle entre dans le champ d'application.
Les fournisseurs SaaS proposant des outils par abonnement à des entreprises ou consommateurs de l'UE.
Les agences et freelances qui développent des logiciels ou applications web personnalisés livrés à des clients de l'UE. Si vous remettez un produit basé sur WordPress à un client en Allemagne, en France, en Italie, ou dans tout autre pays de l'UE, vous pouvez être considéré comme un « fabricant » selon le CRA.
Les propriétaires de sites e-commerce qui vendent leurs propres produits numériques à des clients de l'UE.
À noter : les logiciels open source développés et distribués de manière non commerciale sont largement exemptés. Mais si vous monétisez une extension WordPress — même partiellement, même via un modèle freemium — vous êtes probablement dans le champ d'application.
Exigences clés du CRA
Le CRA introduit plusieurs obligations spécifiques. Voici les plus pertinentes pour les opérateurs WordPress :
1. Politique de divulgation des vulnérabilités (VDP)
Vous devez avoir une politique accessible publiquement expliquant comment les chercheurs en sécurité peuvent signaler des vulnérabilités dans votre produit. C'est ce qu'on appelle une Vulnerability Disclosure Policy ou VDP.
La VDP doit être disponible à un emplacement prévisible (votre site web), rédigée en langage clair, et préciser :
- Comment soumettre un rapport de vulnérabilité
- Quelles informations inclure
- Combien de temps vous prendrez pour accuser réception
- Si vous exploitez un processus de divulgation coordonnée
2. Fichier security.txt (RFC 9116)
L'emplacement standard pour les informations de contact de sécurité est /.well-known/security.txt sur votre domaine. Ce fichier lisible par machine dirige les chercheurs en sécurité vers vos informations de contact et votre VDP.
Le CRA en fait effectivement une exigence pour les produits dans le champ d'application. Le format est défini dans la RFC 9116 et ressemble à ceci :
Contact: mailto:security@votresite.com
Expires: 2027-12-31T23:59:59.000Z
Policy: https://votresite.com/vulnerability-disclosure-policy
3. Nomenclature logicielle (SBOM)
Une SBOM est une liste formelle de tous les composants logiciels de votre produit — essentiellement une liste d'ingrédients pour le logiciel.
Pour une extension WordPress, cela signifie documenter :
- Votre extension elle-même (nom, version, licence)
- Toute bibliothèque ou dépendance tierce qu'elle utilise
- Le cœur de WordPress comme dépendance
Les SBOM doivent être disponibles pour les autorités compétentes sur demande et, pour les produits à risque plus élevé, peuvent devoir être accessibles publiquement.
4. Gestion active des vulnérabilités
Le CRA exige que les fabricants :
- Surveillent leurs produits pour détecter les vulnérabilités connues
- Publient des mises à jour de sécurité en temps opportun
- Informent les utilisateurs des mises à jour de sécurité
- Fournissent des mises à jour de sécurité gratuitement pendant une période de support définie
Pour les extensions WordPress, cela signifie que vous ne pouvez pas simplement publier une version puis l'abandonner. Si une CVE affectant votre extension est découverte, vous êtes tenu de publier un correctif.
5. Évaluation de conformité et marquage CE
La plupart des produits numériques « standard » (Catégorie I selon le CRA) doivent subir une auto-évaluation par rapport aux exigences de la réglementation et apposer le marquage CE sur leur produit. L'évaluation doit être documentée.
Les produits à risque plus élevé (Catégorie II) nécessitent une évaluation par un tiers via un organisme notifié — similaire à la façon dont les dispositifs médicaux ou les jouets sont testés.
La plupart des extensions WordPress relèvent de la Catégorie I et peuvent s'autocertifier.
Et le RGPD et NIS2 ?
Le CRA ne remplace pas le RGPD ni NIS2 — ils s'appliquent en parallèle.
Le RGPD couvre le traitement des données personnelles. Si votre site WordPress ou votre extension traite des données personnelles de résidents de l'UE, le RGPD s'applique indépendamment du CRA.
NIS2 (la directive sur la sécurité des réseaux et de l'information 2) impose des exigences de sécurité aux entités « essentielles » et « importantes » — principalement de grandes entreprises dans des secteurs comme l'énergie, la santé, la finance et les infrastructures numériques. Si votre entreprise ou celle de votre client relève d'une de ces catégories, les obligations NIS2 s'appliquent en plus du CRA.
Pour la plupart des petites entreprises WordPress et des freelances, le RGPD et le CRA sont les préoccupations principales. NIS2 s'applique à un ensemble plus restreint de grandes entités.
Le calendrier — ce qui doit se passer quand
| Date | Obligation |
|---|---|
| Maintenant | Commencez l'analyse des écarts : identifiez ce que vous devez faire |
| Septembre 2026 | Les obligations de signalement du CRA commencent (notifier les autorités des vulnérabilités activement exploitées dans les 24 heures) |
| Décembre 2027 | Les exigences complètes du CRA s'appliquent : VDP, SBOM, security.txt, évaluation de conformité, marquage CE |
L'obligation de signalement de septembre 2026 est souvent négligée. Même si la conformité complète n'est requise qu'en décembre 2027, vous devrez être capable de signaler les vulnérabilités activement exploitées à l'ENISA dans les 24 heures — ce qui nécessite d'avoir des processus de surveillance en place avant cette date.
Comment vérifier votre statut actuel
Si vous n'êtes pas sûr de votre position, commencez par ces questions :
- Avez-vous un contact de sécurité ? Existe-t-il un moyen pour les chercheurs ou utilisateurs de signaler un problème de sécurité dans votre produit ?
- Existe-t-il un fichier security.txt à
/.well-known/security.txtsur votre domaine ? - Pouvez-vous lister tous les composants logiciels de votre produit ? Connaissez-vous les bibliothèques tierces utilisées par vos extensions et leurs versions actuelles ?
- Avez-vous un processus de suivi des vulnérabilités dans les dépendances de votre produit ?
- Avez-vous documenté vos pratiques de sécurité ? Pourriez-vous produire une preuve d'évaluation de conformité si un régulateur le demandait ?
Si vous avez répondu non à la plupart de ces questions, vous avez du travail à faire — mais c'est gérable avec une liste de contrôle claire.
Utiliser une extension pour automatiser la liste de contrôle
Plutôt que de travailler sur ces exigences manuellement, Erdo CRA Compliance automatise l'analyse des écarts et aide à générer la documentation requise directement depuis votre tableau de bord WordPress.
L'extension :
Analyse votre site par rapport aux contrôles CRA, RGPD et NIS2 et produit un tableau de bord de conformité codé par couleur — vert (réussi), orange (nécessite attention), rouge (échec).
Génère votre fichier security.txt au format RFC 9116 correct et l'héberge automatiquement à /.well-known/security.txt. Aucun FTP, aucune configuration serveur.
Crée un modèle de politique de divulgation des vulnérabilités basé sur les détails de votre site, prêt à être publié comme page sur votre site.
Produit une SBOM listant toutes les extensions actives, leurs versions, et leurs informations de licence — le cœur de ce qu'exige une nomenclature logicielle pour un produit basé sur WordPress.
Exporte des rapports d'audit PDF documentant votre statut de conformité, adaptés au partage avec des clients, des auditeurs, ou comme preuves pour une évaluation de conformité.
Génère un modèle de déclaration de conformité — le document d'auto-évaluation requis pour les produits de Catégorie I selon le CRA.
Rien de tout cela ne garantit la conformité légale — cela dépend de votre produit spécifique, de son utilisation, et de votre contexte juridique. Mais cela vous donne un point de départ structuré et garantit que les exigences techniques de base sont en place.
Conseils pratiques pour différents publics
Si vous êtes développeur d'extensions WordPress : Commencez par documenter les dépendances de votre extension (vérifiez votre composer.json ou toute bibliothèque tierce intégrée). Mettez en place un e-mail de contact de sécurité. Publiez une VDP simple. Ces trois étapes couvrent la plupart des obligations de base et prennent quelques heures, pas des semaines.
Si vous êtes freelance livrant des projets WordPress : Vérifiez si vos clients sont basés dans l'UE et si les sites que vous construisez pour eux entrent dans le champ d'application. Envisagez d'inclure la documentation de conformité CRA comme livrable dans vos contrats.
Si vous êtes une agence : Intégrez une liste de contrôle de conformité CRA dans votre processus de remise de projet. Les clients recevant des produits numériques sur le marché de l'UE auront de plus en plus besoin de documentation prouvant que vous avez pris en compte ces exigences.
Si vous exploitez un site e-commerce orienté UE vendant des produits numériques : Traitez l'échéance de décembre 2027 comme les entreprises ont traité l'échéance de mai 2018 du RGPD — mais commencez plus tôt cette fois.
En conclusion
Le Cyber Resilience Act de l'UE est le plus grand changement dans les exigences de conformité logicielle depuis le RGPD. Contrairement au RGPD, que la plupart des propriétaires de sites ont largement ignoré jusqu'au dernier moment, le CRA a des exigences techniques spécifiques qui ne peuvent pas être satisfaites par une simple mise à jour de politique — elles nécessitent une mise en œuvre réelle.
La bonne nouvelle : si vous utilisez WordPress, les outils pour répondre à la plupart des exigences du CRA sont disponibles dès maintenant. Commencer l'évaluation en 2026 vous donne une année complète pour travailler sur la liste de contrôle avant l'échéance de décembre 2027.
Téléchargez Erdo CRA Compliance gratuitement depuis WordPress.org et lancez votre premier scan de conformité dès aujourd'hui.