Le Cyber Resilience Act (CRA) et le RGPD operent sur des plans distincts – le premier vise la securite des produits numeriques, le second la protection des donnees personnelles. Pourtant, des qu’un produit comportant des elements numeriques traite des donnees a caractere personnel, ces deux reglementations se recoupent de maniere significative. Ignorer cette intersection expose a un double risque de non-conformite. Voyons en detail comment ces deux textes s’articulent et comment mettre en place une strategie de conformite unifiee.

I. Security by design et privacy by design : une convergence structurelle

A. L’exigence de securite des la conception dans le CRA

Le CRA impose aux fabricants de produits comportant des elements numeriques de concevoir leurs produits selon le principe de securite par defaut et des la conception (security by design and by default). L’annexe I du reglement detaille les exigences essentielles de cybersecurite : absence de vulnerabilites connues exploitables, surface d’attaque minimale, protection de la confidentialite et de l’integrite des donnees stockees et transmises, ou encore minimisation des donnees collectees au strict necessaire au fonctionnement du produit.

Ce dernier point est particulierement revelateur : le CRA reprend, en matiere de cybersecurite produit, un principe fondamental du droit de la protection des donnees.

B. L’article 25 du RGPD : la protection des donnees des la conception

L’article 25 du RGPD impose au responsable de traitement de mettre en oeuvre, tant au moment de la determination des moyens du traitement qu’au moment du traitement lui-meme, des mesures techniques et organisationnelles appropriees – comme la pseudonymisation – destinees a appliquer les principes de protection des donnees de maniere effective. Le paragraphe 2 de ce meme article impose que, par defaut, seules les donnees necessaires a chaque finalite specifique soient traitees.

La convergence avec le CRA est frappante. Un fabricant qui concoit un objet connecte en appliquant les exigences de l’annexe I du CRA – minimisation des donnees, protection de la confidentialite, chiffrement des transmissions – satisfait simultanement une partie substantielle des obligations de privacy by design du RGPD. Inversement, un produit concu dans le respect de l’article 25 du RGPD aura deja integre des briques de securite que le CRA exige.

C. L’article 32 du RGPD : la securite du traitement

L’article 32 du RGPD oblige les responsables de traitement et les sous-traitants a mettre en oeuvre des mesures techniques et organisationnelles appropriees pour garantir un niveau de securite adapte au risque. Le texte cite expressement le chiffrement, la pseudonymisation, la capacite a garantir la disponibilite et la resilience des systemes, et les procedures de test et d’evaluation regulieres.

Ces exigences font echo aux obligations du CRA en matiere de gestion des vulnerabilites et de mises a jour de securite. Un produit conforme au CRA – c’est-a-dire correctement maintenu, dont les vulnerabilites sont corrigees sans delai et dont les mises a jour de securite sont fournies gratuitement – contribue directement a la conformite de son exploitant aux exigences de l’article 32. Dit autrement : la conformite CRA du fabricant alimente la conformite RGPD de l’utilisateur professionnel.

II. Signalement des vulnerabilites et notification de violation : deux regimes, un meme incident

A. Le signalement CRA : 24 heures a l’ENISA

Le CRA impose aux fabricants de signaler a l’ENISA, dans un delai de 24 heures, toute vulnerabilite activement exploitee dans leurs produits, ainsi que tout incident grave ayant un impact sur la securite du produit. Le regime detaille de signalement des vulnerabilites sous le CRA prevoit ensuite une notification complete dans les 72 heures, suivie d’un rapport final dans les 14 jours.

B. La notification RGPD : 72 heures a l’autorite de controle

Les articles 33 et 34 du RGPD imposent au responsable de traitement de notifier a l’autorite de controle (la CNIL en France) toute violation de donnees a caractere personnel dans les 72 heures suivant la prise de connaissance de la violation, sauf si celle-ci n’est pas susceptible d’engendrer un risque pour les droits et libertes des personnes. Lorsque la violation est susceptible d’engendrer un risque eleve, les personnes concernees doivent egalement etre notifiees.

C. Quand les deux regimes se chevauchent

Prenons un cas concret. Un fabricant d’objets connectes decouvre qu’une vulnerabilite zero-day dans son thermostat intelligent est activement exploitee, permettant a un attaquant d’exfiltrer les donnees de consommation energetique des utilisateurs – qui constituent des donnees a caractere personnel.

Dans ce scenario, les deux regimes de notification s’appliquent simultanement :

• En tant que fabricant, il doit notifier l’ENISA sous 24 heures au titre du CRA.
• S’il agit comme responsable de traitement (ou s’il doit informer le responsable de traitement utilisateur du produit), la notification a l’autorite de controle doit intervenir sous 72 heures au titre du RGPD, et les personnes concernees doivent etre informees si le risque est eleve.

Les delais different, les destinataires different, le contenu des notifications differe. Mais l’evenement declencheur est le meme. Sans processus unifie, le risque de manquer l’un des deux signalements – ou de communiquer des informations incoherentes – est reel.

III. SBOM et analyse d’impact : deux outils complementaires

Le CRA exige des fabricants qu’ils produisent et maintiennent un SBOM (Software Bill of Materials) documentant l’ensemble des composants logiciels de leurs produits. Le RGPD, de son cote, impose la realisation d’une analyse d’impact relative a la protection des donnees (AIPD, article 35) lorsqu’un traitement est susceptible d’engendrer un risque eleve pour les droits et libertes des personnes.

