D'où vient l.facebook.com et pourquoi les clics arrivent en Direct

Qu'est-ce que l.facebook.com ?

Facebook réécrit les liens sortants pour que chaque clic passe par l.facebook.com, le rebond intermédiaire que Meta appelle le link shim, avant que le navigateur n'atteigne votre page. Le blog d'ingénierie de Meta a nommé l'outil en 2012 et l'a décrit comme un moyen « to warn people about potentially spammy or malicious links. » Ce nom d'hôte est un service de redirection et rien d'autre. Demandez le domaine nu et il répond HTTP/2 302 avec location: https://www.facebook.com/, vérifié le 12 septembre 2026.

Meta s'en sert toujours sur ses propres propriétés. Chaque lien sortant du pied de page de developers.facebook.com passe par le shim, ce qui permet de lire le format sur une page en direct plutôt que sur une capture.

À quoi ressemble une URL l.facebook.com ?

Deux paramètres de requête portent tout. La destination est encodée en pourcentage dans u, et une signature se trouve dans h :

https://l.facebook.com/l.php?u=https%3A%2F%2Fwww.llama.com%2F&h=AUCy45wK_2QEcW5a...

Comme l'URL de destination complète est encodée en pourcentage dans u, sa propre query string survit au rebond. Tout utm_source ou utm_campaign que vous placez sur un lien est encore attaché à l'arrivée du navigateur.

Le paramètre h n'est pas un hachage de la destination. Deux requêtes de la même page Meta le 12 septembre 2026 ont produit deux valeurs h différentes pour la même cible llama.com, ce qui signifie que la signature est liée à la session qui a rendu le lien, pas à l'URL. Copiez un lien passé au shim hors de Facebook et collez-le ailleurs : il ne résout pas. Une requête l.php signée comme une requête non signée ont renvoyé HTTP/2 400 avec la page générique « Sorry, something went wrong » de Facebook lorsqu'elles étaient émises hors de la session d'origine.

Meta exploite des noms d'hôte parallèles pour ses autres surfaces, et tous se comportent de la même façon.

Pourquoi Facebook fait-il passer les clics par un shim ?

Pour deux raisons que Meta énonce sans détour, et une seule vous coûte quelque chose. La première est le filtrage des logiciels malveillants. La seconde est la restriction délibérée du referrer.

Le billet de 2012 de Meta « A faster, better link shim » décrit la refonte toujours en place. Plutôt que de vérifier un lien après le clic, « we now check every link on the page before it's sent to the browser, » et « if we find a link to be suspicious, we use the old interstitial warning page; otherwise we allow the user through to the link itself. » Meta a chiffré le gain à « around a second every time they click an external link. »

La moitié referrer est énoncée tout aussi clairement, sous un intertitre appelé Restricting the Referrer : « We still need to let the websites you navigate to know the traffic is from Facebook, but we also want to prevent them from reading the full source url. Otherwise, they could know where on the site you were when you clicked their link. » Ce n'est pas un effet de bord. C'est l'objectif de conception.

Que fait le link shim à votre referrer ?

Il vous remet une origine au lieu d'une URL. Le billet de 2012 de Meta dit avoir « taken advantage of a new feature called the meta referrer, » qui « allows us to specify how much of the source url to share with the external site via the Referer header. » La balise est toujours sur la page aujourd'hui. Une requête sur www.facebook.com le 12 septembre 2026 renvoie ceci dans le head :

<meta name="referrer" content="origin-when-crossorigin" id="meta_referrer">

Cette chaîne cache un accroc. La spécification W3C Referrer Policy définit exactement neuf jetons valides, et origin-when-crossorigin n'en fait pas partie. Le jeton écrit en entier est origin-when-cross-origin, avec un trait d'union entre cross et origin. La spécification dit aussi que « unknown policy values will be ignored, » et que « the default referrer policy is strict-origin-when-cross-origin. »

