Privacy by Design

Privacy by Design (GDPR)

1) De quoi il s'agit et pourquoi

Privacy by Design (PbD) est le principe selon lequel la vie privée est placée dans le produit dès le début : dans les exigences commerciales, l'architecture, le code, les processus et l'exploitation. En termes de RGPD, cela se traduit par « privacy by design and by default » (minimisation des frais, paramètres par défaut - le plus privé possible, transparence et responsabilité).

• Minimiser la collecte et le traitement des données personnelles (PDn).
• Garantir la légalité, la transparence, l'exactitude, la limitation des objectifs et des délais.
• Réduisez les risques (techniques et juridiques), simplifiez l'audit et prouvez la conformité.

2) Rôles, bases juridiques et principes du RGPD

2. 1 Rôles

Contrôleur (Controller) : définit les objectifs/moyens de traitement.
Processeur (Processeur) : traite le PDn au nom du contrôleur en vertu du contrat DPA.
Personne concernée (Sujet de données) : le physique auquel appartient le PDn.
DPO (Data Protection Officer) : sur demande - contrôle et consultation indépendants.

2. 2 Bases juridiques (nous choisissons et documentons)

Consentement, contrat, intérêt légitime, obligation légale, intérêts vitaux, tâche publique. Pour chacun, le but, les données, la rétention, la possibilité de révocation (pour consentement).

2. 3 Principes de traitement (art. 5)

Légalité, équité, transparence

Limitation de l'objectif

Minimisation des données

Précision

Limitation du stockage

Intégrité et confidentialité

Responsabilité (comptabilité) - capacité de prouver la conformité.

3) Processus PbD dans SDLC (cadre de référence)

1. Initiation : formulation des finalités du traitement et des bases juridiques, désignation des owner's de données et DPO point.
2. Cartographie des données (Data Mapping) : Les sources des champs → → le modèle de confiance → où → qui lit → où sont stockés → temps.
3. Évaluation des risques/DPIA : Modèle LINDDUN des menaces à la vie privée, évaluation d'impact, mesures de réduction.
4. Solutions architecturales : choix des schémas de minimisation, de pseudonyme, de chiffrement, de délimitation.
5. Exigences UX/consentements/notifications : textes compréhensibles, consentement granular, configuration par défaut.
6. Réalisation : défauts privés, télémétrie sécurisée, logging sans secrets/PII.
7. Vérification : tests de confidentialité, analyses statiques, tests unitaires privés, protocoles DPIA.
8. Fonctionnement : processus DSAR, retences et suppressions, surveillance des incidents, hurlements des fournisseurs.
9. Révision régulière : re-DPIA lorsque les objectifs/technologies changent.

4) Modèles d'ingénierie PbD

4. 1 Minimisation et décomposition

Collecter uniquement les champs nécessaires ; appliquer un profilage progressif.
Séparez l'ID et le contenu : conservez la clé de communication séparément (token/référence).

4. 2 Pseudonyme et anonymisation

Pseudonyme : conservez l'ID réel séparément ; la couche de travail voit le token.
Anonymisation : utiliser k-anonymat, l-diversité, t-closeness ; pour l'analyse, la vie privée différentielle (ε-budget).

4. 3 Contrôle d'accès et répartition des rôles

PoLP, ABAC/RBAC, segmentation de duties, circuits séparés pour les admins et les analystes.
Ceux-là. mesures : mTLS, SSO/OIDC, jetons scopés, comptes temporaires pour l'accès au PDn.

4. 4 Cryptage et isolation

In Transit: TLS 1. 3/mTLS; At Rest: AEAD/Envelope + KMS/HSM.
Clés séparées par locataire/datacet ; crypto-suppression pour le « droit à l'oubli ».

4. 5 Rétention et élimination

Politiques explicites de TTL par champ/objectif ; auto-purge en piplines ; suppression « biphasée » (logique → physique).
Pour les backaps - clés séparées et fenêtres courtes de stockage des snapshots personnels.

4. 6 Télémétrie et logage privés

Par défaut, sans PII ; utiliser des jetons/hachage avec du sel.
Masquage/Tokénisation des champs sensibles sur le fournisseur.

4. 7 UX vie privée et consentement

Conseil granulaire par catégorie (analyse, marketing, personnalisation).
« Défauts privés » : tout n'est pas critique - éteint jusqu'à ce qu'il soit d'accord.
Option claire « Révoquer le consentement » et notification just-in-time lors d'une nouvelle utilisation.

5) DPIA et LINDDUN (court)

DPIA (Data Protection Impact Assessment) : requis à haut risque (surveillance à grande échelle, évaluation, nouvelle technologie). Se compose d'une description du traitement, de la nécessité/proportionnalité, de l'évaluation des risques, des mesures de réduction.
LINDDUN угрозы: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Pour chaque menace, des contre-mesures (minimisation, pseudonyme, DP, transparence, gestion du consentement, audit).

6) Transferts transfrontaliers

Trouver les emplacements de stockage/accès des fournisseurs.
Utiliser les CCN (clauses contractuelles standard) et effectuer l'évaluation d'impact Transfer.
Techniques : cryptage de bout en bout, cryptographie client pour les données particulièrement sensibles, limitation de l'accès à distance.

7) Fournisseurs et processeurs (Vendor Management)

