Privacy by Design Architecture

Problème

La confidentialité est traitée comme une contrainte légale après-coup plutôt que comme une décision d'architecture.

Solution

Patterns d'architecture privacy-compliant intégrés dès le design.

1. Data Classification System

enum DataCategory {
  PUBLIC = 'public',
  INTERNAL = 'internal',
  PERSONAL = 'personal',
  SENSITIVE = 'sensitive',
  FINANCIAL = 'financial',
  CREDENTIALS = 'credentials'
}

enum RetentionPeriod {
  SESSION = 'session',
  THIRTY_DAYS = '30d',
  ONE_YEAR = '1y',
  THREE_YEARS = '3y',
  SEVEN_YEARS = '7y',
  INDEFINITE = 'indefinite'
}

interface DataFieldDefinition {
  field: string
  category: DataCategory
  purpose: string
  legalBasis: 'consent' | 'contract' | 'legal_obligation' | 'legitimate_interest'
  retention: RetentionPeriod
  encrypted: boolean
  pseudonymizable: boolean
  exportable: boolean
  erasable: boolean
}

2. Consent Management

• Consent = freely given, specific, informed, unambiguous, withdrawable
• Pas de pre-ticked boxes
• Opt-in par défaut (pas opt-out)
• Withdrawal aussi facile que le consentement
• Tracker le consent version pour audit

3. Data Minimization

• Chaque champ doit avoir un purpose documenté
• Si on peut atteindre le même résultat avec moins de données → utiliser moins
• Pseudonymisation pour analytics, logging, internal tooling
• Remplacer identifiants par des tokens quand le business n'a pas besoin d'identifiants réels

4. Encryption Strategy

• In transit : TLS 1.3 (minimum 1.2), HSTS, modern cipher suites
• At rest : AES-256, disk encryption + column-level pour champs sensibles
• Key management : pas juste "encryption checkbox", gestion du cycle de vie des clés
• Champs sensibles obligatoires : adresses, payment, health, national IDs

5. Retention & Deletion

• Définir retention en code et infrastructure
• Temporary doit être temporary → automated deletion
• Deleted ne doit pas persister silencieusement dans des systèmes secondaires
• Retention sur event-level data (ne pas retenir indéfiniment)
• Implémenter right-to-erasure (GDPR Article 17)

6. Logging Privacy

• Logs = shadow data store
• Ne pas logger de PII dans les application logs
• Pseudonymiser les audit trails
• Minimiser ce qui entre dans error traces et debugging tools

Quand l'utiliser

Tout projet traitant des données personnelles (ce qui représente la majorité des projets web).

Références

• [[KNOW-REF-050]] — Privacy by Design Checklist
• [[KNOW-REF-051]] — GDPR Compliance for Web Apps
• [[KNOW-PAT-220]] — Secure SDLC Checklist