Quelque chose s'est produit. Quand en avez-vous eu connaissance ?

Le règlement sur la cyberrésilience pour un petit fabricant de logiciels, en douze étapes

Tout ce qu'une entreprise de dix personnes qui livre un logiciel installé ou un appareil doit faire au titre du CRA, dans l'ordre où le faire : la détermination du champ d'application, le palier, le CSIRT et l'autorité d'application, la procédure de notification en vigueur depuis le 11 septembre 2026, puis le dossier technique, les 22 exigences, la SBOM, la période d'assistance, le marquage CE et la déclaration dus pour le 11 décembre 2027. Chaque étape avec son article et le texte qui l'explique.

À quel CSIRT notifier au titre de l'article 14 du CRA ? Les 27 coordinateurs, tels que l'ENISA les répertorie

Tous les guides sur l'obligation de notification du Cyber Resilience Act disent « notifiez votre CSIRT national » et s'arrêtent là. Depuis le 10 septembre 2026, l'ENISA publie le CSIRT désigné comme coordinateur pour chacun des 27 États membres. Voici cette liste, la règle qui détermine l'État, et les deux États où le coordinateur n'est pas le CSIRT national.

Comment déposer une notification CRA sur la plateforme unique de l'ENISA, d'après son propre manuel

La plateforme a ouvert le 11 septembre 2026 à l'adresse portal.cra-srp.enisa.europa.eu. Qui peut se connecter, quel coordinateur choisir, ce que chacune des trois soumissions demande, ce que le compteur de la plateforme calcule mal, et quand vous pouvez demander que la diffusion soit retardée. Lu dans les guides, la FAQ, le glossaire et les conditions d'utilisation de l'ENISA, pas dans un résumé.

Quand démarre l'horloge de 24 heures du CRA ? La « prise de connaissance », d'après les orientations de la Commission

Les 24 et 72 heures courent à partir du moment où le fabricant « a connaissance », et le règlement ne dit jamais ce que cela signifie. Les orientations de la Commission du 27 juillet 2026 le disent, aux paragraphes 211 à 218 : un degré raisonnable de certitude, après une évaluation initiale, repris mot pour mot du règlement d'exécution NIS2 et des lignes directrices sur les violations de données du RGPD. Ce que cela fait d'un courriel de client, d'une alerte de scanner, d'une CVE listée dans un composant, d'un zero-day de bug bounty et d'une vulnérabilité que vous connaissiez avant le 11 septembre.

Le délai du rapport final du CRA ne part pas du moment où vous avez connaissance

La plupart des présentations de l'article 14 du règlement sur la cyberrésilience donnent trois délais depuis un seul point de départ : 24 heures, 72 heures, 14 jours. Les deux premiers partent de la connaissance. Le troisième non, et pour une vulnérabilité son point de départ est une date qui peut ne pas encore exister. Voici ce que dit le règlement, paragraphe par paragraphe.

Votre produit entre-t-il dans le champ du règlement sur la cyberrésilience ? Où se situe le SaaS

La question la plus posée sur le CRA n'est pas comment notifier, c'est si le règlement s'applique à vous. Le pur logiciel en tant que service est hors champ et relève de NIS2 ; le logiciel installé et téléchargeable est dedans ; le traitement à distance sans lequel un produit ne fonctionne pas y revient. La détermination vous appartient et doit être consignée. Voici le texte qui la décide.

Quand un logiciel est-il « mis sur le marché » au sens du CRA, et lequel de vos builds est un produit ? La règle des orientations pour les logiciels autonomes

