Cyber Resilience Act : ce que le règlement impose, et à partir de quand

Une entreprise qui vend un thermostat connecté, un routeur, un système d’alarme ou un simple logiciel installé chez ses clients a longtemps pu traiter la cybersécurité comme une affaire de diligence commerciale : un argument de vente, éventuellement une clause de contrat. Des exigences existaient, mais elles étaient sectorielles et dispersées. Le règlement (UE) 2024/2847, connu sous le nom de Cyber Resilience Act, installe un cadre horizontal : il subordonne la mise à disposition d’un produit sur le marché de l’Union au respect des exigences essentielles de son annexe I et, avant la mise sur le marché, à l’accomplissement de la procédure d’évaluation de la conformité, à l’établissement de la déclaration UE de conformité et à l’apposition du marquage CE.¹ Des tempéraments existent pour les foires, les démonstrations et les logiciels inachevés diffusés à des fins d’essai, à condition qu’ils portent une marque visible de non-conformité.²

Le déplacement est plus profond qu’il n’en a l’air. Le RGPD encadre le traitement des données à caractère personnel, de leur collecte à leur sécurisation. Le Cyber Resilience Act encadre ce qu’un objet est, avant même qu’une donnée soit traitée. Les objets des deux textes sont distincts, mais leurs champs peuvent se recouvrir, et ils s’appliquent alors cumulativement.

Ce que le règlement appelle un produit

La définition est large, et c’est le premier piège. Un « produit comportant des éléments numériques » est un produit logiciel ou matériel, ainsi que ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels mis sur le marché séparément.³ Trois conséquences se lisent directement dans cette phrase.

D’abord, le logiciel seul peut être un produit. Il n’est pas besoin d’un boîtier : un logiciel autonome entre dans le champ dès lors qu’il est mis à disposition sur le marché dans le cadre d’une activité commerciale et que son utilisation prévue ou raisonnablement prévisible comprend une connexion, directe ou indirecte, logique ou physique, à un dispositif ou à un réseau.⁴

Ensuite, un composant peut être un produit pour lui-même. Une bibliothèque, un module ou une carte mis sur le marché séparément constituent un produit distinct, sous réserve des mêmes conditions de champ et des exclusions du règlement.

Enfin, la partie en nuage suit le produit. Une solution de traitement de données à distance n’est visée que si le logiciel est conçu et développé par le fabricant ou sous sa responsabilité, et si son absence empêcherait le produit d’exécuter une de ses fonctions.⁵

Cette dernière précision règle une question que l’on nous pose souvent, et il vaut la peine de la citer dans les termes du texte plutôt que de la paraphraser. Le considérant 12 énonce que les fonctionnalités en nuage fournies par un fabricant d’appareils domestiques intelligents, qui permettent de commander l’appareil à distance, relèvent du règlement, tandis que les sites internet qui ne supportent pas la fonctionnalité d’un produit comportant des éléments numériques n’en relèvent pas.⁶ La portée de cette exclusion mérite d’être énoncée exactement : elle ne dépend pas du genre du site, mais du lien fonctionnel. Un site qui ne fait pas fonctionner un produit comportant des éléments numériques n’entre pas, à ce titre, dans le champ du règlement. Les fournisseurs de services d’informatique en nuage, eux, peuvent relever de la directive SRI 2, notamment lorsqu’ils atteignent les seuils rappelés par ce même considérant.⁷

Le règlement écarte par ailleurs, de manière expresse et catégorielle, les produits auxquels s’appliquent les règlements sur les dispositifs médicaux, sur les diagnostics in vitro et sur la sécurité générale des véhicules à moteur, ainsi que les produits certifiés en matière d’aviation civile.⁸ D’autres limitations sectorielles peuvent être adoptées par acte délégué, à la condition que les règles sectorielles assurent un niveau de protection identique ou supérieur.⁹ Sont également hors champ les pièces de rechange fabriquées selon les mêmes spécifications que le composant remplacé, et les produits développés exclusivement à des fins de sécurité nationale ou de défense.¹⁰

Le calendrier, et pourquoi la première échéance n’est pas 2027

