CRA : la crise “produit” cyber, ou l’instant où la vulnérabilité devient une affaire réglementaire et commerciale

La plupart des dirigeants ont appris à gérer la crise cyber comme un événement “SI” : une intrusion, un rançongiciel, une fuite, un SOC en alerte, un plan de continuité, puis une communication calibrée. Le Cyber Resilience Act fait basculer le centre de gravité. À partir de septembre 2026, ce n’est plus seulement votre système d’information qui peut déclencher une crise sous contrainte de délai ; c’est votre produit lui-même, c’est-à-dire ce que vous mettez dans les mains de vos clients, ce qui tourne chez eux, ce qui s’exécute dans leurs réseaux, parfois avec votre backend dans le cloud en arrière-plan.

Le changement est culturel autant que juridique : l’incident n’est plus seulement un problème de sécurité interne, il devient un fait de conformité “produit”, comparable, dans sa mécanique, à une crise qualité ou à un rappel. Et cela touche autant les industriels connectés que les éditeurs, les fabricants d’IoT, les acteurs de l’OT, les plateformes logicielles, et toute entreprise qui commercialise un “produit avec éléments numériques” sur le marché européen.

Ce basculement a une date qui compte davantage que celle de l’application générale du texte. Le règlement (UE) 2024/2847 a été publié au Journal officiel le 20 novembre 2024, il est entré en vigueur vingt jours plus tard, et il s’applique globalement à partir du 11 décembre 2027. Mais l’article qui fait naître la “crise produit” avant l’heure, l’article 14, s’applique dès le 11 septembre 2026.

Et surtout, la règle la plus dérangeante pour les organisations qui se rassurent en se disant “nous verrons en 2027”, c’est le caractère rétroactif de cette obligation de reporting : par dérogation aux dispositions transitoires, les obligations de l’article 14 s’appliquent à tous les produits relevant du CRA qui ont été mis sur le marché avant le 11 décembre 2027. Autrement dit, la flotte déjà vendue, déjà déployée, déjà installée, déjà intégrée chez vos clients, entre dans la zone de risque réglementaire dès septembre 2026 analyse l’expert en gestion de crise Florian Silnicki, Président Fondateur de l’agence LaFrenchCom.

La définition de “produit” s’étend : votre cloud peut être dans le périmètre

Le CRA n’est pas un texte pour “les objets connectés” au sens caricatural. Il vise un périmètre large de produits matériels et logiciels avec une connexion directe ou indirecte à un réseau ou à un autre dispositif. Et il va plus loin : il inclut, dans son objectif de sécurité globale, certaines solutions de traitement de données à distance lorsque le logiciel a été conçu et développé par le fabricant (ou pour son compte) et que son absence empêcherait le produit d’assurer une de ses fonctions.

Pour un COMEX, cette précision est déterminante, car elle transforme la cartographie de crise. Le risque “produit” n’est pas limité à un firmware ou à une application installée. Il peut aussi toucher un service distant sans lequel le produit ne “fonctionne” plus : API, service cloud, backend, mécanisme de mise à jour, ou brique d’administration. La crise produit cyber se joue donc dans une continuité : code embarqué, code applicatif, dépendances open source, pipeline de mise à jour, et infrastructure de contrôle.

Le déclencheur CRA : l’exploitation active et l’incident “sévère”, pas seulement la panne

Le CRA ne vous demande pas de reporter toutes les vulnérabilités ni tous les aléas techniques. Il cible deux catégories précises qui, dans une crise, changent tout.

La première est celle des vulnérabilités “activement exploitées” contenues dans un produit avec éléments numériques. Dès que le fabricant en a connaissance, il doit notifier cette vulnérabilité simultanément au CSIRT “coordinateur” compétent et à l’ENISA, via la plateforme de signalement unique prévue par le règlement.

