Navigateurs IA dans GA4 : détecter les sessions Atlas et Comet

Vos sessions de navigateurs IA sont déjà dans GA4, et elles se font passer pour du Chrome. Comet et les agents type ChatGPT n’envoient pas un user-agent distinctif sur le rendu de page, refusent ou bloquent le tracking par défaut, et cassent la continuité de session. Résultat : des « nouveaux utilisateurs » qui n’en sont pas, du Direct qui gonfle sans campagne, et des sessions à engagement nul qui plombent vos moyennes. Le problème, ce n’est pas que la donnée est fausse. C’est que personne ne mesure ce qu’il perd, parce que personne ne sait repérer ces sessions.

Petite précision de vocabulaire, parce qu’on confond tout depuis six mois. Il y a le trafic venant d’une IA (quelqu’un clique sur un lien dans une réponse ChatGPT ou Perplexity, c’est un problème d’attribution de canal, traité dans Tracker le trafic ChatGPT, Gemini et Claude dans GA4). Et il y a le trafic piloté par une IA : l’agent EST le navigateur. C’est ce dont on parle ici, et c’est un problème de qualité de donnée, pas d’attribution.

Un mot sur le calendrier, parce que ça bouge vite. OpenAI a arrêté l’application autonome ChatGPT Atlas le 9 août 2026, neuf mois après son lancement. Ne rangez pas le sujet pour autant. Les sessions Atlas des derniers mois sont encore dans votre historique GA4 et polluent vos comparatifs, ses capacités d’agent ont migré vers l’extension Chrome de ChatGPT, l’app desktop et un navigateur distant côté cloud, et surtout Comet, lui, monte. En juillet 2026, Comet pèse environ 47 % du trafic agentique mesuré par HUMAN Security, l’extension Claude pour Chrome environ 24 %, Atlas environ 15,5 % et en déclin. La marque Atlas s’efface, la catégorie explose.

Trois symptômes à vérifier dans GA4 en cinq minutes

Avant la théorie, le diagnostic. Ouvrez GA4 et regardez trois choses.

D’abord, la courbe des nouveaux utilisateurs sur les 90 derniers jours. Un palier qui monte sans campagne, sans pic saisonnier, sans rien pour l’expliquer, c’est un premier signal. Les agents ne persistent pas les cookies entre deux exécutions : chaque visite repart de zéro, donc chaque visite est un « nouvel utilisateur ».

Ensuite, la part de Direct. Un agent qui ouvre votre page sans referrer atterrit dans le seau Direct comme n’importe quel accès sans provenance. Si votre Direct grimpe alors que votre notoriété n’a pas bougé, méfiance.

Enfin, le temps d’engagement médian par appareil et par navigateur. Comparez desktop macOS aux autres segments. Une session agentique lit le DOM en quelques centaines de millisecondes et repart : elle tire vers le bas la moyenne d’engagement du segment où elle se cache. Si vous voyez un segment desktop avec un engagement anormalement faible, vous tenez votre piste. Pour distinguer ce bruit d’une vraie erreur de configuration (trafic interne, doublons, unassigned), passez d’abord votre propriété au crible de l’audit GA4 des 11 erreurs de configuration.

Pourquoi c’est invisible : ce que fait chaque navigateur

La raison pour laquelle vos rapports standards ne voient rien, c’est que chaque navigateur IA sabote le tracking à un endroit différent de la chaîne. Voici le comportement observé sur les principaux acteurs.

La ligne qui fait mal, c’est la deuxième pour Comet : son bloqueur intégré filtre les scripts d’analytics par défaut. Quand un utilisateur visite votre site via Comet avec le blocage actif, vous ne voyez souvent rien du tout côté client. Pas une session amputée, zéro session. À l’inverse, Comet transmet fréquemment le referrer perplexity.ai, donc une partie de son trafic apparaît quand même en referral. Vous avez donc deux populations Comet : celle qui passe par le tag GA4 classique et celle qui est totalement absente de vos rapports client-side.

