Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Vendredi 16 octobre 2026
Marketing Digital

Identifiant publicitaire connecté : quels choix ?

Identifiant publicitaire connecté : cartographiez sa création, ses destinataires et ses usages, puis organisez le retrait sans perturber le compte.

Un email recueilli pour ouvrir un compte ne peut pas être transformé automatiquement en identité publicitaire partagée. La connexion permet d’authentifier un utilisateur ; elle ne démontre pas son accord au suivi entre services. Le projet publicitaire doit avoir ses finalités, son fondement, ses destinataires et son mécanisme d’arrêt propres.

Le hachage ne règle pas cette question. Lorsque l’identifiant sert justement à rapprocher des activités autour d’une même personne, présenter le dispositif comme « anonyme » est trompeur. Pour décider, suivez l’identifiant depuis sa création jusqu’aux audiences, y compris après retrait et changement de compte.

Trois promesses à examiner dans une proposition commerciale

La CNIL décrit les identifiants persistants dérivés d’une adresse électronique : une même donnée peut permettre de relier des activités sur plusieurs services. Cette technique n’est pas assimilable à un simple numéro interne sans destinataire extérieur.

Une offre peut comporter les trois formulations suivantes. Elles sont ici fictives, utilisées pour expliquer une revue contractuelle, et ne sont attribuées à aucun prestataire.

« Nous recevons uniquement une empreinte de l’adresse. » Cela décrit une transformation, pas la disparition du caractère personnel. Demandez qui détient les données permettant le rapprochement, si la clé est stable entre clients et quels autres événements lui sont associés. Les Art. 4(1) et (5) du RGPD imposent de distinguer identification indirecte et pseudonymisation. Le guide pseudonymisation et anonymisation approfondit cette différence.

« La donnée est déjà connue de votre entreprise. » Sa présence dans le compte ne justifie pas tout nouvel usage. L’adresse nécessaire à la récupération du mot de passe n’est pas nécessaire, pour cette seule raison, au ciblage partagé. Il faut qualifier les opérations publicitaires, pas seulement leur donnée d’entrée.

« Le retrait est géré dans notre interface. » Cette réponse reste insuffisante si votre serveur régénère la clé au prochain accès. L’arrêt doit couvrir votre source, le connecteur, les destinations et les réimports. Une préférence n’est effective que si les opérations correspondantes la respectent.

Séparer le service demandé et la publicité

L’Art. 6(1)(b) du RGPD concerne les traitements nécessaires au contrat avec la personne. Il ne suffit pas d’inscrire une finalité publicitaire dans les conditions du compte pour la rendre nécessaire à ce contrat.

Le responsable doit déterminer un fondement pour les opérations envisagées. S’il retient le consentement, les conditions des Art. 4(11) et 7 s’appliquent : choix libre, spécifique, éclairé, univoque et démontrable. La personne doit comprendre la création de la clé et les usages concernés. Une case « accepter les conditions du compte » ne démontre pas ce choix publicitaire.

L’intérêt légitime n’est pas une solution de remplacement automatique après un refus. Son éventuelle utilisation suppose un intérêt identifié, la nécessité du traitement et une mise en balance réelle avec les droits et attentes des personnes. Elle ne dispense pas du consentement requis par les règles des traceurs. Un fournisseur ne peut pas résumer ce raisonnement à « données professionnelles » ou « données déjà collectées ».

Le refus publicitaire ne signifie pas, par lui-même, qu’il faut effacer l’adresse nécessaire au fonctionnement du compte. Il faut séparer les usages. Inversement, conserver cette adresse pour le compte n’autorise pas à continuer de calculer la clé pour un autre objectif.

Examiner les accès au terminal, pas seulement le serveur

L’article 82 de la loi Informatique et Libertés encadre l’accès à des informations déjà stockées dans le terminal et l’inscription d’informations. Ses exceptions concernent notamment les opérations strictement nécessaires au service expressément demandé ; l’étiquette « sans cookie tiers » ne tranche pas leur application.

