Cyber Resilience Act : signaler une faille en 24 h, qui est concerné depuis le 11 septembre

Depuis le 11 septembre 2026, le Cyber Resilience Act a commencé à produire ses effets. Ce règlement européen impose aux fabricants de « produits comportant des éléments numériques » (logiciels, applications, objets connectés) de signaler toute vulnérabilité activement exploitée et tout incident grave dans un délai très court : une première alerte sous 24 heures.

Le reste du texte, avec le marquage CE des logiciels, ne s’appliquera qu’au 11 décembre 2027. Mais l’obligation de signalement, elle, est déjà là, y compris pour les produits vendus avant cette date. Si vous éditez un logiciel, une application mobile ou un appareil connecté, voici ce que vous devez savoir.

Cet article s’adresse surtout aux entreprises qui vendent ou diffusent un produit numérique sous leur nom. Si vous avez un simple site vitrine ou une boutique en ligne, vous n’êtes en principe pas concerné : retenez seulement que vos fournisseurs de logiciels, eux, le sont, et qu’ils devront vous prévenir en cas de faille.

Qui est concerné par le Cyber Resilience Act ?

Le règlement (UE) 2024/2847 vise le fabricant : celui qui conçoit ou fait concevoir un produit numérique et le met sur le marché européen sous son nom, dans le cadre d’une activité commerciale, qu’il soit payant ou non. Sont notamment concernés :

• les éditeurs de logiciels installés chez le client (logiciel de gestion, application de bureau, extension vendue) ;
• les éditeurs d’applications mobiles diffusées sur les magasins d’applications ;
• les fabricants d’objets connectés et du logiciel intégré à ces appareils (le « firmware ») ;
• les entreprises qui ont fait développer un produit par un prestataire et le commercialisent sous leur marque : ce sont elles, le fabricant. Par exemple, une menuiserie qui fournit à ses clients une application mobile pour piloter ses volets connectés, ou un chauffagiste qui vend un thermostat connecté à son nom ;
• les importateurs et distributeurs qui modifient un produit de façon substantielle ou y apposent leur marque.

À l’inverse, un logiciel utilisé uniquement en ligne, par abonnement et sans installation (ce qu’on appelle un SaaS), est en principe considéré comme un service et sort du champ, sauf s’il constitue le traitement à distance indispensable au fonctionnement d’un produit : le serveur d’une application mobile ou d’un objet connecté, par exemple. Les logiciels libres développés sans activité commerciale, et les produits couverts par leur propre réglementation (dispositifs médicaux, automobile, aviation), sont également exclus.

Le cas des logiciels développés sur mesure pour un seul client professionnel est plus nuancé : le règlement permet de prévoir par contrat certaines dérogations (configuration par défaut, mises à jour gratuites), sans les sortir entièrement du dispositif. Si vous êtes dans ce cas, faites valider votre situation par un juriste.

Les délais de signalement : 24 heures, 72 heures, 14 jours

Le compte à rebours démarre quand vous prenez connaissance d’une vulnérabilité activement exploitée (une faille que des attaquants utilisent réellement) ou d’un incident grave touchant la sécurité de votre produit. Il faut des éléments fiables montrant qu’un attaquant a effectivement utilisé la faille : une faille théorique signalée par un chercheur ne déclenche pas, à elle seule, le délai de 24 heures. Selon les lignes directrices publiées par la Commission européenne le 27 juillet 2026, ce moment correspond à une première analyse donnant une certitude raisonnable, pas à la simple réception d’une rumeur.

1. Sous 24 heures : l’alerte précoce. Quelques informations suffisent : le produit concerné, la nature du problème, s’il semble malveillant et les pays où le produit est diffusé.
2. Sous 72 heures : la notification. Elle détaille le produit, la nature de l’exploitation, les mesures correctives déjà prises et celles que les utilisateurs peuvent appliquer.
3. Le rapport final. Pour une vulnérabilité, au plus tard 14 jours après la mise à disposition d’un correctif. Pour un incident grave, au plus tard un mois après la notification. Il décrit la gravité, l’impact, la cause et le correctif.

