Un éditeur d’extensions premium avec qui nous travaillons régulièrement nous a interpellés cette année avec une question simple en apparence : « Est-ce que le nouveau règlement européen sur la cybersécurité nous concerne, nous qui vendons des extensions WordPress à quelques milliers d’euros par mois ? » La réponse, après lecture du texte, est oui, sans ambiguïté sérieuse dès lors que le produit est vendu dans l’Union européenne, même par une petite structure. Cet article pose les bases du Cyber Resilience Act (CRA) pour un éditeur d’extensions commerciales, sans entrer dans les pratiques de sécurisation du code elles-mêmes, déjà traitées par ailleurs.
Ce qu’est le Cyber Resilience Act
Le Cyber Resilience Act est un règlement de l’Union européenne qui encadre la cybersécurité des produits comportant des éléments numériques mis sur le marché européen — matériel connecté, mais aussi logiciels, y compris les logiciels commercialisés sous forme d’extensions ou de modules complémentaires à un système existant. Le principe central : un éditeur ne peut plus se contenter de vendre un logiciel et de laisser ses failles de sécurité sans suivi ; il doit assumer une responsabilité continue sur le cycle de vie du produit, de la conception jusqu’à la fin de son support.
Qui est concerné parmi les auteurs d’extensions
Le texte distingue les logiciels commercialisés dans un cadre professionnel (vente, abonnement, modèle freemium avec composante payante) des logiciels distribués gratuitement sans activité commerciale associée, ces derniers bénéficiant d’un traitement allégé lorsqu’ils sont développés dans un cadre non lucratif, par exemple au sein d’un projet ouvert porté par une communauté sans finalité commerciale. Une extension freemium avec une version pro payante, un modèle très répandu dans l’écosystème WordPress, entre typiquement dans le périmètre du règlement pour sa composante commerciale.
Les obligations concrètes à anticiper
Une politique de gestion des vulnérabilités documentée
Le règlement impose de disposer d’un processus formalisé pour recevoir, traiter et corriger les signalements de vulnérabilités, avec un canal de contact clairement identifié pour les chercheurs en sécurité qui souhaitent signaler une faille de façon responsable. Une adresse de contact générique noyée dans un formulaire de support classique ne suffit plus : il faut un point d’entrée dédié, documenté publiquement, avec un engagement de délai de traitement.
Des mises à jour de sécurité pendant une durée de vie définie
Le texte prévoit une obligation de support de sécurité minimale après la dernière mise sur le marché d’une version du produit, avec un plancher réglementaire fixé à plusieurs années selon les catégories de produits concernées. Pour un éditeur d’extension, cela signifie documenter clairement, dans sa politique de support, jusqu’à quand une version donnée continuera de recevoir des correctifs de sécurité, même après l’arrêt du développement de nouvelles fonctionnalités.
Une documentation technique de conformité
Le règlement demande de constituer un dossier technique démontrant l’évaluation des risques de sécurité du produit et les mesures prises pour les limiter, une documentation à conserver et à pouvoir présenter en cas de contrôle. Pour une petite structure éditrice, ce dossier ne nécessite pas un appareil bureaucratique disproportionné, mais il exige au minimum une trace écrite des choix de sécurité effectués et des vulnérabilités traitées au fil du temps.
Une notification rapide des vulnérabilités activement exploitées
Une vulnérabilité activement exploitée doit être signalée aux autorités compétentes dans des délais courts, une obligation qui suppose une capacité de détection et de réaction bien plus rapide que le traitement habituel d’un ticket de support classique.
Calendrier d’application
Le règlement prévoit une montée en puissance progressive de ses obligations, avec des échéances étalées sur plusieurs années après son entrée en vigueur, laissant aux éditeurs le temps de mettre en place les processus nécessaires plutôt que de les imposer du jour au lendemain. Il reste néanmoins prudent, pour un éditeur commercial, de ne pas attendre la dernière échéance pour formaliser sa politique de vulnérabilités : la mise en conformité touche des processus internes (gestion du support, communication de sécurité) qui prennent du temps à installer sereinement.
Ce que ça change concrètement pour un petit éditeur
- Rédiger et publier une politique de divulgation responsable des vulnérabilités, même sommaire, avec un contact de sécurité identifié.
- Documenter la durée de support de sécurité de chaque version majeure vendue, et s’y tenir.
- Tenir un registre interne des vulnérabilités signalées et de leur traitement, même artisanal au départ (un simple tableau structuré peut suffire pour commencer).
- Prévoir une procédure de notification rapide en cas de vulnérabilité critique activement exploitée, avec un responsable clairement identifié en interne.
Un conseil qu’on donne systématiquement aux éditeurs qu’on accompagne : ne pas voir le CRA comme une contrainte purement administrative, mais comme un argument commercial. Une politique de sécurité documentée et un historique de correctifs rapides deviennent un argument de vente crédible face à des clients professionnels de plus en plus attentifs à ces critères.
Ce que cet article ne couvre pas
Le CRA impose une gouvernance et une documentation, pas des techniques de sécurisation du code lui-même — validation des entrées, gestion des permissions, protection contre les injections. Ces sujets, tout aussi essentiels à une bonne conformité de fond, relèvent d’un travail de sécurisation technique distinct de l’obligation réglementaire traitée ici.
En résumé
Le Cyber Resilience Act transforme la gestion des vulnérabilités d’une bonne pratique optionnelle en une obligation légale pour tout éditeur d’extensions commerciales vendues dans l’Union européenne. Les trois piliers à mettre en place sans attendre les dernières échéances : un canal de signalement de vulnérabilités documenté, un engagement clair de durée de support de sécurité, et une trace écrite du traitement des failles rencontrées. Une petite structure n’a pas besoin d’un appareil disproportionné pour s’y conformer, mais elle a intérêt à formaliser ces processus dès maintenant plutôt que dans l’urgence d’un contrôle ou d’un incident de sécurité médiatisé.
