---
title: "CRM — Consentement marketing d'un contact"
module: crm
type: functional
status: active
updated: 2026-09-11
---

# 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 :

| État de la case | Ligne affichée |
|-----------------|----------------|
| Opposition cochée | **Opposition depuis le** 03/09/2026 à 14:32 |
| Opposition décochée | **Consentement confirmé le** 03/09/2026 à 14:32 |
| Aucune décision enregistrée | *(aucune ligne)* |

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** :

| Ce qui est affiché | Exemple |
|--------------------|---------|
| Date et heure | 03/09/2026 à 14:32 |
| Sens de la décision | *Opposition à la prospection* · *Consentement confirmé* · *Adresse devenue injoignable* |
| Origine | *Saisie sur la fiche contact* · *Désabonnement depuis un e-mail* · *Import de fichier* · *Synchronisation* · *Rebond* |
| Auteur | son nom, ou *sans intervention interne* quand la décision vient du contact lui-même |

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 :

| Origine | Cas |
|---------|-----|
| Interface | un utilisateur coche ou décoche la case sur la fiche contact |
| Désabonnement | le contact s'est désinscrit depuis un e-mail de campagne |
| Import | la décision provient d'un fichier importé |
| API | la décision est reçue par l'API |
| Synchronisation | alignement avec un outil externe |

## 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](../integrations/brevo-connector.md).

## 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](../integrations/brevo-connector.md) — la liaison avec la plateforme
  d'e-mailing, son installation et ce qu'elle synchronise.
- [Service / Département d'un contact](contact-service-field.md)
- [Génération d'e-mail d'un contact](contact-email-generation.md)