Obligations de l'article 14 du règlement (UE) 2024/2847

1. Suis-je fabricant, et de quoi ? Périmètre, vocabulaire, dates

1.0 Note de vocabulaire

L'intitulé imprimé de l'article 14 du règlement (UE) 2024/2847, tel qu'il figure au Journal officiel, est « Obligations en matière de communication d'informations incombant aux fabricants » (:3012). Le corps de l'article n'emploie jamais cette expression. Le paragraphe 1 s'ouvre par « Un fabricant notifie » (:3015), le paragraphe 3 reprend la même tournure (:3056), le paragraphe 2 parle de « la notification visée au paragraphe 1 » (:3021), et le canal désigné est « la plateforme unique de signalement » (:3017-3018). Deux articles voisins ajoutent un troisième mot : l'article 15 s'intitule « Signalement volontaire » (:3181) et l'article 16 « Mise en place d'une plateforme unique de signalement » (:3223).

Trois mots désignent donc un même dispositif. « Communication d'informations » est le mot de l'intitulé. « Notification » est le terme dominant du dispositif, celui qui décrit l'acte que le fabricant accomplit. « Signalement » nomme le canal (la plateforme) et le régime volontaire de l'article 15. Le présent dossier cite l'intitulé tel qu'imprimé et n'en déduit pas que les autres mots seraient fautifs : ils coexistent dans le texte officiel, et le texte officiel fait foi dans ses propres mots. La distinction s'écrit, elle ne se résout pas.

Cette note compte pour une raison pratique. Le mot que vous chercherez spontanément dans le règlement, « signalement », vous conduira à la plateforme et au régime volontaire. Le mot qui vous lie, dans l'intitulé de l'article qui crée l'obligation, est « communication d'informations », et l'acte lui-même se nomme « notification ». Une recherche textuelle sur un seul de ces trois mots manque les deux autres.

1.1 Cadrage des dates

L'article 71 fixe l'entrée en vigueur et l'application. Son paragraphe 1 dispose : « Le présent règlement entre en vigueur le vingtième jour suivant celui de sa publication au Journal officiel de l'Union européenne. » (:5444-5445). Le fichier officiel n'imprime nulle part la date d'entrée en vigueur en clair : elle se dérive de la date de publication, le 20 novembre 2024, qui figure dans le mobilier de page du Journal officiel (par exemple :5455), à laquelle s'ajoute le délai de vingt jours. Cette date dérivée n'emporte aucune obligation opérationnelle par elle-même ; ce sont les dates d'application qui comptent.

Le paragraphe 2 de l'article 71 comporte deux alinéas, qui ne sont pas contigus dans le fichier (une note de bas de page et le mobilier de page s'intercalent). Le premier pose la règle générale : « 2. Le présent règlement est applicable à partir du 11 décembre 2027. » (:5457). Le second pose la dérogation : « Toutefois, l'article 14 est applicable à partir du 11 septembre 2026 et le chapitre IV (articles 35 à 51) à partir du 11 juin 2026. » (:5460-5461).

Le 11 septembre 2026 marque l'entrée en application de l'article 14 seul. Aucune échéance ne tombe ce jour-là : aucun dossier à déposer, aucune déclaration à produire. À partir de cette date, un fabricant qui prend connaissance d'une vulnérabilité activement exploitée ou d'un incident grave entre dans le dispositif de notification. Tout le reste du règlement, marquage CE, exigences de cybersécurité de l'annexe I, documentation technique, évaluation de conformité, relève de la règle générale et s'applique à partir du 11 décembre 2027 (:5457).

Reste la question du parc existant. L'article 69 §2 dispose : « Les produits comportant des éléments numériques qui ont été mis sur le marché avant le 11 décembre 2027 ne sont soumis aux exigences énoncées dans le présent règlement que si, à compter de cette date, ces produits font l'objet d'une modification substantielle. » (:5411-5413). L'article 69 §3, dans sa version rectifiée par le rectificatif publié au JO L 2025/90555 du 2 juillet 2025 [1], et cité ici uniquement depuis ce rectificatif, prévoit que, par dérogation au paragraphe 2, les obligations de l'article 14 s'appliquent à tous les produits comportant des éléments numériques relevant du règlement « mis sur le marché avant le 11 décembre 2027 ».

La conséquence se lit sans interprétation. Un produit mis sur le marché avant le 11 décembre 2027 est couvert par l'article 14 dès le 11 septembre 2026, et par rien d'autre tant qu'il ne fait pas l'objet d'une « modification substantielle » au sens du point 30 de l'article 3 (:2357-2360), soit, en paraphrase de ce point, une modification postérieure à la mise sur le marché qui a une incidence sur la conformité du produit aux exigences de cybersécurité de l'annexe I, partie I, ou qui modifie l'utilisation prévue pour laquelle le produit a été évalué. Un logiciel vendu depuis dix ans et toujours maintenu entre dans le dispositif de notification le 11 septembre 2026.

La FAQ des services de la Commission, dans sa version 1.4 du 4 septembre 2026 [2], corrobore cette lecture à l'entrée 5.3 : « Reporting obligations start applying as of 11 September 2026. Manufacturers are required to comply with Article 14 … for all products with digital elements falling within the scope of the CRA, including products that have been placed on the market before 11 December 2027. » Ce document porte son propre avertissement, reproduit ici tel quel : « This document is prepared by the Commission services and should not be considered as representative of the European Commission's official position. […] The expressed views are not authoritative and cannot prejudge any future actions the European Commission may take. » La FAQ vient donc en corroboration ; le fondement reste l'article 69 §3 rectifié et l'article 71 §2.

1.2 Les dix définitions

L'article 3 (:2217) ouvre par le chapeau « Aux fins du présent règlement, on entend par: » (:2223). Dix points suffisent à décider du périmètre pour un éditeur de logiciels ou un fabricant de produits connectés. Ils sont reproduits verbatim, avec leur numéro de point et leur ligne.

Point 1 (:2226-2227). « «produit comportant des éléments numériques»: un produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels mis sur le marché séparément; »

Point 2 (:2230-2232). « «traitement de données à distance»: tout traitement de données à distance pour lequel le logiciel est conçu et développé par le fabricant ou sous la responsabilité de ce dernier, et dont l'absence empêcherait le produit comportant des éléments numériques d'exécuter une de ses fonctions; »

Point 4 (:2238). « «logiciel»: la partie d'un système d'information électronique qui consiste en un code informatique; »

Point 6 (:2245). « «composant»: un logiciel ou du matériel destiné à être intégré dans un système d'information électronique; »

Point 13 (:2273-2275). « «fabricant»: une personne physique ou morale qui développe ou fabrique des produits comportant des éléments numériques ou fait concevoir, développer ou fabriquer des produits comportant des éléments numériques, et les commercialise sous son propre nom ou sa propre marque, à titre onéreux, monétisé ou gratuit; »

Point 14 (:2278-2281). « «intendant de logiciels ouverts»: une personne morale, autre que le fabricant, qui a pour objectif ou finalité de fournir un soutien systématique et continu au développement de produits spécifiques comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts et sont destinés à des activités commerciales, et qui assure la viabilité de ces produits; »

Point 15 (:2284-2285). « «mandataire»: une personne physique ou morale établie dans l'Union ayant reçu mandat écrit du fabricant pour agir en son nom aux fins de l'accomplissement de tâches déterminées; »

Point 16 (:2293-2295). « «importateur»: une personne physique ou morale établie dans l'Union qui met sur le marché un produit comportant des éléments numériques, lequel porte le nom ou la marque d'une personne physique ou morale établie en dehors de l'Union; »

Point 17 (:2298-2300). « «distributeur»: une personne physique ou morale faisant partie de la chaîne d'approvisionnement, autre que le fabricant ou l'importateur, qui met un produit comportant des éléments numériques à disposition sur le marché de l'Union sans altérer ses propriétés; »

Point 48 (:2435-2437). « «logiciel libre et ouvert»: un logiciel dont le code source est partagé de manière ouverte et qui est mis à disposition sous licence libre et ouverte prévoyant tous les droits pour qu'il soit librement accessible, utilisable, modifiable et redistribuable; »

Deux définitions d'appoint servent aux raisonnements qui suivent. Le point 21 (:2316-2317) définit la « mise sur le marché » comme « la première mise à disposition d'un produit comportant des éléments numériques sur le marché de l'Union ». Le point 22 (:2320-2321) définit la « mise à disposition sur le marché » comme la fourniture d'un produit destiné à être distribué ou utilisé sur le marché de l'Union « dans le cadre d'une activité commerciale, à titre onéreux ou gratuit ».

Trois remarques sur le point 13. Le mot « fabricant » est celui du règlement et il vaut pour un éditeur de logiciels : le texte pose « développe ou fabrique » en alternative, de sorte qu'une entreprise qui écrit du code sans jamais assembler un objet physique est un fabricant au sens du règlement. Le point 13 ajoute une seconde voie, « fait concevoir, développer ou fabriquer », qui couvre l'entreprise qui sous-traite le développement et vend sous son nom. La fin de la définition, « à titre onéreux, monétisé ou gratuit », écarte l'argument de la gratuité : un logiciel distribué sans contrepartie, sous le nom d'une entreprise, dans le cadre d'une activité commerciale au sens du point 22, fait de cette entreprise un fabricant.

1.3 Le logiciel seul

Le point 1 et le point 4 se lisent ensemble. Le point 1 vise « un produit logiciel ou matériel » : le produit purement logiciel est nommé en premier, sans condition de support matériel. Le point 4 définit le logiciel comme « la partie d'un système d'information électronique qui consiste en un code informatique ». Un exécutable, un paquet, une image de conteneur, un script distribué à des clients, tout cela est du code informatique et constitue un produit logiciel au sens du point 1.

Le point 1 se termine par « y compris les composants logiciels ou matériels mis sur le marché séparément », et le point 6 définit le composant comme « un logiciel ou du matériel destiné à être intégré dans un système d'information électronique ». La combinaison des deux couvre le cas de l'éditeur qui ne vend pas d'application finale : une bibliothèque, un kit de développement logiciel (software development kit, SDK), un module, un pilote, un connecteur, dès lors qu'il est vendu ou distribué séparément, est un produit comportant des éléments numériques à part entière, et l'éditeur de ce composant en est le fabricant au sens du point 13 s'il le commercialise sous son nom.

1.4 Composants open source et leurs mainteneurs

Le point 48 définit le logiciel libre et ouvert par deux critères cumulés : un code source « partagé de manière ouverte » et une licence « prévoyant tous les droits pour qu'il soit librement accessible, utilisable, modifiable et redistribuable ». Le point 14 crée une qualité distincte, l'intendant de logiciels ouverts, défini comme « une personne morale, autre que le fabricant », qui apporte un « soutien systématique et continu » à des produits libres et ouverts « destinés à des activités commerciales ». Une fondation, une association, une structure d'hébergement de projets peut être intendant ; un fabricant, par construction, ne l'est pas pour ses propres produits.

L'article 24, intitulé « Obligations des intendants de logiciels ouverts » (:3603), fixe en son paragraphe 3 ce que l'intendant doit au titre de l'article 14 (:3625-3629) : « 3. Les obligations prévues à l'article 14, paragraphe 1, s'appliquent aux intendants de logiciels ouverts dès lors qu'ils participent au développement des produits comportant des éléments numériques. Les obligations prévues à l'article 14, paragraphes 3 et 8, s'appliquent aux intendants de logiciels ouverts dès lors que des incidents graves ayant des répercussions sur la sécurité des produits comportant des éléments numériques touchent les réseaux et les systèmes d'information fournis par les intendants de logiciels ouverts pour le développement de ces produits. » L'intendant est donc tenu à une partie de l'article 14 seulement, et sous conditions : participation au développement pour le paragraphe 1, atteinte à ses propres réseaux et systèmes pour les paragraphes 3 et 8.

