GA4 / Plausible : comment isoler réellement le trafic humain avec l’essor des agents IA ?

[EUSKAL CONSEIL]

Bonjour,

Je me pose une question sur la fiabilité actuelle des outils analytics comme GA4 ou Plausible pour mesurer uniquement le trafic humain.

Avec l’évolution de la recherche et des accès automatisés au Web, la frontière entre une visite humaine et une visite générée par un navigateur automatisé devient plus difficile à lire dans les outils analytics.

Un crawler classique qui se contente de récupérer le HTML ne déclenche généralement pas un script analytics côté client. En revanche, un système automatisé utilisant un environnement de navigateur capable d’exécuter JavaScript peut techniquement déclencher GA4 ou un autre outil de mesure.

Cela ne signifie évidemment pas que les systèmes d’AI Search fonctionnent tous ainsi, ni que le trafic inexpliqué observé dans GA4 ou Plausible provient de l’IA. C’est précisément cette incertitude que je cherche à mieux mesurer.

Or certains de ces systèmes sont capables d’exécuter du JavaScript côté client et peuvent donc, au moins techniquement, déclencher les scripts analytics.

Le problème est particulièrement visible dans le trafic Direct / None : une session enregistrée par GA4 ou Plausible peut évidemment correspondre à un humain dont le referrer a disparu, mais potentiellement aussi à une automatisation suffisamment proche du comportement d’un navigateur.

Plausible filtre déjà énormément de trafic automatisé, mais cela ne permet pas nécessairement de considérer que tout ce qui reste est humain.

Ma question est donc surtout destinée aux personnes qui ont travaillé techniquement sur ce sujet :

Avez-vous réussi aujourd’hui à améliorer ou compléter GA4/Plausible afin d’isoler de manière beaucoup plus fiable le trafic réellement humain du trafic généré par des bots, navigateurs automatisés, agents IA ?

 

[anemone-clown]

Bonjour,
ta question m'interpelle car je cherche à filtrer les bots "inutiles" et les agents IA des bots "utiles" et des "vrais" humains. Comme j'affiche de la Pub sur AquaPortail, ça se complique encore plus par rapport aux outils qui vérifie la légitimité de la connexion pour valider ou non une pub.

J'enregistre de façon simplifiée mais très ordonnée tout ce qui ne va pas répondre à certains critères et notamment par rapport à certains "languages", "referer" et autres valeurs accessibles soit via htaccess/apache, soit en php.

Pour l'instant, je réussis à filtrer certaines (pas mal!) choses mais c'est plus du bricolage perso que toute méthode exportable.

Pour le "referer", il est tellement facile à manipuler qu'il faut y prêter une attention très relative. Par exemple, iPhone ou SamsungBrowser vire systématiquement le referer et réaffiche la page dès que la fenêtre du navigateur a été occultée : tu peux donc identifier plusieurs pages lues (et sessions!), la même par la même IP, mais c'est probablement bel et bien un humain qui lit 1 seule page. Dans ce cas, comme plusieurs sessions ont été ouvertes, tu as plusieurs pages lues (la même) mais c'est, d'une certaine façon, faux.

Et je ne parle même pas des redondances d'un nom de domaine sur les serveurs dans plusieurs pays quand tu as la bonne option 'internationale' pour la NDD.

En résumé, à notre niveau, on ne peut pas espérer grand chose. Surtout si on tient compte que même GG Search ne parvient pas à filtrer lui-même les lectures automatisées sur ses résultats, tu imagines à notre niveau de pauvre admin...

 

[EUSKAL CONSEIL]

Si toi tu n'y arrives pas, moi non plus...je voulais même identifier le trafic venant de gmb en faisant des workers à l'époque sur cloudflare sur les fiches produits...mais ma gsc ne voulait pas indexer les workers car d'autres pages du site répondaient à la même intention de recherche....du coup vu les changements initiés par hostinger sur son builder, depuis mars 2026, j'ai du passer cloudflare en dns only...d'ailleurs le référencement s'en porte mieux, même si certaines pages sont plus lentes à charger que d'autres...et du coup mon geo fonctionne mieux mais j'ai 60% de trafic direct voire plus des fois et le reste les moteurs de recherche. Dans ce trafic direct, des fois ce sont des humains vu le temps de lecture mais d'autres fois, je ne peux pas me permettre d'être aussi affirmative....je me disais que comme ici on croisait des développeurs et des passionnés de vibe coding peut être que quelqu'un avait trouvé le truc, histoire quand même d'avoir des KPI honnêtes sur notre SEO et GEO....

 