Ces deux exercices sont complementaires. Le SBOM permet d’identifier les composants logiciels qui traitent, stockent ou transmettent des donnees personnelles. L’AIPD permet d’evaluer les risques que ce traitement fait peser sur les personnes concernees. Concretement, le SBOM alimente l’AIPD : un composant tiers identifie dans le SBOM comme ayant acces a des donnees personnelles devra faire l’objet d’une evaluation de risque dans le cadre de l’analyse d’impact.

Par exemple, si le SBOM revele qu’un produit embarque une bibliotheque d’analytique tierce qui collecte des identifiants d’appareils, cette information doit declencher une evaluation au titre de l’article 35 du RGPD. L’articulation entre les deux demarches n’est pas optionnelle : elle est la consequence logique de l’application simultanee des deux textes.

IV. Quand un incident CRA est aussi une violation RGPD

Tous les incidents de securite au sens du CRA ne constituent pas des violations de donnees au sens du RGPD, et inversement. Pour qu’un incident CRA soit aussi qualifie de violation RGPD, il faut que l’incident ait conduit a une violation de la securite entrainant, de maniere accidentelle ou illicite, la destruction, la perte, l’alteration, la divulgation non autorisee de donnees a caractere personnel, ou l’acces non autorise a de telles donnees (article 4(12) du RGPD).

En pratique, le chevauchement est frequent. Une vulnerabilite exploitee dans un objet connecte qui traite des donnees personnelles aboutira souvent a un acces non autorise a ces donnees. Le fabricant doit alors gerer deux processus paralleles : la correction technique de la vulnerabilite (obligation CRA) et la gestion de la violation de donnees (obligation RGPD), avec ses volets de notification, de documentation au registre des violations, et eventuellement de communication aux personnes concernees.

V. Gerer la double conformite : approche pratique

A. Unifier la gouvernance

La premiere erreur serait de traiter le CRA et le RGPD en silos. L’equipe securite produit (CRA) et le delegue a la protection des donnees (RGPD) doivent travailler de concert. Chaque evaluation de risque cybersecurite au titre du CRA doit integrer un volet “donnees personnelles”, et chaque AIPD au titre du RGPD doit prendre en compte le niveau de securite du produit.

B. Harmoniser les processus de notification

Un processus unique de gestion des incidents doit alimenter les deux chaines de notification. Lorsqu’un incident est detecte, la qualification doit etre double : s’agit-il d’une vulnerabilite activement exploitee ou d’un incident grave au sens du CRA ? S’agit-il d’une violation de donnees au sens du RGPD ? Les deux questions doivent etre posees simultanement, par une equipe qui comprend les deux cadres juridiques.

C. Utiliser des outils adaptes

La gestion manuelle de la double conformite CRA-RGPD est rapidement impraticable des qu’un produit atteint une certaine complexite. Des outils comme Legiscope permettent de centraliser le suivi des obligations issues des deux reglementations, d’automatiser la documentation de conformite et de suivre les echeances de notification. L’interet d’un tel outil est de maintenir une vue unifiee des obligations croisees plutot que de multiplier les tableurs et les processus paralleles. Un audit RGPD integrant la dimension CRA permet d’identifier les zones de chevauchement et d’optimiser les efforts de conformite.

VI. Checklist de double conformite CRA-RGPD

Voici les actions concretes a mettre en oeuvre pour assurer une conformite conjointe :

Phase de conception du produit :

• Integrer les exigences de security by design (CRA, annexe I) et de privacy by design (RGPD, article 25) dans un cahier des charges unique.
• Appliquer le principe de minimisation des donnees, qui est commun aux deux textes.
• Prevoir le chiffrement des donnees personnelles en transit et au repos (exigence partagee CRA/RGPD).
• Documenter les choix de conception dans la documentation technique CRA et dans le registre des traitements RGPD.

Phase de mise sur le marche :

• Realiser l’evaluation de risque cybersecurite (CRA) et l’AIPD (RGPD) en parallele, en s’assurant de leur coherence.
• Exploiter le SBOM pour identifier les composants traitant des donnees personnelles et les integrer a l’AIPD.
• Verifier que les parametres par defaut du produit respectent a la fois le security by default et le privacy by default.

Phase d’exploitation et de maintenance :

• Mettre en place un processus unifie de gestion des incidents alimentant les deux chaines de notification (ENISA sous 24h pour le CRA, autorite de controle sous 72h pour le RGPD).
• Tenir a jour un registre des violations (article 33(5) RGPD) et un journal des vulnerabilites (CRA) dans un systeme centralise.
• Fournir les mises a jour de securite gratuites (CRA) et verifier que ces mises a jour ne creent pas de nouveaux risques pour les donnees personnelles (RGPD).
• Auditer periodiquement la conformite aux deux textes via un audit RGPD elargi a la dimension cybersecurite produit.

Outils et gouvernance :

• Designer un referent double conformite CRA-RGPD ou etablir une procedure de coordination entre le responsable securite produit et le DPO.
• Deployer un outil de suivi reglementaire comme Legiscope pour centraliser les obligations, les echeances et la documentation des deux cadres.
• Former les equipes de developpement aux exigences des deux textes, en insistant sur les zones de convergence.

Conclusion

Le CRA et le RGPD ne sont pas des reglementations concurrentes : elles sont complementaires. La securite des produits numeriques imposee par le CRA est un prerequis de la protection des donnees personnelles imposee par le RGPD. Les organisations qui comprennent cette articulation et mettent en place une gouvernance unifiee gagneront en efficacite et reduiront significativement leur exposition au risque – tant le risque d’incident que le risque de sanction. Celles qui persistent a traiter ces deux sujets en silos decouvert, un jour ou l’autre, qu’un incident de securite produit est aussi une fuite de donnees, et que deux non-conformites valent toujours pire qu’une seule.