Tout ce que vous devez savoir sur la loi sur la cyber-résilience

By Rébecca Harper • 23 juin 2026 • 10 min de lecture

La loi européenne sur la cyber-résilience (CRA) est la première réglementation majeure à traiter la cybersécurité comme une exigence de sécurité des produits plutôt que comme une exigence de gouvernance organisationnelle.

Alors que de nombreuses réglementations portent sur la gestion interne des cyber-risques par les organisations, la CRA adopte une approche différente. Elle se concentre sur les produits eux-mêmes. Plus précisément, elle vérifie si les logiciels, appareils, plateformes et technologies connectées mis sur le marché européen sont sécurisés dès leur conception, correctement maintenus et bénéficient d'un support tout au long de leur cycle de vie.

Pendant des années, la cybersécurité a souvent été perçue comme un problème de gouvernance, une préoccupation opérationnelle ou un défi technique relevant principalement des équipes de sécurité. L'accord de reconnaissance mutuelle (CRA) révèle une réalité plus vaste : la cybersécurité est de plus en plus considérée comme une exigence de sécurité des produits et, pour les organisations commercialisant des produits sur le marché de l'UE, les implications vont bien au-delà de la simple conformité.

Qu’est-ce que la loi sur la cyber-résilience ?

L'objectif principal du CRA est d'améliorer la cybersécurité des produits comportant des éléments numériques.

Concrètement, si un produit contient un logiciel, se connecte à un réseau, échange des données numériquement ou inclut une technologie connectée intégrée, il est probable qu'il entre dans le champ d'application.

Le règlement s'applique à l'ensemble du cycle de vie du produit et impose des obligations en matière de développement sécurisé dès la conception, de gestion des vulnérabilités, de mises à jour et de correctifs de sécurité, de signalement des incidents et des vulnérabilités, de documentation technique et d'évaluations de conformité, ainsi que de maintenance continue de la sécurité du produit. Il prévoit également des sanctions financières et, plus grave encore, la possibilité de restreindre ou de retirer définitivement les produits du marché en cas de manquement grave et persistant aux obligations réglementaires.

L’objectif est de réduire le nombre de produits numériques non sécurisés mis sur le marché européen, tout en harmonisant les exigences en matière de cybersécurité entre les États membres. Il est important de noter que ce document ne constitue ni une orientation ni un cadre de référence. La CRA est un règlement juridiquement contraignant.

Pourquoi l'ARC est importante

L'une des raisons pour lesquelles l'ARC a suscité autant d'attention est qu'elle modifie le lieu de la responsabilité.

Historiquement, de nombreuses réglementations en matière de cybersécurité se sont concentrées sur la résilience organisationnelle : la manière dont les entreprises gèrent les risques, réagissent aux incidents, encadrent leurs fournisseurs et protègent les services critiques. La CRA, quant à elle, met l’accent sur la sécurité du produit lui-même.

En pratique, ce règlement assimile la cybersécurité à la sécurité des produits traditionnels. De même que les fabricants doivent s'assurer que leurs produits physiques respectent les normes de sécurité avant leur mise sur le marché, la CRA exige que les produits numériques satisfassent aux exigences minimales de cybersécurité avant de pouvoir être vendus dans l'UE. Cela a des conséquences importantes pour les équipes de développement produit, les services d'ingénierie, les fournisseurs de logiciels, les responsables des achats et les chaînes d'approvisionnement.

Cela confirme également une tendance de marché plus générale. Les clients, les organismes de réglementation, les assureurs et les investisseurs attendent de plus en plus des organisations qu'elles démontrent non seulement leur capacité à réagir aux cyberincidents, mais aussi que la sécurité a été intégrée à leurs produits dès leur conception.

À qui s'applique l'ARC ?

On croit souvent, à tort, que le règlement ne s'applique qu'aux organisations dont le siège social est situé dans l'UE. En réalité, la CRA s'applique à toute organisation mettant sur le marché européen des produits éligibles, quel que soit son lieu d'établissement. Ainsi, les organisations britanniques, américaines et internationales peuvent toutes être concernées si elles vendent en Europe des produits comportant des éléments numériques.

Cette réglementation devrait avoir un impact sur un large éventail d'organisations, notamment :

