Le Cyber Resilience Act expliqué.

Le CRA s'applique aux produits comportant des éléments numériques : logiciels ou matériels dont l'utilisation prévue ou raisonnablement prévisible inclut une connexion de données directe ou indirecte à un appareil ou à un réseau (art. 2, par. 1, art. 3, point 1). Le traitement de données à distance est aussi couvert, si le fabricant l'a conçu pour le produit et que le produit ne pourrait pas exercer l'une de ses fonctions sans lui (art. 3, point 2).

Le produit doit être mis à disposition sur le marché de l'UE dans le cadre d'une activité commerciale, contre paiement ou gratuitement (art. 3, point 22). Il ne s'agit donc pas seulement de vente.

Selon les lignes directrices de la Commission de 2026, un logiciel qui s'exécute à distance et que vous ouvrez uniquement dans un navigateur n'est pas un produit sur ce seul motif. Les sites web ne sont pas non plus des produits. Les services d'informatique en nuage conçus et développés hors de la responsabilité d'un fabricant de produit sont exclus du CRA (considérant 12) ; la directive NIS 2 leur est applicable. Les fonctions en nuage qu'un fabricant construit pour faire fonctionner son propre produit sont couvertes. Un logiciel que vous téléchargez ou installez, y compris une extension de navigateur, est un produit.

Les secteurs dotés de règles propres sont exclus : dispositifs médicaux et dispositifs de diagnostic in vitro, véhicules à moteur, aviation civile et équipements marins (art. 2, par. 2 à 4). Les produits développés exclusivement pour la sécurité nationale ou la défense le sont aussi (art. 2, par. 7). Les produits qu'une administration publique développe ou modifie exclusivement pour son propre usage ne sont pas mis à disposition sur le marché (considérant 16).

• Couverts : les logiciels que vous installez ou exécutez sur vos propres appareils, le matériel connecté et les fonctions en nuage qu'un fabricant construit pour faire fonctionner son propre produit.
• Généralement exclus : les applications web que vous n'utilisez que via un navigateur, et les sites web qui ne soutiennent pas les fonctionnalités d'un produit.
• Exclus par secteur : dispositifs médicaux, diagnostic in vitro, véhicules à moteur, aviation civile, équipements marins.
• Les produits mis sur le marché avant le 11 décembre 2027 ne relèvent du CRA qu'après une modification substantielle (art. 69, par. 2). L'obligation de notification de l'article 14 s'applique en revanche à tous les produits relevant du champ d'application (art. 69, par. 3).

Les fabricants portent l'essentiel des obligations (art. 13). Ils doivent concevoir les produits conformément à l'annexe I, réaliser et documenter une évaluation des risques de cybersécurité et la tenir à jour pendant la période de support.

Avant de fournir un produit, les importateurs et distributeurs vérifient la présence du marquage CE, de la déclaration UE de conformité et des informations destinées aux utilisateurs (art. 19, art. 20). Quiconque fournit sous son propre nom ou sa propre marque, ou modifie substantiellement un produit, est traité comme un fabricant (art. 21 et 22).

Par défaut, le fabricant évalue lui-même la conformité (contrôle interne, art. 32, par. 1). Des procédures plus strictes s'appliquent aux produits importants (annexe III) et aux produits critiques (annexe IV). La classe I, par exemple les systèmes d'exploitation, gestionnaires de mots de passe, produits VPN et routeurs, ne peut recourir à l'autoévaluation que si des normes harmonisées, des spécifications communes ou une certification sont appliquées intégralement. La classe II, par exemple les hyperviseurs, pare-feu et systèmes de détection d'intrusion, ainsi que les produits critiques exigent une évaluation ou une certification par un tiers (art. 32, par. 2 à 4).

Un manquement à l'article 13 ou à l'article 14 peut entraîner des amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu (art. 64, par. 2). Les États membres fixent et appliquent les règles de sanction.

