Cyber Resilience Act : ce que les éditeurs doivent faire depuis l’entrée en application du signalement

Ce qui s’applique depuis le 11 septembre 2026

Le Cyber Resilience Act (règlement sur la cyberrésilience, règlement (UE) 2024/2847) est en vigueur depuis décembre 2024. Depuis le 11 septembre 2026, s’applique le premier volet qui touche directement les fabricants : les obligations de signalement de l’article 14. Les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves qui touchent leurs produits.

Point essentiel : l’obligation de signalement vaut aussi pour les produits mis sur le marché avant cette date. Les autres obligations, comme la sécurité dès la conception, les mises à jour de sécurité pendant toute la période de support, l’évaluation de la conformité et le marquage CE, suivront le 11 décembre 2027.

Qui est concerné ?

Le CRA s’applique aux produits comportant des éléments numériques proposés dans l’UE : logiciels et matériels capables de se connecter à un appareil ou à un réseau. Cela inclut les applications de bureau et mobiles, les logiciels métier installables, les firmwares et les objets connectés.

• Les fabricants portent l’essentiel des obligations, même s’ils sont établis hors de l’UE.
• Les importateurs et distributeurs doivent vérifier que le fabricant respecte ses obligations.
• Les services purement SaaS ne relèvent pas du CRA. L’application de NIS2 dépend de votre secteur et de la taille de votre entreprise. Le CRA s’applique en revanche lorsque le cloud fait partie du fonctionnement d’un produit, par exemple le back-end d’une application ou d’un appareil.
• L’open source sans activité commerciale est exclu. Les organisations qui soutiennent durablement des projets open source relèvent d’un régime allégé.

En cas de doute, un avis juridique rapide est utile. Si vous commercialisez des logiciels installables, des applications ou des objets connectés, vous êtes presque certainement concerné.

Le signalement : 24 heures, 72 heures, 14 jours

Dès que vous avez connaissance d’une vulnérabilité activement exploitée, le compte à rebours démarre :

1. Alerte précoce sous 24 heures : l’existence de la vulnérabilité et les États membres dans lesquels votre produit est disponible.
2. Notification sous 72 heures : détails sur le produit, la nature de l’exploitation et les mesures prises ou recommandées.
3. Rapport final au plus tard 14 jours après la mise à disposition d’un correctif ou d’une mesure d’atténuation : gravité, impact, cause et correction.

Pour les incidents graves, les délais de 24 et 72 heures s’appliquent également ; le rapport final est dû un mois après la notification. Le signalement passe par la plateforme unique de signalement de l’ENISA et parvient simultanément à l’ENISA et au CSIRT coordinateur de l’État membre de votre établissement principal : en France le CERT-FR de l’ANSSI. Le cas échéant, vous devez aussi informer les utilisateurs concernés.

Pourquoi c’est une question de code

24 heures, c’est court. Pour tenir ce délai, vous devez pouvoir répondre rapidement à trois questions :

• Quels composants, dans quelle version, contient votre produit ? Sans nomenclature à jour (SBOM), vous ne saurez pas, lors de la prochaine faille de type Log4j, si vous êtes concerné.
• Où se situe le problème dans le code ? Qui connaît son code peut évaluer la gravité et l’impact au lieu de deviner.
• À quelle vitesse pouvez-vous livrer ? Un correctif n’est utile qu’une fois arrivé chez les utilisateurs.

Il s’agit souvent non pas d’un zero-day exotique, mais d’une faille connue dans une dépendance qui aurait dû être mise à jour depuis longtemps. De plus en plus de ces dépendances arrivent dans les projets via les assistants IA : voir Vibe coding : le code généré par IA est-il sûr ?

Check-list pour les 30 prochains jours

1. Clarifier votre situation : quels produits relèvent du CRA, et dans quel rôle intervenez-vous ?
2. Désigner les responsables : qui signale, qui remplace, qui est joignable le week-end ?
3. Automatiser la SBOM : générer une nomenclature au format CycloneDX ou SPDX à chaque version.
4. Scanner les dépendances en continu : face aux bases CVE et OSV, avec alerte en cas de nouvelle correspondance.
5. Ouvrir un canal de signalement : un fichier security.txt et une politique de divulgation coordonnée.
6. S’entraîner : préparer un modèle d’alerte précoce à 24 heures et le tester une fois.
7. Faire l’état des lieux : où en êtes-vous aujourd’hui ? Un audit de code révèle les failles connues, les paquets obsolètes et les secrets avant qu’elles ne soient exploitées et donc à signaler.

Les sanctions encourues

Pour les manquements aux exigences essentielles et aux obligations des articles 13 et 14, le CRA prévoit des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. S’y ajoutent des retraits du marché. Les micro et petites entreprises sont exemptées d’amende en cas d’alerte précoce tardive à 24 heures, mais elles doivent tout de même signaler.

Cet article propose un éclairage ; il ne remplace pas un conseil juridique.

Comment un audit de code vous aide

Notre audit de code confronte vos dépendances aux vulnérabilités connues, recherche les secrets dans le code et l’historique, et évalue le code selon l’OWASP Top 10:2025. Chaque constat est assorti d’une note CVSS et d’un plan d’action. Le rapport documente votre état des lieux auprès de vos clients et des autorités. Forfait 890 € HT, livraison en 2 jours ouvrés.

Le rapport ne remplace ni l’évaluation de la conformité ni le marquage CE. Il vous montre en revanche par où commencer. Notre façon de procéder est décrite dans notre méthodologie.

Cet article a été rédigé avec l’aide de recherches automatisées et de l’IA. David Kreutzer l’a relu et validé le 1 novembre 2026.