La plupart des calendriers de mise en conformité indiquent que la loi sur la cyber-résilience (Cyber Resilience Act) entrera en vigueur en décembre 2027. C’est à cette date que s’appliqueront les dispositions de fond du règlement : sécurité dès la conception, documentation technique, évaluation de la conformité et marquage CE.
Cependant, les obligations de déclaration interviennent bien plus tôt. À compter du 11 septembre 2026, les fabricants de produits comportant des éléments numériques devront signaler les vulnérabilités activement exploitées et les incidents graves dans des délais définis, et ces obligations s’étendent aux produits déjà mis sur le marché de l’UE. Un produit commercialisé pour la première fois en 2018 et toujours vendu aujourd’hui entre dans le champ d’application dès le premier jour.
Pour les fabricants, cela introduit un délai de signalement de 24 heures. Pour la population bien plus importante d’organisations qui achètent et exploitent des technologies plutôt que de les mettre sur le marché, la CRA introduit un élément moins visible et pour lequel elles sont nettement moins préparées : un nouveau flux de notifications de sécurité provenant de tiers, selon leur calendrier et non le vôtre.
À deux semaines de la date butoir, très peu d’organisations ont déterminé qui serait chargé de les recevoir.
Aucune déclaration n’est due à la date elle-même. Il n’y a ni déclaration à déposer ni formulaire à remplir. Le 11 septembre marque le moment où les obligations liées aux événements prennent effet, ce qui rend la planification plus difficile qu’avec une échéance classique. Le déclencheur est un incident, et les incidents ne respectent pas les calendriers.
Pour les fabricants, le cadre est clair. Dès qu’une organisation constate qu’une vulnérabilité de l’un de ses produits est activement exploitée, elle dispose de 24 heures pour émettre une alerte précoce, de 72 heures pour fournir une notification plus complète, puis d’un délai défini pour soumettre un rapport final. Les sanctions en cas de non-respect des obligations fondamentales des fabricants prévues par le règlement peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.
La question de savoir si une organisation entre dans cette catégorie est abordée ci-dessous. D’une manière plus générale, et cela n’a guère retenu l’attention jusqu’à présent, l’effet opérationnel le plus immédiat du CRA se fera sentir sur les organisations qu’il ne réglemente pas directement.
Il convient de s’attarder sur la chronologie des mesures qui entreront en vigueur en septembre.
La plateforme de signalement gérée par l’ENISA devrait être opérationnelle à cette date, et non avant. Les normes harmonisées qui définiront les modalités de conformité pour les fabricants font toujours l’objet d’une consultation publique. Et l’obligation de mettre en place une politique coordonnée de divulgation des vulnérabilités — mécanisme par lequel les fabricants apprennent le plus souvent que leurs produits font l’objet d’exploitations — ne deviendra généralement applicable qu’en décembre 2027.
L’obligation de signalement précède donc l’obligation de mettre en place le canal par lequel la plupart des signalements sont émis.
Il ne s’agit pas d’un oubli. Cela reflète un changement délibéré dans la manière dont la réglementation numérique de l’UE est séquencée : les obligations sont mises en place par étapes et entrent en vigueur avant l’infrastructure qui les soutient, partant du principe qu’attendre la mise en place complète des outils retarderait de plusieurs années la réduction des risques. La directive NIS2 a suivi ce modèle. La loi sur l’IA l’a suivi. La CRA le suit désormais.
Pour les fonctions GRC, l’implication est structurelle plutôt que tactique. Les programmes de conformité doivent de plus en plus souvent fonctionner dans l’intervalle entre l’entrée en vigueur d’une obligation et la maturation de l’écosystème qui l’entoure. Planifier en partant du principe que la réglementation arrive déjà au point revient à planifier selon un modèle qui n’est plus d’actualité.
Cela justifie une évaluation brève mais réfléchie, car les exceptions ont un coût élevé.
Peu d’organisations se décrivent comme des fabricants. La réglementation ne se fonde pas sur l’autodéfinition. Elle prend en compte ce qui est mis sur le marché de l’UE et sous quel nom ou quelle marque. Le matériel sous marque propre, les micrologiciels intégrés, les appareils connectés revendus sous le logo de l’entreprise et les logiciels intégrés à un produit physique peuvent tous faire entrer une organisation dans le champ d’application de la réglementation. Les importateurs et les distributeurs qui rebaptisent un produit ou le modifient de manière substantielle assument par là même les obligations du fabricant.
La question pertinente n’est donc pas de savoir si une organisation développe des logiciels. Elle est la suivante : qu’est-ce que l’organisation met sur le marché de l’UE, sous quel nom, et que contient ce produit ?
Nous vous recommandons de consigner la réponse par écrit cette semaine. Pour la plupart des organisations, il s’agit d’un exercice rapide. Pour une minorité d’entre elles, cela fait la différence entre un programme maîtrisé et un programme imprévu.
Outre ses obligations envers les autorités, la CRA exige qu’un fabricant qui prend connaissance d’une vulnérabilité activement exploitée ou d’un incident grave informe les utilisateurs concernés, et le cas échéant tous les utilisateurs, en leur indiquant les mesures d’atténuation qu’ils peuvent prendre. Si un fabricant ne le fait pas dans un délai raisonnable, le CSIRT national de coordination peut communiquer ces informations directement.
Du point de vue du destinataire, cela crée un flux entrant entièrement nouveau. À compter du 11 septembre, les organisations commenceront à recevoir des notifications de sécurité concernant des produits présents dans leur propre environnement, émises par le fabricant de ces produits, qui n’est souvent pas la partie avec laquelle elles entretiennent une relation commerciale.
Il en découle trois conséquences.
La responsabilité n’est pas clairement définie. Ces notifications parviennent généralement à un chargé de compte, au service des achats ou dans une boîte mail partagée consultée pendant les heures de bureau. D’après notre expérience, les avis de vulnérabilité émis par les fournisseurs sont rarement acheminés vers le triage des incidents de manière systématique. Ils sont transmis de manière informelle par toute personne qui en reconnaît l’importance.
La notification déclenche une évaluation, et non un signalement. Cette distinction est souvent mal comprise et mérite d’être précisée. Un avis de fabricant ne constitue pas en soi un incident devant faire l’objet d’un signalement. Le fait qu’elle en devienne un au titre de la directive NIS2 ou de la réglementation DORA dépend de l’impact significatif sur les propres services de l’organisation, ce qui est rarement évident au cours de la première heure. C’est précisément l’argument en faveur d’une structuration de cette première heure. Lorsque le seuil est atteint par la suite, l’organisation devra prouver à quel moment elle en a pris connaissance.
Les contrats n’abordent pas cette question à l’heure actuelle. Rares sont les accords avec les fournisseurs qui précisent le canal de notification, le format, le destinataire désigné ou le délai prévu. À cet égard, la CRA apporte aux services d’approvisionnement ce qui leur faisait défaut jusqu’à présent. Pendant une décennie, l’assurance de la sécurité des fournisseurs s’est largement appuyée sur des questionnaires dont la force contractuelle était limitée. La réglementation établit désormais une base de référence à partir de laquelle des engagements spécifiques peuvent être négociés : l’accès à une liste des composants logiciels (SBOM), une politique de divulgation publiée, une période de support définie et des modalités de notification convenues. Il convient de noter que la CRA oblige les fabricants à établir une nomenclature logicielle (SBOM) ; elle ne les oblige pas à la fournir à leurs clients. C’est précisément à cela que servent les renouvellements de contrats, et la plupart de ces renouvellements interviendront bien avant décembre 2027.
Chaque délai prévu par ce régime court à compter du moment de la prise de connaissance.
La Commission européenne a abordé cette question au niveau des fabricants, en publiant en juillet 2026 des lignes directrices qui expliquent à quel moment un fabricant est considéré comme ayant pris connaissance de la situation. Ce qu’aucune ligne directrice externe ne peut déterminer, c’est qui, au sein d’une organisation donnée, est habilité à en prendre connaissance en son nom.
Dans la pratique, le signal arrive par l’intermédiaire d’un ingénieur support à 19 h, d’un chercheur écrivant à une adresse e-mail générique, ou de l’équipe des opérations de sécurité d’un client contactant un chargé de compte en congé.
Le parallèle avec le RGPD est instructif. Des violations ont été déclarées avec plusieurs semaines de retard, non pas par dissimulation, mais en raison d’un défaut de classification. Le service d’assistance a enregistré le problème comme un défaut. Le service informatique l’a traité comme une erreur de configuration. Personne ne s’était mis d’accord sur ce qui constituait un événement à signaler, l’évaluation n’a jamais été lancée, et le service juridique n’en a pris connaissance que lorsqu’un client a soulevé la question.
Trois éléments doivent être consignés par écrit avant le 11 septembre : les critères déclenchant une évaluation immédiate, les personnes habilitées à faire remonter l’information et à prendre une décision en dehors des heures de bureau, ainsi que le registre dans lequel cet événement est consigné.
Deux semaines ne suffisent pas pour mettre en place un programme complet d’évaluation des risques de cyberattaques (CRA). Elles suffisent toutefois pour mettre en place les éléments qui doivent fonctionner en priorité.
Pour les organisations commercialisant des produits sur le marché de l’UE :
Pour toutes les autres organisations :
Le dernier point est le seul qui permette de vérifier si les autres fonctionnent.
Une organisation peut déployer tous les outils disponibles et pourtant passer à côté du moment crucial.
Une alerte précoce ne peut pas être déclenchée sur la seule base d’un certificat. Un produit ne peut pas être classé par une politique. Et une évaluation en 24 heures ne peut pas être menée selon un processus qui n’existe que sous la forme d’un document que personne n’a jamais mis en pratique.
Les organisations qui géreront bien le mois de septembre seront celles au sein desquelles une personne désignée, contactée à 19 h un samedi, comprend qu’elle est habilitée à agir.
Quelle que soit la technologie, tout commence par une bonne dose de gouvernance.
Deux semaines ne suffisent pas pour mettre en place un programme CRA, mais elles suffisent pour répondre aux deux questions soulevées par cet article : la réglementation s’applique-t-elle à votre organisation, et qui reçoit la notification lorsqu’elle arrive ?
Nos services CRA couvrent la détermination du champ d’application, la préparation aux déclarations au titre de l’article 14, l’acheminement des notifications des fournisseurs, ainsi que l’intégration des obligations CRA dans les programmes NIS2 et DORA déjà en cours.
Nous encourageons les organisations à engager cette discussion avant le 11 septembre. Passé cette date, la donne aura changé.