Pourquoi retirer les paramètres de suivi avant de partager un lien, et ce qu’il reste ensuite

Répondre à l’intention de recherche en une phrase

On retire les paramètres de suivi avant de partager un lien parce que la chaîne de requête fait partie de la cible HTTP. Quand le navigateur demande le document, utm_source, fbclid et gclid après le point d’interrogation s’écrivent dans la ligne de requête. L’hébergeur, un éventuel proxy inverse et le journal d’accès sont conçus pour les voir. Collez la chaîne entière dans Slack, Teams ou un ticket, et vous donnez aussi à la personne suivante le canal et la marque de clic.

Cette note s’adresse au support, à l’exploitation, et à quiconque veut séparer « ce que l’adresse écrit déjà » de « ce qui se passe encore après le chargement » avant de transférer une URL. Elle ne remplace pas le mode d’emploi du nettoyage de confidentialité, et elle ne répète pas quel bouton produit un lien propre. Ce qu’il faut emporter : ce qu’écrivent respectivement les UTM et les identifiants de clic, qui les hérite au partage, ce que le retrait peut encore prouver, et comment comparer ici la liste des retraits avec Network.

Ce qui suit le point d’interrogation entre dans HTTP

La RFC 3986 §3.4 définit la query comme le segment après le premier ? et avant le fragment. La RFC 9110 précise ensuite que l’URI cible de la requête inclut le chemin et la query, et exclut le fragment. Une barre d’adresse trop longue n’est pas un problème d’esthétique. Cette requête de document remettra les paires clé–valeur après le point d’interrogation à l’autre côté.

Le fragment après le dièse reste, par défaut, dans l’onglet actuel. Une note précédente explique déjà comment le vérifier. Celle-ci s’en tient au point d’interrogation. Gardez les deux règles sous les yeux, pour ne pas lire « le serveur ne voit jamais la clé après # » comme « le serveur ne voit pas non plus le canal après ? ».

L’API URLSearchParams du navigateur peut découper une query en paires, les supprimer par nom, puis reconstruire l’adresse. Un nettoyeur travaille à cette couche : il édite une chaîne. Il n’éteint pas les scripts de la page d’arrivée. Effacer utm_campaign ne coupe pas le pixel de l’autre site.

UTM écrit un canal, pas un suffixe décoratif

Google Analytics décrit le marquage manuel comme un ensemble de paramètres de requête utm_*. L’article d’aide associe les plus courants ainsi : utm_source à la source, utm_medium au support, utm_campaign au nom de campagne, plus utm_term, utm_content, utm_id, et des champs plus récents comme utm_source_platform. L’exemple officiel est http://www.example.com/?utm_source=google&utm_medium=cpc&utm_campaign=summersale. C’est le libellé de la note Analytics sur les sources de trafic, pas une reconstruction.

Ces valeurs aident la personne qui a lancé la campagne : le même article peut être compté à part depuis un e-mail, une description de vidéo et une annonce Slack. Pour la personne suivante qui ouvre le lien, ce sont une note en clair. Un ticket qui contient utm_source=vip_slack&utm_campaign=remboursement_202609 permet à quiconque cherchera ce ticket plus tard de lire « ce clic venait de cette campagne privée ».

Un UTM ne porte en général ni numéro de pièce d’identité ni phrase secrète. Ce qu’il fuit, c’est le contexte : quel e-mail vous avez ouvert, quelle publicité vous avez cliquée, si vous êtes arrivé par un lien réservé au support. Une fois ce contexte dans une URL partageable, il ne reste plus dans votre onglet.

Un identifiant de clic nomme un clic, pas une campagne

Un identifiant de clic est plus proche de « ce clic-ci » que d’un nom de campagne. Le marquage automatique de Google Ads ajoute gclid (Google Click Identifier) à l’URL d’arrivée. La forme officielle est www.example.com/?gclid=123xyz. Quand le marquage automatique est actif et que le site fait tourner Analytics, cette valeur peut aussi être écrite dans un cookie first-party, pour rattacher plus tard les conversions à ce clic. Voir la note Google Ads sur le marquage automatique.

