Cyber Resilience Act.
Développer des produits comportant des éléments numériques sûrs, traiter les vulnérabilités et préparer la preuve de conformité adaptée.
- Règlement (UE) 2024/2847
- Par Derya Altinay
- À jour au 22/10/2026
- Temps de lecture : 9 min
Réponse courte.
Le Cyber Resilience Act est le règlement européen sur la cybersécurité des produits concernés comportant des éléments numériques. Les fabricants sont responsables de la sécurité du développement à la fourniture et au support. Leurs obligations de notification s’appliquent depuis le 11 septembre 2026 ; les obligations générales relatives aux produits s’appliqueront dès le 11 décembre 2027, selon le règlement (UE) 2024/2847.
Le Cyber Resilience Act et ses échéances.
Le Cyber Resilience Act, ou CRA, est le règlement sur la cyberrésilience qui régit la cybersécurité des produits. Le règlement (UE) 2024/2847 associe des exigences de conception à des obligations pendant le cycle de vie. L’objet examiné est le produit concret, avec ses composants pertinents et le traitement de données à distance associé. Un programme de sécurité d’entreprise peut soutenir ce travail, mais ne répond pas seul aux questions propres au produit.
Les échéances du CRA sont échelonnées. Selon l’art. 71, paragraphe 2, les exigences générales s’appliquent dès le 11 décembre 2027 ; les notifications des fabricants de l’art. 14 s’appliquent déjà depuis le 11 septembre 2026. Le chapitre IV sur la notification des organismes d’évaluation de la conformité s’applique depuis le 11 juin 2026. Cette échéance institutionnelle ne constitue pas une date générale anticipée de marquage CE pour tous les logiciels.
Les anciens produits ne sont pas globalement exemptés des notifications des fabricants. L’art. 69, paragraphes 2 et 3, distingue les règles transitoires de conformité des produits de celles des notifications. Les lignes directrices de la Commission C(2026) 5252, section 9.1, expliquent cette distinction aussi pour les produits mis sur le marché avant décembre 2027. Elles constituent une aide à l’interprétation sans force juridique contraignante ; le règlement fait foi.
Les produits et entreprises concernés par le CRA.
Le CRA concerne les produits matériels et logiciels couverts, mis à disposition sur le marché de l’Union et prévoyant une connexion de données directe ou indirecte à un appareil ou un réseau. Les art. 2 et 3 CRA définissent le champ d’application et les termes. Des composants proposés séparément peuvent être concernés. Vérifiez les fonctions réelles et les exceptions légales avant de classer tout le portefeuille de façon identique.
Le rôle de l’entreprise détermine ses obligations. Fabricants, importateurs et distributeurs ont des tâches différentes ; la commercialisation sous sa propre marque peut aussi conférer le rôle de fabricant. Pour les logiciels libres, il faut distinguer la fourniture commerciale, les contributions individuelles et le rôle particulier d’intendant de logiciels ouverts. Une licence libre ne dégage pas globalement le fabricant d’un produit commercial de sa responsabilité.
Un service SaaS n’entre pas dans le CRA et n’en est pas exclu du seul fait de son appellation commerciale. La limite du produit et le traitement de données à distance associé sont déterminants. Les lignes directrices de la Commission, sections 2 et 8, distinguent les produits logiciels des services fournis à distance. Consignez la justification propre à l’architecture concrète ; une affirmation générale sur toutes les offres cloud serait trop large.
Les principaux domaines d’exigences du CRA.
Les exigences du CRA associent sécurité des produits fondée sur les risques et responsabilité continue. L’art. 13 et l’annexe I fondent les obligations relatives aux produits ; l’art. 14 régit les notifications des fabricants applicables plus tôt. Les domaines suivants orientent le travail sans remplacer les exigences légales détaillées.
Comprendre le produit et les risques.
Une évaluation des risques de cybersécurité fonde les décisions de sécurité tout au long du cycle de vie. Les fabricants prennent en compte l’utilisation prévue et raisonnablement prévisible. Décrivez concrètement les fonctions, interfaces et dépendances du produit ainsi que les conséquences possibles d’un problème de sécurité pour ses utilisateurs.
Intégrer la sécurité au produit.
La sécurité dès la conception et les paramètres sûrs par défaut vont de pair. L’annexe I CRA couvre des caractéristiques telles que le contrôle des accès, la protection des données et la limitation des surfaces d’attaque. Une politique rédigée a posteriori ne remplace pas les propriétés techniques ; les décisions de développement et leur vérification doivent correspondre à l’évaluation des risques.
Intégrer les composants de manière responsable.
Les composants intégrés restent dans le champ d’examen du produit. Les fabricants doivent disposer d’informations traçables sur ce qu’ils livrent et sur l’incidence des vulnérabilités des dépendances sur leur produit. La Commission décrit explicitement la diligence requise envers les composants tiers ; transmettre simplement une information du fournisseur ne répond pas à toutes les questions relatives au produit.
Traiter les vulnérabilités et les mises à jour.
Le traitement des vulnérabilités est une tâche continue pendant la période de support pertinente. Il comprend des canaux de signalement accessibles, l’évaluation, la remédiation et la fourniture sécurisée des mises à jour de sécurité. Distinguez le traitement technique d’un constat de l’évaluation juridique déterminant si une vulnérabilité activement exploitée ou un incident grave doit être notifié.
Définir le support et les informations destinées aux utilisateurs.
La période de support dépend des critères de l’art. 13, paragraphe 8, CRA et de l’utilisation attendue. Elle est en principe d’au moins cinq ans ; si l’utilisation attendue est plus courte, sa durée s’applique, tandis qu’une utilisation plus longue peut nécessiter une période supérieure. Les lignes directrices de la Commission, section 5, précisent explicitement que cinq ans ne constituent pas un plafond général.
Rendre possibles les notifications des fabricants.
L’art. 14 CRA distingue les vulnérabilités activement exploitées des incidents de sécurité graves. Les fabricants doivent notifier par étapes : sans délai, avec une alerte précoce au plus tard sous 24 heures et des informations complémentaires sous 72 heures après en avoir pris connaissance. Les délais finaux diffèrent selon le déclencheur. Un résultat de scanner ne constitue donc automatiquement ni une notification obligatoire ni un motif suffisant pour clore l’événement.
Préparer la conformité et la documentation.
La documentation technique et l’évaluation de la conformité doivent expliquer le produit proposé. L’art. 32 CRA et la catégorie du produit déterminent la procédure admissible. Conservez la base d’évaluation retenue avec la version du produit ; une collection générale de documents sans lien traçable avec la version évaluée ne constitue pas une stratégie pratique de preuve suffisante.
La mise en œuvre du CRA comme processus produit.
Délimiter le portefeuille et les rôles.
Pour commencer concrètement, recensez les produits proposés, leurs fonctions pertinentes, l’entité juridique responsable et le rôle dans chaque circuit de distribution.
Distinguer les phases d’application.
Distinguez la capacité de notification des fabricants, déjà obligatoire, de la préparation à la conformité générale des produits et examinez les dispositions transitoires pour les produits existants.
Traduire les risques en décisions produit.
Reliez l’évaluation des risques à la conception, au choix des composants et aux critères de sécurité vérifiables pour le développement et la mise à disposition.
Tester les circuits de notification.
Désignez les responsables et leurs suppléants, puis exercez l’évaluation, l’escalade et la transmission d’informations incomplètes dans les délais applicables.
Définir le support et la démarche de preuve.
Planifiez la maintenance des versions prises en charge et clarifiez, selon la catégorie, l’évaluation de conformité et la documentation technique nécessaires.
Marquage CE des logiciels et preuve relative au produit.
La preuve CRA repose sur une évaluation de conformité propre au produit. La Commission explique, à propos de l’art. 32 CRA, qu’une évaluation interne est possible pour la catégorie standard. Certains produits importants ou critiques nécessitent des procédures plus strictes avec un organisme notifié ou d’autres voies admissibles. La fonction réelle détermine la catégorie ; un nom commercial ne suffit pas.
La déclaration UE de conformité et le marquage CE suivent la procédure applicable. Ils ne constituent ni un certificat général pour l’entreprise entière ni une promesse d’absence permanente de vulnérabilités. Une durée de certificat uniforme ne décrit donc pas correctement le CRA : la documentation, le traitement des vulnérabilités et les obligations applicables doivent être considérés sur le cycle de vie pertinent.
Autres référentiels et obligations distinctes.
ISO 27001 organise un système de management de la sécurité de l’information ; son certificat ne confirme pas à lui seul la conformité CRA d’un produit. NIS2 concerne les entités assujetties et leur organisation de sécurité. Le RGPD protège les données personnelles ; un événement produit peut donc soulever des questions supplémentaires de protection des données. Les processus apparentés peuvent être coordonnés, mais leurs déclencheurs juridiques et leurs preuves restent à examiner séparément.
Dans Secani.
Secani contient un catalogue de travail éditorial CRA avec des sources, des questions d’évaluation et des exemples de preuves. Le profil d’entreprise recense notamment les rôles et la date d’évaluation ; les conditions non clarifiées restent visibles comme points à vérifier. Cet outil aide à organiser l’examen, mais ne confirme ni la classification juridique ni la conformité d’un produit.
Commencer par un produit délimité.
Choisissez un produit concret et clarifiez d’abord ses limites, l’entité juridique responsable et les personnes chargées des notifications de sécurité. Examinez ensuite les obligations actuelles et futures qui le concernent. Cette approche rend la préparation maîtrisable et évite qu’un projet général de conformité masque la capacité de notification déjà nécessaire.
Sources.
- Règlement (UE) 2024/2847 – Cyber Resilience Act
- Commission européenne : Cyber Resilience Act et dates d’application
- Commission européenne : résumé de l’acte
- Commission européenne : obligations des fabricants
- Commission européenne : évaluation de la conformité
- Commission européenne : CRA et logiciels libres
- Commission européenne : lignes directrices C(2026) 5252 avec annexe
Questions fréquentes.
Oui, les notifications de l’art. 14 CRA s’appliquent aux fabricants concernés depuis le 11 septembre 2026. Les obligations générales relatives aux produits commencent le 11 décembre 2027 ; les rôles particuliers et les transitions doivent être examinés séparément.
Non, l’appellation SaaS ne détermine pas le champ d’application. Examinez le produit logiciel, ses fonctions et le traitement de données à distance associé à partir de l’architecture concrète.
Non, le traitement particulier des contributions libres en amont n’exonère pas globalement le fabricant du produit commercial de ses obligations. Le rôle de fabricant et un éventuel rôle d’intendant doivent être distingués.
Non, un certificat ISO 27001 porte sur un système de management délimité. Le CRA exige un examen distinct du produit et la preuve de conformité applicable.
Organiser la sécurité des produits de manière traçable.
Traiter de manière structurée les exigences CRA et leur évaluation avec Secani.
Cette page explique le Cyber Resilience Act de manière générale et ne remplace pas une analyse juridique de chaque produit. Les actes en vigueur font foi.