Une asymétrie de calendrier se déduit de l'article 71 §2. Le second alinéa (:5460-5461) est énumératif : il nomme « l'article 14 » et « le chapitre IV (articles 35 à 51) », et rien d'autre. L'article 24 n'y figure pas. L'article 24 §3 relève donc de la règle générale du premier alinéa (:5457) et s'applique à partir du 11 décembre 2027. Un fabricant notifie dès le 11 septembre 2026, y compris pour son parc antérieur ; un intendant de logiciels ouverts n'y est tenu qu'au 11 décembre 2027. La FAQ des services de la Commission [2], dans son entrée 5.5 ajoutée avec la version 1.4 du 4 septembre 2026, dit la même chose : « In accordance with Article 71(2) of the CRA, Article 24(3) shall apply from 11 December 2027. » Cette entrée vient en corroboration, sous l'avertissement de non-opposabilité reproduit en 1.1 ; le fondement est le texte de l'article 71 §2 lui-même.

Deux précisions ferment ce point. Le fabricant qui intègre un composant libre et ouvert dans son produit reste fabricant de ce produit, avec l'ensemble des obligations attachées à cette qualité ; l'origine libre du composant ne déplace rien. À l'inverse, le développeur individuel ou la communauté sans personne morale n'est ni fabricant, faute de commercialisation sous son nom au sens du point 13, ni intendant, faute de personne morale au sens du point 14 ; il échappe aux deux qualités. Le régime détaillé des composants tiers, libres ou propriétaires, et ce que le fabricant intégrateur doit en faire au titre de l'article 14, relève de la section 2.

1.5 Question de champ n° 1 : le logiciel fourni exclusivement en service hébergé

La question se pose à tout éditeur qui exploite son logiciel pour le compte de ses clients au lieu de le leur livrer. Le texte se lit en trois temps.

Le point 1 vise « un produit logiciel ou matériel et ses solutions de traitement de données à distance » (:2226-2227). Le possessif « ses » rattache la solution à distance à un produit. La solution de traitement à distance entre dans le champ comme accessoire d'un produit ; elle n'est pas posée comme une catégorie autonome de produit.

Le point 2 (:2230-2232) est cumulatif. Le premier membre porte sur la paternité : le logiciel de traitement à distance est « conçu et développé par le fabricant ou sous la responsabilité de ce dernier », et le « ou » est interne à ce membre, il ne fait qu'admettre la sous-traitance. Le second membre porte sur la nécessité fonctionnelle : « et dont l'absence empêcherait le produit comportant des éléments numériques d'exécuter une de ses fonctions ». Ce second membre suppose un produit distinct du service, dont une fonction dépend du service. Le seuil est bas : « une » de ses fonctions (:2232), et non la fonction principale.

Les considérants 11 et 12 précisent l'intention. Le considérant 11 (:194-209) dispose que « le traitement ou le stockage des données à distance ne relèvent du champ d'application du présent règlement que s'ils sont nécessaires à l'exécution des fonctions d'un produit comportant des éléments numériques ». Il donne un exemple : « Le traitement ou le stockage à distance comprend les cas où une application mobile a besoin d'accéder à une interface de programmation d'application ou à une base de données fournie par l'intermédiaire d'un service développé par le fabricant. Dans cette situation, le service constitue une solution de traitement de données à distance et relève donc du champ d'application du présent règlement. » Il précise in fine que les exigences applicables « ne comportent pas de mesures techniques, opérationnelles ou organisationnelles visant à gérer les risques qui pèsent sur la sécurité des réseaux et systèmes d'information d'un fabricant dans leur ensemble » (:206-209). Le considérant 12 (:212-223) ajoute : « Les solutions en nuage ne constituent des solutions de traitement de données à distance au sens du présent règlement que si elles répondent à la définition énoncée dans ce dernier. » Il cite les fonctionnalités en nuage d'un fabricant d'appareils domestiques intelligents comme relevant du règlement, puis pose la limite : « À l'inverse, les sites internet qui ne supportent pas la fonctionnalité d'un produit comportant des éléments numériques ou les services en nuage qui ne sont pas conçus et développés sous la responsabilité du fabricant d'un produit comportant des éléments numériques ne relèvent pas du champ d'application du présent règlement. La directive (UE) 2022/2555 s'applique aux services d'informatique en nuage et aux modèles de services en nuage, tels que les logiciels service (SaaS), les plates-formes services (PaaS) et les infrastructures services (IaaS). »

Sur ce texte, deux cas se tranchent et un troisième reste ouvert.

Se tranche, en premier lieu, le cas de l'éditeur qui livre un artefact au client : client lourd, agent installé sur les postes ou les serveurs, connecteur, extension de navigateur, application mobile, collecteur sur site. Cet artefact est un produit logiciel au sens des points 1 et 4. Son service hébergé est entraîné avec lui dès que le produit s'appuie sur ce traitement distant pour une de ses fonctions, ce qui est le cas ordinaire d'un agent qui remonte des données ou d'une application mobile qui interroge une interface de programmation (:2226-2232, :194-209). La position que je défends est que l'artefact commande la qualification de l'ensemble.

Se tranche, en second lieu, le cas du service hébergé conçu et développé pour le produit d'un autre fabricant, sous la responsabilité de ce dernier : il est la solution de traitement à distance de ce fabricant, et entre dans le champ à ce titre, rattaché à ce produit (:2230-2232, :203-206).

Reste ouvert le cas du pur service hébergé, sans aucun artefact livré, accessible par navigateur seulement. Le fichier officiel ne contient aucune disposition qui qualifie expressément cette configuration, ni pour l'inclure ni pour l'exclure. Le considérant 12 s'en approche par la négative, en mentionnant les sites internet et les services en nuage qui ne supportent pas la fonctionnalité d'un produit, et en renvoyant les modèles de services en nuage à la directive (UE) 2022/2555. Un considérant n'a cependant pas la portée normative d'un article, et la première phrase du considérant 12 renvoie elle-même au test de la définition. Je lis ce silence comme un trou, et je le nomme comme tel : ce cas est renvoyé à la section 7, consacrée aux zones d'incertitude.

Une position existe, qui est rapportée ici sans valeur d'autorité. Les orientations de la Commission européenne du 27 juillet 2026 sur le champ d'application [10], que je n'ai pas lues à la source et qui sont connues par les commentaires de trois cabinets (Hogan Lovells, Lewis Silkin, DLA Piper), retiendraient qu'une application web accédée exclusivement par navigateur n'est pas, de ce seul fait, un produit comportant des éléments numériques. La Commission indique elle-même que ces orientations sont non contraignantes. DIGITALEUROPE [11] tient une position de même sens, antérieure aux orientations et de nature différente, puisqu'il s'agit d'un plaidoyer sectoriel. Il s'agit de deux voix indépendantes, et non de six, les trois cabinets relayant une même source ; aucune n'a été relue à la source, aucune ne lie, et tout lien vers ces documents demande un contrôle humain avant reprise.

Ce que l'éditeur en service hébergé retient malgré le trou tient en une phrase : un seul artefact livré, agent, connecteur, application mobile ou extension, fait basculer l'ensemble dans le champ, service compris. Hypothèse de travail : la plupart des éditeurs dits SaaS livrent en pratique au moins un artefact de ce type (une application mobile, une extension, un agent de synchronisation, un connecteur d'authentification), ce qui réduit le trou du pur service hébergé à un cas plus étroit qu'il n'y paraît. Cette hypothèse est formulée comme telle ; elle ne repose sur aucun décompte et ne préjuge pas de la réponse que la section 7 laissera ouverte. Le trou existe, il est étroit.

1.6 Question de champ n° 2 : fabricant contre entité de vente

L'article 14 désigne un seul obligé. « Un fabricant notifie » (:3015, :3056). Aucun paragraphe de l'article 14 ne transfère l'obligation à un importateur, un distributeur ou un mandataire. La question qui se pose alors aux groupes est celle de l'entité qui porte l'obligation lorsque la fabrication et la vente sont séparées.

Le cas concret est celui d'un groupe qui fabrique dans un pays et vend en Belgique par une filiale commerciale distincte. Le critère décisif se trouve au point 13 : le fabricant est celui qui « les commercialise sous son propre nom ou sa propre marque ». Le tableau qui suit décrit les deux configurations.

Le piège tient dans la seconde ligne. La marque propre, y compris en marque blanche, fait basculer l'entité de vente dans la qualité de fabricant. Une filiale qui appose son nom sur un produit développé ailleurs dans le groupe « fait concevoir, développer ou fabriquer » ce produit et le « commercialise sous son propre nom » ; les deux branches du point 13 sont réunies, et l'obligation de notifier lui incombe, sans qu'elle ait écrit une ligne de code. Le même mécanisme joue pour le revendeur qui rebaptise un logiciel tiers. Le mandataire du point 15, lui, agit « en son nom » pour « des tâches déterminées » : il exécute pour le compte du fabricant, il ne devient pas l'obligé. Je tiens que la marque décide, et non l'organigramme.

Le paragraphe 7 de l'article 14 ne modifie pas cette attribution : il route la notification, il ne la transfère pas. Son deuxième alinéa dispose (:3117-3120) : « Aux fins du présent règlement, un fabricant est réputé avoir son établissement principal dans l'Union dans l'État membre où sont principalement prises les décisions relatives à la cybersécurité des produits comportant des éléments numériques. Si un tel État membre ne peut être déterminé, l'établissement principal est considéré comme se trouvant dans l'État membre où le fabricant concerné possède l'établissement comptant le plus grand nombre de salariés dans l'Union. » Le troisième alinéa (:3123-3125) ouvre une cascade « lorsqu'un fabricant n'a pas d'établissement principal dans l'Union » : a) l'État membre du mandataire agissant pour le plus grand nombre de produits (:3128-3129) ; b) celui de l'importateur qui met sur le marché le plus grand nombre de produits (:3132-3133) ; c) celui du distributeur qui met à disposition le plus grand nombre de produits (:3141-3142) ; d) celui où se trouvent le plus grand nombre d'utilisateurs (:3145-3146). Cette cascade ne sert qu'à déterminer le CSIRT destinataire, autrement dit le point final de notification électronique ; elle ne fait d'aucun mandataire, importateur ou distributeur un obligé.

La conséquence pour un groupe se lit directement. Un groupe dont la filiale commerciale est belge mais dont les décisions relatives à la cybersécurité des produits se prennent dans un autre État membre notifie au CSIRT désigné comme coordinateur de cet autre État, et non au CSIRT belge. Ni le siège social ni le marché de vente ne décident du destinataire ; seul le lieu des décisions de cybersécurité produit le fait, puis, à défaut, le lieu de l'effectif le plus nombreux, puis la cascade. Le volet belge, la place du Centre pour la Cybersécurité Belgique et l'articulation avec la transposition de NIS2, est renvoyé à la section 3.

1.7 Ce qui est établi

Le périmètre se décide sur trois questions, chacune adossée à un texte : qui commercialise le produit sous son nom ou sa marque (point 13, :2273-2275), y a-t-il un artefact livré au client (points 1, 2 et 4, :2226-2238), et où se prennent les décisions de cybersécurité produit (article 14 §7, :3117-3120). L'article 14 est la seule obligation du règlement en application le 11 septembre 2026 (:5460-5461), et elle couvre le parc mis sur le marché avant le 11 décembre 2027 (article 69 §3 rectifié [1], confirmé par relecture indépendante du 8-9 septembre 2026 sur la source primaire EUR-Lex). Le pur service hébergé sans artefact reste un cas non qualifié par le texte, renvoyé à la section 7 ; l'intendant de logiciels ouverts n'entre dans le dispositif qu'au 11 décembre 2027 (:5457). Tout le reste attend le 11 décembre 2027.

2. Ce qui doit être communiqué, et ce qui ne relève pas de l'obligation

L'article 14 du règlement (UE) 2024/2847 [3] porte l'intitulé « Obligations en matière de communication d'informations incombant aux fabricants » (art. 14, intitulé, :3012). Son dispositif ne vise que deux objets : la vulnérabilité activement exploitée (§1) et l'incident grave ayant des répercussions sur la sécurité du produit (§3). Tout le reste, dans le texte, relève d'un autre article ou d'aucun. La présente section suit les définitions de l'article 3 jusqu'aux deux déclencheurs de l'article 14, puis délimite ce que le règlement laisse au régime volontaire de l'article 15, avant de traiter le cas des composants tiers et l'information des utilisateurs prévue au §8.

2.1 Vulnérabilité activement exploitée : le test des « preuves fiables »

