Une alerte arrive un vendredi soir : une faille dans un équipement connecté serait utilisée pour pénétrer les réseaux de ses clients. Qui vérifie ? Qui prévient les autorités ? Qui décide de communiquer sans aider les attaquants ? À partir du 11 septembre 2026, ces questions deviennent un enjeu réglementaire immédiat. Le Cyber Resilience Act impose aux fabricants concernés une première notification sous vingt-quatre heures. Le changement ne tient pas seulement au formulaire : il oblige à construire une chaîne de décision capable de fonctionner avant même que l’enquête soit terminée.
Une première échéance avant le grand basculement de 2027
Le Cyber Resilience Act, ou CRA, est le règlement européen destiné à renforcer la cybersécurité des produits comportant des éléments numériques. Adopté en 2024, il vise un ensemble très large : logiciels, objets connectés, équipements réseau ou composants commercialisés séparément. Son ambition est de faire de la sécurité une responsabilité suivie pendant la vie du produit, plutôt qu’une option ajoutée après sa vente.
Il faut cependant distinguer deux dates. Les obligations de notification prévues à l’article 14 s’appliquent dès le 11 septembre 2026, tandis que l’essentiel du règlement s’appliquera le 11 décembre 2027. Cette entrée en vigueur progressive ne permet donc pas d’attendre 2027 pour organiser le traitement des alertes. Les notifications peuvent aussi concerner des produits déjà mis sur le marché avant l’application générale du texte.
Le calendrier et les obligations décrits ici reposent sur le règlement adopté. Les transformations opérationnelles envisagées pour septembre 2026 relèvent, elles, d’une analyse prospective : elles ne présument ni du fonctionnement constaté des outils de signalement à cette date, ni des premières pratiques des autorités.
Deux déclencheurs, et non toutes les failles
Premier déclencheur : une vulnérabilité activement exploitée contenue dans le produit. Le CRA vise une exploitation pour laquelle existent des preuves fiables qu’un acteur malveillant a utilisé la faille sans l’autorisation du propriétaire du système. Une vulnérabilité simplement découverte, même critique, ne relève donc pas automatiquement de cette notification. Elle reste néanmoins un problème à traiter.
Second déclencheur : un incident grave ayant une incidence sur la sécurité du produit. Le texte retient notamment l’atteinte à sa capacité de protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions importantes. Ce volet dépasse la seule découverte d’une erreur de programmation : une compromission de mécanismes essentiels à la sécurité peut également entrer dans le champ.
Cette distinction change le travail de veille. Un score de sévérité élevé ne suffit pas à caractériser une exploitation réelle ; inversement, une faille moins spectaculaire peut devenir urgente si des attaques sont observées. Les fabricants devront rapprocher les remontées des chercheurs, les alertes des clients, les renseignements sur les menaces et les données techniques disponibles, sans confondre soupçon et preuve.
Un chronomètre en plusieurs étapes
Le règlement organise une notification progressive. L’objectif n’est pas d’exiger une expertise complète en une journée, mais de faire circuler rapidement les informations utiles, puis de les enrichir. Les délais commencent lorsque le fabricant prend connaissance de la vulnérabilité activement exploitée ou de l’incident grave.
- Sous vingt-quatre heures : une alerte précoce doit être transmise, sans retard injustifié, avec les premiers éléments disponibles.
- Sous soixante-douze heures : une notification plus détaillée doit suivre, précisant notamment le produit concerné, la nature du problème et les mesures correctives ou d’atténuation disponibles.
- Pour une vulnérabilité exploitée : le rapport final est attendu au plus tard quatorze jours après la disponibilité d’une mesure corrective ou d’atténuation.
- Pour un incident grave : le rapport final intervient normalement dans le mois suivant la notification détaillée. Si l’incident reste en cours, un rapport d’avancement précède le rapport final.
Les signalements sont destinés au CSIRT désigné comme coordinateur et à l’ENISA, l’agence européenne pour la cybersécurité, selon le mécanisme de plateforme unique prévu par le texte. Signaler aux autorités ne signifie pas publier immédiatement tous les détails techniques. Le dispositif prévoit le traitement sécurisé des informations et des possibilités encadrées de différer leur diffusion dans certaines circonstances exceptionnelles.
Le vrai chantier : savoir qui décide
Pour un fabricant, le premier risque est organisationnel. Le support client reçoit un comportement étrange ; l’équipe technique y voit un incident isolé ; le service juridique attend une confirmation ; la direction découvre le dossier le lundi. Avec une échéance de vingt-quatre heures, ce fonctionnement en silos devient difficilement tenable.
La réponse consiste à établir une permanence adaptée aux risques, une procédure d’escalade et une autorité clairement habilitée à notifier. Une équipe de réponse aux incidents de sécurité des produits, souvent appelée PSIRT, peut coordonner le dispositif. Dans une petite structure, quelques responsables identifiés peuvent remplir cette fonction, à condition de disposer de suppléants et d’un accès direct aux décideurs.
Un exercice sur table permet de tester cette organisation : simuler une alerte, identifier les versions touchées, déterminer les clients exposés et préparer une première notification avec des informations incomplètes. Il faut aussi documenter quand l’entreprise a pris connaissance des faits, ce qu’elle savait alors et pourquoi elle a retenu telle qualification. La traçabilité compte autant que la vitesse.
La chaîne logicielle devient une responsabilité concrète
Les crises Log4Shell et la tentative de compromission de XZ Utils ont illustré, bien avant cette échéance, la dépendance des produits à des composants parfois peu visibles. Le CRA accentue une nécessité déjà connue : savoir ce que l’on livre. Un inventaire des dépendances, complété par une nomenclature logicielle exploitable, aide à retrouver rapidement les produits concernés. Il ne remplace cependant ni l’analyse de leur exposition, ni la vérification des possibilités d’exploitation.
Le périmètre exige également de la précision. Le règlement comporte des exclusions sectorielles et ne couvre pas indistinctement tous les services numériques. Certaines fonctions de traitement à distance nécessaires au produit peuvent toutefois être concernées. Quant aux logiciels libres et ouverts développés ou fournis hors d’une activité commerciale, ils bénéficient d’une exclusion spécifique. Cela ne dispense pas un fabricant commercial de ses responsabilités envers le produit qui les intègre.
Informer sans transformer l’alerte en mode d’emploi
La notification réglementaire ne remplace pas l’information des utilisateurs. Le fabricant doit aussi leur communiquer les éléments pertinents et, lorsque nécessaire, les mesures qu’ils peuvent prendre. Désactiver temporairement une fonction, restreindre un accès ou appliquer un correctif : une consigne concrète protège davantage qu’un message rassurant mais vide.
Cette communication devra s’articuler avec d’autres obligations, notamment celles de NIS2 ou du RGPD lorsque leurs conditions respectives sont réunies. Les destinataires, les critères et les délais ne sont pas identiques. Un dossier technique commun peut alimenter plusieurs démarches ; supposer qu’une notification unique règle tout serait une erreur.
Et maintenant ? Septembre 2026 pourrait marquer le passage d’une gestion des failles essentiellement interne à une responsabilité européenne plus structurée. Le résultat dépendra de la qualité des signalements, de leur protection et de leur exploitation par les autorités. Pour les fabricants, la priorité est déjà claire : tester la chaîne d’alerte avant la crise. Le meilleur indicateur de préparation n’est pas l’existence d’une procédure, mais la capacité à l’activer un vendredi soir.
