Chapitre 10.1 — Qu’est-ce qu’une violation

⏱️ TL;DR — Une violation de données (art. 4.12) n’est pas « un piratage ». C’est toute atteinte à la sécurité qui entraîne, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée ou l’accès non autorisé à des données personnelles. Trois familles à retenir : atteinte à la confidentialité (quelqu’un voit ce qu’il ne devrait pas), à l’intégrité (les données sont altérées) et à la disponibilité (on perd l’accès aux données). Un e-mail parti au mauvais destinataire, un ordinateur volé, une suppression accidentelle, une base publiquement exposée, un ransomware : tout ça compte. Savoir reconnaître une violation est la première marche — on ne notifie bien que ce qu’on a d’abord su nommer.

🎯 Objectifs

• Connaître la définition exacte de l’article 4.12 et ses cinq verbes.
• Classer un incident dans les 3 types : confidentialité, intégrité, disponibilité.
• Reconnaître une violation au-delà de la cyberattaque (erreur humaine, perte, panne).
• Distinguer un incident de sécurité d’une violation de données personnelles.

La définition, mot à mot (art. 4.12)

Le RGPD définit une « violation de données à caractère personnel » 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.

Décortiquons, parce que chaque morceau élargit le champ :

• « violation de la sécurité » — il faut une atteinte aux mesures de l’article 32 (celles de la Partie 9). Pas de sécurité franchie, pas de violation.
• « accidentelle ou illicite » — c’est LE point que tout le monde rate. Une violation n’a pas besoin d’être malveillante. Un Ctrl+A malheureux, un mauvais destinataire, une panne de disque non sauvegardé : accidentel, mais bien une violation.
• cinq verbes — destruction, perte, altération, divulgation, accès. Il suffit d’un seul pour qu’il y ait violation.

⚠️ Piège — Croire qu’une violation, c’est forcément « un hacker ». La majorité des violations notifiées à la CNIL sont des erreurs internes ordinaires : un e-mail avec le mauvais fichier joint, un colis d’archives égaré, une mauvaise configuration de droits, une clé USB perdue. Attendre « la cyberattaque » pour déclencher ta procédure, c’est ignorer 80 % des cas réels — ceux qui arrivent dans ton équipe, un mardi après-midi.

Les 3 types d’atteinte

Tout revient à trois propriétés de la sécurité — la triade CID. Sache classer, parce que le type oriente déjà l’évaluation du risque (Partie 10.2) et la réaction.

Une même violation peut cumuler plusieurs types. Un ransomware, par exemple, atteint la disponibilité (tout est chiffré, inaccessible) et souvent la confidentialité (les attaquants exfiltrent les données avant de chiffrer, pour faire chanter). Classer les deux change l’analyse du risque.

Des exemples très concrets

Pour ancrer le réflexe, voici des situations du quotidien — et le type d’atteinte associé. Aucune n’est exotique ; toutes sont des motifs fréquents de notification.

• Une base de données exposée sur Internet (bucket mal configuré, port ouvert, absence de mot de passe) → confidentialité. Classique et redoutable : personne n’a « piraté », la porte était juste ouverte.
• Un ransomware chiffre les serveurs → disponibilité (accès perdu) + souvent confidentialité (exfiltration).
• Un e-mail au mauvais destinataire, avec une pièce jointe contenant des données personnelles → confidentialité. La violation la plus banale — et l’une des plus notifiées.
• Un ordinateur portable ou un téléphone volé, non chiffré, avec des données personnelles → confidentialité (si le disque est chiffré, le risque chute — on y revient en 10.4).
• Une suppression accidentelle de données sans sauvegarde exploitable → disponibilité (et perte définitive).
• Une mauvaise attribution de droits : un utilisateur voit les données d’un autre à cause d’un bug d’autorisation → confidentialité.

💡 Réflexe — Ne te demande pas « est-ce qu’on nous a attaqués ? » mais « est-ce qu’une donnée personnelle a pu être vue, perdue, altérée ou rendue indisponible, prévu ou non ? ». Si la réponse est oui — même par ta propre faute, même sans intention — tu tiens une violation, et l’horloge des procédures commence à tourner. Le doute se tranche en faveur de la qualification : mieux vaut analyser une fausse alerte que rater une vraie.

Incident de sécurité n’est pas toujours violation de données

Nuance utile : tout incident de sécurité n’est pas une violation de données personnelles. Un serveur web vitrine qui tombe cinq minutes, sans qu’aucune donnée personnelle ne soit touchée, est un incident de disponibilité — mais s’il ne portait aucune donnée personnelle, ce n’est pas une violation au sens du RGPD. Le test : des données personnelles sont-elles concernées ? Si non, c’est un problème d’exploitation ; si oui, tu bascules dans la procédure violation.

Inversement, une violation de données n’exige aucun préjudice réel pour exister. La divulgation possible suffit à qualifier la violation ; la question du préjudice relève de l’étape suivante (le risque, chapitre 10.2), pas de la définition.

🧭 Sur FormaCampus — Les scénarios de violation ne manquent pas : un formateur qui envoie la liste d’émargement d’un groupe au mauvais organisme (confidentialité), un bug d’autorisation qui laisse un parent voir les notes d’un autre enfant (confidentialité), un ransomware sur le LMS qui bloque les cours en pleine session (disponibilité), une migration ratée qui écrase les dossiers de stagiaires sans sauvegarde (disponibilité), un stagiaire malveillant qui modifie ses propres résultats (intégrité). Et le cas d’école, celui qu’on traitera au playbook (10.5) : un export CSV d’élèves envoyé par erreur au mauvais parent. Aucun « hacker » — et pourtant, à chaque fois, une vraie violation.

📚 Le texte — La définition est à l’article 4, point 12 du RGPD. Elle se lit avec l’article 32 (la sécurité, dont la violation déclenche tout) et prépare les articles 33 et 34 (notifier, informer). Le CEPD a publié des lignes directrices sur les notifications de violation avec une typologie confidentialité / intégrité / disponibilité et de nombreux exemples : c’est la référence à consulter pour classer un cas réel.

✏️ Exercices

Exercice 1 — Violation ou pas ? Pour chaque situation, dis s’il s’agit d’une violation de données personnelles au sens de l’art. 4.12, et pourquoi : (a) un développeur pousse par erreur un fichier .env avec des identifiants de base clients sur un dépôt public ; (b) le site vitrine (sans aucune donnée personnelle) est inaccessible 10 minutes suite à une panne ; (c) un salarié perd un téléphone professionnel chiffré contenant des e-mails de stagiaires.

Exercice 2 — Classe l’atteinte. Range chaque incident dans le bon type (confidentialité / intégrité / disponibilité), et signale ceux qui en cumulent plusieurs : (a) ransomware avec exfiltration ; (b) suppression accidentelle d’une table sans sauvegarde ; (c) un stagiaire modifie frauduleusement ses notes ; (d) une newsletter envoyée en cc au lieu de cci, exposant 2 000 e-mails.

Exercice 3 — Le réflexe accidentel. Un dirigeant te dit : « On n’a pas été piratés, donc pas besoin de procédure violation. » Réponds-lui en une phrase, en t’appuyant sur le texte.

🧠 Quiz de révision

Chapitre suivant : Qualifier le risque — une fois la violation reconnue, tout se joue sur une question : quel est le risque pour les personnes ? C’est lui qui décide si tu dois notifier la CNIL, informer les gens, ou seulement journaliser.