Fournisseurs de logiciels
Fournisseurs SaaS et cloud
Fabricants d'IoT
Fabricants de matériel avec logiciel embarqué
fournisseurs de technologies industrielles
Importateurs et distributeurs de produits numériques

Les fabricants portent la plus grande responsabilité en vertu de cette réglementation car ils sont tenus de garantir la conformité tout au long du cycle de vie du produit.

Il existe également des catégories de « produits critiques » qui font l’objet d’un examen plus approfondi et d’exigences d’évaluation de la conformité plus rigoureuses en raison du niveau de cyber-risque qui leur est associé.

Ce que l'ARC exige

C’est au niveau opérationnel de la CRA que de nombreuses organisations risquent de ressentir le plus de pression. Cette réglementation ne se limite pas à la création de documents ou à la mise à jour des politiques. Elle exige des organisations qu’elles démontrent que la sécurité est mise en œuvre tout au long du cycle de vie du produit. Cela implique d’intégrer les principes de sécurité dès la conception dans les processus de développement, de maintenir des capacités efficaces de gestion des vulnérabilités, de publier les mises à jour de sécurité de manière appropriée et de conserver les preuves techniques de conformité.

Pour de nombreuses entreprises, cela nécessitera une meilleure visibilité sur les composants logiciels, les dépendances, les fournisseurs et les risques liés aux tiers. Il faudra également mettre davantage l'accent sur des processus de gestion des vulnérabilités éprouvés et sur des voies d'escalade plus claires entre les équipes de sécurité, d'ingénierie, de produit et de conformité. En pratique, certaines organisations pourraient constater que le principal défi n'est pas la compréhension de la réglementation elle-même, mais plutôt la préparation opérationnelle.

Signalement des incidents en vertu de la loi CRA et de la plateforme ENISA

L’un des aspects opérationnels les plus importants de l’accord de reconnaissance mutuelle (ARC) est l’introduction de l’obligation de déclaration des incidents et des vulnérabilités. Les fabricants seront tenus de déclarer :

Vulnérabilités activement exploitées
Incidents graves affectant la sécurité des produits comportant des éléments numériques

Il est important de noter que les obligations de déclaration sont spécifiquement liées à la sécurité des produits et à l'exploitation des vulnérabilités. Cela distingue la CRA des exigences plus générales de notification des violations de données prévues par des réglementations telles que le RGPD ou NIS 2.

Les délais sont volontairement exigeants. Conformément à l'article 14 de la CRA, les organisations devront soumettre :

Une notification d'alerte précoce dans les 24 heures suivant la prise de connaissance d'une vulnérabilité activement exploitée ou d'un incident grave
Une notification plus détaillée vous sera envoyée dans les 72 heures.
Un rapport final dans un délai d'un mois.

Pour de nombreuses organisations, ces fenêtres de reporting peuvent s'avérer difficiles à mettre en œuvre sur le plan opérationnel, notamment lorsque les chaînes d'approvisionnement logicielles sont complexes ou que la visibilité sur les dépendances est limitée.

Le règlement instaure également une structure de déclaration centralisée, liée à l'Agence de l'Union européenne pour la cybersécurité (ENISA). L'ENISA développe une plateforme unique de déclaration (SRP) destinée à simplifier les déclarations entre les États membres. Au lieu d'exiger des entreprises qu'elles notifient séparément plusieurs autorités nationales, l'objectif est de créer un mécanisme de déclaration plus unifié. Le processus de déclaration actuellement publié est décrit comme suit :

Un fabricant identifie une vulnérabilité exploitée ou un incident grave.
Une notification initiale est soumise via la plateforme de déclaration ENISA.
Les autorités nationales compétentes et les équipes d'intervention en cas d'incident de sécurité informatique (CSIRT) sont informées.
Les informations techniques complémentaires et les détails relatifs à la remédiation sont ensuite soumis via la même structure.

Au moment de la rédaction de ce document, la plateforme elle-même est encore en cours de développement, les obligations de déclaration devant commencer à s'appliquer à partir de septembre 2026.

Sur le plan opérationnel, ces obligations risquent d'exercer une pression accrue sur :