On lit partout que le Cyber Resilience Act « s’appliquera en 2027 ». C’est vrai de l’essentiel du texte, et faux de ce qui arrivera en premier. L’article 71 fixe une date d’entrée en vigueur et trois dates d’application successives.¹¹

Le règlement est entré en vigueur le vingtième jour suivant sa publication au Journal officiel, intervenue le 20 novembre 2024, soit le 10 décembre 2024.¹²

Le 11 juin 2026, le chapitre IV, c’est-à-dire les articles 35 à 51, devient applicable. Ce chapitre organise la notification des organismes d’évaluation de la conformité. Il n’impose pas directement d’obligations aux fabricants, mais il met en place le cadre sans lequel les produits qui exigent l’intervention d’un tiers ne pourraient pas être évalués.

Le 11 septembre 2026, l’article 14 devient applicable. C’est l’échéance la plus souvent oubliée : les obligations de signalement des vulnérabilités activement exploitées et des incidents graves s’appliqueront quinze mois avant le reste du règlement.

Le 11 décembre 2027, le règlement devient applicable dans son ensemble. À compter de cette date, un produit nouvellement mis sur le marché doit respecter l’ensemble du texte. Les produits déjà mis sur le marché avant cette date ne relèvent des exigences du règlement que s’ils font l’objet d’une modification substantielle ; par dérogation, les obligations de signalement de l’article 14 leur sont applicables.¹³

Ce que le fabricant doit faire

L’article 13 est le cœur du texte. Il impose de concevoir, développer et produire le produit conformément aux exigences essentielles de cybersécurité de l’annexe I, partie I.¹⁴ Cette conformité doit être étayée par une évaluation des risques de cybersécurité, documentée, mise à jour selon les besoins au cours de la période d’assistance, et versée à la documentation technique.¹⁵ Selon la catégorie du produit, l’évaluation de la conformité peut toutefois reposer sur le contrôle interne du fabricant : la démonstration est exigeante, elle n’est pas nécessairement externe.¹⁶ Lorsqu’une exigence essentielle n’est pas applicable au produit, la documentation technique doit comporter une justification claire de cette inapplicabilité : le silence ne vaut pas exemption.¹⁷

Quatre obligations méritent d’être détachées, parce qu’elles ont des conséquences immédiates sur la manière dont un produit est conçu et vendu.

La période d’assistance, et son plancher de cinq ans. Le fabricant fixe lui-même la durée pendant laquelle il gérera les vulnérabilités, en fonction de la durée d’utilisation attendue du produit et des attentes raisonnables des utilisateurs. Mais cette période est d’au moins cinq ans, sauf si le produit est censé être utilisé moins longtemps, auquel cas elle épouse la durée d’utilisation prévue.¹⁸ Les éléments retenus pour fixer cette durée figurent dans la documentation technique : le chiffre doit pouvoir être justifié, pas seulement affiché.¹⁹

La date de fin d’assistance, annoncée au moment de l’achat. Elle doit être précisée, mois et année au minimum, de manière claire, compréhensible et aisément accessible au moment de l’achat, et, le cas échéant, figurer sur le produit, son emballage ou par des moyens numériques.²⁰ L’obligation est d’abord une obligation d’information : ce que le fabricant sait de la fin de vie de son produit, l’acheteur doit le savoir avant d’acheter.

Les mises à jour de sécurité, disponibles dix ans. Chaque mise à jour de sécurité diffusée pendant la période d’assistance doit rester disponible pendant dix ans au moins après son émission, ou pendant le reste de la période d’assistance si celle-ci est plus longue.²¹ Les correctifs sont par ailleurs diffusés sans retard et gratuitement, sauf accord contraire entre le fabricant et un utilisateur professionnel portant sur un produit sur mesure.²²

La nomenclature des logiciels. Le fabricant recense et documente les vulnérabilités et les composants du produit, notamment par une nomenclature des logiciels dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur.²³ La formulation mérite d’être lue deux fois : le règlement n’exige pas l’arbre complet des dépendances, mais son premier niveau.

