Privacy by Design : principes de conception

1) Pourquoi cela est nécessaire (objectif et zone)

PbD garantit que la vie privée est intégrée au produit par défaut et non « collé » sur le dessus. Pour iGaming, cela réduit les risques réglementaires (GDPR/ePrivacy/lois locales), protège les utilisateurs vulnérables, augmente la confiance et réduit le coût des incidents. Couverture : web/mobile, KYC/AML/RG, paiements, marketing/CRM, analytique/DWH, logs/ARM, partenaires/fournisseurs.

2) Sept principes (et comment les atterrir dans les opérations)

1. Proactivité, non réactivité

Threat modeling (LINDDUN/STRIDE) à l'étape discovery.
Critères de confidentialité-acceptation dans les modèles Jira/PR.

2. Vie privée par défaut

Tous les brouilleurs de marketing/personnalisation sont désactivés jusqu'à ce que vous soyez d'accord.
Collecte uniquement des identifiants « strictement nécessaires » par défaut.

3. La vie privée est intégrée dans le design

PII est stocké dans le circuit régional (data residency), control plane - sans PII.
Tokenization/pseudonyme des clés dans les événements de service.

4. Fonctionnalité complète (win-win)

Modes « analytique anonyme » et « personnalisation avec consentement ».
Égal à UX sans discrimination de ceux qui refusent le tracking.

5. Sécurité à travers le cycle de vie

Cryptage at rest/in transit ; BYOK/HYOK; segmentation des réseaux ; le secret-gestion.
Journaux WORM pour la preuve et l'audit.

6. Transparence

Des politiques courtes et un « résumé » des conditions clés ; panneau d'intimité dans le profil.
Reporting : qui/quoi/quand/pourquoi était disponible aux données.

7. Orientation utilisateur

Textes simples, pas de patterns sombres, disponibilité de WCAG AA +.
Retrait facile du consentement et canaux DSAR pratiques.

3) Rôles et RACI

DPO/Tête de conformité - Politique PbD, DPIA/TRA, contrôle des risques. (A)

Security/Infra Lead - cryptographie, accès, journaux, vendeurs. (R)

Product/UX - exigences de confidentialité dans les dattes, absence de dark patterns. (R)

Ingénierie/Architecture - Tokenization, isolation tenant/région, contrats API. (R)

Data/Analytics - convoyeurs de PII, PETs, agrégation. (R)

Legal - bases juridiques, textes et locals. (C)

Marketing/CRM - consentement/suppression, communication honnête. (R)

Audit interne - échantillons d'artefacts, CAPA. (C)

4) Classification et taxonomie des données

PII de base : nom, e-mail, téléphone, adresse, date de naissance, IP/ID de l'appareil.
PII sensibles : biométrie (selfie/vivacité), documents KYC, détails de paiement, statuts RG/SE.
Opérations : événements de jeu, logs/trajets (PII-free par défaut).
Marketing/Analytics : Cookies/SDK (d'accord).

Règles : minimisation, stockage séparé, objectif explicite et durée de conservation.

5) Cycle de vie des données (Data Lifecycle)

1. Collecte - uniquement les champs nécessaires ; CMR/consentement ; vérification de l'âge.
2. La transmission est TLS 1. 2 +/mTLS, signature webhooks, itinérance régionale.
3. Stockage - cryptage, tokenization, rotation des clés, isolation par les marchés.
4. Utilisation - RBAC/ABAC, « need-to-know », PETs pour l'analyse.
5. Échange - DPA/SCC, ensembles minimaux, canaux audités.
6. Rétention/suppression - durée par catégorie ; delete jobs en cascade ; crypto-suppression des archives.
7. Rapports/audits - logs d'accès et d'exportation, artefacts DPIA/DSAR.

6) DPIA/TRA (comment faire court)

Déclencheurs : nouvelles catégories d'IPI, catégories spéciales, nouveaux fournisseurs, transferts transfrontaliers, risques élevés de RG/biométrie.
Modèle DPIA : objectif → catégories de données → cadre juridique → flux/carte → risques → mesures (t/org) → risque résiduel → solution.
Artefacts : diagramme de flux, liste de champs, tableau des risques, protocole de négociation.

7) Modèles architecturaux PbD

Isolation Tenant/Région : ségrégation physique/logique des OBD, clés et secrets.
Control vs Data Plane : contrôle global - sans PII ; PII seulement localement.
Pipeline DE-PII : avant d'être exportée vers DWH - hachage/sel, troncature, k-anonymat/cohortage.
Tokenization Gateway : jetons au lieu des identifiants primaires dans le bus de service.
Edge sans PII : Le cache CDN/edge n'est qu'un contenu public.
Fail-Closed : inconnu 'player _ region' → l'interdiction des opérations PII.

8) Mesures techniques et normes

Cryptage : AES-256/GCM at rest ; TLS 1. 2+/1. 3; PFS.
Clés : KMS, BYOK/HYOK, rotation, accès par rôle HSM, journal des opérations clés.
Accès : RBAC/ABAC, accès JIT, rôles d'administration et d'audit séparés.
Journaux : immuables (WORM), chaînes de hachage, stockage dans la région.
DevSecOps : secrets dans Vault, SAST/DAST, linter de champs PII, tests de confidentialité dans CI.
Données de test : synthétique par défaut ; Si les données sont de l'identification et de la rétention courte.

