Chapitre 11.2 — Privacy by design & by default (art. 25)

⏱️ TL;DR — L’article 25 pose deux obligations jumelles. Privacy by design (protection dès la conception) : tu intègres la protection des données au moment où tu conçois le traitement, pas après coup. Privacy by default (protection par défaut) : le réglage le plus protecteur doit être actif sans que la personne ait à faire quoi que ce soit — opt-in plutôt qu’opt-out, visibilité minimale, pas de cases pré-cochées. Pour un dev, ce n’est pas de la philosophie : ça se joue dans le schéma de données (minimiser les colonnes), la pseudonymisation, les durées de conservation codées, et les valeurs par défaut des formulaires et des réglages de confidentialité. On voit ici le principe et des exemples avant/après ; le code complet est en Partie 14.

🎯 Objectifs

• Distinguer by design (dès la conception) et by default (par défaut).
• Traduire l’article 25 en décisions de schéma et de réglages par défaut.
• Appliquer la minimisation, la pseudonymisation et les durées codées dès le départ.
• Reconnaître les mauvais réglages par défaut (opt-out, cases pré-cochées, visibilité maximale) et les corriger.

By design : protéger dès la conception

Privacy by design, c’est décider de la protection au moment de concevoir, quand ça ne coûte presque rien — pas six mois après, quand corriger veut dire migrer une base en production. Concrètement, avant d’écrire la première ligne d’un traitement, tu te poses les questions de la checklist des 6 principes (chapitre 1.4) : quelle finalité ? quelles données strictement nécessaires ? combien de temps ? qui y accède ?

Le résultat s’inscrit dans l’architecture :

• Minimisation dans le schéma : on ne crée que les colonnes justifiées par la finalité. Une colonne qui existe finit toujours par se remplir.
• Pseudonymisation : on sépare les identifiants directs des données de comportement, on préfère un user_id opaque à l’e-mail comme clé.
• Durées codées : la conservation n’est pas un vœu dans une politique, c’est une tâche planifiée qui purge pour de vrai.
• Cloisonnement : les données sensibles (aménagements de santé) dans une table à part, chiffrée, à accès restreint.

💡 Réflexe — Traite la protection des données comme une contrainte de conception au même titre que la performance ou la sécurité : elle se décide dans le modèle, tôt. Ajouter la minimisation ou une durée de purge après coup coûte dix fois plus cher — et laisse en attendant une base de données personnelles trop grosse, trop vieille, trop exposée.

Exemple : minimiser dans le schéma

// ❌ AVANT — « on prend tout, on verra bien »
type Inscription = {
  email: string
  nom: string
  prenom: string
  dateNaissance: Date        // pas nécessaire ici
  telephone: string          // pas nécessaire ici
  adressePostale: string     // pas nécessaire ici
  newsletterOptin: boolean = true   // case pré-cochée : interdit
}
 
// ✅ APRÈS — minimisé pour la finalité « créer un compte apprenant »
type Inscription = {
  email: string
  prenom: string
  newsletterOptin: boolean   // par défaut false, choix explicite de la personne
}

Chaque champ retiré, c’est une donnée de moins à sécuriser, à conserver, à déclarer en cas de fuite. La minimisation by design, c’est d’abord un schéma plus court.

By default : le réglage le plus protecteur, sans action

Privacy by default, c’est l’autre moitié de l’article 25, et la plus concrète pour un dev : par défaut, seules les données nécessaires à chaque finalité doivent être traitées, et le réglage le plus protecteur doit être actif d’emblée. La personne ne doit rien avoir à faire pour être protégée ; c’est l’inverse qui doit exiger une action (partager plus, se rendre visible, s’abonner).

Les règles pratiques :

Le RGPD (et la CJUE dans l’arrêt Planet49, voir chapitre 7.1) est catégorique : pas de cases pré-cochées. Un consentement doit être un acte positif clair ; un défaut coché n’est pas un choix, c’est un piège.

⚠️ Piège — Le réglage par défaut « ouvert » qu’on justifie par l’expérience utilisateur : profil public d’emblée, newsletter cochée « pour ne pas les perdre », partage activé « c’est plus pratique ». C’est exactement ce que l’article 25.2 interdit. Le défaut doit protéger la personne, pas maximiser ta collecte. Si l’utilisateur veut partager plus, il agit ; il ne doit jamais avoir à agir pour arrêter ce qu’il n’a pas demandé.

