Ce qui change le 11 septembre 2026 pour les éditeurs de logiciels

Ceci n’est pas un conseil juridique. Chaque affirmation renvoie à l’article du règlement (UE) 2024/2847 dont elle vient, pour que vous puissiez vérifier. Les corrections sont bienvenues.

La version courte

À partir du 11 septembre 2026, quiconque vend un logiciel, un firmware ou un objet connecté dans l’UE doit notifier les vulnérabilités activement exploitées dans son produit et les incidents graves qui le touchent. Cela vaut pour une entreprise d’une personne, et pour une entreprise établie hors UE. Les délais courent à partir du moment où vous en avez connaissance : une alerte précoce sous 24 heures, une notification sous 72 heures, les deux via la plateforme unique de l’ENISA (articles 14 et 16).

Tout le reste du Cyber Resilience Act s’applique à partir du 11 décembre 2027 (article 71) : exigences de sécurité dès la conception, SBOM, documentation technique, déclaration UE de conformité, marquage CE, cinq ans de support de sécurité. Les amendes existent (article 64 : jusqu'à 15 M€ ou 2,5 % du chiffre d’affaires mondial, le montant le plus élevé étant retenu ; pour une entreprise d’une personne, les 15 M€ sont théoriques). Elles s’appliquent aussi à partir de décembre 2027.

Septembre n’est donc pas la date à laquelle il faut être conforme. C’est la date à partir de laquelle votre procédure de notification doit exister. Le compte à rebours démarre quand vous en avez connaissance, pas quand une autorité vous écrit.

Êtes-vous « fabricant » ?

Le règlement s’applique aux « produits comportant des éléments numériques » : produits logiciels ou matériels, et leurs solutions de traitement de données à distance, dont l’utilisation prévue ou raisonnablement prévisible comprend une connexion de données, directe ou indirecte, à un appareil ou à un réseau (article 3, point 1). Le « fabricant » est celui qui développe ou fabrique un tel produit, ou le fait développer, et le commercialise sous son nom ou sa marque, à titre onéreux, gratuit ou en le monétisant (article 3, point 13). La condition : le produit est mis à disposition sur le marché de l’UE dans le cadre d’une activité commerciale (article 3, point 22).

En pratique :

Exceptions sectorielles : dispositifs médicaux (MDR/IVDR), véhicules soumis à réception par type, aviation civile, équipements marins et produits développés uniquement pour la défense ou la sécurité nationale ont leur propre régime (article 2). Un test gratuit pose ces questions et renvoie une évaluation écrite et indicative, avec les articles : crakit.eu/fr/champ-d-application.

Ce qui doit exister le 11 septembre

L’article 14 demande au fabricant de notifier toute vulnérabilité activement exploitée contenue dans le produit (paragraphe 1) et tout incident grave ayant un impact sur la sécurité du produit (paragraphe 3). Pas toutes les CVE. Pas les bugs.

« Activement exploitée » : il existe des éléments fiables indiquant qu’un acteur malveillant a exploité la vulnérabilité dans un système sans l’autorisation de son propriétaire (article 3, point 42).

« Incident grave » : un incident qui affecte, ou est susceptible d’affecter, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes. Cela couvre aussi un incident qui a conduit, ou est susceptible de conduire, à l’introduction ou à l’exécution de code malveillant dans le produit ou dans les réseaux et systèmes d’information d’un utilisateur (article 14, paragraphe 5).

Le calendrier, à compter du moment où vous en avez connaissance :

• 24 h : alerte précoce. Le fait que la vulnérabilité est exploitée (ou qu’un incident a eu lieu) et les États membres où le produit est disponible. Très peu de détails sont exigés à ce stade.
• 72 h : notification. Informations générales, nature de l’exploitation, mesures correctives ou d’atténuation prises et celles que les utilisateurs peuvent prendre. Pour un incident : nature, gravité, impact, indicateurs de compromission.
• Rapport final : pour une vulnérabilité, 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation. Pour un incident, 1 mois après la notification.

Destinataires : le CSIRT désigné comme coordinateur dans votre État membre (en France, l’ANSSI / CERT-FR, désignation à confirmer sur la carte des CSIRT de l’ENISA ; pour un fabricant hors UE, celui déterminé par son mandataire) et l’ENISA, via la plateforme unique de notification (article 16). Vous devez aussi informer les utilisateurs du produit sans retard injustifié, et leur indiquer les mesures d’atténuation si besoin (article 14, paragraphe 8).

Le dispositif minimal d’un petit éditeur au 11 septembre est donc court :

1. Un contact sécurité joignable. Une adresse security@ lue chaque jour ouvré, un fichier /.well-known/security.txt (RFC 9116) et une politique publique de divulgation coordonnée des vulnérabilités qui dit comment signaler et ce qui se passe ensuite. L’annexe I, partie II, points 5 et 6 rendent de toute façon la politique et l’adresse de contact obligatoires en 2027. Le security.txt est la façon pratique de publier l’adresse.
2. Savoir ce qu’il y a dans votre produit. Une nomenclature logicielle (SBOM) de vos dépendances. Pas parce que la SBOM est due (c’est 2027), mais parce que « activement exploitée » arrive presque toujours sous la forme d’une bibliothèque que vous embarquez qui entre dans un catalogue de failles exploitées. Si vous ignorez que vous la livrez, vous ne pouvez pas en « avoir connaissance » à temps.
3. Une procédure d’une page. Qui décide « c’est activement exploité » ou « c’est un incident grave », qui détient le compte sur la plateforme ENISA, ce qui va dans le message des 24 h, ce qui va dans celui des 72 h, et comment les utilisateurs sont informés.
4. Les modèles prêts, pour que personne ne parte d’une page blanche à deux heures du matin.

Ce qui attend le 11 décembre 2027

• Les exigences essentielles de l’annexe I, partie I : sécurité dès la conception, configuration sécurisée par défaut, absence de vulnérabilité exploitable connue à la mise sur le marché, mises à jour de sécurité, contrôle d’accès, chiffrement, intégrité, minimisation des données, résilience, réduction de la surface d’attaque, journalisation, effacement sûr.
• Les exigences de traitement des vulnérabilités de l’annexe I, partie II : SBOM (au moins les dépendances de premier niveau), correction sans retard, tests réguliers, publication des vulnérabilités corrigées, politique de divulgation coordonnée, adresse de contact, distribution sécurisée des mises à jour, correctifs de sécurité gratuits.
• La documentation technique (annexe VII), l'évaluation de la conformité, la déclaration UE de conformité (annexe V), le marquage CE et les informations aux utilisateurs de l’annexe II. Sur l'évaluation : auto-évaluation pour la plupart des produits. Pour les produits « importants » de classe I de l’annexe III, l’auto-évaluation n’est possible que si les normes harmonisées ou spécifications communes sont appliquées intégralement (article 32, paragraphe 2) ; sinon, organisme notifié. Évaluation par un tiers pour la classe II et pour les produits « critiques » de l’annexe IV.
• Une période d’assistance d’au moins cinq ans, sauf durée d’utilisation prévue plus courte (article 13, paragraphe 8). Chaque mise à jour de sécurité reste disponible au moins dix ans après sa publication, ou jusqu'à la fin de la période d’assistance, la plus longue des deux durées étant retenue (article 13, paragraphe 9).
• Les amendes : jusqu'à 15 M€ ou 2,5 % pour l’annexe I et les articles 13/14 ; 10 M€ ou 2 % pour les autres obligations ; 5 M€ ou 1 % pour des informations inexactes (article 64). Les micro et petites entreprises ne peuvent pas être sanctionnées pour le seul dépassement du délai de 24 h de l’alerte précoce, et les gestionnaires de logiciels libres ne peuvent pas être sanctionnés du tout (article 64, paragraphe 10).

Quinze mois suffisent pour faire cela sans stress, dans l’ordre : écrire ce que vous faites déjà, mettre la SBOM dans l’intégration continue, faire l’analyse de risques au regard de l’annexe I, puis rédiger la déclaration.

Ce qui existe gratuitement

• L'ENISA publie des guides et la documentation de la plateforme de notification. L'ANSSI relaie le calendrier. L'OpenSSF et le groupe de travail ORC de la fondation Eclipse publient des guides et spécifications pensés pour le logiciel libre. Tout est gratuit.
• J’ai construit deux outils gratuits pour le cas du petit éditeur. Un test de périmètre (8 questions, évaluation indicative avec les articles). Et une analyse SBOM + vulnérabilités dans le navigateur, qui lit votre fichier de verrouillage, produit une SBOM CycloneDX, interroge OSV.dev et signale les entrées du catalogue CISA des vulnérabilités activement exploitées, l’indicateur public le plus proche du déclencheur de l’article 14. Rien n’est envoyé, à part les identifiants de paquets transmis à OSV. Même chose en ligne de commande et en action GitHub : npx crakit (MIT). crakit.eu/fr/scan
• Le même site vend un kit de 13 documents à 79 € (politique de divulgation, security.txt, procédures de traitement et de notification avec modèles, déclaration de support, projets d’annexes I/II/V/VII), générés à partir de vos réponses, en français ou en anglais. On peut le prévisualiser avant de payer, et les outils gratuits ne l’exigent pas. Je le mentionne parce que c’est lui qui finance la partie gratuite.

Trois réserves honnêtes

1. Le catalogue KEV de la CISA est une liste américaine, pas une définition juridique européenne. C’est un signal fort qu’une faille est activement exploitée, pas la réponse complète. Les avis des éditeurs et vos propres journaux comptent aussi.
2. « Activement exploitée » est une appréciation du fabricant. Écrivez comment vous la faites. Sur-notifier est prévu par le règlement (l’article 15 organise la notification volontaire). Sous-notifier est ce que le régime de sanctions visera à partir de décembre 2027.
3. Les orientations de la Commission bougent encore (actes délégués sur les catégories, descriptions techniques des annexes III/IV, normes en cours). Les numéros d’articles sont stables ; les interprétations peuvent bouger. Revérifiez avant décembre 2027.

Règlement (UE) 2024/2847 du 23 octobre 2024, JO L du 20.11.2024. Les articles cités renvoient à ce texte.