Explication de la loi européenne sur la cyber-résilience (CRA) : Ce que les agences et les développeurs WP doivent savoir

Il n'est pas nécessaire de connaître le texte intégral de la loi européenne sur la cyber-résilience pour en ressentir la présence. Si vous créez ou entretenez un logiciel WordPress (dans un but commercial) et qu'il est utilisé dans l'UE, cette loi s'applique très probablement à vous. 

L'ARC attend de vous que vous sachiez quelles dépendances votre code inclut. Vous devez mettre en place une procédure lorsque quelqu'un signale une vulnérabilité. Vous devez séparer les mises à jour de sécurité de tout le reste. Et oui, si quelque chose est exploité, vous avez une date limite pour le signaler, comme tous les autres vendeurs de produits numériques en Europe.

L'ARC n'affectera pas seulement les développeurs de plugins. Elle touche les boutiques de thèmes, les indépendants, les agences et les personnes qui gèrent des piles de sites clients en utilisant un code qu'ils n'ont pas écrit. Elle concerne les places de marché. Elle touche tous ceux qui distribuent des logiciels d'une manière qui permet d'atteindre les utilisateurs de l'UE. La différence est que certains développeurs disposeront d'un système pour faire face à ces obligations. La plupart n'en auront pas.

Il n'est pas nécessaire de tout bouleverser en même temps. Mais vous devez savoir quels sont les changements à venir, quelles sont vos responsabilités et quelles sont les attentes minimales par rapport auxquelles vous serez jugé.

C'est l'objet de cet article.

Qu'est-ce que la loi européenne sur la cyber-résilience (CRA) ?

La loi sur la cyber-résilience (CRA) est un règlement européen qui introduit des exigences obligatoires en matière de cybersécurité pour tous les produits numériques vendus ou distribués au sein de l'UE. Cela concerne à la fois le matériel (comme les routeurs ou les appareils intelligents) et les logiciels, et inclut les solutions de traitement des données à distance du fabricant uniquement lorsque ces solutions sont essentielles au fonctionnement du produit (le SaaS général n'entre pas dans le champ d'application).

L'ARC a été officiellement adoptée par le Parlement européen en mars 2024 et par le Conseil de l'UE en octobre de la même année. La loi s'applique à tous les produits comportant des "éléments numériques" pouvant se connecter à un réseau, y compris les logiciels libres, les plugins, les applications et les systèmes intégrés.

L'ARC comble deux lacunes principales :

1. L'absence générale de sécurité intégrée et de mises à jour fiables pour les produits numériques.
2. Le manque de transparence : les utilisateurs ne savent souvent pas si un produit est sûr, ni si le fournisseur corrigera effectivement les vulnérabilités.

Pour répondre à ces questions, la loi introduit deux séries d'exigences :

• Sécurité pendant le développement et la conception du produit.
• Un processus formel de traitement des vulnérabilités, comprenant la divulgation et l'application de correctifs.

Ces règles s'appliquent tout au long du cycle de vie du produit. Les mises à jour, la réponse aux incidents et la documentation sont toutes concernées. Si votre produit est utilisé dans l'UE, quel que soit votre lieu d'établissement, et s'il comporte un élément commercial, la conformité à l'ARC sera obligatoire d'ici décembre 2027.

Source du champ d'application : Loi sur la cyber-résilience, article 2

Comment l'ARC affecte les développeurs de WordPress et les auteurs de plugins

L'ARC s'applique à tout produit contenant des éléments numériques proposé dans l'UE. Cela inclut le cœur de WordPress, les plugins, les thèmes et même les outils SaaS s'ils traitent des données à distance. Peu importe que le produit soit payant ou gratuit, à code source ouvert ou propriétaire. S'il est utilisé dans l'UE et qu'il comporte un élément commercial, directement ou indirectement, il tombe sous le coup du règlement. C'est pourquoi cette loi s'applique à toutes les couches de l'écosystème WordPress.