Surveillance des vulnérabilités
procédures d'escalade interne
visibilité de la nomenclature logicielle (SBOM)
Surveillance des fournisseurs
Coordination des interventions en cas d'incident
Communication interfonctionnelle entre les équipes d'ingénierie, de sécurité, juridiques et de conformité

Dates clés que les entreprises doivent connaître

Les organisations devraient déjà se préparer à deux dates importantes.

À compter du 11 septembre 2026, les obligations de l’ARC en matière de déclaration des vulnérabilités et des incidents commenceront à s’appliquer.

Les obligations de conformité élargies entreront en vigueur le 11 décembre 2027. À cette date, les produits entrant sur le marché de l'UE devront satisfaire aux exigences de cybersécurité de l'autorité de réglementation, tenir à jour la documentation technique, effectuer les évaluations de conformité pertinentes et satisfaire aux obligations de marquage CE associées – l'exigence de marquage de conformité, bien connue en matière de sécurité physique des produits, qui confirme qu'un produit répond aux normes réglementaires de l'UE applicables avant sa mise sur le marché.

Bien que ces échéances puissent paraître lointaines, de nombreuses organisations aux chaînes d'approvisionnement complexes ou à la visibilité limitée sur les nomenclatures de stock constatent déjà que la préparation opérationnelle prend beaucoup plus de temps que prévu.

Ce que les entreprises ignorent souvent au sujet de l'ARC

L'une des idées fausses les plus répandues est de croire que la CRA (Community Reinvestment Act) concerne principalement l'Internet des objets (IoT). Si les appareils connectés grand public sont bien sûr concernés, la réglementation s'applique à un champ d'application beaucoup plus vaste que ne le pensent de nombreuses organisations. Les logiciels d'entreprise, les plateformes cloud, les technologies industrielles, les systèmes logiciels embarqués et une large gamme de produits connectés peuvent tous être impactés.

Une autre idée fausse est que le règlement ne s'applique qu'aux organisations dont le siège social est situé dans l'UE. En réalité, le règlement relatif aux droits numériques (CRA) s'applique aux organisations qui mettent sur le marché de l'UE des produits comportant des éléments numériques, quel que soit leur lieu d'établissement. Les organisations britanniques et américaines qui vendent en Europe sont soumises aux mêmes obligations que les fournisseurs établis dans l'UE.

On a également tendance à sous-estimer le caractère opérationnel de la réglementation. La CRA n'est pas un simple exercice de documentation ni un cadre de conformité supplémentaire axé sur des politiques. Elle exige des organisations qu'elles démontrent la mise en œuvre de pratiques de développement sécurisées, de processus de gestion des vulnérabilités, de capacités de gestion des correctifs et d'une maintenance continue de la sécurité des produits.

Cela signifie que la réglementation est susceptible d'avoir un impact sur :

Équipes d'ingénierie et de développement
Fonctions du produit
Opérations DevOps et de sécurité
Gestion des achats et des fournisseurs
Équipes juridiques et de conformité
Leadership executif

De nombreuses organisations sous-estiment également le temps de préparation nécessaire. Le principal défi ne réside probablement pas dans la compréhension de la réglementation elle-même, mais plutôt dans l'état de préparation opérationnelle. Parmi les lacunes courantes, on peut citer :

Visibilité limitée sur les composants logiciels et leurs dépendances
Gestion SBOM incomplète
Faible surveillance de la sécurité des fournisseurs
Processus de gestion des vulnérabilités fragmentés
Procédures d'escalade et de signalement immatures
Difficulté à prouver les pratiques de développement sécurisées dès la conception

Enfin, de nombreuses entreprises se concentrent initialement sur les sanctions financières liées à la réglementation, négligeant ainsi ses implications commerciales plus larges. Les autorités peuvent restreindre les ventes, exiger des mesures correctives, imposer des rappels de produits ou retirer purement et simplement les produits non conformes du marché de l'UE. Pour de nombreuses organisations, le maintien de l'accès au marché européen pourrait finalement devenir le principal facteur de motivation pour se conformer à la réglementation sur les accords de reconnaissance mutuelle (ARC).

Les sanctions en cas de non-respect

