Le règlement sur la cyberrésilience : votre produit, pas votre parc
Le CRA régit le produit comportant des éléments numériques que vous mettez sur le marché — un système distinct de l'infrastructure sur laquelle vous l'exploitez. La majeure partie du marché de la conformité brouille cette frontière ; ce guide la trace. Ce que demande le règlement, les échéances qui tombent avant 2027, la part restreinte qu'un observateur externe peut étayer, et la liste plus longue qui reste la vôtre quoi que vous achetiez.
Rédigé par l’équipe d’ingénierie SkyQon · Dernière vérification : 6 août 2026
Ce que régit le CRA
Le règlement (UE) 2024/2847 fixe des exigences de cybersécurité pour les produits comportant des éléments numériques — logiciels et matériels mis sur le marché de l'UE, avec leurs solutions de traitement de données à distance. C'est une législation produit dans la tradition du marquage CE : évaluation de la conformité à l'article 32, déclaration UE de conformité à l'article 28, marquage CE à l'article 30, surveillance du marché à l'article 52. Ses plus proches parents sont les directives jouets et machines, pas NIS2.
Cette filiation détermine qui porte les obligations. Elles pèsent sur le fabricant — l'article 13 en aligne vingt-cinq paragraphes — les importateurs et distributeurs assumant leurs propres devoirs en aval, et l'article 24 réservant aux gestionnaires de logiciels libres un régime délibérément allégé. Il n'existe pas de test « d'entité concernée » comme dans NIS2 : si vous mettez un produit visé sur le marché de l'UE, vous êtes concerné.
La substance se trouve à l'annexe I. La partie I énumère les propriétés de sécurité que le produit lui-même doit présenter — configuration sécurisée par défaut, protection de la confidentialité et de l'intégrité, réduction de la surface d'attaque, et le reste. La partie II énumère les exigences de gestion des vulnérabilités : un SBOM couvrant au moins les dépendances de premier niveau du produit, la correction des vulnérabilités sans retard, une politique de divulgation coordonnée, et la distribution sécurisée des mises à jour de sécurité.
Texte officiel: Regulation (EU) 2024/2847
Les échéances, et celle qui arrive en premier
Le règlement est entré en vigueur le 10 décembre 2024 et s'applique intégralement à partir du 11 décembre 2027. Deux volets arrivent plus tôt : le chapitre IV, sur les organismes notifiés, s'applique depuis le 11 juin 2026 — et l'article 14, l'obligation de notification, s'applique à partir du 11 septembre 2026.
L'article 69, paragraphe 2, adoucit le tableau pour les produits existants : ce qui a été mis sur le marché avant le 11 décembre 2027 n'est saisi que s'il subit ensuite une modification substantielle. Puis l'article 69, paragraphe 3, retire cet adoucissement pour le volet le plus proche — par dérogation, l'article 14 s'applique à tous les produits visés déjà sur le marché. L'obligation de notification n'est ni reportée à 2027, ni limitée aux produits nouveaux.
La première obligation du CRA que la plupart des fabricants ressentiront est donc une horloge : à partir du 11 septembre 2026, une vulnérabilité activement exploitée dans un produit expédié il y a des années déclenche un compte à rebours de 24 heures. Au moment où nous écrivons, c'est dans cinq semaines.
Le plafond des sanctions donne leur poids aux échéances. L'article 64, paragraphe 2, prévoit des amendes administratives pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu, en cas de non-respect de l'annexe I ou des articles 13 et 14.
L'article 14, en pratique
Deux déclencheurs, un seul circuit. Le fabricant qui prend connaissance d'une vulnérabilité activement exploitée dans son produit, ou d'un incident grave ayant un impact sur la sécurité du produit, le notifie simultanément au CSIRT désigné comme coordinateur et à l'ENISA, via la plateforme unique de notification établie par l'article 16.
| Étape | Vulnérabilité activement exploitée | Incident grave |
|---|---|---|
| Alerte précoce | Dans les 24 heures suivant la prise de connaissance | Dans les 24 heures suivant la prise de connaissance |
| Notification | Dans les 72 heures — nature de l'exploitation, mesures correctives ou d'atténuation prises et à la disposition des utilisateurs | Dans les 72 heures — nature de l'incident, première évaluation, mesures prises et à la disposition des utilisateurs |
| Rapport final | Au plus tard 14 jours après qu'une mesure corrective ou d'atténuation est disponible | Dans le mois suivant la notification des 72 heures |
L'expression qui porte la charge est « prise de connaissance ». Le fabricant qui apprend l'exploitation le premier jour et commence à rédiger le sixième a déjà manqué deux échéances. Tenir une horloge de 24 heures est une propriété de votre chaîne de détection et d'escalade, pas de votre service juridique — c'est donc la seule partie de l'article 14 que l'on peut répéter à l'avance.
L'article 13 : les devoirs derrière le marquage CE
L'article 13 est le socle des obligations du fabricant. Le produit doit être conçu, développé et fabriqué conformément aux exigences essentielles de l'annexe I, sur la base d'une évaluation documentée des risques de cybersécurité, tenue à jour, qui détermine quelles exigences de l'annexe I s'appliquent et comment elles sont mises en œuvre.
L'article 13, paragraphe 8, ajoute l'engagement à la plus longue traîne : une période d'assistance, déterminée par la durée d'utilisation attendue du produit, et — sans préjudice de cette évaluation — d'au moins cinq ans, sauf si la durée d'utilisation attendue est plus courte. Pendant toute cette période, les vulnérabilités du produit et de ses composants doivent être gérées conformément à l'annexe I, partie II. Une période d'assistance est une promesse sur votre organisation d'ingénierie dans plusieurs années — elle relève de la planification produit, pas d'un classeur de conformité.
Autour de cela gravitent la diligence sur les composants tiers, la documentation technique, la voie d'évaluation de la conformité — auto-évaluation pour la classe par défaut, intervention d'un tiers pour les produits importants et critiques —, la déclaration de conformité et le marquage CE. Tout cela est le travail propre du fabricant, et rien n'en est observable de l'extérieur.
La frontière que le marketing de conformité brouille le plus
NIS2 régit une entité. DORA régit une entité financière et ses prestataires informatiques. Tous deux posent des questions sur une organisation, et une organisation laisse des traces observables — certificats, enregistrements DNS, politiques de messagerie, poignées de main TLS. C'est pourquoi un observateur externe peut honnêtement fournir une partie des preuves pour ces deux cadres.
Le CRA pose une question sur l'artefact expédié. Un observateur externe n'a jamais vu votre produit : ni son binaire, ni son mécanisme de mise à jour, ni sa configuration par défaut, ni son arbre de dépendances. Une organisation peut tenir un parc externe irréprochable et expédier malgré tout un produit non conforme — et l'inverse est tout aussi possible.
La conséquence honnête : aucun produit de surveillance, le nôtre compris, ne peut revendiquer une couverture de conformité CRA. Ce que la surveillance externe peut faire est plus étroit — prouver un petit nombre de propriétés de l'annexe I telles qu'elles apparaissent sur le parc du fabricant, clairement étiquetées comme portant sur le parc, plus une contribution réellement opérationnelle : la vitesse de détection que les horloges de l'article 14 supposent acquise.
Ce que SkyQon prouve, dit précisément
Le rapport de preuve SkyQon comporte une section CRA — ce n'est pas un produit distinct. La section s'ouvre sur une déclaration de portée disant, en toutes lettres, qu'elle ne constitue pas une déclaration de conformité au CRA et que SkyQon n'évalue pas de produits. Elle ne cartographie que deux propriétés de l'annexe I, et le texte de correspondance ci-dessous est repris mot pour mot dans le PDF signé depuis une correspondance réglementaire versionnée.
| Exigence de l'annexe I | Preuve fournie | Couverture |
|---|---|---|
| Part I, (2)(e) | Confidentialité : posture de chiffrement du transport sur le parc externe du fabricant — versions TLS, suites cryptographiques, robustesse des clés et préparation post-quantique, suivies dans le temps. | Parc uniquement — non revendiqué comme conformité du produit |
| Part I, (2)(f) | Intégrité : validation du chemin de confiance des certificats et statut de révocation — les identités que le fabricant présente à l'internet remontent-elles à une racine de confiance et sont-elles non révoquées. | Parc uniquement — non revendiqué comme conformité du produit |
Deux lignes, portant la même étiquette. Chacune s'accompagne dans le rapport d'une note de portée précisant ce que l'exigence régit à l'intérieur du produit — protections de la confidentialité dans l'artefact expédié, démarrage sécurisé, mises à jour signées — et le fait que SkyQon n'en observe rien. La seconde moitié de la section est la liste des obligations qui restent entièrement les vôtres, énumérées parce qu'une lacune que vous avez déclarée se lit tout autrement qu'une lacune qu'un évaluateur découvre.
Au-delà du rapport, la surveillance continue apporte une contribution opérationnelle à l'article 14 : la détection horodatée. Une horloge d'alerte de 24 heures devient tenable quand la prise de connaissance vient de la surveillance plutôt que d'un client, et le relevé daté du moment où vous en avez pris connaissance est le premier élément qu'un régulateur demandera.
Ce qui reste entièrement à vous
Le rapport les nomme parce que les fabricants supposent souvent qu'un programme de sécurité d'entreprise existant les couvre déjà. Ce n'est généralement pas le cas — ce sont des devoirs côté produit, et chacun est cité ou dérivé du texte du Journal officiel.
- Un SBOM du produit — lisible par machine, couvrant au minimum les dépendances de premier niveau du produit (annexe I, partie II, point 1). Un inventaire cryptographique de votre parc est un intrant utile à ce travail ; c'est un artefact différent portant sur un système différent, et il ne vous acquitte pas de l'obligation.
- Corriger sans retard les vulnérabilités du produit — y compris des mises à jour de sécurité livrées séparément des mises à jour fonctionnelles lorsque c'est techniquement faisable (partie II, point 2).
- Une politique de divulgation coordonnée des vulnérabilités — mise en place et appliquée (partie II, point 5). Une politique de sécurité d'entreprise existante n'est généralement pas cela.
- La distribution sécurisée des mises à jour de sécurité — diffusées sans retard et gratuitement, accompagnées de messages d'avis (partie II, points 7 et 8).
- Configuration sécurisée par défaut et mises à jour par défaut — des propriétés de conception du produit (partie I, points 2 b) et 2 c)) qu'aucun observateur externe ne voit jamais.
- La notification de l'article 14 elle-même — les notifications au CSIRT coordinateur et à l'ENISA vous incombent ; la surveillance peut déclencher votre horloge honnêtement, pas déposer à votre place.
Un enchaînement pratique
- Classez d'abord vos produits. Ce qui, dans ce que vous expédiez, constitue un produit comportant des éléments numériques, dans quelle classe il tombe, et quelle voie de conformité en découle. Tout le reste du CRA est cadré par cette réponse.
- Répétez l'horloge de l'article 14 avant septembre 2026. Faites l'exercice : vulnérabilité exploitée signalée un vendredi soir — qui en prend connaissance, quand, et qui détient les identifiants de la plateforme pour déposer sous 24 heures. Le parc installé est concerné, donc rien n'attend votre prochaine version.
- Construisez le SBOM depuis le système de build, pas depuis un questionnaire. Les listes de dépendances assemblées à la main pourrissent ; l'annexe I demande quelque chose qu'un pipeline peut régénérer à chaque version.
- Décidez la période d'assistance comme une décision produit. Cinq ans de gestion des vulnérabilités, c'est un engagement d'ingénierie. Chiffrez-le, dotez-le en personnel, et écrivez de quels composants vous dépendez auprès de tiers.
- Publiez la politique de divulgation. Une politique de divulgation coordonnée coûte peu à rédiger, est visible de tous, et c'est l'une des premières choses qu'une autorité de surveillance du marché peut vérifier sans rien vous demander.
- Gardez preuves du parc et conformité du produit dans des dossiers séparés. Les deux sont un vrai travail. Les mélanger, c'est ainsi que naissent les surdéclarations — et une surdéclaration sur un produit marqué CE, c'est une conversation avec une autorité de surveillance du marché.
Questions fréquentes
Quand le CRA s'applique-t-il ?
Intégralement à partir du 11 décembre 2027. Le chapitre IV, sur les organismes notifiés, s'applique depuis le 11 juin 2026, et les obligations de notification de l'article 14 s'appliquent à partir du 11 septembre 2026 — y compris, en vertu de l'article 69, paragraphe 3, aux produits déjà sur le marché.
Atteint-il des produits expédiés il y a des années ?
Pour les exigences générales, seulement si le produit subit une modification substantielle après le 11 décembre 2027. Pour la notification de l'article 14, oui — la dérogation de l'article 69, paragraphe 3, l'applique à tous les produits visés déjà sur le marché.
Le logiciel libre est-il concerné ?
Le logiciel fourni dans le cadre d'une activité commerciale l'est ; l'article 24 donne aux gestionnaires de logiciels libres un régime dédié plus léger. Les détails dépendent de la façon dont le logiciel est monétisé et fourni, et méritent d'être lus dans le texte plutôt que dans un résumé.
Quelle est la durée de la période d'assistance ?
Déterminée par la durée d'utilisation attendue, et d'au moins cinq ans sauf si le produit est censé servir moins longtemps (article 13, paragraphe 8). La gestion des vulnérabilités de l'annexe I, partie II, s'applique pendant toute cette période.
Un outil de surveillance peut-il nous rendre conformes au CRA ?
Non. La conformité est une propriété du produit et de sa documentation, évaluée selon l'article 32. La surveillance externe peut fournir des éléments d'appui côté parc et des horodatages de détection honnêtes ; un fournisseur qui revendique davantage décrit un système qu'il n'a jamais vu.
Comment le CRA s'articule-t-il avec NIS2 ?
Ils régissent des objets différents — le produit que vous expédiez et l'entité que vous êtes — et peuvent s'appliquer à vous simultanément. Les preuves sur votre parc servent NIS2 directement ; sous le CRA, les mêmes preuves ne sont que des éléments d'appui, et le rapport les étiquette ainsi.
Guide compagnon : NIS2 article 21(2) — ce qui constitue une preuve · DORA — ce qui constitue une preuve technique
Voyez ce que dit votre parc aujourd'hui
SkyQon ne vous vendra pas la conformité au CRA — personne ne le peut honnêtement. Ce qu'il vous apporte : les preuves côté parc, clairement étiquetées, dans le même rapport signé que celui de votre travail NIS2, et la vitesse de détection que supposent les horloges de l'article 14. Commencez par une vérification gratuite de votre parc externe.