Faille exploitée : 24 heures pour prévenir l'Europe, et ce que ça change
Ou : Comment l’Europe a posé un chronomètre à côté de ton gestionnaire de tickets
Depuis le 11 septembre 2026, un éditeur de logiciel qui apprend qu’une faille de son produit est exploitée par un attaquant dispose de 24 heures pour le signaler. Pas seulement à ses clients : à l’Europe, par une plateforme unique tenue par l’ENISA, l’agence européenne de cybersécurité. C’est l’article 14 du Cyber Resilience Act, le règlement (UE) 2024/2847, et c’est la seule partie du texte qui s’applique déjà. Le reste, les exigences de sécurité dès la conception, la nomenclature des composants, le marquage CE des logiciels, attendra le 11 décembre 2027. Le règlement a donc commencé par la fin : avant de t’expliquer comment construire un produit sûr, il t’explique quoi faire le jour où il ne l’est pas.
Je ne suis pas juriste, et cet article n’est pas un avis juridique. C’est la lecture d’un développeur qui a ouvert le texte pour savoir si son code était concerné. Les réponses sont plus nuancées que les résumés qui circulent, et les questions restées ouvertes le sont vraiment.
Cyber Resilience Act : qui doit signaler une faille exploitée, et en combien de temps
Trois délais, une seule porte
Le texte prévoit trois envois successifs pour une vulnérabilité activement exploitée, et le même schéma, avec un délai final différent, pour un incident grave touchant la sécurité du produit1.
| Étape | Délai | Ce qu’on y met |
|---|---|---|
| Alerte précoce | 24 heures après la prise de connaissance | Les États membres où le produit est disponible |
| Notification | 72 heures après la prise de connaissance | La nature de l’exploitation, les mesures prises, ce que les utilisateurs peuvent faire |
| Rapport final, vulnérabilité | 14 jours après la mise à disposition d’un correctif | Gravité, acteur malveillant s’il est connu, détail du correctif |
| Rapport final, incident grave | Un mois après la notification | Cause probable, mesures d’atténuation |
Tout passe par la plateforme unique de signalement de l’ENISA, ouverte le 11 septembre 2026 dans une première version que l’agence promet d’enrichir dans les mois qui viennent2. Un seul dépôt suffit : la notification part d’abord vers le CSIRT, l’équipe nationale de réponse aux incidents, de l’État où se trouve ton établissement principal, puis vers les autres CSIRT concernés et vers l’ENISA. En Belgique, c’est le CCB, par l’intermédiaire de CERT.be ; en France, l’ANSSI et son CERT-FR3. Si ces délais te rappellent quelque chose, c’est normal : la directive NIS2 impose le même rythme de 24 et 72 heures aux entités qu’elle couvre.
Il y a une quatrième obligation, plus discrète et plus coûteuse : informer les utilisateurs touchés de la faille et des mesures qu’ils peuvent prendre, au besoin dans un format structuré et lisible par machine. Si tu ne le fais pas à temps, le CSIRT peut s’en charger à ta place. C’est une façon élégante de dire que le silence n’est plus une option.
« Activement exploitée » : le mot qui déclenche le chronomètre
Toutes les failles ne lancent pas le décompte. Le règlement vise la vulnérabilité « pour laquelle il existe des preuves fiables qu’elle a été exploitée par un acteur malveillant dans un système sans l’autorisation du propriétaire du système ». Un bogue trouvé par ton équipe ne compte pas. Une faille signalée par un chercheur, non plus, tant que personne ne l’exploite. Le chronomètre démarre quand tu as la preuve qu’un attaquant s’en est servi.
Deux questions restent ouvertes, et je les laisse ouvertes. À partir de quand une équipe « prend-elle connaissance » d’une exploitation : quand un client l’écrit au support un vendredi soir, ou quand l’analyse le confirme le lundi ? Et une faille exploitée dans une bibliothèque que tu embarques est-elle « contenue dans ton produit » ? Le texte ne distingue pas ton code de celui de tes dépendances. C’est exactement le genre de question à poser à un juriste avant d’en avoir besoin, pas pendant.
Ton code est-il un « produit comportant des éléments numériques » ?
C’est la question qui intéresse un développeur web, et la réponse surprend. Le règlement définit le produit comme un logiciel ou un matériel « et ses solutions de traitement de données à distance », c’est-à-dire le traitement en ligne conçu par le fabricant et sans lequel le produit ne remplirait pas une de ses fonctions. L’application qui pilote un objet connecté depuis le nuage est donc dedans. Mais le considérant 12 précise que les sites web qui ne soutiennent pas la fonction d’un produit, et les services en nuage qui ne sont pas développés sous la responsabilité de son fabricant, en sont exclus. Le logiciel fourni comme service, le SaaS, relève de la directive NIS2, pas du CRA4.
En pratique, une application web pure, hébergée par toi et utilisée dans un navigateur, sort du champ du CRA, et relève de NIS2 si l’entreprise atteint la taille d’une entreprise moyenne. Les obligations NIS2 des PME sont détaillées ailleurs sur ce site. En revanche, tout ce que tu distribues pour qu’un client l’installe y entre : une application mobile, un client de bureau, un outil en ligne de commande, un agent à déployer sur des serveurs, une bibliothèque vendue comme composant. Et le texte précise qu’un fabricant commercialise son produit « à titre onéreux, monétisé ou gratuit » : l’application gratuite financée par un abonnement ailleurs ne s’en sort pas parce qu’elle ne coûte rien.
DevOps Dave : On est une boîte SaaS. Le CRA, ce n’est pas pour nous.
Security Sarah : Et votre application mobile ?
DevOps Dave : Elle affiche juste le tableau de bord.
Security Sarah : Et l’agent que vos clients installent sur leurs serveurs pour remonter les métriques ?
DevOps Dave : C’est un petit binaire Go de douze mégaoctets.
Security Sarah : C’est un produit comportant des éléments numériques. Le règlement ne mesure pas la taille du binaire.
Le logiciel libre bénéficie d’un régime à part. Le code publié sous licence libre et non monétisé par son auteur n’est pas considéré comme une activité commerciale, et reste hors champ. Les « intendants de logiciels ouverts », ces fondations et organisations qui soutiennent durablement des projets libres utilisés commercialement, auront une obligation de signalement allégée à partir du 11 décembre 2027 seulement, et l’article 64 leur épargne les amendes administratives qu’il prévoit5.
Dernière précision, et elle compte : la règle générale épargne les produits mis sur le marché avant décembre 2027, sauf modification substantielle. L’article 69 fait une exception pour le signalement. Ton application sortie en 2023 et toujours vendue est concernée depuis le 11 septembre6.
Ce que ça change lundi matin
Le règlement ne te demande pas de n’avoir aucune faille. Il te demande de savoir que tu en as une, et de le dire vite. Pour beaucoup d’équipes, la première moitié sera la plus difficile.
Savoir commence par un endroit où l’on peut te le dire. Un fichier security.txt, décrit par la RFC 9116, indique aux chercheurs et aux clients où signaler une faille7. Sans lui, l’alerte arrive au support commercial, qui la range entre deux demandes de facture.
Savoir suppose ensuite un inventaire. Quand une bibliothèque très répandue fait l’objet d’une exploitation massive, la première question est « l’embarquons-nous, et dans quelle version ? ». Une équipe qui met deux jours à répondre a déjà dépassé le premier délai. La nomenclature des composants, le SBOM, ne deviendra une exigence qu’en décembre 2027, sans obligation de la publier8. Mais elle est déjà l’outil qui permet de tenir 24 heures. Pour un projet Go, go version -m appliqué au binaire livré liste chaque module embarqué avec sa version et son empreinte, une première nomenclature en une commande ; les dépendances détournées ne préviennent pas toujours, comme l’a montré la chaîne d’approvisionnement empoisonnée d’OpenClaw.
Reste la procédure. Qui a un compte sur la plateforme de l’ENISA ? Qui décide qu’une exploitation est « avérée » ? Qui rédige l’alerte si l’incident tombe un samedi ? Vingt-quatre heures ne sont pas un jour ouvrable. Le non-respect des obligations de l’article 14 peut coûter jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial, le montant le plus élevé étant retenu9. Écrire une page de procédure, avec des noms dedans, coûte une heure.
Le Cyber Resilience Act sera surtout discuté en 2027, quand le marquage CE arrivera sur les logiciels. Mais sa première exigence est déjà là, et elle est d’une simplicité désarmante : quand quelqu’un exploite ta faille, ne fais pas semblant de ne pas l’avoir vu. Le chronomètre tourne depuis le 11 septembre. Il ne s’arrête pas le week-end.
L’article 14 du règlement (UE) 2024/2847 détaille les trois envois : une alerte précoce « sans retard injustifié et, en tout état de cause, au plus tard 24 heures après en avoir eu connaissance », une notification au plus tard 72 heures après, et un rapport final « au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation » pour une vulnérabilité, ou dans le mois qui suit la notification pour un incident grave. L’article 71 fixe l’application de l’article 14 au 11 septembre 2026, et celle du reste du règlement au 11 décembre 2027. ↩︎
L’ENISA a annoncé le lancement de la plateforme unique de signalement le 11 septembre 2026, en précisant qu’il s’agit d’une « initial operating capability » appelée à évoluer. Sa fiche d’information en français résume les délais et explique comment le CSIRT destinataire est déterminé, selon l’article 14, paragraphe 7. ↩︎
La page du CCB consacrée au CRA indique que les fabricants établis en Belgique notifient au CCB. Côté français, l’ANSSI a rappelé le 23 septembre 2026 que les fabricants doivent signaler depuis le 11 septembre les vulnérabilités activement exploitées et les incidents graves. Pour un fabricant établi hors de l’Union, l’article 14, paragraphe 7, prévoit une cascade : l’État de son mandataire, puis de son importateur, puis de son distributeur. ↩︎
Le considérant 12 est explicite : « La directive (UE) 2022/2555 s’applique aux services d’informatique en nuage et aux modèles de services en nuage, tels que les logiciels service (SaaS), les plates-formes services (PaaS) et les infrastructures services (IaaS). » Les définitions du produit, du traitement de données à distance et du fabricant figurent à l’article 3, points 1, 2 et 13. ↩︎
Le considérant 18 précise que la fourniture de logiciels libres et ouverts « qui ne sont pas monétisés par leur fabricant ne devrait pas être considérée comme une activité commerciale ». L’article 24, paragraphe 3, étend aux intendants une partie de l’article 14, applicable comme le reste du règlement le 11 décembre 2027, et l’article 64, paragraphe 10, point b), écarte les amendes administratives « à toute violation du présent règlement par les intendants de logiciels ouverts », avec la même ambiguïté de renvoi que celle décrite dans la dernière note. ↩︎
L’article 69, paragraphe 2, limite les exigences aux produits mis sur le marché avant le 11 décembre 2027 qui subissent ensuite une modification substantielle. Le paragraphe 3 déroge à cette règle pour l’article 14, qui s’applique à tous les produits relevant du règlement. ↩︎
La RFC 9116, publiée en avril 2022, standardise ce fichier placé dans
/.well-known/security.txt. Il tient en quelques lignes : un moyen de contact, une date d’expiration, et si possible un lien vers la politique de divulgation. ↩︎L’annexe I, partie II, du règlement en fait une exigence de gestion des vulnérabilités, applicable en décembre 2027. Le considérant 77 ajoute que « les fabricants ne devraient pas être tenus de rendre publique la nomenclature des logiciels ». ↩︎
L’article 64, paragraphe 2, fixe ce plafond pour le non-respect de l’annexe I et des articles 13 et 14. Le paragraphe 10 prévoit qu’aucune amende ne s’applique aux micro et petites entreprises qui manquent le délai de 24 heures de l’alerte précoce, mais il déroge aux « paragraphes 3 à 9 », alors que l’article 14 relève du paragraphe 2. Comment les autorités liront cette dérogation est une question ouverte que je ne trancherai pas. ↩︎