Cyberrésilience: 24 heures pour signaler, pas pour corriger

À partir du 11 septembre, une équipe qui prend connaissance d’une faille répondant aux critères européens ne disposera pas de 24 heures pour résoudre le problème. Elle aura 24 heures pour envoyer une première alerte. La nuance est décisive: le sablier mesure le début du signalement, pas la livraison d’un correctif.

Cette obligation anticipée vient de l’article 14 du Cyber Resilience Act, ou CRA. Elle vise les fabricants de produits comportant des éléments numériques et, dans un cadre plus limité, certains gestionnaires de logiciels libres. La plupart des exigences générales sur la conception, la documentation et la conformité des produits ne s’appliqueront que le 11 décembre 2027. Confondre ces deux dates ferait croire à tort que tout le régime entre en vigueur dès septembre.

Deux événements précis, pas chaque défaut

Le canal obligatoire ne s’ouvre pas pour n’importe quel bogue. Le premier déclencheur est la «vulnérabilité activement exploitée»: il faut disposer d’éléments fiables montrant qu’un acteur malveillant l’a utilisée sans l’autorisation du propriétaire du système. Une faiblesse découverte pendant un audit, sans indice d’exploitation, n’entre donc pas automatiquement dans cette alerte de 24 heures. Elle peut rester urgente à traiter pour autant.

Le second déclencheur est l’incident grave ayant un effet négatif sur la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions. Le règlement ajoute des critères de gravité. Le simple ralentissement d’un service ou un signal encore inexpliqué ne doit pas être qualifié mécaniquement; l’équipe doit conserver les faits et documenter son analyse.

Le champ des produits est large. La Commission cite notamment les moniteurs pour bébé, montres connectées, systèmes d’exploitation, applications mobiles et processeurs. Cela ne transforme pas l’utilisateur, le chercheur indépendant ou le développeur bénévole en déclarant obligatoire. La responsabilité dépend du rôle économique et de la manière dont le produit est mis sur le marché.

Le compte à rebours commence avec la prise de connaissance

Le premier jalon est une alerte précoce envoyée sans retard injustifié et, au plus tard, dans les 24 heures après la prise de connaissance. Pour une vulnérabilité, cette alerte peut déjà indiquer les États membres où le produit concerné a été mis à disposition. Pour un incident grave, elle donne les premières informations disponibles sur sa nature et son impact. L’heure retenue en interne devient donc une donnée opérationnelle à tracer.

Une notification plus complète suit dans les 72 heures. Elle apporte une première évaluation, la gravité et l’impact attendus ainsi que, lorsqu’elles existent, des mesures correctives ou d’atténuation. Le rapport final n’obéit pas au même rythme: pour une vulnérabilité, il doit arriver au plus tard 14 jours après qu’une mesure corrective ou d’atténuation est disponible; pour un incident grave, au plus tard un mois après la notification de 72 heures.

Il n’existe donc pas de garantie européenne d’un correctif en un jour. Une équipe peut devoir alerter avec des informations encore partielles, poursuivre l’enquête, réduire le risque puis expliquer la cause et la correction. Attendre un diagnostic parfait avant d’escalader ferait perdre le temps précisément réservé à l’alerte initiale.

Un guichet unique, mais pas un tableau public

Les notifications passeront par la Single Reporting Platform de l’ENISA. Le guichet transmettra le dossier au CSIRT coordinateur compétent, généralement lié à l’établissement principal du fabricant dans l’Union, ainsi qu’à l’ENISA. L’objectif est d’éviter des dépôts séparés dans plusieurs systèmes nationaux pour le même événement.

Cette plateforme n’est pas conçue comme une carte publique des produits vulnérables. L’accès aux notifications doit rester strictement limité et protégé. Les autorités peuvent décider qu’une information du public est nécessaire, mais le dépôt initial ne devient pas automatiquement une alerte visible par tous. Signaler une vulnérabilité ne prouve pas non plus que chaque exemplaire du produit a été compromis.

Ce qu’une équipe peut préparer maintenant

La préparation utile commence par les personnes, pas par un formulaire. Il faut nommer un représentant principal et un remplaçant, relier le support, l’ingénierie, la sécurité et le juridique, puis tester qui peut décider de l’escalade en dehors des heures ouvrées. Un dossier interne minimal peut réunir le produit et sa version, la chronologie, les indices d’exploitation, l’impact observé et les mesures temporaires.

L’ENISA demande un compte EU Login au représentant autorisé, mais sa consigne actuelle n’est pas de créer préventivement une organisation vide. L’inscription doit se faire lorsqu’une notification précise est à déposer. La validation de l’organisation n’empêche pas l’envoi initial et les informations pourront être complétées. L’agence indique aussi qu’aucune API n’est prévue à ce stade; il faut donc éviter de bâtir un processus qui dépendrait d’un dépôt automatisé.

Le logiciel libre mérite une distinction supplémentaire. Un contributeur non rémunéré n’entre pas dans ce régime du seul fait qu’il publie du code. Le CRA crée la notion de gestionnaire de logiciels libres pour certaines personnes morales qui soutiennent durablement un projet destiné à des activités commerciales. Leur régime est adapté et n’utilise pas les mêmes sanctions administratives que celui des fabricants. Un fabricant qui intègre un composant libre dans son propre produit conserve, lui, ses responsabilités.

Ce qui attend encore 2027

Le 11 septembre ne déclenche ni un nouveau label de sécurité en rayon, ni toutes les évaluations de conformité. Les exigences essentielles, l’analyse des risques, la documentation technique, l’évaluation de conformité, le marquage CE et la gestion des vulnérabilités pendant la période de support relèvent principalement de l’échéance du 11 décembre 2027. Le signalement commence plus tôt afin que le canal soit déjà rodé.

Pour le propriétaire d’un objet connecté, il n’y aura donc pas nécessairement de changement visible le jour du lancement. Le bon réflexe reste de vérifier les mises à jour et la durée de support annoncée, sans interpréter le silence comme une preuve d’absence de faille. Pour les équipes produit, la question pratique est plus immédiate: qui horodate la prise de connaissance, qui qualifie l’événement et qui peut envoyer l’alerte si elle tombe à deux heures du matin?

Les pages de la Commission et de l’ENISA restent appelées à évoluer à l’approche du lancement. Une procédure interne peut donc citer les sources officielles plutôt que recopier une adresse ou un écran qui changerait. Le point stable est l’ordre des opérations: qualifier rapidement, signaler dans le délai, enrichir le dossier, puis documenter la correction.