L'article 3 pose trois définitions en escalier. Le point 40 définit la vulnérabilité comme « une faiblesse, une susceptibilité ou une faille d'un produit comportant des éléments numériques qui peut être exploitée par une cybermenace » (art. 3, point 40, :2405-2406). Le point 41 resserre : la vulnérabilité exploitable est « une vulnérabilité susceptible d'être utilisée efficacement par un adversaire en conditions de fonctionnement effectives » (art. 3, point 41, :2409-2410). Le point 42 resserre encore : la vulnérabilité activement exploitée est « une vulnérabilité pour laquelle il existe des preuves fiables qu'elle a été exploitée par un acteur malveillant dans un système sans l'autorisation du propriétaire du système » (art. 3, point 42, :2413-2414).

L'article 14 §1 ne retient que le troisième degré : « Un fabricant notifie toute vulnérabilité activement exploitée contenue dans le produit comportant des éléments numériques dont il prend connaissance » (art. 14, §1, :3015-3018). Le point 42 est le seul déclencheur de l'article 14 §1. Une vulnérabilité exploitable au sens du point 41, aussi sérieuse soit-elle sur le plan technique, n'entre pas dans le §1 tant qu'il n'existe pas de preuves d'une exploitation effective par un acteur malveillant, dans un système, sans l'autorisation du propriétaire de ce système. Trois éléments cumulatifs composent le point 42 : des preuves qualifiées de fiables, un acteur malveillant, une absence d'autorisation. Un correctif publié pour une faille démontrée en laboratoire ne remplit aucun des trois.

Le texte ne définit pas « preuves fiables ». On constate l'absence de tout critère de fiabilité à l'article 3 comme à l'article 14 : ni source, ni degré de certitude, ni forme. Hypothèse de travail : la qualification des preuves relève de l'appréciation du fabricant au moment où il « prend connaissance », et le texte ne lui fournit aucun étalon. Je m'en tiens à ce constat d'ouverture et je ne le comble pas ; la lecture d'un point que le règlement laisse ouvert appartient aux autorités qui l'appliqueront.

2.2 Incident grave : une notion sans définition à l'article 3

L'article 3 compte cinquante et un points, des lignes :2226 à :2447. Aucun d'eux ne définit « incident grave ». La séquence passe du point 44 au point 45 sans intercaler cette expression, qui figure pourtant dans le corps de l'article 14. Toute citation d'un point de l'article 3 comme définition de l'incident grave serait inexacte.

La chaîne de définitions disponible est la suivante. Le point 43 renvoie à la directive NIS2 : « «incident»: un incident au sens de l'article 6, point 6), de la directive (UE) 2022/2555 » (art. 3, point 43, :2417). Le contenu de cette disposition de la directive n'est pas reproduit dans le règlement, et il n'est pas reproduit ici. Le point 44 définit ensuite l'incident ayant des répercussions sur la sécurité du produit comportant des éléments numériques : « un incident qui entache ou est susceptible d'entacher la capacité d'un produit comportant des éléments numériques à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou fonctions » (art. 3, point 44, :2420-2422).

Le test de gravité se trouve à l'article 14 §5, et il est posé « Aux fins du paragraphe 3 » (art. 14, §5, :3092-3102), ce qui en borne la portée à l'obligation de notification. Un incident ayant des répercussions sur la sécurité du produit est considéré comme grave lorsque : « a) il entache ou est susceptible d'entacher la capacité d'un produit comportant des éléments numériques à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou fonctions sensibles ou importantes; ou b) il a conduit ou est susceptible de conduire à l'introduction ou à l'exécution d'un code malveillant dans un produit comportant des éléments numériques ou dans le réseau et les systèmes d'information d'un utilisateur du produit comportant des éléments numériques » (art. 14, §5, :3092-3102).

La comparaison des mots entre le point 44 et le §5 a) fait apparaître un écart. Le point 44 parle de « données ou fonctions » ; le §5 a) parle de « données ou fonctions sensibles ou importantes ». Le §5 ajoute donc un qualificatif, « sensibles ou importantes », que ni l'article 3 ni l'article 14 ne définissent. C'est ce qualificatif qui sépare l'incident au sens du point 44, notifiable à titre volontaire, de l'incident grave, notifiable à titre obligatoire. Le §5 b) porte sur un autre critère : le code malveillant, introduit ou exécuté, dans le produit lui-même ou dans le réseau et les systèmes d'information d'un utilisateur. Les deux branches sont reliées par « ou » ; l'une suffit.

2.3 Ce qui ne relève pas de l'obligation : le signalement volontaire de l'article 15

L'article 15, intitulé « Signalement volontaire » (art. 15, intitulé, :3181), recueille ce que l'article 14 ne couvre pas. Son §1 dispose que « Les fabricants mais aussi d'autres personnes physiques ou morales peuvent notifier toute vulnérabilité contenue dans un produit comportant des éléments numériques ainsi que les cybermenaces susceptibles d'affecter le profil de risque d'un produit comportant des éléments numériques, de manière volontaire, à un CSIRT désigné comme coordinateur ou à l'ENISA » (art. 15, §1, :3184-3187). Son §2 étend la faculté à « tout incident ayant des répercussions sur la sécurité du produit comportant des éléments numériques ainsi que des incidents évités qui auraient pu entraîner un tel incident » (art. 15, §2, :3190-3192), l'incident évité étant défini au point 45 par renvoi à l'article 6, point 5), de la directive (UE) 2022/2555 (art. 3, point 45, :2425).

Quatre catégories se trouvent ainsi hors de l'article 14 : la vulnérabilité sans preuves d'exploitation, y compris la vulnérabilité exploitable du point 41 ; la cybermenace affectant le profil de risque du produit ; l'incident ayant des répercussions sur la sécurité du produit qui ne remplit pas le test du §5 ; l'incident évité. Pour ces quatre catégories, le verbe est « peuvent notifier ». La faculté est ouverte, l'obligation absente.

L'asymétrie de canal se lit dans le texte. L'article 15 §1 et §2 disent « à un CSIRT désigné comme coordinateur ou à l'ENISA » (:3186-3187) : le « ou » est disjonctif, un seul destinataire suffit. L'article 14 §1 et §3 disent « simultanément au CSIRT désigné comme coordinateur conformément au paragraphe 7 du présent article, et à l'ENISA » (:3016-3017 ; art. 14, §3, :3056-3059) : le « et » est cumulatif, et l'adverbe « simultanément » impose la concomitance. Le régime obligatoire exige deux destinataires en même temps ; le régime volontaire en admet un seul.

L'article 15 §5 fixe l'effet juridique du signalement volontaire : « Sans préjudice de la prévention et de la détection d'infractions pénales et des enquêtes et poursuites en la matière, un signalement volontaire n'a pas pour effet d'imposer à la personne physique ou morale à l'origine de la notification des obligations supplémentaires auxquelles elle n'aurait pas été soumise si elle n'avait pas fait la notification » (art. 15, §5, :3208-3212). Le même paragraphe met à la charge des CSIRT coordinateurs et de l'ENISA la confidentialité et « une protection appropriée des informations fournies ». Signaler volontairement ne crée pas d'obligation nouvelle.

2.4 Composants tiers intégrés : ce que le texte impose, et ce que la FAQ ajoute sans l'imposer

Le règlement ne contient, à l'article 14, aucune règle particulière pour les composants tiers intégrés. Le seul test normatif reste celui du point 42, appliqué au produit du fabricant. Le §1 vise « toute vulnérabilité activement exploitée contenue dans le produit comportant des éléments numériques » (:3015-3018) : l'origine de la vulnérabilité, composant maison ou composant intégré, n'apparaît pas dans le texte. Si la vulnérabilité d'un composant intégré est activement exploitée dans le produit, au sens du point 42, l'article 14 §1 s'applique au fabricant du produit. Si les preuves d'exploitation manquent, le point 42 n'est pas rempli, quelle que soit la provenance du code.

La FAQ des services de la Commission, version 1.4 du 4 septembre 2026 [2], consacre sa section 5.4 aux composants tiers en général. On y lit : « Where the product with digital elements contains an actively exploited vulnerability originating from an integrated component, the manufacturer of the product with digital elements is required to notify that vulnerability. The manufacturer of the integrated component is also required to notify it, if that component has been placed on the market. » Et plus loin : « If the manufacturer … is aware that an integrated component contains a vulnerability, but that vulnerability cannot be exploited in its product with digital elements, that vulnerability is not actively exploited, and therefore it is not subject to mandatory reporting. »

Le statut de ce document est fixé par lui-même. Son avertissement dispose : « This document is prepared by the Commission services and should not be considered as representative of the European Commission's official position. […] The expressed views are not authoritative and cannot prejudge any future actions the European Commission may take. » Il s'agit d'un document de services, sans valeur normative, qui ne lie ni la Commission elle-même selon ses propres termes, ni les autorités qui appliqueront le règlement.

La première phrase de la FAQ 5.4 ne fait que redire le point 42 ; elle n'ajoute rien au texte. La seconde phrase, en revanche, formule une conséquence que le règlement n'énonce pas en ces termes : une vulnérabilité de composant non exploitable dans le produit ne serait pas soumise à notification obligatoire. Cette conséquence est cohérente avec le point 42, puisqu'une vulnérabilité non exploitable dans le produit ne peut pas y avoir été exploitée. Mais la cohérence d'un raisonnement n'est pas une norme. Je tranche ici sur le statut, et sur lui seul : la position de la FAQ ne fonde aucune exclusion. Un lecteur ne peut pas s'appuyer sur ce seul document pour écarter une notification. Ce qui tranche, c'est le point 42, appliqué aux preuves d'exploitation dans le produit tel que livré : si ces preuves existent, l'obligation du §1 existe ; si elles n'existent pas, l'obligation n'existe pas. La FAQ décrit, elle ne dispose pas.

2.5 Correction d'attribution : FAQ 5.4 et 4.4.4

Une version antérieure de ce dossier attribuait à la section 5.4 de la FAQ le traitement des composants open source. C'était une erreur d'attribution. La section 5.4 porte sur les composants tiers en général, sans distinction de licence ; les composants libres et ouverts, au sens du point 48 de l'article 3 (:2435-2437), sont traités par la FAQ en section 4.4.4, qui porte sur la diligence raisonnable applicable à ces composants et non sur la notification de l'article 14. Les deux sections répondent à deux questions différentes : la 4.4.4 à celle de l'intégration d'un composant ouvert, la 5.4 à celle de la notification d'une vulnérabilité d'origine tierce. L'analyse de la section 2.4 ci-dessus ne vaut que pour la seconde. Les conséquences de cette correction sur le reste du dossier sont consignées à la section 7, trou (a).

2.6 L'information des utilisateurs : article 14 §8

L'article 14 §8 ajoute une obligation distincte de la notification aux autorités : l'information des utilisateurs. Elle naît « Après avoir pris connaissance d'une vulnérabilité activement exploitée ou d'un incident grave ayant des répercussions sur la sécurité du produit comportant des éléments numériques » (art. 14, §8, :3154-3162) ; son fait générateur est donc le même que celui des §1 et §3.

Le texte précise quatre éléments. Sur l'objet : le fabricant informe « de ladite vulnérabilité ou dudit incident et, si nécessaire, de toute mesure corrective ou d'atténuation des risques que les utilisateurs peuvent mettre en place pour atténuer les répercussions ». Sur les destinataires : « les utilisateurs du produit comportant des éléments numériques touchés et, s'il y a lieu, tous les utilisateurs ». Le cercle des utilisateurs touchés est visé sans condition ; l'extension à tous les utilisateurs est subordonnée à « s'il y a lieu », que le texte n'explicite pas. Sur la forme : « s'il y a lieu dans un format structuré, lisible par machine pouvant être facilement traité automatiquement » ; le format lisible par machine est lui aussi conditionnel. Sur la reprise par l'autorité : « Lorsque le fabricant n'informe pas les utilisateurs du produit comportant des éléments numériques en temps utile, les CSIRT notifiés désignés comme coordinateurs peuvent fournir ces informations aux utilisateurs lorsqu'ils le jugent proportionné et nécessaire ». La reprise est une faculté du CSIRT, soumise à son appréciation de proportionnalité et de nécessité.

