Le Cyber Resilience Act ne s’applique pleinement qu’au 11 décembre 2027. La plupart des équipes l’ont classé en conséquence, quelque part dans la colonne 2027 d’une feuille de route. Ce classement a désormais quinze mois de retard : l’article 14, l’obligation de notification, s’applique depuis le 11 septembre 2026.
C’est une obligation étroite, et rapide. Si vous fabriquez un produit comportant des éléments numériques mis sur le marché de l’Union, et que vous avez connaissance de l’exploitation active d’une vulnérabilité de ce produit, vous disposez de 24 heures pour transmettre une alerte précoce. Pas un correctif, pas une analyse : une notification, via la plateforme unique de signalement, au CSIRT désigné comme coordinateur et à l’ENISA.
Qui est concerné, y compris ceux qui ne se voient pas en fabricants
Le mot « fabricant » évoque le matériel, et cette lecture est la première erreur. Un produit comportant des éléments numériques, c’est tout produit logiciel ou matériel, et ses solutions de traitement de données à distance, mis sur le marché comme une offre commerciale distincte. Une plateforme SaaS vendue comme produit, une application mobile, une image de firmware, une bibliothèque distribuée commercialement, un contrôleur embarqué : tous dans le champ.
Deux cas supplémentaires surprennent régulièrement.
Vous y apposez votre nom. Un distributeur ou un importateur qui commercialise un produit sous son propre nom ou sa propre marque devient le fabricant au sens du règlement, obligation de notification comprise.
Vous l’avez modifié substantiellement. Prenez un composant open source ou un produit tiers, modifiez-le d’une manière qui affecte ses propriétés de sécurité, puis mettez le résultat sur le marché : les obligations suivent la modification.
L’open source développé et fourni en dehors d’une activité commerciale reste hors champ. La frontière est l’activité commerciale, pas la licence, et elle est plus fine qu’on ne le croit : un mainteneur qui vend du support ou des correctifs prioritaires est du mauvais côté.
Les trois rapports, et le chronomètre de chacun
L’obligation n’est pas un dépôt unique. C’est une séquence, et chaque étape a son délai, qui court à partir du moment où vous avez connaissance des faits.
Sous 24 heures, l’alerte précoce. Quelle est la vulnérabilité, le fait qu’elle soit exploitée, et quels États membres vous pensez concernés si vous le savez. Cette alerte est volontairement mince. Elle existe pour que les coordinateurs puissent commencer, pas pour que vous soyez exhaustif.
Sous 72 heures, la notification de vulnérabilité. Les informations générales sur le produit, la nature de l’exploitation, et les mesures correctives ou d’atténuation prises ou disponibles.
Sous 14 jours après la disponibilité d’une mesure corrective, le rapport final. Description de la vulnérabilité, gravité et impact, et correctif.
La même forme s’applique aux incidents graves affectant la sécurité du produit, avec la même alerte à 24 heures et un rapport final à un mois.
Deux points pratiques. Le chronomètre part de la connaissance, et la connaissance est un fait organisationnel, non une décision : un ingénieur support qui voit une exploitation dans les journaux d’un client un vendredi soir l’a déclenché. Et le rapport à 24 heures n’est pas conditionné à votre compréhension de la vulnérabilité : vous signalez ce que vous savez, puis vous signalez de nouveau.
Ce qui échoue réellement
Nous avons joué ce scénario avec des équipes produit quatre fois cette année, en exercice sur table avec le chronomètre affiché. Personne n’a manqué le délai faute de savoir rédiger le rapport. Les délais ont été manqués, ou frôlés, pour les mêmes quatre raisons.
Personne ne possède le déclencheur. L’exploitation est remarquée par le support, par un client, par un chercheur, par la veille, ou par un avis éditeur — cinq points d’entrée, et à chaque fois la personne qui a vu ne savait pas qu’un délai réglementaire de 24 heures venait de commencer. C’est le point le plus rentable à corriger, et c’est une après-midi de travail : une règle écrite décrivant à quoi ressemble une « exploitation active » chez vous, et un circuit unique de n’importe lequel des cinq points d’entrée vers la personne qui peut déposer.
L’inventaire produit n’est pas un inventaire réglementaire. Les entreprises savent ce qu’elles vendent. Elles n’ont pas la liste qui répond à : lesquels sont des produits comportant des éléments numériques, mis sur quels marchés, sous quel nom, avec quelle période de support déclarée. C’est cette liste qui dit si une exploitation donnée est notifiable, et elle ne se construit pas sous un délai de 24 heures.
Le compte sur la plateforme n’existe pas. Le signalement passe par la plateforme unique. Un compte, les bonnes personnes dessus, et un dépôt de test ne se règlent pas à la troisième heure d’un incident.
Le réflexe juridique est d’attendre. L’instinct de confirmer avant de notifier est juste dans presque tous les autres contextes, et faux ici. Vingt-quatre heures n’accueillent pas un cycle de relecture. L’alerte précoce est conçue pour être révisée ; le délai, non.
Si vous n’avez pas commencé
Quatre jours de travail, étalés sur quinze jours, comblent l’écart :
- Une note de cadrage qui nomme vos produits comportant des éléments numériques, leurs marchés, et qui en est le fabricant. Une page par produit, pas un projet.
- Une définition écrite du déclencheur, et un circuit interne unique de n’importe quel point d’entrée vers le déposant. Placez-la là où le support la voit, pas seulement dans le wiki de l’équipe sécurité.
- Le compte sur la plateforme, provisionné, avec deux personnes nommées et un essai à blanc.
- Un exercice sur table, chronomètre compris. Une heure, une fois. C’est là que le circuit manquant devient évident.
Rien de tout cela n’est le travail de décembre 2027 : l’évaluation de la conformité, la documentation technique, les exigences de sécurité dès la conception, la période de support déclarée et le processus de traitement des vulnérabilités. C’est un vrai programme, et il doit être planifié maintenant. Mais ce n’est pas ce qui est dû aujourd’hui. Ce qui est dû aujourd’hui, c’est un appel qui atteint la bonne personne dans la journée, et un formulaire auquel quelqu’un s’est déjà connecté une fois.
La question à poser à votre équipe cette semaine
Pas « sommes-nous conformes au CRA » — personne ne l’est, et la question n’a pas de réponse avant un an. Demandez plutôt : si un client écrit ce soir à notre adresse de support pour dire qu’il est attaqué à travers notre produit, qui dépose l’alerte précoce, et pour quand ?
Si la réponse prend plus d’une phrase, c’est l’écart, et c’est le moins cher à combler de tout le règlement.