Quelles données de suivi partent quand vous collez un lien UTM dans un chat

L’URL de la barre d’adresse n’est pas automatiquement partageable

Un marketeur dépose une landing dans Slack. Le support colle l’URL d’une réclamation dans un ticket. Un développeur recopie une reproduction dans un fil Teams. Dans les trois cas, le geste le moins cher est le même : tout sélectionner dans la barre d’adresse, copier, coller. Cette barre affiche l’URL complète du document courant. Dans le modèle WHATWG, elle contient au moins un schéma, un hôte, un chemin, une query (après ?) et un fragment (après #). Le fragment ne part pas dans HTTP par défaut — c’est l’objet de la note précédente. La query, elle, voyage dans la ligne de requête, et elle voyage aussi dans le presse-papiers.

Souvent, cette query n’est pas nécessaire pour ouvrir la page. Vous arrivez d’un e-mail suivi, d’un clic payant, ou d’une carte sociale qui a ajouté son propre jeton. La page n’a besoin que de /product/42. La barre affiche /product/42?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale&fbclid=…. Pour l’outil d’analyse, c’est une visite attribuable. Pour la personne suivante qui lit la chaîne, c’est un profil latéral qui n’a rien à faire dans un ticket : de quelle campagne vous venez, si vous venez de cliquer une pub, si l’outil d’e-mail a numéroté ce destinataire.

HTTPS ne protège que le saut contre l’écoute. Il n’efface ni la barre d’adresse, ni l’historique du navigateur, ni le stockage du chat, ni les captures d’écran, ni les journaux d’accès. La note OWASP sur l’exposition d’information par les chaînes de requête est nette : même sur un canal chiffré, la query apparaît encore dans le Referer, les journaux web, les systèmes partagés, l’historique, les caches et le regard par-dessus l’épaule. Avant d’envoyer, la question n’est pas « ce site est-il sûr ». C’est « ce point d’interrogation porte-t-il des étiquettes qui ne devraient pas quitter cet onglet ».

L’UTM nomme une campagne. L’identifiant de clic nomme ce clic.

Les deux familles cohabitent souvent sur la même URL. Elles ne font pas le même travail, et elles ne fuient pas la même chose. La première est une étiquette de campagne que vous (ou la régie) avez écrite exprès. Le centre d’aide Google Analytics les appelle campaign parameters et donne l’exemple standard : https://www.example.com/?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale. La documentation indique que, si vous ajoutez des paramètres, il faut utiliser ensemble utm_source, utm_medium et utm_campaign. Les extensions comprennent utm_id, utm_term, utm_content et utm_source_platform. Les valeurs sont sensibles à la casse : utm_source=google et utm_source=Google se séparent en deux lignes dans un rapport.

Ces étiquettes n’encodent en général pas une personne. Elles décrivent un canal et une campagne : quelle newsletter, quelle soldes d’été, le lien du haut ou celui du bas. Les transférer dans un chat externe révèle tout de même la structure média interne. Le destinataire lit quelle campagne vous poussez et si le clic venait d’un e-mail ou d’un achat média, et il peut en déduire votre chemin d’acquisition. Pour un concurrent ou un tiers sans rapport, c’est plus que « ouvrir cette page » n’exige.

La seconde famille est un jeton de clic que la régie ou l’outil d’e-mail ajoute tout seul. Les noms fréquents : gclid pour Google Ads, dclid pour Display & Video 360, gbraid / wbraid côté iOS, fbclid pour Meta, msclkid pour Microsoft Advertising, twclid pour X, et des jetons d’e-mail comme mc_eid. Leur rôle est de recoudre « ce clic » aux enregistrements de la plateforme, pas de vous offrir une phrase lisible. La valeur est opaque pour le destinataire, lisible pour la plateforme. Transférer une chaîne qui porte encore fbclid ou gclid, c’est remettre un identifiant de clic recoupable. Un mc_eid se rapproche de « ce message est parti vers cette ligne d’abonné ».

Il existe une troisième couche : les paramètres d’attribution ou de partage du site lui-même. Boutiques et médias ajoutent souvent spm, scm, pvid, share_token ou refer_share_id. Ce n’est pas la spécification UTM de Google, mais cela transforme une « simple fiche produit » en trace de qui l’a partagée et d’où. Une règle qui ne retire que utm_* laisse cette couche derrière.

Où atterrit la query une fois collée

La CWE-598 — titre actuel : Use of HTTP Request With Sensitive Query String — formule le défaut ainsi : une donnée sensible a été placée dans la query. Elle apparaît ensuite dans l’historique du navigateur, voyage vers d’autres sites via Referer, s’écrit dans les journaux web, ou se recopie dans d’autres archives. L’entrée a été renommée dans la version 4.20 d’avril 2026 pour insister sur un point : GET n’est pas la seule méthode qui peut porter une query ; POST, PUT et DELETE le peuvent aussi. La mitigation est précise : mettre les données sensibles dans le corps ou dans les en-têtes, pas dans la query.

La plupart des paramètres marketing ne sont ni des mots de passe ni des jetons de session. La surface d’exposition, elle, est la même. Coller une URL complète dans une messagerie crée au moins ces copies : le stockage du prestataire de chat, l’historique local du destinataire, et — s’il transfère — le stockage du saut suivant. S’il ouvre le lien, le journal d’accès de la destination enregistre une ligne de requête qui porte encore les paramètres. Si la page charge ensuite un script ou une image tiers, l’URL complète peut aussi voyager dans le Referer vers un hôte pub ou analytics. Les « systèmes partagés » d’OWASP sont banals en entreprise : tickets, documents, supervision d’erreurs, rejeu de session. Un lien prévu seulement pour reproduire un bug devient cherchable en clair dans ces outils.

C’est pourquoi « le site est en HTTPS » ne répond pas à la question de l’envoi. HTTPS rend plus difficile, pour un observateur sur le chemin, de lire le clair. Il ne vous empêche pas de coller ce clair dans le système suivant. Parmi les défauts réels cités par CWE-598 : une caméra qui mettait un mot de passe dans la query, un produit de comm qui mettait un jeton d’accès en GET. Même classe d’erreur, plus grave. UTM et identifiants de clic sont en général plus bénins. Le mécanisme est identique : ce qui suit le point d’interrogation est ce que les gens copient et ce que les systèmes journalisent.

Le Referer peut emporter la query chez un tiers

Copier-coller est un envoi actif. Il existe aussi un envoi passif : une fois le destinataire sur la page, la politique par défaut du navigateur dit aux requêtes suivantes « d’où je viens ». Le nom standard de cet en-tête est Referer (il manque un r). La note MDN sur la confidentialité du Referer reprend un cas familier : une page de réinitialisation avec des liens sociaux en pied — un clic vers l’extérieur peut remettre une adresse porteuse de jeton au réseau social. Une image tierce sur la page peut envoyer de la même façon l’URL complète à l’hôte de l’image.

Les navigateurs décident de la quantité envoyée avec Referrer-Policy. Chrome et les moteurs proches utilisent par défaut strict-origin-when-cross-origin : une requête same-origin peut porter l’URL complète (chemin et query) ; une requête cross-origin sans rétrogradation n’envoie que l’origine (schéma + hôte + port) ; un saut HTTPS vers HTTP n’envoie rien. Le guide referrer de web.dev traite ce défaut comme un compromis entre confidentialité et usage. Il bloque une partie des cas « query complète vers un autre hôte ». Il ne bloque pas les requêtes d’analyse same-origin, et il n’aide pas si le site pose unsafe-url ou laisse la politique vide sur un ancien client qui envoie encore l’URL entière.

Pour « je l’ai seulement envoyé à un collègue », le Referer compte encore : dès qu’il clique, les utm_* et les identifiants de clic que vous avez collés peuvent faire un saut de plus. Si la landing a un pixel tiers, un widget support ou une police sur un CDN, et que la politique autorise une URL complète, ces paramètres apparaissent dans les journaux de ces hôtes. Retirer les traceurs de la query avant l’envoi coupe les deux sauts : le clair dans l’historique du chat, et un Referer qui pourrait partir à l’ouverture.

Le contraste avec le fragment mérite encore une phrase. Une clé après # est conçue pour ne pas entrer dans la ligne de requête, donc elle reste hors des implémentations ordinaires du Referer. Une query n’a pas cette couche. Les étiquettes de campagne et les identifiants de clic sont après ? pour que serveurs et scripts les lisent — c’est précisément pourquoi ils atterrissent dans les journaux. Pour vérifier « le point d’interrogation entre dans la requête, le dièse en principe non », suivez les étapes de Pourquoi le fragment après # d’une URL convient pour une clé, et quand cette protection lâche.

Le système peut retirer certains jetons. Ce n’est pas une politique d’envoi.

Apple documente une coupure intégrée. Sur la page Privacy Features, la protection contre le suivi des liens est formulée ainsi : lorsque vous partagez des liens dans Messages, les informations supplémentaires que certains sites ajoutent aux URL sont retirées, afin que ces sites ne puissent pas vous suivre ni suivre la personne avec qui vous partagez. Safari en navigation privée est décrit à part : la protection retire le suivi ajouté aux URL pendant la navigation. Apple publie la capacité, pas une liste de paramètres.

Il n’existe pas de liste officielle complète. Les contrôles communautaires (PrivacyTests.org et équivalents) citent souvent gclid, fbclid, mc_eid, twclid et dclid. Les étiquettes de campagne comme utm_source restent en général. Le périmètre a aussi des bords : Safari habituel, un navigateur tiers et une WebView in-app ne sont pas les mêmes chemins que le partage dans Messages ou la navigation privée. Un destinataire sous Android, dans Chrome bureau, ou qui ouvre depuis Slack ou WhatsApp, ne retiendra rien à votre place.

Donc « mon téléphone retire déjà les paramètres de suivi » signifie seulement : sur un système donné, dans une application donnée, certains identifiants de clic peuvent disparaître avant l’ouverture. Cela ne signifie pas : la chaîne que vous avez collée dans le ticket a déjà été nettoyée. L’envoi a lieu au moment de la copie, là où le système d’exploitation n’est pas encore intervenu. Ce que vous contrôlez, c’est le presse-papiers, pas le fait que l’autre appareil retire encore une fois.

Quoi retirer, quoi garder

Une règle exécutable : demandez d’abord si la page s’ouvre encore sans cette clé. Un id produit, une recherche q, un numéro de page, un lang, ou une query dont le document a besoin, change la ressource si vous la retirez. Les étiquettes de campagne, les identifiants de clic, les numéros de destinataire d’e-mail et les jetons de partage ne changent en général que l’attribution, pas la page.

La deuxième question est le but du lien. Un collègue qui reproduit un bug a besoin d’une adresse de ressource stable, pas de utm_campaign=summer-sale. Un client à qui l’on dit « ouvrez ce produit » a besoin du sku, pas du gclid de votre dernier clic. Gardez les UTM seulement si la tâche est « merci d’entrer par cette campagne taguée pour que nous comptions ce transfert ». Même dans ce cas, n’attachez pas votre propre identifiant de clic.

La suppression à la main rate des clés. Une URL d’achat média réelle peut porter cinq ou six champs utm_*, un identifiant de clic et deux ou trois jetons internes. Scanner de droite à gauche efface souvent id et laisse fbclid. Un passage plus stable se fait par nom de clé : retirer tout préfixe utm_ ; retirer une table connue d’identifiants de clic ; si la tâche le permet, retirer aussi les clés d’analyse courantes (_ga, _gl, mc_eid, mkt_tok) et l’attribution e-commerce fréquente. Garder le chemin, l’hôte et la query métier. Ensuite, lire la liste des « clés retirées » — pas seulement si le résultat « a l’air plus court ».

Prudent et standard sont deux préférences de risque, pas deux grades d’anonymat. Prudent : ne toucher qu’aux UTM et aux identifiants de clic, laisser les clés custom inconnues, pour ne pas effacer un paramètre métier jamais vu. Standard : retirer aussi l’analyse courante et l’attribution boutique, ce qui convient à un lien qui sort de l’entreprise ou atterrit dans un espace public. Ni l’un ni l’autre ne peut affirmer « c’est désormais anonyme ». Un chemin peut encore contenir un identifiant. Une query email= n’est pas dans la table UTM. Un nettoyage par règles traite des clés de suivi connues, pas n’importe quel champ sensible. Téléphones, numéros de pièce d’identité et clés dans le corps du message demandent un masquage à part. Ne comptez pas sur le retrait d’URL pour finir ce travail.

Contrôle sur place : la liste des clés retirées, puis Network

« Nettoyage local, rien n’est envoyé » ne se prouve pas tout seul. Ce que vous pouvez voir sur place, ce sont trois choses : quelles clés ont disparu, quelles clés restent, et si votre URL d’origine est partie comme donnée métier.

Construisez d’abord un canari. Ouvrez une page publique sans client réel, et ajoutez ?utm_source=canary-share&utm_medium=email&utm_campaign=canary-2026&fbclid=canaryclid&id=42. Collez toute la chaîne dans l’outil. Après exécution, les quatre clés de suivi doivent avoir disparu et id=42 doit encore être là. Si l’outil liste les noms retirés, contrôlez ces noms un par un. Ne vous arrêtez pas à « l’URL a raccourci ».

Puis ouvrez Network dans les outils de développement, activez Preserve log, et cherchez canary-share ou la query canari entière. Elle ne doit apparaître ni sur une ligne XHR / Fetch, ni dans une query ou un corps, ni dans une query ou un corps d’analyse. Les ressources statiques, les styles et les scripts peuvent apparaître — ce sont les fichiers de la page. L’échec, c’est la chaîne d’origine qui part comme champ métier. Un titre ou un chemin qui dit « privacy » ou « clean » est attendu. Le contenu entier de la zone de saisie ne l’est pas.

1. Construisez une URL canari avec utm_*, fbclid et un id métier. N’utilisez ni un client réel ni un nom de campagne en cours.
2. Après nettoyage, contrôlez le tableau : clés de suivi du côté « retirées », id encore dans l’URL résultat.
3. Cherchez la chaîne canari dans Network. Un hit sur une requête métier signifie que l’original a quitté cet onglet.

La preuve est étroite : dans cette exécution, les clés de suivi connues ont disparu selon la règle, la clé métier est restée, et l’original n’a pas quitté cet onglet comme champ HTTP observé. Cela ne prouve pas qu’une extension n’a jamais lu la saisie, ni qu’un traceur custom hors table a été traité. Après un changement de navigateur ou de liste de règles, relancez le canari.

S’exercer sur une page qui s’ouvre sans compte

Si vous voulez un outil qui affiche la liste des clés retirées sur la page, commencez par Supprimer les UTM de MakePwd. Ouverture immédiate, sans inscription et sans compte. L’analyse d’URL et le retrait des paramètres se font dans cet onglet. Selon les notes produit, la chaîne d’origine n’est pas envoyée comme requête et n’est pas écrite dans les statistiques. Le mode standard retire utm_*, les identifiants de clic publicitaires, les paramètres d’analyse courants et des traceurs boutique fréquents comme spm. Le mode prudent ne retire que les UTM et les identifiants de clic. Le chemin et les paramètres métier tels que id et q restent. Vous pouvez envoyer jusqu’à 100 URL à la fois. Une ligne de plus de 8 Ko est refusée. Seuls http et https sont acceptés.

Exercez-vous avec le canari ci-dessus, pas avec un identifiant de clic d’une campagne en cours. Après une passe, regardez deux endroits : la liste des clés retirées dans le volet résultat, et Network pour la chaîne d’origine. La liste répond à « ai-je retiré les bonnes clés ». Network répond à « est-ce parti ». Les deux doivent passer avant que vous disiez à un collègue : voici les clés que j’ai retirées, et j’ai cherché le canari sans hit sortant.

Le nettoyage ne traite que la forme du lien. Téléphones, numéros de pièce d’identité, e-mails et clés API dans un chat ou un ticket appartiennent à l’outil de masquage de la même page, masqués par motif, puis relu par une personne. MakePwd ne revendique ni certification RGPD, ni équivalent. Si le résultat nettoyé reste un secret qui ne doit pas séjourner, envoyez-le une fois avec un lien auto-destructible et gardez la clé dans le fragment # de l’URL. Pour un fichier entier, utilisez Chiffrer un fichier sur cet appareil pour produire .lock / .enc, puis envoyez cela via un drive ou un e-mail. Aucune de ces étapes n’exige de connexion.

Questions fréquentes

Le destinataire atteindra-t-il encore la page sans les UTM ?

Oui, si les paramètres métier et le chemin restent. UTM et identifiants de clic servent l’attribution, pas le routage. Retirez utm_campaign ou fbclid et la landing doit encore s’ouvrir depuis le chemin et id. Une 404 ou un autre résultat signifie que vous avez touché une clé métier. Passez en mode prudent et comparez les clés une par une.

HTTPS protège-t-il déjà ces paramètres ?

Pas au moment de l’envoi. HTTPS abaisse le risque d’écoute sur le chemin. Il n’efface ni la barre d’adresse, ni l’historique, ni le chat, ni les journaux. OWASP indique que, même sur un canal chiffré, la query apparaît encore dans le Referer, les journaux web, les systèmes partagés et l’historique. Coller l’URL complète et savoir si le site a un certificat sont deux questions distinctes.

Apple retire des traceurs. Dois-je encore le faire moi-même ?

Oui. La fonction système s’applique sur des chemins documentés comme le partage dans Messages et la navigation privée de Safari, et Apple ne publie pas de liste complète. Les UTM restent en général. Quand vous collez dans un ticket ou dans un chat sous Android, ces protections ne s’exécutent pas pour vous. Une politique d’envoi regarde le presse-papiers, pas le fait que le système du destinataire retire encore une fois.

Une URL propre retire-t-elle aussi l’id produit ?

Non, si l’outil se base sur les noms. id, q et sku ne sont pas un préfixe utm_ et ne figurent pas dans la table courante des identifiants de clic. Le contrôle est un canari qui porte à la fois des clés de suivi et une clé métier, puis confirme que seules les premières ont disparu. Si un site écrit le suivi dans un nom custom, la table ne le connaîtra pas. Retirez cette clé à la main ou étendez la liste.

Trois points à retenir avant le prochain envoi

Premier : tout sélectionner dans la barre d’adresse n’équivaut pas à « sûr à envoyer ». Séparez la query en étiquettes de campagne, identifiants de clic, attribution interne et paramètres métier. Seule la dernière famille doit rester par défaut. Deuxième : HTTPS et un retrait automatique du système ne remplacent pas un contrôle du presse-papiers. La query atterrit dans l’historique, les tickets et les journaux, et elle peut voyager encore dans le Referer. Troisième : vérifiez deux endroits : la liste des clés retirées, et une recherche Network de votre canari.

Si la question suivante est de savoir si du clair a quitté cet onglet comme donnée métier, lisez Chiffrer dans le navigateur : comment vérifier que le texte en clair n’a pas quitté l’appareil. Cette note ne fait que transformer « quels champs de query ne devraient pas voyager quand vous envoyez une URL complète » en un périmètre que vous pouvez écrire dans une conclusion.