Consentement, données sensibles et traçabilité

Consentement par finalité

Tout se joue à l’entrée du prospect. Il ne consent pas « aux messages » : il consent à une finalité, à une date, sur un libellé précis — et sa preuve entre avec lui.

Un prospect arrive par un formulaire, une page de préférences, un import ou un appel d’API — et il arrive avec sa preuve : la source de la collecte, l’adresse du formulaire et le libellé exact de la case cochée sont enregistrés au moment de l’acte, jamais reconstitués après coup.
Un registre d’actes en ajout seul : un acte = une finalité × un statut, avec son contexte de preuve.
Les finalités sont distinctes — prospection, mesure des ouvertures, mesure des clics, traitement d’attributs sensibles — et ne se déduisent jamais l’une de l’autre.
Un refus est conservé comme preuve, jamais appliqué à l’envers : il n’autorise rien et il ne s’efface pas.
Un retrait prend effet immédiatement : l’envoi en cours s’arrête, les segments qui en dépendent excluent le contact, les parcours dérivés le relâchent.
L’état courant par finalité et le registre complet sont lisibles par appel, et repris dans l’export du droit d’accès.

Ce que contient un acte de consentement

La finalité et le statut : accordé, refusé, retiré.
La date de l’acte, en temps universel.
La source de la collecte : formulaire, page de préférences, import, appel d’API.
Le libellé exact présenté à la personne au moment où elle a coché.
L’adresse du formulaire et, le cas échéant, l’adresse d’une preuve conservée par le responsable de traitement.

Deux pixels, deux régimes

Un e-mail peut porter deux pixels qui se ressemblent techniquement et n’ont rien à voir juridiquement. Ils ne sont jamais confondus.

	Pixel de délivrabilité	Pixel de performance
Régime	Exempté de consentement	Soumis à consentement
Inséré	Si le template l’active	Uniquement avec un consentement de suivi des ouvertures valide au moment du rendu
Ce qui est écrit	La date de dernière ouverture, à la journée, écrasée	Un événement d’ouverture et l’agrégat du jour
Jamais conservé	IP, user-agent, heure précise, historique	IP, user-agent
Finalité	Adapter la fréquence, cesser d’écrire aux inactifs	Mesurer la performance, sur les seuls contacts consentants

La requête du pixel d’un contact opposé, désinscrit ou dont le consentement a été retiré n’écrit rien — pas même une trace applicative portant son adresse. Les liens ne sont réécrits que si le consentement au suivi des clics est valide au moment du rendu ; sinon, le lien d’origine part tel quel.

Seul le pixel de performance alimente un parcours : le pixel de délivrabilité n’émet aucun événement, il n’écrit qu’une date.

Droits des personnes

Ce qu’une personne peut obtenir, et par quel chemin.

Désinscription : lien dans chaque e-mail marketing, désinscription en un clic (RFC 8058) et en-têtes correspondants, effet immédiat.
Préférences : une page à la marque de l’espace pour choisir ses abonnements, ce qu’elle autorise à mesurer, ou tout arrêter.
Accès et portabilité : un appel restitue attributs, consentements, inscriptions, enrôlements et événements.
Historique des accès : un export par personne concernée dit tout ce qui a été fait sur elle, par qui et quand — lectures comprises.
Effacement : anonymisation irréversible de la fiche, les preuves de consentement et les empreintes de suppression survivant seules, parce qu’elles servent à ne plus jamais écrire.

Attributs sensibles

Chaque attribut d’un contact porte une classe. Ce n’est pas une convention d’interface : la classe décide, côté serveur, de l’endroit où la valeur est écrite, de qui peut la relire, et de ce qui en est journalisé.

Classe	Ce qu’elle porte	Où la valeur est écrite	Qui peut la lire
Technique	Compteurs, statuts, préférences sans portée personnelle	Avec la fiche du contact	Tous les rôles
Personnelle	Nom, adresse e-mail, téléphone, adresse postale	Avec la fiche du contact	Les rôles du client uniquement
Sensible	Réponse à un questionnaire, à valeurs fermées	Table dédiée, chiffrée, hors de la fiche	Les rôles du client porteurs de la permission nominative, chaque lecture journalisée

Ce qui dérive d’une donnée sensible l’est aussi : l’appartenance à un segment défini sur ce critère, le parcours assigné, les événements de la série différenciée. La cohorte « non concernée » est une donnée sensible au même titre que l’autre.

Chiffrée, et pourtant segmentable

Chiffrement au niveau de la colonne (AES-256-GCM), version de clé enregistrée avec la valeur, rotation par tâche planifiée.
À côté de la valeur chiffrée, un index dérivé à sens unique : il rend possibles l’égalité et l’appartenance à une liste de valeurs, jamais un tri ni une recherche partielle. Tout autre opérateur est refusé.
Un attribut sensible est à valeurs fermées ; une valeur hors liste est refusée, et la réponse d’erreur ne répète jamais la valeur envoyée.
La classe ne se défait pas : l’attribut ne peut être reclassé, une valeur encore portée par un contact ne peut être retirée de la liste, et la définition ne s’efface pas tant qu’un segment s’en sert.

Consentement dédié, minimisation et seuil