Tout, dans le CRA, tient à une date et à un nom : la date à laquelle un produit est mis sur le marché, et la question de savoir si ce que vous livrez est un produit. Pour les logiciels autonomes, les orientations de la Commission du 27 juillet 2026 répondent aux deux aux paragraphes 13 à 21 : une version est mise sur le marché une fois, lors de sa première offre, et chaque téléchargement ultérieur compte à partir de ce jour ; les builds par système d'exploitation et les bundles de fonctionnalités sont des produits distincts ; une application web utilisée dans un navigateur n'est pas un produit, une extension de navigateur ou un client installé l'est. Ce que cela signifie pour le 11 décembre 2027, pour les bêtas et pour les anciennes versions que vous laissez en ligne.

Quelles parties de votre backend sont dans le CRA ? Le traitement de données à distance, d'après les orientations de la Commission

Un produit comportant des éléments numériques inclut ses solutions de traitement de données à distance, et le règlement les définit en une phrase. Les orientations de la Commission du 27 juillet 2026 font de cette phrase deux tests cumulatifs, une règle de délimitation, une liste de ce qui n'est jamais inclus (CI/CD, RH, CRM, télémétrie, sites web), les cas SaaS, PaaS et IaaS, et un exemple de banque mobile traité de bout en bout. Pour un éditeur de logiciels avec une application et un cloud, c'est la ligne.

Qui applique le règlement sur la cyberrésilience dans votre État membre ? 7 sur 27 l'ont dit

Le CRA est appliqué au niveau national, par une autorité de surveillance du marché que chaque État membre désigne et enregistre auprès de la Commission. Le 11 septembre 2026, jour où l'obligation de notification s'est appliquée, sept États en avaient enregistré une. Voici le registre, État par État, y compris les vingt qui ne l'ont pas fait, et ce que cela signifie pour un petit fabricant qui se demande qui viendra frapper à sa porte.

Votre produit est-il important ou critique au sens du règlement sur la cyberrésilience ? Les annexes III et IV en entier

Une fois qu'un produit entre dans le champ du CRA, il est par défaut, important (classe I ou II) ou critique, et le palier décide si vous pouvez vous auto-évaluer ou s'il vous faut un organisme notifié. Voici les 19, 4 et 3 catégories mot pour mot depuis le Journal officiel, ce que chaque palier change au titre de l'article 32, et la seule chose que le palier ne change pas.

Par défaut, important ou critique : les 26 descriptions techniques du règlement d'exécution 2025/2392, et le test de la fonctionnalité de base

Les annexes III et IV du CRA nomment 26 catégories de produits en une ligne chacune. Le règlement d'exécution (UE) 2025/2392 de la Commission, en vigueur depuis le 21 décembre 2025, décrit chacune techniquement, et les orientations de la Commission du 27 juillet 2026 disent comment classer par rapport à elles : selon la fonctionnalité de base du produit, pas selon ce qu'il fait aussi ni ce qu'il intègre. Les 26 descriptions textuellement, les six règles des orientations avec leurs exemples (un SOAR n'est pas un SIEM, un visualiseur de journaux n'est pas un SIEM, un routeur avec pare-feu est un routeur), et ce que la classification change.

CRA annexe I : les 22 exigences essentielles, en liste de contrôle

L'annexe I du règlement sur la cyberrésilience est ce que votre produit doit respecter à partir du 11 décembre 2027 et ce que le dossier technique doit démontrer. La partie I compte 14 exigences sur le produit, dont 13 « le cas échéant » sur la base de votre évaluation des risques ; la partie II compte 8 exigences de gestion des vulnérabilités qui s'appliquent toujours. Les voici en un seul tableau, avec ce que chacune demande et si vous pouvez l'exclure.

Ce que contient le dossier technique du CRA : l'annexe VII, point par point

À partir du 11 décembre 2027, tout produit comportant des éléments numériques mis sur le marché de l'UE a besoin d'une documentation technique avant sa mise sur le marché, conservée dix ans ou pendant la période d'assistance, la plus longue des deux. L'annexe VII dit ce qu'elle contient en huit points. Les voici, ce que chacun demande réellement, les quatre documents que la partie II de l'annexe I présuppose, et combien de temps vous la gardez.

