Le Cyber Resilience Act (CRA) impose dès 2026 de nouvelles obligations de cybersécurité aux éditeurs de logiciels, créateurs de plugins, fabricants de produits numériques, importateurs et distributeurs actifs sur le marché européen.
Cyber resilience act (CRA) : pourquoi les logiciels et plugins sont directement concernés
Le Cyber Resilience Act, règlement (UE) 2024/2847, marque un changement profond dans la manière de concevoir, publier et maintenir les produits numériques. Adopté le 23 octobre 2024 puis publié au Journal officiel de l’Union européenne le 20 novembre 2024, il crée un cadre commun de cybersécurité pour les produits comportant des éléments numériques.
Jusqu’ici, beaucoup d’éditeurs traitaient la sécurité comme une couche de correction après publication. Le CRA inverse cette logique : un logiciel, un plugin WordPress, un firmware ou un composant connecté doit être sécurisé dès sa conception, documenté, maintenu et surveillé pendant son cycle de vie.
Cette évolution concerne particulièrement les agences web, les éditeurs SaaS hybrides, les développeurs de plugins, les intégrateurs WordPress et les entreprises qui commercialisent des applications métier. Une agence comme DualMedia, qui intervient sur des projets web, mobiles et applicatifs, doit intégrer ces exigences dans les choix d’architecture, les audits techniques et les processus de maintenance.
Le problème que le Cyber resilience act (CRA) veut résoudre
La multiplication des objets connectés, applications, dépendances open source et extensions logicielles a élargi la surface d’attaque en Europe. La Commission européenne estimait déjà le coût annuel mondial de la cybercriminalité à 5 500 milliards d’euros en 2021, un signal fort sur l’ampleur du risque.
Le marché souffrait de trois faiblesses récurrentes : des produits livrés avec des failles connues, une absence de transparence pour les acheteurs et un suivi post-commercialisation parfois insuffisant. Dans l’univers des plugins, cela peut se traduire par une extension non maintenue, une bibliothèque vulnérable ou une fonction d’administration trop permissive.
Le CRA introduit donc une logique simple : si un produit numérique est mis sur le marché européen, son fabricant doit pouvoir démontrer qu’il a évalué les risques, réduit les vulnérabilités et prévu des correctifs. La sécurité devient une condition d’accès au marché, et non un argument marketing secondaire.
Quels produits numériques entrent dans le champ du CRA
Le CRA s’applique aux produits comportant des éléments numériques. Cette notion couvre les produits logiciels ou matériels, leurs composants, ainsi que certaines solutions de traitement de données à distance lorsqu’elles sont liées au fonctionnement du produit.
Pour un éditeur, le point clé consiste à regarder non seulement le produit final, mais aussi ses dépendances, ses modules complémentaires et ses intégrations. Un plugin WordPress commercial, une application mobile connectée à une API, un firmware embarqué ou un module logiciel vendu séparément peuvent entrer dans le périmètre.
- Objets connectés : caméras, thermostats, serrures connectées, équipements industriels, appareils médicaux connectés hors régimes spécifiques.
- Logiciels : applications, systèmes d’exploitation, firmwares, extensions, plugins, outils d’administration.
- Composants matériels : processeurs, cartes réseau, modules de communication, composants embarqués.
- Solutions distantes liées à un produit : traitements SaaS nécessaires au fonctionnement d’un produit numérique commercialisé.
Certains éléments sont exclus, notamment les services cloud purs, les logiciels libres développés dans un cadre non commercial, les produits de défense ou les dispositifs déjà couverts par des règlements sectoriels spécifiques. Attention toutefois : lorsqu’un composant open source est intégré dans un produit commercial, l’éditeur ou le fabricant du produit doit assumer les obligations associées.
Les catégories de produits et les niveaux de conformité
Le CRA classe les produits selon leur criticité. Cette classification détermine le niveau d’évaluation de conformité à prévoir, depuis l’auto-évaluation jusqu’à l’intervention d’un organisme tiers ou d’une certification européenne.
Pour les éditeurs de logiciels et plugins, cette étape est structurante. Un plugin de galerie d’images n’aura pas le même niveau de risque qu’un gestionnaire de mots de passe, un outil VPN ou une extension d’authentification utilisée sur des sites à fort trafic.
| Catégorie | Exemples de produits | Évaluation attendue |
|---|---|---|
| Produits par défaut | Logiciels de bureautique, jeux vidéo, extensions simples, composants peu sensibles | Auto-évaluation par le fabricant |
| Produits importants de classe I | Gestionnaires de mots de passe, VPN, routeurs domestiques, systèmes domotiques, jouets connectés | Normes harmonisées ou évaluation par un tiers selon les cas |
| Produits importants de classe II | Systèmes d’exploitation, pare-feu industriels, outils de détection d’intrusion, microprocesseurs sécurisés | Évaluation tierce obligatoire |
| Produits critiques | Cartes à puce, dispositifs de signature électronique, passerelles de compteurs intelligents | Certification européenne de cybersécurité |
Cette lecture par niveau de risque oblige les entreprises à documenter leurs arbitrages. En pratique, une cartographie des produits et plugins devient le point de départ de toute stratégie CRA sérieuse.
Les obligations 2026 du Cyber resilience act (CRA) pour les éditeurs de logiciels
Les premières obligations opérationnelles du CRA arrivent avant l’application complète du règlement. Les organismes d’évaluation de conformité sont concernés à partir du 11 juin 2026, puis les obligations de notification des vulnérabilités activement exploitées et des incidents graves s’appliquent à partir du 11 septembre 2026.
L’ensemble des exigences du CRA s’appliquera ensuite à partir du 11 décembre 2027. Ce calendrier laisse une marge apparente, mais elle se réduit rapidement pour les équipes qui doivent revoir leurs chaînes de développement, leurs dépendances, leurs contrats et leur documentation technique.
| Date | Étape réglementaire | Impact pour les logiciels et plugins |
|---|---|---|
| 10 décembre 2024 | Entrée en vigueur du CRA | Début de la période de préparation réglementaire |
| 11 juin 2026 | Application des règles relatives aux organismes d’évaluation | Préparation des évaluations de conformité pour les produits concernés |
| 11 septembre 2026 | Obligations de notification des vulnérabilités et incidents graves | Mise en place indispensable d’un processus de détection, qualification et notification |
| 11 décembre 2027 | Application complète du règlement | Conformité globale exigée pour la mise sur le marché européen |
Pour une entreprise qui édite plusieurs plugins, le risque n’est pas seulement juridique. Sans inventaire fiable, il devient difficile de savoir quel produit est maintenu, quelles bibliothèques sont exposées et quelles versions doivent être corrigées en priorité.
Sécurité par conception : le nouveau réflexe des projets web, mobiles et WordPress
Le CRA impose la sécurité dès la conception et par défaut. Concrètement, un produit ne doit pas être livré avec des vulnérabilités exploitables connues, des mots de passe génériques, des permissions excessives ou des mécanismes de mise à jour insuffisants.
Dans un projet WordPress, cela change la manière de concevoir un plugin. Les rôles utilisateurs doivent être strictement contrôlés, les entrées doivent être validées, les requêtes sécurisées et les dépendances surveillées avant même la première mise en production.
Dans une application mobile, le même principe s’applique aux API, aux jetons d’authentification, au stockage local, au chiffrement et aux journaux techniques. DualMedia intègre ce type d’approche dans les phases de cadrage, d’UX technique, de développement et de maintenance pour éviter que la sécurité soit traitée trop tard.
La question n’est donc plus : le produit fonctionne-t-il ? Elle devient : le produit fonctionne-t-il de manière sûre, maintenable et démontrable face à un audit ?
Gestion des vulnérabilités : ce que les éditeurs doivent organiser avant septembre 2026
La gestion des vulnérabilités devient l’un des piliers du CRA. Le fabricant doit identifier, documenter, corriger et communiquer sur les failles affectant son produit pendant la durée de vie attendue ou pendant cinq ans après la mise sur le marché, selon la période la plus courte.
Cette exigence suppose un processus formalisé. Il ne suffit plus d’attendre qu’un client signale un bug critique par e-mail ou qu’un développeur corrige une dépendance lorsqu’il en a le temps.
- Mettre en place une veille sur les vulnérabilités des dépendances et composants tiers.
- Créer une procédure publique de signalement des failles, claire et accessible.
- Qualifier les vulnérabilités selon leur gravité, leur exploitabilité et leur impact réel.
- Diffuser des mises à jour de sécurité gratuites et dans des délais adaptés au risque.
- Publier des avis de sécurité lorsque les failles corrigées doivent être connues des utilisateurs.
- Documenter les décisions prises pour conserver une preuve de conformité.
Un cas typique concerne un plugin e-commerce qui utilise une bibliothèque JavaScript vulnérable. Si cette dépendance expose les données de commande ou permet une élévation de privilèges, l’éditeur doit être capable de détecter le problème, publier un correctif et informer les canaux compétents dans les délais prévus.
SBOM : l’inventaire logiciel devient une preuve de maîtrise
Le SBOM, pour Software Bill of Materials, est un inventaire des composants logiciels intégrés dans un produit. Il liste notamment les bibliothèques tierces, dépendances open source et packages utilisés dans une application, un plugin ou un firmware.
Son intérêt est évident dès qu’une faille majeure apparaît dans une dépendance populaire. L’affaire Log4Shell a montré qu’une vulnérabilité dans un composant largement diffusé pouvait obliger des milliers d’organisations à vérifier en urgence leur exposition.
Le CRA impose aux fabricants de générer et maintenir un SBOM à jour, au minimum au niveau du package. Ce document n’a pas vocation à être publié systématiquement, car il pourrait aussi fournir des informations utiles à un attaquant, mais il doit être disponible pour les autorités compétentes sur demande.
Pour les équipes de développement, le SBOM doit idéalement être produit automatiquement dans le pipeline d’intégration continue. Cette automatisation réduit les oublis et facilite les audits, notamment lorsque plusieurs produits partagent les mêmes briques techniques.
Notification des incidents : les délais à intégrer dans l’organisation
À partir du 11 septembre 2026, le CRA impose des délais stricts de notification pour les vulnérabilités activement exploitées et les incidents graves affectant la sécurité du produit. Le fabricant doit notifier l’ENISA dans les 24 heures suivant la découverte, fournir un rapport plus complet sous 72 heures, puis un rapport final sous 14 jours.
Ces délais sont proches de ceux que certaines organisations connaissent déjà avec NIS2. La différence tient au périmètre : le CRA se concentre sur le produit numérique lui-même, tandis que NIS2 vise la sécurité des systèmes d’information des entités concernées.
Dans une entreprise logicielle, cela exige une chaîne de décision courte. Qui qualifie l’incident ? Qui valide la notification ? Qui contacte les clients ? Qui rédige le rapport technique ? Sans réponse préparée, les 24 premières heures peuvent devenir chaotiques.
Marquage CE cyber : une condition d’accès au marché européen
Le marquage CE est étendu à la cybersécurité pour les produits couverts par le CRA. Il atteste que le produit respecte les exigences essentielles applicables et qu’une procédure de conformité adaptée à sa catégorie a été suivie.
Pour l’éditeur ou le fabricant, ce marquage suppose un dossier technique, une déclaration de conformité UE et, selon le niveau de criticité, une évaluation tierce. Pour un distributeur ou un importateur, il devient un point de contrôle avant commercialisation.
Cette évolution aura des effets directs sur les appels d’offres. Un client professionnel pourra demander la preuve de conformité CRA, la durée de support sécurité, les modalités de mise à jour et, pour les produits sensibles, des éléments sur la traçabilité des composants.
CRA, NIS2, DORA, RGPD et règlement IA : comment articuler les textes
Le Cyber Resilience Act ne remplace pas les autres cadres européens. Il s’ajoute à un ensemble de règles qui visent chacune un angle précis de la résilience numérique.
NIS2 concerne les organisations essentielles et importantes, leur gouvernance cyber, leur gestion des risques et leurs obligations de notification. DORA cible le secteur financier et la résilience opérationnelle numérique des banques, assureurs, prestataires financiers et fournisseurs TIC critiques.
Le RGPD impose déjà des mesures de sécurité adaptées pour protéger les données personnelles. Le CRA renforce cette logique au niveau du produit : un logiciel vulnérable utilisé pour traiter des données personnelles peut aggraver le risque en cas d’incident ou de contrôle.
Le règlement IA peut également croiser le CRA lorsqu’un système d’intelligence artificielle à haut risque constitue un produit comportant des éléments numériques. Dans ce cas, la conformité cyber devient un socle indispensable pour construire une conformité plus large.
| Texte | Périmètre principal | Effet pour l’entreprise |
|---|---|---|
| CRA | Produits numériques, logiciels, plugins, composants, objets connectés | Sécurité par conception, gestion des vulnérabilités, SBOM, marquage CE |
| NIS2 | Entités essentielles et importantes | Gouvernance cyber, continuité, notification, sécurité de la chaîne d’approvisionnement |
| DORA | Secteur financier et prestataires TIC critiques | Résilience opérationnelle, tests, gestion des tiers, incidents TIC |
| RGPD | Données personnelles | Mesures de sécurité, responsabilité, gestion des violations de données |
| Règlement IA | Systèmes d’intelligence artificielle, notamment à haut risque | Exigences de conformité, gestion des risques, documentation et supervision |
La bonne approche consiste à éviter les silos. Un même produit peut être concerné par plusieurs textes, mais une gouvernance commune permet de mutualiser les preuves, les audits, les registres et les plans d’action.
Sanctions du Cyber resilience act (CRA) : pourquoi l’anticipation est indispensable
Le CRA prévoit des sanctions significatives. Le non-respect des exigences essentielles de cybersécurité peut atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.
Les autres manquements au règlement peuvent être sanctionnés jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial. La fourniture d’informations inexactes ou incomplètes aux autorités peut atteindre 5 millions d’euros ou 1 % du chiffre d’affaires mondial.
Les autorités de surveillance pourront aussi ordonner le retrait ou le rappel de produits non conformes. Pour un éditeur de plugins, l’impact peut donc dépasser l’amende : perte d’accès au marché, rupture de confiance client, interruption de distribution et atteinte durable à la réputation.
Comment préparer un logiciel ou un plugin à la conformité CRA
La mise en conformité commence par un diagnostic. Une entreprise doit identifier son rôle : fabricant, éditeur, importateur, distributeur ou simple utilisateur professionnel de produits numériques.
Pour un éditeur de plugins WordPress, la priorité consiste à relier chaque extension à son modèle économique, ses dépendances, son niveau d’exposition et sa criticité. Un plugin gratuit, non commercial et communautaire n’appelle pas la même analyse qu’une extension premium vendue à des clients européens.
- Cartographier les logiciels, plugins, API, composants embarqués et dépendances critiques.
- Classer chaque produit selon les catégories du CRA et son niveau de risque.
- Mettre en place un pipeline DevSecOps avec analyse de dépendances, revue de code et tests de sécurité.
- Générer un SBOM maintenu à jour pour chaque produit commercialisé.
- Formaliser une politique de divulgation coordonnée des vulnérabilités.
- Préparer les modèles de notification ENISA, les rapports techniques et les circuits de validation.
- Constituer le dossier technique, la déclaration de conformité et les preuves d’évaluation.
- Anticiper l’intervention d’un organisme tiers pour les produits de classe II ou critiques.
Dans un projet accompagné par DualMedia, cette démarche peut être intégrée dès la refonte technique ou la création d’un nouveau produit. L’enjeu est de transformer la conformité en méthode de développement : architecture plus robuste, maintenance plus lisible et meilleure confiance côté client.
Ce que les acheteurs professionnels doivent vérifier
Le CRA ne concerne pas seulement les fabricants. Les acheteurs professionnels auront tout intérêt à renforcer leurs critères de sélection, surtout lorsqu’ils déploient des logiciels critiques, des plugins d’administration, des solutions de paiement ou des composants connectés.
Un service informatique qui installe un plugin sur plusieurs dizaines de sites clients doit vérifier sa maintenance, la réactivité de l’éditeur et la qualité de ses correctifs. Le prix ou la popularité d’une extension ne suffisent plus à justifier un choix technique.
- Demander la durée de support sécurité avant l’achat ou le renouvellement.
- Vérifier l’existence d’un processus de signalement des vulnérabilités.
- Contrôler la fréquence des mises à jour et l’historique de maintenance.
- Exiger les éléments de conformité CRA lorsque le produit est critique.
- Intégrer la cybersécurité dans les appels d’offres et contrats fournisseurs.
Cette discipline d’achat réduit les risques de dépendance à des produits abandonnés. Elle renforce aussi la position des entreprises face aux audits RGPD, NIS2 ou aux exigences contractuelles de grands comptes.
Notre avis
Le Cyber Resilience Act (CRA) oblige les éditeurs de logiciels et de plugins à franchir un cap de maturité. La sécurité ne peut plus être improvisée au moment d’une faille publique ou d’un incident client ; elle doit être pensée, suivie et documentée dès la conception.
Pour les acteurs du web, du mobile et de WordPress, cette contrainte peut devenir un avantage concurrentiel. Un produit mieux sécurisé, mieux maintenu et mieux documenté inspire davantage confiance aux clients, aux distributeurs et aux partenaires.
L’approche la plus pragmatique consiste à commencer par les produits les plus exposés : plugins d’authentification, modules e-commerce, API métier, applications mobiles connectées et outils manipulant des données sensibles. Avec un accompagnement technique adapté, notamment par une agence experte comme DualMedia, la conformité CRA peut s’intégrer progressivement dans les cycles de développement sans bloquer l’innovation.
Quels logiciels sont concernés par le Cyber Resilience Act (CRA) ?
Les logiciels commercialisés sur le marché européen peuvent être concernés par le Cyber Resilience Act (CRA). Cela inclut les applications, systèmes d’exploitation, firmwares, plugins, composants logiciels et certains services distants liés au fonctionnement d’un produit numérique.
Un plugin WordPress est-il soumis au Cyber Resilience Act (CRA) ?
Un plugin WordPress commercial peut entrer dans le champ du Cyber Resilience Act (CRA). L’analyse dépend de son modèle de distribution, de ses fonctionnalités, de son niveau de risque et de sa mise à disposition sur le marché européen.
Le CRA s’applique-t-il aux logiciels open source ?
Les logiciels open source non commerciaux ne sont pas directement soumis aux mêmes obligations. En revanche, lorsqu’un composant open source est intégré dans un produit commercial, le fabricant ou l’éditeur du produit doit gérer les obligations prévues par le CRA.
Quelles obligations CRA s’appliquent dès 2026 ?
Les obligations de notification des vulnérabilités activement exploitées et des incidents graves s’appliquent à partir du 11 septembre 2026. Les entreprises doivent donc préparer leurs processus de détection, qualification, notification et reporting avant cette échéance.
Qu’est-ce qu’un SBOM dans le cadre du CRA ?
Un SBOM est l’inventaire des composants logiciels présents dans un produit. Il permet d’identifier les bibliothèques, dépendances et packages utilisés afin de réagir rapidement lorsqu’une vulnérabilité affecte un composant tiers.
Le Cyber Resilience Act (CRA) impose-t-il des mises à jour de sécurité gratuites ?
Oui, le CRA impose la fourniture de mises à jour de sécurité gratuites pendant la période de support applicable. Cette obligation vise à éviter que les utilisateurs restent exposés à des failles connues après l’achat du produit.
Quels sont les délais de notification prévus par le CRA ?
Le fabricant doit notifier certaines vulnérabilités et incidents à l’ENISA dans les 24 heures suivant leur découverte. Un rapport plus complet doit suivre sous 72 heures, puis un rapport final sous 14 jours.
Quelle est la différence entre le CRA et NIS2 ?
Le CRA vise la cybersécurité des produits numériques mis sur le marché. NIS2 vise plutôt la cybersécurité des organisations essentielles et importantes, leurs systèmes d’information, leur gouvernance et leurs procédures de notification.
Quelles sanctions sont prévues en cas de non-conformité au CRA ?
Les sanctions peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial pour les manquements les plus graves. Les autorités peuvent aussi demander le retrait ou le rappel de produits non conformes.
Comment préparer un logiciel ou un plugin à la conformité CRA ?
La préparation commence par une cartographie des produits, dépendances et risques. Il faut ensuite classifier les produits, générer des SBOM, organiser la gestion des vulnérabilités, documenter les preuves de sécurité et anticiper les évaluations de conformité.
Vous souhaitez obtenir un devis détaillé pour une application mobile ou un site web ?
Notre équipe d’experts en développement et design chez DualMedia se tient prête à transformer vos idées en réalité. Contactez-nous dès aujourd’hui pour une estimation rapide et précise : contact@dualmedia.fr