RGPD & données personnelles

Avant de commencer

Pourquoi le RGPD te concerne (en tant que dev)

Dès que tu crées une appli qui stocke des noms, des emails, des adresses… tu manipules des données personnelles. Le RGPD (Règlement Général sur la Protection des Données) encadre strictement ce que tu as le droit d'en faire. Ce n'est pas qu'une affaire de juristes : c'est une contrainte technique qui influence ton code — ce que tu stockes, comment, combien de temps, qui peut le lire. Mal le respecter coûte très cher, et c'est au programme de l'E7 (épreuve cybersécurité).

Comment travailler ce playbook (seul)

Ce que tu sauras faire à la fin

0. Derrière la base patients

Quand la base patients de GSB est volée, ce ne sont pas des « lignes » qui fuient : ce sont des personnes réelles, avec des informations intimes.

Le vol expose GSB à trois choses, toutes organisées par le RGPD : des sanctions (par la CNIL), une obligation de prévenir les victimes, et une perte de confiance majeure. Ce playbook t'explique tout le cadre — et surtout ce qu'il change pour toi quand tu codes.

1. C'est quoi une donnée personnelle ?

Une donnée à caractère personnel (DCP) est toute information se rapportant à une personne physique identifiée ou identifiable — directement ou indirectement. Le mot clé est identifiable : même sans nom, si on peut remonter à la personne, c'est une DCP.

La donnée sensible est un sous-ensemble de la DCP (encore plus protégée). La donnée anonyme, elle, sort du RGPD — à condition que la ré-identification soit vraiment impossible.

Exemple travaillé (le modèle à suivre)

Qualifions ensemble une donnée, pour montrer le raisonnement attendu :

À toi : exercice de qualification

Range chacune de ces données de GSB dans la bonne case : direct / indirect / sensible / anonyme. Justifie en une ligne, comme dans l'exemple.

2. Pseudonymiser ≠ anonymiser

On confond souvent les deux, et l'erreur a des conséquences énormes : l'une reste soumise au RGPD, l'autre en sort. C'est LE point que les jurys adorent vérifier.

3. Le RGPD : ce que c'est, à qui ça s'applique

Le RGPD est un règlement de l'Union européenne, applicable depuis le 25 mai 2018. « Règlement » = il s'impose directement dans tous les pays de l'UE, sans loi nationale pour le transposer.

Champ d'application (qui est concerné ?)

Transferts hors UE : trois mécanismes, un choix concret

Envoyer des DCP hors de l'Union européenne — héberger sur AWS us-east-1, utiliser Mailchimp, Stripe, SendGrid… — n'est autorisé que via un mécanisme encadré :

Le RGPD repose ensuite sur deux piliers, qu'on voit dans les chapitres suivants : des principes (chap. 4) à respecter, et une base légale (chap. 5) qui justifie chaque traitement.

4. Les principes du RGPD

Tout traitement de données doit respecter ces principes. Ce sont les questions à te poser avant de stocker quoi que ce soit.

Cas travaillé : GSB face aux principes

Voilà le réflexe : pour chaque donnée, passe les principes en revue un par un.

5. Les 6 bases légales

Avant tout traitement, il faut une base légale : un fondement qui le rend licite. Beaucoup de monde croit qu'il faut toujours le consentement — faux. Le consentement n'est qu'une des 6 bases. En choisir une (et la bonne) est obligatoire.

6. Durée de conservation

Le principe « conservation limitée » dit : on ne garde pas les données pour toujours. À chaque donnée doit correspondre une durée, liée à la finalité. Passé ce délai → suppression ou archivage (accès très restreint), ou anonymisation.

7. Les acteurs : qui fait quoi ?

Le RGPD distingue trois rôles. Savoir qui est quoi détermine qui est responsable en cas de problème — une question d'examen classique.

La personne fournit ses données au responsable et exerce ses droits auprès de lui. Le responsable peut confier le traitement à un sous-traitant, encadré par un contrat. En cas de fuite, le responsable reste en première ligne.