Les sanctions financières prévues par la loi sur la cybersécurité (CRA) sont considérables. Pour les infractions les plus graves, les organisations peuvent se voir infliger des amendes allant jusqu'à 15 millions d'euros ou 2.5 % de leur chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Ces sanctions peuvent s'appliquer lorsque les organisations ne respectent pas les exigences en matière de cybersécurité, négligent leurs obligations de déclaration ou mettent sur le marché des produits non conformes.

Des sanctions supplémentaires peuvent être appliquées aux organisations qui fournissent des informations inexactes ou trompeuses aux autorités de réglementation.

Toutefois, les sanctions financières ne rendent pas pleinement compte du risque commercial lié à cette réglementation. L'impact potentiel sur l'accès au marché, la confiance des clients, l'éligibilité aux marchés publics et les relations avec les fournisseurs pourrait s'avérer encore plus important sur le plan commercial.

Se préparer à l'ARC : par où commencer

Pour de nombreuses organisations, la préparation nécessitera bien plus qu'une simple révision des politiques ou une mise à jour des documents de conformité . La réglementation obligera probablement les entreprises à examiner comment la sécurité est intégrée à l'ensemble du processus, de la conception des produits au développement, en passant par la maintenance, la supervision des fournisseurs et la gestion des incidents.

Pour de nombreuses organisations, le point de départ idéal est la définition du périmètre : identifier les produits concernés par la réglementation et ceux qui ne le sont pas. À partir de là, la préparation peut suivre une séquence logique :

Fondements : établir une visibilité. La plupart des organisations constatent que la principale lacune initiale ne réside pas dans la maturité des processus, mais dans une visibilité de base, et plus précisément dans la capacité à cartographier les composants logiciels et leurs dépendances grâce à une nomenclature logicielle (SBOM) à jour. Sans cela, la gestion des vulnérabilités et le contrôle des fournisseurs ne disposent d’aucune base fiable.

Processus : renforcer la gestion des vulnérabilités et la réponse aux incidents. Grâce à une meilleure visibilité, les organisations peuvent évaluer la maturité de leurs processus de gestion des vulnérabilités, leur capacité à respecter les délais de reporting stricts des autorités de réglementation et l’efficacité des voies d’escalade entre les services d’ingénierie, de sécurité et de conformité.

Assurance : preuves de pratiques de sécurité intégrées dès la conception. La dernière étape consiste à démontrer que la sécurité a été intégrée au cycle de développement lui-même, et non ajoutée a posteriori. C’est généralement là que les organisations dotées de cadres de gouvernance matures, tels que la norme ISO 27001, sont les mieux placées : l’infrastructure de contrôle existe déjà ; il suffit de l’étendre et de l’orienter vers la sécurité du produit.

C’est pourquoi de nombreuses entreprises s’efforcent d’aligner leurs cadres de gouvernance et de sécurité existants sur les nouvelles exigences en matière de sécurité des produits. Si ces cadres ne garantissent pas à eux seuls la conformité, les organisations dotées d’une gouvernance mature, d’une gestion efficace des risques, d’un contrôle rigoureux des fournisseurs et de capacités de réponse aux incidents seront probablement mieux préparées lorsque les obligations liées à la conformité aux réglementations commerciales entreront en vigueur.

La direction du voyage

La loi sur la cyber-résilience représente une évolution majeure en matière de réglementation de la cybersécurité. Au lieu de se concentrer uniquement sur la gouvernance ou la résilience organisationnelle, elle intègre les exigences de cybersécurité directement dans les produits numériques eux-mêmes. Pour les entreprises commercialisant leurs produits sur le marché européen, cela deviendra probablement non seulement un enjeu de conformité, mais aussi un facteur de stratégie produit, de résilience opérationnelle et de confiance commerciale.

Les organisations les mieux placées pour répondre avec succès seront probablement celles qui dépasseront la simple vision de l'analyse des risques liés aux produits (CRA) comme un exercice de conformité de dernière minute et l'intégreront plutôt à une évolution plus large vers des opérations sécurisées dès la conception, une résilience accrue et une plus grande responsabilité en matière de produits.

En définitive, l'accord de reconnaissance mutuelle des produits (CRA) reflète une réalité plus large à laquelle sont confrontées les entreprises modernes : la cybersécurité n'est plus seulement une responsabilité du service informatique. Elle devient de plus en plus une exigence fondamentale en matière de qualité des produits, de confiance des clients et d'accès au marché.