Notification de violation : le chiffrement change l'équation
Quand une violation survient, le compte à rebours de 72 heures du RGPD et la règle « dès que possible » de la nLPD suisse démarrent. Le chiffrement fort n'empêche pas les violations — mais il peut considérablement réduire ce qui doit être notifié, à qui, et quand. Voici comment les deux régimes traitent les données chiffrées et où cela change le calcul des décideurs.

Tôt ou tard, quelque chose dérape. Un ordinateur portable avec un export de base sort du bureau. Un bucket cloud mal configuré est indexé par un moteur de recherche. Un token GitHub de prestataire fuite. Un e-mail de phishing atterrit chez la mauvaise assistante. À cet instant précis, l'horloge juridique démarre : 72 heures pour notifier l'autorité de contrôle UE au titre du RGPD, « dès que possible » sous la nLPD suisse, plus — dans certains cas — l'obligation d'informer chaque personne concernée de ce qui s'est passé.
Le chiffrement fort n'empêche ni la disparition de l'ordinateur ni la mauvaise configuration du bucket. Mais les deux régimes tracent une ligne nette entre la violation de données lisibles par un tiers non autorisé et la violation de données qui ne le sont pas. Pour les décideurs — direction juridique, DPO, CISO, comité exécutif — cette distinction fait souvent la différence entre une notification réglementaire pénible mais gérable et un événement de notification de masse aux conséquences réputationnelles et financières lourdes. Cet article examine où se situe cette distinction, ce qui compte comme « suffisamment chiffré » et comment les deux régimes en tiennent compte en pratique.
À qui s'adresse cet article
Directions juridiques, DPO, CISO et dirigeants responsables de la réponse à incident dans des organisations suisses et européennes — particulièrement lorsque les scénarios de violation passent par des formulaires, des fournisseurs SaaS ou des sous-traitants où les contrôles techniques ne sont pas uniformes sur la chaîne.
Qu'est-ce qu'une violation de données personnelles
Les deux régimes utilisent une définition large. L'art. 4(12) du RGPD définit la violation comme « une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l'altération, la divulgation non autorisée de données à caractère personnel transmises, conservées ou traitées d'une autre manière, ou l'accès non autorisé à de telles données ». L'art. 5(h) nLPD emploie une formulation essentiellement parallèle : toute violation de la sécurité entraînant la perte, la suppression, la destruction ou la modification involontaires ou illicites de données personnelles, ou leur divulgation ou un accès à des personnes non autorisées.
Quelques implications pratiques pour les processus fondés sur des formulaires :
- L'incident n'a pas à être l'œuvre d'un attaquant hostile. La perte accidentelle — disque dur oublié dans le train, e-mail au mauvais groupe, Drive Google partagé publiquement — compte
- L'indisponibilité peut compter. Si un rançongiciel chiffre votre base de soumissions sans sauvegarde, c'est une « perte » sous les deux définitions
- La violation vit là où vivent les données. Une fuite chez votre fournisseur de formulaires est votre violation en tant que responsable, même si la défaillance était de son côté
- Une violation chez le sous-traitant est présumée une violation dont le responsable doit être informé ; le sous-traitant a sa propre obligation légale d'informer sans retard indu
RGPD : l'horloge de 72 heures et l'exception de l'art. 34
Le RGPD connaît deux obligations de notification distinctes avec deux seuils distincts.
Notification à l'autorité de contrôle (art. 33)
Le responsable notifie sans retard injustifié et, si possible, dans les 72 heures après avoir pris connaissance de la violation. L'exception est étroite : « à moins que la violation ne soit pas susceptible d'engendrer un risque pour les droits et libertés des personnes physiques ». En pratique, beaucoup d'équipes juridiques notifient même les cas limites, parce que le coût d'une omission justifiée qui s'avère injustifiée dépasse largement celui d'une sur-notification.
La notification décrit la nature de la violation, catégories et nombres approximatifs de personnes et d'enregistrements concernés, conséquences probables et mesures prises ou proposées. Un délai supérieur à 72 heures est possible, mais doit être motivé. Ce motif est lui-même un document que l'autorité examinera plus tard.
Notification aux personnes concernées (art. 34)
Un seuil bien plus élevé s'applique à la notification individuelle. Elle n'est requise que lorsque la violation est « susceptible d'engendrer un risque élevé pour les droits et libertés d'une personne physique ». L'art. 34(3) énumère trois cas dans lesquels même une violation à risque élevé n'exige pas de notification individuelle :
- Art. 34(3)(a) : « le responsable du traitement a mis en œuvre les mesures de protection techniques et organisationnelles appropriées et ces dernières ont été appliquées aux données à caractère personnel affectées par ladite violation, en particulier les mesures qui rendent les données à caractère personnel incompréhensibles à toute personne qui n'est pas autorisée à y avoir accès, telles que le chiffrement »
- Art. 34(3)(b) : mesures ultérieures garantissant que le risque élevé de l'art. 34(1) n'est plus susceptible de se matérialiser
- Art. 34(3)(c) : effort disproportionné — alors communication publique ou mesure équivalente
Le premier — l'exception de chiffrement — est la plus puissante des bouées de sauvetage dans l'architecture RGPD des violations. Il ne supprime pas la notification à l'autorité (qui reste due), mais peut légalement lever l'obligation d'envoyer un courrier, un e-mail ou une communication publique à chaque personne concernée. À l'échelle — des dizaines ou centaines de milliers de personnes — la différence pratique est énorme.
nLPD : « dès que possible » et le critère de protection
La loi fédérale suisse révisée sur la protection des données (nLPD), en vigueur depuis le 1er septembre 2023, poursuit une intention similaire avec des termes différents.
Notification au PFPDT (art. 24 al. 1)
Le responsable notifie au PFPDT toute violation de la sécurité des données « susceptible d'entraîner un risque élevé pour la personnalité ou les droits fondamentaux de la personne concernée ». La notification intervient « dès que possible ». Pas de délai strict de 72 heures, mais en pratique la plupart des équipes juridiques suisses exécutent un playbook 72 heures pour satisfaire simultanément RGPD et nLPD.
Notification à la personne concernée (art. 24 al. 2)
Le responsable informe la personne concernée « si cela est nécessaire à sa protection ou si le PFPDT l'exige ». Notable : c'est un test à friction plus faible que le « risque élevé » du RGPD — la règle suisse demande ce dont la personne a réellement besoin pour se protéger.
La nLPD ne codifie pas l'exception de l'art. 34(3)(a) dans les mêmes mots. Mais elle produit une logique voisine : si les données ne sont jamais devenues lisibles hors du cercle autorisé — parce qu'un chiffrement fort a été appliqué et que les clés n'ont pas été compromises — la question « la notification est-elle nécessaire à la protection de la personne ? » trouve souvent sa réponse. Les orientations du PFPDT et le cadre fondé sur le risque de la nLPD traitent l'intelligibilité effective des données comme un facteur de premier ordre.
Un playbook 72 heures couvre généralement les deux
La plupart des organisations suisses avec même une légère exposition UE exécutent un playbook calibré sur l'horloge 72 heures du RGPD. Celle-ci étant la plus stricte, elle couvre automatiquement le « dès que possible » de la nLPD. La divergence est surtout sur le seuil de notification individuelle — et les deux régimes pèsent fortement la question de l'intelligibilité réelle des données pour le tiers non autorisé.
Qu'est-ce qui compte comme « suffisamment chiffré » pour l'exception ?
Les autorités ont été claires : le « chiffrement » au sens de l'art. 34(3)(a) n'est pas une case à cocher. Les Lignes directrices 01/2021 du CEPD et les commentaires du PFPDT posent quelques conditions pour que l'exception s'applique réellement :
- L'algorithme et la longueur de clé doivent être considérés comme état de l'art au moment de la violation — grosso modo AES-256, RSA-4096 ou équivalents modernes en courbes elliptiques, ou primitives équivalentes bien relues
- L'implémentation doit être saine — pas de crypto maison, pas de réutilisation de clés, gestion correcte des IV/nonces, chiffrement authentifié (AES-GCM ou équivalent) où l'intégrité compte
- Les clés doivent être restées hors de portée de l'attaquant — si la même compromission qui expose le chiffré expose aussi la clé, plus d'exception
- Le chiffrement doit avoir été appliqué aux données effectivement exposées — pas simplement à une autre copie ou un autre système
- La durabilité prospective compte — un algorithme robuste aujourd'hui mais probablement cassé demain (p. ex. menaces quantiques connues contre certains schémas) ne couvre pas à vie
Quelques corollaires pour les flux de formulaires :
- Le chiffrement au repos (disque complet) aide contre le vol physique, pas contre la compromission d'une application en cours d'exécution — l'OS sert du clair à l'application, qui sert du clair à l'attaquant
- Le chiffrement en transit (HTTPS / TLS) ne qualifie pas : les données sont lisibles aux deux extrémités
- Le chiffrement applicatif avec clés chez le fournisseur ne qualifie pas si c'est le fournisseur qui est compromis — il détenait les clés
- Le chiffrement de bout en bout où seul le propriétaire du formulaire détient les clés (architecture à connaissance nulle) est la posture la plus forte : une violation chez le fournisseur n'expose que du chiffré, et le fournisseur ne peut livrer de données lisibles même sous contrainte
L'exception protège le contenu, pas les métadonnées
Même avec le chiffrement le plus fort sur le contenu des soumissions, certaines métadonnées peuvent fuiter — ID de formulaire, horodatages, volumes, et dans certaines architectures l'identité de l'émetteur. Les autorités examinent la violation dans son ensemble — minimiser ce qui est collecté et garder les métadonnées peu sensibles reste important.
Matrice de décision : que notifier réellement
À haut niveau, les deux régimes produisent la matrice suivante pour les scénarios courants. Indicative seulement — les incidents réels ont toujours des nuances — mais elle montre où le chiffrement vous déplace.
| Scénario | Autorité (UE) | Autorité (CH) | Personnes |
|---|---|---|---|
| Violation en clair, faible risque | Notifier (art. 33) sauf absence-de-risque défendable | Notifier si risque élevé — cas limites : notifier | Généralement non requis |
| Violation en clair, risque élevé (données sensibles, grande échelle) | Notifier dans 72 h (art. 33) | Notifier dès que possible (art. 24 al. 1) | Notification individuelle au titre de l'art. 34 RGPD ; art. 24 al. 2 nLPD si nécessaire à la protection |
| Violation en chiffré seul, chiffrement fort, clés hors portée | Notifier dans 72 h (art. 33) — c'est l'autorité qui décide, pas vous | Notifier si encore probablement risque élevé — souvent non | Exception art. 34(3)(a) applicable ; nLPD généralement « non nécessaire à la protection » |
| Violation chiffrée mais clés compromises au même incident | Notifier dans 72 h (art. 33) | Notifier dès que possible | Notification individuelle — pas d'exception |
| Violation chez le sous-traitant, E2EE forte côté responsable | Notifier dans 72 h une fois le responsable informé | Notifier dès que possible | Généralement non requis si l'architecture E2EE n'expose que du chiffré |
Les grands déplacements sont toujours dans la colonne de droite. La notification individuelle de masse génère presse, attention de régulateur, risque de class-action et atteinte réputationnelle. L'exception de chiffrement est le mécanisme juridique qui peut retirer cette colonne d'un incident donné — et elle est entièrement pilotée par les contrôles techniques mis en place avant l'incident.
Un playbook 72 heures à double régime
Heure 0 — Détection et escalade
Sécurité ou opérations repèrent un incident potentiel. Un playbook d'astreinte l'envoie au DPO et à la direction juridique dans la première heure. L'horloge de l'art. 33 RGPD démarre à la « prise de connaissance » du responsable — les autorités traitent cela comme un moment managérial, pas purement technique.
Heures 0–12 — Périmètre et confinement technique
Quelles données exposées, à qui, pendant combien de temps ? Crucial : en clair ou en chiffré ? Si chiffré, les clés ont-elles été exposées au même incident ? Documenter avec preuves — logs, KMS, schémas d'architecture.
Heures 12–36 — Évaluation juridique et rédaction
Cartographier l'incident sur les seuils : art. 33 (autorité UE), art. 24 nLPD (autorité CH), art. 34 RGPD et art. 24 al. 2 nLPD (personnes). Si l'exception de chiffrement est plausible, documenter les preuves techniques — algorithme, garde des clés, preuve d'absence de compromission. Décider de la stratégie de notification individuelle.
Heures 36–72 — Notifications aux autorités
Déposer la notification art. 33 auprès de l'autorité chef de file. Déposer la notification art. 24 al. 1 nLPD auprès du PFPDT. Tenir une traçabilité interne propre. Si notification individuelle requise, rédiger une copie simple, actionnable, sans jargon.
Au-delà de 72 heures — Notification individuelle et remédiation
Si art. 34 RGPD déclenché, les notifications partent. Sous nLPD, le tempo tient au « dès que possible » et au retour du PFPDT. En parallèle, remédier à la vulnérabilité et — tout aussi important — produire la traçabilité qui montre une réaction raisonnable. Le dossier post-incident est ce que les régulateurs lisent en premier.
Semaine 2+ — Revue post-incident et renforcement
Documenter la cause racine, les contrôles qui ont tenu et ceux qui ont cédé. Là où l'exception de chiffrement a joué, capturer la décision architecturale qui l'a rendue possible — elle portera encore lors du prochain incident. Boucler dans le registre des violations et la revue de risque annuelle.
Où un fournisseur à connaissance nulle change les comptes
Pour une large classe de flux par formulaires — admission patients, KYC, lanceurs d'alerte, accueil juridique, sinistres assurance — l'exposition aux violations passe par un fournisseur tiers. La question le jour de l'incident : qu'y a-t-il effectivement dans la base du fournisseur ?
Chez un fournisseur générique, la réponse est souvent « du clair ». Une violation devient votre violation de responsable, et le chemin des art. 33, 24, 34 et notification individuelle est ouvert. Chez un fournisseur à connaissance nulle — qui ne stocke que du chiffré dont il n'a pas la clé — le même incident produit une exposition chiffrée. L'application de l'art. 34(3)(a) est à apprécier avec votre autorité, mais vous êtes du bon côté de la ligne.
Schweizerform est bâti pour cette posture : chiffrement de bout en bout dans le navigateur de l'émetteur, clés uniquement chez le propriétaire du formulaire, hébergement suisse pour le chiffré, support EN / DE / FR / IT. Cela n'élimine pas le risque. Cela change ce qu'une violation signifie.
En résumé
La notification sous RGPD et nLPD est un exercice de timing autour d'un exercice de faits. Le timing — 72 heures, « dès que possible » — est implacable ; les faits pilotent les décisions. Et le fait unique qui change régulièrement la décision dans les deux régimes est celui de savoir si les données qui ont quitté votre contrôle étaient intelligibles pour celui qui les a reçues.
Le chiffrement n'empêche pas les violations. Il change ce que la violation vous oblige à faire. Pour des données assez sensibles pour qu'une notification de masse soit un événement qui définit la catégorie de votre organisation, cette bascule vaut qu'on la conçoive — pas après l'incident, trop tard, mais avant, dans les choix d'architecture qui déterminent ce que « les données » sont vraiment lorsque quelque chose dérape.
Schweizerform est conçu pour qu'un incident chez le fournisseur expose du chiffré, pas du contenu. Chiffrement de bout en bout à connaissance nulle sur chaque formulaire, hébergement suisse, support complet EN / DE / FR / IT — sans carte bancaire sur le palier gratuit.
Avertissement : Cet article est une information générale et du contenu marketing, non un conseil juridique, réglementaire ou de réponse à incident. Les références aux art. 4, 33 et 34 RGPD et aux Lignes directrices 01/2021 du CEPD, aux art. 5 et 24 nLPD et aux orientations du PFPDT, ainsi qu'à l'état de l'art cryptographique, sont résumées conceptuellement et sujettes à interprétation juridictionnelle, pratiques d'autorités, jurisprudence et évolution législative. Les incidents concrets — y compris la détermination factuelle de l'applicabilité de l'exception de chiffrement — exigent une évaluation juridique et technique en temps réel. Consultez un conseil qualifié en protection des données suisse et UE, et vos partenaires réponse à incident et forensique, avant de fonder vos décisions de réponse ou d'achat sur un seul article, y compris celui-ci.