Résumé pour la direction

L’obligation de notification du CRA s’applique à partir du 11 septembre 2026 ; la majeure partie des obligations à partir du 11 décembre 2027
Notifier exige une alerte précoce dans les 24 heures — et donc un pouvoir de décision attribué à l’avance
La question du rôle (fabricant, importateur, distributeur) détermine vos obligations et surprend régulièrement les entreprises
Un SBOM n’est pas une contrainte administrative mais l’instrument qui rend les délais de notification tenables
Déterminer le scope est un travail juridique avec une réponse technique ; mener ces deux conversations séparément est la principale source de retard
Les clients demandent la documentation CRA bien avant l’échéance légale

Cyber Resilience Act : du règlement au plan d’implémentation

À partir du 11 septembre 2026, les fabricants doivent notifier les vulnérabilités activement exploitées et les incidents graves au titre du Cyber Resilience Act. Le reste du règlement suivra le 11 décembre 2027. Cet ordre est frappant : l’obligation de notification arrive avant les exigences applicables aux produits au regard desquelles il faudrait notifier.

Pour qui met des produits comportant des éléments numériques sur le marché de l’UE, cela a une conséquence très concrète. Dès ce mois-ci, vous avez besoin d’un processus de notification, même si votre dossier de conformité est encore loin d’être finalisé. Et ce processus exige des décisions qui, dans beaucoup d’entreprises, ne relèvent aujourd’hui de personne.

NIS2 regarde votre organisation. Le CRA regarde votre produit. Cette différence détermine qui doit agir dans votre entreprise — et c’est rarement la même personne.

Qu’est-ce que le Cyber Resilience Act ?

Le Cyber Resilience Act, règlement (UE) 2024/2847, fixe des exigences de cybersécurité pour les produits comportant des éléments numériques mis à disposition sur le marché européen. Le raisonnement est simple : lorsque des logiciels et du matériel connecté arrivent sur le marché sans être sécurisés, le problème est reporté sur l’utilisateur, qui ne peut pas y faire grand-chose.

Le règlement s’inscrit dans le modèle européen de législation sur les produits. Il amène donc des notions qui ne viennent pas du monde de la security mais du marché intérieur : making available, placing on the market, intended use, mauvaise utilisation raisonnablement prévisible, et surtout modification substantielle — le moment où une mise à jour remet juridiquement votre produit sur le marché.

Pour les équipes security, ce vocabulaire est nouveau. Pour les juristes, ce sont les exigences techniques qui le sont. C’est précisément là que réside la difficulté de ce dossier.

Quels produits relèvent du CRA ?

C’est la question par laquelle commencent la plupart des trajets d’implémentation — et sur laquelle ils butent.

Un produit comportant des éléments numériques est une notion plus large que ce que la plupart des gens imaginent. Elle couvre les logiciels et le matériel disposant d’une connexion de données, y compris les composants logiciels distincts et certaines solutions de traitement de données à distance qui font fonctionnellement partie du produit. Qu’un produit entre ou non dans le scope dépend notamment du critère de core functionality.

S’y ajoute la question des composants : que se passe-t-il si votre produit repose sur des éléments de tiers, ou sur des logiciels libres et open source ? Le règlement prévoit pour cela une obligation de due diligence et un régime particulier pour l’open source.

Reste enfin la question du rôle. Fabricant, quasi-fabricant, importateur, distributeur ou mandataire : chaque rôle entraîne des obligations différentes. Des entreprises qui pensent se limiter à la distribution s’avèrent régulièrement être fabricants — par exemple parce qu’elles vendent un produit sous leur propre marque.

La question du scope est juridique. La réponse vient de l’engineering. Sans les deux, vous n’y arriverez pas.

Qu’est-ce qui change le 11 septembre 2026 ?

À partir de cette date, l’obligation de notification de l’article 14 s’applique. Concrètement, elle porte sur deux volets : les vulnérabilités activement exploitées dans votre produit, et les incidents graves ayant un impact sur sa sécurité.

Le rythme est serré. Une alerte précoce dans les 24 heures après en avoir pris connaissance, une notification plus détaillée dans les 72 heures, puis un rapport final — dans les quatorze jours suivant la mise à disposition d’une mesure corrective pour une vulnérabilité activement exploitée. La notification passe par le canal européen prévu à cet effet, avec l’implication du CSIRT national et de l’ENISA.

Vingt-quatre heures, c’est court. Non pas parce que c’est techniquement difficile, mais parce qu’il faut prendre rapidement une décision : s’agit-il d’une vulnérabilité activement exploitée, et qui, dans notre entreprise, peut le constater ?

Le problème est rarement que l’entreprise ne sait pas corriger une vulnérabilité. Le problème est que personne n’est désigné pour décider qu’il s’agit d’une vulnérabilité à notifier. Ce n’est pas une question technique. C’est un choix de gouvernance à faire avant le premier incident, pas après.

SBOM, gestion des vulnérabilités et documentation

Les exigences de fond de l’annexe I se traduisent en une to-do list concrète. Trois d’entre elles reviennent dans pratiquement tous les trajets.

L’évaluation des risques est le point de départ : quelles exigences de l’annexe I s’appliquent à ce produit, et pourquoi. Ce raisonnement doit pouvoir être documenté, car il porte tout le reste de votre dossier.

Le SBOM — la software bill of materials — recense les composants dont votre produit est constitué. Ce n’est pas une fin en soi. C’est l’instrument qui vous permet d’établir dans les 24 heures si une vulnérabilité nouvellement publiée touche votre produit. Sans SBOM, chaque notification commence par des jours de recherche.

