Le trafic LLM est un angle mort de vos analytics. Voici pourquoi.

Votre canal IA grandit. Vos analytics ne suivent pas.

ChatGPT, Gemini, Claude, Perplexity et d’autres LLM génèrent plus de trafic que vous ne le pensez. Le volume n’arrive pas au compte-gouttes, il s’accélère à un rythme qui commence à rivaliser avec les canaux établis. Certains analystes estiment que le trafic de référence IA pourrait dépasser les référencements traditionnels de recherche d’ici 2028. Nous pensons que, sur certains sites, cela se produit déjà.

Cet article explique pourquoi, en s’appuyant sur des tests pratiques sur mobile et desktop, des modes debug de navigateur, du logging de requêtes côté serveur et d’autres techniques, à travers trois plateformes LLM majeures: ChatGPT, Gemini et Claude.

D’abord, comprenez où se trouvent vos utilisateurs

Avant d’aborder ce qui casse et quand, il est utile de comprendre l’ampleur du problème par type d’appareil.

Le mobile est la plateforme dominante pour le trafic web. Selon Cloudflare Radar, qui suit les requêtes HTTP sur un réseau traitant plus de 20% de tout le trafic web mondial, les appareils mobiles représentent environ 50% de toutes les requêtes web. Ce chiffre doit être considéré comme un plancher: le réseau de Cloudflare transporte un volume significatif de trafic API, de services B2B et d’outillage pour développeurs, tout cela étant fortement orienté desktop. Le trafic web grand public est considérablement plus orienté mobile. Sur les comptes GA4 avec lesquels nous travaillons au quotidien, le mobile représente généralement entre 70% et 90% des sessions totales. Le trafic desktop est réel, mais secondaire.

Le mobile est l’endroit où l’attribution LLM échoue le plus complètement. L’appareil que la plupart de votre audience utilise est celui où la mesure est la plus cassée.

Ce que nous avons testé

Pour comprendre exactement où le suivi casse, nous avons mené des tests pratiques sur des appareils mobiles et desktop, en utilisant les applications natives et les navigateurs web pour ChatGPT, Gemini et Claude. Les tests ont été réalisés sur un iPhone avec la dernière version d’iOS, un appareil Android avec la dernière version d’Android, un Mac avec la dernière version de macOS et un PC Windows avec la dernière version de Windows.

Pour chaque scénario, nous avons examiné si les paramètres UTM étaient présents, si un referrer était transmis au site de destination, et si l’identité de session persistait lorsqu’un utilisateur passait de l’interface LLM à un navigateur standard.

Voici ce que nous avons trouvé.

Les résultats en un coup d’œil

Mobile: là où se trouve la majorité du trafic, et là où le suivi casse

Le tableau ci-dessus raconte l’histoire assez clairement. Pour les applications mobiles, le signal traçable est faible ou inexistant. Mais pourquoi?

La réponse est la web view, et il vaut la peine de comprendre ce que cela signifie réellement avant d’entrer dans les spécificités de chaque plateforme.

Lorsqu’un utilisateur tape sur un lien dans une application LLM mobile, que ce soit ChatGPT, Gemini ou Claude, le lien s’ouvre généralement dans un navigateur intégré isolé appelé web view. Cette web view ne partage ni cookies, ni données de session, ni identité avec le navigateur natif de l’appareil. Tout état de suivi établi à l’intérieur de cette web view y reste piégé.

Conséquence pratique: lorsqu’un utilisateur termine sa navigation dans l’application LLM et ouvre plus tard son navigateur habituel pour continuer ses recherches ou convertir, il n’y a aucune continuité. Aucune identité partagée. Aucun relais. Cette visite devient du trafic direct non attribué.

ChatGPT sur mobile est l’option la plus traçable parmi celles testées. L’application transmet utm_source=chatgpt.com sur les liens sortants, et techniquement il existe un chemin vers l’attribution, mais il dépend d’une séquence d’événements peu probable. Pour que cet UTM survive jusqu’à une conversion, l’utilisateur devrait taper sur le lien dans ChatGPT, être emmené dans la web view intégrée, puis taper explicitement sur “Ouvrir dans le navigateur” pour transférer la session vers son navigateur natif avant de poursuivre. À noter que ce parcours ne maintient la session que sur les appareils Android. Sur iOS, même cette solution rompt la continuité de la session.