Pour l’agent héritier d’Atlas, le piège est plus subtil. Le contenu de la page est chargé via une instance Chrome au user-agent parfaitement normal. Seul le fetch des favicons et logos part avec la signature ChatGPT Atlas/… CFNetwork/… Darwin/…. Autrement dit, la preuve existe, mais elle n’est pas là où on la cherche : elle est dans vos logs serveur, sur une requête annexe, pas dans le hit GA4 principal.

Conclusion intermédiaire : tout signal exploitable vit à la couche serveur. Le client-side est aveugle par construction. C’est pour ça que la détection sérieuse passe par un conteneur server-side.

Détecter : les signaux côté serveur et la dimension ai_browser

Si vous n’avez pas encore de conteneur GTM server-side, c’est le prérequis, et le sujet est couvert dans GTM Server-Side : pourquoi et comment migrer. L’idée : au lieu de faire confiance au navigateur, vous inspectez la requête telle qu’elle arrive sur votre endpoint de collecte, là où les en-têtes survivent.

Trois familles de signaux sont exploitables.

Les Client Hints d’abord. L’en-tête sec-ch-ua et ses variantes exposent la marque et la version du moteur. Une incohérence entre ce que déclare le user-agent et ce que disent les Client Hints est un marqueur classique d’environnement automatisé. Ajoutez sec-ch-ua-platform et sec-ch-ua-mobile pour affiner.

La signature réseau ensuite. Sur les requêtes annexes, la chaîne CFNetwork couplée à Darwin trahit une application macOS native qui n’est pas un navigateur classique. Isolée, elle ne prouve rien. Croisée avec un pattern de navigation (une seule page, pas de scroll, temps sur page quasi nul, pas de requête d’asset lourd), elle devient un indice fort.

Les patterns comportementaux enfin. Absence de referrer sur une session desktop macOS, séquence d’événements trop régulière, absence totale d’interaction. Aucun de ces signaux ne suffit seul. C’est leur accumulation qui fait la détection, et c’est pour ça qu’on parle d’heuristique, pas de certitude.

Dans votre conteneur sGTM, vous posez une variable qui évalue ces signaux et écrit une dimension personnalisée ai_browser sur l’événement avant de le transmettre à GA4. Voici la logique, en pseudo-code de variable personnalisée (Sandboxed JavaScript) :

// Variable personnalisée sGTM : classe la requête entrante
const getHeader = require('getRequestHeader');
const ua = getHeader('user-agent') || '';
const chUa = getHeader('sec-ch-ua') || '';
const referer = getHeader('referer') || '';

// 1. Signature native macOS hors navigateur classique
if (ua.indexOf('CFNetwork') !== -1 && ua.indexOf('Darwin') !== -1) {
  return 'chatgpt_atlas';
}
// 2. Marqueur Perplexity conservé dans le referrer
if (referer.indexOf('perplexity.ai') !== -1) {
  return 'comet_or_perplexity';
}
// 3. Incohérence Client Hints / user-agent (heuristique)
if (ua.indexOf('Chrome') !== -1 && chUa === '') {
  return 'suspect_headless';
}
return 'human';

Vous mappez ensuite la valeur retournée vers un paramètre d’événement ai_browser, déclaré comme dimension personnalisée dans l’interface GA4. À partir de là, chaque session est étiquetée, et vous pouvez segmenter au lieu de subir. Attention, ce code est une base à durcir : les signatures changent, on y revient plus bas.

Quantifier : chiffrer la distorsion dans BigQuery

Une dimension, c’est bien. Un chiffre à mettre sur la table d’un client ou d’un comité, c’est mieux. Si l’export BigQuery n’est pas actif, branchez-le, puis inspirez-vous des requêtes BigQuery indispensables pour GA4. La requête ci-dessous mesure l’écart entre trafic humain présumé et trafic suspect sur trois métriques qui parlent : part de sessions, ratio nouveaux/connus, et temps d’engagement médian.

SELECT
  COALESCE(
    (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'ai_browser'), 'human') AS bucket,
  COUNT(DISTINCT CONCAT(user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params)
     WHERE key = 'ga_session_id'))) AS sessions,
  ROUND(AVG(
    (SELECT value.int_value FROM UNNEST(event_params)
     WHERE key = 'engagement_time_msec')) / 1000, 1) AS avg_engagement_s
