Anonymiser le suivi des ouvertures d’email : ce qui est autorisé… ou pas !

Depuis la recommandation de la CNIL sur les pixels de suivi des emails, une phrase revient dans presque toutes les discussions avec les routeurs et les responsables CRM : « de toute façon, si c’est anonymisé, on est tranquille ». Mais, depuis la publication de la recommandation en avril, certains ont fait marche arrière, d’autres se posent encore la question… quoi qu’il arrive, cela ne reste pas limpide.

Un partenaire nous posait récemment la question dans ces termes : sa solution anonymise la donnée d’ouverture « sur toute la chaîne de traitement, sans traitement a posteriori », est-ce que ça suffit à se passer de consentement ? La DPO d’un de ses clients répondait non, au motif que l’anonymisation intervient en aval de la collecte, et qu’upstream, il y a forcément un traitement qui, lui, suppose une base de traitement.

La DPO a raison. Mais sa conclusion mérite d’être précisée. On décrypte.

⚠️ Analyse opérationnelle Badsender. Nous ne sommes ni juristes ni avocats : nous suivons simplement le sujet de très près. Rien de ce qui suit n’est un avis juridique, faites valider votre cas par votre propre DPO.

Le malentendu de départ : l’anonymisation n’est pas une base légale

Pour comprendre, il faut séparer deux moments que l’anonymisation ne met pas du tout sur le même plan : la collecte d’un côté, la réutilisation de l’autre.

La collecte, c’est le déclenchement du pixel. Quand le client email charge l’image invisible, il effectue une opération de lecture/écriture sur le terminal du destinataire. Cette opération est régie par l’article 82 de la loi Informatique et Libertés (transposition de l’article 5.3 de la directive ePrivacy). Et la CNIL est on ne peut plus claire dans sa FAQ du 22 juillet (question 18) : « l’article 82 de la loi Informatique et Libertés s’applique que les données concernées soient personnelles ou non »and « l’anonymisation préalable des données sur le terminal n’est pas une condition suffisante pour exempter leur collecte de consentement ».

Traduisons : ce qui rend un pixel licite, ce n’est pas la nature de la donnée qui en ressort, c’est ce qui justifie l’opération de lecture. Autrement dit, il faut une base, et cette base, c’est soit le consentement, soit une exemption (la délivrabilité ou la sécurité). Le fait qu’une plateforme anonymise « sur toute la chaîne » ne change rien à ce niveau : l’anonymat de la donnée ne crée pas de base de traitement là où il n’y en a pas.

C’est exactement le raisonnement de la DPO : l’anonymisation est en aval, en amont il y a bien un traitement (la lecture) qui doit reposer sur une base de traitement. Là où sa formule « ça suppose un consentement spécifique » est un peu trop absolue, c’est qu’en réalité ça suppose une base : consentement OU exemption. Et pour la délivrabilité, la CNIL prévoit justement une exemption.

Anonymisation des statistiques, ce que la CNIL autorise vraiment : la question 6 de la FAQ

Voilà la bonne nouvelle. Dans la même FAQ, à la question 6, la CNIL répond frontalement à notre interrogation :

« Est-il possible d’utiliser les données collectées à l’aide de pixels exemptés afin d’établir une statistique globale de taux d’ouverture d’une campagne sans consentement ? »
« Oui. Lorsque des données sont collectées au moyen d’un pixel, que cette collecte soit soumise au consentement ou bénéficie d’une exemption, leur réutilisation ne nécessite pas de consentement si elles ont été préalablement anonymisées de manière effective, par exemple via un processus d’agrégation. Des données collectées par un pixel exempté peuvent ainsi […] être utilisées pour établir une statistique globale du taux d’ouverture d’une campagne. »

C’est le pivot de tout le raisonnement qui valide le schéma que de nombreuses plateformes d’envoi vont adopter : un pixel de délivrabilité (exempté, donc posé sans consentement), dont les données servent, après agrégation, à afficher un taux d’ouverture global par campagne. C’est légal, mais à conditions.

La règle à retenir tient en quelques mots : on a le droit de compter, pas de rattacher.

« Anonymisation effective », ça veut dire quoi exactement ?

Dans le vocabulaire de la CNIL et du Comité européen de la protection des données, une donnée n’est « anonyme » que si l’on ne peut plus, de façon irréversible :

• isoler un individu dans le jeu de données (singularisation) ;
• corréler deux enregistrements se rapportant à la même personne (corrélation) ;
• inférer une information sur une personne (inférence).

Tant que ces trois risques ne sont pas écartés, on n’a pas de l’anonyme. Un identifiant de contact haché associé à un historique d’ouverture n’est pas anonyme : il est parfaitement ré-identifiable. « C’est haché » ou « c’est notre plateforme qui gère » ne sont pas des réponses recevables.

Les pièges à éviter dans cette histoire d’anonymisation des ouvertures

1. Confondre pseudonymat et anonymat. Le piège numéro un. Dès qu’une donnée d’ouverture reste rattachable à un contact, même via un identifiant technique, on est dans le suivi individuel, donc dans le consentement.

2. Oublier la taille de l’audience. Un « taux » calculé sur une poignée de destinataires peut, de fait, désigner une personne (si trois personnes ont reçu l’email et qu’une seule l’a ouvert, l’agrégat n’anonymise rien). Un agrégat n’est anonyme que si l’audience est suffisamment grande. Cela vaut pour les petits domaines, mais aussi pour les petites campagnes et les petits segments.

