CRM — Consentement marketing d'un contact

Objectif

La fiche contact portait déjà une case « Opposition prospection » : cochée, elle signifie que le contact refuse d'être démarché. Elle disait l'état, elle ne disait rien de son histoire — ni depuis quand, ni qui l'avait cochée, ni d'où venait la demande.

C'est insuffisant dès qu'un contact conteste avoir été démarché, ou exerce son droit d'accès. Le RGPD demande de pouvoir prouver un consentement, pas seulement de l'afficher.

Deux ajouts répondent à ce besoin :

• une date de décision sur la fiche contact, qui dit depuis quand l'état courant s'applique ;
• un registre interne qui conserve chaque changement : valeur avant, valeur après, origine, auteur, horodatage.

Ce que voit l'utilisateur

Sur la fiche contact (consultation)

Le bloc « Identité » affiche une ligne supplémentaire, dont le libellé suit l'état :

L'heure est affichée volontairement : deux décisions peuvent se suivre le même jour, et c'est l'horodatage précis qui fait foi.

Le badge rouge « Opposition prospection », à côté du nom, est inchangé.

Sur la fiche contact (modification)

Le champ « Date de la dernière décision de consentement » apparaît juste sous la case « Opposition prospection », grisé et non modifiable.

Ce n'est pas un oubli : une date de preuve qui se saisit à la main ne prouve rien. Elle est posée automatiquement par l'application au moment exact où la case change d'état. Cocher ou décocher la case suffit — la date suit.

Le bloc « Historique du consentement »

En bas de la fiche, un bloc retrace les décisions successives, la plus récente en premier :

Le bloc est en lecture seule : aucune action, aucune modification, aucune suppression. C'est voulu — voir Pourquoi le registre est inaltérable.

Un contact sur lequel personne ne s'est jamais prononcé affiche un message le disant, plutôt qu'un bloc vide : c'est une situation normale, pas une anomalie.

Le bloc fait partie de l'export PDF de la fiche. C'est lui qu'on produit lorsqu'un contact exerce son droit d'accès et demande ce que l'on sait de ses choix.

Qui peut agir

La case « Opposition prospection » se modifie depuis la fiche contact, accessible aux utilisateurs disposant du module CRM (b2b). Il n'y a pas de droit distinct pour le consentement : qui peut modifier un contact peut modifier son opposition.

Quel que soit l'auteur, la décision est tracée. En mode assistance — quand un assistant ISI intervient sur l'espace d'un client — c'est l'identité de l'utilisateur pour le compte duquel il agit qui est enregistrée, et non celle de l'assistant.

Certaines décisions n'ont légitimement aucun auteur : une désinscription reçue depuis un e-mail est le fait du contact lui-même, pas d'un utilisateur de l'application. Le registre l'enregistre alors sans auteur, avec l'origine correspondante.

Origines d'une décision

Chaque ligne du registre porte l'origine de la décision :

Désabonnement depuis un e-mail

Quand un contact clique sur le lien de désinscription d'une campagne, l'outil d'e-mailing en informe l'application. Celle-ci coche l'opposition, pose la date, et inscrit la décision au registre avec l'origine « désabonnement » et aucun auteur.

Le contact n'a pas à être recontacté pour confirmer, et un utilisateur qui rouvrirait la fiche verra l'opposition déjà en place. Le paramétrage de la liaison avec l'outil d'e-mailing est décrit dans la documentation du connecteur Brevo.

Première décision et changements sans effet

Deux comportements méritent d'être connus :

• Un contact n'ayant jamais fait l'objet d'une décision n'a pas de date. Enregistrer un consentement pour lui — même « pas d'opposition » — crée bien une entrée au registre : c'est la première preuve qu'on a demandé et obtenu son accord.
• Réenregistrer la valeur déjà en place ne fait rien. Recocher une case déjà cochée n'écrit aucune ligne et ne repousse pas la date : la décision d'origine reste celle qui compte.
• Un contact qu'on vient de créer n'a aucune décision, case décochée comprise : tant que personne ne s'est prononcé, l'application ne prétend pas savoir. Si la case est cochée dès la création — parce qu'on sait déjà que la personne refuse —, c'est en revanche une première décision, enregistrée comme telle.

Pourquoi le registre est inaltérable

Le registre ne peut être ni modifié ni supprimé, ni depuis l'interface ni par une action d'administration. Contrairement au reste de l'application, il ignore la corbeille : il n'existe aucun moyen d'en retirer une ligne.

C'est sa raison d'être. Un journal de consentement qu'on peut purger ne prouve plus rien le jour où il faut s'en servir — et ce jour-là, c'est précisément la ligne gênante qui aurait disparu. Les entrées s'accumulent donc indéfiniment ; leur volume reste négligeable, une décision de consentement étant un événement rare dans la vie d'un contact.

Limites

• La date ne remonte pas le passé : les contacts dont l'opposition avait été cochée avant la mise en service n'ont aucune date ni aucune entrée au registre. L'information n'existe nulle part, elle ne peut pas être reconstituée. Ces contacts se documenteront au fil de leur prochaine décision.
• Le bloc « Historique du consentement » affiche les 5 décisions les plus récentes. Le registre les conserve toutes — il annonce simplement combien il n'en montre pas. Au-delà, la lecture complète se fait sur demande, par l'équipe technique.
• Il n'existe aucun écran de modification du registre, et c'est un choix assumé : l'écran standard que l'application sait générer pour une table permettrait aussi d'en supprimer les lignes, ce qui ôterait au registre sa valeur de preuve.

Voir aussi

• Connecteur Brevo — la liaison avec la plateforme d'e-mailing, son installation et ce qu'elle synchronise.
• Service / Département d'un contact
• Génération d'e-mail d'un contact