8. Les droits des personnes

Le RGPD donne à chacun des droits sur ses données. Une organisation doit pouvoir y répondre, en général sous 1 mois et gratuitement.

Le droit d'accès, en vrai

Concrètement, une route qui rassemble TOUT ce qu'on a sur la personne et le renvoie :

// GET /mon-compte/export  — droit d'accès + portabilité
const moi   = await User.findById(req.user.id);
const frais = await Frais.find({ userId: req.user.id });
res.json({ profil: moi, frais });   // format réutilisable (JSON)

9. Obligations & la CNIL

Côté organisation, le RGPD impose des obligations, contrôlées en France par la CNIL (Commission Nationale de l'Informatique et des Libertés).

Les sanctions réelles : ce que ça coûte vraiment

Ce ne sont pas des chiffres théoriques — voici des amendes effectives prononcées sous le RGPD :

À quoi ressemble un registre des traitements ?

C'est un tableau qui décrit chaque traitement. En voici une ligne, pour GSB :

Tu en rédigeras un toi-même dans le mini-projet (chap. 13, Bonus A).

En cas de fuite : la marche à suivre

Le jour où GSB découvre le vol, l'ordre des gestes compte. Voici la procédure type :

1. Contenir : couper l'accès exploité, changer les secrets, isoler le système touché.
2. Qualifier : quelles données ? combien de personnes ? quel risque pour elles ?
3. Notifier la CNIL sous 72 h (qui, quoi, conséquences, mesures prises).
4. Informer les victimes si le risque pour elles est élevé (ici : oui, données de santé).
5. Documenter : tout consigner (l'organisation doit pouvoir prouver qu'elle a réagi).
6. Corriger la faille pour qu'elle ne se reproduise pas.

10. L'AIPD (analyse d'impact)