Le CRA exige-t-il une SBOM ? Oui, et voici exactement ce qu'il dit

L'annexe I, partie II, point 1 du règlement sur la cyberrésilience exige une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau. Elle va dans le dossier technique, n'est pas publiée, et une autorité de surveillance du marché peut la demander sur demande motivée. Les trois phrases qui tranchent, et ce qu'elles laissent ouvert.

Ce que le CRA vous demande pour vos dépendances : diligence raisonnable, signalement en amont et vulnérabilités exploitables connues, d'après les orientations de la Commission

Un produit logiciel est surtout fait du code des autres. Le CRA rend le fabricant responsable du produit dans son ensemble et lui donne trois devoirs envers les composants qu'il contient : la diligence raisonnable de l'article 13(5), le signalement des vulnérabilités en amont et le partage des correctifs de l'article 13(6), et la mise sur le marché sans vulnérabilités exploitables connues. Les orientations de la Commission du 27 juillet 2026, sections 3.4, 7.3 et 9.2, disent ce que chacun exige et ce qu'il n'exige pas : pas de signalements en double, pas d'obligation de faire accepter votre correctif, et une définition de « connue » qui inclut la base CVE et la presse.

CRA ou NIS2 : lequel s'applique à une société de logiciels, et peut-on être sous les deux ?

Le règlement sur la cyberrésilience régit les produits mis sur le marché ; NIS2 régit les entités qui fournissent des services. Une société de logiciels peut relever de l'un, de l'autre, des deux ou d'aucun, et la réponse tient à deux questions : mettez-vous un produit sur le marché, et êtes-vous une entité de taille moyenne ou plus dans un secteur listé. Les dates, les horloges de notification, les amendes et le tableau de décision, tirés des deux textes.

NIS2 ou CRA : quelle horloge d'incident court pour un éditeur de logiciels, et ce qui rend un incident « important »

Les deux textes vous donnent 24 heures, 72 heures et un mois, et les deux font partir l'horloge du moment où vous « avez connaissance ». Presque tout le reste diffère : ce qui la déclenche, qui la reçoit, sur quelle plateforme, et ce qui compte. L'article 23 de NIS2 et le règlement d'exécution 2024/2690 pour l'entreprise qui exploite un service en nuage ; l'article 14 du CRA pour l'entreprise qui livre un produit ; les deux pour l'entreprise qui fait les deux. Les seuils, critère par critère, et une seule procédure qui satisfait aux deux.

Un logiciel doit-il porter le marquage CE au titre du CRA ? Oui, et l'article 30 dit où il va

À partir du 11 décembre 2027, un marquage CE est exigé sur tout produit comportant des éléments numériques mis sur le marché de l'UE, logiciel compris. Pour un logiciel, le marquage va sur la déclaration UE de conformité ou sur le site web accompagnant le produit, avant la mise sur le marché. Ce que le marquage affirme, qui peut l'apposer, quand le numéro d'un organisme notifié s'y ajoute, et ce que doit contenir la déclaration qui le sous-tend.

La déclaration UE de conformité au titre du CRA : l'annexe V point par point, la forme simplifiée et un exemple rempli

L'article 28 impose au fabricant d'établir une déclaration UE de conformité avant la mise sur le marché, selon le modèle de l'annexe V, et l'article 28(4) fait de sa signature l'acte par lequel le fabricant assume la responsabilité du produit. Les huit points de l'annexe V, la forme simplifiée en une phrase de l'annexe VI, les règles qui l'entourent (langues, la déclaration unique, les familles de produits, 10 ans de conservation), un exemple rempli, et ce que coûte une déclaration absente ou incorrecte au titre des articles 58 et 64.

L'auto-évaluation au titre du CRA : ce que le module A exige vraiment, d'après l'annexe VIII et la FAQ de la Commission