À quoi s’ajoutent un point de contact unique, réellement joignable et non limité à des outils automatisés, pour que les utilisateurs puissent signaler une faille,²⁴ et deux règles distinctes sur les composants de tiers, qu’il ne faut pas confondre. Le devoir de diligence dans le choix des composants inclut expressément les composants libres et ouverts qui n’ont pas été mis à disposition sur le marché dans le cadre d’une activité commerciale.²⁵ Séparément, toute vulnérabilité identifiée dans un composant intégré, y compris un composant logiciel ouvert, doit être signalée à la personne ou à l’entité qui en assure la maintenance, et le correctif éventuel partagé avec elle, dans un format lisible par machine s’il y a lieu.²⁶

Les délais d’annonce, applicables dès septembre 2026

L’article 14 institue une double chaîne de signalement, adressée simultanément au CSIRT désigné comme coordinateur et à l’ENISA, par l’intermédiaire d’une plateforme unique.²⁷

Pour une vulnérabilité activement exploitée : une alerte précoce au plus tard 24 heures après en avoir eu connaissance ; une notification de vulnérabilité au plus tard 72 heures ; puis un rapport final au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation.²⁸

Pour un incident grave ayant des répercussions sur la sécurité du produit : mêmes délais de 24 et 72 heures, mais un rapport final dans un délai d’un mois à compter de la notification d’incident.²⁹ Un incident est grave lorsqu’il entache ou est susceptible d’entacher la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes, ou lorsqu’il a conduit ou est susceptible de conduire à l’introduction ou à l’exécution d’un code malveillant dans le produit ou dans les réseaux et systèmes d’information d’un utilisateur.³⁰

Le respect de ces délais suppose des procédures internes permettant de qualifier vite l’événement, de désigner qui décide et de savoir qui signe l’annonce. C’est ce qui rend l’échéance de septembre 2026 exigeante bien avant celle de 2027, alors même qu’elle attire moins l’attention.

Toutes les catégories de produits ne suivent pas le même chemin

Deux annexes sortent du régime ordinaire. L’annexe III énumère les produits importants, répartis en deux classes : la classe I comprend notamment les gestionnaires de mots de passe, les navigateurs, les systèmes d’exploitation, les routeurs et modems destinés à la connexion à internet, les assistants virtuels polyvalents pour maison intelligente, les produits domestiques intelligents dotés de fonctionnalités de sécurité, notamment les serrures et les caméras de sécurité, et les jouets connectés couverts par la directive 2009/48/CE qui présentent des caractéristiques sociales interactives ou des fonctions de localisation ; la classe II vise les hyperviseurs et systèmes d’exécution de conteneurs, les pare-feu et systèmes de détection et de prévention des intrusions, ainsi que les microprocesseurs et microcontrôleurs résistants aux manipulations.³¹ L’annexe IV, plus courte, liste les produits critiques : dispositifs matériels avec boîtier de sécurité, passerelles pour compteur intelligent et autres dispositifs de traitement cryptographique sécurisé, cartes à puce et éléments sécurisés.³² Le classement d’un produit détermine la procédure d’évaluation de la conformité applicable.³³

Le logiciel libre, traité à part

Le règlement crée une figure nouvelle, que la version française nomme l’intendant de logiciels ouverts : une personne morale, autre que le fabricant, qui a pour objectif de fournir un soutien systématique et continu au développement de produits libres et ouverts destinés à des activités commerciales, et qui en assure la viabilité.³⁴ Ses obligations sont réduites et adaptées : mettre en place et documenter de manière vérifiable une politique de cybersécurité, coopérer avec les autorités de surveillance du marché, et signaler dans certaines conditions les vulnérabilités et incidents.³⁵

Le contributeur individuel, lui, n’est pas atteint par cette construction. Le considérant 18 réserve l’application du règlement aux logiciels libres et ouverts mis à disposition sur le marché, c’est-à-dire fournis pour être distribués ou utilisés dans le cadre d’une activité commerciale.³⁶ Un programme volontaire d’attestation de sécurité peut par ailleurs être établi par la Commission, qui y est habilitée sans y être tenue.³⁷

Les sanctions

