Le règlement sur la cyberrésilience : votre produit, pas votre parc

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.

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. Selon le calendrier de l'ENISA, cette plateforme est opérationnelle au 11 septembre 2026 ; son adresse est publiée sur la page de l'ENISA consacrée à la plateforme avant la mise en service, l'accès se fait par un compte EU Login, et l'ENISA recommande de ne s'enregistrer qu'au moment de déposer une notification. Si la plateforme est temporairement indisponible, la consigne de l'ENISA est d'attendre son rétablissement pour soumettre, en ne contactant directement le CSIRT que si une communication immédiate est nécessaire. Vérifié le 4 septembre 2026 sur la base de la FAQ de l'ENISA du 31 août 2026.

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 donc 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 nous prouvons, dit précisément

Notre rapport de preuve 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 nous n'évaluons 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.

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 nous n'en observons 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 à vous, et où SkyQon aide désormais

Le rapport les nomme parce que les fabricants supposent souvent qu'un programme de sécurité d'entreprise existant les couvre déjà. En général, non. Ce sont des obligations côté produit, citées ou dérivées du texte du Journal officiel, et elles restent celles du fabricant. Ce qui a changé depuis la première rédaction de ce guide : SkyQon propose désormais une étape pour chacune d'elles, un contrôle gratuit du champ d'application et de la classe, une analyse des écarts à prix fixe, un sprint de mise en œuvre, le kit de signalement, et le module complémentaire CRA Product Evidence dans le tableau de bord, qui conserve le registre des produits, les points d'écart, le SBOM, les preuves de mise à jour et les projets de documents comme un dossier vivant avec un rapport signé par produit. Aucune de ces étapes ne déclare la conformité ; chacune laisse une preuve ou un document que vous pouvez assumer.

• 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 une entrée utile pour ce travail ; c'est un artefact différent sur un système différent, et il ne s'acquitte pas de l'obligation. Où SkyQon aide : le sprint de mise en œuvre produit le SBOM à partir de votre système de build ; le module SBOM du tableau de bord prend le fichier CycloneDX ou SPDX par version, conserve l'historique et rapproche les composants chaque jour d'OSV.dev et de la NVD, avec CISA KEV et EPSS. Seuls les identifiants de paquets quittent la plateforme.
• 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 possible (partie II, point 2). Où SkyQon aide : l'analyse des écarts montre d'abord ce qui manque ; le sprint rédige le processus de gestion des vulnérabilités ; le journal de réception et de correction du tableau de bord horodate chaque étape, de la réception à la publication de l'avis, et rédige l'avis.
• 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. Où SkyQon aide : le sprint rédige la politique et le security.txt qui l'accompagne ; le tableau de bord conserve la politique consignée et contrôle le security.txt.
• La distribution sécurisée des mises à jour de sécurité. Diffusées sans délai et gratuitement, avec des messages d'avis (partie II, points 7 et 8). Où SkyQon aide : le sprint documente le mécanisme de mise à jour et son identité de signature comme preuve ; le module de mises à jour sécurisées consigne, par produit, le mécanisme, si les mises à jour de sécurité sont séparées et gratuites, la période de disponibilité, l'identité de signature du code et la posture TLS du point de mise à jour.
• Configuration sécurisée par défaut et mises à jour par défaut. Des propriétés du produit fixées à la conception (partie I, point 2, b) et c)) qu'aucun observateur externe ne voit jamais. Où SkyQon aide : l'analyse des écarts consigne leur statut à partir de vos documents et entretiens, avec la justification que demande l'article 13 lorsqu'une exigence ne s'applique pas ; le registre des produits conserve ce statut, le responsable, l'échéance et les pièces justificatives par exigence, avec l'historique, et le générateur de documents transforme le registre en projets d'annexe VII, d'annexe II et d'annexe V que vous signez.
• 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. Où SkyQon aide : le kit de signalement en 24 heures et le module complémentaire Incident Reporting tiennent la procédure, les horloges et la trace ; un composant exploité activement dans votre SBOM propose de lancer en un clic l'horloge de l'article 14, et une personne décide.

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. La vérification gratuite du champ et de la classe donne une première réponse avec les articles cités.
• Répétez l'horloge de l'article 14 : elle court à partir du 11 septembre 2026. Faites l'exercice : vulnérabilité exploitée signalée un vendredi soir. Qui en prend connaissance, quand, et qui détient le compte EU Login pour déposer sur la plateforme 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

Guide compagnon : NIS2 article 21(2), ce qui constitue une preuve · DORA : ce qui constitue une preuve technique