Gestion des consentements

1) Termes et limites de responsabilité

Consentement (consent) : volonté volontaire, éclairée, concrète et sans ambiguïté ; peut être retiré.
Base juridique : le consentement n'est qu'une option (contrat, base légale, intérêt légitime, etc.). Le modèle doit stocker à la fois la base et le but.
But du traitement (purpose) : cause atomique : analytique, personalisation, ads, email_marketing, data_sharing_vendor_X.
Granularité : les consentements sont stockés par objectifs, canaux, fournisseurs, régions, catégories de données.
Profil du sujet : personne, appareil, ménage, compte de l'enfant (règles spéciales pour les mineurs).

2) Cycle de vie du consentement

1. Collecte : bannière/SMR, paramètres de profil, API/SDK, canal hors ligne (centre de contact).
2. Validation : âge, région, disponibilité des alternatives (pas de « patterns sombres »).
3. Inscription : créez un événement de consentement et un instantané actuel des états pour les fins.
4. Diffusion : publication sur le bus d'événements, mise à jour des caches sur edge, synchronisation avec les vendeurs.
5. Exécution : application en temps réel (passerelles/pixels/SDK), en batch (ETL/analytique), en piplines ML.
6. Modification/révocation : interdiction immédiate d'une nouvelle collecte/activation, suivi d'un « nettoyage » des données historiques sur la politique.
7. Audit/rapport : preuve du consentement au moment du traitement (qui, quand, quelle version du texte).

3) Composants architecturaux

CMP (Consent Management Platform) : UI/SDK + API, formatage des options de consentement sous UX/juridiction ; source de vérité sur les textes et les versions.
Consent Registry (registre) : stockage fiable des états et événements de consonnes (journal append-only + projection à jour).
Consent PDP/PEP: Policy Decision/Enforcement Point. PDP décide "est-il possible ? ", PEP applique la solution sur la passerelle API, dans ETL, dans le SDK, etc.
Cache de consentement Edge : faible latence pour la vérification sur le périmètre.
Passerelle Partner/GPP/IAB : traduction des cibles locales en signaux partenaires et inversement.
Data Lineage & Tagging : marquage des données avec des drapeaux de consentement/de base tout au long de la chaîne.

4) Modèle de données (schémas)

json
{
"subject_id": "usr_123",
"subject_scope": "user",
"region": "EU",
"legal_basis": {
"analytics": "consent",
"personalization": "consent",
"security": "legitimate_interest",
"contract_core": "contract"
},
"purposes": {
"analytics": {"status": "granted", "version": "v5", "updated_at": "2025-10-31T13:20:10Z"},
"personalization": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"ads": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"email_marketing": {"status": "granted", "channel":"email","updated_at":"2025-10-31T13:22:05Z"}
},
"text_bundle": {"locale":"uk-UA","policy_version":"2025-09"},
"evidence": {"capture_ip":"203. 0. 113. 5","capture_ua":"Chrome/142"}
}

json
{
"event_id": "cse_987",
"subject_id": "usr_123",
"purpose": "personalization",
"previous": "denied",
"current": "granted",
"legal_basis": "consent",
"policy_version": "2025-09",
"captured_at": "2025-10-31T13:21:31Z",
"channel": "web",
"evidence": {
"banner_id": "cmp_v3",
"text_hash": "sha256:...",
"ip": "203. 0. 113. 5",
"ua": "Chrome/142",
"locale": "uk-UA"
}
}

5) Protocoles de signaux et diffusion

Web/App/SDK : stockage du marqueur de consentement (cookie/stockage local/stockage sécurisé) + signature/vérification de l'intégrité ; Auto-resink à l'identifiant.
Côté serveur : headers 'X-Consent-Token '/' X-Purposes', échange bidirectionnel avec le rendu SSR/edge.
Partenaires/fournisseurs : traduction dans leurs formats (vecteur cible, signal commun « GPP/TCF », par exemple) ; en cas de panne, signal zéro/mode limité.
Canal hors ligne : Enregistrement de l'audio-accord/checkbox par l'opérateur, suivi de la vérification et de la liaison à 'subject _ id'.

6) Exécution : où et comment le trafic est « coupé »

• Bloquer les endpoints/champs sans consentement (/profile/enrich ,/ads/,/events/track).
• Muter réponse/demande : couper les trackers, les champs de personnalisation, les identifiants.
• Attribuer un contexte de consentement à une requête backend (marques JWT ou en-têtes individuels).

• Le transformateur d'événements supprime/masque les champs par indicateur de consentement.
• Marquage des datacets : 'dataset. consent_scope=analytics:granted; ads:denied`.
• Les enregistrements sans consentements appropriés sont exclus dans la pipline ML ; la formation/activation à des fins interdites est désactivée.

7) Pseudo-code : solution sur la passerelle

python def enforce_consent(request, consent_snapshot):
purpose = map_endpoint_to_purpose(request. path) # /ads/ -> "ads"
basis  = consent_snapshot. legal_basis. get(purpose)
status = consent_snapshot. purposes. get(purpose, {}). get("status", "denied")