La seconde est celle des “incidents sévères” ayant un impact sur la sécurité du produit. Là encore, dès que le fabricant en a connaissance, la notification doit être adressée simultanément au CSIRT coordinateur et à l’ENISA, via la même plateforme. Le texte définit l’incident sévère en termes d’effets : notamment lorsqu’il affecte ou peut affecter la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou fonctions sensibles/importantes, ou lorsqu’il a conduit ou peut conduire à l’introduction ou l’exécution de code malveillant dans le produit ou dans les systèmes d’information d’un utilisateur du produit.

Pour la gouvernance, la nuance est capitale : on ne parle pas d’un incident “chez vous”, mais d’un incident dont les conséquences se manifestent “chez eux”. Le CRA fait du client un espace d’exposition. Il transforme la sécurité produit en responsabilité d’écosystème.

Le chrono de septembre 2026 : 24 heures, 72 heures, puis la clôture

Le CRA organise une crise sous cadence, exactement comme les grands textes cyber récents : il impose un premier signal avant la certitude complète, puis un enrichissement, puis une clôture documentée.

Pour une vulnérabilité activement exploitée, le fabricant doit transmettre une alerte précoce sans délai indu et, en tout état de cause, dans les 24 heures après en avoir eu connaissance. Il doit ensuite transmettre, sauf si l’information a déjà été fournie, une notification de vulnérabilité dans les 72 heures, comprenant des informations générales sur le produit, la nature générale de l’exploit et de la vulnérabilité, les mesures correctives ou d’atténuation prises, et celles que les utilisateurs peuvent mettre en œuvre, avec, le cas échéant, une indication sur la sensibilité des informations communiquées. Enfin, il doit produire un rapport final au plus tard 14 jours après la disponibilité d’une mesure corrective ou d’atténuation, en incluant au minimum une description de la vulnérabilité (sévérité et impact), et, lorsque disponible, des informations sur l’acteur malveillant, ainsi que des détails sur la mise à jour de sécurité ou les mesures correctives mises à disposition.

Pour un incident sévère, la logique est parallèle : alerte précoce sous 24 heures, avec au minimum l’indication du caractère potentiellement illicite ou malveillant, puis notification d’incident sous 72 heures avec une information générale, une évaluation initiale, des mesures de mitigation, y compris celles que les utilisateurs peuvent prendre, et enfin un rapport final dans le mois suivant la notification 72 heures, décrivant l’incident, sa sévérité et son impact, la menace ou cause racine probable, et les mesures appliquées et en cours.

La conséquence managériale est directe : votre “capacité de crise” ne se mesure plus seulement à la restauration du service, mais à votre capacité à produire des artefacts conformes, dans les délais, tout en maîtrisant la confidentialité et la sécurité de la remédiation.

La plateforme unique ENISA : un guichet, plusieurs États, et une diffusion automatique

La mécanique CRA a été pensée pour éviter le cauchemar du multi-reporting pays par pays. Les notifications obligatoires sont soumises via une plateforme unique (Single Reporting Platform) établie et opérée par l’ENISA. La Commission indique que cette plateforme doit être opérationnelle au 11 septembre 2026, avec une période de test avant cette date, et que l’ENISA a lancé un processus d’acquisition pour la développer.

Le point qui intéresse directement un COMEX, c’est l’orchestration multi-États. Le fabricant notifie via le point d’entrée électronique du CSIRT coordinateur correspondant à son “établissement principal” dans l’Union, et l’information est simultanément accessible à l’ENISA. Ensuite, le CSIRT qui reçoit initialement la notification doit la diffuser sans délai, via la plateforme, aux CSIRTs des États où le fabricant a indiqué que le produit a été mis à disposition.

Cela signifie que la crise “produit” est, par défaut, transfrontalière dès lors que vous avez une distribution européenne. Le dispositif fabrique de la coordination, et, mécaniquement, fabrique aussi de la traçabilité.

L’établissement “principal” : la crise devient aussi un sujet d’organisation et de gouvernance

Un détail juridique a des effets très concrets sur l’exécution. Le règlement précise que l’établissement principal du fabricant, pour ces obligations, est réputé se situer dans l’État membre où les décisions relatives à la cybersécurité de ses produits sont “principalement” prises ; à défaut, là où se trouve l’établissement avec le plus grand nombre de salariés dans l’Union.