Deux montages doivent être distingués. Dans le premier, un script lit un identifiant sur le navigateur puis le transmet à un partenaire publicitaire. L’analyse doit couvrir cette lecture et ce partage ; une exemption d’authentification ne se prolonge pas automatiquement à la publicité.

Dans le second, un système travaille sur une adresse déjà détenue côté serveur, sans nouvelle lecture ni écriture identifiée sur le terminal. Il faut vérifier cette description sur toute la chaîne. On ne peut ni affirmer que toute opération serveur relève nécessairement de l’article 82, ni en déduire une liberté de réutilisation : le RGPD continue à encadrer le traitement personnel.

En pratique, demandez les événements de déclenchement, les scripts, les cookies ou stockages locaux, les requêtes et les copies intermédiaires. Une réponse limitée à la destination finale ne décrit pas l’origine des données.

Une spécification remplie pour un projet limité

La fiche I06 ci-dessous est une proposition pédagogique pour un service fictif de contenus de randonnée. Il envisage une identité publicitaire connectée, fondée dans cet exemple sur un consentement spécifique, avec deux partenaires précisément identifiés dans son dossier. Aucun résultat d’essai réel n’est rapporté.

Élément Décision retenue dans I06 Conséquence attendue
Compte du lecteur Adresse utilisée pour connexion et récupération Le compte demeure accessible après refus publicitaire
Création de la clé Seulement pour le choix publicitaire documenté La seule connexion ne déclenche pas le calcul publicitaire
Destinations Deux partenaires nommés, périmètre défini Aucun troisième destinataire ajouté silencieusement
Événements associés Rubrique consultée après activation dans le périmètre admis Pas de récupération de la navigation antérieure au choix
Données exclues Texte libre, messages d’assistance et contenus sensibles Aucun ajout automatique de propriétés au flux
Retrait Arrêt des nouveaux événements et de la régénération de clé Contrôle aussi des files et des synchronisations

La rubrique « randonnée » ne rend pas tout profilage inoffensif. Un historique détaillé peut révéler davantage que le sujet général du site. I06 limite donc les catégories, les événements et leur durée, puis examine si ce besoin justifie réellement le rapprochement entre services.

La liste des partenaires ne doit pas être remplacée par « partenaires de confiance » lorsque cette formule empêche de comprendre les intervenants. La notice doit décrire les finalités, destinataires, conservation, transferts éventuels et droits selon les Art. 13–14 du RGPD. La présentation du choix doit permettre de comprendre sa portée avant l’activation.

Ne pas rattacher la mauvaise personne

Un identifiant dérivé d’une adresse peut être stable sans constituer une preuve que chaque événement provient du même individu. Une adresse peut être partagée ; un appareil peut accueillir plusieurs comptes ; une adresse professionnelle peut changer de titulaire. La qualité du rapprochement doit être examinée au regard de l’Art. 5(1)(d).

Dans I06, lorsque Léa se déconnecte et Sami ouvre son compte sur le même navigateur, les événements de Sami ne doivent pas poursuivre le profil de Léa. Le retrait de Léa ne doit pas non plus être remplacé par le choix de Sami. Ces résultats sont des exigences de conception, pas une description d’une fonction disponible chez un éditeur précis.

La navigation précédant la connexion ne devient pas automatiquement l’historique du titulaire qui se connecte ensuite. Le responsable doit pouvoir expliquer toute règle de rattachement, sa nécessité et sa portée. Si le système ne permet pas de distinguer ces contextes, désactivez le rapprochement concerné ou réduisez son périmètre avant de l’utiliser.

Le changement d’adresse appelle la même prudence : remplacer une clé ne prouve ni un nouveau consentement ni la continuité d’un titulaire. Le lien entre ancien compte, nouveau contact et choix doit être établi, sans transférer aveuglément tous les profils.

Préparer le retrait avec les destinataires