Dans certains cas iOS 14 et suivants, gclid n’est pas utilisé sans consentement. Google a introduit gbraid (web vers application) et wbraid (application vers web) pour que la mesure publicitaire continue sous ces limites de plateforme. Cette distinction figure dans la note Analytics sur la mesure des campagnes iOS 14+ ; ce n’est pas une catégorie inventée par un nettoyeur.

Côté Meta, le nom courant est fbclid. La documentation développeur indique que si l’URL de la page porte ce paramètre de requête, l’API Conversions peut encore construire fbc à partir de lui. Si le site exécute Meta Pixel, l’identifiant de clic peut aussi être écrit dans un cookie first-party nommé _fbc, sous la forme version.subdomainIndex.creationTime.fbclid. La source est la note Meta sur fbp / fbc. Transférez une URL qui a encore fbclid, et le collègue qui l’ouvre peut encore laisser l’autre site stocker « ce clic » dans son propre cookie et dans les événements suivants.

La même famille apparaît sous msclkid, ttclid, twclid et li_fat_id. Chacun sert son propre compte publicitaire. Le fait commun est plus simple : écrit dans la query, il voyage avec la ligne de requête ; écrit dans la chaîne que vous partagez, la personne suivante l’hérite.

En partageant, la personne suivante hérite de toute la query

Les boutons « Partager », « Copier l’adresse » et un appui long sur un message copient en général l’URL complète actuelle, pas le chemin court que le site préférerait montrer en public. Slack, Outlook, WhatsApp et les aperçus publicitaires le rendent évident : vous croyez avoir copié un article ou un produit, et le presse-papiers tient un chemin plus une traînée de champs d’attribution.

Ces champs atterrissent alors à trois endroits. D’abord, le corps du chat ou du ticket, où tout le fil et quiconque cherchera plus tard peuvent les lire. Ensuite, la barre d’adresse de l’autre personne, et tout historique qui se synchronise depuis elle. Enfin, la requête de document qu’elle envoie à l’ouverture : le journal serveur contiendra la query complète. Effacer la ligne de votre propre conversation ne change rien pour ceux qui l’ont déjà ouverte, ni pour les journaux déjà écrits.

Déposer un lien de suivi de campagne dans une annonce publique, recoller tel quel la longue URL d’un utilisateur dans un ticket, et joindre à un ticket d’incident une URL de reproduction qui a encore gclid, c’est le même geste : vous avez transformé un contexte de clic qui était dans votre barre d’adresse en une marque que quiconque voit ces caractères peut réutiliser.

Ce que le retrait peut prouver, et ce que l’adresse garde

La conclusion qu’une URL nettoyée peut soutenir est étroite. L’écrire ainsi évite une lecture de trop. Elle peut prouver que, sur la liste que vous avez utilisée et pour cette passe, les utm_* connus, les identifiants de clic et (dans un mode plus large) certains champs d’attribution ont quitté la query. Le chemin est toujours là. Les paramètres métier comme id= et q= doivent rester par conception. Le lien doit encore ouvrir le même article.

Elle ne peut pas prouver que la page d’arrivée n’a pas de pixel, que l’autre site n’a pas de cookie first-party, qu’un saut de lien court n’ajoutera pas de nouveaux paramètres, que le chemin lui-même ne porte pas de jeton de suivi, ni qu’une extension n’a pas réécrit le presse-papiers. Elle ne peut pas non plus prouver « personne ne saura qui vous êtes après l’ouverture ». Vous avez édité la chaîne que vous allez envoyer. Vous n’avez pas édité la session de navigation suivante.

Les liens courts sont le faux succès le plus fréquent. Le raccourcisseur cache la vraie cible derrière sa propre redirection. Nettoyez https://short.example/abc : la query est souvent vide, donc l’outil signale qu’il n’a rien trouvé à retirer. Le suivi est sur l’URL longue après le 302. Pour contrôler, ouvrez le lien court en navigation privée et copiez l’URL finale dans la barre d’adresse. N’utilisez pas, pour cette étape, un lien court qui porte de vraies données privées.