FROM `votre_projet.analytics_XXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260831'
GROUP BY bucket
ORDER BY sessions DESC;

Ce que vous cherchez : un bucket chatgpt_atlas ou comet_or_perplexity avec un temps d’engagement plancher et un volume non négligeable. Le jour où vous mettez un pourcentage dessus (« 4 % de nos sessions sont des agents, avec un engagement dix fois inférieur »), le sujet passe de curiosité à décision.

Décider : filtrer, segmenter ou garder ?

Voici mon avis, et il tranche : ne filtrez pas aveuglément. La tentation est de créer un filtre GA4 qui exclut tout ce qui est étiqueté ai_browser et de passer à autre chose. C’est une erreur dans la majorité des cas.

Une session pilotée par un agent est très souvent une session de recherche pré-achat lancée par un humain. Quelqu’un demande à son assistant de comparer trois produits, l’agent visite votre fiche, en extrait le prix et les specs, et restitue à l’humain qui décide. Supprimer cette session, c’est perdre du signal de demande réelle. Pire, quand l’agent va jusqu’à l’achat, vous voulez le mesurer, pas l’effacer, et c’est tout l’enjeu du commerce agentique dans GA4.

Ma recommandation, dans l’ordre :

1. Segmenter d’abord. Gardez la donnée, isolez-la avec la dimension ai_browser. Vos rapports « humains » redeviennent propres sans rien jeter.
2. Filtrer ensuite, et seulement le trafic clairement autonome. Un agent qui boucle, qui scanne sans jamais convertir, qui n’a aucune valeur analytique : là, oui, une audience d’exclusion se justifie.
3. Garder brut en parallèle. Une propriété ou un flux non filtré vous sert de référence pour ne pas piloter à l’aveugle.

Point de vigilance sur le consentement. L’ex-Atlas refusait fréquemment les bannières, et Comet bloque une partie du stack analytics. Concrètement, une grande part de ce trafic tombe en denied côté Consent Mode, ce qui alimente la modélisation des conversions plutôt que la mesure directe. Si vous ne comprenez pas encore comment ce basculement affecte vos chiffres, Consent Mode v2 dans GA4 pose les bases. Traiter les agents comme des humains sans consentement fausse doublement vos modèles.

Les limites honnêtes

Je ne vais pas vous vendre une détection parfaite, parce qu’elle n’existe pas.

La méthode est heuristique. Vous travaillez sur des faisceaux d’indices, pas sur une étiquette officielle. Vous aurez des faux positifs (un vrai utilisateur macOS avec un adblock agressif) et des faux négatifs (un agent bien camouflé qui passe pour un humain).

Les signatures changent. CFNetwork/Darwin marche aujourd’hui parce que l’implémentation le laisse fuiter. La prochaine version peut router ce fetch différemment, et votre règle tombe. C’est de la maintenance, pas du « configurer et oublier ».

Et Comet en mode blocage reste invisible. S’il coupe GA4 et GTM au chargement, aucun signal n’atteint votre conteneur, server-side compris, puisque le tag ne part jamais. La seule contre-mesure fiable est l’analyse de vos logs serveur bruts, en dehors de GA4. C’est un autre chantier.

Dernier rappel de fond : chaque nouveau signal client-side qui disparaît renforce l’argument server-first. Les navigateurs IA ne sont qu’un symptôme de plus de cette bascule, au même titre que la fin de Privacy Sandbox. Si votre mesure dépend encore entièrement du navigateur en 2026, ce ne sont pas les agents votre vrai problème.

Récap actionnable

Ouvrez GA4, vérifiez les trois symptômes (nouveaux utilisateurs en palier, Direct qui gonfle, engagement desktop macOS anormalement bas). Si ça matche, posez une dimension ai_browser dans votre conteneur server-side à partir des signaux d’en-têtes, chiffrez la distorsion avec la requête BigQuery, puis segmentez avant de filtrer quoi que ce soit. Gardez en tête que la marque Atlas disparaît mais que la catégorie, Comet en tête, ne fait que commencer. La donnée que vous nettoyez aujourd’hui est celle sur laquelle vous piloterez vos budgets demain.