En pratique, quelqu’un vous découvre dans ChatGPT. Il lit quelque chose à votre sujet, tape peut-être brièvement vers votre site, puis passe à autre chose. Plus tard, peut-être une heure après, peut-être deux jours après, il vous cherche sur Google, ou tape directement votre URL, et c’est à ce moment qu’il peut entamer le processus de conversion. Cette session ne porte aucune trace de l’interaction ChatGPT qui a tout déclenché. L’UTM a disparu. Le referrer a disparu. GA4 l’enregistre comme trafic direct ou organique, et ChatGPT n’obtient aucun crédit. Et oui, c’est vrai même si vous avez activé des fonctionnalités de suivi comme Google Signals dans votre propriété GA4.

Gemini et Claude sur mobile ne transmettent ni paramètres UTM ni referrer dans aucun scénario testé. Les sessions issues de ces plateformes arrivent comme du trafic direct pur. Aucun signal ne les rattache au LLM qui les a générées.

Une nuance mérite d’être notée: si un utilisateur découvre un site et convertit dans la web view, il existe une continuité de session interne au sein de ce contexte isolé. La web view conserve ses propres cookies entre les sessions, donc un parcours réalisé entièrement dans l’application est théoriquement mesurable. Les limitations standard du suivi par cookies s’appliquent toujours, et la fréquence à laquelle les utilisateurs complètent une boucle de conversion entière dans une web view d’application est en soi une question ouverte à explorer.

Desktop: mieux, mais toujours inconsistant

Le desktop offre des conditions de suivi plus favorables que le mobile, mais le tableau reste fragmenté selon la plateforme et l’interface utilisées.

Contrairement au mobile, les applications LLM desktop ne piègent pas les liens dans des web views isolées. Elles transmettent directement les liens sortants au navigateur par défaut de l’utilisateur. Le problème d’isolement de la web view ne s’applique donc pas sur desktop. Ce qui s’applique encore, c’est de savoir si la plateforme prend la peine de transmettre les UTM ou un referrer, et sur ce point, les résultats sont mitigés.

ChatGPT sur desktop (application native) transmet utm_source=chatgpt.com sur les liens sortants, le scénario desktop le plus fiable de toutes les plateformes testées. ChatGPT dans le navigateur transmet un referrer mais aucun UTM.

Gemini n’a pas d’application desktop sur Mac ou Windows. Toute utilisation de Gemini sur desktop passe par le navigateur. Gemini dans le navigateur transmet un referrer mais aucun UTM, même histoire que ChatGPT en navigateur.

Claude est le plus faible dans tous les scénarios desktop. L’application desktop native ne transmet ni UTM ni referrer. Claude dans le navigateur ne transmet rien non plus. Chaque session de Claude sur desktop arrive comme du trafic direct totalement non attribué, quel que soit le moyen par lequel l’utilisateur est arrivé.

Le problème cumulatif: même une bonne attribution ne survit pas toujours jusqu’à la conversion

Supposons un instant que le suivi fonctionne. L’UTM est renseigné, le referrer est présent, la session est attribuable. Vous pourriez penser que vous êtes couvert.

Vous ne l’êtes pas.

Le chemin d’une interaction LLM à une conversion complétée est rarement une session unique. Un utilisateur découvre quelque chose via ChatGPT sur son téléphone dans la journée. Il clique sur le lien, atterrit sur la page, navigue pendant quelques minutes. Il repart sans convertir. Deux jours plus tard, il revient sur son ordinateur portable pour finaliser. À ce moment-là, l’UTM original peut avoir expiré, l’appareil peut être différent, les cookies peuvent avoir disparu.

L’expiration des cookies, les parcours multi-appareils et les chemins multi-sessions cassent chacun indépendamment l’attribution. Ensemble, ils garantissent que même la fraction des sessions référées par un LLM qui sont correctement étiquetées au premier point de contact recevront rarement le crédit de la conversion finale.

Ce n’est pas un problème propre au trafic LLM. Mais il frappe plus fort ici parce que la découverte assistée par LLM tend à se produire plus tôt dans le parcours de considération, les gens cherchent et explorent, ils ne sont pas prêts à acheter. L’écart entre cette première visite influencée par l’IA et la conversion éventuelle est plus long qu’une fenêtre typique de clic payant à conversion, ce qui aggrave le problème multi-appareils.

