CRA et RGPD : sécurité, responsabilités et notifications

Une faille dans un produit connecté peut déclencher des obligations au titre du CRA et du RGPD. Les personnes responsables, les événements à signaler et les destinataires diffèrent. Une procédure commune doit conserver ces distinctions pour éviter qu’une notification technique masque une violation de données personnelles.

Au 28 septembre 2026, les signalements de l’Art. 14 du CRA sont déjà applicables. Les exigences générales de sécurité du produit présentées ci-dessous se préparent pour leur échéance principale de décembre 2027 ; elles ne reportent pas les obligations actuelles du RGPD.

CRA et RGPD : qualifier deux responsabilités

Le règlement (UE) 2024/2847 impose notamment au fabricant des exigences de cybersécurité du produit. Le RGPD concerne les traitements de données personnelles : le responsable du traitement détermine leurs finalités et moyens, tandis que le sous-traitant agit pour son compte. Un fabricant peut remplir plusieurs rôles selon l’opération, sans devenir automatiquement responsable de tous les traitements réalisés par ses clients.

Exemple hypothétique : une entreprise achète une caméra pour contrôler ses accès. L’éditeur doit examiner ses obligations de fabricant ; l’entreprise doit justifier son dispositif, limiter les accès aux images et fixer leur conservation. Le marquage CE de la caméra ne répond pas à ces dernières questions.

Commencer par le produit et les opérations réelles

Le CRA vise, dans son champ, des produits comportant des éléments numériques dont l’utilisation prévue ou raisonnablement prévisible comprend une connexion directe ou indirecte à un appareil ou à un réseau. Son Art. 2 prévoit aussi des exclusions. Une fiche d’achat doit donc identifier le produit, ses versions et ses fonctions ; l’étiquette « solution numérique » ne suffit pas à déterminer le régime applicable.

L’Art. 3, points 1 et 2, inclut certaines solutions de traitement à distance nécessaires aux fonctions du produit, conçues et développées par le fabricant ou sous sa responsabilité. Il ne faut pas en déduire que tout service cloud relève automatiquement du CRA. Décrivez la dépendance concrète entre l’appareil, le logiciel et le service distant avant d’attribuer des obligations.

Sur le versant RGPD, partez des opérations : images enregistrées localement, compte de l’administrateur, assistance technique ou données de diagnostic. Un fournisseur peut intervenir différemment selon ces opérations. Si une prestation traite des données pour le compte du client, examinez l’Art. 28 ; une notice de sécurité du produit ne remplace pas le contrat requis. Si le fournisseur détermine ses propres finalités, cette opération demande une autre qualification.

Mutualiser les preuves de sécurité

L’Art. 25(1) du RGPD impose au responsable du traitement la protection des données dès la conception. L’Art. 32(1) impose au responsable et au sous-traitant une sécurité adaptée au risque. Le CRA, Art. 13 et annexe I, organise la sécurité du produit et la gestion de ses vulnérabilités. Ces exigences se recoupent sans avoir exactement le même objet. Textes RGPD applicables.

Conservez une référence vers chaque preuve, son périmètre, sa date et son propriétaire. Une même pièce peut servir plusieurs analyses ; une conclusion de conformité doit rester rattachée à son texte. Le guide sur la sécurité des traitements permet de compléter cette matrice.

Transformer les documents du fabricant en questions d’achat

Pour préparer les exigences générales du CRA applicables principalement en décembre 2027, rapprochez l’Art. 13 et l’annexe I de vos usages. L’annexe prévoit notamment des exigences de protection des données traitées par le produit, de limitation aux données nécessaires et de gestion des vulnérabilités. Ces données ne sont pas nécessairement toutes personnelles. Le RGPD conserve son objet propre et ses obligations déjà applicables.

Dans une revue d’achat, demandez quelle version est couverte par la documentation, quelles fonctions exigent une connexion et ce qui change lorsqu’une option est activée. Un rapport relatif à une version antérieure peut être utile, mais il faut identifier les changements avant d’en tirer une conclusion sur le produit proposé.

Examinez ensuite la mise à jour en exploitation : qui reçoit l’avis, qui évalue la compatibilité, qui déploie et qui peut vérifier la version installée ? Un correctif disponible n’est pas un correctif appliqué. La fiche de suivi peut relier l’avis du fournisseur aux équipements concernés et aux exceptions à résoudre, sans annoncer une sécurisation de tout le parc à partir d’un seul équipement.

Enfin, préparez la sortie : récupération des données nécessaires, suppression des copies, retrait des accès et remplacement des fonctions devenues indispensables. La possibilité technique d’effacer un appareil ne règle pas, à elle seule, le sort des copies conservées dans un service distant. Ces points doivent être examinés avec les responsables de chaque traitement.

Une évaluation CRA ne remplace pas l’AIPD