Les développeurs de plugins sont des "fabricants" au sens de l'ARC. Si vous livrez un plugin qui a une version pro, qui collecte des données, qui supporte des publicités ou qui est entretenu par une entreprise, vous entrez dans le champ d'application. Il en va de même pour les développeurs de thèmes et les fournisseurs de services. Même si le plugin lui-même est gratuit, la CRA s'applique toujours s'il y a une intention commerciale derrière la façon dont il est offert.

On croit souvent à tort que les logiciels libres sont exclus. Ce n'est pas le cas.

L'ARC introduit un terme distinct, "open-source stewardship", pour décrire le rôle joué par des organisations telles que la WordPress Foundation. Mais WordPress lui-même manque actuellement de ce type de gestion structurée. Il n'existe pas de point de coordination central sur la façon dont les fournisseurs de plugins gèrent les divulgations, les rapports de sécurité ou les réponses aux incidents. Cette responsabilité est fragmentée, souvent laissée à des développeurs individuels ou à de petites équipes.

Et cela soulève un problème plus profond. L'une des exigences de l'ARC est que les développeurs doivent informer les utilisateurs et l'ENISA lorsqu'une vulnérabilité est activement exploitée. Mais dans la plupart des configurations WordPress, les développeurs de plugins n'ont aucun moyen de savoir qui sont leurs utilisateurs. Si votre plugin est téléchargé à partir de WordPress.org ou installé par l'intermédiaire d'une plateforme comme WordPress.com, il se peut que vous ne sachiez pas qui sont vos utilisateurs. Pourtant, la loi attend de vous que vous informiez les utilisateurs. Mais la structure de WordPress ne vous permet pas de le faire.

Cette déconnexion n'a pas encore été résolue, et elle ne peut pas l'être par un seul auteur de plugin. C'est le genre de problème qui nécessite des changements au niveau de l'écosystème : des drapeaux de sécurité coordonnés, des métadonnées structurées dans le référentiel des plugins et une compréhension partagée des responsabilités de chacun.

À partir de la mi-2026, les produits devront suivre des procédures formelles de traitement des vulnérabilités. Il s'agira notamment de disposer d'un point de contact clair pour les rapports de sécurité, d'un calendrier de divulgation documenté et d'un processus de correction. À la fin de l'année 2027, les exigences complètes entreront en vigueur : sécurité du cycle de vie, marquage CE, traçabilité des mises à jour, etc.

Les développeurs doivent adopter des processus formels pour gérer les vulnérabilités. Le répertoire de plugins de WordPress.org devra prendre en charge les drapeaux de sécurité et les étiquettes de mise à jour. La Fondation devra fournir des conseils ou jouer un rôle plus clair en matière d'intendance. La communauté au sens large devra également se familiariser avec de nouveaux termes, notamment les SBOM, les rapports d'incidents, la documentation d'audit, etc.

Le délai est court et les obligations sont précises. Tous ceux qui travaillent sur WordPress, les équipes de plugins, les boutiques de thèmes, les agences, et même les mainteneurs solitaires, devraient commencer à réfléchir à la manière dont ils vont s'en acquitter.

Ce que les développeurs WordPress doivent faire

Si vous êtes l'auteur d'un plugin ou d'un thème WordPress, voici une courte liste de contrôle que vous pouvez suivre :

1. Conservez des journaux détaillés des modifications et des mises à jour afin de pouvoir déterminer quand et comment les problèmes de sécurité ont été résolus.
2. Informer les utilisateurs lorsqu'une mise à jour contient un correctif de sécurité (par exemple, par le biais de notes de version ou d'avis sur le tableau de bord/administration).
3. Utiliser des outils de surveillance des dépendances tels que WP Umbrella pour repérer rapidement les paquets vulnérables.
4. S'efforcer de traiter et d'accuser réception des rapports sur les vulnérabilités critiques dans un délai de 24 à 72 heures.
5. Mettez en place une politique claire de divulgation de la sécurité (par exemple, en ajoutant un fichier SECURITY.md à votre référentiel).
6. Fournir les mises à jour de sécurité séparément des mises à jour de fonctionnalités lorsque cela est techniquement possible, et gratuitement, avec des messages d'avertissement clairs.
7. Désigner un contact de sécurité unique et l'inclure dans les instructions de l'utilisateur.
   

