Cyber Resilience Act : une loi produit, pas un programme de RSSI

Une loi produit, pas une loi d'organisation

NIS2 vous demande comment vous êtes organisés. DORA vous demande comment vous tenez le choc. Le Cyber Resilience Act régule autre chose : ce que vous mettez sur le marché. Différence de nature, pas de degré — et elle décide qui, chez vous, porte le sujet.

Le règlement (UE) 2024/2847 appartient à la famille du marquage CE, comme la réglementation machines ou celle des équipements radio : exigences essentielles en annexe, évaluation de conformité, marquage sur le produit, surveillance du marché habilitée à en exiger le retrait. C'est du droit des produits, pas de la gouvernance du risque.

Le CRA n'est donc pas le programme du RSSI mais celui de l'organisation produit. Le confier à la conformité SSI donne des politiques irréprochables et aucune preuve d'ingénierie : ce qu'attend un organisme notifié, c'est une analyse de risque par produit, des exigences tracées jusqu'aux décisions de conception, un canal de mise à jour signé. Wavatec écrit ces lignes des deux côtés du guichet — nous accompagnons des organisations sur EBIOS RM, NIS2 et DORA, et nous éditons Elyys360, ce qui fait de nous un fabricant.

Le calendrier est décalé, et le premier jalon est le plus proche

Entrée en vigueur le 10 décembre 2024. L'article 71 échelonne l'application : le chapitre IV, qui organise la notification des organismes d'évaluation de la conformité, s'applique depuis le 11 juin 2026 ; l'article 14, signalement des vulnérabilités activement exploitées et des incidents graves, à partir du 11 septembre 2026 ; tout le reste — exigences essentielles de l'annexe I, évaluation de conformité, marquage CE — le 11 décembre 2027.

L'inversion n'est pas un accident : une vulnérabilité exploitée dans la nature ne pouvait pas attendre trois ans de plus. Le législateur en tire une conséquence découverte tard. L'article 69, paragraphe 3, étend le signalement aux produits déjà mis sur le marché avant le 11 décembre 2027, alors que le reste du texte ne rattrape l'existant qu'en cas de modification substantielle. Votre parc installé entre donc dans le périmètre du signalement en septembre 2026.

Le signalement passe par une plateforme unique confiée à l'ENISA (article 16), qui route la notification vers le CSIRT coordinateur de votre établissement principal. Fin juin 2026, elle n'était toujours pas ouverte. Le délai, lui, court dès que vous avez connaissance du fait.

Vous êtes probablement concernés

Le champ couvre tout produit comportant des éléments numériques mis à disposition sur le marché de l'Union, matériel ou logiciel, composants vendus séparément compris : capteur industriel, automate, application mobile, firmware embarqué. Beaucoup d'industriels se croient hors sujet parce qu'ils fabriquent des machines et non « du numérique » : le critère n'est pas la nature du produit, c'est la présence d'éléments numériques et d'une connexion.

Les exclusions sont sectorielles : dispositifs médicaux (règlements 2017/745 et 2017/746), véhicules réceptionnés (2019/2144), aéronautique civile (2018/1139), équipements marins (directive 2014/90/UE), défense et informations classifiées. La réglementation machines (règlement 2023/1230), applicable au 20 janvier 2027, n'exclut rien : un constructeur devra satisfaire les deux textes. Et le règlement délégué (UE) 2022/30 sur la cybersécurité des équipements radio doit disparaître au 11 décembre 2027, la Commission ayant engagé son abrogation.

Classes de produits et routes d'évaluation

L'auto-évaluation est la règle par défaut ; elle cesse de l'être selon la fonctionnalité principale du produit, listée aux annexes III et IV et précisée techniquement par le règlement d'exécution (UE) 2025/2392 du 28 novembre 2025.

La classe I ne perd l'auto-évaluation que si les normes harmonisées ne sont pas appliquées. Or à la mi-2026, aucune norme harmonisée CRA n'était ratifiée ni citée au Journal officiel, sur les quarante et une prévues par la demande de normalisation M/606 acceptée en avril 2025 : la présomption de conformité de l'article 27 n'existe encore pour aucune catégorie, ce qui resserre l'échéance de 2027.

La clause dormante : la période de support

C'est l'obligation qui coûtera le plus cher, et rarement celle dont on parle.

L'article 13, paragraphe 8, impose de déterminer une période de support reflétant la durée pendant laquelle le produit est censé être utilisé, avec un plancher de cinq ans sauf si l'usage attendu est plus court. Le paragraphe 9 ajoute que chaque mise à jour de sécurité publiée reste disponible dix ans au moins, ou jusqu'à la fin du support si celle-ci est plus longue. Et la date de fin de support doit être communiquée clairement à l'acheteur au moment de l'achat.

Lisez cela en directeur produit. Vous ne pouvez plus arrêter une gamme le jour où elle cesse d'être rentable : la date d'arrêt est un engagement pris à la vente, pour cinq ans minimum. Il faut maintenir chaînes de compilation, environnements de test et compétences sur des versions que la feuille de route a quittées : chaque référence au catalogue crée une dette de maintenance datée. Le coût réel du CRA n'est pas dans le dossier technique, il tient à ce que la fin de vie devienne une décision contractuelle. Pour un éditeur, cela pousse vers moins de versions supportées en parallèle ; nous avons fait ce calcul pour Elyys360 avant de le faire pour nos clients. Pour un industriel qui livre du firmware sur du matériel installé quinze ans, c'est un problème de conception : le produit doit pouvoir recevoir une mise à jour signée pendant toute la période annoncée.

SBOM : nécessaire, insuffisant