Le §8 ne fixe aucun délai chiffré. Là où les §2 et §4 posent des échéances en heures et en jours pour les notifications aux autorités, le §8 se contente de « en temps utile », et le texte ne définit pas ce délai. La seule conséquence textuelle de son dépassement est l'ouverture de la faculté d'information directe par le CSIRT coordinateur. Le délai reste sans mesure.

3. À qui, et par quel canal

3.1 Deux destinataires, simultanément

L'article 14 §1 désigne les destinataires en une phrase. On lit, à JO-FR-L_202402847.md:3015-3018 : « Un fabricant notifie toute vulnérabilité activement exploitée contenue dans le produit comportant des éléments numériques dont il prend connaissance simultanément au CSIRT désigné comme coordinateur conformément au paragraphe 7 du présent article, et à l'ENISA. Le fabricant notifie cette vulnérabilité activement exploitée par l'intermédiaire de la plateforme unique de signalement établie en vertu de l'article 16. » Le §3 reprend la même construction pour l'incident grave, :3056-3059 : « Un fabricant notifie tout incident grave ayant des répercussions sur la sécurité du produit comportant des éléments numériques dont il prend connaissance simultanément au CSIRT désigné comme coordinateur conformément au paragraphe 7 du présent article et à l'ENISA. » Deux destinataires, un adverbe : « simultanément ». Le texte ne prévoit pas de destinataire principal et de destinataire en copie ; il prévoit deux réceptions au même instant.

Le premier destinataire est défini par renvoi. L'article 3, point 51, :2446-2447, dit : « «CSIRT désigné comme coordinateur»: un CSIRT désigné comme coordinateur conformément à l'article 12, paragraphe 1, de la directive (UE) 2022/2555. » Le règlement ne crée donc aucune autorité nouvelle pour recevoir les notifications de l'article 14 ; il emprunte à NIS2 le CSIRT que chaque État membre a désigné pour la divulgation coordonnée des vulnérabilités. Ce chaînage vaut pour la matière comme pour le destinataire : l'« incident » lui-même est défini, au point 43, :2417, comme « un incident au sens de l'article 6, point 6), de la directive (UE) 2022/2555; ». Le CRA ne redéfinit ni l'incident ni le CSIRT.

L'article 15, qui organise le signalement volontaire, s'écarte de cette construction. Son §1, :3184-3187, ouvre la notification « de manière volontaire, à un CSIRT désigné comme coordinateur ou à l'ENISA ». Le « ou » de l'article 15 contre le « simultanément … et » de l'article 14 (:3016-3017) : la même plateforme sert deux régimes dont l'un est cumulatif et l'autre disjonctif. L'asymétrie est dans le texte.

3.2 Un seul canal : la plateforme unique de signalement

Le canal est nommé trois fois et il est unique. L'article 16 §1, :3226-3230, en fixe le maître d'œuvre : « Aux fins des notifications visées à l'article 14, paragraphes 1 et 3, et à l'article 15, paragraphes 1 et 2, et afin de simplifier les obligations de signalement des fabricants, l'ENISA met en place une plateforme unique de signalement. Les opérations quotidiennes de la plateforme unique de signalement sont administrées par l'ENISA, qui en assure le fonctionnement. L'architecture de la plateforme unique de signalement permet aux États membres et à l'ENISA de mettre en place leurs propres points finaux de notification électronique. » La plateforme (single reporting platform) est donc une infrastructure européenne, administrée par l'ENISA, sur laquelle chaque État membre branche son propre point final.

L'article 14 §7, alinéa 1, :3110-3114, lie l'obligation du fabricant à cette architecture : « Les notifications visées aux paragraphes 1 et 3 du présent article sont soumises par l'intermédiaire de la plateforme unique de signalement visée à l'article 16 en utilisant l'un des points finaux de notification électronique visés à l'article 16, paragraphe 1. La notification est soumise au moyen du point final de notification électronique du CSIRT désigné comme coordinateur de l'État membre dans lequel le fabricant a son établissement principal dans l'Union et est simultanément mise à la disposition de l'ENISA. » La simultanéité de l'article 14 §1 trouve ici sa mécanique : le fabricant soumet une fois, au point final national, et la plateforme met la notification à disposition de l'ENISA. Un dépôt, deux réceptions.

Le format et les procédures ne sont pas fixés par le règlement lui-même. L'article 14 §10, :3172-3175, dit : « La Commission peut, par voie d'actes d'exécution, préciser plus en détail le format et les procédures des notifications visées au présent article ainsi qu'aux articles 15 et 16. » Le verbe est « peut ». Il s'agit d'une faculté ouverte à la Commission, non d'une obligation assortie d'un délai, à la différence du §9 voisin (:3165-3169), où la Commission « adopte » des actes délégués avant le 11 décembre 2025. L'obligation de notifier par la plateforme ne dépend donc pas, sur le texte, de l'adoption préalable d'un acte d'exécution.

Le fichier impose la plateforme ; il ne décrit pas son état. Aucune déclaration publique vérifiée sur l'état opérationnel de la plateforme unique de signalement au 8 septembre 2026 ne figure dans ce dossier. Le point reste ouvert.

3.3 Quel point final : le test de l'établissement principal et la cascade

Le point final à utiliser dépend d'un test que l'article 14 §7, alinéa 2, :3117-3120, énonce ainsi : « Aux fins du présent règlement, un fabricant est réputé avoir son établissement principal dans l'Union dans l'État membre où sont principalement prises les décisions relatives à la cybersécurité des produits comportant des éléments numériques. Si un tel État membre ne peut être déterminé, l'établissement principal est considéré comme se trouvant dans l'État membre où le fabricant concerné possède l'établissement comptant le plus grand nombre de salariés dans l'Union. » Le critère premier n'est ni le siège statutaire ni le lieu de vente : c'est le lieu de décision sur la cybersécurité des produits. Le critère subsidiaire, à défaut, est l'effectif.

Cas concret. Un groupe dont la direction produit et l'équipe sécurité arrêtent les décisions de cybersécurité à Paris, et qui vend en Belgique par une filiale de distribution, a son établissement principal en France au sens de l'alinéa 2. Son point final est celui du CSIRT coordinateur français, même si l'incident touche des clients belges ; la filiale belge n'est pas le fabricant. La diffusion vers le CSIRT belge relève de l'article 16 §2, traité en 3.4, et non du choix du point final. Le lieu de décision commande.

Pour le fabricant sans établissement principal dans l'Union, l'alinéa 3, :3123-3125, ouvre une cascade : « Lorsqu'un fabricant n'a pas d'établissement principal dans l'Union, il soumet les notifications visées aux paragraphes 1 et 3 en utilisant le point final de notification électronique du CSIRT désigné comme coordinateur dans l'État membre déterminé conformément à l'ordre suivant, selon les informations dont dispose le fabricant: ». Les quatre échelons se lisent séparément. Le point a), :3128-3129 : « l'État membre dans lequel le mandataire agissant au nom du fabricant pour le plus grand nombre de produits comportant des éléments numériques de ce fabricant est établi; ». Le point b), :3132-3133 : « l'État membre dans lequel l'importateur qui met sur le marché le plus grand nombre de produits comportant des éléments numériques de ce fabricant est établi; ». Le point c), :3141-3142 : « l'État membre dans lequel le distributeur qui met à disposition sur le marché le plus grand nombre de produits comportant des éléments numériques de ce fabricant est établi; ». Le point d), :3145-3146 : « l'État membre dans lequel se trouvent le plus grand nombre d'utilisateurs de produits comportant des éléments numériques de ce fabricant. »¹

Second cas concret. Un éditeur établi hors de l'Union, qui a confié un mandat écrit au sens de l'article 3, point 15 (:2284-2285), à une société bruxelloise pour l'ensemble de ses produits, tombe au point a) : son point final est celui du CSIRT coordinateur belge. Il n'a pas à descendre plus bas dans la cascade, et l'ordre est impératif : « conformément à l'ordre suivant ». Le mandataire fixe le point final.

Le point d) est le seul échelon dont le résultat peut changer d'un cas à l'autre, puisque la répartition des utilisateurs bouge. L'alinéa 4, :3149-3151, y répond : « En ce qui concerne le troisième alinéa, point d), un fabricant peut soumettre des notifications relatives à tout nouveau cas de vulnérabilité activement exploitée ou d'incident grave ayant un impact sur la sécurité du produit comportant des éléments numériques au même CSIRT désigné comme coordinateur que celui avec lequel il a communiqué la première fois. » C'est une faculté, réservée au cas d).

¹ Les lignes 3136 et 3139 du fichier sont du mobilier de page (saut de page entre les points b) et c)) et ne sont pas du texte règlementaire. Une extraction contiguë 3128-3146 y ramasserait deux lignes parasites ; la cascade se cite échelon par échelon.

3.4 Ce que le CSIRT fait de la notification

La notification ne s'arrête pas au point final. L'article 16 §2, alinéa 1, :3233-3235, dit : « Après réception d'une notification, le CSIRT désigné comme coordinateur qui reçoit initialement la notification diffuse, sans retard, la notification via la plateforme unique de signalement aux CSIRT désignés comme coordinateurs sur le territoire desquels le fabricant a indiqué que le produit comportant des éléments numériques a été mis à disposition. » La liste des États membres que le fabricant indique dans l'alerte précoce (§2 a), :3024-3026 ; §4 a), :3065-3069) devient ainsi la liste de diffusion. Dans le premier cas de 3.3, c'est par cette voie que le CSIRT belge apprend l'incident notifié en France.

L'alinéa 2, :3238-3246, autorise un retard de diffusion « dans des circonstances exceptionnelles et, en particulier, à la demande du fabricant et compte tenu du degré de sensibilité des informations notifiées indiqué par celui-ci en vertu de l'article 14, paragraphe 2, point a), du présent règlement », « pour des motifs justifiés ayant trait à la cybersécurité pour une période limitée à ce qui est strictement nécessaire ». Le CSIRT qui retarde « en informe immédiatement l'ENISA » avec justification et date de diffusion prévue. Un constat de renvoi s'impose ici. La ligne 3239 rattache le degré de sensibilité au point a) du §2 ; or le point a) est l'alerte à 24 heures et ne comporte aucun champ de sensibilité, lequel figure au point b), :3034. L'alinéa 3 du même paragraphe, ligne 3250, renvoie correctement au point b). Aucun rectificatif ne corrige ce renvoi en version française. Le dossier l'écrit sans le résoudre ; la section 7 le reprend.

L'alinéa 3, :3249-3262, cité ici en paraphrase, ouvre un second niveau de retard, « dans des circonstances particulièrement exceptionnelles », lorsque le fabricant indique dans sa notification à 72 heures que la vulnérabilité n'a été exploitée dans aucun autre État membre que celui du CSIRT notifié, ou qu'une diffusion immédiate livrerait des informations dont la divulgation nuirait aux intérêts de premier rang de cet État membre, ou que la vulnérabilité présente un risque de cybersécurité imminent élevé en cas de poursuite de la diffusion. Pendant un tel retard, l'ENISA n'est pas laissée sans rien. L'alinéa 4, :3265-3270, dit : « Seules l'information qu'une notification a été effectuée par le fabricant, les informations générales sur le produit, les informations sur la nature générale de l'exploitation et les informations indiquant que des motifs ayant trait à la sécurité ont été soulevés sont mises simultanément à la disposition de l'ENISA jusqu'à ce que la notification complète soit diffusée aux CSIRT concernés et à l'ENISA. » Si, sur cette base, l'ENISA identifie un risque systémique pour le marché intérieur, elle s'adresse au CSIRT destinataire pour que la notification complète soit diffusée aux autres CSIRT coordinateurs et à elle-même (:3268-3270).

Le §3, :3273-3277, ajoute un relais interne à chaque État membre : les CSIRT coordinateurs « fournissent aux autorités de surveillance du marché de leurs États membres respectifs les informations notifiées dont elles ont besoin pour s'acquitter des obligations qui leur incombent en vertu du présent règlement ». Ces autorités relèvent du chapitre V. L'article 71 §2 rend le règlement « applicable à partir du 11 décembre 2027 » (:5457) et précise : « Toutefois, l'article 14 est applicable à partir du 11 septembre 2026 et le chapitre IV (articles 35 à 51) à partir du 11 juin 2026. » (:5460-5461). Le chapitre V n'est pas dans l'exception. Au 11 septembre 2026, il existe donc un destinataire de notification, pas encore de contrepartie belge de surveillance du marché au titre du CRA.