[GEOpti]

Je raisonnerais en deux colonnes : trafic humain mesuré et visibilité IA. À mon avis, GA4/Plausible ne permettront pas d’isoler proprement 100 % des agents IA : dès qu’un navigateur exécute JS, ça ressemble trop à un vrai visiteur. Par contre on peut rendre les KPI plus honnêtes.
1. Côté analytics, créer un segment “suspect” plutôt qu’un filtre brutal : direct/none + 0 interaction + temps très court + user-agent/datacenter quand disponible. Et garder un segment “humain probable” : scroll, clic, page 2, formulaire, temps de lecture cohérent.
2. Côté GEO, ne pas déduire la visibilité IA depuis GA4. La mesurer à part, avec 10-20 requêtes clés testées régulièrement.
3. Mini-exemple fait aujourd’hui en web_search sur “meilleur dentiste à Lyon” : les sources visibles sont MyEstheticAdvisor, Dentego, Doctolib, ThreeBestRated et plusieurs cabinets locaux. Le gap pour un cabinet absent n’est pas seulement analytics : il manque souvent des preuves reprises par l’IA (fiche Google Business à jour, avis récents qui citent la ville/spécialité, pages répondant à une intention précise, présence dans les annuaires/comparateurs déjà visibles).
4. Côté site, ajouter du JSON-LD LocalBusiness/Organization et des pages très claires “dentiste urgence Lyon”, “implant dentaire Lyon”, etc., plutôt qu’une page générique.
Donc je traiterais GA4/Plausible comme mesure de demande, et le suivi GEO comme mesure de citation.

 

[EUSKAL CONSEIL]

Merci GEOpti pour ce cadrage très clair et cette approche par colonnes (demande vs citation).

Si je résume pour la mise en pratique concrète sur mon installation :

1. Côté Hostinger Website Builder :Comme l'éditeur ne permet pas de modifier le code source directement, le snippet JS doit être collé dans Paramètres du site > Intégrations > Code personnalisé (qui est le seul emplacement <head> disponible) :

HTML

<script>
let scrolled = false;
window.addEventListener('scroll', function() {
if ((window.scrollY + window.innerHeight) / document.body.offsetHeight > 0.3) {
scrolled = true;
}
});

setTimeout(function() {
if (scrolled && typeof plausible === 'function') {
plausible('Humain_Engage');
}
}, 10000);
</script>

2. Côté Plausible Analytics :

• Déclarer l'événement dans Settings > Goals > Add Goal > Custom Event avec le nom exact : Humain_Engage.
• Pour l'analyse sur le tableau de bord :
  
  • Segment « Humain probable » : Filtrer directement en cliquant sur l'objectif Humain_Engage en bas du dashboard pour n'isoler que les sessions ayant exécuté le JS et généré une interaction réelle (scroll + temps de lecture).
  • Segment « Trafic suspect » : Filtrer sur la source Direct / None, puis comparer le volume total de visites Direct avec le nombre de conversions Humain_Engage. L'écart (le delta) représente la part de navigateurs automatisés ou agents JS n'ayant eu aucun comportement humain.

Est-ce bien ainsi que tu concrétiserais la segmentation pour garder des KPI exploitables ?

 

[anemone-clown]

Au niveau du site, je donne un exemple de ce qui est indéterminable, ou plutôt probablement des données envoyées à un autre "service" en plus d'une lecture humaine.