if basis! = "consent": # e.g. security/contract - allowed without return ALLOW banner

if status!= "granted":
return DENY # or ALLOW with redaction if degradation is allowed

return ALLOW

8) Versioning et prouvabilité

Version du texte de consentement : stockez 'policy _ version', 'text _ hash', 'banner _ id'.
Local et région : quel texte et dans quelle langue est montré.
Image au moment du traitement : possibilité de répondre "Pourquoi la publicité a-t-elle été affichée 2025-10-15 à 09:03 ? ».
Journal immuable : WORM/append-only avec crypto-écriture d'événements.

9) Cas spéciaux

Mineurs : validation de l'âge, consentement parental, objectifs individuels et délais.
Invité → login : fusion d'un marqueur anonyme avec un compte ; les règles en cas de conflit (le plus strict gagne).
Multi-structure : récépissé cohérent ; en cas de rappel, l'invalidité push des tokens sur tous les appareils.
Régimes régionaux : « rigoureux » (EU) vs « opt-out » (certains marchés) - commutation des presets CMP.
Essais A/B : les expériences sur les données sont un objectif distinct de l'expérience ; sans elle, seulement des tests fonctionnels sans données personnelles.
Droit de suppression : la révocation peut déclencher la suppression/anonymisation des données historiques par finalité (politique « purge on revoke »).

10) Anti-modèles

Un checkbox « général » pour tout.
L'absence de versions des textes et la probabilité de l'affichage.
Ne stocker que le cookie drapeau sans registre du serveur.
Application du consentement uniquement dans l'IU, mais pas dans l'ETL/ML/exportations.
Sources de vérité conflictuelles (SDK ≠ backend).
Dark patterns, l'imposition du consentement : risques juridiques et de réputation.

11) Observabilité et métriques

Coverage : part du trafic avec le marqueur de consentement validé.
Latency PDP : temps de décision sur le périmètre.
Drift : incohérence entre le SDK et le snapshot serveur.
Revoke SLA : temps de rappel → temps de désactivation/nettoyage complet.
Conformité Vendor : pourcentage d'appels partenaires avec un signal correct.
Incidents : tentatives de traitement sans consentement, appels bloqués.

Dashboards : « entonnoirs d'accord », carte des régions/canaux, cartes thermiques des pannes.

12) Test et vérification

Tests contractuels PDP/PEP : tableau de vérité par combinaison d'objectifs/régions.
Tests Chaos/Drift : États SDK non synchronisés ↔ le serveur ; l'expiration du cache TTL.
Communiqués du CMP : Validation A/B des textes et neutralité de l'UX (pas de patterns sombres).
E2E-trassirovka : l'événement user-revoke → l'absence de l'expédition aux pixels de partenariat et пайплайны.

13) Capacités interconnectées

Anonymisation/pseudonymisation : exécution des refus avant et après impersonnalisation.
Cryptage et KMS : protection des marqueurs/journaux.
Géo-routage : sélection de textes/règles régionaux.
Observabilité : dashboards privés sans PDn ; corrélation uniquement par tokens.
Data Lineage : chaque date est l'empreinte des consonnes.

14) Mini recettes

yaml purposes:
analytics:
legal_basis: consent enforcement: redact_fields: [ad_id, gaid, idfa]
personalization:
legal_basis: consent enforcement: deny_endpoints: [/recs/, /profile/enrich]
security:
legal_basis: legitimate_interest enforcement: allow email_marketing:
legal_basis: consent channel: email

event. meta. consent. analytics = granted    denied event. meta. consent. ads    = denied event. meta. legal_basis    = consent    contract    li

on user_revoke(purpose):
mark subject_id + purpose as "purge_pending"
schedule purge jobs over datasets with lineage(purpose)
emit audit_event("purge_started", scope=purpose)

15) Chèque de l'architecte

1. Y a-t-il un registre unique et un journal de consentement immuable ?
2. Y a-t-il des cibles atomiques et des versioniums partout ?
3. L'exécution est sur le périmètre, dans les flux, dans l'analyse et dans le ML ?
4. Mise en œuvre de la politique de révocation et de nettoyage des données historiques ?
5. Accord sur les snapshots/SDK/serveurs et les mécanismes de récupération ?
6. Des métriques et des rapports Coverage/Drift/Revoke SLA personnalisés ?
7. Y a-t-il un runbook sur les incidents (violations, plaintes, régulateur) ?
8. Régimes spéciaux soutenus (enfants, régions, partenaires B2B) ?

Conclusion

La gestion du consentement n'est pas une fenêtre modale, mais une fonction architecturale de bout en bout : de la déclaration des objectifs et de la versioning des textes à l'exécution automatique des décisions en temps réel et aux rapports ultérieurs. Un modèle de données rigoureux, un registre unique, un PDP/PEP sur toutes les couches, une télémétrie complète et des procédures de nettoyage transforment la conformité en un avantage concurrentiel - une plate-forme de confiance.