Contrôler maintenant : liste des retraits et Network

Un slogan n’est pas une preuve. Deux contrôles que vous pouvez finir sur cet appareil : un sur le résultat propre, un sur le trafic sortant. Préparez un exemple jetable, par exemple :

https://example.com/article/42?id=42&q=aes&utm_source=newsletter&utm_medium=email&utm_campaign=partage_20260903&fbclid=IwAR0canaryfp&spm=demo.share.0

Placez le canari dans les valeurs de utm_campaign et de fbclid. Après nettoyage, l’adresse propre ne doit plus contenir partage_20260903 ni IwAR0canaryfp. id=42 et q=aes doivent encore être là.

1. Lisez d’abord la liste des paramètres retirés. Vous devez y voir utm_source, utm_medium, utm_campaign et fbclid. Dans un mode plus large, un nom d’attribution e-commerce comme spm doit aussi apparaître. Si la liste est vide alors que le lien « paraît propre », soupçonnez un raccourcisseur ou une marque dans le chemin.
2. Lisez ensuite le chemin de l’adresse propre et la query restante. Si l’identifiant d’article ou le mot recherché a disparu, c’est un dégât collatéral. N’envoyez pas ce résultat.
3. Ouvrez Network dans DevTools, activez Preserve log, et mettez le filtre sur All. Collez le canari dans la recherche. Il ne doit figurer ni dans les lignes de requête, ni dans les corps, ni dans les payloads analytics.

Le lien propre de FastPwd suit cette frontière : l’analyse a lieu dans l’onglet actuel ; une URL unique de plus de 8 Ko est refusée ; un lot est plafonné à 100 lignes ; seuls http / https sont acceptés. Le mode conservateur retire utm_* et les identifiants de clic (dont fbclid, gclid, gbraid, wbraid et msclkid). Le mode standard retire aussi _ga / _gl, des jetons d’e-mail comme mc_eid / mc_cid, des attributions de marketplace comme spm / scm, des préfixes comme _x_*, des jetons de partage comme share_token, et — sauf si vous les conservez — ref / referrer. Le chemin et id= / q= restent. L’outil est prêt à l’emploi ; il n’y a pas de compte. Analytics enregistre des noms d’événement tels que « nettoyage effectué », pas l’URL source. Une promesse n’est encore qu’une promesse. Fiez-vous à ce que cette passe montre dans la liste et dans Network.

Trois cas qui paraissent propres et n’ont rien retiré

Premier cas : le suivi est dans le chemin. Certaines pages de partage utilisent /s/xxxx ou un préfixe de canal dans le path, et la query est vide. Supprimer des clés de query par nom change à peine l’adresse. Comparez l’URL canonique après le saut, pas l’enveloppe de redirection que le bouton de partage vient d’émettre.

Deuxième cas : le nettoyeur édite searchParams et laisse hash intact. Si un traceur a été écrit après le dièse, le nettoyage de query signalera un succès. Le contrôle reste de poser la chaîne complète de la barre d’adresse à côté du résultat complet. Ne vous arrêtez pas aux caractères avant le point d’interrogation.

Troisième cas : vous avez nettoyé la chaîne que vous alliez envoyer, et le client de chat a ajouté des paramètres à la sortie. Certains clients tamponnent les liens sortants avec leurs propres marques de clic. Après l’envoi, ouvrez le message dans une autre fenêtre et relisez la barre d’adresse. Le nettoyage a lieu avant le collage. Vous contrôlez encore après l’envoi.

Questions fréquentes

Après avoir retiré les UTM, la personne qui ouvre le lien peut-elle encore être suivie ?

Oui. Vous avez retiré la query de la chaîne que vous allez envoyer. La page d’arrivée peut encore exécuter des pixels, des cookies first-party et une session connectée. La documentation Meta note aussi que, même si l’URL n’a plus fbclid, un site qui a déjà écrit _fbc peut encore l’attacher aux événements suivants. Le retrait prouve seulement que cette URL a perdu des paramètres de suivi connus. Il ne prouve pas que la visite suivante est anonyme.