L’idée est simple : éviter l’errance des responsabilités. Mais l’effet pour un groupe international est plus profond : votre modèle de gouvernance produit, la localisation des décisions de sécurité produit, et même votre cartographie RH peuvent déterminer le “point d’entrée” CSIRT et donc influencer vos interactions opérationnelles en crise.

Le texte prévoit aussi le cas où le fabricant n’a pas d’établissement principal dans l’Union : l’ordre de détermination bascule alors vers l’État membre où se trouve l’agent autorisé le plus représentatif, ou l’importateur, ou le distributeur, ou, à défaut, là où se trouve le plus grand nombre d’utilisateurs. On voit immédiatement le sujet COMEX : un produit vendu en Europe via un réseau d’importateurs et de distributeurs peut déclencher une crise de reporting où la chaîne commerciale devient un paramètre réglementaire.

La crise “clients” est inscrite dans la loi : vous devez informer les utilisateurs, et vite

Le CRA ne se contente pas d’organiser un reporting aux autorités. Il organise aussi une obligation d’information vers les utilisateurs, et c’est l’un des points les plus structurants pour la communication de crise.

Après avoir eu connaissance d’une vulnérabilité activement exploitée ou d’un incident sévère impactant la sécurité du produit, le fabricant doit informer les utilisateurs impactés, et, lorsque approprié, l’ensemble des utilisateurs, de cette vulnérabilité ou de cet incident, ainsi que, lorsque nécessaire, des mesures de mitigation et des corrections que les utilisateurs peuvent déployer pour réduire l’impact, avec, le cas échéant, une diffusion dans un format structuré et lisible par machine.

Et le texte va plus loin : si le fabricant ne fournit pas cette information en temps utile, les CSIRTs coordinateurs notifiés peuvent eux-mêmes fournir ces informations aux utilisateurs lorsqu’ils le jugent proportionné et nécessaire pour prévenir ou atténuer l’impact.

C’est là que naît la vraie “crise produit”. Une entreprise peut encore croire qu’elle contrôle son récit lorsqu’elle traite une crise SI. Avec le CRA, il faut intégrer une hypothèse nouvelle : si vous n’informez pas, ou si vous tardez, le dispositif institutionnel peut informer à votre place. Ce n’est pas seulement une question de réputation, c’est une question de souveraineté narrative.

Le droit au tempo existe, mais il est encadré : la logique de disclosure coordonnée

L’écosystème cyber a besoin d’un équilibre entre transparence et sécurité opérationnelle. Le CRA l’intègre, notamment via la diffusion des notifications entre CSIRTs.

En substance, après qu’un CSIRT a reçu une notification, il doit la diffuser, mais cette diffusion peut être retardée, dans des circonstances exceptionnelles, sur la base de motifs de cybersécurité justifiés et pour une durée strictement nécessaire, notamment lorsqu’une vulnérabilité fait l’objet d’une procédure de divulgation coordonnée telle que prévue par la directive NIS2. Le CSIRT qui retient une notification doit en informer immédiatement l’ENISA, justifier la retenue, et indiquer quand il diffusera.

La Commission, de son côté, souligne sur sa page dédiée au reporting CRA que, dans ce cadre, le CSIRT peut décider de retarder la dissémination à d’autres CSIRTs sur des motifs de cybersécurité, et qu’un acte délégué adopté le 11 décembre 2025 précise les conditions d’application de ces motifs.

Ce mécanisme est stratégique en communication de crise. Il signifie que la meilleure gestion d’une vulnérabilité exploitée n’est pas l’opacité, mais la coordination : capacité à produire une notification précise, capacité à qualifier la sensibilité de l’information, capacité à synchroniser la publication d’un correctif et la communication aux utilisateurs, capacité à s’inscrire dans une logique de disclosure responsable.

Vous ne déciderez pas toujours du moment où l’affaire devient publique

Autre bascule majeure : l’autorité peut considérer que l’intérêt public commande l’information.