9) PETs (Privacy-Enhancing Technologies)

Pseudonyme : Remplacement de l'ID par des tokens ; la clé-map est stockée séparément.
Anonymisation : agrégats, k- anonimnost/ℓ-diversité, bining/cochorts.
Vie privée différentielle : bruit sur les rapports, « budget privé ».
Analyse fédérée : modèles locaux, exportation uniquement de poids/agrégats.
Masquage/révision : supprimer EXIF, zipper les champs dans les documents KYC.

10) UX sans patterns sombres

Visibilité égale « Tout rejeter « /« Tout accepter « /« Personnaliser ».
Textes compréhensibles des objectifs et exemples d'utilisation des données.
Le refus de personnalisation ne nuit pas à l'expérience de base.
Panneau d'intimité en 1-2 clics de partout ; disponibilité AA +.

11) Vendeurs et transmission de données

Registre des vendeurs : juridictions DC, sous-processeurs, certification, régions de stockage, DPA/SCC/IDTA.
La politique du « recrutement minimum » : seulement les champs nécessaires, l'interdiction de la libre exportation.
Notification et révision lors du changement des emplacements/sous-processeurs.

12) Données et événements (modèle minimum)

data_asset{id, category{KYC    PCI    RG    CRM    LOG    ANON}, region, owner, retention_days, lawful_basis, pii{yes/no}}
processing_event{id, actor, purpose, lawful_basis, started_at, ended_at, records_count, export{yes/no, basis_id}}
access_log{id, subject_id_hash, actor, action{read/write/export/delete}, ts_utc, reason, ticket_id}
erasure_job{id, subject_id_hash, scope, started_at, completed_at, evidence_id}

13) KPI/KRI et dashboard PbD

Indice de minimisation PII (nombre moyen de champs PII par fiche).
Couverture de résidence (% des entrées dans la bonne région).
Taux de justification de l'exportation (combien d'exportations avec référence à la base).
DSAR SLA (exécution médiane/précision).
Tag Firing Violations (tags sans consentement).
Score d'auditabilité (% des cas avec un paquet complet d'artefacts).
Incidents/Findings (observations répétées de la vérification/de l'organisme de réglementation).

14) Chèques-feuilles

A. Avant le développement de fiches (Design)

• Les objectifs et les fondements juridiques du traitement sont définis.
• Carte de données et liste des champs marqués PII/sensibles.
• DPIA/TRA ont été exécutés ; les risques résiduels ont été acceptés.
• Un « mode anonyme » ou un mode avec un minimum de données est envisagé.

B. Avant la sortie (Build/Release)

• Secrets dans le gestionnaire, clés/cryptage configurés.
• Logs sans PII ; les événements et l'audit sont inclus.
• Les politiques régionales d'itinérance et de retraite sont actives.
• Tests : consent-gates, deny-by-default pour les tags, erasure-path.

C. Dans les opérations

• Revues trimestrielles d'accès et d'exportation.
• Surveillance des violations et des demandes transfrontalières.
• Les DSAR/suppressions sont effectuées dans les délais ; les artefacts sont conservés.

15) Modèles (inserts rapides)

A) Modèle DPIA (court)

B) Politique de minimisation des champs

C) Clause avec vendeur (engagement PbD)

D) Réponse au DSAR (extrait)

16) Erreurs fréquentes et comment les éviter

Collecte « au cas où ». → Politique de minimisation des schémas de code.
Logs bruts avec PII dans APM. → Masquage/révision sur agent, stockage local.
Global DWH avec PII. → Seulement des agrégats/pseudonymes de PII.
Pas d'artefacts DPIA/consent. → le référentiel WORM, auto-snapshots UI/textes.
Vendeurs/SDK non enregistrés. → Registre trimestriel, interdiction des connexions « grises ».

17) Plan de mise en œuvre de 30 jours

Semaine 1

1. Approuver la politique PbD et les modèles DPIA/TRA.
2. Construire une carte des données/flux par zone clé (KYC/PCI/RG/CRM/Logs).
3. Attribuer des périmètres régionaux (UE/UK/...) ; Définir un modèle de clé (BYOK/HYOK).

Semaine 2

4) Activer les convoyeurs Tokenization/de-PII et deny-by-default pour les étiquettes.
5) Orienter les WORM-revues (доступы/экспорты/consent/удаления).
6) Mettre à jour les contrats avec les fournisseurs (DPA/SCC, emplacements, sous-processeurs).

Semaine 3

7) Mettre en place des tests de confidentialité dans les IC (linter PII, screening CMP, erasure-E2E).
8) Sortie du panneau de la vie privée dans le profil ; améliorer les textes et les lieux.
9) Former les équipes (Product/Eng/Data/CS/Legal).

Semaine 4

10) Passer DPIA-revue top fich, fermer CAPA.
11) Démarrer le dashboard KPI/KRI (Residency, Exports, DSAR SLA).
12) Plan v1. 1 : diff. confidentialité pour les rapports, pipelines fédérées.

18) Sections interconnectées

GDPR : Gestion du consentement de l'utilisateur/Politique de cookies et CMP

Localisation des données par juridiction

Vérification de l'âge et filtres d'âge

AML/KYC et stockage des artefacts

Dashboard Complience & Monitoring/Regulatory Reports

Audit interne/externe et chèques d'audit

BCP/DRP/Cryptage At Rest & In Transit