DPA/processeurs imbriqués, mesures techniques et organisationnelles, sous-processeurs - sous contrôle.
Revues et audits réguliers ; le droit d'inspection ; plan de sortie/migration (data export).

8) Droits des personnes concernées (DSAR)

Accès, rectification, suppression, limitation, portabilité, opposition, ne pas faire l'objet d'un AADM (profilage/automatisation).
SLA et automatisation : suivi des demandes, preuve d'identification, journal des réponses.
Mouchoirs techniques dans le produit : recherche rapide et exportation par ID ; retrait en cascade par rétentions.

9) Décisions automatisées et profilage (art. 22)

Si les décisions avec un « impact significatif » sont prises par un automate - assurer le droit à l'intervention humaine, l'explication, la transparence des signes.
Le chemin d'accès et la version des modèles ; mécanisme d'appel.

10) Sécurité du traitement (art. 32) et incidents (art. 33/34)

Mesures axées sur les risques : cryptage, intégrité, résilience, plans de rétablissement (RTO/RPO).
Les incidents avec ПДн : le procès de la détection → триаж → l'estimation du risque → l'avis du régulateur ≤ de 72 heures (où il faut) et les sujets (si un haut risque).
Playbook séparé, liste de contact DPO/avocats, modèles de notification.

11) Vie privée et ML/analytique

Jeux de données Governance : Datline, licences/fondations, consentements.
Techniques : Privacy différentielle, federated learning, secure aggregation, minimisation des fiches.
Protection contre les attaques : membre/model inversion - estimations régulières des fuites, réglage des ε, bruit/clip.
Données synthétiques - seulement avec la vérification de l'absence de récupération des personnes.

12) Schémas architecturaux (modèles)

12. 1 Architecture d'ID « à deux circuits »

Boucle A (PDS - Personal Data Store) : données d'identification réelles (RED), accès - strictement limité, clés/cryptage/audit.
Boucle B (Operational) : données commerciales avec tokens ; communications par l'intermédiaire d'un courtier en tokens avec limites et audit.

12. 2 Bus de consentement (Consent Service)

Service centralisé qui stocke les versions de consentement et l'historique.
SDK : 'can _ use (category, purpose)' - décide à la volée ; tout est logé.

12. 3 Politiques de rétroaction en tant que code

Configuration YAML : entité de champ → → TTL → action à l'expiration (anonymisation/suppression/suppression).
Le planificateur exécute job's, le rapport est disponible par le DPO.

13) Mini recettes

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14) Documentation et responsabilité

ROPA (Records of Processing Activities) est un registre des opérations : objectif, base juridique, catégories de données/entités, transferts, durées de conservation, mesures.
Politiques : vie privée, cookies, notifications dans le produit (en langage clair).
Formation du personnel et revues annuelles.

15) Erreurs fréquentes

Collecte « au cas où » et stockage « pour toujours ».
Le consentement est le seul motif, bien que le contrat/intérêt légitime convient.
Bannières de cookies « vides » sans interrupteurs réels.
Manque de cartographie des données et manque de préparation au DSAR.
Logs avec PII, backups non protégés, mélange de RED et de données d'exploitation.
Il n'y a pas de contrôle des fournisseurs et des transferts transfrontaliers.

16) Chèques-feuilles

• L'objet du traitement et la base juridique ont été définis ; mise à jour du ROPA.
• La cartographie des données et la DPIA (si nécessaire) ont été effectuées.
• Mise en œuvre de la minimisation, de la pseudonymisation, du cryptage (en route/au repos).
• Consentements - granulaires, avec UX compréhensible ; les défauts sont privés.
• Configuré les politiques de rétroaction comme code ; suppression/anonymisation vérifiée.
• Logi/télémétrie - sans PII ; le masquage est activé.
• DSAR-hooks et exportations préparés.
• Formation de l'équipe et approbation du DPO.

• Examen trimestriel des retraits et des bases juridiques.
• Audit périodique des processeurs/sous-processeurs.
• Surveillance des incidents et préparation à la notification ≤ 72 h.
• Révision de la DPIA en cas d'évolution des processus/technologies.
• Stockage des artefacts de conformité (DPIA, ROPA, rapports d'essai).

17) FAQ

Q : Est-il possible de « fuir » complètement les consentements ?
R : Parfois, oui (contrat/obligation légale/intérêt légitime), mais seulement si nécessaire et avec une évaluation de l'équilibre des intérêts. Le marketing et l'analyse non critique exigent le plus souvent le consentement.

Q : La pseudonymisation est-elle suffisante ?
R : Non, c'est toujours des données personnelles. Pour quitter le domaine du RGPD, il faut une anonymisation fiable (vérifiable pour ne pas pouvoir être réidentifié).

Q : Comment faire avec ML et personnalisation ?
R : Réduisez les fiches, utilisez des approches DP/fédérées, logiez les solutions, assurez-vous que vous avez le droit d'intervenir et de refuser le profilage.

Q : Que faire en cas de conflit entre affaires et vie privée ?
R : Redéfinir la collecte (profilage progressif), passer aux agrégats/synthétiques, réévaluer la base juridique, offrir une option sans tracking.

• « Gestion des secrets »
• Cryptage At Rest
• Cryptage In Transit
• Audit et journaux invariables
• Signature et vérification des demandes
• Gestion des clés et rotation