31.32.160....   | lg =  (P=FR, C=EU) | Android10 SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:11:02
31.32.160....   | lg =  (P=FR, C=EU) | Android10 SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:11:26
31.32.160....   | lg =  (P=FR, C=EU) | Android10 SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:11:46
31.32.160....   | lg =  (P=FR, C=EU) | Android10 SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:12:07
31.32.160....   | lg =  (P=FR, C=EU) | Android10 SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:12:26
31.32.160....   | lg =  (P=FR, C=EU) | Android10 SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:12:46
31.32.160....   | lg =  (P=FR, C=EU) | Android10 SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:13:06
31.32.160....   | lg =  (P=FR, C=EU) | Android10 SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:26:33
31.32.160....   | lg =  (P=FR, C=EU) | Android10 SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip) | referer =  | URI = /fiche-poisson-2575-hyphessobrycon-heliacus.html | 2026/09/06 15:15:14
31.32.160....   | lg = fr-FR,fr,en-US,en (P=FR, C=EU) | Linux SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip, deflate, br) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:10:41
31.32.160....   | lg = fr-FR,fr,en-US,en (P=FR, C=EU) | Linux SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip, deflate, br) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:25:51
31.32.160....   | lg = fr-FR,fr,en-US,en (P=FR, C=EU) | Linux SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip, deflate, br) | referer =  | URI = /fiche-poisson-2575-hyphessobrycon-heliacus.html | 2026/09/06 15:14:52
31.32.160....   | lg = fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7 (P=FR, C=EU) | Linux SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip, deflate, br) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:15:57
31.32.160....   | lg = fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7 (P=FR, C=EU) | Linux SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip, deflate, br) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:24:44
31.32.160....   | lg = fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7 (P=FR, C=EU) | Linux SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip, deflate, br) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 15:26:47
31.32.160....   | lg = fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7 (P=FR, C=EU) | Linux SamsungBrowser/26.0 Chrome/122.0.0.0 Safari/537.36 (gzip, deflate, br) | referer =  | URI = /fiche-poisson-2238-hyphessobrycon-elachys.html | 2026/09/06 16:26:05

En résumé, avec la même IP (bouygues, donc une IP personnelle, pas un serveur), les pages ont été rechargées (j'ai expliqué plus haut) plusieurs fois par 3 systèmes différents, mais tout indique que des données ont été envoyées à un service tiers (typique du SamsungBrowser, c'est quasi-systématique!). Comment classer une telle IP??? Le referer est absent, la méthode de compression change, et même l'indicateur de langue change... un vrai binz!

C'est pour cette raison que je pense qu'à notre niveau, il devient impossible de distinguer les "vraies" visites des lectures automatisées.

 

[anemone-clown]

Certaines lectures peuvent être détectées comme supposément du "spam". Exemple:

38.3.195.22     | lg = en-US,en;q=0.9 (P=US, C=NA) | WinNT10 Chrome/145.0.0.0 Safari/537.36 (gzip) | referer = https://www.aquaportail.com/especies/lista/familia/serranidae | URI = /especies/ficha/pez/2467/odontanthias-tapui | 2026/09/07 07:34:35

Le referer indiqué et la page lue semblent tout à fait correct, on pourrait donc penser que c'est un humain. L'IP correspond à un réseau Cogent aux USA. Bref, tout semble valable. Mais en fait, non, il y a un problème : la méthode compression ($_SERVER['HTTP_ACCEPT_ENCODING'] en PHP) est uniquement GZIP et ça ne correspond pas aux possibilités normales de Chrome 145 pour lequel la compression devrait être "gzip, deflate, br, zstd". Que décider??? Véritable lecture ou système de spam???

 

[EUSKAL CONSEIL]

Justement c'est ce qui me fait un peu flipper car l'idée était d'aller jusqu'au tracking de leads une fois l'entité réconciliée sur toutes les pages et le nurturing cognitif en place, mais la grande difficulté c'est que les trackers de leads se mettent dans le head dans un builder comme le mien, ou peut être dans les pages avec wp code sur wordpress, mais ils enregistrent aussi les bots et le reste du trafic...ce qui fait que le budget de tracking de leads peut exploser pour un rendement en leads tièdes ou chauds minime....en raison de cette forte activité de bots et d'IA, et je ne parle même pas du ralentissement du site, quand on n'a pas les proxys sur cloudflare, en raison de cette grosse activité....je suis désolée anemone de ne pas avoir compris du premier coup ton langage technique...merci pour ta pédagogie

 

[alex_builds_eu]

De mon côté j'ai regardé les logs bruts plutôt que l'analytics, sur une fenêtre de 30 heures : 696 requêtes, un seul visiteur humain identifiable. Je ne l'ai pas repéré dans GA4 mais dans le log. Chez moi GA4 est derrière le consentement, et comme un bot ne consent jamais, l'écart entre le log et GA4 me sert d'estimation haute de la part machine.