3. Croire qu’on rattrape la sur-collecte. La FAQ (question 7) est nette : « la seule donnée nécessaire à cette fin est la date de dernière ouverture du courriel ». Embarquer l’adresse IP, le user-agent, ou tenir un journal d’ouvertures par contact × par campagne « pour calculer les stats », fait perdre l’exemption : le fait que ces données « soient rendues anonymes ou supprimées peu après leur collecte ne remet pas en cause le fait qu’elles ont été collectées au-delà de ce qui est nécessaire ». La sur-collecte ne se rattrape pas par une anonymisation a posteriori.

C’est le point technique le plus subtil. Pour piloter des statistiques par campagne, il faut bien que le serveur sache, au moment où le pixel est appelé, de quelle campagne il s’agit. Est-ce interdit ? Non : l’identifiant de campagne au moment de la requête n’est pas la « donnée supplémentaire » que vise la Q7 (elle cible ce qui enrichit le profil individuel : IP, user-agent…). Ce qui compte, c’est que la sortie soit un agrégat anonyme et qu’on ne conserve pas d’historique d’ouverture individualisé et rattachable. On peut donc compter les ouvertures d’une campagne sans conserver « qui a ouvert quoi ».

Et au niveau du domaine de destination ? (le nerf du monitoring délivrabilité)

Il y a un cas que ni la recommandation ni la FAQ ne tranchent, et c’est justement celui qui intéresse le plus les équipes délivrabilité : le suivi des taux d’ouverture par domaine de destination (Gmail, Orange, Outlook, Yahoo…). C’est la brique de base du monitoring de délivrabilité : c’est comme ça qu’on repère une mise en spam chez un fournisseur de messagerie précis.

La matière première est pourtant « propre » : la statistique peut se construire, au moment où le pixel est appelé, à partir du même pixel de délivrabilité (celui qui met à jour la date de dernière ouverture), sous forme de simples compteurs agrégés, sans stocker « qui a ouvert quoi ». Le problème n’est pas la source, c’est le niveau de finesse. La FAQ valide explicitement la statistique anonyme au niveau de la campagne (Q6). Au niveau du domaine de destination, en revanche, elle ne dit rien.

Notre lecture : rien ne l’interdit sur le principe (c’est un agrégat de plus, et le monitoring de délivrabilité est une finalité parfaitement légitime), mais comme la CNIL ne l’a pas explicitement validé, on est en zone grise assumée. La règle de prudence est simple : tentez, mais tenez des critères d’anonymisation stricts. Tout se joue sur la taille de la maille. Sur un gros domaine (Gmail, Orange…), un taux d’ouverture par domaine reste un agrégat anonyme. Sur un petit domaine (celui d’une PME avec trois adresses) ou un petit volume d’envoi, le croisement domaine × campagne peut de fait désigner une personne, et là, on repasse sous consentement.

En pratique : fixez un seuil minimal d’audience par maille (domaine × campagne) en dessous duquel la statistique n’est tout simplement pas affichée. C’est votre meilleure défense le jour où l’on vous demandera de prouver que vos « stats par domaine » sont réellement anonymes.

Comment les routeurs s’y prennent (et ce qu’il faut leur demander)

Deux grandes philosophies se dégagent dans l’implémentation des pixels de tracking chez les plateformes d’envoi, et le choix n’est pas neutre pour vos indicateurs (et certains vont sans doute encore changer d’approche à l’avenir).

L’approche « anonymisation d’abord ». On pose un pixel anonyme (pour tout le monde, ou pour les seuls non-consentants) et on n’expose plus que des agrégats. On garde ainsi un taux d’ouverture global sans consentement, dans la logique de la Q6.

L’approche « consentement d’abord ». On mise sur le recueil du consentement au tracking, contact par contact, et sans consentement on se limite à l’exemption délivrabilité.

Les bonnes questions à poser à votre routeur : dans l’approche anonymisation d’abord, quelle est la base de traitement qui justifie la présence d’un pixel de tracking ? L’anonymisation est-elle effective (irréversible, sans ré-identification possible) ou n’est-ce qu’un identifiant masqué ? Le pixel de délivrabilité est-il minimisé (date de dernière ouverture, sans IP ni user-agent) ? Conserve-t-il un historique d’ouverture par contact ? Les statistiques exposées sont-elles de vrais agrégats ? Peut-on documenter tout ça en cas de contrôle ?

Notre recommandation : la checklist « anonymisation propre »

Si vous voulez continuer à piloter vos ouvertures globales sans consentement, tenez la ligne jusqu’au bout :

1. Un pixel de délivrabilité minimisé : on ne conserve que la date de dernière ouverture (à la journée, sans l’heure), écrasée à chaque nouvelle ouverture. Pas d’IP, pas de user-agent.
2. Uniquement sur des emails « expressément demandés » : transactionnels ou emails pour lesquels il y a consentement à la réception. La prospection non sollicitée (B2B, produits/services similaires) n’entre pas dans l’exemption de délivrabilité.
3. Des sorties réellement agrégées et anonymes : pas de statistiques sur de trop petites audiences — y compris lorsqu’on découpe par domaine de destination.
4. Aucun historique d’ouverture individualisé et rattachable conservé.
5. Une frontière étanche avec le marketing : dès qu’il s’agit d’optimiser, personnaliser, cibler ou adapter la fréquence au niveau individuel ? consentement.
6. De la documentation : être capable d’expliquer how la donnée est anonymisée. C’est la première chose qu’on vous demandera.

In summary

L’anonymisation n’est pas une baguette magique qui ferait disparaître le besoin de consentement. Elle sécurise la réutilisation des données, pas leur collecte. Mais bien comprise, c’est une vraie voie de survie : on peut continuer à mesurer des taux d’ouverture globaux par campagne sans consentement, à condition de s’appuyer sur un pixel réellement cantonné à la délivrabilité.