Ce que cela signifie pour vos données

Mettons quelques chiffres approximatifs sur tout cela. L’objectif n’est pas une fausse précision: c’est une plage raisonnable qui vous aide à comprendre l’ampleur de ce qui vous échappe probablement.

Commencez par la répartition par appareil. Cloudflare Radar situe le trafic web mondial mobile à environ 50% de toutes les requêtes HTTP, et ce chiffre est sous-estimé pour les audiences grand public, car le réseau de Cloudflare transporte un lourd mélange de trafic API et de trafic de développeurs. Dans les comptes GA4 avec lesquels nous travaillons, le mobile représente généralement entre 70% et 90% des sessions. Nous utilisons 70% ici pour rester prudents.

Ensuite, il y a la question de savoir comment les gens utilisent réellement les LLM sur leur téléphone. Tout le monde n’utilise pas l’application native. Certains accèdent à ChatGPT, Gemini ou Claude via leur navigateur mobile, et l’utilisation via navigateur est sensiblement plus traçable. Deux hypothèses encadrent la plage.

Hypothèses de base utilisées dans les deux cas:

• Répartition mobile/desktop: 70% mobile, 30% desktop
• Taux de survie du signal d’application: 20% des clics d’application mobile transmettent avec succès un signal utilisable (par ex. un utilisateur Android tapant “Ouvrir dans le navigateur”, ou une conversion se produisant dans la web view)
• Attrition du chemin de conversion: pénalité de 25% appliquée pour la perte de signal due aux sauts multi-appareils et aux cookies expirés
• Facteur Google AIO: une part de la découverte influencée par l’IA se produit désormais via Google AI Overviews et AI Mode, que GA4 enregistre comme recherche organique standard sans moyen de séparation

La plage

Les hypothèses ci-dessus sont des estimations, n’hésitez pas à saisir des chiffres qui reflètent mieux votre propre audience ou vos propres hypothèses. Utilisez une autre répartition mobile, un autre ratio application/navigateur, un autre taux d’attrition. Le modèle n’est pas destiné à être précis. Il est destiné à montrer que peu importe les chiffres raisonnables choisis, la conclusion est la même: il y a une sous-déclaration substantielle en cours, et l’écart est suffisamment grand pour avoir de l’importance.

Avec nos hypothèses, la plage va d’environ 2,5x dans le cas optimiste à 5x dans le cas plus pessimiste, et potentiellement plus une fois que l’on intègre les sessions organiques Google influencées par les LLM, impossibles à séparer avec les analytics standards.

Si votre tableau de bord indique que 1,5% de vos sessions proviennent de LLM, il est probable qu’entre 4% et 8% de ces sessions soient en réalité issues de LLM, et ce chiffre croît rapidement. C’est un canal entier qui se cache dans vos rapports Direct et Organique.

Peut-on y remédier?

Partiellement. Il n’existe pas de solution complète, mais il y a des améliorations significatives à la portée des équipes prêtes à investir dans des analytics et un suivi plus sophistiqués.

Le suivi côté serveur et le logging de requêtes peuvent capturer des signaux que le JavaScript côté client rate entièrement. Les outils de fingerprinting d’appareils peuvent maintenir une identité probabiliste entre les contextes de web view et de navigateur sur le même appareil, comblant partiellement l’écart d’isolement que le suivi standard par cookies ne peut franchir. Aucune approche ne permet d’atteindre une mesure complète, et aucune ne résout le problème multi-appareils sans un état d’utilisateur connecté pour ancrer ensemble les deux sessions.

La réponse honnête: vous n’obtiendrez jamais une mesure complète. L’architecture des systèmes d’exploitation mobiles, les politiques de referrer des plateformes LLM et la nature des parcours multi-sessions et multi-appareils jouent tous contre. Mais ce n’est pas la chose la plus importante à comprendre à propos de ce canal.

