Le fichier de fidélité a disparu

Le programme de fidélité des Arcades, le centre commercial qui sert de fil rouge à cette série, tourne depuis six ans. Quarante mille porteurs de carte, avec pour chacun un nom, un courriel, une date de naissance et l'historique des achats dans les boutiques partenaires.

Un lundi matin, le prestataire qui gère les cartes pour le compte du centre envoie un message embarrassé. Une console d'administration est restée joignable depuis Internet tout le week-end, et les journaux montrent des téléchargements que personne ne s'explique.

Le directeur se retrouve avec deux problèmes qui se ressemblent mais ne se traitent pas pareil. Le premier est technique : couper l'accès, mesurer ce qui est parti, empêcher la récidive. Le second concerne le fichier lui-même, qui ne décrit pas des stocks mais des personnes, et ces personnes ont des droits.

Les deux problèmes partagent les mêmes faits et démarrent au même instant. Ils ne s'adressent pas au même public, et ils ne se comptent pas dans la même unité de temps.

Un incident de sécurité qui touche des données personnelles se lit deux fois : une fois par le SOC, qui mesure des minutes de confinement, une fois par le responsable de traitement, qui compte des heures avant une notification.

Ce billet est le point de contact entre la réponse à incident vue plus tôt dans la série et le RGPD. Il porte volontairement le domaine Détection & réponse, parce que qualifier une violation et la notifier reste un geste de gestion d'incident, pas un exercice de paperasse séparé.

Vue d'ensemble : cinq gestes, deux destinataires

Le règlement traite le sujet en trois articles, plus une définition. Les connaître dans l'ordre évite l'essentiel des erreurs.

L'article 4(12) définit ce qu'est une violation de données à caractère personnel. C'est le filtre d'entrée : si les faits n'entrent pas dans cette définition, la suite ne s'applique pas.

L'article 33 organise la notification à l'autorité de contrôle, avec son délai de 72 heures, son contenu minimal, sa possibilité de compléter par étapes, et à son paragraphe 5 l'obligation de documenter en interne toutes les violations.

L'article 34 traite d'un autre destinataire, les personnes concernées elles-mêmes, avec un seuil différent et plus élevé.

En pratique, la séquence tient en cinq gestes qui s'enchaînent : qualifier les faits, horodater la prise de connaissance, apprécier le risque, notifier l'autorité puis informer les personnes si le risque le justifie, et consigner la décision dans un registre interne. Les sections qui suivent reprennent ces gestes un par un.

Deux destinataires, deux seuils. On notifie l'autorité de contrôle sauf si le risque est improbable ; on informe les personnes concernées seulement quand le risque est élevé.

Le RGPD a déjà été présenté dans cette série comme obligation légale, aux côtés d'ISO 27001, de SOC 2 et de NIS2, dans le billet Conformité : ISO 27001, SOC 2, RGPD et NIS2. On ne refait pas ce cadrage ici.

Ce qui compte comme violation

Aux Arcades, le vol du fichier client est le scénario auquel tout le monde pense. Mais l'hôtesse d'accueil qui laisse une liste d'adhérents imprimée sur le comptoir pose exactement le même problème juridique, sans qu'aucun attaquant n'ait eu à intervenir.

L'article 4(12) 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, ou l'accès non autorisé à ces données.

Deux éléments portent tout le poids de la définition. « Accidentelle », qui écarte l'idée qu'il faille un attaquant. Et l'énumération, qui couvre bien plus que la fuite.

On y retrouve les trois atteintes classiques de la sécurité, sous un vocabulaire juridique :

  • Confidentialité : des données sont divulguées ou consultées sans autorisation.
  • Intégrité : des données sont altérées de manière non autorisée.
  • Disponibilité : des données sont détruites ou deviennent inaccessibles.

Un rançongiciel qui chiffre la base clients sans rien exfiltrer reste donc une violation, par atteinte à la disponibilité. Un courriel parti au mauvais destinataire en est une autre, par atteinte à la confidentialité. Une suppression accidentelle sans sauvegarde exploitable également.

