Compétence RGPD en Ingénierie

Référence RGPD actionnelle pour les ingénieurs, architectes, DevOps et tech leads. Inspirée par les lignes directrices CNIL et les Articles 5, 25, 32, 33, 35 du RGPD.

Règle d'or : Collecter moins. Stocker moins. Exposer moins. Conserver moins.

Pour des approfondissements, consultez les fichiers de référence dans references/:

• references/data-rights.md — endpoints de droits utilisateurs, workflow DSR, RoPA
• references/security.md — chiffrement, hachage, secrets, anonymisation
• references/operations.md — cloud, CI/CD, incident response, patterns d'architecture

1. Principes fondamentaux du RGPD (Article 5)

2. Protection des données par la conception et par défaut

DOIT

• Ajouter CreatedAt, RetentionExpiresAt à chaque table contenant des données personnelles au moment de la création.
• Paramétrer par défaut toute collecte de données optionnelle sur désactivé. Les utilisateurs acceptent explicitement ; ils n'acceptent jamais un paramètre activé par défaut.
• Effectuer une DPIA avant de construire un traitement à haut risque (biométrie, données de santé, profilage à grande échelle, surveillance systématique).
• Mettre à jour la RoPA avec chaque nouvelle fonctionnalité introduisant une activité de traitement.
• Signer une DPA avec chaque sous-traitant avant que les données ne circulent vers lui.

NE DOIT PAS

• Livrer une nouvelle fonctionnalité de collecte de données sans une base légale documentée.
• Activer l'analytique, le suivi ou la télémétrie par défaut sans consentement explicite.
• Stocker des données personnelles dans un système non listé dans la RoPA.

3. Minimisation des données

DOIT