L’évaluation des risques du produit examine ses risques de cybersécurité. L’AIPD analyse un traitement susceptible d’engendrer un risque élevé pour les personnes, selon l’Art. 35(1). Elle examine notamment sa nécessité et sa proportionnalité. L’ajout d’un composant analytique ne rend donc pas toute AIPD obligatoire par principe ; le traitement concret et les critères applicables doivent être examinés.

Pour un projet d’achat, faites valider ensemble : les usages, les données nécessaires, les accès, les durées, l’assistance de sécurité et le contrat de sous-traitance s’il y a lieu. La protection des données dès la conception complète cette démarche.

Deux circuits de notification à préparer

Les notifications du fabricant prévues par l’Art. 14 du CRA s’appliquent depuis le 11 septembre 2026. Les autres obligations générales suivent le calendrier de l’Art. 71, principalement le 11 décembre 2027.

Le CRA prévoit un signalement simultané au CSIRT coordonnateur et à l’ENISA, via la plateforme unique. Le RGPD conserve ses destinataires propres. L’information des personnes, en cas de risque élevé, relève de l’Art. 34, avec ses exceptions. Sources : CRA, Art. 14 et 16 ; RGPD, Art. 33–34.

Préparez deux fiches reliées au même dossier : signalement CRA et notification d’une violation de données. Une vulnérabilité n’est pas, à elle seule, la preuve d’une violation de données personnelles.

Relier les notifications sans fusionner leurs seuils

Les échéances CRA de 24 et 72 heures sont des plafonds accompagnant l’exigence d’agir sans retard injustifié. Il faut également distinguer les deux rapports finaux : leur point de départ diffère selon qu’il s’agit d’une vulnérabilité activement exploitée ou d’un incident grave. La date de disponibilité d’une mesure corrective ou d’atténuation ne doit pas être remplacée par la date à laquelle le dernier client l’a installée.

L’Art. 14(5) définit l’incident grave en fonction des effets possibles sur des données ou fonctions sensibles ou importantes, ou de l’introduction ou exécution possible de code malveillant. Cette appréciation n’exige pas nécessairement une atteinte à des données personnelles. Réciproquement, une violation de données chez un client peut résulter d’une mauvaise habilitation sans établir une vulnérabilité activement exploitée du produit.

L’information des utilisateurs prévue à l’Art. 14(8) du CRA doit aussi rester distincte de la communication aux personnes de l’Art. 34 du RGPD. L’administrateur d’un parc et les personnes filmées par un appareil ne sont pas forcément les mêmes destinataires. Préparez des messages adaptés à leurs besoins et vérifiez séparément les conditions de chaque obligation.

Une fiche commune avec des conclusions séparées

Reprenons la caméra dans un scénario entièrement fictif. Son fabricant signale une vulnérabilité activement exploitée sur une version. Le client possède deux appareils, mais n’a pas encore confirmé leurs versions ni les accès effectivement intervenus sur ses images. Aucun incident réel ni contrôle technique réalisé n’est relaté ici.

Cette fiche proposée évite deux raccourcis : conclure à une fuite chez tous les clients ou considérer que l’absence de preuve immédiatement disponible dispense de toute investigation. Conservez la date à laquelle chaque acteur connaît les faits qui déclenchent ses obligations. Le client n’attend pas nécessairement la clôture du dossier du fabricant pour agir sur sa propre violation.

Lors de la clôture, rapprochez les engagements des pièces disponibles : avis envoyé, mesure mise à disposition, déploiement effectivement vérifié et décisions de notification. Les conclusions peuvent rester différentes entre le produit et le traitement. Un dossier commun rend les échanges plus cohérents ; il n’efface ni les responsabilités ni les incertitudes propres à chaque organisme.

Ce qu’il faut retenir

• Attribuez séparément les rôles de fabricant, responsable du traitement et sous-traitant.
• Réutilisez les preuves techniques sans assimiler les deux conformités.
• Conservez les déclencheurs, destinataires et délais propres à chaque notification.
• Évaluez l’AIPD sur le traitement et les risques pour les personnes.

FAQ

Le marquage CE prouve-t-il la conformité RGPD ?

Non. Il ne démontre ni la base légale du traitement, ni la proportionnalité de la collecte, ni le respect des droits des personnes.

Faut-il notifier toute vulnérabilité à la CNIL ?

Non. Il faut qualifier une éventuelle violation de données et le risque correspondant. Une vulnérabilité activement exploitée peut cependant relever du CRA indépendamment de cette analyse.

Peut-on conserver un dossier d’incident commun ?

Oui. Une chronologie et des preuves communes sont utiles, à condition de conserver des décisions et notifications distinctes pour chaque obligation applicable.

Recevez nos analyses sur la protection des données et la conformité numérique.

Thiébaut Devergranne, docteur en droit, accompagne depuis plus de vingt ans les enjeux juridiques des technologies et est le fondateur de donneespersonnelles.fr.