Situation Atteinte concernée Violation au sens de l'article 4(12)
Un rançongiciel chiffre la base clients, aucune exfiltration constatée Disponibilité, intégrité si les données sont altérées Oui
Un export de la liste des adhérents part au mauvais destinataire Confidentialité Oui
Un portable non chiffré contenant des dossiers RH est volé Confidentialité Oui
Un bug d'affichage montre le dossier d'un client à un autre client Confidentialité Oui
La seule copie d'un fichier de contacts est effacée par erreur Disponibilité Oui
Une coupure rend le CRM injoignable deux heures, sans perte de données Disponibilité, temporaire Oui par définition, l'appréciation du risque décide ensuite de la notification
Un serveur de test sans aucune donnée personnelle est compromis Aucune Non, incident de sécurité sans dimension RGPD

La dernière ligne mérite d'être lue à l'envers. Beaucoup d'équipes traitent la qualification comme une exception réservée aux gros incidents, alors que le vrai tri se fait sur une seule question : y a-t-il des données personnelles dans le périmètre touché ? Cette question se répond avec la cartographie des traitements, pas avec l'intuition de l'astreinte.

La violation ne suppose ni attaquant ni malveillance. Un geste maladroit, un bug d'affichage ou une sauvegarde manquante suffisent à faire entrer un incident dans le champ de l'article 33.

Les 72 heures, à partir de quand

Aux Arcades, le compteur ne démarre ni le samedi soir, quand la console est restée ouverte, ni trois semaines plus tard, quand l'analyse forensique aura livré ses conclusions définitives. Il démarre le lundi matin, quand le directeur a de bonnes raisons de penser que le fichier a bougé.

L'article 33(1) parle de notification « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance ». Tout se joue sur cette prise de connaissance.

Les lignes directrices européennes retiennent un critère praticable : le responsable de traitement est réputé avoir connaissance de la violation dès qu'il dispose d'un degré raisonnable de certitude qu'un incident de sécurité s'est produit et qu'il a compromis des données personnelles.

Ce curseur se situe entre deux positions confortables et fausses. Trop tôt, on notifierait chaque alerte SIEM non triée, y compris les faux positifs. Trop tard, on attendrait le rapport final d'investigation, ce que le règlement n'autorise pas.

Une courte phase de vérification est donc admise, le temps d'écarter le faux positif et d'établir que des données personnelles sont bien en cause. Elle doit rester brève, et elle ne se confond pas avec l'enquête complète : une fois la certitude raisonnable acquise, l'horloge tourne pendant que l'investigation continue.

Trois précisions changent la vie des équipes d'astreinte.

Les 72 heures sont calendaires. Une découverte le vendredi en fin de journée n'ouvre pas un délai jusqu'au mercredi. Le week-end et les jours fériés ne suspendent rien, ce qui suppose une chaîne de décision joignable hors heures ouvrées.

La notification par étapes est prévue. L'article 33(4) permet expressément de fournir les informations de manière échelonnée quand elles ne sont pas toutes disponibles. Une première notification volontairement incomplète, suivie de compléments, vaut mieux qu'un silence documenté.

Le retard doit être motivé. Au-delà des 72 heures, la notification est accompagnée des motifs du retard. Le dépassement n'entraîne pas de sanction automatique, mais il oblige à produire une justification.

Reste le cas le plus fréquent dans une architecture moderne : la violation survient chez un prestataire. L'article 33(2) impose au sous-traitant de notifier la violation au responsable de traitement dans les meilleurs délais après en avoir pris connaissance. Le responsable est alors considéré comme ayant connaissance de la violation à partir du moment où son sous-traitant l'informe, ce qui explique pourquoi les clauses de notification du contrat de sous-traitance pèsent lourd. C'est le sujet du billet suivant.

Le compteur démarre à l'instant où l'organisation acquiert une certitude raisonnable que des données personnelles sont en cause. Cet instant se date dans le ticket d'incident, au même titre qu'une heure de confinement.

Notifier l'autorité, informer les personnes

Le directeur des Arcades a deux courriers possibles à écrire, et il ne les écrit pas dans les mêmes cas. L'un part vers l'autorité de contrôle. L'autre part vers les quarante mille porteurs de carte, et celui-là ne s'envoie pas à la légère.

L'article 33 pose la notification à l'autorité comme le principe, avec une exception rédigée en double négation : elle n'est pas exigée si la violation n'est pas susceptible d'engendrer un risque pour les droits et libertés des personnes physiques. Autrement dit, le doute penche vers la notification.

