[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:fr:quand-demarre-l-horloge-de-24-heures-du-cra-la-prise-de-connaissance":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"fr","quand-demarre-l-horloge-de-24-heures-du-cra-la-prise-de-connaissance","Quand démarre l'horloge de 24 heures du CRA ? La « prise de connaissance », d'après les orientations de la Commission","Les 24 et 72 heures courent à partir du moment où le fabricant « a connaissance », et le règlement ne dit jamais ce que cela signifie. Les orientations de la Commission du 27 juillet 2026 le disent, aux paragraphes 211 à 218 : un degré raisonnable de certitude, après une évaluation initiale, repris mot pour mot du règlement d'exécution NIS2 et des lignes directrices sur les violations de données du RGPD. Ce que cela fait d'un courriel de client, d'une alerte de scanner, d'une CVE listée dans un composant, d'un zero-day de bug bounty et d'une vulnérabilité que vous connaissiez avant le 11 septembre.","2026-09-11","\nL'article 14(2)(a) du Cyber Resilience Act, règlement (UE) 2024\u002F2847, donne au fabricant 24 heures « après que le fabricant a eu connaissance de la vulnérabilité activement exploitée » pour déposer une alerte précoce, et l'article 14(4)(a) dit la même chose pour un incident grave. La notification de 72 heures court à partir du même moment. Tout ce sur quoi un fabricant sera jugé pendant les trois premiers jours d'un incident dépend du moment où cela s'est produit, et le règlement ne le définit pas. Il définit ce dont il faut avoir connaissance : l'article 3(42) dit qu'une vulnérabilité activement exploitée est une vulnérabilité « pour laquelle il existe des preuves fiables qu'un acteur malveillant l'a exploitée dans un système sans l'autorisation du propriétaire de celui-ci ». Il ne dit pas quand des preuves fiables deviennent une connaissance.\n\nLes orientations de la Commission sur l'application du règlement, C(2026) 5252 du 27 juillet 2026, le disent, à la section 9.1, paragraphes 211 à 218. Cet article, ce sont ces huit paragraphes, avec les deux textes plus anciens dont ils sont copiés, appliqués aux cinq manières dont un fabricant l'apprend réellement.\n\n## Le critère : un degré raisonnable de certitude, après une évaluation initiale\n\nLe paragraphe 213 est la phrase opérante. Un fabricant qui détecte un événement suspect, ou qu'« un particulier, un client, une entité, une autorité, un organe de presse ou une autre source » en informe, « devrait évaluer immédiatement l'événement suspect pour déterminer s'il constitue une vulnérabilité activement exploitée ou un incident grave », et :\n\n> Le fabricant doit donc être considéré comme ayant eu connaissance lorsque, après cette évaluation initiale, il a un degré raisonnable de certitude que : (i) une vulnérabilité contenue dans son produit comportant des éléments numériques est activement exploitée ; ou (ii) un incident grave s'est produit et a conduit à la compromission de la sécurité de son produit comportant des éléments numériques.\n\nTrois choses en découlent, et le paragraphe 214 en énonce deux. Le moment n'est pas le premier signal : « le moment auquel un fabricant peut être considéré comme ayant connaissance dépendra des circonstances », et « dans d'autres cas, il peut falloir un certain temps pour établir si un produit comportant des éléments numériques est affecté par une vulnérabilité et si cette vulnérabilité est exploitée par un acteur malveillant ». L'évaluation n'est ni facultative ni lente : « l'accent devrait être mis sur une action rapide pour procéder à l'évaluation initiale afin de déterminer si ces conditions sont effectivement remplies, en particulier lorsque la vulnérabilité peut présenter un risque important ». Et, d'après le paragraphe 215, on n'attend pas de vous que vous sachiez tout à l'heure 24 : la structure en trois étapes « exige des fabricants qu'ils mettent à jour leurs notifications progressivement, à mesure que leurs enquêtes internes avancent ».\n\nL'horloge ne démarre donc ni à l'arrivée du courriel ni à la fin de l'analyse forensique. Elle démarre lorsqu'une évaluation initiale rapide atteint une certitude raisonnable que votre produit est exploité, ou qu'un incident grave a compromis sa sécurité. Le mot qui porte tout est « rapide », et c'est pourquoi l'évaluation doit être une procédure avec une heure de début et un responsable, plutôt qu'une réunion que quelqu'un convoquera.\n\n## D'où viennent les mots\n\nLe paragraphe 212 indique que les orientations sont « alignées sur le considérant 31 du règlement d'exécution (UE) 2024\u002F2690 de la Commission et sur la section II(A) des lignes directrices 9\u002F2022 sur la notification des violations de données à caractère personnel au titre du RGPD ». Cet alignement n'a rien de vague. Le considérant 31 du règlement d'exécution NIS2 dit : lorsqu'une entité « a détecté un événement suspect, ou après qu'un incident potentiel a été porté à son attention par un tiers, tel qu'un particulier, un client, une entité, une autorité, un organe de presse ou une autre source, l'entité concernée devrait évaluer en temps utile l'événement suspect », et elle « doit donc être considérée comme ayant eu \"connaissance\" de l'incident important lorsque, après cette évaluation initiale, elle a un degré raisonnable de certitude qu'un incident important s'est produit ». Les lignes directrices du CEPD sur les violations, au paragraphe 31, disent qu'un responsable du traitement « doit être considéré comme ayant eu \"connaissance\" lorsqu'il a un degré raisonnable de certitude qu'un incident de sécurité s'est produit et a conduit à la compromission de données à caractère personnel », et le paragraphe 34 admet « une courte période d'enquête » pendant laquelle le responsable « peut ne pas être considéré comme ayant \"connaissance\" », à condition que l'enquête « commence dès que possible ».\n\nLa conséquence pratique est grande pour une entreprise qui dispose déjà d'une procédure RGPD de violation de données, c'est-à-dire toute entreprise ayant des clients. Le déclencheur du CRA est le même déclencheur, appliqué à la sécurité du produit au lieu des données personnelles. La procédure, l'évaluation, les deux horodatages et la personne qui décide peuvent être les mêmes, et une entreprise qui notifie aussi au titre de NIS2 a trois obligations qui tournent sur une seule définition.\n\n## Cinq manières de l'apprendre, et ce que chacune déclenche\n\nLa FAQ de la Commission sur la mise en œuvre, version 1.4 du 4 septembre 2026, section 5.1, énumère comment un fabricant peut avoir connaissance sans l'obliger à surveiller aucun de ces canaux : un client ou un partenaire signalant une activité inhabituelle, du renseignement sur les menaces, la notification d'une agence gouvernementale, le rapport d'un hacker éthique, la télémétrie, les scans ou les pots de miel du fabricant lui-même. Lus avec les orientations, chacun de ces signaux est un « événement suspect » qui déclenche l'évaluation, pas l'horloge.\n\n**Un courriel de client.** L'évaluation commence à la lecture du courriel, et elle doit être immédiate. Si les preuves du client sont ce que la définition appelle fiables, l'évaluation peut prendre une heure, et l'horloge démarre alors. Une équipe qui laisse le courriel jusqu'à lundi ne déplace pas l'horloge à lundi : l'« action rapide » du paragraphe 214 est le critère auquel une autorité de surveillance du marché confrontera la chronologie, et la seule défense est un enregistrement montrant quand l'évaluation a commencé, qui l'a menée et ce qu'elle a conclu.\n\n**Une alerte de scanner signalant que la CVE d'un composant figure sur une liste de vulnérabilités exploitées.** C'est le cas que la plupart des éditeurs de logiciels rencontreront en premier, et le paragraphe 218 y répond. Un fabricant notifie une vulnérabilité activement exploitée « contenue dans son produit ». S'il sait qu'un composant tiers contient une vulnérabilité qui « soit (i) ne peut pas être exploitée dans son produit comportant des éléments numériques (par exemple parce que le code vulnérable n'est pas accessible), soit (ii) n'a pas été exploitée dans son produit comportant des éléments numériques, cette vulnérabilité ne constitue pas une vulnérabilité activement exploitée contenue dans son produit comportant des éléments numériques et n'est donc pas soumise à la notification obligatoire pour ce fabricant ». Une inscription sur une liste est donc un événement suspect. L'évaluation pose deux questions : le code vulnérable est-il accessible dans notre produit, et existe-t-il des preuves fiables qu'il est exploité dans notre produit, et pas seulement dans celui d'un autre. Une certitude raisonnable sur les deux démarre l'horloge ; une certitude raisonnable contre l'une des deux clôt l'affaire comme notification obligatoire, en laissant la voie volontaire de l'article 15 et le devoir de l'article 13(6) de signaler la vulnérabilité en amont au mainteneur du composant. La section 5.4 de la FAQ ajoute que le fabricant du composant lui-même, si le composant a été mis sur le marché séparément, la notifie également.\n\n**Un zero-day issu d'un bug bounty ou d'un laboratoire de test.** Ni une vulnérabilité activement exploitée, ni une notification obligatoire. FAQ 5.2 : un zero-day « découvert par des hackers éthiques, pour lequel il n'existe aucune preuve d'exploitation malveillante antérieure, et qui est divulgué au fabricant du produit dans le cadre de son programme de bug bounty » n'est pas soumis à la notification obligatoire, pas plus que celui trouvé par « un laboratoire d'évaluation de la cybersécurité réalisant des tests pour le compte du fabricant ». Le considérant 68 dit la même chose de la recherche de bonne foi. Les obligations de gestion des vulnérabilités de l'annexe I, partie II, s'appliquent toujours pleinement ; la notification, non.\n\n**Une vulnérabilité que vous connaissiez avant le 11 septembre 2026.** Le paragraphe 217 trace la ligne à l'exploitation, pas à la vulnérabilité. Un fabricant « n'est pas tenu de notifier les vulnérabilités dont il avait déjà connaissance de l'exploitation active avant le 11 septembre 2026 ». Mais « l'obligation s'applique lorsque le fabricant avait connaissance d'une vulnérabilité avant le 11 septembre 2026 sans avoir, à ce moment-là, connaissance d'une exploitation active de celle-ci ». Si l'exploitation survient, ou si vous l'apprenez, après cette date, l'horloge démarre le jour où vous l'apprenez. Une vieille vulnérabilité n'est pas une défense ; une vieille connaissance de son exploitation, si.\n\n**Un incident grave.** Le second volet du paragraphe 213 : une certitude raisonnable qu'« un incident grave s'est produit et a conduit à la compromission de la sécurité de son produit comportant des éléments numériques ». Qu'un incident soit grave relève de l'article 14(5) : il porte atteinte, ou est susceptible de porter atteinte, à la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes, ou il a conduit, ou est susceptible de conduire, à l'introduction ou à l'exécution d'un code malveillant dans le produit ou dans les systèmes d'un utilisateur. Une panne qui ne touche à rien de cela est un incident mais pas une notification. L'évaluation comporte donc, pour les incidents, une troisième question : lequel des deux volets de l'article 14(5) est rempli, et la réponse a sa place dans le champ d'évaluation initiale de la notification de 72 heures.\n\n## Le champ de l'obligation est plus large que le reste du règlement\n\nLe paragraphe 210 fait deux remarques qui surprennent. L'article 14 s'applique à partir du 11 septembre 2026 à tout produit comportant des éléments numériques relevant du champ d'application, « y compris les produits comportant des éléments numériques mis sur le marché avant le 11 décembre 2027 ». Et l'obligation de notification survit à la période d'assistance : « contrairement aux obligations de gestion des vulnérabilités, qui ne perdurent que pendant la durée de la période d'assistance d'un produit, les obligations de notification continuent de s'appliquer après qu'un produit comportant des éléments numériques n'est plus pris en charge ». Pour un produit mis sur le marché avant décembre 2027 ou dont la période d'assistance a expiré, le fabricant doit toujours notifier mais « n'est pas tenu de respecter les obligations de gestion des vulnérabilités énoncées à l'annexe I, partie II ». La FAQ, 5.3, reconnaît que pour les vieux produits le fabricant « peut ne pas être en mesure d'enquêter sur ces vulnérabilités », les environnements de compilation et le personnel ayant disparu, et dit que la notification reste due.\n\n## Après la notification : les utilisateurs, et ce qu'il ne faut pas publier\n\nLes paragraphes 219 à 221 concernent l'article 14(8), le devoir d'informer les utilisateurs touchés « et, le cas échéant, tous les utilisateurs ». Les orientations le lisent de manière fondée sur les risques : informer les utilisateurs « n'implique pas que ces informations doivent être rendues publiques ou divulguées sans discernement », et les fabricants « peuvent limiter la divulgation d'informations détaillées aux utilisateurs ou clients concernés », en particulier pour les produits « utilisés dans des environnements sensibles ou essentiels, où la divulgation publique de détails techniques pourrait elle-même accroître les risques de cybersécurité ». Une divulgation plus large « peut être appropriée » une fois la vulnérabilité atténuée, et l'annexe I, partie II, point 4, exige la divulgation publique des vulnérabilités corrigées une fois la mise à jour de sécurité disponible. Le CSIRT qui a reçu la notification peut informer lui-même les utilisateurs si le fabricant ne le fait pas en temps utile.\n\n## Ce qu'il faut écrire avant d'en avoir besoin\n\nLes orientations font de la « prise de connaissance » une constatation plutôt qu'un fait, et les constatations exigent une procédure. Une page suffit.\n\n1. **Ce qui compte comme événement suspect.** La liste de la FAQ, plus vos propres canaux : l'adresse de contact sécurité qu'exige l'annexe I, le scanner, la file du support client, l'actualité.\n2. **Qui mène l'évaluation initiale, et pour quand.** Une personne nommée et un suppléant, et un plafond pour l'évaluation mesuré en heures. « Immédiatement » et « rapide » sont les mots de la Commission ; un plafond que vous fixez et respectez est la façon de montrer que vous les avez honorés.\n3. **Les deux questions, dans les termes de la Commission.** Pour une vulnérabilité : est-elle dans notre produit et accessible, et existe-t-il des preuves fiables d'exploitation dans notre produit. Pour un incident : s'est-il produit, a-t-il compromis la sécurité du produit, et quel volet de l'article 14(5) s'applique.\n4. **Deux horodatages, tous deux en UTC.** Quand l'événement suspect a été détecté ou reçu, et quand l'évaluation a atteint une certitude raisonnable. Le second est la « prise de connaissance » et démarre l'horloge ; le premier, et l'écart entre les deux, montre que l'évaluation a été rapide. La plateforme de notification demande le second et, pour une vulnérabilité, n'obtiendra le champ que dans une version ultérieure, de sorte que votre propre enregistrement est le seul qui existe le jour même.\n5. **Qui signe la constatation, et où elle est classée.** La personne qui décide que la certitude raisonnable est atteinte, et l'enregistrement que l'autorité de surveillance du marché lira si la chronologie est un jour contestée.\n\nCet enregistrement, c'est ce qu'est l'événement de notification CRA de StandardOS : une détermination du champ d'application, le déclarant et son suppléant nommés, le coordinateur à sélectionner, un horodatage de prise de connaissance avec le raisonnement à côté, et les trois délais calculés à partir de lui dans les termes du règlement plutôt que dans ceux de la plateforme. [La page des délais](\u002Fcyber-resilience-act\u002Freporting-deadlines) les calcule pour quiconque ; [comment la plateforme reçoit ensuite la notification](\u002Farticles\u002Fhow-to-file-a-cra-notification-on-enisa-s-single-reporting-platform) est l'article suivant, et [quel coordinateur la reçoit](\u002Farticles\u002Fwhich-csirt-do-you-report-to-under-cra-article-14) le précédent.\n\n## Sources\n\n- Règlement (UE) 2024\u002F2847, article 3(42), article 13(6), article 14(1) à (5) et (8), article 15, article 69(3), considérant 68.\n- Commission européenne, orientations de la Commission sur l'application du règlement (UE) 2024\u002F2847, C(2026) 5252 final du 27 juillet 2026, annexe, section 9.1 paragraphes 209 à 221 et section 9.2.\n- Commission européenne, FAQ sur le Cyber Resilience Act, version 1.4 du 4 septembre 2026, sections 5.1 à 5.5.\n- Règlement d'exécution (UE) 2024\u002F2690 de la Commission, considérant 31.\n- Comité européen de la protection des données, lignes directrices 9\u002F2022 sur la notification des violations de données à caractère personnel au titre du RGPD, version 2.0, paragraphes 31 à 34.\n\nCeci n'est pas un avis juridique. Les huit paragraphes des orientations se lisent en dix minutes, et les numéros d'article ci-dessus sont là pour que vous puissiez le faire.\n",1789383976969]