Une finalité de consentement propre au traitement de ces données, recueillie avec sa preuve comme toutes les autres.
Sans elle, le contact n’appartient à aucun segment construit sur un attribut sensible, n’entre dans aucun parcours qui en dérive et ne fait partie d’aucune audience dérivée. Son retrait l’en sort immédiatement.
Une valeur sensible n’est pas une variable de fusion : on différencie le message en choisissant le parcours, jamais en l’insérant dans le corps de l’e-mail.
Jamais dans un journal applicatif, jamais dans un export, jamais dans un corps de webhook — les charges utiles sortantes ne portent que des identifiants opaques.
Tout compteur servi à un rôle d’exploitation de la plateforme en dessous de vingt personnes est masqué, zéro compris, ainsi que les taux qui s’en déduiraient. Un rôle du client reçoit la valeur exacte.

Journal d’audit

Lire une fiche, lister des contacts, télécharger un export, envoyer une série : chaque accès à une donnée personnelle et chaque modification sont écrits dans un journal en ajout seul, chaîné, conservé dans la même base que les données.

Inaltérable : la modification et la suppression sont refusées par la base elle-même. Chaque entrée porte l’empreinte de la précédente, et une vérification de chaîne quotidienne distingue un contenu modifié d’un maillon retiré ou réordonné.
Nominatif côté acteur : la clé employée, et la personne qui a déclenché l’action lorsqu’elle vient d’une interface d’administration, par un en-tête signé qui nomme sans autoriser.
Un refus est journalisé avec l’opération tentée, et aucune entrée de lecture ne l’accompagne : l’historique d’une personne ne se remplit jamais d’accès qui n’ont pas eu lieu.
Export par personne concernée : tout ce qui a été fait sur elle, par qui et quand, restituable en un appel — et cette lecture-là est journalisée à son tour.
Rien n’est expédié vers un outil extérieur : le journal ne quitte pas le périmètre du déploiement.

Ce qui est écrit, et ce qui ne l’est jamais

Écrit : l’acteur, la date en temps universel, l’appel, la ressource, l’identifiant de requête, la nature de l’opération.
Écrit : les noms des champs lus ou écrits, et un marqueur distinct lorsqu’un champ sensible a été touché.
Jamais écrit : la valeur d’un champ — ni adresse, ni attribut, ni terme de recherche.
Jamais écrit : une adresse IP en clair. Une empreinte tronquée et salée corrèle deux requêtes d’une même origine sans jamais retrouver l’adresse.
Rien du tout lorsqu’un rôle qui ne voit pas un champ interroge la fiche : il n’y a pas eu de consultation.

Conservation, anonymisation, réversibilité

Des durées paramétrables par espace, une sortie irréversible, et une porte de sortie qui n’est pas à notre main.

Six durées réglables par espace — contacts, événements, journal d’audit, livraisons de webhooks, fichiers d’export, envois de test — appliquées par purge automatique.
Le journal d’audit est soumis à un plancher contractuel : une valeur inférieure est refusée, jamais remontée en silence. Un réglage qui ne fait pas ce qu’il annonce est pire qu’un refus.
Anonymisation irréversible d’un contact inactif, en une transaction : adresse, empreinte d’adresse, noms, identifiant externe, attributs personnels, valeurs sensibles, actes de consentement et appartenances détruits ; le pseudonyme dérive de l’identifiant interne, jamais de l’adresse. La fiche reste lisible, vide, pour que son historique d’audit garde un sens — et elle est exclue par construction de tout segment, donc de tout envoi.
Les agrégats statistiques ne sont pas touchés : ils n’ont jamais porté que des identifiants et des nombres.
Ce qui n’est jamais purgé : les preuves de consentement des contacts encore actifs, les agrégats, et les empreintes de la liste de suppression — ne plus jamais écrire à une adresse est une obligation qui survit à la fiche dont elle provient.

Export de réversibilité et suppression définitive

Une archive complète, un fichier par table, chiffrée pour la clé publique du client : la plateforme ne reçoit jamais de clé privée.
L’archive est accompagnée de l’inventaire des tables incluses et de la raison de chaque exclusion ; l’opération est journalisée avec le nombre de personnes concernées.
La suppression définitive se fait en deux temps : un premier appel vérifie qu’un export récent existe et délivre un jeton de confirmation à durée courte ; le second déclenche l’effacement.
Le compte-rendu — noms de tables, comptes, horodatages, signature — est écrit avant la purge du journal et survit à l’espace supprimé. Il ne contient aucune donnée personnelle.

Aucune donnée ne sort du périmètre

La liste des sorties est courte, et aucune ne porte de donnée personnelle.

Aucun prestataire d’envoi tiers : la plateforme remet elle-même les messages aux serveurs de messagerie des destinataires.
Aucun outil d’analyse d’audience ni de télémétrie tiers — ni sur ce site, ni dans la plateforme, ni dans les pages publiques envoyées aux destinataires.
Aucun stockage objet externe : images, exports et archives restent dans la base chiffrée et sauvegardée du déploiement.
Corps des webhooks et fichiers d’export : identifiants opaques uniquement, jamais une adresse.
Journaux constitués par liste d’autorisation : seules les clés explicitement permises sont écrites, y compris dans les traces d’erreur.
Charges utiles des tâches de fond réduites à des identifiants : le contenu est relu depuis la base au moment de l’exécution, jamais transporté dans la file.

Ce que la plateforme sait, et ce qu’elle s’interdit de savoir