• Mapper chaque champ DTO/modèle à un besoin métier concret. Supprimer les champs non documentés.
• Utiliser des DTOs distincts pour la création, la lecture et la mise à jour — ne jamais réutiliser le même objet.
• Retourner uniquement ce que l'appelant est autorisé à voir — utiliser des projections de réponse.
• Masquer les valeurs sensibles à la périphérie : retourner ****1234 pour les numéros de carte, jamais la valeur complète.
• Exclure les champs sensibles (date de naissance, numéro d'identité national, santé) des projections par défaut de liste/recherche.

NE DOIT PAS

• Enregistrer les corps de requête/réponse complets s'ils peuvent contenir des données personnelles.
• Inclure des données personnelles dans les segments de chemin URL ou les paramètres de requête (logs CDN, historique du navigateur).
• Collecter dateOfBirth, numéro d'identité national ou données de santé sans une base légale explicite.

4. Limitation des finalités

DOIT

• Documenter la finalité de chaque activité de traitement dans les commentaires du code et dans la RoPA.
• Obtenir une nouvelle base légale ou effectuer une analyse de compatibilité avant de réutiliser les données à une finalité secondaire.

NE DOIT PAS

• Partager les données personnelles collectées pour la fourniture de services avec des réseaux publicitaires sans consentement explicite.
• Utiliser le contenu des tickets de support pour entraîner des modèles ML sans une base légale distincte et un avis utilisateur.

5. Limitation de la conservation et rétention

DOIT

• Chaque table contenant des données personnelles DOIT avoir une période de rétention définie.
• Appliquer la rétention automatiquement via un travail planifié (Hangfire, cron) — jamais un processus manuel.
• Anonymiser ou supprimer les données à l'expiration de la rétention — ne jamais laisser les données expirées silencieusement en production.

Durées par défaut recommandées

DEVRAIT

• Ajouter une colonne RetentionExpiresAt — calculer au moment de l'insertion.
• Utiliser la suppression logicielle (DeletedAt) avec une suppression physique planifiée après la fenêtre de demande d'effacement (30 jours).

NE DOIT PAS

• Conserver les données personnelles indéfiniment « au cas où elles deviendraient utiles plus tard ».

6. Règles de conception des API

DOIT

• NE DOIT PAS inclure de données personnelles dans les chemins URL ou les paramètres de requête.
  • GET /users/{userId}
• Authentifier tous les endpoints retournant ou acceptant des données personnelles.
• Extraire l'identité de l'utilisateur agissant du JWT — jamais du corps de la requête.
• Valider la propriété sur chaque ressource : if (resource.OwnerId != currentUserId) return 403.
• Utiliser des UUIDs ou des identifiants opaques — jamais des entiers séquentiels comme IDs de ressource publics.

DEVRAIT

• Appliquer un rate limiting aux endpoints sensibles (connexion, export de données, réinitialisation de mot de passe).
• Définir Referrer-Policy: no-referrer et une allowlist CORS explicite.

NE DOIT PAS

• Retourner des stack traces, des chemins internes ou des erreurs de base de données dans les réponses API.
• Utiliser Access-Control-Allow-Origin: * sur les APIs authentifiées.

7. Règles de journalisation

DOIT

• Anonymiser les IPs dans les logs d'application — masquer le dernier octet (IPv4) ou les 80 derniers bits (IPv6).
  • 192.168.1.xxx
• NE DOIT PAS journaliser : mots de passe, tokens, IDs de session, credentials, numéros de carte, numéros d'identité national, données de santé.
• NE DOIT PAS journaliser les corps de requête/réponse complets où des DPI peuvent être présents.
• Appliquer la rétention des logs — purger automatiquement après la période définie.

DEVRAIT

• Journaliser des événements et non des données : "User {UserId} updated email" et non "Email changed from a@b.com to c@d.com".
• Utiliser la journalisation structurée (JSON) avec userId comme identifiant interne, pas l'adresse e-mail.
• Séparer les logs d'audit (accès sensible, actions administratives) des logs d'application — rétention et ACLs différentes.

8. Gestion des erreurs

DOIT

• Retourner des messages d'erreur génériques — ne jamais exposer des stack traces, des chemins internes ou des erreurs DB.
  • "Column 'email' violates unique constraint on table 'users'"
  • "A user with this email address already exists."
• Utiliser Problem Details (RFC 7807) pour toutes les réponses d'erreur.
• Journaliser l'erreur complet côté serveur avec un ID de corrélation ; retourner uniquement l'ID de corrélation au client.

NE DOIT PAS

• Inclure les chemins de fichiers, les noms de classes ou les numéros de ligne dans les réponses d'erreur.
• Inclure les données personnelles dans les messages d'erreur (p. ex., « User john@example.com not found »).

9. Chiffrement (résumé — voir references/security.md pour les détails complets)

NE DOIT PAS autoriser TLS 1.0/1.1, des suites de chiffrement null ou des clés de chiffrement codées en dur.

10. Hachage des mots de passe

DOIT

• Utiliser Argon2id (recommandé) ou bcrypt (cost ≥ 12). Jamais MD5, SHA-1 ou SHA-256.
• Utiliser un salt unique par mot de passe. Stocker uniquement le hachage.

NE DOIT PAS

• Journaliser les mots de passe sous quelque forme que ce soit. Transmettre les mots de passe dans les URLs. Stocker les tokens de réinitialisation en texte clair.

11. Gestion des secrets

DOIT

• Stocker tous les secrets dans un KMS : Azure Key Vault, AWS Secrets Manager, GCP Secret Manager ou HashiCorp Vault.
• Utiliser des hooks pre-commit (gitleaks, detect-secrets) pour prévenir les commits de secrets.
• Rotation des secrets lors du départ des développeurs, selon un calendrier annuel ou après une suspicion de compromission.

.gitignore DOIT inclure : .env, .env.*, *.pem, *.key, *.pfx, *.p12, secrets/

NE DOIT PAS

• Commiter des secrets dans le code source. Stocker des secrets comme valeurs par défaut de variable d'environnement en texte clair.

12. Anonymisation et pseudonymisation (résumé — voir references/security.md)

• Anonymisation = irréversible → sort du scope du RGPD. Utiliser pour les enregistrements conservés après effacement.
• Pseudonymisation = réversible avec une clé → reste des données personnelles, risque réduit.
• Lors de l'effacement d'un utilisateur, anonymiser les enregistrements qui doivent être conservés (finance, audit) plutôt que de les supprimer.
• Stocker la clé de pseudonymisation dans le KMS — jamais dans la même base de données que les données pseudonymisées.

NE DOIT PAS appeler les données « anonymisées » si une ré-identification est possible via des attaques par chaînage.

13. Tests avec données fictives

DOIT

• NE DOIT PAS utiliser de données personnelles de production en dev, staging ou CI.
• NE DOIT PAS restaurer les sauvegardes DB de production en non-production sans scrubbing des DPI au préalable.
• Utiliser des générateurs de données synthétiques : Bogus (.NET), Faker (JS/Python/Ruby).
• Utiliser @example.com pour toutes les adresses e-mail de test.

14. Anti-patterns

15. Checklist de révision de PR

Modèle de données

• Chaque nouvelle colonne DPI a une finalité documentée et une période de rétention.
• Les champs sensibles (santé, finance, numéro d'identité national) utilisent le chiffrement au niveau colonne.
• Pas de PKs entiers séquentiels comme identifiants publics.

API

• Pas de DPI dans les chemins URL ou les paramètres de requête.
• Tous les endpoints retournant des données personnelles sont authentifiés.
• Contrôles de propriété présents — l'utilisateur ne peut pas accéder à la ressource d'un autre utilisateur.
• Rate limiting appliqué aux endpoints sensibles.

Journalisation

• Pas de mots de passe, tokens ou credentials journalisés.
• IPs anonymisées (dernier octet masqué).
• Pas de corps de requête/réponse complets journalisés où des DPI peuvent être présents.

Infrastructure

• Pas de buckets de stockage publics ou de bases de données avec IP publique.
• Nouvelles ressources cloud marquées avec DataClassification.
• Chiffrement au repos activé pour les nouvelles ressources de stockage.
• Les nouvelles régions géographiques pour le stockage de données sont conformes à l'EEA ou couvertes par des SCC.

Secrets et CI/CD

• Pas de secrets dans le code source ou les fichiers de config committés.
• Nouveaux secrets ajoutés au KMS et au document d'inventaire des secrets.
• Secrets CI/CD masqués dans les logs du pipeline.

Rétention et effacement

• Le travail ou la politique d'application de la rétention couvre le nouveau magasin de données ou le nouveau champ.
• Le pipeline d'effacement mis à jour pour couvrir le nouveau magasin de données.

Droits des utilisateurs et gouvernance

• L'endpoint d'export de données inclut tout nouveau champ de données personnelles.
• RoPA mise à jour si le changement introduit une nouvelle activité de traitement.
• Nouveaux sous-traitants avec une DPA signée et une entrée RoPA.
• DPIA déclenchée si le changement implique un traitement à haut risque.

Règle d'or : Collecter moins. Stocker moins. Exposer moins. Conserver moins.

Chaque octet de données personnelles que vous ne collectez pas est un octet que vous ne pouvez pas perdre, que vous ne pouvez pas compromettre et pour lequel vous ne pouvez pas être tenu responsable.

Inspiré par les lignes directrices RGPD CNIL pour les développeurs, les Articles 5, 25, 32, 33, 35 du RGPD, ENISA, OWASP et les bonnes pratiques d'ingénierie NIST.