L'article 34 vise l'autre destinataire, et relève le seuil : l'information des personnes concernées est due lorsque la violation est susceptible d'engendrer un risque élevé pour leurs droits et libertés.

Entre les deux, il y a une appréciation du risque, et elle ne se fait pas au jugé. Les lignes directrices européennes énumèrent notamment les facteurs à peser : le type de violation, la nature et le volume des données, la facilité avec laquelle les personnes peuvent être identifiées, la gravité des conséquences possibles, les caractéristiques particulières des personnes touchées (des mineurs, des patients) et leur nombre.

Destinataire Seuil Délai Contenu attendu
Autorité de contrôle, art. 33 Sauf si la violation n'est pas susceptible d'engendrer un risque 72 h après la prise de connaissance, motifs du retard au-delà Nature de la violation, catégories et nombre approximatif de personnes et d'enregistrements, point de contact, conséquences probables, mesures prises ou proposées
Personnes concernées, art. 34 Risque élevé pour les droits et libertés Dans les meilleurs délais Description en termes clairs et simples, point de contact, conséquences probables, mesures prises
Registre interne, art. 33(5) Toutes les violations, notifiées ou non En continu Faits, effets, mesures correctives, et justification de la décision

L'article 34(3) prévoit trois cas où l'information individuelle n'est pas requise. Le premier intéresse directement les équipes techniques : quand le responsable a mis en œuvre des mesures de protection appropriées qui rendent les données incompréhensibles pour toute personne non autorisée, le chiffrement étant l'exemple cité par le texte lui-même.

C'est probablement l'argument opérationnel le plus solide en faveur du chiffrement au repos, et il est rarement présenté ainsi. Une base volée mais chiffrée, dont les clés n'ont pas été compromises, change la nature de la conversation qui suit. La mécanique du chiffrement a été traitée dans la série, avec cette réserve constante : l'algorithme ne vaut que ce que vaut la gestion des clés.

Les deux autres dispenses tiennent aux mesures ultérieures qui font disparaître le risque élevé, et à l'effort disproportionné. Dans ce second cas, le texte prévoit une communication publique d'effet équivalent plutôt qu'un envoi individuel.