L’Art. 7(3) prévoit un retrait aussi simple que le consentement. Il n’invalide pas rétroactivement les traitements licites antérieurs, mais impose de traiter les conséquences pour les opérations futures et les données conservées. L’Art. 17(1)(b) prévoit l’effacement lorsque le consentement est retiré et qu’aucun autre fondement ne justifie le traitement concerné.

I06 distingue trois tâches : bloquer la création et les nouveaux envois, traiter les clés et profils déjà transmis, puis empêcher leur recréation par une synchronisation ancienne. Le guide du retrait d’audience publicitaire détaille ce dernier risque.

La preuve attendue ne se limite pas à « demande reçue ». Il faut savoir quels destinataires sont concernés, quelle action a été effectuée et quelles réserves subsistent. Lorsque les conditions de l’Art. 19 sont réunies, les rectifications, effacements ou limitations doivent être notifiés aux destinataires, sous les exceptions prévues par cet article.

Une information minimale peut rester nécessaire pour faire respecter une opposition ; elle ne doit pas redevenir un profil actif. Définissez sa finalité, son accès et sa conservation séparément. Ne gardez pas l’ensemble de la navigation sous prétexte de prouver que la personne a refusé.

Conditionner l’achat à une démonstration précise

Le contrat doit définir les usages permis, les destinataires et les suites du retrait. Le statut de sous-traitant ou de responsable se déduit des fonctions réelles, selon les Art. 26(1) et 28(3). Un acteur qui réutilise les profils pour ses propres finalités ne peut pas être traité comme un simple exécutant sans examiner cette activité.

Demandez une démonstration sur des parcours définis : connexion sans accord publicitaire, activation, retrait, reconnexion, changement de compte et nouvel envoi d’une ancienne file. L’observation doit couvrir la source et les destinataires, avec les limites de visibilité signalées. Un écran de préférences fonctionnel ne prouve pas, seul, l’arrêt des transmissions.

Si le prestataire ne peut pas expliquer ce qui arrive aux clés après retrait, I06 reste non activé. Une solution de publicité contextuelle peut être étudiée, mais il faut vérifier qu’elle n’ajoute pas discrètement le même identifiant pour mesurer ou cibler. Changer le nom de l’offre ne change pas ses flux.

Ce qu’il faut retenir

L’adresse du compte et la clé publicitaire répondent à des usages distincts. Le hachage ne vaut pas anonymisation et la connexion ne vaut pas consentement. Documentez les destinataires, empêchez les rattachements erronés et exigez un retrait qui fonctionne jusque dans les reprises et les profils déjà créés.

FAQ

Faut-il recalculer une nouvelle clé après chaque refus ?

Non : remplacer une clé pour poursuivre le même suivi ne respecte pas le refus. La question porte sur les opérations autorisées, pas sur le nom de l’identifiant. Une rotation technique ne crée pas un nouveau choix de la personne.

Le retrait publicitaire oblige-t-il à supprimer le compte ?

Pas automatiquement. Les données nécessaires au service peuvent suivre leur fondement propre. Il faut arrêter les usages publicitaires concernés et traiter leur conservation, sans confondre cet arrêt avec la fermeture du compte demandé.

Peut-on relier plusieurs appareils parce que le lecteur se connecte ?

La connexion établit un contexte de compte, pas une permission générale de rapprochement publicitaire. Le dispositif doit respecter les choix, l’information et le périmètre réellement admis. Les situations hors connexion et les contradictions entre appareils nécessitent leur propre traitement.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.

Thiébaut Devergranne
Docteur en droit des nouvelles technologies (Paris II)

Docteur en droit, Thiébaut Devergranne travaille en droit des nouvelles technologies et en protection des données personnelles depuis plus de 20 ans. Il a accompagné des centaines d'organisations dans leur mise en conformité RGPD et est le fondateur de Legiscope, logiciel de conformité RGPD.

En savoir plus sur l'auteur →