Lorsque la sensibilisation du public est nécessaire pour prévenir ou atténuer un incident sévère, ou pour gérer un incident en cours, ou lorsque la divulgation est autrement dans l’intérêt public, le CSIRT coordinateur peut, après consultation du fabricant et, le cas échéant, en coopération avec l’ENISA, informer le public de l’incident ou exiger que le fabricant le fasse.

Ce seul paragraphe oblige à une hygiène de communication que beaucoup d’entreprises n’ont pas encore industrialisée : en crise produit, l’enjeu n’est pas seulement “que dire”, c’est “être prêt à dire” si l’on vous le demande, dans un cadre où votre silence peut être jugé disproportionné au regard du risque.

La vulnérabilité devient une donnée européenne : le passage par une base de référence

Un autre effet, plus lent mais plus durable, concerne la mémoire institutionnelle des crises.

Après qu’une mise à jour de sécurité ou une mesure corrective/atténuante est disponible, l’ENISA doit, en accord avec le fabricant, ajouter la vulnérabilité “publiquement connue” notifiée au titre du CRA à la base européenne des vulnérabilités mise en place dans le cadre de NIS2.

Cela transforme la vulnérabilité en objet de gouvernance publique. Pour les clients grands comptes, pour les chaînes d’approvisionnement, pour les assureurs, pour les auditeurs, cette base devient un référentiel potentiel. Votre gestion d’une vulnérabilité exploitée ne s’éteint pas au moment où le patch est publié : elle laisse une trace exploitable dans le temps.

La crise produit, c’est aussi une crise de conformité : amendes, rappel, et pouvoir de marché

Dans l’imaginaire managérial, la crise cyber est souvent associée à la confidentialité et à l’image. Le CRA y ajoute une dimension plus brutale : le risque financier administratif, comparable à celui des grands textes de conformité.

Le règlement prévoit que le non-respect des exigences essentielles de cybersécurité (annexe I) et des obligations des articles 13 et 14, donc notamment les obligations de notification et de gestion de vulnérabilités, peut être sanctionné par des amendes administratives allant jusqu’à 15 millions d’euros ou, pour une entreprise, jusqu’à 2,5 % du chiffre d’affaires mondial annuel, selon le montant le plus élevé. D’autres manquements relèvent d’un plafond de 10 millions d’euros ou 2 % du chiffre d’affaires mondial, et l’information incorrecte/incomplète/mensongère peut monter jusqu’à 5 millions d’euros ou 1 %.

Le texte prévoit aussi des nuances importantes, notamment le fait que certaines amendes ne s’appliquent pas aux microentreprises et petites entreprises en cas de non-respect des délais 24 heures pour l’alerte précoce, et qu’il existe une exonération d’amendes pour les “open-source software stewards” pour les infractions au règlement. Ce n’est pas anecdotique : cela révèle une philosophie d’ensemble où l’Europe veut capter les grands risques industriels sans étouffer l’écosystème, tout en rendant non négociable la discipline pour les acteurs dominants.

À côté des amendes, le CRA remet sur la table une logique “rappel produit” appliquée au cyber. Le texte impose, sur toute la période de support, que le fabricant qui sait ou a des raisons de croire que son produit ou ses processus ne sont pas conformes prenne immédiatement les mesures correctives nécessaires pour revenir en conformité, ou retire ou rappelle le produit si c’est approprié. Pour un COMEX, c’est une rupture : l’ultime mesure de remédiation d’une crise cyber produit peut être une mesure de marché, pas seulement une mesure technique.

La crise produit cyber ressemble à un rappel, mais avec une complexité supplémentaire : la vitesse et l’asymétrie

Le rappel classique, en automobile ou en santé, a une mécanique connue : identification, campagne, correctif, communication, suivi. La crise produit cyber conserve cette structure, mais y ajoute deux complexités spécifiques.

La première est la vitesse. Entre le moment où vous êtes “au courant” et le moment où vous devez notifier, le CRA parle d’heures, pas de jours. Cette vitesse crée un impératif de préparation. On ne construit pas une capacité de notification 24 heures en pleine nuit, au moment où l’on découvre que l’exploitation est active.