Deux flux complètent le tableau. Le CSIRT récepteur peut demander un rapport intermédiaire, §6, :3105-3107 : « Si nécessaire, le CSIRT désigné comme coordinateur qui reçoit initialement la notification peut demander au fabricant de fournir un rapport intermédiaire de situation ». Et le fabricant a un destinataire second, distinct de la notification : les utilisateurs. Le §8, :3154-3162, dit que le fabricant « informe les utilisateurs du produit comportant des éléments numériques touchés et, s'il y a lieu, tous les utilisateurs », et que si cette information n'arrive pas en temps utile, « les CSIRT notifiés désignés comme coordinateurs peuvent fournir ces informations aux utilisateurs ». Informer n'est pas notifier.

3.5 Le volet belge : ce qui est inféré

Tout ce qui précède est du texte. Ce qui suit est de l'inférence, et le dossier le marque comme telle.

La seule source publique consultée qui nomme un point d'entrée belge est la liste tenue par l'ENISA [4], page datée « Updated: 04/09/2026 », récupérée le 8 septembre 2026. La ligne belge se lit, mot pour mot : Belgium → https://ccb.belgium.be/contacts. Aucun nom d'entité, aucun courriel, aucun numéro ne figure sur la ligne. Les chaînes « CCB », « CERT.be » et « Centre for Cybersecurity Belgium » n'apparaissent nulle part sur la page. Ce que la liste établit, c'est un domaine.

Hypothèse de travail : le CSIRT désigné comme coordinateur pour la Belgique, au sens de l'article 3, point 51, est le Centre pour la Cybersécurité Belgique (CCB). Cette identification est une déduction tirée du domaine ccb.belgium.be de l'URL listée par l'ENISA [4], et du chaînage NIS2 du point 51, :2446-2447. Elle n'est pas lue dans un acte belge.

La page vers laquelle renvoie la liste [5], récupérée le 8 septembre 2026, porte le titre « Centre for Cybersecurity Belgium » et donne une adresse postale, rue de la Loi 18, 1000 Bruxelles, un courriel général, [email protected], et un numéro d'urgence. C'est la page de contact général de l'institution. Le contact général du CCB n'est pas le canal de l'article 14 : le canal est la plateforme unique de signalement, et rien d'autre (:3017-3018, :3058-3059, :3110-3111). Ni le courriel ni le numéro figurant sur cette page ne constituent un point final de notification électronique au sens de l'article 16 §1. Le dossier ne reproduit pas le numéro.

Reste le trou ouvert (b). Au 8 septembre 2026, aucun acte belge désignant une autorité au titre du règlement (UE) 2024/2847 n'a été identifié dans ce dossier. Le rattachement du CCB tient à deux fils : le point 51, qui renvoie à la désignation NIS2, et la liste ENISA [4], qui renvoie à un domaine. Ce trou est repris en section 7.

3.6 NIS2 : faut-il notifier deux fois ?

La question revient chez tout fabricant belge qui est aussi entité NIS2. Elle se traite sur ce que le texte dit et sur ce qu'il ne dit pas.

Ce que le texte dit. L'article 14 impose sa propre notification, au fabricant, sur le produit : « Un fabricant notifie » (:3015, :3056). L'objet est la vulnérabilité activement exploitée « contenue dans le produit » ou l'incident grave « ayant des répercussions sur la sécurité du produit ». L'« incident » est défini par renvoi à NIS2 (point 43, :2417) et le destinataire est le CSIRT de NIS2 (point 51, :2446-2447). Les deux régimes partagent donc un vocabulaire et un guichet.

Ce que le texte ne dit pas. Aucune ligne des articles 14, 15 et 16, de :3009 à :3307, ne contient de clause dispensant un fabricant qui est aussi entité NIS2 de l'une des deux notifications, ni de clause organisant la coordination entre les deux régimes. Le fichier a été relu sur ce point ; la clause n'y est pas. Le partage du CSIRT est un partage de destinataire, pas une fusion des obligations.

La position du CCB [6] (source à contrôle humain), telle que lue le 7 septembre 2026, va dans le même sens sans trancher. Le CCB écrit : « Both NIS2 and the CRA are complementary. NIS2 deals with the cybersecurity of network and information systems, while CRA deals with the cybersecurity of products with digital elements », et : « the CCB will connect to the future single reporting platform to be developed by ENISA ». Le CCB n'y dit pas qu'une notification CRA vaut notification NIS2, ni l'inverse. Sa page consacrée aux notifications NIS2 [7] (source à contrôle humain) décrit un formulaire en ligne distinct, sans renvoi à la plateforme unique de signalement.

Ma lecture est que, sur le texte au 11 septembre 2026, les deux obligations coexistent, portent sur des objets différents, le produit chez le fabricant d'un côté, les réseaux et systèmes d'information de l'entité de l'autre, et n'ont pas de passerelle écrite. Un même événement peut relever des deux. Le dossier ne va pas au-delà de ce constat.

3.7 Tableau : imposé par le texte / inféré

4. Les délais exacts : trois étapes, deux horloges

4.0 Chapeau

L'article 14 organise deux voies parallèles. La première concerne la vulnérabilité activement exploitée (§1 et §2, l. 3015-3048) ; la seconde concerne l'incident grave ayant des répercussions sur la sécurité du produit (§3 et §4, l. 3056-3089). Chaque voie se déroule en trois étapes : une alerte précoce, une notification, un rapport final. Les deux premières étapes portent les mêmes délais dans les deux voies, soit « au plus tard 24 heures » (l. 3025, l. 3066) et « au plus tard 72 heures » (l. 3030, l. 3073). La troisième étape, le rapport final, obéit à une horloge différente selon la voie : « 14 jours après la mise à disposition d'une mesure de correction ou d'atténuation » (l. 3037-3038) d'un côté, « un mois à compter de la présentation de la notification d'incident visée au point b) » (l. 3079-3080) de l'autre. On constate au passage un décalage de vocabulaire : l'intitulé de l'article parle d'« Obligations en matière de communication d'informations incombant aux fabricants » (l. 3012), alors que le corps de l'article dit qu'« un fabricant notifie » (l. 3015) et que « le fabricant soumet » (l. 3021, l. 3062). Le terme opératoire dans les paragraphes est bien « notification », et c'est ce terme que la présente section retient.

4.1 Voie vulnérabilité activement exploitée (art. 14 §1-2)

Le tableau établit que les deux premières étapes de cette voie sont datées à partir d'un même événement, la connaissance par le fabricant, tandis que la troisième est datée à partir d'un événement postérieur et distinct, la mise à disposition d'une mesure. Le contenu exigé s'épaissit d'une étape à l'autre : l'alerte précoce ne demande que l'indication des États membres concernés, « le cas échéant » ; la notification demande des « informations générales » ; le rapport final demande une « description » et des « précisions ». Les destinataires sont fixés par le §1 : « simultanément au CSIRT désigné comme coordinateur conformément au paragraphe 7 du présent article, et à l'ENISA » (l. 3016-3017), par « la plateforme unique de signalement établie en vertu de l'article 16 » (l. 3018).

4.2 Voie incident grave (art. 14 §3-4)

Le tableau établit une structure identique à celle de la voie vulnérabilité pour les étapes a) et b), avec une différence de contenu à l'alerte précoce : dans la voie incident, le fabricant indique « au minimum, si l'incident pourrait avoir été causé par des actes illicites ou malveillants » (l. 3067), exigence qui n'a pas d'équivalent aux l. 3024-3026. La troisième étape se distingue par son point de départ, qui n'est plus la mise à disposition d'une mesure mais la présentation de la notification b). Le §3 fixe les mêmes destinataires et le même canal que le §1 (l. 3056-3059).

4.3 Le point de départ des délais de 24 h et 72 h : la connaissance

Aux quatre endroits où le texte fixe les délais de 24 heures et de 72 heures, le point de départ est le même. Pour la vulnérabilité, l'alerte précoce est due « au plus tard 24 heures après en avoir eu connaissance » (l. 3025) et la notification « au plus tard 72 heures après avoir eu connaissance de la vulnérabilité activement exploitée » (l. 3030). Pour l'incident, l'alerte précoce est due « au plus tard 24 heures après en avoir eu connaissance » (l. 3066) et la notification « au plus tard 72 heures après avoir eu connaissance de l'incident » (l. 3073). Le sujet de « avoir eu connaissance » est, dans les quatre cas, le fabricant, désigné au §1 et au §3 comme celui qui « prend connaissance » (l. 3016, l. 3057).

Le délai court donc à partir de la connaissance par le fabricant. Il ne court pas à partir de la découverte de la vulnérabilité par un tiers, ni à partir de la publication d'un identifiant CVE, ni à partir de la mise à disposition d'un correctif : aucun de ces trois événements n'apparaît aux l. 3025, 3030, 3066 et 3073 comme point de départ. Les deux délais de 24 heures et de 72 heures partent du même instant et ne s'enchaînent pas ; la notification b) n'est pas due 72 heures après l'alerte a), elle est due 72 heures après la connaissance.

Le texte ne définit pas le moment de la « connaissance ». Le règlement ne dit pas si la connaissance s'entend de celle d'un employé quelconque, de celle du service chargé de la sécurité, ou de celle de la direction. Il ne dit pas non plus quel degré de certitude est requis pour que l'on puisse parler de connaissance d'une vulnérabilité « activement exploitée » par opposition à une vulnérabilité simplement soupçonnée. La présente section constate cette absence et ne la comble pas.

4.4 Les deux horloges du rapport final

Les deux rapports finaux portent des points de départ différents, que l'on place ici en regard. Voie vulnérabilité : « un rapport final, au plus tard 14 jours après la mise à disposition d'une mesure de correction ou d'atténuation » (l. 3037-3038). Voie incident : « dans un délai d'un mois à compter de la présentation de la notification d'incident visée au point b), un rapport final » (l. 3079-3080).

Dans la voie vulnérabilité, l'horloge du rapport final ne démarre pas tant qu'aucune mesure de correction ou d'atténuation n'est mise à disposition ; dans la voie incident, elle démarre à la présentation de la notification b) par le fabricant lui-même. Le premier point de départ est un fait technique dépendant de l'existence d'une mesure ; le second est un acte du fabricant, daté par lui puisque c'est lui qui présente la notification. Ce point est le trou (c) de la section 7, tranché ici sur le verbatim.

Deux conséquences se lisent sur le texte. D'une part, pour la voie vulnérabilité, l'article 14 ne fixe aucune butée absolue au rapport final : le seul délai chiffré, 14 jours, est rattaché à la mise à disposition d'une mesure, et aucune autre date limite n'apparaît aux l. 3037-3048. Hypothèse de lecture : tant qu'aucune mesure de correction ou d'atténuation n'est mise à disposition, le délai de 14 jours n'a pas commencé à courir, et le texte de l'article 14 ne contient pas de mécanisme qui le déclencherait autrement. D'autre part, pour la voie incident, le délai d'un mois est rattaché à un acte dont la date est connue du fabricant au moment où il l'accomplit, ce qui rend la butée déterminable dès la présentation de la notification b).

Ce que le texte ne dit pas : ce qui se passe si aucune mesure de correction ou d'atténuation n'est jamais mise à disposition. L'article 14 ne prévoit ni délai de substitution, ni obligation de rapport final en l'absence de mesure, ni clause traitant du produit qui ne serait jamais corrigé. La question est non tranchée par le texte de l'article 14.

4.5 La réserve « à moins que les informations pertinentes n'aient déjà été communiquées »

La même réserve ouvre quatre alinéas. Elle précède la notification de vulnérabilité (l. 3029), le rapport final de vulnérabilité (l. 3037), la notification d'incident (l. 3072) et le rapport final d'incident (l. 3079). Elle ne précède pas l'alerte précoce de vulnérabilité (l. 3024) ni l'alerte précoce d'incident (l. 3065). La répartition est symétrique dans les deux voies : la réserve accompagne les étapes b) et c), elle est absente de l'étape a).