Les deux chemins finissent au même endroit pour vous. Si un navigateur accepte l'orthographe héritée de Meta, les navigations cross-origin n'envoient que l'origine. S'il la rejette et retombe sur la valeur par défaut, les navigations cross-origin n'envoient toujours que l'origine. Dans les deux cas, l'en-tête Referer qui arrive sur votre serveur est une origine nue comme https://l.facebook.com/, jamais la publication, le groupe ou le profil d'où partait le clic.

Le seul cas où vous n'obtenez rien du tout est une rétrogradation de protocole. Sous strict-origin-when-cross-origin, une navigation d'une page HTTPS vers une destination HTTP « would send no Referer header. » Un site qui sert encore du HTTP simple perd l'attribution entièrement.

Pourquoi le trafic l.facebook.com arrive-t-il en Direct dans les analytics ?

Parce que l'en-tête Referer n'est pas arrivé, pas parce que Google étiquette mal le nom d'hôte. C'est là que la plupart des conseils sur le shim prennent le problème à l'envers.

Google publie la liste des sources qu'il rattache à des canaux, et l.facebook.com, lm.facebook.com, l.instagram.com et l.messenger.com y figurent tous comme SOURCE_CATEGORY_SOCIAL. Le canal Organic Social de GA4 correspond quand la source « matches a regex list of social sites » ou quand le support est l'un de social, social-network, social-media et assimilés. Un clic qui arrive avec l'origine du shim est donc déjà classé en Organic Social. Il n'y a rien à corriger et aucune exclusion de référence à ajouter.

Le canal Direct a une définition bien plus étroite : la source correspond exactement à (direct) et le support est (not set) ou (none). Rien n'y atterrit par erreur de classement. Les sessions y atterrissent quand la balise analytics n'a ni referrer ni paramètres de campagne à exploiter. Trois situations produisent cela :

• Une rétrogradation de protocole, où la spécification dit qu'aucun Referer n'est envoyé.
• Un passage d'un navigateur intégré vers le navigateur système, où la nouvelle navigation n'est pas un clic sur un lien et ne porte aucun referrer propre.
• Un lien copié-collé, qui arrive sans referrer par définition puisque personne n'a cliqué sur quoi que ce soit.

La forme générale de ce panier, et ce qui y tombe d'autre, est traitée dans cette explication du trafic direct.

Comment cesser de perdre l'attribution ?

Balisez l'URL avant qu'elle n'atteigne le compositeur, car le shim préserve la query string qu'il enveloppe. La destination est portée encodée en pourcentage dans u, donc utm_source=facebook&utm_medium=social&utm_campaign=spring-launch survit à la redirection et parvient intact à vos analytics. Les paramètres de campagne l'emportent aussi sur le referrer dans la correspondance de canaux de GA4, ce qui signifie qu'un lien balisé est classé de la même façon que l'en-tête Referer apparaisse ou non. Les conventions de nommage qui gardent cela cohérent d'un réseau à l'autre sont détaillées dans ce guide des paramètres UTM.

L'enveloppement de liens n'est pas une bizarrerie de Facebook. X fait la même chose avec son propre raccourcisseur, en réécrivant chaque URL publiée en un lien t.co avec ses propres effets sur ce que voit votre serveur. Le côté crawler de Meta a la même double personnalité : la carte d'aperçu est construite par une requête distincte du crawler facebookexternalhit bien avant qu'un humain ne clique sur le shim.

Deux ensembles de chiffres méritent de rester séparés. Les impressions, la portée et les clics enregistrés côté Facebook viennent des API de Meta, ce qu'un outil comme adaptlypost expose sous analytics des réseaux sociaux. La session qui atterrit sur votre site est un autre enregistrement, tenu par vos propres analytics, et le link shim se loge dans l'écart entre les deux. Baliser l'URL, c'est ce qui le referme.

Questions fréquentes

Dois-je ajouter l.facebook.com à ma liste d'exclusion de références ?

