9 min de lecture - Signalement CRA : répétez le parcours des 24 heures

Le 11 septembre 2026, une partie du règlement européen sur la cyberrésilience, ou Cyber Resilience Act (CRA), devient une contrainte opérationnelle. Les fabricants devront signaler, sur la plateforme unique de l'ENISA, toute vulnérabilité activement exploitée contenue dans un produit comportant des éléments numériques ainsi que tout incident grave affectant la sécurité de ce produit. La page de la Commission européenne consacrée au signalement fixe une alerte précoce sous 24 heures et une notification complétée sous 72 heures.

À trois jours de l'échéance, testez plutôt le parcours. Vos responsables produit, sécurité, ingénierie et juridique savent-ils transformer un signal incomplet en décision étayée, retrouver les versions concernées et déposer pendant que l'enquête continue ?

L'exercice ci-dessous répond à cette question. Il ne détermine pas si une entreprise ou un produit relève du CRA, n'interprète pas le moment auquel une organisation donnée prend connaissance d'un événement et ne remplace pas un conseil juridique qualifié.

Séparez l'obligation de septembre du programme de 2027

Le CRA ne s'applique pas en bloc à une seule date. Le texte du règlement (UE) 2024/2847 rend l'article 14 applicable le 11 septembre 2026, tandis que l'essentiel du règlement s'appliquera à partir du 11 décembre 2027. Présenter l'échéance de septembre comme une conformité CRA complète crée deux difficultés : l'équipe risque de consacrer les derniers jours à un vaste chantier documentaire, alors que le parcours de signalement n'a toujours pas de responsable.

Commencez par une question circonscrite pour chaque produit vendu ou mis à disposition dans l'Union européenne : quelle entité juridique a la qualité de fabricant au sens du CRA, et qui peut déposer en son nom ? Faites confirmer la réponse par un conseil compétent, au regard du produit et du montage commercial. L'équipe de développement, le distributeur, l'intégrateur et le fabricant peuvent tous intervenir sur le même logiciel ; l'accès au code ne tranche pas leur rôle juridique.

Pour une équipe franco-marocaine, ni le bureau, ni la propriété du dépôt, ni le premier destinataire de l'alerte ne désignent automatiquement le fabricant ou le CSIRT coordonnateur. Transmettez les preuves au rôle juridique vérifié.

Limitez le chantier de septembre : évaluez le rôle de fabricant, nommez le titulaire et son suppléant, préparez les trois étapes du signalement et répétez les deux déclencheurs. Les autres travaux liés au CRA ont besoin de leur propre plan piloté.

Traitez séparément les deux déclencheurs

L'article 14 prévoit deux déclencheurs. Une file générique d'« événements de sécurité » risque de les confondre.

Le règlement qualifie une vulnérabilité d'« activement exploitée » lorsque des preuves fiables montrent qu'un acteur malveillant l'a exploitée sans autorisation. Elle doit aussi être contenue dans le produit du fabricant. Une démonstration publique, un score élevé ou une alerte de scanner ne reproduisent pas ce test. Consignez la preuve d'exploitation et le lien avec les versions maintenues.

Un incident est grave s'il affecte ou peut affecter la protection de données ou de fonctions sensibles ou importantes, ou s'il introduit ou peut introduire du code malveillant dans le produit ou les systèmes de l'utilisateur. Reliez les preuves à ce seuil précis.

N'attendez pas une attribution parfaite. L'alerte précoce précède la fin de l'enquête. Ne remplacez pas pour autant l'incertitude par une supposition. Consignez la source, l'heure de réception, l'artefact affecté, les versions connues, le niveau de confiance et les questions ouvertes. Conservez ensuite la décision et son motif, que l'équipe dépose, ne dépose pas ou demande une analyse supplémentaire.

L'autorité finlandaise de cybersécurité, Traficom, propose une séquence opérationnelle utile dans sa liste de préparation au CRA : identifier les produits concernés, nommer un représentant principal et un suppléant, planifier les canaux d'entrée, documenter le processus et le tester. Elle recommande aussi au fabricant du produit final d'évaluer les signalements portant sur un composant tiers et de signaler le cas lorsqu'il a confirmé que son produit est affecté. Appliquez cette recommandation à vos faits et à votre rôle juridique.

Définissez comment le délai atteint l'équipe

Le texte légal rattache les délais de 24 et 72 heures au moment où le fabricant prend connaissance de l'événement. Aucune procédure générique ne peut déterminer cet instant pour un cas réel, mais la répétition révèle les retards qui rendent la question risquée.

Tracez le parcours depuis chaque point d'entrée jusqu'aux personnes qui évaluent le seuil. Incluez les adresses de sécurité, le support, les alertes de dépendances, les prestataires et les signalements envoyés à un ingénieur. Consignez le responsable, les plages couvertes, le suppléant et le délai maximal de transmission.

Le journal peut rester court. Conservez la première réception, la source, la correspondance avec les produits et versions, l'évaluation du déclencheur, le décideur et la preuve de dépôt. Ces champs permettent de reconstruire le parcours sans recopier tout le dossier technique.

Évitez qu'un automatisme décide seul du début ou de la fin du délai juridique. Un outil peut collecter les horodatages, enrichir les données sur les composants et alerter l'équipe d'astreinte. Les personnes responsables ont toujours besoin d'une méthode convenue pour juger la fiabilité des preuves, l'impact sur le produit et la gravité.

Préparez les étapes de dépôt avant l'incident

Le résumé de la Commission européenne et l'article 14 décrivent un dossier progressif, et non un rapport d'enquête achevé dès le premier jour.