L'annexe I, partie II, impose d'identifier et de documenter composants et vulnérabilités, notamment en établissant une nomenclature logicielle — un SBOM — dans un format lisible par machine couvrant au moins les dépendances de premier niveau. Il entre dans la documentation technique et se fournit aux autorités de surveillance du marché sur demande motivée, sans obligation de publication.

Le plancher légal est bas, et un SBOM qui s'y tient ne sert à rien. Quatre conditions le rendent utile : qu'il soit produit à la compilation, donc fidèle à l'artefact livré ; que les composants portent des identifiants résolvables, seuls capables d'alimenter une correspondance automatique avec les bases de vulnérabilités ; qu'il soit conservé pour chaque version encore supportée, sans quoi vous ne saurez pas dire quels clients sont exposés ; et qu'il s'accompagne d'une position d'exploitabilité, une bonne part des CVE remontées sur vos dépendances ne touchant pas le chemin de code que vous empruntez.

Le reste de la partie II compte autant : divulgation coordonnée, point de contact publié, correctifs diffusés sans délai et gratuitement. L'article 13 y ajoute une diligence sur les composants tiers, y compris libres, et l'obligation de remonter la vulnérabilité découverte au mainteneur amont.

Signaler en 24 heures

L'article 14 impose un enchaînement à trois temps, vers le CSIRT coordinateur et l'ENISA simultanément.

1. Une alerte précoce dans les 24 heures suivant la prise de connaissance.
2. Une notification étoffée dans les 72 heures, avec les mesures correctives ou d'atténuation.
3. Un rapport final : sous 14 jours après mise à disposition d'un correctif pour une vulnérabilité activement exploitée, sous un mois après la notification à 72 heures pour un incident grave.

Vingt-quatre heures, c'est un délai d'astreinte, pas un délai de comité : il suppose une détection qui remonte, une personne habilitée à qualifier « activement exploitée » un dimanche soir, et un modèle de notification prêt. Micro et petites entreprises ne sont pas passibles d'amende au seul titre d'un manquement à l'alerte précoce. Les autres le sont à hauteur de 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu — plafond commun à l'annexe I et aux articles 13 et 14 ; 10 millions ou 2 % pour les obligations procédurales ; 5 millions ou 1 % pour des informations trompeuses fournies à une autorité. L'amende n'est pourtant pas le vrai risque : la surveillance du marché peut exiger le retrait ou le rappel, et perdre une référence sur le marché européen coûte davantage, plus vite.

Open source : le steward, expliqué calmement

La panique de 2023 a laissé des traces, mais le texte adopté est mesuré. Un logiciel libre développé et fourni hors de toute activité commerciale reste hors du champ ; un contributeur individuel n'encourt rien ; quand un fabricant intègre une bibliothèque libre dans un produit commercialisé, c'est lui qui porte la conformité, pas l'amont.

Entre les deux, l'article 24 crée une figure intermédiaire : le steward de logiciel libre, personne morale autre qu'un fabricant, qui soutient de manière systématique et durable le développement d'un logiciel libre destiné à des activités commerciales et en assure la viabilité — typiquement une fondation. Ses obligations sont limitées : documenter une politique de cybersécurité, coopérer avec les autorités de surveillance du marché, signaler les vulnérabilités activement exploitées à partir du 11 septembre 2026. Ce qui ne s'applique pas compte autant : ni marquage CE, ni évaluation de conformité, ni dossier technique, et l'article 64, paragraphe 10, exclut toute amende administrative. L'article 32 laisse par ailleurs au fabricant d'un logiciel libre commercialisé les procédures du régime général s'il publie sa documentation technique.

Articulation avec NIS2, et l'écart réel entre entreprises

Le CRA et NIS2 ne se recouvrent pas, ils s'emboîtent. NIS2 impose à une entité essentielle ou importante de maîtriser sa chaîne d'approvisionnement ; le CRA lui donne un référentiel opposable pour le faire, ses fournisseurs devant produire documentation, période de support annoncée et canal de signalement. Attendez-vous à voir les preuves CRA entrer dans les appels d'offres bien avant décembre 2027 : les acheteurs soumis à NIS2 n'ont aucune raison d'attendre. Côté IA, l'article 12 ouvre une présomption de conformité aux exigences de cybersécurité de l'article 15 du règlement (UE) 2024/1689.

Reste l'écart entre entreprises. Celle qui pratique déjà un cycle de développement sécurisé mature — modélisation des menaces, gestion des dépendances, signature des artefacts, PSIRT constitué — trouvera dans le CRA un exercice de preuve : formaliser l'existant, tracer les exigences de l'annexe I, constituer le dossier technique de l'annexe VII. Douze à dix-huit mois de travail sérieux mais prévisible. Celle qui livre du firmware sans processus de mise à jour, sans inventaire de composants et sans point de contact vulnérabilités ne fait pas de la conformité : elle fait de la réingénierie produit. Ni le même budget ni le même calendrier — et confondre les deux au cadrage est la manière la plus sûre de rater 2027.

Ce qui doit être en place avant le 11 septembre

Trois choses, dont aucune ne dépend d'une norme harmonisée.

1. Savoir quels produits de votre catalogue entrent dans le champ, y compris ceux déjà installés chez vos clients, puisque le signalement les rattrape.
2. Un processus de qualification et de notification opérationnel en 24 heures : astreinte nommée, critère écrit de déclenchement, CSIRT coordinateur identifié, modèle prêt.
3. Un point de contact de divulgation publié et réellement surveillé, faute de quoi vous apprendrez l'exploitation active de vos vulnérabilités par la presse.

Le 11 décembre 2027 paraît loin. La période de support, elle, se décide maintenant : tout produit mis sur le marché à cette date portera un engagement de cinq ans au moins, et cet engagement se prend à la conception, pas à la déclaration de conformité.