Résumé

  • Depuis le 11 septembre 2026, les fabricants de produits comportant des éléments numériques doivent notifier les vulnérabilités activement exploitées et les incidents graves de sécurité. Le premier avertissement est attendu sous 24 heures, puis une notification plus complète sous 72 heures après la prise de connaissance.
  • Le Single Reporting Platform crée un guichet commun, pas une autorité unique. Le fabricant choisit un CSIRT coordinateur national, qui évalue et diffuse normalement le dossier ; ENISA exploite la plateforme. Au lancement, l’interface est uniquement en anglais, sans API, sans signalement volontaire et sans obligation immédiate pour les intendants de logiciels libres.

Le Cyber Resilience Act commence par l’alarme, non par le marquage de conformité.

Cette chronologie peut surprendre. L’essentiel des exigences applicables aux produits numériques — sécurité dès la conception, traitement des vulnérabilités, documentation et conformité — doit s’appliquer à partir du 11 décembre 2027. Pourtant, les obligations de signalement de l’article 14 ont pris effet le 11 septembre 2026. Le calendrier publié par la European Commission sépare clairement ces deux étapes.

Dès maintenant, un fabricant qui prend connaissance d’une vulnérabilité activement exploitée ou d’un incident portant gravement atteinte à la sécurité d’un produit couvert entre dans une séquence minutée. La page de la European Commission consacrée au signalement fixe un premier avertissement sans retard injustifié et au plus tard dans les 24 heures. La notification enrichie est due dans les 72 heures. Pour une vulnérabilité exploitée, le rapport final arrive au plus tard quatorze jours après la disponibilité d’une mesure corrective ; pour un incident grave, il arrive dans le mois suivant la notification de 72 heures.

Le point de départ est la prise de connaissance par le fabricant. Ce n’est ni la date d’un communiqué, ni l’heure à laquelle un juriste ouvre le portail, ni le moment où l’enquête technique devient parfaite. La gouvernance du délai commence donc à l’intérieur de l’entreprise, au passage entre signal faible, preuve fiable et qualification de l’événement.

Un dossier déposé une fois, des responsabilités distribuées

Le Single Reporting Platform d’ENISA évite au fabricant d’adresser séparément le même dossier à plusieurs autorités. Une seule notification suffit pour un événement donné, y compris lorsque le groupe possède plusieurs filiales ou succursales dans l’Union, ou lorsque sa société mère se trouve hors de l’UE.

Cette simplicité de façade ne supprime pas la géographie institutionnelle. Le déclarant doit sélectionner le CSIRT désigné comme coordinateur compétent, en principe celui lié à son établissement principal. Il lui appartient de choisir correctement. Le répertoire publié par ENISA devient ainsi une pièce de l’infrastructure juridique, et pas une simple liste de contacts.

Dans le parcours normal, le CSIRT choisi et ENISA reçoivent la notification. Le coordinateur national la transmet ensuite sans délai aux autres CSIRT concernés dans les États membres où le produit a été mis à disposition. Des informations peuvent aussi parvenir aux autorités de surveillance du marché pour l’exercice de leurs fonctions de contrôle.

Le portail est central. Le jugement reste distribué. Le fabricant décrit l’événement et son produit ; le coordinateur national tient le premier rôle d’évaluation et de diffusion ; ENISA entretient le canal commun et observe le flux européen ; les autorités de marché portent l’éventuelle suite coercitive. « Déclarer une fois » ne veut donc pas dire « confier toute la décision à ENISA ».

Cette distinction évite une erreur fréquente : confondre accusé technique et réception institutionnelle. La réussite d’un envoi ne prouve pas, à elle seule, que chaque CSIRT concerné ou chaque autorité de surveillance a reçu exactement le même contenu au même instant.

L’exception fonctionne avec deux décisions, pas un bouton secret

La diffusion rapide connaît une soupape étroite. Lors d’une notification de 72 heures portant sur une vulnérabilité activement exploitée, le déclarant peut signaler des « Particularly Exceptional Circumstances » lorsque le partage immédiat créerait un risque de cybersécurité prévu par le cadre légal.

La notice opérationnelle d’ENISA distingue nettement la demande et la décision. Le fabricant active l’indicateur et peut justifier son motif. Le CSIRT coordinateur décide si la diffusion doit être retardée. Si l’exception est retenue, ENISA ne reçoit d’abord que des informations limitées, tandis que le coordinateur demeure responsable du partage ultérieur du dossier complet.