• Sécurité dès la conception et par défaut (annexe I, partie I) : aucune vulnérabilité exploitable connue à la mise à disposition, configuration sécurisée par défaut, protection contre les accès non autorisés, protection des données et possibilité de recevoir des mises à jour de sécurité.
• Gestion des vulnérabilités (annexe I, partie II) : une politique de divulgation coordonnée des vulnérabilités, une adresse de contact pour les signalements, la correction des vulnérabilités sans retard, une SBOM (nomenclature logicielle) couvrant au moins les dépendances de premier niveau, et des mises à jour de sécurité gratuites, sauf accord contraire pour les produits sur mesure (point 8).
• Période de support (art. 13, par. 8) : fondée sur la durée d'utilisation attendue et d'au moins cinq ans, sauf si le produit devrait être utilisé moins longtemps. La date de fin, au moins le mois et l'année, est indiquée clairement au moment de l'achat (art. 13, par. 19). Chaque mise à jour de sécurité reste disponible au moins 10 ans, ou pour le reste de la période de support si elle est plus longue (art. 13, par. 9).
• Conformité : évaluation de la conformité, documentation technique, déclaration UE de conformité, marquage CE (art. 13, 28 et 30) et informations aux utilisateurs conformément à l'annexe II.
• Notification (art. 14), depuis le 11 septembre 2026 : une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification dans les 72 heures, et un rapport final au plus tard 14 jours après la disponibilité d'une mesure corrective ou d'atténuation (vulnérabilités) ou dans un délai d'un mois après la notification de l'incident (incidents graves). Les notifications passent par la plateforme unique, simultanément vers le CSIRT désigné comme coordinateur et vers l'ENISA. Le fabricant informe aussi les utilisateurs concernés (art. 14, par. 8).

À partir du 11 décembre 2027, les obligations de la section précédente s'appliquent aux produits relevant du champ d'application mis alors sur le marché. Elles ne s'appliquent généralement pas au SaaS que vous n'utilisez que via un navigateur, ni aux produits mis sur le marché plus tôt, sauf modification substantielle. Reprenez les points ci-dessous dans vos appels d'offres, questionnaires et contrats.

L'obligation de notification s'applique déjà depuis le 11 septembre 2026. Vous pouvez dès à présent attendre des fournisseurs qu'ils notifient les vulnérabilités activement exploitées et les incidents graves dans les délais de l'article 14, y compris pour les produits mis sur le marché plus tôt. Le CRA ne vous empêche pas d'imposer des exigences de cybersécurité supplémentaires dans vos propres achats (art. 5, par. 1, considérant 13).

• Marquage CE : le produit le porte-t-il, et où ? Pour un logiciel, il figure sur la déclaration UE de conformité ou sur le site web qui accompagne le logiciel (art. 30, par. 1).
• Déclaration UE de conformité : où pouvez-vous la consulter ? Une déclaration simplifiée doit contenir l'adresse internet exacte de la déclaration complète (art. 13, par. 20).
• Période de support : quelle est la date de fin, au moins le mois et l'année, pour la version que vous achetez ? Elle doit être indiquée clairement au moment de l'achat (art. 13, par. 19). Le minimum est de cinq ans, sauf si le produit devrait être utilisé moins longtemps (art. 13, par. 8).
• Mises à jour de sécurité : sont-elles gratuites pendant la période de support (sauf accord contraire pour les produits sur mesure), et comment sont-elles distribuées ? (annexe I, partie II, points 7 et 8).
• Contact pour les vulnérabilités : qui est le point de contact unique, et où se trouve la politique de divulgation coordonnée des vulnérabilités ? (art. 13, par. 17, annexe II).
• SBOM : le fournisseur doit en tenir une couvrant au moins les dépendances de premier niveau, et la remet aux autorités sur demande motivée. La partager avec les clients est facultatif (annexe II, point 9) : demandez-la donc expressément ou prévoyez-la dans le contrat.
• Incidents : le fournisseur vous informera-t-il des vulnérabilités activement exploitées et des incidents graves, et sous quelle forme ? (art. 14, par. 8).
• Procédure de conformité : pour les produits des annexes III ou IV, quelle procédure d'évaluation a été suivie ? (art. 32).

