RGPD pour développeurs juniors.

Pourquoi le RGPD vous concerne, vous, développeur

De quoi parle-t-on, concrètement ?

Le RGPD (Règlement Général sur la Protection des Données) est un texte européen entré en application le 25 mai 2018. Il encadre la manière dont toute organisation collecte, stocke, traite et partage des données personnelles concernant des résidents de l'Union européenne.

En tant que développeur, vous êtes en première ligne : c'est vous qui écrivez le code qui collecte un email, qui décide de conserver une adresse IP dans un log, ou qui choisit comment hacher un mot de passe. Une grande partie des manquements RGPD trouvent leur origine dans des choix techniques faits à votre niveau.

Qu'est-ce qu'une donnée personnelle ?

Une donnée personnelle est toute information se rapportant à une personne physique identifiée ou identifiable. Le périmètre est volontairement large :

• Identifiants directs — nom, prénom, email, numéro de téléphone, photo, voix
• Identifiants techniques — adresse IP, identifiant publicitaire, cookie ID, MAC address, empreinte (fingerprint) du navigateur
• Données combinées — un code postal + une date de naissance + un genre suffit souvent à identifier quelqu'un de manière unique
• Données comportementales — historique de navigation, géolocalisation, habitudes d'achat

Les données sensibles : protection renforcée

Certaines données dites « sensibles » bénéficient d'une protection renforcée. Leur traitement est en principe interdit, sauf exceptions strictes :

• Origine raciale ou ethnique, opinions politiques, convictions religieuses ou philosophiques
• Appartenance syndicale, données génétiques ou biométriques (empreinte digitale, reconnaissance faciale)
• Données concernant la santé, la vie sexuelle ou l'orientation sexuelle

Les sanctions : un risque très concret

Les sanctions RGPD ne sont pas théoriques. La CNIL et ses homologues européens prononcent régulièrement des amendes très lourdes :

Les plafonds prévus par l'article 83 du RGPD sont :

• Jusqu'à 10 M€ ou 2 % du CA mondial — manquements moins graves (registre, sécurité, sous-traitance…)
• Jusqu'à 20 M€ ou 4 % du CA mondial — manquements graves (principes fondamentaux, droits des personnes, transferts internationaux…)

C'est toujours le montant le plus élevé entre la somme fixe et le pourcentage qui est retenu.

Les 7 principes fondamentaux

L'article 5 du RGPD énonce 7 principes qui doivent guider tout traitement de données personnelles. Les connaître, c'est avoir une grille d'analyse pour chaque feature qu'on développe.

Durées de conservation : quelques repères

Les 6 bases légales

Tout traitement doit reposer sur l'une des 6 bases légales prévues à l'article 6. Sans base légale, le traitement est illicite — c'est aussi simple que cela.

Le consentement : 4 critères de validité

Pour qu'un consentement soit valable au sens du RGPD, il doit cumuler 4 caractéristiques :

Par ailleurs, le consentement doit pouvoir être retiré aussi facilement qu'il a été donné, et le responsable de traitement doit pouvoir prouver l'avoir obtenu (article 7).

Les droits des personnes

Les personnes dont vous traitez les données disposent d'un ensemble de droits. En tant que développeur, vous serez vraisemblablement amené à implémenter les fonctionnalités permettant d'exercer ces droits. Mieux vaut les concevoir dès le départ que les bricoler plus tard.

Délai de réponse : 1 mois en principe, extensible à 3 mois pour les demandes complexes (article 12.3). La première copie de données est gratuite.

Implémenter le droit d'accès : checklist technique

1. Identifier tous les endroits où sont stockées les données de l'utilisateur (BDD principale, BDD analytics, logs, fichiers, caches Redis, exports S3, sauvegardes)
2. Construire un endpoint authentifié de type GET /me/export qui renvoie un fichier structuré (JSON ou ZIP)
3. Y inclure également les données dérivées : préférences, scores, segments marketing
4. Documenter les destinataires : à qui ont été transmises ces données (sous-traitants, partenaires) ?
5. Documenter les durées de conservation et la base légale pour chaque catégorie
6. Tracer la demande (qui, quand, ce qui a été fourni) pour démontrer la conformité

Droit à l'effacement : les pièges à connaître

Pensez aussi aux copies parallèles qu'on oublie souvent :

• Sauvegardes de la base de données (politique de rétention claire)
• Caches applicatifs (Redis, Memcached)
• Logs applicatifs et logs d'accès
• Index de recherche (Elasticsearch, Algolia)
• Bases analytics, data warehouse, outils tiers (Mixpanel, Segment, etc.)