L’objectif de la mesure n’est pas un décompte parfait de chaque conversion: c’est une compréhension directionnelle suffisamment bonne pour prendre des décisions. Vous n’avez pas besoin d’attribuer chaque conversion assistée par LLM pour savoir que ce canal grandit, que votre part y est quelque chose que vous pouvez influencer, et que les changements relatifs apportés à votre stratégie de visibilité IA se verront dans vos chiffres. Si votre trafic référé par LLM double après avoir restructuré votre contenu pour une meilleure citation IA, ce mouvement est significatif, que vous puissiez ou non relier chaque vente à une session de chat spécifique.

Cet article n’est pas un argument pour abandonner la mesure. C’est un argument pour ne pas laisser une mesure imparfaite devenir une excuse pour l’inaction. Les équipes qui traitent la visibilité IA comme un canal de croissance sérieux dès maintenant, pas quand l’attribution sera plus propre, pas quand GA4 rattrapera son retard, mais maintenant, sont celles qui construisent une avance qu’il sera difficile de rattraper.

Méthodologie

Les tests ont été menés sur un iPhone exécutant la dernière version d’iOS, un appareil Android exécutant la dernière version d’Android, un Mac exécutant la dernière version de macOS et un PC Windows exécutant la dernière version de Windows. Linux n’a pas été testé directement, mais devrait suivre des schémas similaires. Chaque plateforme LLM, ChatGPT, Gemini et Claude, a été testée via son application native (lorsque disponible) et via le navigateur de l’appareil. Pour chaque scénario, nous avons examiné si les paramètres UTM étaient renseignés, si un referrer était transmis au site de destination, et si l’identité de session persistait lorsque la navigation passait de l’interface LLM au navigateur par défaut de l’appareil. Le logging côté serveur a été utilisé pour compléter les observations côté client.

Cette recherche reflète le comportement des plateformes au moment des tests (12 avril 2026). Les plateformes LLM mettent à jour fréquemment leurs applications et interfaces web, et le comportement de suivi peut changer.

L’essentiel

Les canaux IA ne sont pas une considération future. Ils sont actifs maintenant, en croissance, et façonnent des décisions à grande échelle. Le problème est que l’infrastructure utilisée par la plupart des équipes pour mesurer ces canaux a été construite pour un monde où un clic produisait un referrer fiable et un cookie durant suffisamment longtemps pour voir une conversion.

Ce n’est pas ainsi que fonctionne le trafic LLM.

Traitez vos chiffres de canal IA comme une sous-déclaration significative. Les sessions que vous voyez sont celles qui ont réussi à survivre à chaque couche de perte de suivi. Celles qui n’y sont pas parvenues sont bien plus nombreuses, et elles incluent des personnes qui vous ont trouvé, qui ont été influencées par ce qu’une IA a dit à votre sujet, et qui ont converti sans laisser aucune trace à suivre.

Questions fréquemment posées

Pourquoi mon GA4 affiche-t-il presque aucun trafic provenant de Claude ou Gemini?

Parce que les deux plateformes ne transmettent aucun paramètre UTM et aucun referrer dans la grande majorité des scénarios que nous avons testés. Sur mobile, les liens s’ouvrent dans des web views isolées intégrées à l’application, qui ne se connectent jamais à votre environnement analytique standard. Sur desktop, Claude ne transmet rien, ni dans l’application, ni dans le navigateur. Gemini transmet un referrer dans le navigateur mais aucun UTM. Sans l’un ou l’autre, la majeure partie de ce trafic arrive dans GA4 comme trafic direct ou n’est tout simplement pas comptabilisée.

ChatGPT apparaît dans mes rapports. Cela signifie-t-il qu’il est suivi correctement?

Pas tout à fait. ChatGPT est la plateforme la plus traçable parmi les trois que nous avons testées. Il ajoute utm_source=chatgpt.com dans plusieurs scénarios, et son application desktop le fait de manière fiable. Mais sur mobile, le chemin vers l’attribution est étroit et dépendant de la plateforme. L’UTM peut survivre si l’utilisateur tape sur “Ouvrir dans le navigateur” dans la web view, mais cela ne fonctionne que sur Android. Sur iOS, ce transfert ne préserve pas la session du tout. L’identité est perdue lorsque l’utilisateur quitte la web view, peu importe comment il en sort. Donc, même dans le meilleur des cas, il faut que l’utilisateur soit sur Android, utilise l’application, et tape expliquement sur “Ouvrir dans le navigateur” avant de naviguer plus loin. Cela représente une petite tranche de votre trafic mobile ChatGPT réel. Les chiffres que vous voyez dans GA4 sont réels, mais ils représentent une fraction de ce que ChatGPT génère réellement.