Ce mécanisme ne remet donc pas au fabricant un droit unilatéral au secret. Il ne s’étend pas non plus indistinctement à tous les incidents. La trace probante devrait conserver quatre moments : invocation par le déclarant, décision du coordinateur, portée des informations initialement limitées et levée du retard. Sans cette séquence, une retenue prudente et un défaut de transmission peuvent produire la même apparence extérieure.

Une première version volontairement incomplète

La FAQ d’ENISA mise à jour le 10 septembre décrit sans détour les limites du lancement.

Le portail accepte les notifications obligatoires des fabricants concernant les vulnérabilités activement exploitées et les incidents graves. La fonction de signalement volontaire prévue par l’article 15 viendra plus tard. Les personnes et organisations qui ne sont pas fabricants doivent pour l’instant contacter le CSIRT national pertinent. Les obligations propres aux intendants de logiciels libres ne commenceront que le 11 décembre 2027.

L’interface est en anglais seulement. Aucune API n’est fournie au lancement. Les entreprises peuvent automatiser leur triage et leurs dossiers en interne, mais le dépôt final passe par l’interface. Pour une équipe qui gère de nombreux produits, cette limite transforme l’organisation des représentants en contrôle opérationnel essentiel.

Ces représentants utilisent un compte EU Login personnel avec authentification multifacteur. L’association entre le représentant et le fabricant est validée par le coordinateur. Cette validation s’effectue en parallèle et ne bloque pas l’urgence initiale : jusqu’à vingt notifications peuvent être déposées pour le fabricant avant que la vérification ne devienne indispensable. Le guide d’inscription donne ici une leçon simple : attendre l’incident pour régler l’identité, les rôles et le pays compétent revient à dépenser une partie du délai de 24 heures en administration.

Le compteur de l’écran n’est pas la règle de droit

ENISA documente aussi une imperfection utile à connaître. Dans la version actuelle, le compteur de la notification de 72 heures affiche une échéance située 48 heures après le dépôt de l’avertissement de 24 heures. Or la loi compte 72 heures depuis la prise de connaissance. Selon le moment du premier dépôt, l’interface peut donc présenter le dossier comme en retard avant l’écoulement réel des 72 heures. ENISA annonce une correction fondée sur l’heure de prise de connaissance enregistrée.

L’écart ne modifie pas l’obligation. Il montre pourquoi un écran ne doit jamais absorber silencieusement la norme qu’il met en œuvre. Le fabricant doit garder séparément l’heure de connaissance, l’heure du premier avertissement, l’échéance juridique calculée, l’échéance affichée par le portail et les preuves de dépôt.

Une indisponibilité éventuelle ne fusionne pas davantage ces couches. La FAQ demande d’attendre le retour du service puis de soumettre le dossier. Si une communication immédiate est nécessaire, le fabricant peut joindre directement son CSIRT, mais il devra encore déposer dans la plateforme. Un contact téléphonique n’est pas une substitution permanente, et une tentative réseau isolée n’est pas une preuve d’indisponibilité générale.

Rendre visible la version de la règle exécutée

Le contenu d’une vulnérabilité active doit rester protégé. Le fonctionnement général du canal, lui, peut être vérifiable.

ENISA gagnerait à publier un journal de service et de versions respectueux de la confidentialité : incidents de disponibilité, catégories de déclarants admises, types de notification pris en charge, langues d’interface, état de l’API, logique des compteurs et heure d’effet de chaque modification. Ce journal ne nommerait ni produit vulnérable ni fabricant. Il permettrait simplement de relier une action à la version du mécanisme qui l’a reçue.

Il s’agit de ma recommandation éditoriale, et non d’une exigence actuelle du CRA ou d’un engagement d’ENISA. Elle applique la chaîne d’autorité décrite dans The Policy Mirror, le test d’exécution de Running Code Primary et la séparation entre faits et plaidoyer de Why BTW Media Exists.

Le signalement européen n’est plus un projet. Son premier jour expose déjà l’essentiel : un guichet partagé, plusieurs détenteurs d’autorité et un délai que seule la preuve de connaissance peut ancrer.

Sources