Privacy by Design & by Default

Article 25 du RGPD : la protection des données doit être intégrée dès la conception et par défaut. C'est probablement le chapitre le plus important pour un développeur.

Privacy by Design

On intègre la protection de la vie privée dès la phase de conception, pas après coup. Pour chaque nouvelle fonctionnalité :

• Identifier les données personnelles concernées avant d'écrire la première ligne de code
• Se demander quelle est la finalité, la base légale et la durée de conservation
• Concevoir le schéma de données en minimisant la collecte
• Anticiper la mise en œuvre des droits (export, suppression)

Privacy by Default

Les paramètres par défaut doivent être les plus protecteurs de la vie privée. La personne doit faire un acte volontaire pour partager davantage.

Pseudonymisation vs Anonymisation

Deux notions souvent confondues, mais aux conséquences très différentes.

Pseudonymisation

Remplacer des identifiants directs par un pseudonyme, mais conserver la possibilité de réidentifier la personne (via une clé, une table de correspondance). Les données pseudonymisées restent des données personnelles soumises au RGPD.

// Exemple de pseudonymisation
const userId = uuid.v4();                            // identifiant interne
const userEmailHash = sha256(email + secretSalt);    // pseudo
// La table users contient encore l'email en clair quelque part
// → réversible → pseudonymisation, pas anonymisation

Anonymisation

Rendre la réidentification impossible, même en croisant avec d'autres jeux de données. Les données anonymisées sortent du périmètre RGPD. Techniques principales :

• Agrégation statistique sur de grands ensembles
• k-anonymat (chaque enregistrement est indistinguable d'au moins k-1 autres)
• Généralisation et suppression des quasi-identifiants
• Confidentialité différentielle (differential privacy)

Sécurité technique

L'article 32 impose des « mesures techniques et organisationnelles appropriées ». Le RGPD n'impose pas de technologies précises mais évalue la pertinence des mesures par rapport au risque. Voici les pratiques de base que tout dev doit maîtriser.

Authentification et mots de passe

• Ne JAMAIS stocker un mot de passe en clair, ni en chiffrement réversible
• Utiliser un hachage adapté aux mots de passe : Argon2id (préféré), bcrypt, scrypt
• Ne jamais utiliser MD5 ou SHA-1/SHA-256 seul pour des mots de passe (trop rapides, vulnérables au brute-force GPU)
• Politique raisonnable (recommandations CNIL 2022) : 12 caractères mini sans complexité forcée, ou 8 + MFA
• Mettre en place une authentification multi-facteur sur les comptes sensibles
• Limiter les tentatives de connexion (rate limiting + verrouillage temporaire)

// ✅ Bonne pratique : Argon2id en Node.js
const argon2 = require('argon2');
const hash = await argon2.hash(password, { type: argon2.argon2id });
const valid = await argon2.verify(hash, attempt);

// ❌ À ne JAMAIS faire
const hash = crypto.createHash('md5').update(password).digest('hex');
const hash = crypto.createHash('sha256').update(password).digest('hex');

Chiffrement

• En transit : TLS 1.2 minimum, idéalement TLS 1.3, sur tous les flux
• Au repos : disques, sauvegardes, snapshots — souvent assuré par défaut chez les principaux cloud providers, à vérifier
• Applicatif : chiffrement des champs particulièrement sensibles (santé, carte bancaire) avec gestion rigoureuse des clés (KMS, HSM)

Journalisation et logs

Les logs sont essentiels pour la sécurité, mais peuvent eux-mêmes devenir une faille RGPD.

• Ne jamais logger de mot de passe, de token de session ou de numéro de carte
• Masquer (ou hacher) les identifiants directs : email → e***@d***.com
• Définir une durée de rétention courte (généralement 6 mois à 1 an, sauf besoin spécifique)
• Restreindre l'accès aux logs aux personnes qui en ont strictement besoin

Gestion des accès

• Principe du moindre privilège : chaque compte n'a que les droits strictement nécessaires
• Pas de comptes partagés, surtout en production
• Revues d'accès périodiques (trimestrielles a minima)
• Désactivation des comptes au départ d'un collaborateur (J + 0)

Gestion des violations de données

Une violation de données personnelles (data breach) est définie largement par le RGPD : exfiltration, altération non autorisée, indisponibilité… En cas de violation :

1. Contenir l'incident (révocation d'accès, déconnexion, isolation des systèmes touchés)
2. Évaluer le risque pour les personnes concernées
3. Notifier la CNIL sous 72 heures (article 33), sauf si la violation est sans risque
4. Informer les personnes concernées si le risque est élevé (article 34)
5. Documenter la violation dans le registre interne, même si elle n'est pas notifiable