Les États membres fixent le régime des sanctions, mais le règlement en pose lui-même les plafonds. Le non-respect des exigences essentielles de l’annexe I et des obligations des articles 13 et 14 est passible d’une amende administrative pouvant aller jusqu’à 15 000 000 EUR ou, pour une entreprise, jusqu’à 2,5 % de son chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu.³⁸ Le manquement aux obligations expressément énumérées à l’article 64, paragraphe 3, relève d’un plafond de 10 000 000 EUR ou 2 %,³⁹ et la fourniture, en réponse à une demande, d’informations inexactes, incomplètes ou trompeuses aux organismes notifiés ou aux autorités de surveillance du marché, d’un plafond de 5 000 000 EUR ou 1 %.⁴⁰

Deux tempéraments méritent d’être connus, parce qu’ils sont rarement cités. La taille de l’opérateur, en particulier lorsqu’il s’agit d’une microentreprise, d’une PME ou d’une jeune entreprise, fait partie des éléments dont il doit être dûment tenu compte pour fixer le montant.⁴¹ Et le règlement entend exempter les microentreprises et les petites entreprises des amendes encourues pour le seul dépassement du délai d’alerte de 24 heures, avec une réserve de rédaction qui mérite d’être signalée.⁴²

Ce que le règlement n’est pas

Il n’est pas un régime de protection des données. Une entreprise conforme au RGPD n’est pas pour autant conforme au Cyber Resilience Act, et l’inverse est tout aussi vrai : les deux textes n’ont ni le même objet, ni les mêmes critères de notification, ni les mêmes bases juridiques. Rien n’empêche en revanche un État membre de confier plusieurs compétences à une même autorité, et certains délais coïncident, notamment celui de 72 heures.

Il n’est pas non plus la directive SRI 2. Celle-ci impose des obligations de gestion des risques et de notification à des entités, secteur par secteur ; le Cyber Resilience Act vise des produits, catégorie par catégorie. Une même entreprise peut relever des deux, à deux titres différents, et devoir annoncer un même événement selon deux régimes distincts.

Enfin, il n’est pas un texte de spécialistes de la sécurité. Ses conséquences les plus lourdes sont commerciales et documentaires : une période d’assistance qu’il faut fixer, justifier et annoncer, une date de fin d’assistance connue de l’acheteur avant l’achat, un inventaire de composants qu’il faut être capable de produire, et un délai de 24 heures qui suppose une décision, pas seulement une équipe technique.

Une divergence entre versions linguistiques, à connaître

Le régime transitoire de l’article 69, paragraphe 3, n’a pas le même sens selon la langue dans laquelle on le lit. Les versions anglaise et italienne visent les produits mis sur le marché avant le 11 décembre 2027, ce qui donne à la dérogation son objet : étendre les obligations de signalement au parc déjà installé. La version française, elle, vise les produits mis sur le marché le 11 décembre 2027, ce qui la viderait de portée. Les deux versions font également foi.⁴³ Le lecteur francophone qui n’a que sa version sous les yeux conclura donc au contraire de ce que le texte veut dire.

Ce qui reste à venir

Le règlement prévoit encore l’adoption de normes harmonisées ouvrant présomption de conformité, la possibilité d’actes d’exécution précisant le format de la nomenclature des logiciels,⁴⁴ et la fixation par les États membres de leurs régimes de sanctions.⁴⁵ Cette revue les suivra à mesure qu’ils paraissent, et datera chaque mise à jour.

Le volet suisse fait l’objet d’un article distinct. La Suisse n’est pas dans le marché intérieur, mais un fabricant suisse est concerné dès lors qu’un produit relevant du règlement est mis à disposition sur le marché de l’Union, directement ou par sa chaîne de distribution. Le Conseil fédéral a par ailleurs chargé l’Office fédéral de la cybersécurité de préparer, avec l’OFCOM et le SECO, un projet de consultation sur la cyberrésilience des produits numériques d’ici l’automne 2026.⁴⁶

Notes

1. Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 relatif à des exigences de cybersécurité horizontales pour les produits comportant des éléments numériques, JO L, 2024/2847, 20.11.2024. Art. 6 pour la condition de mise à disposition sur le marché, et art. 13, par. 12, pour l’enchaînement documentation, évaluation de la conformité, déclaration UE de conformité et marquage CE. ↩