Non. La liste de sources publiée par Google rattache déjà l.facebook.com à SOURCE_CATEGORY_SOCIAL, donc GA4 rapporte ces sessions en Organic Social plutôt qu'en référence générique. Exclure le nom d'hôte supprime le referrer et pousse ces sessions vers Direct, soit exactement le résultat que la plupart des gens cherchent à éviter.

Puis-je savoir de quelle publication Facebook vient un clic ?

Pas par le referrer. L'objectif de conception affiché par Meta est de « prevent them from reading the full source url, » et l'en-tête qui arrive sur votre serveur est une origine comme https://l.facebook.com/ sans chemin. Une valeur utm_content unique par publication est le seul moyen de distinguer deux publications.

Pourquoi un lien l.facebook.com collé ne fonctionne-t-il pas ?

Parce que le paramètre h est une signature liée à la session qui a généré le lien, pas à la destination. Une requête l.php hors de cette session a renvoyé HTTP/2 400 et la page d'erreur générique de Facebook, aussi bien dans un test signé que non signé, le 12 septembre 2026.

Quelle est la différence entre l.facebook.com et lm.facebook.com ?

La surface qui a généré le clic. lm.facebook.com est l'équivalent web mobile, et le nom d'hôte nu redirige vers https://m.facebook.com/?_rdr là où l.facebook.com redirige vers https://www.facebook.com/. Google classe les deux comme sources sociales.

Le link shim supprime-t-il mes paramètres UTM ?

Non. L'URL de destination est encodée en pourcentage en entier dans le paramètre u, query string comprise, donc les balises de campagne arrivent avec le visiteur. Les paramètres disparaissent quand un lien est ressaisi ou raccourci à la main avant publication, pas au niveau du shim.

Tous les liens Facebook passent-ils par le shim ?

La description de Meta de 2012 dit que les liens sont contrôlés avant l'envoi de la page au navigateur, et que les liens suspects reçoivent une page d'avertissement interstitielle tandis que tout le reste est laissé passer vers le lien lui-même. Meta ne publie aucune règle sur les liens réécrits en l.php et ceux qui ne le sont pas, alors considérez le rebond comme présent par défaut et balisez en conséquence.

Pourquoi Facebook fait-il passer un clic par l.facebook.com au lieu de lier directement vers ma page ?

Meta donne deux raisons à ce détour : vérifier les liens contre les malwares avant même que le clic n'atteigne le navigateur, et limiter la part de l'URL source qui quitte Facebook. La vérification anti-malware se fait sur la page elle-même, avant tout clic. La restriction du referrer est tout aussi voulue et figure sous le propre titre de Meta, Restricting the Referrer.

La vérification anti-malware du link shim ralentit-elle les clics ?

Meta indique l'inverse. La refonte de 2012, qui vérifie les liens avant qu'ils n'atteignent le navigateur, a fait gagner environ une seconde à chaque clic externe par rapport à l'ancien système, qui vérifiait après le clic. Les liens suspects reçoivent toujours la page d'avertissement intermédiaire, et tout le reste passe directement vers la destination.

Pourquoi deux personnes obtiennent-elles des valeurs h différentes pour le même lien shimmé ?

Le paramètre h n'est pas un hash de l'URL de destination, c'est une signature liée à la session du navigateur qui a généré le lien. Interroger deux fois la même page Meta le 12 septembre 2026 a produit deux valeurs h différentes pour la même destination llama.com, ce qui montre que la valeur dépend de la session et non du lien. Un lien copié échoue en dehors de cette session, même quand sa valeur h est récente.

Comment voir la vraie destination d'un lien l.facebook.com avant de cliquer ?

La destination est encodée en pourcentage dans le paramètre u de l'URL, avec le reste de la chaîne de requête, y compris utm_source ou utm_campaign. Décoder ce paramètre montre la page exacte visée par le lien sans passer par le shim. Le paramètre h juste à côté n'est qu'une signature de session et ne dit rien sur la destination.