On compte les passages. Pas les personnes.

« Le suivi, c'est du pistage. » C'est l'objection la plus fréquente, et elle mélange deux choses très différentes.

Un pixel publicitaire observe une personne à travers des sites qui ne lui appartiennent pas. C'est ce comportement-là que le RGPD encadre lourdement, que les navigateurs bloquent l'un après l'autre, et qui a fait disparaître les cookies tiers.

Un lien mesuré compte les passages sur une porte qui vous appartient. Ce n'est pas la même opération, ce n'est pas le même risque juridique, et confondre les deux fait renoncer des agences à une mesure parfaitement légitime.

Ce qui est enregistré à chaque clic

Pas de liste vague : voici les sept champs écrits en base, et rien d'autre.

Les agrégats statistiques — les totaux par jour, par pays, par appareil — sont conservés sans limite de durée, parce qu'ils ne contiennent plus personne. Les événements bruts, eux, expirent à treize mois.

Regardez la colonne du milieu. Aucun de ces sept champs n'identifie quelqu'un. C'est un compteur de porte, pas un carnet de visiteurs.

Ce qui n'est pas enregistré, et pourquoi c'est un choix

Ces trois refus sont écrits dans notre politique de confidentialité, pas seulement sur une page de vente. Ce sont des décisions de conception, pas des limites techniques.

Zéro adresse IP stockée. L'IP est lue en mémoire pour deux choses — déterminer le pays et écarter les robots — puis jetée immédiatement. Aucune IP n'est écrite en base de données. C'est la différence entre « nous la protégeons bien » et « nous ne l'avons pas » ; seule la seconde survit à une fuite.

Zéro empreinte d'appareil. Nous ne combinons pas résolution, polices, greffons et fuseau horaire pour fabriquer un identifiant persistant. Cette pratique est interdite par la conception du produit, pas seulement déconseillée : le champ n'existe nulle part.

Zéro cookie tiers. Le lien lui-même n'en dépose aucun. Le mouchard optionnel posé sur le site de votre client écrit l'identifiant de clic dans le localStorage du domaine de votre client — un stockage de première partie, sous la clé subtraq.click. Rien ne voyage vers un domaine tiers.

Et une quatrième, moins connue : le référent est tronqué à son nom d'hôte. On garde instagram.com, jamais instagram.com/p/identifiant-privé…. Un chemin complet peut contenir des données personnelles ; on ne le prend pas.

Le partage des responsabilités, en deux phrases

C'est la partie que les outils américains laissent dans le flou, et c'est celle que votre délégué à la protection des données va lire en premier.

Le RGPD distingue deux qualifications. Pour les données de votre compte — l'adresse d'authentification, la préférence de langue, la facturation, les clés d'interface de programmation — nous sommes responsable de traitement : nous décidons des finalités, nous répondons devant vous.

Pour les clics, prospects et ventes collectés sur les campagnes de vos clients finaux, c'est l'inverse : [votre agence](/agences-marketing) est responsable de traitement vis-à-vis de ses propres visiteurs, et nous agissons en sous-traitant au sens de l'article 28 du RGPD, sur vos instructions et rien d'autre.

Cette inversion a une conséquence pratique très concrète :

• Il vous appartient d'informer vos visiteurs du suivi mis en place, dans votre politique de confidentialité ou votre bandeau.
• Il nous appartient de ne traiter que le nécessaire, et de pouvoir le prouver champ par champ — c'est le tableau plus haut.
• Un accord de traitement des données est disponible sur simple demande, sans palier minimum, et ce que voit le client final dans son rapport n'est jamais une liste de personnes : ce sont des totaux par campagne.

Ce n'est pas un conseil juridique et cette page n'en tient pas lieu : c'est la description de ce que l'outil fait. Ce que votre agence doit écrire à ses visiteurs reste à écrire avec ses mots.

Où vivent les données

Le point à comprendre sur Cloudflare, parce que c'est le seul maillon qui sort de l'Union : il traite chaque requête au point de présence le plus proche du visiteur, qui peut se trouver hors UE. Ce qui lui est transmis se limite à ce qu'une requête HTTP standard contient. Le carnet de liens — destination et statut — est répliqué mondialement chez lui, et il ne contient aucune donnée personnelle : pas d'adresse, pas d'IP. Les données personnelles restent sur le serveur allemand, dont l'état est public.

Ce qui change quand votre propre code identifie quelqu'un

Jusqu'ici, personne n'est identifiable. Ça change à un endroit précis, et il faut le dire clairement.

Quand un visiteur devient un prospect ou un client, votre code appelle lead(email) ou identify(userId) — deux appels documentés, à vous de décider si vous les utilisez. Ces données-là sont associées à l'identifiant de clic et stockées dans votre espace. À cet instant, il y a bien une donnée personnelle — et elle relève de votre responsabilité de responsable de traitement, pas de la nôtre.

C'est la limite honnête de l'exercice, et elle est facile à manquer dans une brochure : un outil qui jure ne jamais toucher de donnée personnelle tout en vous proposant de relier une vente à une adresse de courriel ne dit pas la vérité. La bonne formulation est celle-ci : l'outil ne collecte aucune identité tout seul ; il en stocke une si, et seulement si, votre application la lui envoie.

Les cinq questions d'un délégué à la protection des données

Un visiteur peut-il être identifié ? Pas par nous. Ni IP, ni empreinte, ni adresse de référent complète : les clics bruts ne portent pas d'identité. Une identité n'apparaît que si votre propre application appelle lead() ou identify().

Faut-il une case dans notre bandeau ? Le lien ne dépose aucun cookie tiers. Le mouchard optionnel écrit dans le stockage local du domaine de votre client : un stockage de première partie, à mentionner dans sa politique de confidentialité. C'est une responsabilité d'éditeur, et la politique le dit sans détour. La comparaison avec un outil d'analyse classique détaille la différence.

Combien de temps les données vivent-elles ? Événements bruts : treize mois. Agrégats statistiques : sans limite, parce qu'ils ne contiennent plus de données personnelles.

Et si nous partons ? Les données s'exportent en CSV, l'espace se supprime sur demande, et la suppression est effective — pas un « compte désactivé » qui garde tout.

Quels droits, et auprès de qui ? Accès, rectification, effacement, limitation, opposition, portabilité, à [email protected], avec réponse sous un mois. Et le recours devant la CNIL, comme toujours.

Pourquoi cette conception mesure mieux, pas moins bien

Le paragraphe qu'on n'attend pas dans un texte sur le RGPD. Renoncer au pistage n'est pas un sacrifice de mesure, c'est un changement de méthode qui gagne sur deux points.

Un lien n'est pas bloquable. Les pixels publicitaires sont bloqués par les navigateurs, les extensions et les systèmes d'exploitation, et de plus en plus. Une redirection, non : elle est le chemin que le visiteur emprunte. La mesure ne se dégrade pas à mesure que la vie privée progresse.

Vous mesurez ce que vous vendez. Un pixel vous donne des sessions et des conversions estimées. Un lien relié au paiement vous donne un montant encaissé, rattaché à un placement nommé. Le premier alimente un rapport d'activité, le second décide où passe le budget du mois prochain.

La contrepartie est réelle et il faut l'assumer : cette méthode ne suit personne d'un site à l'autre. Elle ne vous dira jamais ce que votre prospect a regardé ailleurs. C'est précisément ce qu'on lui demande.

Le détail champ par champ, les sous-traitants et le paragraphe prêt à copier pour un questionnaire de conformité sont sur la page sécurité et RGPD. Et pour savoir lequel de vos liens a vendu, l'article sur l'attribution explique la méthode.