La plupart des produits logiciels ne verront jamais un organisme notifié. Ils utilisent le module A, la procédure de contrôle interne de l'annexe VIII, et « auto-évaluation » est le mot que tout le monde emploie sans dire ce qu'il contient. L'annexe VIII, partie I, tient en cinq points ; la FAQ de la Commission ajoute la liste des activités, le fait qu'aucune méthodologie d'essai n'est imposée, l'endroit où un produit logiciel porte son marquage CE, les deux formes de la déclaration de conformité, et le calendrier des normes harmonisées qui décide quand l'auto-évaluation cesse de vouloir dire « directement contre l'annexe I ».

Normes harmonisées pour le CRA : ce que demande la demande de normalisation M/606, pour quand, et ce dont un fabricant dispose aujourd'hui

L'article 27 donne une présomption de conformité aux produits qui suivent des normes harmonisées citées au Journal officiel. Le 3 février 2025, la Commission en a demandé 41 au CEN, au CENELEC et à l'ETSI, avec des délais du 30 août 2026 au 30 octobre 2027 ; les trois ont accepté le 3 avril 2025. Le 12 septembre 2026, l'index des normes harmonisées de la Commission n'a toujours aucune entrée pour le règlement, ce qui, pour un produit de classe I, signifie aucune voie d'auto-évaluation au titre de l'article 32(2). Ce qui a été demandé, les dates, et contre quoi construire d'ici là.

Quelle est la durée de la période d'assistance du CRA ? Au moins cinq ans, et trois autres horloges qui en dépendent

L'article 13, paragraphe 8, du règlement sur la cyberrésilience exige une période d'assistance d'au moins cinq ans, ou la durée d'utilisation attendue si elle est plus courte, pendant laquelle les vulnérabilités sont traitées. Sa date de fin doit être affichée à l'achat, au moins le mois et l'année. Les mises à jour de sécurité doivent rester disponibles dix ans ou la période d'assistance. Et le dossier technique, la déclaration et les informations utilisateur sont conservés aussi longtemps. Les quatre horloges, d'après le texte.

Quelle mise à jour fait entrer votre logiciel existant dans le CRA ? Les modifications substantielles, d'après les orientations de la Commission

Un logiciel mis sur le marché avant le 11 décembre 2027 reste hors des obligations de conception et de conformité du CRA tant qu'il n'est pas substantiellement modifié. Les orientations de la Commission du 27 juillet 2026 disent ce que cela signifie pour une mise à jour logicielle aux paragraphes 103 à 113 et 122 à 124, avec onze exemples traités : un risque absent de votre évaluation des risques, pas la taille du diff. Les mises à jour de sécurité sont en général hors champ ; une case « se souvenir de moi » peut être dedans. Ce qu'il faut écrire dans chaque version, et ce que la première modification substantielle déclenche ou non.

Ce que vous devez notifier au titre du CRA : les deux déclencheurs, tels que le règlement les définit

L'article 14 a deux déclencheurs et les deux sont définis dans le texte. Une vulnérabilité activement exploitée est une vulnérabilité pour laquelle il existe des preuves fiables qu'un acteur malveillant l'a exploitée dans un système sans l'autorisation du propriétaire (article 3, point 42). Un incident grave est un incident qui affecte, ou peut affecter, la capacité du produit à protéger des données ou fonctions sensibles, ou qui conduit, ou peut conduire, à du code malveillant dans le produit ou les systèmes d'un utilisateur (article 14, paragraphe 5). Ce qui est dedans, ce qui est dehors, et l'obligation d'informer les utilisateurs qui accompagne les deux.

Le CRA s'applique-t-il aux logiciels libres ? Trois cas, et le régime allégé des gestionnaires