Conformité à l'ARC pour les agences WordPress et les prestataires de soins

Les agences ne sont pas de simples spectateurs de ce changement. Si vous gérez les sites de vos clients, si vous créez des thèmes ou des plugins personnalisés ou si vous proposez des plans de maintenance comprenant des mises à jour et un contrôle de la sécurité, l'ARC a des implications directes sur votre façon de travailler et sur ce dont vous êtes responsable.

Le risque le plus évident réside dans le développement personnalisé. Si votre équipe développe un plugin, un module ou un thème, aussi petit soit-il, qui est déployé sur le site d'un client dans l'UE, vous n'êtes pas un simple prestataire de services.

En vertu de l'ARC, vous êtes désormais un "fabricant". Cela signifie que vous devez suivre des pratiques de développement sécurisées, documenter votre travail et mettre en place un processus de traitement des vulnérabilités. Si l'un de vos modules est exploité, vous disposez de 24 heures pour en informer les autorités européennes (ENISA) et de deux semaines pour y remédier.

Mais même si vous n'écrivez pas de code, vous n'êtes pas tiré d'affaire. La plupart des agences agissent en tant que distributeurs ou importateurs lorsqu'elles déploient des logiciels tiers. Cela inclut l'installation de plugins à partir de WordPress.org ou le regroupement de thèmes avec de nouvelles versions. Dans ces rôles, on attend de vous que vous vérifiiez que les produits que vous utilisez respectent les normes de l'ARC. 

Cela ne signifie pas qu'il faille auditer chaque ligne de code, mais qu'il faut savoir où se trouve la nomenclature du logiciel (SBOM), comprendre comment sont gérées les mises à jour de sécurité et conserver cette documentation dans les dossiers. Il n'est pas nécessaire de créer des SBOM, mais il faut pouvoir les retrouver.

Pour les prestataires de soins, les implications sont encore plus immédiates. L'ARC fixe des attentes quant à la rapidité avec laquelle les incidents de sécurité doivent être traités. Cela signifie que la séparation entre les mises à jour de fonctionnalités et les correctifs de sécurité est une nécessité légale. Si un plugin que vous gérez présente une vulnérabilité critique activement exploitée, il ne suffit pas d'attendre le prochain sprint mensuel.

Vous devrez mettre à jour le site et éventuellement assurer la coordination avec le fournisseur du plugin, votre client et les contacts réglementaires dans les heures qui suivent. Ce changement aura également un impact sur la manière dont vous communiquez avec vos clients. Les mises à jour de sécurité devront être hiérarchisées, documentées et, dans certains cas, archivées.

Les rapports sur les plans de soins devront peut-être mentionner la date à laquelle les correctifs de sécurité ont été appliqués. Il se peut également que vous deviez collecter et conserver des documents, tels que des évaluations des risques, des journaux de mise à jour et des mesures d'atténuation, pour tous les logiciels avec lesquels vous interagissez.

Il existe également un risque plus large : de nombreuses agences construisent des solutions uniques en utilisant des plugins gratuits et des intégrations rapides qui ne répondent plus aux normes de l'ARC. Si vous déployez un plugin gratuit qui n'a pas été mis à jour depuis des années, qui ne divulgue pas les vulnérabilités ou qui n'a pas de SBOM, vous introduisez un risque juridique pour votre client et pour vous-même.