Ce problème n’affecte-t-il que les utilisateurs mobiles?

Le mobile est l’endroit le plus sévère, mais le desktop n’est pas propre non plus. Claude sur desktop ne transmet rien dans tous les scénarios testés, application ou navigateur. Gemini sur desktop transmet un referrer mais aucun UTM, ce qui peut ou non être classifié correctement selon votre configuration GA4. L’application desktop de ChatGPT est le seul point lumineux fiable. Donc, même si votre audience était entièrement sur desktop, vous passeriez quand même à côté d’une part significative du trafic influencé par les LLM.

Qu’est-ce qu’une web view et pourquoi cause-t-elle des problèmes de suivi?

Une web view est un navigateur intégré à l’application qui s’ouvre lorsque vous tapez sur un lien à l’intérieur d’une application mobile. Elle ressemble à un navigateur, mais elle est isolée du véritable navigateur de votre appareil. Elle ne partage ni cookies, ni données de session, ni identité avec Safari ou Chrome. Donc tout suivi qui se déclenche à l’intérieur d’une web view y reste piégé. Lorsque l’utilisateur ouvre plus tard son vrai navigateur pour poursuivre son parcours, il apparaît comme un tout nouveau visiteur sans historique.

Si la conversion finale se produit dans la web view de l’application, est-elle suivie?

Elle peut l’être, mais ce n’est pas propre. La conversion doit avoir lieu dans la web view pour que la chaîne d’attribution tienne. L’utilisateur n’a pas besoin d’avoir passé tout son parcours là, mais cette dernière étape, oui. Le hic, c’est qu’iOS représente la majorité du trafic mobile pour la plupart des audiences, et sur iOS la web view est soumise aux restrictions de cookies de WebKit, y compris Intelligent Tracking Prevention. Ces restrictions peuvent limiter ou rompre la continuité sur laquelle vous comptez. Donc, bien que ce scénario soit théoriquement traçable, en pratique c’est l’option la moins cassée disponible plutôt qu’un chemin fiable.

Puis-je résoudre cela avec le suivi côté serveur?

Le suivi côté serveur aide, mais il ne résout pas tout. Il peut capturer des signaux que le JavaScript côté client manque, y compris des données de referrer qui n’atteignent jamais GA4. Les outils de fingerprinting d’appareils peuvent aussi aider en maintenant une identité probabiliste entre les contextes de web view et de navigateur sur le même appareil. Mais aucune approche ne résout le problème multi-appareils, et aucune ne vous donne une mesure complète. Vous vous rapprocherez significativement de la vérité, mais vous n’irez pas jusqu’au bout.

De combien le trafic de conversion assisté par LLM est-il réellement sous-déclaré?

Selon notre analyse, entre 2,5x et 5x, selon votre audience et la manière dont elle utilise les plateformes LLM. L’estimation prudente (Cas A) suppose que la moitié des utilisateurs mobiles accèdent aux LLM via le navigateur, où le suivi fonctionne largement, produisant environ une sous-déclaration de 2,5x après prise en compte des pertes du chemin de conversion. L’estimation plus réaliste (Cas B) suppose que 80% des utilisateurs mobiles sont sur l’application native, où le suivi échoue essentiellement, produisant une sous-déclaration de 4 à 5x. Les deux estimations restent probablement prudentes, car une part croissante de ce que GA4 classe comme organique Google est en réalité du trafic influencé par les LLM arrivant via AI Overviews et AI Mode, un trafic impossible à séparer avec les analytics standards.

Devrais-je investir davantage dans la visibilité IA si je ne peux pas mesurer les résultats?

Oui, sans doute davantage, et non l’inverse. Le fait que vous ne puissiez pas mesurer l’impact complet de ce canal ne signifie pas que l’impact n’existe pas. Cela signifie que vos outils actuels sont sous-qualifiés pour le voir. Les sessions qui parviennent à vos rapports montrent déjà un engagement significatif. Celles qui n’y arrivent pas sont des ordres de grandeur plus nombreuses. Traiter ce canal comme peu important parce que les chiffres paraissent petits est exactement la mauvaise conclusion à tirer.