Après le CSIRT et l'ENISA, prévenez vos utilisateurs
L'article 14, paragraphe 8 demande d'informer les utilisateurs concernés après une faille exploitée. Ce qu'il exige, ce qu'il laisse ouvert.
Aujourd’hui, The Hacker News rapporte une faille de Cisco Secure Email Gateway exploitée dans la nature, avec exécution de commandes en root : https://thehackernews.com/2026/09/cisco-secure-email-gateway-flaw.html
Le même jour, Neowin et Security Affairs relaient un avertissement de l’ENISA sur l’IA de frontière et le raccourcissement des fenêtres d’exploitation.
Mettez-vous à la place d’un petit éditeur. Une faille de votre produit est activement exploitée. Vous envoyez l’alerte précoce sous 24 heures, puis vous préparez la notification des 72 heures.
Il reste un troisième destinataire : vos utilisateurs. Beaucoup de fondateurs l’oublient, parce qu’il arrive à la fin de l’article.
Le paragraphe 8
L’article 14, paragraphe 8 s’applique depuis le 11 septembre 2026, comme le reste de l’article.
Après avoir eu connaissance d’une vulnérabilité activement exploitée ou d’un incident grave, le fabricant informe sans retard injustifié les utilisateurs concernés. Si besoin, tous les utilisateurs.
Il les informe de la vulnérabilité ou de l’incident. Et, si nécessaire, des mesures d’atténuation et correctives qu’ils peuvent appliquer de leur côté.
Le texte ajoute une préférence : si possible, dans un format structuré, lisible par machine.
Deux horloges différentes
Les 24 heures et les 72 heures visent le CSIRT désigné comme coordinateur dans votre État membre, et l’ENISA.
Le message aux utilisateurs suit une autre règle. « Sans retard injustifié ». Pas de compteur en heures.
Ce qui ne veut pas dire « plus tard ». Vous devrez expliquer votre délai si on vous le demande, et un délai s’explique mieux quand la décision a été écrite quelque part avant l’incident.
Les deux horloges partent du même point : le moment où vous en avez connaissance. Pas le moment où une autorité vous écrit.
Un exemple
Un développeur seul vend un plugin de sauvegarde pour un CMS. 600 sites l’utilisent. Le revenu vient d’une licence annuelle.
Un jeudi matin, un client lui envoie des logs. Un attaquant a utilisé une faille du plugin pour lire des fichiers hors du répertoire prévu. Les éléments sont assez fiables pour parler d’exploitation active au sens de l’article 3, point 42.
Il a trois choses à faire, et elles ne se suivent pas dans le même tempo.
L’alerte précoce au CSIRT et à l’ENISA, dans la journée. La notification complète sous 72 heures. Et le message aux 600 clients, sans retard injustifié.
Le troisième point est celui qui coûte le plus de temps le jour J, parce que rien n’est prêt. Quelle adresse ? Quel ton ? Faut-il donner le détail technique avant le correctif ?
Le règlement ne fixe pas de modèle de message. La rédaction reste la vôtre.
Ce qui peut être prêt à l’avance : la liste des clients joignables, le canal choisi, et un texte à trous avec les champs à remplir. Produit, version affectée, ce qu’on sait, ce qu’on ne sait pas, mesure d’atténuation, date de la prochaine mise à jour du message.
Là où ça rejoint votre politique de divulgation
L’annexe I, partie II, points 5 et 6 demande une politique de divulgation coordonnée des vulnérabilités et une adresse de contact. Cette partie s’applique le 11 décembre 2027, avec le reste des exigences essentielles.
Mais la même page sert dans les deux cas. Elle dit où on vous signale une faille, et elle dit comment vous prévenez les utilisateurs quand une faille est exploitée.
Un chercheur qui trouve votre adresse de contact vous prévient. Vous gagnez des heures sur le délai de 24 heures. C’est la partie la moins chère du dossier et elle sert dès maintenant.
Ce qui court, ce qui attend
Depuis le 11 septembre 2026 : l’article 14, dans ses deux cas. Une vulnérabilité de votre produit activement exploitée (paragraphe 1). Un incident grave ayant un impact sur la sécurité du produit (paragraphe 3). Et l’information des utilisateurs du paragraphe 8.
Le rapport final vient plus tard. 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation pour une vulnérabilité. Un mois après la notification pour un incident.
Le reste arrive le 11 décembre 2027 : SBOM, documentation technique, marquage CE, informations aux utilisateurs de l’annexe II. Les amendes de l’article 64 s’appliquent à partir de cette date, pas avant.
Reste la question qui vient avant tout ça. Est-ce que vous êtes fabricant au sens de l’article 3, point 13 ? Le test de périmètre déroule les définitions dans leur ordre, avec les références d’articles, en huit questions : https://crakit.eu/fr/champ-d-application/
C’est une évaluation écrite et indicative. Pas un verdict.
Ce n’est pas un conseil juridique.
Ce n’est pas un conseil juridique.