La lecture qui en découle est la suivante. L'alerte précoce à 24 heures est due dans tous les cas ; aucune communication antérieure ne peut la remplacer, puisque le texte ne l'assortit d'aucune réserve. Les étapes b) et c) peuvent au contraire être absorbées par une communication antérieure, à condition que les « informations pertinentes » aient « déjà été communiquées ». Une alerte précoce qui contiendrait déjà l'ensemble des éléments attendus à l'étape b) pourrait, selon les termes de la réserve, dispenser de cette étape ; le texte ne l'exclut pas.

Le texte ne précise pas qui juge que les informations « pertinentes » ont été communiquées. Il ne dit pas si cette appréciation relève du fabricant qui s'abstient de soumettre l'étape suivante, du CSIRT coordinateur qui la reçoit, ou de l'ENISA. Il ne définit pas non plus ce que recouvre le mot « pertinentes » par rapport aux listes de contenu des l. 3029-3034, 3041-3048, 3072-3076 et 3083-3089. Cette absence est constatée et laissée telle quelle.

4.6 Rapport intermédiaire et marquage de sensibilité

Le §6 prévoit un rapport supplémentaire : « Si nécessaire, le CSIRT désigné comme coordinateur qui reçoit initialement la notification peut demander au fabricant de fournir un rapport intermédiaire de situation concernant la vulnérabilité activement exploitée ou l'incident grave ayant des répercussions sur la sécurité du produit comportant des éléments numériques. » (l. 3105-3107). Le verbe est « peut demander » : il s'agit d'une faculté du CSIRT coordinateur, subordonnée à la condition « si nécessaire », et non d'une obligation spontanée du fabricant. Le fabricant n'a pas à produire ce rapport de sa propre initiative ; il le fournit sur demande. Le texte ne fixe aucun délai pour ce rapport intermédiaire, ni pour la demande du CSIRT, ni pour la réponse du fabricant, et n'en précise pas le contenu au-delà de l'expression « rapport intermédiaire de situation ».

Le degré de sensibilité apparaît aux étapes b) des deux voies, et uniquement là. Pour la notification de vulnérabilité, le fabricant précise « s'il y a lieu, le degré de sensibilité qu'il attribue aux informations notifiées » (l. 3034). Pour la notification d'incident, il précise « le cas échéant, le degré de sensibilité qu'il attribue aux informations notifiées » (l. 3076). Dans les deux cas, c'est le fabricant qui « attribue » ce degré, et la formulation conditionnelle (« s'il y a lieu », « le cas échéant ») laisse au fabricant l'appréciation de l'opportunité du marquage. Le texte de l'article 14 ne définit pas d'échelle de sensibilité et ne dit pas quel effet ce marquage produit chez le destinataire.

4.7 Ce que la section établit

Je tiens pour établi, sur le seul verbatim de l'article 14, que les deux voies partagent une même structure en trois étapes et un même point de départ pour les délais de 24 heures et de 72 heures, la connaissance par le fabricant, sans que le texte définisse ce moment. Je tiens également pour établi que le rapport final relève de deux horloges distinctes, l'une rattachée à la mise à disposition d'une mesure, l'autre à la présentation de la notification b), et que la première ne connaît aucune butée absolue dans le texte. La réserve « à moins que les informations pertinentes n'aient déjà été communiquées » épargne l'alerte précoce et couvre les deux étapes suivantes, sans que le texte désigne l'autorité qui en apprécie la satisfaction. Le rapport intermédiaire est une faculté du CSIRT coordinateur, sans délai. Le marquage de sensibilité est un acte du fabricant, à l'étape b) seulement. Le texte chiffre les délais ; il ne définit pas la connaissance qui les déclenche.

Source : Règlement (UE) 2024/2847, JO L du 20 novembre 2024, version française, article 14, lignes 3012 à 3114 du fichier de travail JO-FR-L_202402847.md [3]. Deux passages du fichier local (art. 64 §10 et art. 69 §3) ont fait l'objet du rectificatif [1] ; ils ne concernent pas la présente section.

5. Ce qui ne s'applique pas encore, et quand : le calendrier et le coût de l'article 14

5.1 Ce qui n'est pas encore applicable

Le règlement est entré en vigueur « le vingtième jour suivant celui de sa publication au Journal officiel de l'Union européenne » (art. 71 §1, l. 5444-5445). Le fichier officiel n'imprime aucune date d'entrée en vigueur ; la publication au Journal officiel datant du 20 novembre 2024, la date du 10 décembre 2024 est une date dérivée, non un chiffre du texte. L'entrée en vigueur ne déclenche par elle-même aucune obligation à la charge des fabricants. Le calendrier d'application est fixé par l'article 71 §2 : « 2. Le présent règlement est applicable à partir du 11 décembre 2027. » (art. 71 §2, l. 5457). Le même paragraphe pose deux exceptions, et deux seulement : « Toutefois, l'article 14 est applicable à partir du 11 septembre 2026 et le chapitre IV (articles 35 à 51) à partir du 11 juin 2026. » (art. 71 §2, l. 5460-5461).

Le tableau suivant reprend, obligation par obligation, la date à partir de laquelle chacune devient applicable.

Le 11 septembre 2026 n'ouvre rien d'autre que l'article 14. Ce jour-là, aucun marquage CE n'est exigible, aucune documentation technique ne doit exister au sens de l'article 31, aucune évaluation de la conformité n'est requise et aucune exigence de l'annexe I n'est opposable à un fabricant. Le chapitre IV, applicable depuis le 11 juin 2026, concerne les autorités notifiantes et les organismes notifiés, c'est-à-dire l'appareil de certification que les États membres mettent en place avant l'échéance de 2027. Le 11 septembre 2026 est la date d'entrée en application d'un seul article, pas une échéance de conformité.

5.2 Article 69 : le parc existant

L'article 69 règle le sort des produits déjà présents sur le marché. Son paragraphe 1 vise les attestations délivrées sous d'autres législations d'harmonisation : « 1. Les attestations d'examen UE de type et les décisions d'approbation délivrées en ce qui concerne les exigences de cybersécurité applicables aux produits comportant des éléments numériques qui sont soumis à d'autres législations d'harmonisation de l'Union restent valables jusqu'au 11 juin 2028, à moins qu'elles n'expirent avant cette date, ou sauf disposition contraire dans toute autre législation d'harmonisation de l'Union, auquel cas elles restent valables conformément à cette législation. » (art. 69 §1, l. 5404-5408).

Le paragraphe 2 pose la règle générale pour le parc existant : « 2. Les produits comportant des éléments numériques qui ont été mis sur le marché avant le 11 décembre 2027 ne sont soumis aux exigences énoncées dans le présent règlement que si, à compter de cette date, ces produits font l'objet d'une modification substantielle. » (art. 69 §2, l. 5411-5413).

Le paragraphe 3 introduit une dérogation propre à l'article 14. Son libellé est cité ici depuis le rectificatif [1], qui constitue le texte en vigueur : « Par dérogation au paragraphe 2, les obligations prévues à l'article 14 s'appliquent à tous les produits comportant des éléments numériques relevant du champ d'application du présent règlement qui ont été mis sur le marché avant le 11 décembre 2027. » Ce libellé est la lecture après rectificatif. Elle est confirmée par une relecture indépendante du 8-9 septembre 2026 sur la source primaire EUR-Lex (rectificatif [1], version française), conduite en dehors de la consultation initiale ; le dossier repose donc, sur ce point précis, sur le texte du rectificatif tel que publié sur EUR-Lex, lu deux fois par des consultations distinctes.

Hypothèse : un lecteur qui ouvre le PDF du Journal officiel du 20 novembre 2024 sans passer par la version consolidée lira la version fautive du paragraphe 3 et pourra en tirer une conclusion inverse de celle qui suit.

La combinaison de l'article 71 §2 et de l'article 69 §3 produit la conséquence suivante, et la lecture que je tiens est celle-ci : un produit déjà sur le marché en septembre 2026, ou mis sur le marché entre septembre 2026 et décembre 2027, entre dans l'obligation de notification de l'article 14, et dans elle seule. Aucune autre obligation du règlement ne l'atteint tant qu'il ne fait pas l'objet d'une modification substantielle à compter du 11 décembre 2027. La FAQ de la Commission, point 5.3 [2], va dans le même sens ; elle est citée en corroboration seulement et n'a pas de valeur opposable.

La notion charnière est définie à l'article 3, point 30 (l. 2357-2360) : une modification apportée au produit après sa mise sur le marché, qui a une incidence sur sa conformité aux exigences de l'annexe I, partie I, ou qui change l'utilisation prévue pour laquelle il a été évalué. Le verbatim complet de cette définition figure en section 1. Un produit du parc existant qui subit une telle modification après le 11 décembre 2027 bascule dans le régime complet ; jusque-là, seule la notification des vulnérabilités activement exploitées et des incidents graves le concerne.

Note sur la coquille du Journal officiel. Le Journal officiel imprimé du 20 novembre 2024, version française, lit à l'article 69 §3 « mis sur le marché le 11 décembre 2027 », sans le mot « avant » ; le paragraphe 2 du même article porte bien « avant ». Le rectificatif [1] du 2 juillet 2025 ajoute « avant » au paragraphe 3. Un lecteur qui ouvre le PDF du Journal officiel d'origine verra la version fautive ; la version consolidée sur EUR-Lex porte la correction. Le même rectificatif corrige l'article 64 §10, où « paragraphes 2 à 9 » remplace « paragraphes 3 à 9 ». La version anglaise portait déjà « before » à l'article 69 §3 et n'a pas eu besoin de cette correction.

5.3 Asymétrie de calendrier entre fabricant et intendant de logiciels ouverts

Le fabricant notifie à partir du 11 septembre 2026 (art. 71 §2, l. 5460), y compris pour son parc existant en vertu de l'article 69 §3 [1]. La situation de l'intendant de logiciels ouverts est différente. L'article 3 le définit comme « une personne morale, autre que le fabricant, qui a pour objectif ou finalité de fournir un soutien systématique et continu au développement de produits spécifiques comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts et sont destinés à des activités commerciales, et qui assure la viabilité de ces produits; » (art. 3 pt 14, l. 2278-2281).

L'intendant n'est pas destinataire direct de l'article 14. Il n'y est soumis qu'à travers l'article 24 §3 : « 3. Les obligations prévues à l'article 14, paragraphe 1, s'appliquent aux intendants de logiciels ouverts dès lors qu'ils participent au développement des produits comportant des éléments numériques. Les obligations prévues à l'article 14, paragraphes 3 et 8, s'appliquent aux intendants de logiciels ouverts dès lors que des incidents graves ayant des répercussions sur la sécurité des produits comportant des éléments numériques touchent les réseaux et les systèmes d'information fournis par les intendants de logiciels ouverts pour le développement de ces produits. » (art. 24 §3, l. 3625-3629).

L'article 71 §2 n'avance que deux blocs : l'article 14 et le chapitre IV. Il n'avance pas l'article 24. Or c'est l'article 24 §3, et lui seul, qui rend l'article 14 applicable à l'intendant. Sur la dérogation énumérative de l'article 71 §2, l'obligation de l'intendant ne naît donc que le 11 décembre 2027, date d'application générale du règlement. La FAQ de la Commission, point 5.5 [2], corrobore cette lecture ; elle n'est pas opposable. Cette conclusion est une lecture sur le texte, non une position officielle vérifiée. Entre le 11 septembre 2026 et le 11 décembre 2027, un même incident grave peut ainsi déclencher une obligation de notification chez le fabricant qui intègre un composant ouvert, et aucune chez l'intendant qui le maintient.

5.4 Sanctions

Le règlement ne fixe pas lui-même les sanctions ; il en confie la détermination aux États membres : « 1. Les États membres déterminent le régime des sanctions applicables aux violations du présent règlement et prennent toutes les mesures nécessaires pour assurer la mise en œuvre de ces sanctions. Ces sanctions doivent être effectives, proportionnées et dissuasives. Les États membres informent la Commission, sans retard, du régime ainsi déterminé et des mesures ainsi prises, de même que, sans retard, de toute modification apportée ultérieurement à ce régime ou à ces mesures. » (art. 64 §1, l. 5241-5244).

