CRA : ce que change le 11 septembre 2026 pour un fabricant de 20 personnes
C'est la première échéance du Cyber Resilience Act à mordre vraiment, et c'est aussi la moins coûteuse à traiter — à condition de s'y prendre avant. Elle ne demande ni marquage CE, ni documentation technique, ni organisme notifié. Elle demande de savoir qui, chez vous, décrochera dans les vingt-quatre heures.
Ce qui change exactement
À compter du 11 septembre 2026, le fabricant d'un produit comportant des éléments numériques doit signaler deux catégories de faits : toute vulnérabilité de son produit qui est activement exploitée, et tout incident grave ayant une incidence sur la sécurité du produit. Le signalement va au CSIRT désigné comme coordinateur et à l'ENISA (art. 14).
C'est une obligation de processus, pas de produit. Elle ne juge pas la qualité de votre firmware : elle juge votre capacité à réagir dans un délai qui se compte en heures. Une entreprise de vingt personnes peut parfaitement la satisfaire — souvent mieux qu'un groupe où l'information met trois jours à remonter trois étages. À une condition : avoir décidé à l'avance qui fait quoi.
C'est tout l'intérêt de cette échéance. Contrairement à celle de décembre 2027, elle ne se règle pas avec du budget. Elle se règle avec une décision d'organisation et une demi-journée de réunion.
Ce qui ne change pas le 11 septembre
C'est la confusion la plus répandue, et elle coûte cher dans les deux sens : soit on se met en ordre de bataille pour des obligations qui n'arrivent que dans quinze mois, soit on se croit tranquille jusqu'en 2027 et on rate la seule qui s'applique déjà.
| Obligation | Applicable à partir de |
|---|---|
| Signalement des vulnérabilités activement exploitées et des incidents graves | 11 septembre 2026 |
| Exigences essentielles de conception (annexe I) | 11 décembre 2027 |
| Documentation technique (annexe VII) | 11 décembre 2027 |
| Évaluation de la conformité, intervention éventuelle d'un organisme notifié | 11 décembre 2027 |
| Déclaration UE de conformité et marquage CE | 11 décembre 2027 |
Autrement dit : le 11 septembre 2026, personne ne viendra vous demander votre dossier technique. Mais si une vulnérabilité de votre produit est exploitée et que vous ne l'avez pas signalée, c'est un manquement — quel que soit l'état d'avancement du reste.
Ce qui déclenche le signalement
Deux faits distincts, régulièrement confondus. La distinction compte, parce que le délai du rapport final n'est pas le même.
Une vulnérabilité activement exploitée
Une faille de votre produit dont quelqu'un se sert réellement — pas une faille théorique. Le déclencheur n'est pas la publication d'une CVE, c'est le constat d'une exploitation. Vous pouvez l'apprendre par un client, par un chercheur en sécurité, par votre propre supervision ou par une publication.
Un incident grave affectant la sécurité du produit
Un événement qui compromet effectivement la sécurité du produit ou des données qu'il traite. Là encore, le fait déclencheur est la connaissance de l'événement, pas sa résolution ni sa compréhension complète.
Dans les deux cas, le compte à rebours part du moment où vous en avez connaissance. Pas du moment où vous avez compris ce qui se passe, ni de celui où vous disposez d'un correctif. C'est le point que les équipes techniques intègrent le plus difficilement : on alerte avant de savoir.
Le compte à rebours
| Étape | Délai | Ce qu'on y met |
|---|---|---|
| Alerte précoce | 24 heures | Le strict minimum : qui vous êtes, quel produit, ce que vous savez. L'information peut être partielle, c'est prévu. |
| Notification | 72 heures | Les éléments techniques disponibles et, le cas échéant, les mesures correctives ou d'atténuation déjà prises. |
| Rapport final — vulnérabilité | 14 jours | Après la mise à disposition d'un correctif ou d'une mesure d'atténuation. |
| Rapport final — incident | 1 mois | Après la notification à 72 heures. |
Vingt-quatre heures, ce n'est pas vingt-quatre heures ouvrées. Un signalement qui tombe un vendredi soir de pont doit partir avant le dimanche soir. C'est exactement pour ce cas de figure que la checklist ci-dessous insiste sur les suppléants.
La checklist de notification
Huit points. Aucun ne demande de budget, tous demandent une décision. Comptez une demi-journée en réunion pour les traiter, et une matinée pour l'exercice à blanc.
1. Nommer celui qui décide
Une personne, nommément, qui tranche « on signale / on ne signale pas ». Dans une PME c'est souvent le dirigeant ou le directeur technique. Ajoutez un suppléant : la question ne se posera pas au moment où vous êtes disponible.
2. Nommer celui qui rédige et qui envoie
Ce n'est pas forcément la même personne que celle qui décide, et c'est même préférable : celui qui décide est souvent celui qui gère la crise côté client au même moment.
3. Identifier le CSIRT compétent et le canal d'envoi
Faites-le maintenant, pas le jour J. La désignation du CSIRT coordinateur relève de chaque État membre : identifiez celui dont vous relevez, repérez le canal de signalement, et si un compte est nécessaire, créez-le à froid.
4. Écrire la procédure sur une page
Une page, pas un classeur. Qui décide, qui rédige, où on envoie, quels délais, où sont les modèles. Si elle tient sur une page, elle sera lue le jour où il faut.
5. Lister les produits et versions concernés
Vous ne pouvez pas signaler ce que vous n'avez pas inventorié. Quels produits sont sur le marché européen, dans quelles versions, chez combien de clients. Les produits anciens encore en service comptent aussi.
6. Décider où vous regardez
Une vulnérabilité exploitée vous arrive rarement par courrier recommandé. Elle arrive par le support, par un client, par un chercheur qui ne sait pas à qui écrire. Ouvrez une adresse de contact sécurité visible et regardez-la.
7. Préparer le modèle de première alerte
Un document pré-rempli avec vos identifiants d'entreprise, votre contact, la structure des champs. Le jour J, il ne doit rester que les faits à saisir.
8. Faire un exercice à blanc
Une matinée. Quelqu'un annonce un scénario, l'équipe déroule jusqu'à l'alerte rédigée — sans l'envoyer. Vous découvrirez en deux heures les trois choses qui bloqueront le jour J.
Qui fait quoi dans une entreprise de vingt personnes
Vous n'avez ni RSSI, ni centre opérationnel de sécurité, ni juriste interne. Ce n'est pas un handicap pour cette obligation : trois rôles suffisent. Une même personne peut en tenir deux, mais chacun doit avoir un nom et un suppléant.
Le décideur
Tranche en moins d'une heure : est-ce un fait à signaler ? En cas de doute réel, on signale — les deux étapes suivantes servent précisément à corriger le tir.
Le rédacteur
Remplit le modèle, envoie, archive l'accusé. Profil technique de préférence, parce qu'il devra décrire la faille sans en dire trop.
Le relais client
Répond aux clients qui appellent en parallèle. Sans lui, le rédacteur passe sa journée au téléphone et rate le délai.
Le point faible d'une équipe de vingt personnes n'est pas la compétence, c'est la disponibilité. Un seul nom par rôle et vous êtes exposé aux congés, aux arrêts et aux déplacements. Deux noms par rôle, et l'obligation devient tenable.
Ce que doit contenir la première alerte
L'alerte à vingt-quatre heures n'est pas un rapport d'expertise. Elle est courte, factuelle, et peut être incomplète : c'est exactement pour cela que le règlement prévoit deux étapes ensuite.
- Qui vous êtes : raison sociale, rôle (fabricant), contact joignable.
- Quel produit, quelles versions, quel périmètre de déploiement estimé.
- La nature du fait : vulnérabilité activement exploitée ou incident grave.
- Ce que vous savez à cet instant, et — tout aussi important — ce que vous ne savez pas encore.
- Comment vous l'avez appris et depuis quand.
- Les mesures déjà prises ou décidées, même provisoires.
Écrire « à ce stade nous ne savons pas si d'autres versions sont affectées » est une réponse acceptable dans une alerte précoce. Ne rien envoyer parce qu'on ne sait pas encore ne l'est pas.
Cinq erreurs qui coûtent cher
Attendre de comprendre avant d'alerter
Le délai de vingt-quatre heures ne laisse pas le temps d'une analyse complète, et le règlement ne le demande pas. L'alerte précoce est faite pour être partielle.
Confondre vulnérabilité et incident
Les deux se signalent, mais le rapport final n'a pas le même délai — quatorze jours d'un côté, un mois de l'autre. Qualifier le fait dès la première heure évite de se tromper de calendrier.
N'avoir qu'un seul nom par rôle
Les incidents ne consultent pas le planning des congés. Un rôle sans suppléant est un rôle vacant une semaine sur six.
Oublier les produits anciens
Un équipement livré il y a six ans et toujours en service chez un client reste votre produit. C'est souvent lui qui porte les composants les plus datés.
Croire que le sous-traitant s'en charge
L'obligation pèse sur celui qui met le produit sur le marché sous son nom. Vous pouvez sous-traiter le développement, pas le signalement.
Et après le 11 septembre
L'échéance suivante est le 11 décembre 2027, et elle n'a rien à voir en volume de travail : exigences essentielles, documentation technique, évaluation de la conformité, marquage CE. Le bon usage des quinze mois qui séparent les deux dates est de commencer par l'inventaire des composants — sans lui, rien de ce qui suit n'est vérifiable.
Questions fréquentes
Mon produit est sur le marché depuis des années. Suis-je concerné ?
Le règlement échelonne son application (art. 71) et comporte des dispositions transitoires ; l'articulation exacte pour un produit déjà commercialisé est un point à faire trancher par un conseil. En pratique, la question est peu opérante : mettre en place la chaîne de signalement coûte une demi-journée, et un produit ancien encore en service est précisément celui qui a le plus de chances de porter une vulnérabilité exploitée.
Quel est le CSIRT compétent pour une entreprise française ?
La désignation du CSIRT coordinateur relève de chaque État membre. C'est justement pour cela que le point 3 de la checklist consiste à l'identifier maintenant plutôt que le jour où le délai court.
Et si je signale un fait qui s'avère finalement bénin ?
Le règlement construit le signalement en trois temps précisément parce que l'information initiale est incomplète et peut évoluer. Une alerte rectifiée ensuite reste une alerte ; une alerte jamais envoyée est un manquement.
La vulnérabilité vient d'un composant open source. Est-ce à moi de signaler ?
L'obligation pèse sur le fabricant du produit mis sur le marché, quelle que soit l'origine du composant fautif. Un composant tiers intégré à votre produit relève de votre responsabilité au titre du règlement.
Dois-je prévenir mes clients en même temps ?
Le signalement au CSIRT et à l'ENISA est distinct de l'information de vos utilisateurs. Les deux existent, avec des logiques et des calendriers différents. Ne faites pas dépendre le premier du second : le délai de vingt-quatre heures ne s'interrompt pas pendant que vous rédigez un communiqué client.
Combien coûte la mise en conformité à cette échéance ?
Quasiment rien en euros : une demi-journée de réunion pour les huit points de la checklist, une matinée d'exercice à blanc, et une adresse de contact sécurité. C'est la seule échéance du CRA dont on peut dire cela — raison de plus pour ne pas la manquer.
Source : règlement (UE) 2024/2847, articles 14 et 71. Les délais cités sont ceux de l'article 14.