À compter du 11 septembre 2026, le Cyber Resilience Act européen entre dans une phase concrète pour les entreprises qui conçoivent, commercialisent ou distribuent des produits numériques dans l’Union européenne. Avant même l’application complète du règlement, prévue en décembre 2027, les vulnérabilités activement exploitées et les incidents de sécurité graves devront être signalés selon un calendrier resserré, sous le contrôle de l’Agence de l’Union européenne pour la cybersécurité, l’ENISA.
Le Cyber Resilience Act devient progressivement une contrainte opérationnelle
Un règlement adopté pour sécuriser les produits connectés
Le Cyber Resilience Act, ou règlement européen sur la cyberrésilience, a été publié au Journal officiel de l’Union européenne le 20 novembre 2024 sous la référence règlement (UE) 2024/2847. Il est entré en vigueur le 10 décembre 2024. Son ambition est d’imposer des exigences communes de cybersécurité aux produits comportant des éléments numériques vendus sur le marché européen.
Le texte répond à un constat récurrent des autorités européennes : de nombreux logiciels, objets connectés, équipements réseau et services associés arrivent sur le marché avec des vulnérabilités connues, des mécanismes de mise à jour insuffisants ou une documentation de sécurité lacunaire. Dans un environnement où les attaques par rançongiciel, l’exploitation de failles zero-day et les compromissions de chaînes logicielles se multiplient, l’Union européenne cherche à déplacer l’effort de sécurité en amont, dès la conception du produit.
« Les fabricants doivent veiller à ce que les produits comportant des éléments numériques soient livrés sans vulnérabilités exploitables connues », prévoit le règlement européen.
Une application en deux temps
Le calendrier retenu est progressif. La plupart des obligations de conformité, incluant l’évaluation de conformité, le marquage CE et les exigences de cybersécurité sur l’ensemble du cycle de vie, s’appliqueront à partir du 11 décembre 2027. Mais les règles relatives à la déclaration des incidents et vulnérabilités arrivent quinze mois plus tôt.
| Date / Indicateur | Événement / Valeur |
|---|---|
| 10 décembre 2024 | Entrée en vigueur du règlement (UE) 2024/2847 sur la cyberrésilience. |
| 11 septembre 2026 | Début des obligations de signalement des vulnérabilités activement exploitées et incidents graves. |
| 11 décembre 2027 | Application générale des obligations du Cyber Resilience Act pour les produits concernés. |
| 24 heures | Délai prévu pour l’alerte précoce après la connaissance d’une vulnérabilité exploitée ou d’un incident grave. |
| 72 heures | Délai prévu pour transmettre une notification détaillée initiale. |
Une logique proche des obligations de notification existantes
Ce mécanisme rappelle la directive NIS2, qui renforce les obligations de notification d’incidents pour de nombreuses organisations essentielles ou importantes. Le Cyber Resilience Act se distingue toutefois par son objet : il ne cible pas d’abord l’entreprise victime d’une attaque, mais les opérateurs économiques responsables de produits numériques mis sur le marché européen.
Pour les éditeurs de logiciels, les fabricants d’objets connectés et certaines agences numériques, le sujet ne relève donc plus uniquement de la conformité juridique. Il devient une question d’organisation interne : capacité à détecter, qualifier, documenter et remonter une faille dans des délais très courts.
Quels professionnels sont concernés par le Cyber Resilience Act ?
Les fabricants et éditeurs placés au premier rang
Les fabricants sont les premiers visés. Cette catégorie couvre les entreprises qui développent un produit comportant des éléments numériques et le commercialisent sous leur propre nom ou leur marque. Dans l’économie numérique, la définition dépasse largement les fabricants de matériel : un éditeur de logiciel SaaS, une entreprise qui commercialise un plugin WordPress, un fournisseur d’application mobile ou un concepteur de solution d’intelligence artificielle peut être concerné selon les caractéristiques du produit et son mode de mise à disposition.
Les obligations pèsent également sur les opérateurs qui modifient substantiellement un produit existant ou le mettent sur le marché sous leur marque. Dans ces situations, l’entreprise peut être assimilée à un fabricant et supporter les mêmes responsabilités.
Importateurs, distributeurs et prestataires : une vigilance accrue
Le règlement ne s’arrête pas aux concepteurs. Les importateurs qui introduisent sur le marché européen des produits conçus hors de l’Union doivent vérifier que les exigences applicables sont respectées. Les distributeurs doivent, de leur côté, agir avec diligence lorsqu’ils savent ou ont des raisons de croire qu’un produit ne satisfait pas aux règles de cybersécurité.
Les agences web, intégrateurs et prestataires techniques ne seront pas automatiquement concernés dans toutes leurs activités. Leur exposition dépendra notamment de leur rôle réel dans la commercialisation, le reconditionnement ou la modification d’un logiciel, d’un thème, d’une extension ou d’un équipement connecté. Une agence qui livre un développement propriétaire sous sa propre marque ne se situe pas dans la même position qu’un prestataire réalisant une simple configuration pour le compte d’un client.
Des exemptions, mais un périmètre large
Certains produits restent en dehors du champ d’application ou relèvent prioritairement de réglementations sectorielles spécifiques, notamment dans la santé, l’aviation, l’automobile ou certains dispositifs déjà couverts par des règles européennes exigeantes. Les logiciels libres peuvent aussi bénéficier d’aménagements lorsqu’ils sont développés ou fournis hors activité commerciale.
La frontière reste importante pour les éditeurs de solutions numériques : dès lors qu’un produit open source est monétisé, intégré dans une offre commerciale ou fourni dans le cadre d’un service professionnel, les exemptions ne peuvent être présumées. Le texte européen invite les entreprises à cartographier précisément leurs produits, leurs composants tiers et leur rôle dans la chaîne de distribution.
- Éditeurs de logiciels et fournisseurs de solutions SaaS ;
- Fabricants de matériels connectés, équipements réseau et objets connectés ;
- Créateurs d’applications, d’extensions, de thèmes et de plugins commercialisés ;
- Importateurs de produits numériques en provenance de pays tiers ;
- Distributeurs et revendeurs intervenant sur le marché européen ;
- Prestataires qui modifient ou commercialisent un produit sous leur propre marque.
Le 11 septembre 2026 ouvre l’ère du signalement accéléré
Une alerte précoce dans les vingt-quatre heures
À partir du 11 septembre 2026, le fabricant devra transmettre une alerte précoce à l’ENISA lorsqu’il a connaissance d’une vulnérabilité activement exploitée contenue dans son produit ou d’un incident grave ayant une incidence sur la sécurité de ce produit. Le délai de référence est de vingt-quatre heures après la prise de connaissance.
L’expression « activement exploitée » est déterminante. Il ne s’agit pas de déclarer chaque anomalie technique découverte lors d’un test interne, mais les vulnérabilités pour lesquelles existe un élément attestant d’une exploitation malveillante. Cette qualification impose une surveillance des remontées clients, des bases de vulnérabilités, des chercheurs en sécurité, des dépendances logicielles et des alertes émises par les CERT.
Une notification plus complète sous soixante-douze heures
Dans un second temps, une notification doit être remise dans les soixante-douze heures. Elle doit contenir les informations disponibles sur la nature de la vulnérabilité ou de l’incident, le produit affecté, les premières mesures correctrices engagées et, lorsque cela est pertinent, les indications permettant de limiter le risque pour les utilisateurs.
Le règlement prévoit ensuite des rapports complémentaires. Pour une vulnérabilité activement exploitée, le rapport final intervient, en principe, dans les quatorze jours suivant la disponibilité d’une mesure corrective ou d’atténuation. Pour un incident grave, un rapport final doit documenter notamment ses causes, son impact et les actions mises en œuvre. Ces délais peuvent être ajustés dans les modalités pratiques de la plateforme de notification européenne.
L’ENISA au centre du dispositif de remontée
Les signalements doivent transiter par une plateforme unique gérée par l’ENISA, puis être orientés vers les autorités compétentes des États membres. Cette centralisation vise à éviter la fragmentation des procédures nationales et à permettre une vision européenne des menaces affectant des produits largement distribués.
Les modalités de déclaration sont appelées à devenir un sujet technique autant que réglementaire. Une notification incomplète, trop tardive ou fondée sur une qualification erronée peut exposer l’entreprise à un risque de conformité, tout en compliquant la gestion de crise. Les informations publiées par l’ENISA constitueront un point de référence pour les équipes de cybersécurité et de conformité.
Pour les éditeurs et les équipes marketing, la conformité commence dans le produit
La sécurité ne peut plus être dissociée de la feuille de route
Dans les entreprises numériques, la vitesse de publication a longtemps prévalu : nouvelles fonctionnalités, intégrations d’API, automatisations, modèles d’intelligence artificielle ou extensions tierces sont déployés à un rythme soutenu. Le Cyber Resilience Act contraint à intégrer la sécurité dans cette chaîne de production, selon une logique de « security by design » et de « security by default ».
Cette évolution concerne directement les solutions de production de contenu, les outils de pilotage éditorial, les connecteurs de publication et les plateformes reliées à WordPress ou à des flux RSS. Dès qu’un produit traite des identifiants, pilote des publications, accède à des API ou échange des données avec des systèmes tiers, la maîtrise des accès, des dépendances et des mises à jour devient un sujet de continuité opérationnelle.
La question sensible des composants open source
Un logiciel moderne repose fréquemment sur des dizaines, parfois des centaines de bibliothèques et composants open source. Cette dépendance accélère le développement, mais elle complique l’identification d’une faille affectant un produit commercial. L’épisode Log4Shell, révélé fin 2021, avait montré la vitesse à laquelle une vulnérabilité dans une composante largement utilisée pouvait toucher des organisations de secteurs très différents.
Le règlement pousse les éditeurs à disposer d’un inventaire fiable des composants logiciels. La nomenclature SBOM, pour Software Bill of Materials, s’impose progressivement comme un outil de gouvernance : elle permet de savoir quelles versions de bibliothèques sont intégrées dans un produit, d’identifier les clients potentiellement exposés et de prioriser les correctifs.
Un enjeu de transparence envers les clients
La gestion d’une vulnérabilité ne se limite pas au dialogue avec l’autorité compétente. Les utilisateurs affectés doivent pouvoir recevoir une information compréhensible et des instructions d’atténuation lorsque leur sécurité est en jeu. Pour les fournisseurs SaaS, cette obligation se traduit par la nécessité de maintenir des canaux de communication de crise, des procédures de support et une documentation à jour.
La promesse commerciale d’un service numérique est ainsi appelée à intégrer plus explicitement la durée du support, les conditions de mise à jour et les mesures de sécurité appliquées. Dans les appels d’offres comme dans les contrats entre entreprises, ces garanties pourraient devenir des critères de sélection plus fréquents.
Les risques économiques et juridiques d’une préparation tardive
Des sanctions pouvant atteindre 15 millions d’euros
Le Cyber Resilience Act prévoit un régime de sanctions administratives laissé à la mise en œuvre des États membres, dans la limite des plafonds fixés par le règlement. Les manquements aux exigences essentielles de cybersécurité peuvent être sanctionnés jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total de l’exercice précédent, le montant le plus élevé étant retenu.
Les violations d’autres obligations prévues par le règlement peuvent conduire à des plafonds de 10 millions d’euros ou 2 % du chiffre d’affaires mondial. La transmission d’informations incorrectes, incomplètes ou trompeuses aux autorités est elle aussi passible de sanctions pouvant atteindre 5 millions d’euros ou 1 % du chiffre d’affaires mondial.
La non-conformité peut bloquer l’accès au marché
Au-delà des amendes, les autorités de surveillance du marché pourront demander des mesures correctrices, restreindre la mise à disposition d’un produit ou exiger son retrait du marché. Pour une jeune entreprise SaaS ou un éditeur spécialisé, la conséquence commerciale d’une telle décision peut être plus immédiate qu’une sanction financière : interruption de ventes, perte de clients et dégradation de la confiance des partenaires.
Le règlement ne crée pas seulement une charge de conformité. Il accroît aussi la valeur stratégique des processus de réponse à incident. Une entreprise capable d’isoler rapidement une vulnérabilité, de fournir un correctif et d’informer ses clients limite à la fois son exposition réglementaire et le coût d’une crise de réputation.
La documentation devient une preuve de maîtrise
Les entreprises devront être capables de démontrer les choix de sécurité réalisés pendant la conception, les tests menés, les vulnérabilités identifiées, les correctifs publiés et la période pendant laquelle elles assurent le support du produit. Cette documentation technique devra être conservée pendant au moins dix ans après la mise sur le marché du produit, selon les dispositions générales du règlement.
Pour les structures de taille réduite, la difficulté est moins théorique que documentaire : les connaissances sont souvent réparties entre développeurs, prestataires cloud, responsables produit et support client. Sans processus formalisé, les délais de vingt-quatre et soixante-douze heures risquent de s’avérer difficiles à tenir.
Comment se préparer avant l’échéance de septembre 2026
Cartographier les produits et les responsabilités
La première étape consiste à identifier les produits qui entrent dans le champ du règlement et le rôle exact de l’entreprise pour chacun d’eux : fabricant, importateur, distributeur ou prestataire technique. Cette cartographie doit inclure les logiciels commercialisés, les plugins, les applications, les objets connectés, les composants embarqués et les interfaces programmatiques exposées aux clients.
Cette analyse doit également distinguer les actifs exploités directement de ceux fournis par des tiers. Un outil SaaS peut reposer sur un hébergeur, un fournisseur de modèles d’intelligence artificielle, une passerelle de paiement, un service d’envoi d’e-mails et de nombreuses bibliothèques externes. La responsabilité juridique n’est pas identique pour chaque élément, mais la continuité de service dépend de l’ensemble.
Formaliser une procédure de réponse à incident
Les entreprises concernées disposent encore d’une période de préparation avant l’échéance. Les priorités opérationnelles sont relativement identifiables :
- désigner les responsables de la qualification et de la notification des incidents ;
- mettre en place une veille sur les vulnérabilités affectant les composants utilisés ;
- tenir un inventaire des dépendances et des versions déployées ;
- préparer des modèles d’alerte, de notification et de communication client ;
- tester des scénarios de crise incluant les délais de vingt-quatre et soixante-douze heures ;
- documenter les correctifs, mises à jour et décisions de sécurité.
Articuler le CRA avec le RGPD et NIS2
Les organisations peuvent être confrontées à plusieurs régimes de notification simultanés. Une cyberattaque affectant un produit numérique peut, selon les cas, entraîner une déclaration au titre du Cyber Resilience Act, une notification d’incident relevant de NIS2 et une notification de violation de données personnelles auprès de l’autorité compétente au titre du RGPD.
Ces textes n’ont ni le même périmètre ni les mêmes destinataires. Les rapprocher dans une gouvernance unique de la sécurité réduit néanmoins les risques de contradiction, de retard et de pertes d’information. Le texte complet du règlement est accessible sur EUR-Lex, la base officielle du droit de l’Union européenne.
Vers une sélection plus exigeante des fournisseurs numériques
La cybersécurité comme critère d’achat
Le Cyber Resilience Act devrait modifier progressivement les critères d’achat des entreprises. Les directions marketing et les responsables opérationnels choisissent de plus en plus des outils reliés à leurs systèmes de publication, à leurs données clients et à leurs environnements analytiques. La facilité d’intégration ou le prix ne suffiront plus à départager les solutions : les engagements de sécurité, de maintenance et de support seront appelés à peser davantage.
Cette tendance est particulièrement sensible pour les outils qui automatisent des actions à fort impact : publication de contenus, gestion de comptes, synchronisation de bases de données, traitement de documents ou pilotage de campagnes. Une vulnérabilité affectant un connecteur peut devenir une porte d’entrée vers des systèmes bien plus larges que l’outil initial.
Une charge disproportionnée pour les petites structures ?
Le règlement prévoit des dispositions tenant compte de la situation des microentreprises et petites entreprises, notamment dans l’accompagnement et la proportionnalité de certaines démarches. Pourtant, la mise en place d’une véritable gouvernance de la vulnérabilité représente un coût fixe qui pèse davantage sur les petites équipes que sur les grands éditeurs.
La mutualisation de certaines fonctions, le recours à des outils d’inventaire automatisé et l’intégration de contrôles de sécurité dans les cycles de développement peuvent limiter ce coût. Le principal enjeu reste l’anticipation : traiter la conformité quelques semaines avant l’échéance expose à des décisions précipitées, souvent plus onéreuses.
Une échéance intermédiaire avant le basculement de 2027
Le 11 septembre 2026 ne marque pas encore l’application de toutes les exigences du Cyber Resilience Act. Il constitue toutefois un test majeur de maturité pour l’écosystème numérique européen. À cette date, les entreprises devront prouver qu’elles savent détecter les signaux faibles, décider rapidement et communiquer avec les autorités lorsqu’une faille devient une menace effective.
À quinze mois de l’application générale prévue le 11 décembre 2027, cette première obligation de signalement dessine déjà la norme qui s’imposera aux produits numériques : la cybersécurité ne sera plus seulement une fonctionnalité attendue, mais une responsabilité documentée, suivie et contrôlable tout au long de leur vie commerciale.