Un nettoyeur d’URL va-t-il aussi supprimer l’identifiant d’article ou le mot recherché ?

Sur une liste par nom, le chemin et les paramètres métier comme id= ou q= doivent rester. En cas de doute, utilisez le mode conservateur, qui ne retire que utm_* et les identifiants de clic. Après nettoyage, lisez la liste des paramètres retirés. Ne traitez pas un lien plus court comme une preuve. Si une clé dont vous avez besoin figure sur cette liste, jetez ce résultat.

Faut-il d’abord retirer les paramètres de suivi d’un lien court ?

Un lien court n’a souvent aucun UTM. Le suivi se trouve sur l’adresse longue après la redirection. Nettoyer seulement la forme courte ne retire généralement rien. Ouvrez-le en navigation privée, copiez l’URL finale dans la barre d’adresse, puis retirez les paramètres de celle-ci. N’utilisez pas un lien court qui porte de vraies données privées comme test. Un exemple public suffit.

Quand je nettoie un lien sur FastPwd, l’URL d’origine est-elle envoyée ?

Selon les notes produit, l’analyse et le retrait se terminent dans l’onglet actuel. L’URL source n’est pas envoyée comme donnée métier HTTP et n’est pas écrite dans analytics. Analytics enregistre des noms d’événement tels que « nettoyage effectué ». Pour contrôler cette passe, cherchez le canari dans Network : il ne doit figurer ni dans les lignes de requête, ni dans les corps, ni dans les payloads analytics. Localhost n’envoie pas d’analytics par défaut ; recommencez le contrôle sur le nom d’hôte en ligne si vous voulez une passe plus proche de l’usage réel.

Comparer le même lien avec un outil prêt à l’emploi

Si vous voulez une page qui écrit la liste de retrait à découvert, ouvrez le nettoyage de confidentialité de FastPwd. Aucune inscription. Collez l’exemple ci-dessus, lancez le mode conservateur, puis le mode standard, et comparez les deux pastilles « retirés ». Les deux modes doivent emporter UTM et fbclid ; seul le mode standard doit toucher spm. Dans le résultat propre, id et q doivent encore être là.

La même page peut basculer vers le masquage de texte pour les téléphones et e-mails d’un corps de ticket ; c’est un autre article. Quand un secret entier doit atteindre un collègue, utilisez plutôt Burn-Link : chiffrez en local avec AES-256-GCM, ne stockez que le texte chiffré côté serveur, et gardez la clé après le dièse du lien. Ne collez pas dans le même fil une URL métier tout juste nettoyée et un Burn-Link complet.

Avant le prochain partage, retenez trois faits. Premier : le point d’interrogation entre dans HTTP ; le canal et les identifiants de clic y vivent. Deuxième : le retrait ne change que la chaîne que vous allez envoyer ; il n’éteint pas la mesure de la page d’arrivée. Troisième : les liens courts, les marques dans le chemin et les paramètres ajoutés après l’envoi demandent chacun leur propre contrôle. Une observation que vous pouvez répéter est celle qui mérite d’entrer dans votre propre consigne d’envoi.

Pour aller plus loin

Ne mélangez pas le point d’interrogation et le dièse. Pourquoi une clé peut tenir après #, et quelle couche tombe quand vous collez le lien entier dans un chat, se trouve dans Pourquoi un fragment d’URL peut porter une clé, et quand cette protection lâche. Comment comparer téléphones, numéros de pièce d’identité et clés API d’un ticket avant qu’ils quittent cet appareil est dans Avant de coller un ticket ou un journal dans une IA, vérifier quels champs quittent cet appareil. Pour confirmer que le nettoyeur lui-même n’a pas envoyé l’URL d’origine comme donnée métier, utilisez les étapes au canari de Vérifier que le chiffrement local n’envoie pas le texte en clair.