Chapitre 1.1 — Donnée personnelle & traitement

⏱️ TL;DR — Le RGPD se déclenche dès que deux conditions sont réunies : il y a une donnée personnelle (toute information se rapportant à une personne physique identifiée ou identifiable) et on lui fait subir un traitement (à peu près n’importe quelle opération : collecter, stocker, afficher, envoyer, supprimer). Ces deux notions sont volontairement très larges. Un e-mail, une adresse IP, un identifiant de cookie, un simple prénom + classe suffisent. Savoir les repérer, c’est savoir quand le RGPD s’applique — c’est-à-dire presque tout le temps quand on développe une app.

🎯 Objectifs

• Définir une donnée personnelle et reconnaître les cas indirects.
• Comprendre pourquoi une adresse IP ou un identifiant technique en est une.
• Définir un traitement et voir qu’il englobe quasiment toute opération.
• Distinguer anonymisation (sort du RGPD) et pseudonymisation (reste dedans).

Une donnée personnelle : plus large que tu ne crois

Le RGPD (art. 4) définit une donnée à caractère personnel comme toute information se rapportant à une personne physique identifiée ou identifiable. Décortiquons :

• Toute information : un nom, mais aussi une photo, une voix, un résultat d’examen, une géolocalisation, un historique d’achats, un comportement de navigation.
• Personne physique : un être humain vivant. Pas une entreprise (les données d’une société ne sont pas « personnelles »), pas une personne décédée (règles spécifiques en France).
• Identifiée ou identifiable : c’est le point clé. Une personne est identifiable si on peut la reconnaître directement (son nom) ou indirectement — en croisant plusieurs informations, ou via un identifiant (numéro client, e-mail, identifiant de cookie, adresse IP).

C’est ce « indirectement » qui piège les devs. Tu crois manipuler des données « anonymes », mais si un recoupement raisonnable permet de remonter à une personne, ce sont des données personnelles.

⚠️ Piège — « On ne stocke pas les noms, juste un ID technique, donc c’est anonyme. » Faux. Un identifiant qui permet de retrouver ou de distinguer une personne (même sans son nom) est une donnée personnelle. Un user_id relié à un compte, un identifiant d’appareil, un cookie : tout ça est pseudonyme, pas anonyme (on y revient plus bas).

📚 Le texte — La définition est à l’article 4.1 du RGPD. Pour l’adresse IP, la CJUE a tranché dès 2016 (arrêt Breyer, C-582/14) : une IP, même dynamique, est une donnée personnelle pour qui dispose de moyens légaux de l’associer à un abonné.

Un traitement : presque tout ce que fait ton code

Deuxième notion, tout aussi large. Un traitement (art. 4.2) est toute opération appliquée à des données personnelles : collecte, enregistrement, organisation, structuration, conservation, adaptation, extraction, consultation, utilisation, communication, diffusion, rapprochement, limitation, effacement, destruction.

Traduit en langage de dev, un traitement c’est :

• un INSERT en base quand un utilisateur s’inscrit (collecte + enregistrement),
• un SELECT qui affiche un profil (consultation + utilisation),
• un e-mail transactionnel envoyé via un prestataire (communication),
• un export CSV pour l’équipe support (extraction),
• un log applicatif qui enregistre l’IP et l’e-mail (enregistrement),
• un DELETE de compte (effacement).

Autrement dit : dès que ton application touche à des données personnelles, elle réalise un traitement, et le RGPD s’applique. Il n’y a pas besoin d’un « gros fichier » ou d’un « algorithme » : afficher une liste d’élèves est déjà un traitement.

// Chacune de ces lignes est un « traitement » au sens du RGPD.
await db.users.create({ email, nom, classe })          // collecte
const profil = await db.users.findUnique({ where: { id } }) // consultation
await mailer.send(email, "Bienvenue")                  // communication (via sous-traitant)
logger.info(`login ${email} depuis ${req.ip}`)         // enregistrement (⚠️ e-mail + IP dans les logs)
await db.users.delete({ where: { id } })               // effacement

💡 Réflexe — Quand tu conçois une fonctionnalité, pose-toi la question à voix haute : « Est-ce que je manipule une donnée qui se rapporte à une personne ? » Si oui — et c’est presque toujours oui — tu es dans le champ du RGPD, et les bons réflexes (finalité claire, minimisation, durée de conservation) doivent s’appliquer dès cette ligne de code, pas après.

Anonymisation vs pseudonymisation : la nuance qui change tout

Deux mots qu’on confond en permanence, alors qu’ils ont des conséquences juridiques opposées.

• Anonymisation : le lien avec la personne est définitivement rompu, de façon irréversible, sans aucun moyen raisonnable de le reconstituer. Une donnée vraiment anonyme sort du RGPD (ce n’est plus une donnée personnelle). Exemple : une statistique agrégée « âge moyen des stagiaires : 34 ans » sur un grand échantillon.
• Pseudonymisation : on remplace les identifiants directs par un pseudonyme (un user_id, un hash), mais une table de correspondance ou une clé permet encore de remonter à la personne. La donnée reste personnelle et reste dans le RGPD — c’est juste une mesure de sécurité (encouragée par l’art. 32), pas une sortie de route.

La vraie anonymisation est difficile : il suffit souvent de quelques attributs (code postal + date de naissance + sexe) pour ré-identifier quelqu’un dans un jeu « anonymisé ». Ne qualifie jamais des données d’« anonymes » à la légère.

🧭 Sur FormaCampus — La plateforme stocke, pour chaque apprenant, un user_id, un e-mail, une classe (ou un organisme), et des résultats de quiz. Tout ça est personnel — le user_id est pseudonyme, pas anonyme, puisqu’une table users fait le lien. En revanche, le tableau de bord « taux de réussite moyen par module » affiché au formateur, calculé sur des dizaines d’apprenants, peut être considéré comme anonyme s’il ne permet pas d’isoler un individu. Cette distinction guidera plus tard nos durées de conservation et nos exports.

🔒 Côté personne concernée — Pour un parent d’élève, « donnée personnelle » n’a rien d’abstrait : c’est le prénom de son enfant, ses notes, ses absences, son adresse, parfois un aménagement de handicap. Il attend, légitimement, que ces informations ne servent qu’à ce pour quoi il les a confiées à l’école — pas à alimenter une pub ou un profil commercial. Le RGPD, c’est d’abord ça : sa confiance.

✏️ Exercices

Exercice 1 — Personnelle ou pas ? Pour chaque élément, dis si c’est une donnée personnelle et pourquoi : (a) l’e-mail contact@mairie.fr (adresse générique), (b) l’identifiant de session d’un utilisateur connecté, (c) « nombre de connexions aujourd’hui : 1 240 », (d) une photo de classe.

Exercice 2 — Repère les traitements. Dans une page de profil d’élève qui (1) charge ses infos depuis la base, (2) affiche sa moyenne, (3) propose un bouton « exporter en PDF », (4) envoie un e-mail au parent, combien de traitements identifies-tu ?

🧠 Quiz de révision

Chapitre suivant : Histoire & champ d’application — d’où vient le RGPD, et jusqu’où (et jusqu’à qui) il s’applique, même hors d’Europe.