flowchart TD A["Incident de sécurité constaté"] --> B{"Des données personnelles sont-elles touchées ?"} B -->|"Non"| C["Incident traité par le seul playbook du SOC"] B -->|"Oui"| D["Violation au sens de l'article 4(12)"] D --> E{"Risque pour les droits et libertés ?"} E -->|"Peu probable"| F["Pas de notification
décision motivée"] E -->|"Oui"| G["Notification à l'autorité sous 72 h
article 33"] G --> H{"Risque élevé ?"} H -->|"Non"| I["Information individuelle non requise"] H -->|"Oui"| J{"Dispense de l'article 34(3) applicable ?"} J -->|"Oui"| K["Pas d'information individuelle
justification conservée"] J -->|"Non"| L["Information des personnes concernées
article 34"] F --> M["Inscription au registre des violations
article 33(5)"] I --> M K --> M L --> M classDef entree fill:#ede9e1,stroke:#b5651d,color:#1a1a1a classDef question fill:#d89253,stroke:#8a4d16,color:#1a1a1a classDef action fill:#b5651d,stroke:#8a4d16,color:#f5f2ec classDef final fill:#2c3338,stroke:#1f2428,color:#f5f2ec class A,C,D entree class B,E,H,J question class F,G,I,K,L action class M final
Notifier l'autorité est le principe, informer les personnes est l'exception réservée au risque élevé. Une information massive et injustifiée n'est pas une précaution neutre : elle inquiète sans réduire le risque.

Le registre interne des violations

Aux Arcades, la main courante du PC sécurité ne consigne pas seulement les intrusions avérées. Elle note aussi la porte de secours trouvée ouverte à 3 heures du matin, l'inspection qui a suivi, et la conclusion selon laquelle rien n'avait bougé. Cette ligne-là est celle qui sert le jour où quelqu'un demande des comptes.

L'article 33(5) impose la même logique. Le responsable de traitement documente toute violation, en précisant les faits, les effets et les mesures correctives prises. Le texte le dit explicitement : cette documentation permet à l'autorité de contrôle de vérifier le respect de l'article.

La conséquence est contre-intuitive. Les violations qui ne sont pas notifiées sont celles qui doivent être documentées avec le plus de soin, puisque le registre est le seul endroit où la décision de ne pas notifier s'explique. Les lignes directrices européennes recommandent d'y consigner le raisonnement suivi, au-delà des trois éléments listés par l'article.

Un registre utile ressemble davantage à une structure de données qu'à un classeur.

# Entrée type d'un registre interne des violations, article 33(5)
id: "VIOL-2026-014"
detecte_le: "2026-03-11T02:47:00Z"          # première alerte SIEM
prise_de_connaissance_le: "2026-03-11T09:20:00Z"  # départ des 72 heures
source: "règle SIEM, exfiltration volumétrique sortante"
nature: "accès non autorisé à une base de réservation"
atteinte: ["confidentialité"]
categories_de_donnees: ["identité", "coordonnées", "historique d'achat"]
personnes_concernees_estimees: 12400
consequences_probables: "usurpation d'identité, hameçonnage ciblé"
mesures:
  - "révocation des clés API exposées"
  - "isolation du serveur et reconstruction depuis une image saine"
  - "réinitialisation des sessions actives"
notification_autorite: true
notification_autorite_le: "2026-03-12T16:05:00Z"
information_personnes: false
justification: "données chiffrées au repos, clés non compromises"  # art. 34(3)(a)
reexamen_le: "2026-04-15"

Deux champs valent la peine d'être défendus en revue. L'écart entre detecte_le et prise_de_connaissance_le, qui matérialise la phase de vérification et se justifie. Et justification, qui transforme une non-notification en décision tracée plutôt qu'en oubli.

Le schéma ci-dessous replace ces gestes dans la chronologie réelle d'un incident, du signalement jusqu'au registre.

sequenceDiagram participant ST as "Sous-traitant" participant SOC as "SOC" participant RT as "Responsable de traitement" participant DPO as "DPO" participant AC as "Autorité de contrôle" participant PC as "Personnes concernées" ST->>RT: "Signalement dans les meilleurs délais" SOC->>RT: "Alerte triée et confirmée" RT->>DPO: "Saisine et analyse du risque" DPO-->>RT: "Avis sur la qualification" Note over RT: "Prise de connaissance horodatée" Note over RT,AC: "Départ du délai de 72 heures" RT->>AC: "Notification initiale" SOC-->>RT: "Résultats de l'investigation" RT->>AC: "Compléments par étapes" RT->>PC: "Information si le risque est élevé" RT->>RT: "Inscription au registre des violations"
Le registre n'est pas une formalité posée après coup. C'est la seule preuve que les violations non notifiées ont été examinées plutôt qu'ignorées.

Une étape du playbook, pas un processus parallèle

Une erreur d'organisation fréquente consiste à mener deux réponses en même temps. D'un côté le SOC, qui confine et éradique. De l'autre le juridique, qui découvre l'incident au troisième jour et réclame des éléments que personne n'a pensé à conserver.

Le cycle de réponse à incident décrit dans le billet CTI, IOC et réponse à incident prévoit une phase de détection et d'analyse dont la mission est précisément de qualifier. La qualification RGPD est une case de cette phase, au même titre que l'évaluation de la portée technique.

Concrètement, cela veut dire trois ajouts au playbook existant, et aucun processus nouveau : une question « des données personnelles sont-elles concernées ? » dans le formulaire de triage, un champ d'horodatage de la prise de connaissance, et un contact d'astreinte côté DPO au même titre que l'astreinte système.

Horloge Point de départ Échéance Qui la porte
Réponse à incident Détection de l'alerte Confinement puis éradication, mesurés en MTTR, le MTTD couvrant l'amont SOC et cellule de crise
RGPD, art. 33 Prise de connaissance de la violation 72 heures pour notifier l'autorité Responsable de traitement, appuyé par le DPO
NIS2, art. 23, pour les entités concernées Prise de connaissance de l'incident significatif Alerte précoce sous 24 heures, notification sous 72 heures Entité essentielle ou importante

Les trois horloges lisent les mêmes faits et démarrent à des instants différents. Un SOC qui ne connaît que la première produit mécaniquement du retard sur les deux autres.

Un dernier point d'organisation, souvent découvert au pire moment : pour un traitement transfrontalier, le règlement organise un mécanisme de guichet unique, où l'autorité chef de file (art. 56) coordonne la procédure avec les autres autorités concernées. Savoir à quelle autorité on s'adresse fait partie de la préparation, pas de l'improvisation du jour J.

La conformité ne se rattrape pas à froid. Si la qualification RGPD n'est pas une case du playbook, elle arrivera systématiquement après le délai.

Scénario réel : Marriott et les quatre ans de Starwood

Le 30 octobre 2020, l'autorité britannique de protection des données, l'ICO, a prononcé une amende de 18,4 millions de livres contre Marriott International pour n'avoir pas protégé de manière appropriée les données personnelles de ses clients. Les faits résumés ici proviennent de cette décision publique, l'ICO ayant agi comme autorité chef de file pour ce dossier transfrontalier.

La chronologie est le vrai sujet du dossier.

Les systèmes de réservation du groupe hôtelier Starwood ont été compromis en 2014. Marriott a racheté Starwood en 2016, et la base de réservation de la marque acquise a continué de fonctionner. La compromission n'a été découverte qu'en septembre 2018, quand un outil de sécurité interne a signalé une requête anormale sur cette base. Marriott a rendu l'affaire publique le 30 novembre 2018.

L'ICO a retenu que la compromission concernait environ 339 millions d'enregistrements clients au niveau mondial, dont de l'ordre de 30 millions rattachés à des résidents de l'Espace économique européen. Le RGPD n'étant applicable qu'à partir du 25 mai 2018, la sanction n'a couvert que la période postérieure à cette date, ce qui explique en partie l'écart avec le montant très supérieur envisagé dans l'avis d'intention de 2019.

Deux lectures intéressent directement ce billet.

Le délai de détection se comptait en années. Entre 2014 et septembre 2018, aucune horloge n'a démarré, pour une raison simple : personne ne savait. Les 72 heures de l'article 33 ne protègent de rien si le MTTD se mesure en trimestres. Le point de départ du délai suppose une détection qui fonctionne, et c'est bien pour cela que ce billet porte le domaine Détection & réponse.

Le risque était hérité. Marriott n'a pas créé la compromission, elle l'a achetée avec Starwood. L'ICO a notamment relevé l'insuffisance des mesures de sécurité appliquées à l'environnement acquis. Reprendre un système d'information, comme confier un traitement à un prestataire, revient à reprendre son passif de sécurité. Ce fil se prolonge dans le billet suivant, consacré à la due diligence des sous-traitants.

Une nuance mérite d'être posée pour ne pas surinterpréter le cas. La sanction portait sur le défaut de mesures techniques et organisationnelles appropriées, pas sur un retard de notification. La chronologie reste néanmoins l'illustration la plus nette de l'écart entre un premier signal, en septembre 2018, et la certitude raisonnable qui fait courir le délai. L'ICO avait sanctionné le même mois un autre grand dossier RGPD, celui de British Airways, déjà raconté dans le billet sur la conformité.

Marriott rappelle une hiérarchie simple : notifier vite est une obligation, mais détecter reste la condition préalable. Une violation ignorée pendant quatre ans ne déclenche aucun compteur.

Points clés

  • Une violation au sens de l'article 4(12) peut être accidentelle, et couvre les atteintes à la confidentialité, à l'intégrité et à la disponibilité : un rançongiciel sans exfiltration ou un courriel mal adressé en sont.
  • Les 72 heures de l'article 33 partent de la prise de connaissance, c'est-à-dire d'un degré raisonnable de certitude, ni du premier signal faible ni de la fin de l'investigation. Elles sont calendaires.
  • Deux seuils distincts : on notifie l'autorité sauf risque improbable, on informe les personnes seulement en cas de risque élevé, avec les dispenses de l'article 34(3) dont le chiffrement rendant les données incompréhensibles.
  • L'article 33(5) impose un registre interne couvrant toutes les violations, y compris celles qu'on a choisi de ne pas notifier, avec la justification de ce choix.
  • La qualification RGPD est une étape du playbook de réponse à incident. Le cas Marriott montre qu'un délai de détection de plusieurs années rend la question du délai de notification secondaire.

Dans la série

Palier 3 : Tenir la galerie. Domaine : Détection & réponse.

Pour aller plus loin