Pour les traitements à risque élevé, le RGPD impose une AIPD (Analyse d'Impact relative à la Protection des Données ; en anglais PIA, Privacy Impact Assessment). C'est une étude qu'on mène avant de lancer le traitement.

Les 9 critères CNIL — quand une AIPD est obligatoire

La CNIL a publié une liste de 9 types de traitements qui peuvent déclencher une AIPD. Dès que 2 critères sur 9 sont réunis, l'AIPD est obligatoire (lignes directrices CEPD et liste CNIL 2018) :

Structure d'une AIPD : les 4 questions-clés

Et si l'AIPD révèle un risque résiduel élevé ?

Si, même après toutes les mesures, le risque reste élevé, le responsable de traitement doit consulter la CNIL avant de lancer le traitement (art. 36 RGPD). La CNIL dispose alors de 8 semaines pour répondre (prolongeable de 6 semaines supplémentaires). Si elle s'y oppose → le traitement ne peut pas démarrer.

11. Le RGPD dans ton code

Pour un développeur SLAM, le RGPD se traduit en choix techniques concrets. Deux principes officiels guident tout :

1. Consentement : la case NON pré-cochée

Privacy by default = la case n'est jamais cochée d'avance. C'est à l'utilisateur de faire le geste.

<!-- MAUVAIS : case déjà cochée (consentement invalide) -->
<input type="checkbox" name="pub" checked> Recevoir des offres

<!-- BON : décochée par défaut, l'utilisateur choisit -->
<input type="checkbox" name="pub"> Recevoir des offres

2. Droit à l'oubli : soft-delete ≠ hard-delete

Beaucoup d'applis « suppriment » en posant juste un drapeau. Attention : si la donnée reste lisible, le droit à l'oubli n'est PAS respecté.

// Soft-delete : on marque, mais la donnée RESTE (insuffisant seul)
await Patient.updateOne({ _id: id }, { supprime: true });

// Hard-delete : on efface vraiment (satisfait le droit à l'oubli)
await Patient.deleteOne({ _id: id });

3. Sécurité : hasher vs chiffrer

// Mot de passe : on HASHE (irréversible, on ne le relit jamais)
const hash = await bcrypt.hash(motDePasse, 12);

// Donnée sensible qu'on doit relire : on CHIFFRE (réversible avec une clé)
const chiffre = chiffrerAES(numeroSecu, cleSecrete);

Comparaison des algorithmes de hachage

4. Injection SQL : la faille qui vole les données (GSB Ordonnances, C#)

La faille OWASP A03 (Injection) : elle survient quand on colle des données utilisateur directement dans le texte d'une requête SQL.

// DANGEREUX — concaténation directe (GSB 1A : NE JAMAIS FAIRE)
string sql = "SELECT * FROM Patient WHERE nom = '" + txtNom.Text + "'";
cmd.CommandText = sql;
// Si l'utilisateur saisit : ' OR '1'='1
// → requête résultante : SELECT * FROM Patient WHERE nom = '' OR '1'='1'
// → renvoie TOUS les patients

// BON — requête paramétrée (GSB 1A, C# ADO.NET + MySQL)
string sql = "SELECT * FROM Patient WHERE nom = @nom";
using var cmd = new MySqlCommand(sql, connexion);
cmd.Parameters.AddWithValue("@nom", txtNom.Text);  // valeur transmise séparément
using var reader = cmd.ExecuteReader();

5. Traçabilité : journaliser les accès sensibles

logger.info(`ACCES dossier patient ${id} par user ${req.user.id} le ${new Date().toISOString()}`);

6. Authentification : JWT et gestion des tokens (GSB AppliFrais)

Quand un visiteur se connecte à GSB AppliFrais, le serveur lui remet un JWT (JSON Web Token) — une carte d'identité numérique qu'il présentera à chaque requête API.

// Génération d'un access token (Node.js / jsonwebtoken)
const accessToken = jwt.sign(
  { userId: user._id, role: user.role },   // payload (données non secrètes)
  process.env.JWT_SECRET,                  // clé secrète (min. 256 bits)
  { expiresIn: '15m' }                     // expiration courte
);

// Refresh token (durée longue, stocké en BDD côté serveur)
const refreshToken = jwt.sign(
  { userId: user._id },
  process.env.JWT_REFRESH_SECRET,
  { expiresIn: '7d' }
);

12. Cookies & consentement web

Sur le web, certains cookies (et traceurs) déposés sur le navigateur de l'utilisateur servent à le pister. Le RGPD (complété par la directive « ePrivacy ») impose des règles précises — c'est le bandeau cookies que tu vois partout.

13. Mini-projet : audit RGPD

La mission

Tu audites une petite application (GSB, ou une appli que tu connais) au regard du RGPD, comme le ferait un DPO junior. Tu produis un vrai tableau d'analyse de conformité.

Étape 1 — Recenser les données

Liste toutes les données personnelles collectées par l'appli. Repère les sensibles.

Étape 2 — Pour chaque donnée, qualifier la conformité

Remplis ce tableau (une ligne par donnée) :

Étape 3 — Vérifier les droits

L'utilisateur peut-il : accéder à ses données ? les corriger ? les faire effacer ? Si non, c'est un écart à corriger.

Étape 4 — Recommander

Propose 3 améliorations concrètes (techniques et/ou organisationnelles).

Pour finir

Ton antisèche

Vérifie tes acquis

1. Qu'est-ce qu'une donnée personnelle ? Donne un exemple indirect.
2. Quelle différence entre pseudonymisation et anonymisation ? Laquelle sort du RGPD ?
3. Cite 3 principes du RGPD.
4. Cite 3 des 6 bases légales (le consentement n'est-il pas obligatoire ?).
5. Différence entre responsable de traitement et sous-traitant ?
6. Cite 3 droits des personnes.
7. Que doit faire une entreprise en cas de fuite de données ? (délai ?)
8. Cite 3 traductions techniques du RGPD dans le code.

Glossaire