La gestion des vulnérabilités est le processus qui l’entoure : comment vous recevez, évaluez, corrigez et communiquez les signalements, et comment vous déployez des mises à jour de sécurité pendant la période de support.

S’y ajoutent des documents à produire : la documentation technique, la déclaration UE de conformité et les informations et instructions destinées à l’utilisateur. Ce sont les pièces que vous présentez lors d’un contrôle du CCB ou du SPF Économie — et que vos clients demandent de plus en plus souvent dans leurs questionnaires, bien avant l’échéance légale.

Pourquoi ce travail est à la fois juridique et technique

La plupart des trajets CRA n’échouent pas par manque de volonté, mais sur un problème de traduction. Le legal peut déterminer ce qu’est une modification substantielle, mais pas si cette release en est une. L’engineering sait ce que contient la release, mais pas quelles en sont les conséquences juridiques.

Tant que ces deux conversations se tiennent séparément, le dossier reste bloqué au stade d’une analyse du scope que personne n’ose clôturer. Les organisations qui avancent réunissent le juriste et le responsable de la product security autour de la même table — et leur donnent le même vocabulaire.

Par où commencer ?

Dressez la liste de vos produits. Tout ce que vous mettez sur le marché de l’UE, y compris les logiciels que vous livrez avec vos produits ou que vous proposez.
Déterminez votre rôle par produit. Fabricant, importateur, distributeur ou mandataire — cela peut varier d’une gamme de produits à l’autre.
Vérifiez le scope à l’aide du critère de core functionality et déterminez la classification.
Mettez en place votre processus de notification. Qui reçoit, qui évalue, qui décide dans les 24 heures, qui notifie. Formalisez-le par écrit et testez-le.
Construisez votre SBOM pour au moins un produit, en guise de projet pilote. Vous ne découvrez les obstacles pratiques qu’en le faisant réellement une fois.
Planifiez le dossier de conformité en vue du 11 décembre 2027, avec l’évaluation des risques comme première pierre.

Construisez votre propre implémentation CRA en deux jours

CRA Lead Implementer ne s’arrête pas à l’explication de la loi. Vous construisez vous-même l’implémentation : scope, classification, SBOM, processus de notification et documentation, pour vos propres produits. Apportez votre liste de produits — vous la classifiez dès le premier jour.

La formation est donnée conjointement par un juriste spécialisé en cybersécurité et un expert en product security : Pedro Demolder (avocat IP/IT et protection des données chez Timelex) et Maxim Baele (product security chez Toreon, chapter leader d’OWASP Belgique). Question juridique, réponse technique, et inversement.

Ce que vous en retirez :

savoir quels produits entrent dans le scope et dans quelle classe ils se situent
un processus de notification qui respecte les délais
l’annexe I traduite en une to-do list concrète
une documentation technique et une déclaration UE de conformité construites
une feuille de route défendable pour votre management

18–19 novembre 2026 — Park Inn by Radisson Diegem. La formation est donnée en anglais.
20 participants maximum.
Vous passez un examen et recevez, en cas de réussite, le certificat « CRA Lead Implementer » — pas une attestation de participation.
L’accès à des sessions de mise à jour annuelles est inclus, afin que votre certificat évolue avec les nouvelles normes et réglementations.
1 495 € HTVA, 1 195 € pour les institutions publiques.

Découvrez le programme complet et inscrivez-vous dès aujourd’hui

Sources et pour aller plus loin

Règlement (UE) 2024/2847 (Cyber Resilience Act) — EUR-Lex
Commission européenne, page de mise en œuvre et FAQ sur le CRA
Centre pour la Cybersécurité Belgique (CCB)
NIS2 Lead Implementer Belgique — pour le volet organisation, à côté du volet produit

Questions fréquentes

Quand le CRA s’applique-t-il exactement ?

Le règlement est entré en vigueur en décembre 2024. L’obligation de notification de l’article 14 s’applique à partir du 11 septembre 2026. La majeure partie des obligations deviendra applicable le 11 décembre 2027.

Le CRA nous concerne-t-il aussi si nous ne fabriquons pas de matériel ?

Oui. Les logiciels relèvent de la notion de produit comportant des éléments numériques. Les composants distincts et certaines solutions de traitement de données à distance peuvent aussi entrer dans le scope.

Et si nous nous contentons de revendre ?

Vous êtes alors en principe distributeur, avec des obligations plus légères mais bien réelles. Attention : quiconque met un produit sur le marché sous son propre nom ou sa propre marque, ou le modifie substantiellement, devient fabricant, avec toutes les obligations qui en découlent.

Comment le CRA s’articule-t-il avec NIS2 et le RGPD ?

Ils se recoupent sans se couvrir mutuellement. NIS2 vise la cybersécurité des entités, le CRA les propriétés des produits. Le RGPD continue par ailleurs de s’appliquer dès que des données à caractère personnel sont traitées. Un même incident peut donc relever de plusieurs régimes de notification.

Un SBOM est-il obligatoire ?

L’établissement d’un SBOM couvrant au moins les dépendances de premier niveau fait partie des exigences en matière de gestion des vulnérabilités. En pratique, c’est en outre le seul moyen réaliste de respecter les délais de notification.

Faut-il être juriste ou ingénieur pour suivre cette formation ?

Ni l’un ni l’autre, et aucune connaissance préalable n’est requise. Le tandem juridique et technique est justement le principe de la formation : n’hésitez pas à venir avec un collègue de l’autre discipline.

Loi sur la cyber-résilience : obligation de signalement à compter du 11 septembre