L'alerte précoce doit partir sans retard injustifié et sous 24 heures. Elle indique, le cas échéant, les États membres où le produit a été mis à disposition. Pour un incident grave, elle précise aussi si des actes illicites ou malveillants sont soupçonnés.

Dans les 72 heures suivant la prise de connaissance, le fabricant complète le dossier avec les informations disponibles sur le produit, l'exploitation ou l'incident, une première évaluation et les mesures correctives ou d'atténuation. Il peut aussi indiquer le niveau de sensibilité attribué aux informations transmises.

L'échéance finale diffère ensuite. Pour une vulnérabilité activement exploitée, le rapport final doit être remis au plus tard 14 jours après la mise à disposition d'une mesure corrective ou d'atténuation. Pour un incident grave, il doit être remis dans le mois suivant la notification des 72 heures.

Préparez un modèle par étape. Préremplissez seulement la dénomination vérifiée du fabricant, le catalogue de produits et les contacts autorisés. Laissez les faits vides : des hypothèses plausibles sont faciles à déposer et faciles à confondre avec des faits.

L'article 14 prévoit aussi d'informer les utilisateurs affectés et, lorsque cela convient, tous les utilisateurs de l'événement et des mesures disponibles. Préparez les validations et canaux sans supposer qu'un même message conviendra à chaque produit.

Testez la plateforme, pas sa capture d'écran

La page de l'ENISA sur la plateforme unique indique que le service accueillera les signalements obligatoires à partir du 11 septembre. Elle publie un glossaire, des instructions d'inscription et des guides destinés aux représentants principaux et secondaires, tout en précisant que ces documents peuvent évoluer.

Servez-vous des documents actuels pour désigner les deux représentants et examiner les champs. Liez la page officielle dans la procédure et précisez comment vérifier l'état de la plateforme avant un dépôt réel.

Pour un fabricant établi en France, la page CRA de l'ANSSI désigne le CERT-FR comme CSIRT coordonnateur. Elle explique que la plateforme lui transmet la notification ainsi qu'à l'ENISA, sauf circonstances exceptionnelles. Un fabricant établi ailleurs doit vérifier son coordonnateur dans les ressources officielles de l'ENISA au lieu de recopier le parcours français.

Testez avec un cas fictif, vérifiez l'accès du suppléant et conservez le journal. Ne transmettez pas ce cas sur le canal réel, sauf si la plateforme propose une fonction de test qui l'autorise.

Organisez un exercice de quatre heures avec des faits incomplets

Utilisez un produit logiciel fictif et des preuves synthétiques. Au début, remettez au support client un signalement selon lequel une faille d'un composant intégré semble avoir été exploitée. Ne dites pas aux participants si le seuil de l'article 14 est atteint.

L'équipe conserve l'heure et le signalement d'origine, identifie le fabricant et les versions, puis sépare la preuve d'exploitation du lien avec le produit. Elle fait trancher les questions restantes, rédige l'alerte avec les inconnues visibles et prépare l'enquête des 72 heures ainsi que l'information des utilisateurs.

À mi-parcours, retirez le représentant principal de l'exercice. Ajoutez ensuite une seconde version du produit dont le relevé de dépendances est incomplet. Ces changements testent le remplacement du responsable et la correspondance entre composant et produit, pas la capacité de l'équipe à suivre un scénario sans accroc.

Terminez avec des durées. Mesurez la transmission interne la plus longue, le temps d'identification du fabricant, la collecte des champs de l'alerte et la capacité du suppléant à exécuter l'étape autorisée. Attribuez chaque point ouvert à une personne avec une échéance antérieure au 11 septembre.

Cette répétition ne rendra pas l'organisation conforme au CRA. Elle donne aux dirigeants une preuve plus modeste et vérifiable : un parcours précis a su passer de la réception à une décision étayée dans le délai testé.

Sources et limites

Nous avons ouvert et relu toutes les sources ci-dessous le 8 septembre 2026.

• Le règlement (UE) 2024/2847 sur EUR-Lex fournit les définitions, les étapes de l'article 14, l'obligation d'informer les utilisateurs et les dates d'application.
• La page de la Commission européenne sur le signalement CRA résume les délais, le routage et la date de démarrage de la plateforme unique.
• La page de l'ENISA sur la plateforme unique donne accès aux ressources actuelles, au glossaire et aux guides des représentants.
• La page réglementaire CRA de l'ANSSI identifie le CSIRT coordonnateur français et présente le calendrier français.
• La liste de préparation de Traficom apporte les recommandations indépendantes d'une autorité nationale sur le catalogue de produits, les représentants, la réception des signalements et l'exercice.

Le règlement et les instructions officielles priment sur cet article. L'ENISA prévient que ses guides peuvent évoluer. Nous n'avons évalué ni le rôle de fabricant d'une entreprise, ni le périmètre d'un produit, ni le moment de la prise de connaissance, ni le contenu d'une notification ou d'autres obligations juridiques. Le parcours et l'exercice sont une méthode de préparation proposée par Exceev ; ils ne sont ni une procédure approuvée par le régulateur ni une preuve de conformité. Vérifiez la plateforme en ligne, les instructions actuelles et l'analyse juridique avant d'agir.

Notre guide des clauses de cybersécurité pour les prestataires technologiques peut vous aider à recenser les questions contractuelles qui s'ajoutent au signalement réglementaire. La méthode Découvrir, Construire, Livrer d'Exceev montre comment transformer une exigence datée en plan d'ingénierie testé sans confondre une liste de contrôle avec une preuve.