Une bibliothèque compromise, un correctif à fabriquer, des clients à prévenir : pour un éditeur, la cybersécurité ne s’arrête plus à la livraison. Avec le Cyber Resilience Act (CRA), l’Union européenne transforme cette évidence technique en responsabilité réglementaire. Première échéance opérationnelle majeure : le 11 septembre 2026, date prévue pour l’application des obligations de signalement de certaines vulnérabilités et de certains incidents graves. La conformité générale viendra en décembre 2027. Mais les procédures, elles, ne s’improvisent pas le jour où une attaque commence.
Du produit vendu au produit suivi
Le CRA, règlement européen 2024/2847, est entré en vigueur le 10 décembre 2024. Son application générale est fixée au 11 décembre 2027, avec plusieurs échéances anticipées. Il concerne les produits comportant des éléments numériques mis sur le marché européen : logiciels, équipements connectés et composants commercialisés séparément. Un logiciel installé dans une entreprise peut donc être concerné autant qu’une caméra connectée ou un routeur domestique.
La rupture tient au cycle de vie. Le fabricant devra intégrer la sécurité dans la conception, documenter les risques, traiter les vulnérabilités et fournir des mises à jour de sécurité pendant une période de support annoncée. Celle-ci devra normalement atteindre au moins cinq ans, sauf lorsque la durée d’utilisation attendue du produit est plus courte. Pour certains équipements destinés à durer, cinq ans ne constitueront pas nécessairement un plafond suffisant.
Ce n’est donc pas simplement une nouvelle case dans les conditions générales. Le règlement rapproche le logiciel d’un produit dont le fabricant doit assumer la sécurité dans le temps. Les importateurs et distributeurs auront également des obligations. Le marquage CE deviendra, pour les produits concernés, le signe d’une conformité intégrant ces exigences de cybersécurité.
Septembre 2026 : signaler, mais pas tout signaler
L’échéance du 11 septembre 2026 porte notamment sur l’article 14. Deux catégories déclenchent les obligations des fabricants : les vulnérabilités activement exploitées contenues dans leurs produits et les incidents graves ayant une incidence sur la sécurité de ces produits. Il ne s’agit pas de déclarer automatiquement chaque faille théorique découverte lors d’un audit, ni chaque anomalie repérée dans des journaux techniques.
Pour une vulnérabilité activement exploitée, le calendrier prévoit une alerte précoce sans retard injustifié et au plus tard dans les 24 heures suivant la prise de connaissance, puis une notification sous 72 heures. Un rapport final doit suivre au plus tard quatorze jours après la disponibilité d’une mesure corrective ou d’atténuation. Ces étapes permettent de signaler rapidement sans prétendre disposer immédiatement d’une analyse complète.
Pour un incident grave, on retrouve les jalons de 24 et 72 heures. Le rapport final est prévu dans le mois suivant la notification de l’incident, avec des modalités adaptées lorsqu’il est toujours en cours. Le dispositif repose sur une plateforme unique de signalement, vers le CSIRT désigné comme coordinateur et l’ENISA, l’agence européenne pour la cybersécurité.
Ces transmissions aux autorités ne remplacent pas l’information des utilisateurs concernés. Le CRA prévoit aussi de leur communiquer les éléments et mesures utiles pour réduire le risque. Une déclaration réglementaire n’est toutefois pas une publication immédiate de tous les détails exploitables : protéger les informations sensibles et coordonner la divulgation restent essentiels.
Le vrai chantier se trouve dans l’organisation
Imaginons un éditeur de logiciel de gestion. Un vendredi soir, son équipe apprend qu’une dépendance intégrée au produit est exploitée chez plusieurs clients. La difficulté n’est pas seulement de modifier le code. Il faut établir quelles versions sont touchées, qualifier les informations disponibles, identifier les destinataires du signalement et décider des conseils à transmettre aux utilisateurs.
Le délai réglementaire oblige à préparer cette chaîne avant la crise. Une boîte électronique réservée aux alertes ne suffit pas si personne ne la consulte le week-end. À l’inverse, tout faire remonter au directeur général peut bloquer une notification urgente. Une organisation crédible nécessite des responsabilités explicites, des suppléants et une capacité à conserver la trace des décisions.
- Recenser les produits et versions : savoir ce qui reste distribué et quelles versions sont maintenues.
- Organiser la réception des alertes : chercheurs, clients, fournisseurs et équipes internes doivent disposer d’un canal identifiable.
- Préparer les notifications : modèles, critères de qualification, validation et procédure de mise à jour des informations.
- Tester une crise : vérifier qu’une alerte reçue hors des heures ouvrées trouve un responsable capable d’agir.
Les entreprises déjà soumises au RGPD, à NIS 2 ou, dans la finance, à DORA devront aussi articuler leurs circuits. Ces textes ne couvrent pas les mêmes objets ni les mêmes événements. Le CRA ne remplace donc pas leurs obligations : une même crise peut nécessiter plusieurs analyses réglementaires, sans que les notifications soient interchangeables.
Les dépendances logicielles deviennent un enjeu industriel
Log4Shell, fin 2021, a montré combien une bibliothèque largement réutilisée pouvait exposer des organisations incapables de localiser rapidement ses copies. La tentative de compromission de XZ Utils, révélée en 2024, a rappelé qu’un composant discret pouvait devenir une cible stratégique. Ces événements éclairent le problème auquel répond le CRA : la sécurité d’un produit dépend aussi de briques que son éditeur n’a pas écrites.
Le règlement prévoit notamment une nomenclature logicielle, ou SBOM, dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau. Cela ne signifie pas publier universellement son inventaire complet. Surtout, un fichier ne résout rien seul : il faut relier les composants aux versions livrées, suivre les alertes et savoir reconstruire puis distribuer un correctif.
L’open source demande une lecture nuancée. Les logiciels libres et ouverts fournis en dehors d’une activité commerciale bénéficient d’une exclusion. Le texte prévoit aussi un régime spécifique pour certains organismes de soutien à l’open source. Mais intégrer un composant libre dans un produit commercial ne dispense pas le fabricant de ses responsabilités sur ce produit. La charge pourrait ainsi pousser les éditeurs à mieux soutenir leurs dépendances critiques.
La maintenance devient une promesse commerciale
Tous les services numériques ne relèvent pas automatiquement du CRA. Un service SaaS autonome n’entre pas dans son champ simplement parce qu’il utilise du logiciel. En revanche, certaines solutions de traitement à distance indispensables aux fonctions d’un produit peuvent être couvertes. Définir précisément le produit, ses composants et ses fonctions sera donc une première étape juridique et technique.
Pour les éditeurs, l’effet économique probable est clair : il faudra financer le suivi après la vente. Les branches anciennes, personnalisations et versions rarement mises à jour coûtent déjà cher ; le règlement rend cette dette plus visible. On peut anticiper des catalogues rationalisés et des engagements de support mieux affichés. Ce sont des évolutions plausibles, pas encore un résultat général démontré.
Et maintenant ? L’échéance de septembre 2026 doit être abordée comme une répétition opérationnelle avant décembre 2027. Priorité aux circuits d’alerte, à la connaissance des versions distribuées et aux exercices de signalement. Ensuite viendront la consolidation documentaire et la conformité complète. Si le CRA atteint son objectif, la différence entre deux logiciels ne se jouera plus seulement à leurs fonctions : elle se mesurera aussi à la qualité du suivi promis, financé et effectivement assuré.