Le cas qui m'a le plus surpris : un bot qui s'annonce ShapBot, 541 requêtes depuis des IP GCP, zéro appel à robots.txt, et qui va chercher sw.js, le manifest et qui poste sur mon endpoint de refresh de session. Autrement dit il exécute le SPA. Celui-là finit dans GA4 sans difficulté, et la politesse comme critère de tri ne l'attrape pas du tout.

Ce qui marche mieux chez moi c'est le jeu de ressources plutôt que l'UA. Les passages machine prennent le manifest, le service worker et les icônes PWA, et ne prennent jamais les polices. L'humain tire un woff2 et des SVG avec le referer de sa propre page. C'est grossier mais ça tient mieux que toutes les listes d'UA que j'ai essayées.

Sur la logique en deux colonnes de GEOpti, un chiffre qui va dans son sens : Claude-SearchBot est passé 25 fois sur la même fenêtre sans lire une seule page de contenu, uniquement sitemap-index.xml et robots.txt. Mesurer la visibilité IA avec le compteur du trafic n'a donc pas beaucoup de sens. Après je suis sur un petit volume, donc sur un site à fort trafic le signal des ressources se comporte peut-être autrement, là je ne peux pas dire.

 

[anemone-clown]

@alex_builds_eu : je confirme pour ShapBot, un indésirable...

 

[EUSKAL CONSEIL]

Bonjour anemone et alex_builds, j'étais en conversation avec getquanty un logiciel de tracking de leads B2B (impossible de le faire en B2C en Europe) qui m'a confirmé qu'il était possible de filtrer les bots et IA des vrais visiteurs B2B mais parce qu'ils peuvent aller jusqu'à l'adresse IP en les confrontant avec les bases de données...je n'ai pas encore fait l'essai car c'est quand même 90€ par mois, à ce jour snitcher était pas mal pour le faire mais ils ont du mal à éliminer le trafic lié aux IA....et c'est quand même comptabilisé dans la facture finale d'identification....quant à visitor queue il n'y a aucun filtre possible, même le passage de googlebot semble comptabilisé....

 

[alex_builds_eu]

Sur le filtrage par IP, la partie qui coûte cher dans ces outils n'est pas la détection. Les plages d'adresses des gros hébergeurs sont publiées par les hébergeurs eux-mêmes, en JSON, et se recoupent en local avec les logs : chez moi les 541 requêtes de ShapBot sortaient toutes de GCP, c'était visible sans rien acheter. Ce que tu paies chez eux, c'est plutôt la base qui relie une IP d'entreprise à un nom d'entreprise, et ce n'est pas du tout le même travail que d'écarter les machines.

Je n'ai jamais utilisé getquanty, mais le point que je vérifierais avant de signer à 90 €, c'est l'ordre des opérations côté facturation : les visiteurs identifiés sont comptés avant ou après leur filtre ? Une IP de datacenter peut très bien se résoudre en société d'hébergement et rentrer dans le quota comme un lead.

À ta place je leur demanderais un test sur 24 h de tes propres logs, avec le détail de ce qu'ils écartent. Si leur compte et le tien divergent fortement, tu sauras de quel côté est le problème avant de payer le premier mois.

 

[EUSKAL CONSEIL]

Ce qui me bloque surtout c'est qu'une entreprise comme la mienne aura plus facilement du lead exploitable venant de gbp plus que du site web, or le script c'est sur le site web et comme je suis sur un builder fermé je ne peux pas me dire que je vais mettre le script sur les pages que je veux suivre afin de rentabiliser les choses rationnellement...ensuite la solution qu'ils me proposent ressemble à un outil de scrapping et je ne suis pas convaincue d'obtenir les bons mails.. d'autant que la réponse de la commerciale est particulièrement vide techniquement et ressemble à du closing plus qu'un argumentaire convaincant....hormis me permettre de grappiller quelques adresses pour ma newsletter mensuelle qui ne me rapporte rien...j'ai du mal à croire à la rentabilité économique de l'affaire si ce n'est de vérifier la qualité de leur outil et si bel et bien ma stratégie seo/geo m'a permis d'attirer du trafic qualifié en dehors des curieux universitaires, consultants, éducation nationale, et parfois des médias....je trouve toutefois que ça fait cher pour un indépendant...