Cookies et traceurs

Le sujet des cookies est encadré par le RGPD mais aussi par la directive ePrivacy (article 82 de la loi Informatique et Libertés en France). C'est l'un des domaines où la CNIL est la plus active en matière de contrôles et de sanctions.

Quand faut-il un consentement ?

Règles d'un bandeau cookies conforme

• Aucun cookie non essentiel déposé avant le choix explicite
• Bouton « Tout refuser » présent au même niveau visuel que « Tout accepter »
• Possibilité de paramétrer finement par catégorie
• Information claire sur les finalités et les destinataires
• Durée de validité du consentement raisonnable (CNIL : 6 mois max recommandés)
• Mécanisme simple pour retirer son consentement (lien permanent dans le footer)

Sous-traitants et transferts hors UE

La sous-traitance au sens RGPD

Dès qu'un prestataire traite des données personnelles pour le compte de votre organisation, c'est un sous-traitant au sens du RGPD. Cela couvre énormément de services :

• Hébergeurs cloud : AWS, GCP, Azure, OVH, Scaleway
• Services SaaS : Google Workspace, Microsoft 365, Slack, Notion, Salesforce
• Analytics : Google Analytics, Mixpanel, Amplitude, Segment
• Messagerie / push : SendGrid, Mailgun, Twilio, OneSignal
• CRM, support : Zendesk, Intercom, outils RH

L'article 28 impose un contrat de sous-traitance (DPA — Data Processing Agreement) avec des mentions obligatoires. La plupart des grands fournisseurs proposent ce document à signer ou l'incluent directement dans leurs conditions générales.

Transferts hors Union européenne

Dès que des données sont stockées ou traitées par un acteur situé hors UE/EEE, on parle de transfert hors UE. Trois grands mécanismes permettent d'encadrer ces transferts :

Checklist du dev RGPD-compliant

Une grille pratique à dérouler pour chaque nouvelle fonctionnalité ou chaque revue de code. Pas besoin d'être DPO pour cocher ces cases.

📐 Avant d'écrire du code

• Ai-je listé toutes les données personnelles concernées ?
• Quelle est la finalité précise du traitement ?
• Sur quelle base légale je m'appuie ?
• Est-ce que je collecte strictement le nécessaire (minimisation) ?
• Quelle est la durée de conservation prévue ?
• Le traitement figure-t-il déjà au registre, ou faut-il l'y ajouter ?

⌨️ Pendant le développement

• Les paramètres par défaut sont-ils les plus protecteurs ? (privacy by default)
• Les mots de passe sont-ils hachés avec un algorithme adapté ?
• Les communications sont-elles en HTTPS / TLS ?
• Les données sensibles bénéficient-elles d'un chiffrement adapté ?
• Les logs sont-ils nettoyés des données personnelles non nécessaires ?
• Les accès à la BDD respectent-ils le moindre privilège ?
• Les sous-traitants utilisés sont-ils sous DPA ?

🚀 Avant la mise en production

• L'utilisateur est-il informé du traitement (politique de confidentialité) ?
• Les droits sont-ils accessibles : export, modification, suppression ?
• Une procédure de purge automatique respecte-t-elle les durées de conservation ?
• Une procédure de notification de violation est-elle documentée ?
• Le DPO a-t-il été consulté pour les traitements à risque élevé ?

♻️ En continu

• Revue des accès trimestrielle
• Mise à jour de la politique de confidentialité à chaque évolution significative
• Veille sur les recommandations CNIL et les sanctions récentes
• Tests de restauration des sauvegardes (intégrité)
• Pen tests / audits de sécurité périodiques sur les fonctionnalités sensibles

Pour aller plus loin

Ressources officielles

La CNIL met à disposition une mine de ressources gratuites, particulièrement pertinentes pour les développeurs :

• Guide CNIL « Sécurité des données personnelles » (mis à jour 2024)
• Guide CNIL « RGPD pour les développeurs » — exemples de code, anti-patterns
• MOOC RGPD de la CNIL, gratuit, certifiant
• Référentiels et certifications sectoriels

Lectures complémentaires

• OWASP Top 10 et OWASP ASVS pour la sécurité applicative
• ANSSI : bonnes pratiques de sécurité informatique
• ENISA : recommandations européennes en cybersécurité

Outils utiles côté technique