Les enregistrements de consentement et de préférence comme données : ce qui a été choisi, quand et par quelle voie

Ce que c'est

Un enregistrement de préférence est un fait en ajout seul : quelle personne ou quel appareil, quelle finalité, quel choix (accepté, refusé, retiré), à quel moment, par quelle voie (version de bannière, page de paramètres, appel d'API, signal de protocole), et quelle version du texte a été présentée. L'état courant est dérivé du dernier enregistrement par sujet et par finalité ; ce n'est pas un booléen sur la ligne utilisateur. Certains choix arrivent sous forme de signaux de protocole : le brouillon de l'éditeur du Global Privacy Control (W3C Privacy Working Group) définit un champ d'en-tête de requête Sec-GPC dont la valeur est 1, ainsi qu'une propriété DOM correspondante, qui transmet au site la préférence d'une personne. Une application traite un tel signal comme une entrée supplémentaire de l'enregistrement, en notant sa source ; ce qu'un site doit faire en réponse sort du cadre de cet article.

Pourquoi c'est important

Deux questions surgissent plus tard et exigent toutes deux un historique : « qu'avait choisi cette personne au moment où cet e-mail a été envoyé ? » et « quels utilisateurs ont été touchés par le bug de bannière entre les versions 4 et 5 ? ». Un booléen ne répond à aucune des deux. Les systèmes en aval (envoi d'e-mails, pipeline analytique, gestionnaire de balises) ont besoin d'une requête peu coûteuse et sans ambiguïté, et une revue d'incident a besoin de la séquence des événements.

Comment l'appliquer

• Table preference_events(subject_id, purpose, choice, recorded_at, source, text_version, evidence) ; horodatages en UTC au format RFC 3339 ; les lignes ne sont jamais mises à jour ni supprimées, sauf dans le cadre du calendrier de rétention.
• Matérialiser preference_current par (sujet, finalité) via un déclencheur ou une tâche périodique, et ne laisser chaque consommateur lire que cette vue.
• Énumérer les finalités comme des constantes au niveau du code ; une nouvelle finalité est un nouvel enregistrement, jamais l'extension implicite d'un ancien.
• Stocker avec l'événement l'identifiant ou le hachage du texte vu par la personne, afin qu'un changement de formulation reste visible dans les données.
• Appliquer la préférence au moment de l'usage : la tâche d'envoi de mails vérifie preference_current au moment de l'envoi, pas au moment de la mise en file.
• Propager les retraits vers les tiers via un événement d'outbox avec relances, et consigner l'accusé de réception comme un événement supplémentaire.

Pièges

Des valeurs par défaut enregistrées comme s'il s'agissait de choix. Des choix stockés uniquement dans un cookie qui disparaît avec le navigateur. Des finalités couplées au point que « marketing » recouvre trois choses différentes. Aucun index sur (subject_id, purpose, recorded_at DESC). Des consommateurs qui mettent le booléen en cache pendant des heures. La suppression de l'historique des événements lors de la suppression d'un compte, sans conserver l'enregistrement minimal nécessaire pour honorer ensuite un refus.