Exemple : réglages de confidentialité par défaut

// ❌ AVANT — défauts qui exposent
const reglagesParDefaut = {
  profilPublic: true,
  partagerProgressionAvecTiers: true,
  recevoirProspection: true,
}
 
// ✅ APRÈS — défauts les plus protecteurs (art. 25.2)
const reglagesParDefaut = {
  profilPublic: false,                  // privé par défaut
  partagerProgressionAvecTiers: false,  // pas de partage sans choix
  recevoirProspection: false,           // opt-in, jamais pré-coché
}

By design + durées : la conservation se code

Une durée de conservation écrite dans une politique mais jamais appliquée ne vaut rien (chapitre 1.4). By design, la durée devient un mécanisme : un champ de date de dernière activité, et une tâche planifiée qui supprime ou anonymise à l’échéance.

// Durée de conservation « codée » : purge planifiée, pas un vœu
// Exemple : anonymiser les comptes inactifs au-delà d'une durée fixée par la politique
async function purgerComptesInactifs(seuil: Date) {
  const inactifs = await db.users.findMany({
    where: { derniereActivite: { lt: seuil }, statut: "inactif" },
  })
  for (const u of inactifs) {
    await db.users.anonymize(u.id)   // casse le lien, garde l'agrégat statistique
  }
}
// Déclenché par un cron régulier — la conservation devient un fait, pas une intention.

🧭 Sur FormaCampus — On applique l’article 25 partout. By design : les aménagements de handicap (donnée de santé) vivent dans une table séparée, chiffrée, à accès journalisé — pas dans la table users. Le schéma d’inscription est minimisé (on a retiré la date de naissance et le téléphone du formulaire newsletter). Les durées sont des tâches planifiées : un compte apprenant inactif est anonymisé au terme de la durée fixée. By default : profils privés, newsletter décochée, traceurs non essentiels inactifs tant que le bandeau n’a pas recueilli le consentement. Le réglage protecteur est celui qu’on n’a pas besoin de choisir.

📚 Le texte — La protection dès la conception et par défaut est à l’article 25. Le 25.1 vise la conception (mesures techniques et organisationnelles appropriées, comme la pseudonymisation et la minimisation), le 25.2 vise les réglages par défaut (seules les données nécessaires à chaque finalité, sans action de la personne). Manquer à l’article 25 relève du premier palier de sanctions (jusqu’à 10 M€ ou 2 %, art. 83).

🔒 Côté personne concernée — Pour un élève ou un stagiaire, la privacy by default, c’est ne pas avoir à fouiller dans les réglages pour se protéger. Il ne devrait pas découvrir, un jour, que son profil était public depuis le début ou qu’il était abonné à une newsletter qu’il n’a jamais demandée. Un bon défaut, c’est une promesse tenue sans qu’il ait eu à la réclamer.

Et le code complet ?

Ce chapitre pose le principe et les réflexes ; la Partie 14 — Le RGPD dans le code descend au niveau de l’implémentation : schémas Prisma minimisés, patterns de pseudonymisation, tâches de purge, gestion des réglages de confidentialité, et l’articulation avec les modèles d’IA. Ici, retiens la règle : la protection se décide dans le modèle et dans les défauts, pas dans une couche ajoutée à la fin.

✏️ Exercices

Exercice 1 — By design ou by default ? Classe chaque mesure : (a) mettre la newsletter en case décochée ; (b) séparer les données de santé dans une table chiffrée à part ; (c) rendre les profils privés par défaut ; (d) ne pas créer de colonne telephone qui n’a pas de finalité.

Exercice 2 — Corrige les défauts. Une app arrive avec ces réglages initiaux : profil public, partage de progression activé, newsletter cochée, aucune durée de purge. Réécris-les conformément à l’article 25.2 et explique.

🧠 Quiz de révision

Chapitre suivant : L’AIPD / DPIA (art. 35) — pour certains traitements à risque élevé, documenter et concevoir protecteur ne suffit pas : il faut mener une analyse d’impact formelle. On voit quand elle est obligatoire et comment la conduire.