La seconde est l’asymétrie informationnelle. Dans une crise SI, vous voyez beaucoup. Dans une crise produit, vous dépendez souvent de signaux externes : un CERT, un client, un chercheur, une preuve publique d’exploitation, un “proof-of-concept” partagé. Le CRA l’officialise en permettant des notifications volontaires par des tiers, y compris sur des vulnérabilités, des menaces, des incidents et des “near misses”. Et si un tiers notifie une vulnérabilité exploitée ou un incident sévère, le CSIRT coordinateur doit informer le fabricant sans délai indu.

En clair, vous pouvez ne pas être le premier informé, ni le premier à déclencher le mouvement. Votre capacité de réaction doit donc être conçue comme une capacité d’absorption de signaux externes, pas seulement comme une capacité de détection interne.

Ce que le COMEX doit “posséder” avant septembre 2026 : une mécanique de crise produit, pas un plan cyber générique

Dans beaucoup d’entreprises, la cybersécurité est encore pensée comme une fonction de protection interne. Le CRA force un basculement vers une logique d’ingénierie et de responsabilité produit. La question n’est plus seulement “comment protège-t-on l’entreprise ?”, c’est “comment protège-t-on l’utilisateur, à l’échelle de la base installée, avec une obligation de notification et d’information ?”.

Cela implique une gouvernance qui dépasse le RSSI. La crise CRA mobilise l’ingénierie produit, le support, le juridique, la conformité, les ventes, parfois les partenaires de distribution, et une communication client qui doit être à la fois utile, techniquement prudente, et conforme. Le texte exige explicitement que les mesures de mitigation que les utilisateurs peuvent prendre fassent partie de la notification 72 heures, et que les utilisateurs soient informés et orientés sur les mesures qu’ils peuvent déployer.

Cela implique aussi une discipline de preuve. Le CRA est un texte “produit” : il s’inscrit dans un univers où la documentation, la traçabilité, l’accessibilité des informations sur la durée, et la capacité à démontrer ce qui a été fait sont des réflexes de conformité. On le voit jusque dans l’exigence de transparence sur la période de support, dont la date de fin doit être indiquée clairement au moment de l’achat et, lorsque c’est techniquement faisable, portée à la connaissance de l’utilisateur lorsque le produit atteint la fin de support.

Enfin, cela impose une vision “communication” plus sophistiquée. Le CRA ne vous demande pas de vous justifier auprès d’un journaliste ; il vous demande de rendre vos utilisateurs capables de réduire leur exposition. Et si vous ne le faites pas à temps, un CSIRT peut juger proportionné de le faire pour vous. C’est une incitation extrêmement puissante à industrialiser la communication produit de crise, sous forme d’avis de sécurité cohérents, de mises à jour régulières, et d’un langage stable.

Conclusion : septembre 2026 inaugure une nouvelle grammaire de crise, centrée sur le produit

Le CRA introduit un objet de crise que beaucoup de COMEX n’ont pas encore pleinement internalisé : la crise cyber “produit”, qui ne part pas nécessairement d’une intrusion dans votre SI, mais d’une exploitation active, d’un incident chez l’utilisateur, ou d’un signal externe, et qui déclenche un double devoir, envers les autorités et envers les utilisateurs, sous contrainte de délai.

À partir du 11 septembre 2026, l’horloge démarre vite, le canal est institutionnalisé via une plateforme unique opérée par l’ENISA, la diffusion inter-États est intégrée, l’information aux utilisateurs est obligatoire, et la sanction potentielle place le sujet au niveau du risque d’entreprise.

En pratique, c’est un retour d’expérience grandeur nature : ceux qui aborderont le CRA comme un sujet de conformité “en plus” auront des crises plus longues, plus coûteuses, et plus publiques que nécessaire. Ceux qui l’aborderont comme une discipline produit — au même titre que la qualité, la sécurité, et la gestion de cycle de vie — transformeront ce nouveau reporting en avantage de confiance.