Les logiciels libres et open source ne sont couverts que s'ils sont fournis dans le cadre d'une activité commerciale. Ceux que leurs auteurs ne monétisent pas ne le sont pas (considérant 18). Le soutien financier de fabricants ou des publications régulières ne rendent pas à eux seuls un logiciel commercial. Le simple hébergement de code sur un dépôt ouvert ou un gestionnaire de paquets n'est pas une mise à disposition sur le marché (considérant 20).

L'activité commerciale ne se limite pas à un prix. Le considérant 15 cite : un prix pour le support technique qui dépasse la simple couverture des coûts, l'intention de monétiser (par exemple une plateforme permettant de monétiser d'autres services), l'exigence de traiter des données personnelles pour d'autres finalités que la sécurité, la compatibilité ou l'interopérabilité, et l'acceptation de dons supérieurs aux coûts. Les dons sans but lucratif ne constituent pas une activité commerciale.

Un gestionnaire de logiciels libres (open-source software steward) est une personne morale, autre qu'un fabricant, qui apporte de manière systématique et durable un soutien au développement de produits open source destinés à des activités commerciales (art. 3, point 14). Certaines fondations, ainsi que des entités qui publient de l'open source dans un contexte professionnel, peuvent être gestionnaires (considérant 19). Un régime allégé leur est applicable (art. 24).

Les gestionnaires ne peuvent pas apposer le marquage CE (considérant 19) et ne sont pas soumis aux amendes administratives de l'article 64, par. 3 à 9 (art. 64, par. 10, point b). Selon l'ENISA, leurs obligations s'appliquent à partir du 11 décembre 2027. Selon les lignes directrices de la Commission, une même organisation peut être gestionnaire pour un projet et fabricant pour un autre. Les fabricants qui utilisent des composants open source doivent faire preuve de diligence à leur égard (art. 13, par. 5).

• Une politique de cybersécurité documentée qui favorise un développement sûr et une gestion efficace des vulnérabilités.
• Une coopération avec les autorités de surveillance du marché sur demande.
• La notification des vulnérabilités selon l'article 14, dans la mesure où le gestionnaire participe au développement.

Le CRA et NIS 2 (directive (UE) 2022/2555) portent sur des objets différents. Le CRA fixe des exigences pour les produits et leurs fabricants. NIS 2 concerne les services et la gestion des risques des entités essentielles et importantes.

Le CRA indique que la législation de l'Union en matière de cybersécurité, dont NIS 2, ne couvre pas directement les exigences obligatoires de sécurité des produits comportant des éléments numériques (considérant 3). Il vise à aider les fournisseurs d'infrastructures numériques à respecter les exigences de la chaîne d'approvisionnement de NIS 2, en veillant à ce que les produits qu'ils utilisent soient développés de manière sûre et reçoivent des mises à jour de sécurité en temps utile (considérant 24). Les mesures de chaîne d'approvisionnement de NIS 2 peuvent exiger des produits plus stricts que le CRA (considérant 13).

Les deux se rejoignent pour les notifications : le CRA utilise comme destinataires les CSIRT désignés comme coordinateurs, connus de NIS 2 (art. 14). Savoir si votre propre organisation relève de NIS 2 est une autre question, à laquelle cette page ne répond pas.

Aujourd'hui, cette page est purement informative. Le CRA ne modifie ni le score de souveraineté ni les recommandations.

À titre pilote, les fournisseurs de la catégorie CMS affichent désormais les signaux CRA que nous avons trouvés publiquement, à titre d'information à côté des données existantes et sans les intégrer au score : un security.txt, une page pour signaler une vulnérabilité, une politique de versions prises en charge et, pour l'open source, l'organisation derrière le projet. Chaque lien a été vérifié sur le site du fournisseur ou du projet lui-même. À partir du 11 décembre 2027, nous afficherons aussi la déclaration UE de conformité (marquage CE) dès qu'un produit en dispose.

Un signal CRA ne dit rien du lieu d'établissement d'un fournisseur ni de son propriétaire. Souveraineté numérique et sécurité des produits sont des questions distinctes.