Il fixe en revanche des plafonds d'amendes administratives par paliers. Le palier le plus élevé couvre l'article 14 : l'article 64 §2 (l. 5247-5250) fixe pour la violation des exigences de l'annexe I et des obligations des articles 13 et 14 une amende administrative pouvant atteindre 15 000 000 EUR ou, si l'auteur de l'infraction est une entreprise, un plafond exprimé en pourcentage du chiffre d'affaires annuel mondial total réalisé au cours de l'exercice précédent, le montant le plus élevé étant retenu — paraphrase de l'article 64 §2, verbatim au fichier JO-FR-L_202402847.md (:5247-5250), le texte citant le plafond en pourcentage (« deux virgule cinq pour cent », non reproduit ici). Ces montants sont du texte règlementaire ; ils fixent un plafond, non un montant dû.

Le deuxième palier, 10 000 000 EUR ou deux pour cent du chiffre d'affaires annuel mondial, vise les articles 18 à 23, 28, 30 §1 à 4, 31 §1 à 4, 32 §1 à 3, 33 §5, 39, 41, 47, 49 et 53 (art. 64 §3, l. 5253-5257) ; l'article 14 n'y figure pas. Le troisième palier, 5 000 000 EUR ou un pour cent, sanctionne « La fourniture d'informations inexactes, incomplètes ou trompeuses aux organismes notifiés et aux autorités de surveillance du marché en réponse à une demande » (art. 64 §4, l. 5260-5263). Ce troisième palier est distinct d'une notification défectueuse au titre de l'article 14 : il vise la réponse à une demande d'une autorité, non la notification spontanée d'une vulnérabilité ou d'un incident.

Le montant est fixé au cas par cas selon des critères énumérés au paragraphe 5 (art. 64 §5, l. 5275-5287) : a) la nature, la gravité, la durée et les conséquences de l'infraction ; b) les amendes déjà imposées pour une infraction similaire ; c) la taille de l'opérateur, « en particulier en ce qui concerne les microentreprises, les petites et moyennes entreprises, y compris les jeunes entreprises, et la part de marché ».

Le paragraphe 10 prévoit deux exemptions. Son chapeau est cité depuis le rectificatif [1] : « Par dérogation aux paragraphes 2 à 9, les amendes administratives visées auxdits paragraphes ne s'appliquent pas: ». Suivent les deux cas : « aux fabricants considérés comme des microentreprises ou des petites entreprises en cas de non-respect du délai visé à l'article 14, paragraphe 2, point a), ou à l'article 14, paragraphe 4, point a); » (art. 64 §10 a, l. 5312-5313) et « à toute violation du présent règlement par les intendants de logiciels ouverts. » (art. 64 §10 b, l. 5316).

La portée de l'exemption a) est étroite. Elle ne couvre que le délai de 24 heures de l'alerte précoce, tant pour une vulnérabilité activement exploitée (art. 14 §2 a, l. 3024-3026) que pour un incident grave (art. 14 §4 a, l. 3065-3069). Elle ne couvre pas le délai de 72 heures de la notification de vulnérabilité ou d'incident, pas le rapport final, et pas les moyennes entreprises. Les termes « microentreprise » et « petite entreprise » renvoient à l'annexe de la recommandation 2003/361/CE (art. 3 pt 19, l. 2307-2308) ; les seuils chiffrés de cette annexe n'ont pas été consultés pour ce dossier. La coquille corrigée par le rectificatif pèse ici directement : avant correction, le chapeau du paragraphe 10 visait les « paragraphes 3 à 9 », ce qui laissait le palier du paragraphe 2, celui de l'article 14, hors du champ de l'exemption ; l'exemption a), qui ne parle que de l'article 14, se trouvait ainsi vidée de sens. Le texte rectifié rétablit la cohérence entre le chapeau et son point a).

5.5 Régime belge

Le fichier officiel ne contient aucun régime national de sanctions ni aucune désignation d'autorité. L'article 64 §1 renvoie cette matière aux États membres (art. 64 §1, l. 5241-5244). Au 8 septembre 2026, aucun instrument belge de désignation d'autorité ou de sanction pris au titre du règlement 2024/2847 n'a été identifié pour ce dossier. Ce vide est consigné comme tel et correspond au trou ouvert (b) de la section 7 « Zones d'incertitude ». Pour la France, le fichier officiel ne contient pas davantage d'information ; le régime français n'a pas été recherché pour ce dossier. Au 8 septembre 2026, le seul texte de sanction qui se lit au titre de l'article 14 est l'article 64 du règlement, dans sa version rectifiée du 2 juillet 2025 : il fixe des plafonds et renvoie le régime lui-même aux États membres.

6. Ce qu'il faut avoir en place le 11 septembre 2026

6.0 Chapeau

Cette section répond à une question unique : un éditeur de logiciels ou un fabricant de produits comportant des éléments numériques est-il concerné le 11 septembre 2026 et, si oui, que doit-il avoir en place ce jour-là. Le 11 septembre 2026 est la date d'entrée en application de l'article 14 seul, fixée par l'article 71 §2, second alinéa (:5460-5461) ; ce n'est pas une échéance qui tombe et rien n'est à déposer ce jour-là. La section ne reprend que ce que le texte impose, chaque ligne étant rattachée à un article et à un numéro de ligne du fichier officiel JO-FR-L_202402847.md, au format :NNNN. L'intitulé imprimé de l'article 14 est « Obligations en matière de communication d'informations incombant aux fabricants » (:3012) ; le corps de l'article dit « Un fabricant notifie » (:3015, :3056). Là où le texte impose un résultat sans prescrire le moyen, la colonne « Moyen » porte la mention exacte « moyen non prescrit par le texte ». La section ne contient aucun conseil, aucun outil, aucun prix ; elle reprend les sections 1 à 5 sans y ajouter d'affirmation ni de source.

6.1 Tableau : ce qu'il faut avoir en place

6.2 Ce qui n'est pas requis le 11 septembre 2026

Voir section 5. Les obligations suivantes n'entrent pas en application le 11 septembre 2026.

• Exigences de cybersécurité de l'annexe I (annexe I, :5496-5499 ; art. 6, :2501-2516) : applicables le 11 décembre 2027 (:5457).
• Marquage CE (art. 30, :3846-3849) : 11 décembre 2027.
• Documentation technique (art. 31, :3898-3901) : 11 décembre 2027.
• Évaluation de la conformité (art. 32, :3931-3934) : 11 décembre 2027.
• Surveillance du marché, chapitre V (:4588-4597) : 11 décembre 2027. Au 11 septembre 2026, un destinataire de notification existe ; il n'y a pas encore d'autorité belge de surveillance du marché au titre du CRA.
• Obligations des intendants de logiciels ouverts, y compris l'art. 24 §3 qui étend l'article 14 aux intendants (:3625-3629) : 11 décembre 2027. L'art. 71 §2 n'avance que l'article 14 et le chapitre IV.
• Chapitre IV, articles 35 à 51 (:4089), applicable depuis le 11 juin 2026 (:5460-5461) : il vise les autorités notifiantes et les organismes notifiés, pas les fabricants.
• Signalement volontaire de l'article 15 (:3184-3187, :3190-3192) : faculté (« peuvent notifier »), jamais une obligation ; il n'impose pas d'obligations supplémentaires (§5, :3208-3212).
• Seconde notification au titre de NIS2 : ni imposée ni dispensée par le règlement. Les articles 14 à 16 (:3009-3307) ne contiennent aucune clause de dispense ni de coordination ; les deux régimes coexistent (section 3).

6.3 Ce qui est établi

Je retiens de la lecture des sections 1 à 5 que ce que le texte impose au 11 septembre 2026 tient en peu de choses : une notification à deux destinataires, le CSIRT désigné comme coordinateur et l'ENISA, par un canal unique, la plateforme de l'article 16, déclenchée par la connaissance qu'a le fabricant d'une vulnérabilité activement exploitée ou d'un incident grave, en trois étapes à délais fixés (24 heures, 72 heures, rapport final à 14 jours ou à un mois selon le cas), plus l'information des utilisateurs « en temps utile ». Le rapport intermédiaire relève d'une demande du CSIRT, pas d'une initiative du fabricant. Deux points restent ouverts et sont marqués comme tels : l'identification du CCB comme CSIRT désigné comme coordinateur pour la Belgique procède d'une déduction, et l'état opérationnel de la plateforme au 8 septembre 2026 n'a pas été vérifié dans ce dossier. Tout le reste, exigences de l'annexe I, marquage CE, documentation technique, évaluation de la conformité et surveillance du marché, attend le 11 décembre 2027. Le 11 septembre 2026, l'article 14 s'applique ; il ne réclame rien ce jour-là.

7. Zones d'incertitude

Cette section rassemble ce que les sections 1 à 5 ont laissé ouvert. Chaque trou y porte son nom, sa section d'origine, les faits qui l'entourent et son statut. Rien n'y est comblé : les incertitudes s'écrivent telles qu'elles sont au 8 septembre 2026. Les références numérotées renvoient à la liste des Références en fin de dossier.

7.1 Trous ouverts nommés

(a) la section 5.4 de la FAQ de la Commission sur les composants tiers et les FOSS

Statut : OUVERT.

La FAQ des services de la Commission, version 1.4 du 4 septembre 2026 [2], est un document de services non contraignant. Son propre avertissement indique qu'elle ne représente pas la position officielle de la Commission. Le règlement, à l'article 14, ne contient aucune clause propre aux composants tiers intégrés. Le seul test normatif est la définition de la vulnérabilité activement exploitée, article 3 point 42 (:2413-2414), appliquée au produit tel que livré.

La section 5.4 de la FAQ retient que le fabricant du produit notifie si la vulnérabilité d'un composant est activement exploitée, et qu'une vulnérabilité de composant non exploitable dans le produit ne serait pas soumise à notification obligatoire. Cette lecture ne fonde aucune exclusion : elle décrit une application du point 42 au produit livré, sans ajouter de règle au texte.

Une correction d'attribution s'ajoute à ce constat, sans le remplacer. La section 5.4 de la FAQ porte sur les composants tiers en général, sans distinction de licence. Les composants libres et ouverts, définis à l'article 3 point 48 (:2435-2437), sont traités à la section 4.4.4 de la FAQ, qui concerne la diligence raisonnable et non la notification. Une référence antérieure du dossier attribuait à tort les FOSS à la section 5.4 ; la section 2.5 consigne cette correction.

Le trou reste ouvert sur un point que le dossier ne peut fermer : ce que vaut la lecture de la FAQ devant une autorité de surveillance ou un juge n'est établi par aucun texte.

(b) l'absence de tout instrument belge de désignation au titre du CRA au 8 septembre 2026

Statut : OUVERT, agrégé des sections 3 et 5.

Le CSIRT désigné comme coordinateur est défini par renvoi à l'article 12 §1 de la directive (UE) 2022/2555, article 3 point 51 (:2446-2447). La seule source publique consultée qui nomme un point d'entrée belge est la liste ENISA [4], page « Updated: 04/09/2026 ». La ligne belge de cette liste ne porte qu'une URL, https://ccb.belgium.be/contacts, sans nom d'entité. L'identification du Centre pour la Cybersécurité Belgique (CCB) comme CSIRT coordinateur au titre du règlement est une déduction de domaine, et non la lecture d'un acte belge. Hypothèse de travail : le CCB est le destinataire belge des notifications de l'article 14, parce que l'URL listée par l'ENISA pointe vers son domaine et parce que le point 51 renvoie à la désignation opérée sous la directive (UE) 2022/2555 ; aucun acte belge de désignation au titre du règlement n'a été lu pour l'établir.

Côté sanctions, l'article 64 §1 (:5241-5244) renvoie le régime aux États membres. Aucun instrument belge de désignation d'autorité ou de sanction pris au titre du règlement n'a été identifié au 8 septembre 2026. Le chapitre V, relatif à la surveillance du marché, n'est applicable qu'au 11 décembre 2027 (:5457). Il en résulte qu'au 11 septembre 2026 il existe un destinataire de notification et pas de contrepartie belge de surveillance du marché au titre du CRA.

Les pages du CCB sur le CRA [6] et sur les notifications NIS2 [7] sont des sources à contrôle humain : leur contenu a été consulté, il n'a pas été rouvert par le rôle de contrôle.

(c) le point de départ du délai de l'article 14 pour le rapport final

Statut : TRANCHÉ SUR LE VERBATIM (section 4).