Comme les développeurs de plugins, les agences doivent commencer à penser en termes de traçabilité. Quel logiciel fonctionne sur quel site ? Quand a-t-il été mis à jour pour la dernière fois ? Existe-t-il une documentation disponible en cas de panne ou de violation ? Qui est responsable du processus de correction ? À l'heure actuelle, ce type d'informations est éparpillé dans des feuilles de calcul, des courriels et des serveurs de transit. Avec l'ARC, cela ne suffira plus.

Les agences qui fournissent des plans de soins ou gèrent des sites web pour le compte de clients devront adapter leur pile, leurs flux de travail et leurs habitudes de documentation. Elles devront traiter la maintenance comme un service de conformité, et non comme un simple contrat d'assistance.

Pénalités et amendes de l'ARC en cas d'inobservation

La loi sur la cyber-résilience (CRA) introduit de sérieux mécanismes d'application en cas de non-respect.

Amendes et sanctions financières

• 15 millions d'euros ou jusqu'à 2,5 % du chiffre d'affaires annuel mondial (le montant le plus élevé étant retenu) pour non-respect des exigences essentielles en matière de sécurité (par exemple, conception sécurisée, traitement des vulnérabilités).
• 10 millions d'euros ou 2 % du chiffre d'affaires mondial pour les manquements à d'autres obligations (documentation, déclaration d'incident).
• 5 millions d'euros ou 1 % du chiffre d'affaires pour la fourniture d'informations fausses ou trompeuses.

(Source : article 64 de la CRA)

Il est important de noter que les États membres ont le pouvoir d'imposer des conséquences supplémentaires, telles que le rappel d'un produit non conforme ou l'ordre de le retirer du marché de l'UE.

Comment la sécurité proactive de WordPress peut aider

Au fond, l'ARC exige une protection proactive. Elle veut que les éléments numériques soient "sécurisés dès la conception". Elle attend des mesures qui réduisent la surface d'attaque avant que les vulnérabilités ne soient exploitées.

Pour les agences et les prestataires de soins, cela signifie qu'il faut aller au-delà des analyses de logiciels malveillants et des services de nettoyage. Vous devez mettre en place des systèmes qui bloquent les menaces connues, appliquent des valeurs par défaut sécurisées et créent un enregistrement traçable de la manière dont les vulnérabilités sont traitées.

C'est là que des outils comme WP UmbrellaSite Protect de WP Umbrella peuvent s'avérer précieux. Il rassemble un ensemble de mesures de protection qui correspondent directement aux attentes de l'ARC en matière de traitement des vulnérabilités et de sécurité du cycle de vie :

• Les correctifs virtuels bloquent les vulnérabilités connues même si un plugin ou un thème n'a pas encore été mis à jour, comblant ainsi le fossé entre la divulgation et la publication du correctif.
• La surveillance continue et les rapports sur les menaces fournissent le type de piste d'audit dont les agences peuvent avoir besoin pour démontrer à leurs clients (ou aux autorités de réglementation) que les vulnérabilités sont suivies et atténuées.

Parce qu'il consolide plusieurs couches de défense en une seule solution légère, Site Protect aide les agences à remplacer un patchwork de plugins par un processus structuré et vérifiable. Combiné à la surveillance des performances et du temps de fonctionnement de WP Umbrella, à la gestion des mises à jour en masse des plugins, des thèmes et du cœur de WordPress, aux journaux de mise à jour et aux sauvegardes conformes au GDPR, les agences peuvent stopper les vulnérabilités avant qu'elles ne s'aggravent.

Il est important d'être clair : aucun outil ne peut assurer la "conformité dans une boîte". L'ARC est autant une question de processus (rapports d'incidents, SBOM et délais de divulgation) que de protections techniques. Mais en adoptant des mesures de sécurité proactives telles que les correctifs virtuels et le renforcement automatisé, les agences se placent dans une position plus forte pour répondre à ces exigences tout en protégeant leurs clients en temps réel.