Partie 14 — Le RGPD dans le code (dev & IA)
⏱️ TL;DR — Jusqu’ici on a décidé, documenté, contractualisé. Cette partie descend dans le code : comment un dev Next.js / TypeScript traduit le RGPD en schéma de données, en migrations, en tâches planifiées, en route handlers et en middleware. On modélise juste ce qu’il faut (minimisation, privacy by design, art. 25), on code la rétention et l’effacement (pas seulement en base : caches, index, sauvegardes, exports), on outille le consentement et les droits (export JSON, suppression en cascade), on assainit les logs et l’analytics, et on affronte le sujet chaud : RGPD & IA (le fournisseur de LLM est un sous-traitant, on minimise les prompts, on combine avec l’AI Act). Beaucoup de code, peu de blabla.
Le problème qu’on résout
Un dev peut connaître les six principes par cœur et livrer une application non conforme, parce que le RGPD ne se joue pas dans la politique de confidentialité mais dans le schema.prisma, dans le cron, dans le route.ts. « Être RGPD » n’est pas une case à cocher en fin de projet : c’est une suite de décisions techniques prises au moment où on écrit la table, le champ, la requête. Cette partie fait le pont — elle prend chaque principe déjà vu (minimisation, limitation de la conservation, sécurité, droits) et le transforme en artefact de code que tu peux copier, adapter et relire en revue de code. On ne réexplique pas le chiffrement et le hachage (c’est la Partie 9) : on montre comment architecturer pour que la conformité soit la voie par défaut, pas un rattrapage.
Ce que tu sauras faire à la fin de cette partie
- Modéliser un schéma qui minimise, sépare les données sensibles et pseudonymise dès la conception (privacy by design, art. 25).
- Coder une durée de conservation : champ d’expiration, tâche de purge, soft delete vs hard delete, effacement en cascade (relations, index, caches, sauvegardes).
- Outiller le consentement (registre horodaté et versionné) et les droits (route d’export JSON, route de suppression).
- Assainir tes logs (pas de PII, IP tronquées) et choisir un analytics respectueux (self-hosted / sans cookie).
- Encadrer l’usage d’un LLM : base légale, minimisation des prompts, DPA du fournisseur, prudence sur les mineurs, articulation avec l’AI Act.
Les chapitres
| # | Chapitre | En un mot |
|---|---|---|
| 14.1 | Schéma de données & minimisation | Ne modéliser que le nécessaire, séparer, pseudonymiser. |
| 14.2 | Coder la rétention & l’effacement | Dates d’expiration, purge planifiée, cascade complète. |
| 14.3 | Consentement & droits côté code | Registre de consentement, export et suppression. |
| 14.4 | Logs & analytics respectueux | Zéro PII dans les logs, mesure d’audience privacy-first. |
| 14.5 | RGPD & IA | LLM = sous-traitant, minimiser les prompts, AI Act. |
On commence : Schéma de données & minimisation.