Voie vulnérabilité activement exploitée : « un rapport final, au plus tard 14 jours après la mise à disposition d'une mesure de correction ou d'atténuation » (:3037-3038). Voie incident grave : « dans un délai d'un mois à compter de la présentation de la notification d'incident visée au point b), un rapport final » (:3079-3080). Le texte fixe donc deux horloges distinctes : un fait technique dans la première voie, la mise à disposition d'une mesure ; un acte du fabricant dans la seconde, la présentation de la notification d'incident.

Ce que le texte ne dit pas reste non comblé. La voie vulnérabilité ne comporte aucune butée absolue si aucune mesure n'est jamais mise à disposition : le délai de 14 jours ne court pas, et le texte ne prévoit rien à sa place. Le texte ne définit pas non plus le moment de la « connaissance » qui déclenche les délais de 24 heures et de 72 heures dans les deux voies (:3025, :3030, :3066, :3073).

7.2 Trous supplémentaires nommés par les sections 1 à 5

Le pur service hébergé sans artefact livré

Section d'origine : section 1. Statut : OUVERT.

L'article 3 point 1 (:2226-2227) rattache « ses solutions de traitement de données à distance » à un produit. Le point 2 (:2230-2232) est cumulatif : paternité du fabricant et nécessité fonctionnelle pour « une de ses fonctions ». Le considérant 12 (:212-223) renvoie les modèles SaaS, PaaS et IaaS à la directive (UE) 2022/2555, mais un considérant n'a pas la portée d'un article, et sa première phrase renvoie elle-même au test de la définition. Le fichier officiel ne contient aucune disposition qualifiant expressément le service accessible uniquement par navigateur, ni pour l'inclure ni pour l'exclure.

Les orientations de la Commission du 27 juillet 2026 et la prise de position de DIGITALEUROPE, décrites au point (v) de la section 7.4, forment deux voix indépendantes, non lues à la source, non contraignantes. Ce qui est tranché par la section 1 : un artefact livré (agent, application mobile, connecteur, extension) entraîne le service dans le champ. Le cas du service sans aucun artefact livré reste sans réponse textuelle.

La lecture rectifiée de l'article 69 §3, confirmée par relecture indépendante

Sections d'origine : sections 1 et 5. Statut : CONFIRMÉ SUR LA VÉRIFICATION ET SUR LE FOND.

Le Journal officiel du 20 novembre 2024, version française, lit à l'article 69 §3 « mis sur le marché le 11 décembre 2027 » sans « avant » (passage à ne pas citer depuis le fichier local). Le rectificatif CELEX 32024R2847R(02), JO L 2025/90555 du 2 juillet 2025 [1], ajoute « avant ». C'est cette lecture rectifiée qui fonde la conclusion des sections 1 et 5 : tout le parc mis sur le marché avant le 11 décembre 2027 entre dans l'obligation de notification dès le 11 septembre 2026.

Cette lecture repose sur deux consultations distinctes de la source primaire EUR-Lex. La première, du 8 septembre 2026, a établi le texte du rectificatif. La seconde, une relecture indépendante du 8-9 septembre 2026 conduite sur la source primaire EUR-Lex (rectificatif [1], version française), a confirmé verbatim les deux points rectifiés : l'article 69 §3 lit « mis sur le marché avant le 11 décembre 2027 » et l'article 64 §10 lit « par dérogation aux paragraphes 2 à 9 ». La version anglaise [8] porte « before 11 December 2027 » sans repère de rectification ; la version consolidée française [9] porte le repère ►C1 à l'article 64 §10. La lecture rectifiée est tenue pour exacte et confirmée. L'article 64 §10 (« paragraphes 2 à 9 ») est couvert par la même confirmation : l'exemption des micro et petites entreprises y est limitée au délai de 24 heures.

L'état opérationnel de la plateforme unique de signalement

Section d'origine : section 3. Statut : OUVERT.

L'ENISA met en place et administre la plateforme (article 16 §1, :3226-3230). Les notifications passent par elle (article 14 §7 alinéa 1, :3110-3114). La Commission « peut » préciser format et procédures par actes d'exécution (article 14 §10, :3172-3175) ; cette faculté n'est assortie d'aucun délai. Aucune déclaration publique vérifiée sur l'état opérationnel de la plateforme au 8 septembre 2026 ne figure dans le dossier. Le CCB annonce se connecter « à la future plateforme » [6], source à contrôle humain.

La coordination CRA/NIS2, absente du texte

Section d'origine : section 3. Statut : OUVERT.

Aucune ligne des articles 14 à 16 (:3009-3307) ne dispense un fabricant qui est aussi entité NIS2 de l'une des deux notifications, ni n'organise la coordination entre elles. Les deux régimes partagent le vocabulaire (point 43, :2417) et le destinataire (point 51) sans fusion des obligations. Le CCB décrit un formulaire NIS2 distinct sans renvoi à la plateforme [7]. Un même événement peut relever des deux régimes ; le texte ne dit rien d'autre.

L'anomalie de renvoi de l'article 16 §2 à la ligne 3239

Section d'origine : section 3. Statut : OUVERT, écrit sans résolution.

L'alinéa 2 de l'article 16 §2 (:3238-3246) rattache le degré de sensibilité à « l'article 14, paragraphe 2, point a) », alors que le point a) est l'alerte précoce à 24 heures, sans champ de sensibilité. Ce champ figure au point b) (:3034). L'alinéa 3 (:3249-3250) renvoie correctement au point b). Aucun rectificatif ne corrige ce renvoi en version française. Le dossier le relève et ne le résout pas.

Notions laissées sans définition par le texte

Sections d'origine : sections 2 et 4. Statut : OUVERT.

Le texte laisse sans définition, ou sans seuil, les notions suivantes : « preuves fiables » du point 42 ; « données ou fonctions sensibles ou importantes » de l'article 14 §5 a) (:3092-3102), absentes du point 44 (:2420-2422) ; « incident grave », qui n'a pas de définition à l'article 3, le seul test étant l'article 14 §5 ; « en temps utile » du §8 (:3154-3162), sans délai chiffré. Le texte ne dit pas non plus qui apprécie que « les informations pertinentes » ont déjà été communiquées (:3029, :3037, :3072, :3079). Les seuils chiffrés des micro et petites entreprises, fixés par l'annexe de la recommandation 2003/361/CE à laquelle renvoie l'article 3 point 19 (:2307-2308), n'ont pas été consultés.

7.3 Sources web non rouvertes par le contrôle

Les six premières références de la recherche du 8 septembre 2026 n'ont pas pu être rouvertes par le rôle de contrôle. Elles sont listées ci-dessous avec URL et date de récupération ; rien de plus fort n'est affirmé à leur sujet. Les références [6] et [7] proviennent d'une consultation du 7 septembre 2026 et portent la mention « source à contrôle humain ».

Verdict de la confirmation du rectificatif. Une relecture indépendante, conduite les 8 et 9 septembre 2026 sur la source primaire EUR-Lex (rectificatif [1], version française), a confirmé verbatim les deux points rectifiés : l'article 69 §3 lit « mis sur le marché avant le 11 décembre 2027 » et l'article 64 §10 lit « par dérogation aux paragraphes 2 à 9 ». La lecture rectifiée des deux passages est confirmée par une consultation indépendante distincte de celle du 8 septembre 2026 ; le dossier repose sur [1] [8] [9], dont [1] relu et confirmé les 8-9 septembre 2026.

7.4 Sources exclues

(i) L'annexe C(2026) 5252 de la Commission ; (ii) l'acceptation par le CEN-CENELEC de la demande de normalisation M/606 ; (iii) la décision d'exécution (UE) 2025/138 : ces trois éléments ne sont pas des sources vérifiées et ne sont cités nulle part dans le dossier.

(iv) Les URL issues d'une consultation antérieure non rouverte, dont une URL enisa.europa.eu inexistante, ne sont pas reprises.

(v) Les orientations de la Commission européenne du 27 juillet 2026 sur le champ d'application, connues par les commentaires de trois cabinets (Hogan Lovells, Lewis Silkin, DLA Piper), et la prise de position de DIGITALEUROPE comptent pour deux voix indépendantes, non lues à la source, non contraignantes ; aucune URL n'en est reproduite.

(vi) Un fichier d'assemblage d'une recherche antérieure, jamais régénéré, n'a pas été consulté.

7.5 Décision laissée à John

Ce qui suit est une hypothèse de ce dossier et non un choix arrêté.

Option retenue par hypothèse : le texte de travail reste le fichier JO-FR-L_202402847.md, extrait du PDF du Journal officiel du 20 novembre 2024, avec ses numéros de ligne. Les deux passages rectifiés, article 69 §3 et article 64 §10, se citent depuis le rectificatif [1], dans une note, et jamais depuis ce fichier.

Alternative : basculer sur la version consolidée CELEX 02024R2847-20241120, qui intègre le rectificatif, au prix de la reprise de toutes les références de ligne du dossier, puisque la pagination et le découpage diffèrent.

Les deux options laissent le fond inchangé. Elles diffèrent sur la traçabilité : un fichier stable à numéros de ligne, avec deux passages à citer en note depuis une autre source, contre un texte à jour sans numéros de ligne. Au 8 septembre 2026, le dossier est écrit selon la première option, et la seconde reste ouverte.

Cette section établit ce sur quoi le dossier tient. Il tient sur le verbatim de l'article 14 pour ses délais et ses destinataires, et il tient sur une source unique, confirmée par relecture indépendante (8-9 septembre 2026, source primaire EUR-Lex), pour l'étendue du parc couvert. Les trous nommés ici restent nommés.

Références

• [1] Rectificatif au règlement (UE) 2024/2847, CELEX 32024R2847R(02), version française, JO L 2025/90555 du 2 juillet 2025, https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R2847R(02) (récupéré le 2026-09-08 ; confirmé par relecture indépendante les 8-9 septembre 2026 sur la source primaire EUR-Lex). Deux points rectifiés : article 64 §10 et article 69 §3.

• [2] FAQ sur la mise en œuvre du règlement sur la cyberrésilience, services de la Commission européenne, version 1.4 du 4 septembre 2026, https://ec.europa.eu/newsroom/dae/redirection/document/123307 (page de renvoi : https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions), récupéré le 2026-09-08. Document de services, non représentatif de la position officielle de la Commission européenne, selon son propre avertissement.

• [3] Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 concernant des exigences horizontales en matière de cybersécurité pour les produits comportant des éléments numériques (règlement sur la cyberrésilience), Journal officiel de l'Union européenne, L, 20 novembre 2024, texte français, fichier de travail JO-FR-L_202402847.md (numéros de ligne cités entre backticks dans le corps).

• [4] ENISA, « List of CSIRTs Designated as Coordinators » — https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators — page « Updated: 04/09/2026 » ; récupéré le 2026-09-08.

• [5] CCB, page de contact — https://ccb.belgium.be/contacts — page non datée ; récupéré le 2026-09-08.

• [6] CCB, « The Cyber Resilience Act (CRA) » — https://ccb.belgium.be/regulation/cra — consulté le 2026-09-07 ; source à contrôle humain.

• [7] CCB, « Notifications NIS2 - Comment procéder ? » — https://ccb.belgium.be/fr/cert/signaler-un-incident/notifications-nis2-comment-proceder — consulté le 2026-09-07 ; source à contrôle humain.

• [8] Version consolidée EN, CELEX 02024R2847-20241120, article 64 §10 sous repère ►C2, article 69 §3 « before 11 December 2027 » sans repère : https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02024R2847-20241120 (récupéré le 2026-09-08)

• [9] Version consolidée FR, CELEX 02024R2847-20241120, article 64 §10 « paragraphes 2 à 9 » sous repère ►C1 : https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:02024R2847-20241120 (récupéré le 2026-09-08)

• [10] Orientations de la Commission européenne du 27 juillet 2026 sur le champ d'application du règlement (UE) 2024/2847. Non lues à la source ; connues par les commentaires de trois cabinets (Hogan Lovells, Lewis Silkin, DLA Piper). La Commission indique elle-même que ces orientations sont non contraignantes. Aucune URL n'est reproduite : les liens proviennent d'une recherche antérieure non rouverte et demandent un contrôle humain avant toute reprise.

• [11] DIGITALEUROPE, prise de position sectorielle sur le champ d'application, antérieure aux orientations de la Commission. Même statut : non rouverte, contrôle humain requis avant citation d'URL.