Le règlement sur la cyberrésilience n'atteint les logiciels libres et ouverts que lorsqu'ils sont fournis dans le cadre d'une activité commerciale. Un projet non monétisé est dehors. Une entreprise qui livre un produit construit sur des composants libres est fabricant de ce produit. Et les fondations et entreprises qui soutiennent des produits libres destinés à un usage commercial sont des « gestionnaires de logiciels libres » au titre de l'article 24 : une politique de cybersécurité, la coopération avec les autorités et une obligation de notification restreinte, sans marquage CE ni dossier technique. Les considérants et l'article, cités.

Votre projet open source est-il « commercial » au sens du CRA ? Les sept tests de la Commission, avec ses exemples

Le CRA n'atteint les logiciels libres et open source que lorsqu'ils sont fournis dans le cadre d'une activité commerciale, et le règlement laisse « commercial » à deux considérants. Les orientations de la Commission du 27 juillet 2026, section 3, en font sept tests : un prix, une édition payante ou de l'open core, la monétisation d'autres services ou de données personnelles, les services de support, les dons, le sponsoring et le statut à but non lucratif, avec 22 exemples. Où atterrissent un mainteneur, une entreprise open core et une fondation, et ce qu'une pull request fait de vous.

Ce que le CRA demande aux importateurs et distributeurs, et quand il fait d'eux le fabricant

Si vous revendez des logiciels ou des appareils dans l'UE plutôt que de les construire, les articles 19 et 20 du règlement sur la cyberrésilience vous donnent une liste de vérification à dérouler avant la mise en vente, l'obligation de transmettre les vulnérabilités au fabricant, l'obligation d'informer les autorités des risques importants, et dix ans de conservation. L'article 21 fait de vous le fabricant dès que vous vendez sous votre propre marque ou modifiez substantiellement le produit. Les obligations, d'après le texte.

La machinerie CRA de l'UE elle-même, le jour où l'obligation a commencé : 0 organisme notifié, 0 norme harmonisée, 7 autorités d'application sur 27

Le règlement sur la cyberrésilience demande aux fabricants d'être prêts. Voici l'état de préparation des institutions dont il dépend les 11 et 12 septembre 2026, lu dans les registres de la Commission elle-même : aucun organisme d'évaluation de la conformité notifié au titre du CRA, aucune norme harmonisée publiée au Journal officiel, sept États membres avec une autorité de surveillance du marché enregistrée, treize avec une autorité notifiante, et la liste des CSIRT coordinateurs publiée la veille, deux États nommant un organisme autre que leur CSIRT national. Ce que cela signifie pour un fabricant ayant un produit de classe I, et ce qu'il faut consigner.

L'évaluation des risques de cybersécurité du CRA : ce que l'article 13 exige vraiment, et le seul résultat qu'elle doit produire

L'article 13, paragraphes 2 à 4, du règlement sur la cyberrésilience fait de l'évaluation des risques le document dont dépend toute autre obligation du CRA. Elle doit analyser les risques d'après la finalité, l'utilisation prévisible et les conditions d'utilisation sur la durée d'utilisation attendue ; dire si et comment chaque exigence du point 2 de la partie I s'applique ; dire comment le point 1 de la partie I et la partie II sont appliqués ; être documentée, tenue à jour sur la période d'assistance et incluse dans le dossier technique, avec une justification claire pour chaque exigence écartée. Les quatre paragraphes, et une structure d'une page qui y satisfait.

La politique de divulgation coordonnée des vulnérabilités exigée par le CRA : trois dispositions, et une politique d'une page qui y répond

L'annexe I, partie II, point 5 du règlement sur la cyberrésilience exige de tout fabricant dans le champ qu'il mette en place et applique une politique de divulgation coordonnée des vulnérabilités. L'article 13, paragraphe 17, exige un point de contact unique pour les signalements, facile à trouver et non limité à des outils automatisés ; l'annexe II, point 2, exige le contact et l'emplacement de la politique dans les informations utilisateur ; l'annexe VII, point 2 b), met les deux dans le dossier technique. Ce que chaque disposition demande, ce qu'une politique doit dire, et ce qu'elle ne doit pas promettre.