2. Art. 4, par. 2 et 3, sous réserve du par. 4 pour les composants de sécurité relevant d’une autre législation d’harmonisation. ↩

3. Art. 3, point 1. ↩

4. Art. 2, par. 1, et considérant 18 pour la condition d’activité commerciale. ↩

5. Art. 3, point 2. ↩

6. Considérant 12. ↩

7. Considérant 12, dernières phrases, renvoyant à la directive (UE) 2022/2555 et aux seuils de la recommandation 2003/361/CE. ↩

8. Art. 2, par. 2 à 4, renvoyant aux règlements (UE) 2017/745, (UE) 2017/746, (UE) 2019/2144 et (UE) 2018/1139. ↩

9. Art. 2, par. 5. ↩

10. Art. 2, par. 6 et 7. ↩

11. Art. 71, par. 1 pour l’entrée en vigueur, par. 2 pour les trois dates d’application. ↩

12. Art. 71, par. 1, combiné à la date de publication au Journal officiel, le 20 novembre 2024. On notera que le communiqué du Conseil fédéral suisse du 20 août 2025 date l’entrée en vigueur du règlement au 11 décembre 2024 ; le calcul de l’art. 71, par. 1, conduit au 10 décembre 2024. La différence est sans portée pratique, mais elle illustre la facilité avec laquelle une date secondaire se propage. ↩

13. Art. 69, par. 2 et 3. Sur la rédaction de ce dernier paragraphe, voir la dernière section de cet article. ↩

14. Art. 13, par. 1. ↩

15. Art. 13, par. 2 à 4, et annexe VII pour le contenu de la documentation technique. ↩

16. Art. 32 pour les procédures applicables, et annexe VIII pour le contrôle interne. ↩

17. Art. 13, par. 4, dernière phrase. ↩

18. Art. 13, par. 8, troisième alinéa. ↩

19. Art. 13, par. 8, cinquième alinéa. ↩

20. Art. 13, par. 19. ↩

21. Art. 13, par. 9. ↩

22. Annexe I, partie II, point 8. ↩

23. Annexe I, partie II, point 1. ↩

24. Art. 13, par. 17. ↩

25. Art. 13, par. 5. ↩

26. Art. 13, par. 6. ↩

27. Art. 14, par. 1 et 7, et art. 16 pour la plateforme unique de signalement. ↩

28. Art. 14, par. 2, points a) à c). ↩

29. Art. 14, par. 4, points a) à c). ↩

30. Art. 14, par. 5. ↩

31. Annexe III, classes I et II. ↩

32. Annexe IV. ↩

33. Art. 32. ↩

34. Art. 3, point 14. ↩

35. Art. 24, par. 1 à 3. ↩

36. Considérant 18. ↩

37. Art. 25, qui habilite la Commission à adopter des actes délégués établissant des programmes volontaires d’attestation de sécurité, sans lui en faire l’obligation ni fixer de délai. ↩

38. Art. 64, par. 2. ↩

39. Art. 64, par. 3, qui énumère limitativement les dispositions concernées. ↩

40. Art. 64, par. 4. ↩

41. Art. 64, par. 5, point c). ↩

42. Art. 64, par. 10, point a). La réserve tient à la rédaction : ce paragraphe déroge « aux paragraphes 3 à 9 » et écarte « les amendes administratives visées auxdits paragraphes », alors que le manquement à l’art. 14 est sanctionné au titre du paragraphe 2. Lue à la lettre, l’exemption ne rencontrerait donc pas l’amende qu’elle entend écarter. Elle vise pourtant expressément le délai de l’art. 14, par. 2, point a) : c’est la seule lecture qui lui laisse un objet. ↩

43. Art. 69, par. 3. Versions consultées le 1er août 2026 sur EUR-Lex : française, anglaise et italienne. L’anglais lit « placed on the market before 11 December 2027 » et l’italien « immessi sul mercato prima dell’11 dicembre 2027 », là où le français lit « mis sur le marché le 11 décembre 2027 ». ↩

44. Art. 13, par. 24. ↩

45. Art. 64, par. 1. ↩

46. Conseil fédéral, communiqué du 20 août 2025, « Le Conseil fédéral souhaite renforcer la cyberrésilience des produits numériques ». ↩