En parallèle, vous devez informer les utilisateurs touchés, et si nécessaire tous vos utilisateurs, de la faille et des mesures à prendre. Pas de signalement rétroactif en revanche : si vous saviez déjà avant le 11 septembre 2026 qu’une faille était exploitée, vous n’avez pas à la déclarer. Mais si vous découvrez après cette date qu’une faille, même ancienne, est exploitée, le délai de 24 heures s’applique.

Où et comment signaler

Les signalements passent par une plateforme unique gérée par l’ENISA, l’agence européenne de cybersécurité, ouverte comme prévu le 11 septembre dans une première version qui n’accepte pour l’instant que les déclarations obligatoires. Vous y désignez un centre coordinateur (l’équipe publique qui traite les incidents de sécurité), en général celui du pays de votre établissement principal (l’ENISA en publie la liste) : pour une entreprise française, il s’agit du CERT-FR, rattaché à l’ANSSI, l’agence nationale de cybersécurité. Ce dernier transmet aux autres pays concernés. Une seule déclaration suffit donc, même si votre produit est vendu dans toute l’Europe.

Conseil pratique : préparez-vous à froid. L’ENISA demande de n’enregistrer votre entreprise sur la plateforme qu’au moment de votre première déclaration, pour ne pas surcharger les équipes publiques. Mais rien ne vous empêche de lire dès maintenant son manuel d’utilisation, de créer les comptes EU Login (l’identifiant unique des services de l’Union européenne, avec double authentification) des personnes qui déclareront, et de noter les informations qui seront demandées. Découvrir l’outil un vendredi soir, au milieu d’une attaque, fait perdre des heures précieuses.

Ce qui arrivera le 11 décembre 2027

À cette date, toutes les exigences du Cyber Resilience Act s’appliqueront aux produits mis sur le marché : sécurité dès la conception, absence de faille connue exploitable à la livraison, configuration sécurisée par défaut, mises à jour de sécurité pendant toute la durée de support annoncée (en principe au moins cinq ans), liste des composants logiciels utilisés, documentation technique et marquage CE (le logo qui atteste qu’un produit respecte les règles européennes). Les manquements à ces exigences ou aux obligations de signalement pourront coûter jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial.

Un an, c’est court pour revoir ses pratiques de développement, d’autant que d’autres textes européens arrivent à la même période, comme les obligations de l’AI Act reportées à fin 2027. Mieux vaut profiter de l’obligation de signalement pour poser les bases dès maintenant.

Six réflexes à mettre en place dès maintenant

1. Listez vos produits numériques vendus ou diffusés dans l’Union, y compris les anciennes versions encore utilisées par vos clients.
2. Nommez un responsable et un suppléant, joignables rapidement, et écrivez une procédure d’une page : qui décide, qui signale, qui prévient les clients.
3. Inventoriez les composants de chaque produit, c’est-à-dire les briques de code venues de l’extérieur que vos développeurs ont réutilisées : beaucoup de failles exploitées viennent de l’une d’elles.
4. Abonnez-vous aux alertes de sécurité de ces composants, pour être prévenu avant vos clients.
5. Publiez un point de contact pour que les chercheurs puissent vous signaler une faille, par exemple une adresse e-mail dédiée et un fichier « security.txt » sur votre site (un petit fichier standard qui indique à qui écrire).
6. Relisez vos contrats avec vos prestataires de développement et d’hébergement : délais d’intervention, accès aux journaux techniques (l’historique de ce qui s’est passé sur le serveur), maintien des correctifs.

Une bonne partie de ces réflexes relève d’une organisation de développement bien tenue : versions identifiées, composants à jour, tests automatisés, capacité à livrer un correctif en quelques jours. Ce sont les bases à exiger de tout prestataire qui développe une application sur mesure.

Ce que nous pouvons faire pour vous

Nous développons et maintenons des applications sur mesure depuis plus de dix ans. Nous pouvons vous aider à cartographier les composants de vos produits, mettre en place la surveillance des failles et organiser une chaîne de correction rapide. Découvrez nos services ou parlons de votre situation.

Sources : règlement (UE) 2024/2847 sur EUR-Lex ; ENISA, lancement de la plateforme de signalement ; ENISA, questions fréquentes sur la plateforme. Article à jour au 12 novembre 2026.