Comment mesurer le trafic IA ?

Trafic IA et Web Analytics : le guide de référence pour mesurer les assistants, agents, crawlers et moteurs génératifs

ChatGPT, Gemini, Claude, Perplexity, Copilot, AI Overviews, agents autonomes… Les systèmes d’intelligence artificielle changent déjà la manière dont les internautes découvrent les sites web. Pourtant, la plupart des outils Analytics continuent d’observer le Web comme s’il était encore dominé par Google Search et les navigateurs classiques.

Résultat : une partie grandissante des interactions échappe aux tableaux de bord. Certaines visites sont mal attribuées. D’autres ne sont jamais enregistrées. D’autres encore ne correspondent plus à une navigation humaine.

Le véritable défi n’est donc plus uniquement de mesurer les visiteurs. Il devient nécessaire de comprendre quels systèmes IA consultent votre site, pourquoi ils le consultent et quelles conséquences cela a sur votre visibilité, votre infrastructure et votre activité.

Dans cet article, je vais volontairement laisser de côté les raccourcis habituels. Non, le trafic IA ne se résume pas aux visiteurs provenant de ChatGPT. Non, un RAG n’est pas un type de trafic. Et non, Google Analytics ne peut pas mesurer l’ensemble des interactions générées par les intelligences artificielles.

L’objectif est beaucoup plus ambitieux : comprendre précisément ce qui se passe aujourd’hui sur le Web et apprendre à construire une mesure réellement exploitable.

Pourquoi le trafic IA bouleverse-t-il la Web Analytics ?

Pendant plus de vingt ans, la Web Analytics a reposé sur une hypothèse simple : un internaute visite un site web avant d’obtenir une réponse.

Découvrez égalementSouveraineté des données ou résidence des données ?

Le parcours était relativement prévisible. Une recherche sur Google, Bing ou un autre moteur, quelques clics dans les résultats, puis une visite sur un ou plusieurs sites. Une fois la page chargée, Google Analytics, Matomo ou une autre solution Analytics enregistrait la session et le comportement du visiteur.

Ce modèle existe toujours.

Mais il n’est plus systématique.

Aujourd’hui, de plus en plus d’internautes commencent leur recherche auprès d’une intelligence artificielle comme ChatGPT, Gemini, Claude ou Perplexity. Avant même qu’ils consultent votre site, ces assistants peuvent analyser plusieurs sources, comparer les informations disponibles et produire une réponse synthétique.

Votre contenu continue donc d’être utilisé.

Découvrez égalementSouveraineté des données quelle différence avec résidence ?

En revanche, il n’est plus forcément consulté.

C’est probablement le changement le plus important que la Web Analytics ait connu depuis l’apparition des moteurs de recherche.

Comment le parcours utilisateur évolue-t-il ?

Pendant des années, le parcours d’un internaute ressemblait à ceci.

Question
    │
    ▼
Moteur de recherche
    │
    ▼
Liste de résultats
    │
    ▼
Votre site
    │
    ▼
Google Analytics

Le moteur de recherche jouait un rôle d’intermédiaire. Il orientait l’utilisateur vers les sites les plus susceptibles de répondre à sa question. Le clic constituait donc le principal indicateur de visibilité.

Aujourd’hui, un nouvel intermédiaire s’est installé entre l’utilisateur et votre contenu.

Question
    │
    ▼
Assistant IA
(ChatGPT, Gemini,
Claude, Perplexity…)
    │
 ┌──┴──────────────┐
 ▼                 ▼
Lecture de plusieurs sites
        │
        ▼
Analyse et synthèse
        │
        ▼
Réponse générée
        │
        ▼
Clic éventuel
        │
        ▼
Votre site

Découvrez égalementComment bâtir une stratégie de mesure web utile ?

Le mot important est éventuel.

Hier, le clic était quasiment obligatoire.

Aujourd’hui, il devient une possibilité.

L’utilisateur peut obtenir une réponse satisfaisante sans jamais visiter votre site.

Pourquoi ce changement est-il si important ?

Prenons une recherche très simple.

Quelle est la meilleure formation n8n en français ?

Il y a quelques années, l’utilisateur aurait probablement ouvert plusieurs résultats Google, comparé les programmes, consulté les avis puis choisi un organisme de formation.

Aujourd’hui, un assistant IA peut effectuer une grande partie de ce travail à sa place.

Il consulte plusieurs sources, identifie leurs points forts, compare les informations puis construit une réponse.

Deux scénarios deviennent alors possibles.

Dans les deux cas, votre contenu participe à la réponse.

Dans un seul, Google Analytics enregistre une visite.

Autrement dit, votre contenu peut créer de la valeur sans générer de trafic.

Le trafic reflète-t-il encore la visibilité d’un contenu ?

Pendant longtemps, trafic et visibilité évoluaient presque toujours dans le même sens.

Plus une page était visible dans les moteurs de recherche, plus elle recevait de visiteurs.

Les assistants IA remettent progressivement cette relation en question.

Une page peut désormais être consultée, résumée et citée dans des centaines de conversations sans qu’aucun utilisateur ne clique sur le lien source.

À l’inverse, quelques dizaines de visiteurs provenant d’un assistant IA peuvent représenter davantage de valeur commerciale que plusieurs centaines de visites issues d’un moteur de recherche traditionnel. L’utilisateur arrive souvent avec un besoin déjà clarifié et une intention beaucoup plus forte.

Le trafic reste donc un indicateur essentiel.

En revanche, il ne suffit plus à mesurer l’influence réelle d’un contenu sur le Web.

Pourquoi la Web Analytics doit-elle évoluer ?

Pendant plus de vingt ans, la question principale était relativement simple :

Combien de visiteurs mon site reçoit-il ?

Cette question reste importante.

Mais elle ne suffit plus.

Les professionnels de la Data et de la Web Analytics doivent désormais répondre à de nouvelles interrogations.

• Combien de visiteurs proviennent réellement des assistants IA ?
• Quels contenus sont utilisés pour produire leurs réponses ?
• Quels robots explorent régulièrement mon site ?
• Quels agents IA exécutent des actions sur mes pages ?
• Quelle partie de cette activité échappe complètement aux outils Analytics ?

La Web Analytics ne consiste donc plus uniquement à mesurer des visites.

Elle consiste désormais à comprendre comment les intelligences artificielles interagissent avec votre contenu, qu’elles génèrent ou non un clic.

C’est précisément cette évolution qui a fait apparaître une nouvelle expression : le trafic IA.

Encore faut-il savoir ce qu’elle recouvre réellement.

Qu’appelle-t-on réellement « trafic IA » ?

Depuis l’explosion des assistants conversationnels, l’expression trafic IA est omniprésente. On la retrouve dans les conférences, les études SEO, les tableaux de bord Analytics et les articles spécialisés.

Le problème, c’est que chacun semble lui donner une définition différente.

Pour certains, le trafic IA correspond uniquement aux visiteurs provenant de ChatGPT ou de Perplexity. Pour d’autres, il englobe tous les robots d’intelligence artificielle qui parcourent le Web. Certains y incluent également les agents autonomes capables d’effectuer des actions à la place d’un utilisateur.

Toutes ces définitions sont partiellement vraies.

Aucune n’est réellement complète.

Avant de chercher à mesurer le trafic IA, il faut donc commencer par définir précisément ce que l’on souhaite mesurer.

Une définition plus rigoureuse du trafic IA

J’utiliserai la définition suivante tout au long de ce guide.

Le trafic IA désigne l’ensemble des interactions entre des systèmes d’intelligence artificielle et un site web, qu’elles soient initiées par un utilisateur, un assistant conversationnel, un crawler, un agent autonome ou une application exploitant un modèle de langage.

Cette définition présente un avantage majeur.

Elle ne se limite pas aux visiteurs.

Elle englobe également toutes les interactions qui utilisent votre contenu sans forcément générer une visite mesurable.

Autrement dit, le trafic IA ne correspond pas uniquement à ce que Google Analytics enregistre.

Il représente l’ensemble des échanges entre les intelligences artificielles et votre site web.

Pourquoi existe-t-il autant de confusion ?

Une grande partie des confusions vient du fait que plusieurs phénomènes très différents sont regroupés sous une même expression.

Prenons quatre situations courantes.

Ces quatre scénarios sont souvent regroupés sous l’expression trafic IA.

Pourtant, ils n’ont pratiquement rien en commun.

Dans le premier cas, un véritable utilisateur visite votre site.

Dans le deuxième, seul un robot consulte vos pages.

Dans le troisième, un agent réalise une tâche au nom d’un utilisateur.

Dans le quatrième, votre contenu influence la réponse générée par l’IA… sans qu’aucune visite ne soit enregistrée.

Chercher à mesurer ces quatre situations avec un seul indicateur n’a donc aucun sens.

Le trafic IA n’est pas un nouveau canal d’acquisition

Depuis quelques mois, certains tableaux de bord proposent un canal intitulé IA ou AI Traffic.

L’idée est séduisante.

Elle est pourtant réductrice.

Un canal d’acquisition décrit généralement l’origine d’une visite.

Par exemple :

• Recherche naturelle
• Recherche payante
• Réseaux sociaux
• Email
• Accès direct

Le trafic IA est différent.

Il ne décrit pas uniquement l’origine d’une visite.

Il décrit une nouvelle manière d’interagir avec le Web.

Une intelligence artificielle peut :

• recommander votre contenu ;
• le résumer ;
• le comparer avec d’autres sources ;
• l’utiliser pour répondre à une question ;
• consulter votre documentation ;
• interroger une API ;
• exécuter une action sur votre site.

Certaines de ces interactions produisent une visite.

D’autres jamais.

Réduire le trafic IA à un simple canal d’acquisition reviendrait donc à ignorer une grande partie du phénomène.

Une autre confusion fréquente : le « trafic RAG »

Depuis quelques mois, une autre expression apparaît régulièrement : trafic RAG.

Là encore, le terme est trompeur.

Le RAG (Retrieval-Augmented Generation) n’est ni un visiteur, ni un robot, ni un agent.

Il s’agit d’une architecture permettant à un modèle de langage de récupérer des informations externes avant de générer sa réponse.

Autrement dit, le RAG ne visite jamais votre site.

C’est l’application qui implémente cette architecture qui peut éventuellement consulter votre contenu.

Parler de « trafic RAG » revient donc à confondre une technologie avec le système qui l’utilise.

Il est beaucoup plus juste de parler :

• d’un assistant IA utilisant un RAG ;
• d’une application exploitant un RAG ;
• d’un agent enrichissant son contexte grâce à un RAG.

La nuance paraît subtile.

Elle est pourtant essentielle lorsqu’on souhaite construire des indicateurs fiables.

Toutes les interactions IA ne se ressemblent pas

Avant d’aller plus loin, retenez une idée simple.

Les intelligences artificielles n’interagissent pas toutes avec votre site de la même manière.

Certaines cherchent simplement une information.

D’autres parcourent systématiquement l’ensemble de votre contenu.

Certaines exécutent des tâches.

D’autres répondent directement à leurs utilisateurs.

Le tableau suivant résume ces différents comportements.

Cette distinction constitue la base de tout le reste.

Avant de parler de Google Analytics, de Matomo ou des logs serveur, il faut d’abord comprendre que le trafic IA n’est pas un phénomène unique.

Il s’agit d’un ensemble de comportements très différents qui nécessitent chacun leur propre méthode de mesure.

La première étape consiste donc à apprendre à les distinguer.

C’est précisément ce que nous allons voir dans la section suivante.

Quels sont les différents types de trafic IA ?

Parler du trafic IA comme d’un phénomène unique est probablement la plus grande source de confusion actuelle.

En réalité, les intelligences artificielles n’interagissent pas toutes avec votre site de la même manière, n’ont pas les mêmes objectifs et, surtout, ne laissent pas les mêmes traces. Un assistant conversationnel, un crawler ou un agent autonome peuvent tous consulter votre contenu, mais leur comportement n’a pratiquement rien en commun.

Avant de choisir un outil de mesure, il faut donc commencer par identifier qui interagit avec votre site et dans quel objectif.

Une même page peut être consultée par quatre types de systèmes

Prenons une page intitulée « Formation n8n : programme complet ».

Au cours d’une même journée, elle peut être sollicitée par plusieurs systèmes différents.

                     Votre page web
                           │
      ┌──────────────┬─────┴──────────────┬──────────────┐
      ▼              ▼                    ▼              ▼
 Assistant IA     Crawler IA         Agent IA      Application IA
(ChatGPT...)      (GPTBot...)       (Operator...)     (RAG...)
      │              │                    │              │
 Répondre à      Découvrir le       Réaliser une     Exploiter une
 une question      contenu             tâche         information

Pour votre serveur, ces quatre systèmes envoient des requêtes HTTP.

Pour votre outil Analytics, en revanche, le résultat peut être complètement différent.

Les assistants IA : ils répondent aux utilisateurs

Les assistants conversationnels sont aujourd’hui les plus visibles.

Ils répondent directement aux questions des internautes et peuvent, selon le contexte, recommander votre site comme source d’information.

Parmi les plus connus figurent :

• ChatGPT
• Gemini
• Claude
• Perplexity
• Microsoft Copilot
• Le Chat de Mistral
• DeepSeek

Dans la majorité des cas, le visiteur reste un humain.

L’assistant joue simplement le rôle d’intermédiaire entre sa question et votre contenu.

Si l’utilisateur clique sur votre lien, Google Analytics ou Matomo enregistrent généralement une visite classique.

En revanche, si la réponse fournie par l’assistant est jugée suffisante, aucune visite ne sera créée.

Le contenu aura pourtant contribué à cette réponse.

Les crawlers IA : ils explorent votre contenu

Les crawlers ont un rôle totalement différent.

Ils ne cherchent pas à répondre immédiatement à un utilisateur.

Leur mission consiste à parcourir le Web afin de découvrir de nouveaux contenus, mettre à jour des informations existantes ou alimenter les différents services proposés par leur éditeur.

Contrairement à un assistant conversationnel, un crawler travaille en arrière-plan.

Il consulte vos pages.

Télécharge leur contenu.

Suit les liens.

Puis poursuit son exploration.

Parmi les principaux crawlers IA, on retrouve notamment :

• GPTBot
• OAI-SearchBot
• ClaudeBot
• Google-Extended
• PerplexityBot
• CCBot (Common Crawl)
• Applebot

Ces robots ne génèrent généralement aucune session Analytics.

En revanche, ils apparaissent très clairement dans les journaux du serveur lorsqu’ils s’identifient correctement.

Ils constituent donc une source d’information essentielle pour comprendre comment les systèmes d’IA découvrent et exploitent votre contenu.

Les agents IA : ils accomplissent une mission

Les agents représentent probablement l’évolution la plus importante des prochaines années.

Contrairement à un assistant conversationnel, leur objectif n’est pas uniquement de produire une réponse.

Ils cherchent à accomplir une tâche.

Par exemple :

• comparer plusieurs offres ;
• réserver un billet ;
• remplir un formulaire ;
• envoyer un email ;
• rechercher un document ;
• effectuer un achat ;
• appeler une API ;
• interagir avec plusieurs sites successivement.

Le comportement observé ne ressemble alors ni à celui d’un humain, ni à celui d’un crawler traditionnel.

L’agent consulte uniquement les ressources dont il a besoin pour accomplir sa mission.

Il peut revenir plusieurs fois sur une même page, interroger une API, utiliser différents outils ou déléguer une partie de son travail à un autre agent.

Cette nouvelle catégorie de trafic reste encore difficile à mesurer avec les outils Analytics actuels.

Les applications IA : elles exploitent votre contenu sans être visibles

Dernière catégorie : les applications intégrant un modèle de langage.

Aujourd’hui, de nombreux logiciels utilisent un LLM pour enrichir leurs fonctionnalités.

Il peut s’agir :

• d’un chatbot d’entreprise ;
• d’un CRM ;
• d’un outil de support ;
• d’un moteur de recherche interne ;
• d’un assistant documentaire ;
• d’une application métier.

Ces applications peuvent consulter votre documentation, appeler une API ou rechercher une information dans votre base de connaissances.

Dans certains cas, elles utilisent une architecture RAG (Retrieval-Augmented Generation) afin de récupérer les informations les plus pertinentes avant de générer une réponse.

Encore une fois, ce n’est pas le RAG qui consulte votre site.

C’est l’application qui l’utilise.

Cette distinction est importante pour éviter de parler, à tort, de « trafic RAG ».

Toutes les interactions ne produisent pas les mêmes données

Le tableau suivant résume les principales différences entre ces quatre familles.

Cette distinction est fondamentale.

Elle montre qu’il n’existe pas un trafic IA, mais plusieurs catégories de trafic ayant chacune leurs propres caractéristiques.

Chercher à toutes les mesurer avec Google Analytics reviendrait à utiliser un thermomètre pour mesurer le vent.

Chaque famille nécessite ses propres outils, ses propres indicateurs et parfois ses propres sources de données.

C’est précisément ce qui explique pourquoi les professionnels de la Web Analytics doivent aujourd’hui dépasser les seuls outils de mesure traditionnels.

Avant de voir lesquels utiliser, il faut comprendre comment une intelligence artificielle accède réellement à votre site. Une fois ce mécanisme compris, il devient beaucoup plus facile d’expliquer pourquoi certaines interactions sont visibles dans Google Analytics… et pourquoi d’autres lui échappent totalement.

Comment une intelligence artificielle accède-t-elle réellement à votre site ?

Pour comprendre pourquoi le trafic IA est si difficile à mesurer, il faut d’abord répondre à une question beaucoup plus fondamentale : comment une intelligence artificielle accède-t-elle réellement à votre site ?

Contrairement à une idée largement répandue, ChatGPT, Claude ou Gemini ne disposent pas d’un accès privilégié au Web. Lorsqu’ils doivent consulter une page, ils utilisent les mêmes protocoles Internet que n’importe quel navigateur, moteur de recherche ou application.

Ils envoient des requêtes HTTP.

Ils téléchargent des ressources.

Ils suivent des liens.

Ils reçoivent des réponses du serveur.

Autrement dit, ils parlent exactement le même langage que le reste du Web.

En revanche, leur manière d’utiliser ce langage est très différente d’un internaute.

C’est précisément cette différence qui permet de les distinguer.

Une page web n’est pas « envoyée » à un navigateur

On imagine souvent qu’un site web est simplement affiché lorsqu’un utilisateur clique sur un lien.

En réalité, plusieurs échanges réseau ont lieu avant que la moindre page n’apparaisse à l’écran.

Le schéma ci-dessous résume le principe.

Utilisateur ou IA
        │
        ▼
 Requête HTTP (GET)
        │
        ▼
      Serveur
        │
        ▼
 Réponse HTTP
(HTML, CSS, JS, Images...)
        │
        ▼
 Client (navigateur,
agent ou crawler)

Tout commence toujours par une requête HTTP.

Le client demande une ressource.

Le serveur répond.

Ce fonctionnement est identique pour :

• un navigateur Chrome ;
• un iPhone ;
• Googlebot ;
• GPTBot ;
• un agent IA ;
• une application métier.

Le serveur ne fait, à ce stade, aucune différence entre eux.

Qu’est-ce qu’une requête HTTP ?

Une requête HTTP est simplement un message envoyé par un client à un serveur afin de demander une ressource.

Par exemple, lorsqu’un utilisateur ouvre la page :

https://www.exemple.com/formation-n8n

son navigateur envoie une requête ressemblant à ceci.

GET /formation-n8n HTTP/2

Host: www.exemple.com

User-Agent: Mozilla/5.0 (...)

Accept: text/html

Le serveur répond ensuite :

HTTP/2 200 OK

Content-Type: text/html

...

Le navigateur reçoit alors le code HTML de la page.

Ce principe est vieux de plus de trente ans.

Toutes les intelligences artificielles qui consultent le Web utilisent aujourd’hui ce même protocole.

Toutes les IA n’utilisent pas le Web de la même manière

C’est ici que les différences apparaissent.

Un utilisateur humain ouvre généralement une page.

Il attend son affichage.

Il lit son contenu.

Il clique éventuellement sur d’autres liens.

Son navigateur télécharge pratiquement toutes les ressources nécessaires :

• HTML ;
• feuilles CSS ;
• images ;
• JavaScript ;
• polices ;
• vidéos éventuelles.

À l’inverse, un crawler IA cherche principalement à récupérer l’information utile.

Selon son objectif, il peut ignorer :

• les images ;
• les animations ;
• les vidéos ;
• une partie du JavaScript.

Il télécharge uniquement ce dont il a besoin.

Résultat : deux clients peuvent consulter la même URL tout en générant un trafic réseau très différent.

Le serveur ne sait pas qui est derrière la requête

C’est un point souvent mal compris.

Lorsque votre serveur reçoit une requête HTTP, il ne sait pas immédiatement si elle provient :

• d’un utilisateur ;
• d’un navigateur ;
• d’un robot ;
• d’un assistant IA ;
• d’un agent autonome.

Il reçoit simplement une demande.

Pour tenter d’identifier son interlocuteur, il s’appuie sur plusieurs informations envoyées par le client.

Les plus importantes sont résumées ci-dessous.

Ces éléments constituent les premiers indices permettant de comprendre qui consulte réellement votre site.

Nous reviendrons sur chacun d’eux dans les prochains chapitres.

Une visite Analytics n’est qu’une étape supplémentaire

C’est probablement la notion la plus importante de tout cet article.

Beaucoup de professionnels considèrent qu’une requête HTTP et une visite Google Analytics sont une seule et même chose.

Ce n’est pas le cas.

Pour qu’une visite apparaisse dans GA4 ou Matomo, plusieurs étapes supplémentaires doivent avoir lieu.

Requête HTTP
      │
      ▼
Le serveur renvoie la page
      │
      ▼
Le navigateur exécute JavaScript
      │
      ▼
Le script Analytics se lance
      │
      ▼
Un événement est envoyé à GA4

Si l’une de ces étapes n’a pas lieu, Google Analytics ne verra jamais cette interaction.

C’est précisément ce qui arrive avec de nombreux crawlers IA.

Ils consultent la page.

Le serveur en garde une trace.

Mais aucun JavaScript n’est exécuté.

Aucune visite n’est donc créée.

Pourquoi cette distinction est-elle essentielle ?

Comprendre cette différence permet déjà d’expliquer une grande partie des écarts observés entre les outils.

Les logs serveur enregistrent toutes les requêtes HTTP.

Google Analytics n’enregistre que celles qui déclenchent son script JavaScript.

Cloudflare observe les échanges réseau avant même que la requête n’atteigne votre serveur.

BigQuery, lui, ne voit que les données que vous décidez d’y envoyer.

Chaque outil observe donc une partie différente de la réalité.

Il n’existe pas de solution capable de mesurer à elle seule l’ensemble du trafic IA.

C’est pourquoi une stratégie de mesure moderne repose nécessairement sur plusieurs sources de données.

Avant de les combiner, il reste une question essentielle à résoudre : pourquoi Google Analytics ne voit-il qu’une partie de ces interactions alors qu’elles transitent toutes par votre serveur ?

Pourquoi Google Analytics ne voit-il qu’une partie du trafic IA ?

Lorsque des professionnels découvrent que ChatGPT, Claude ou d’autres intelligences artificielles utilisent leur contenu, la première réaction est souvent la même.

« Pourquoi ne vois-je presque rien dans Google Analytics ? »

La réponse est simple.

Google Analytics ne mesure pas le trafic Internet.

Il mesure uniquement les interactions qui déclenchent son système de collecte.

Cette nuance paraît anodine.

Elle explique pourtant pourquoi une partie importante du trafic IA lui échappe complètement.

Google Analytics mesure-t-il les visiteurs ou les événements ?

Contrairement à une idée largement répandue, Google Analytics ne « voit » jamais directement un visiteur.

Il reçoit uniquement des événements envoyés par le navigateur.

Pour qu’une simple page vue apparaisse dans vos rapports, plusieurs conditions doivent être réunies.

Requête HTTP
      │
      ▼
Le serveur renvoie le HTML
      │
      ▼
Le navigateur charge la page
      │
      ▼
Le JavaScript Analytics s'exécute
      │
      ▼
Envoi d'un événement vers GA4
      │
      ▼
La visite apparaît dans les rapports

Chaque étape est indispensable.

Si le navigateur n’exécute jamais le script Google Analytics, aucune visite ne sera enregistrée.

Même si votre serveur a parfaitement répondu à la requête.

Pourquoi certains robots n’apparaissent-ils jamais dans GA4 ?

Prenons deux situations.

La première correspond à un utilisateur classique.

09:14:03
GET /formation-n8n

▼

Chrome charge la page

▼

Le JavaScript s'exécute

▼

GA4 reçoit un événement page_view

La seconde correspond à un crawler IA.

09:14:03
GET /formation-n8n

▼

Le robot récupère le HTML

▼

Il extrait uniquement le contenu

▼

Fin de la requête

Dans les deux cas, votre serveur reçoit exactement la même demande.

Dans un seul cas, Google Analytics reçoit un événement.

Pour GA4, le crawler n’a donc jamais existé.

Ce comportement n’a rien d’anormal.

Il correspond simplement au fonctionnement de la plateforme.

Pourquoi JavaScript est-il si important ?

Google Analytics est une solution côté navigateur (client-side).

Autrement dit, le code Analytics est exécuté par le navigateur de l’utilisateur, et non par votre serveur.

Si aucun navigateur n’exécute ce code, Google Analytics n’a aucun moyen de savoir qu’une page a été consultée.

C’est précisément ce qui se produit avec :

• la majorité des crawlers ;
• certains agents IA ;
• certains outils automatisés ;
• certaines applications exploitant directement votre contenu.

Votre serveur voit ces échanges.

Google Analytics, lui, reste aveugle.

Le Referer suffit-il à identifier le trafic IA ?

Pendant longtemps, le champ Referer a constitué l’un des principaux indicateurs d’acquisition.

Il permettait de distinguer facilement les visiteurs provenant de Google, Bing, Facebook ou d’un autre site.

Avec les assistants IA, les choses deviennent beaucoup plus complexes.

Selon les cas :

• le Referer est transmis ;
• il est partiellement transmis ;
• il est supprimé ;
• il est remplacé ;
• il n’existe tout simplement pas.

Deux utilisateurs ayant effectué exactement la même recherche dans ChatGPT peuvent donc apparaître différemment dans Google Analytics.

L’un sera correctement attribué.

L’autre pourra être classé comme un accès direct.

Cette variabilité explique pourquoi il est dangereux de s’appuyer uniquement sur le Referer pour mesurer le trafic IA.

Le User-Agent apporte-t-il une meilleure réponse ?

Le User-Agent constitue un deuxième indice important.

Il permet au client HTTP d’indiquer le logiciel utilisé pour effectuer la requête.

Par exemple.

Mozilla/5.0 (...)

ou

GPTBot/1.0

ou encore

ClaudeBot

Ces informations sont extrêmement utiles…

…mais elles présentent plusieurs limites.

D’abord, elles sont déclaratives.

Un client peut envoyer pratiquement n’importe quelle valeur.

Ensuite, elles évoluent régulièrement.

Les principaux acteurs modifient leurs robots, ajoutent de nouveaux services ou changent leurs signatures.

Enfin, certains agents utilisent volontairement un User-Agent proche de celui d’un navigateur classique.

Le User-Agent constitue donc un excellent indicateur.

Il ne peut cependant pas être considéré comme une preuve absolue.

Le Consent Mode influence-t-il la mesure du trafic IA ?

Oui, mais d’une manière différente.

Le Consent Mode agit uniquement lorsque le script Analytics est exécuté.

Si un utilisateur refuse les cookies, Google Analytics peut continuer à collecter certaines informations de manière limitée, selon votre configuration.

En revanche, si aucun JavaScript n’est exécuté — comme c’est souvent le cas avec les crawlers IA — le Consent Mode n’entre même pas en jeu.

Autrement dit, il ne constitue pas l’explication principale des écarts observés entre le trafic IA réel et les données Analytics.

Que voit réellement Google Analytics ?

Le tableau suivant résume la situation.

* Sous réserve que le navigateur exécute le script Analytics et que les informations de provenance soient disponibles.

Cette distinction est fondamentale.

Elle montre que Google Analytics n’est pas défaillant.

Il remplit exactement la mission pour laquelle il a été conçu.

Le problème est simplement que le Web évolue plus vite que les modèles de mesure historiques.

Aujourd’hui, une partie croissante des interactions entre les intelligences artificielles et votre contenu se déroule avant, à côté ou sans navigateur.

Ces interactions échappent donc naturellement à Google Analytics.

Faut-il pour autant renoncer à les mesurer ?

Bien au contraire.

Il suffit de s’appuyer sur une autre source de données : les logs HTTP. Contrairement à Google Analytics, ils enregistrent toutes les requêtes reçues par votre serveur, qu’elles proviennent d’un internaute, d’un moteur de recherche, d’un crawler IA ou d’un agent autonome. C’est précisément ce qui en fait l’une des pièces maîtresses d’une stratégie moderne de mesure du trafic IA.

Pourquoi les logs serveur deviennent-ils indispensables ?

Si Google Analytics constitue l’outil de référence pour analyser le comportement des visiteurs, les logs HTTP sont la référence lorsqu’il s’agit d’observer ce qui se passe réellement sur votre serveur.

La différence est fondamentale.

Google Analytics mesure les interactions après l’exécution de son script JavaScript.

Les logs enregistrent toutes les requêtes reçues par le serveur, avant même que la page ne soit affichée ou que le moindre code Analytics ne soit exécuté.

Autrement dit, les deux outils n’observent pas la même réalité.

Ils sont donc complémentaires.

Que sont exactement les logs serveur ?

Chaque fois qu’un client communique avec votre serveur, une trace est enregistrée dans un fichier appelé log HTTP.

Peu importe que cette requête provienne :

• d’un visiteur utilisant Chrome ;
• d’un iPhone ;
• de Googlebot ;
• de GPTBot ;
• d’un agent IA ;
• d’un script Python ;
• d’une API.

Le serveur ne fait aucune distinction.

Il traite la requête puis l’enregistre.

Chaque ligne raconte une interaction.

192.168.10.12 - - [05/Aug/2026:09:14:03 +0200]
"GET /formation-n8n HTTP/2"
200
15423
"https://chatgpt.com/"
"Mozilla/5.0 (...)"

Cette ligne paraît peu lisible.

Pourtant, elle contient déjà de nombreuses informations.

Quelles informations trouve-t-on dans un log HTTP ?

Un log serveur ressemble à une boîte noire d’avion.

Chaque événement important y est enregistré.

Les informations disponibles varient selon la configuration de votre serveur, mais on retrouve généralement les éléments suivants.

À elles seules, ces informations permettent déjà de reconstruire une grande partie de l’activité d’un site.

Pourquoi les logs voient-ils davantage de choses que Google Analytics ?

Prenons deux scénarios.

Cas n°1 : un visiteur humain

GET /formation-n8n
        │
        ▼
Le serveur renvoie le HTML
        │
        ▼
Le navigateur charge la page
        │
        ▼
Le JavaScript Analytics s'exécute
        │
        ▼
GA4 reçoit un événement

Dans cette situation, les deux outils enregistrent l’interaction.

Le serveur possède une ligne de log.

Google Analytics crée une visite.

Cas n°2 : un crawler IA

GET /formation-n8n
        │
        ▼
Le serveur renvoie le HTML
        │
        ▼
Le robot extrait le contenu
        │
        ▼
Fin de la requête

Cette fois, aucun navigateur n’exécute JavaScript.

Google Analytics ne reçoit donc aucun événement.

En revanche, le serveur conserve la trace complète de cette consultation.

C’est précisément pour cette raison que les logs deviennent indispensables lorsqu’on cherche à mesurer le trafic IA.

Les logs permettent-ils d’identifier les intelligences artificielles ?

Oui… mais avec quelques précautions.

Contrairement à Google Analytics, les logs donnent accès à plusieurs signaux techniques.

Par exemple :

• le User-Agent ;
• l’adresse IP ;
• le rythme des requêtes ;
• les URL consultées ;
• les méthodes HTTP utilisées ;
• les codes de réponse.

Pris séparément, ces éléments restent imparfaits.

En revanche, leur combinaison permet souvent d’identifier avec une très bonne précision le type de client qui consulte votre site.

Prenons deux exemples.

Navigation d’un utilisateur

09:14:03  GET /formation-n8n

09:16:27  GET /programme

09:19:48  GET /tarifs

09:25:31  GET /contact

Le rythme est irrégulier.

Le visiteur lit.

Réfléchit.

Revient parfois en arrière.

Il consulte quelques pages seulement.

Exploration d’un crawler

09:14:03 GET /formation-n8n

09:14:03 GET /formation-ga4

09:14:04 GET /formation-gtm

09:14:04 GET /formation-bigquery

09:14:04 GET /formation-looker

09:14:05 GET /formations

Six pages en deux secondes.

Même sans connaître le User-Agent, il est évident qu’il ne s’agit pas d’un comportement humain.

Les logs permettent donc d’observer les comportements, et pas uniquement les identités déclarées.

C’est une différence essentielle.

Les logs servent-ils uniquement à détecter les robots ?

Pas du tout.

Ils permettent également de répondre à des questions que Google Analytics ne peut pas traiter.

Par exemple :

• Quels contenus intéressent le plus les IA ?
• Quels robots consultent le plus souvent votre documentation ?
• Quels répertoires sont les plus explorés ?
• Quels robots génèrent le plus de charge serveur ?
• Existe-t-il des comportements suspects ?
• Certaines API sont-elles massivement interrogées ?

Les logs deviennent ainsi un véritable outil d’observabilité.

Ils permettent de comprendre non seulement qui consulte votre site, mais également comment il est utilisé.

Les logs remplacent-ils Google Analytics ?

Non.

C’est probablement l’erreur la plus fréquente.

Les logs et Google Analytics ne répondent pas aux mêmes questions.

Il ne s’agit donc pas de choisir entre les deux.

Une stratégie moderne combine leurs forces.

Google Analytics mesure la performance business.

Les logs mesurent l’activité technique.

Ensemble, ils offrent une vision beaucoup plus fidèle des interactions entre les intelligences artificielles et votre site.

Cette complémentarité devient encore plus intéressante lorsque l’on s’intéresse aux robots eux-mêmes.

Car toutes les IA ne consultent pas le Web de la même manière.

Certaines explorent le contenu.

D’autres recherchent uniquement des informations récentes.

Certaines servent à entraîner des modèles.

D’autres répondent directement aux utilisateurs.

Comprendre leurs différences est indispensable pour interpréter correctement les données de vos logs.

C’est précisément ce que nous allons voir dans la section suivante.

Quels robots IA consultent réellement votre site ?

Lorsque l’on parle de trafic IA, on pense immédiatement à ChatGPT, Gemini ou Claude.

Pourtant, ces assistants ne sont souvent que la partie visible de l’iceberg.

Avant qu’une intelligence artificielle puisse recommander votre contenu, répondre à une question ou comparer plusieurs sources, un autre acteur intervient généralement : le crawler.

Ces robots explorent le Web en permanence.

Ils découvrent de nouvelles pages.

Ils mettent à jour leurs connaissances.

Ils vérifient que des contenus existent toujours.

Ils récupèrent des informations qui pourront ensuite être utilisées par différents services d’intelligence artificielle.

Comprendre leur rôle est essentiel.

D’abord parce qu’ils représentent déjà une part significative du trafic de nombreux sites.

Ensuite parce qu’ils n’ont pas tous les mêmes objectifs.

Enfin parce qu’ils ne doivent pas être traités de la même manière.

Un crawler IA n’est pas un assistant conversationnel

Une confusion revient très souvent.

GPTBot est régulièrement confondu avec ChatGPT.

ClaudeBot avec Claude.

Google-Extended avec AI Overviews.

Pourtant, ces systèmes remplissent des fonctions très différentes.

Le schéma suivant résume leur rôle.

                Utilisateur
                     │
                     ▼
              Assistant IA
           (ChatGPT, Claude...)
                     │
                     ▼
          Recherche d'informations
                     │
        ┌────────────┴────────────┐
        ▼                         ▼
  Base documentaire          Web récent
        │                         │
        ▼                         ▼
                    Crawlers IA
        (GPTBot, ClaudeBot, OAI-SearchBot...)
                     │
                     ▼
                 Votre site

L’utilisateur dialogue avec un assistant.

L’assistant peut s’appuyer sur différentes sources.

Parmi elles figurent parfois des contenus récupérés auparavant par des crawlers.

Autrement dit, le robot qui consulte votre site n’est pas forcément celui qui répond à l’utilisateur.

Cette distinction est importante.

Tous les robots IA n’ont pas le même objectif

Il serait tentant de considérer tous les robots IA comme une seule catégorie.

En réalité, leurs missions sont très différentes.

Cette différence influence directement leur comportement.

Certains parcourent l’ensemble d’un site.

D’autres ciblent uniquement quelques pages.

Certains reviennent quotidiennement.

D’autres plusieurs fois par heure.

Les principaux robots IA

Le paysage évolue rapidement.

De nouveaux robots apparaissent régulièrement et leurs rôles évoluent.

Le tableau ci-dessous présente les principaux robots rencontrés aujourd’hui.

Cette liste évolue régulièrement.

Elle devra être mise à jour au fil des nouvelles annonces des différents éditeurs.

GPTBot et OAI-SearchBot : deux robots différents

L’un des malentendus les plus fréquents concerne OpenAI.

Beaucoup pensent que GPTBot est le robot utilisé par ChatGPT pour répondre aux utilisateurs.

La réalité est plus nuancée.

OpenAI exploite aujourd’hui plusieurs robots ayant des rôles distincts.

Les détails techniques évoluent régulièrement.

Il est donc préférable de consulter la documentation officielle d’OpenAI avant de mettre en place des règles de filtrage.

Cette distinction montre déjà une chose.

Il n’existe pas un robot OpenAI.

Il existe plusieurs services répondant à des besoins différents.

Les robots respectent-ils robots.txt ?

Dans leur très grande majorité, oui.

Les principaux acteurs du marché documentent leur comportement et indiquent les directives qu’ils prennent en compte.

Cela ne signifie pas que tous les robots présents sur Internet respectent robots.txt.

Les robots malveillants peuvent parfaitement l’ignorer.

Il faut donc distinguer :

• les robots légitimes ;
• les robots opportunistes ;
• les robots malveillants.

Le fichier robots.txt constitue une convention.

Il ne représente pas un mécanisme de sécurité.

Nous reviendrons en détail sur ce sujet dans une section dédiée.

Peut-on identifier un robot grâce à son User-Agent ?

Souvent.

Toujours.

Non.

Le User-Agent constitue un excellent point de départ.

Par exemple.

GPTBot/1.0

ou

ClaudeBot

permettent déjà d’identifier clairement certains robots.

Mais cette approche présente plusieurs limites.

• Le User-Agent est déclaratif.
• Il peut évoluer.
• Il peut être falsifié.
• Certains services utilisent plusieurs User-Agent différents.

Il est donc préférable de croiser plusieurs informations.

Par exemple :

• User-Agent ;
• adresse IP ;
• fréquence des requêtes ;
• profondeur d’exploration ;
• ressources consultées.

Plus les signaux convergent, plus l’identification devient fiable.

Faut-il bloquer les robots IA ?

C’est probablement la question qui revient le plus souvent.

La réponse dépend entièrement de votre stratégie.

Prenons quelques exemples.

Il n’existe donc pas de réponse universelle.

Bloquer systématiquement tous les robots IA est rarement une bonne stratégie.

À l’inverse, tout autoriser sans surveillance peut avoir des conséquences sur la charge de votre infrastructure.

L’objectif est d’adopter une politique cohérente avec vos enjeux business, techniques et juridiques.

Les robots ne représentent qu’une partie du trafic IA

Il est tentant de résumer le trafic IA aux différents robots qui parcourent le Web.

Ce serait une erreur.

Les assistants conversationnels, les crawlers et les moteurs de recherche génératifs ne sont qu’une première étape.

La véritable révolution arrive avec les agents IA.

Contrairement aux robots que nous venons d’étudier, ils ne se contentent plus de lire votre contenu.

Ils prennent des décisions.

Ils exécutent des actions.

Ils utilisent des outils.

Ils naviguent comme le ferait un utilisateur.

Ils peuvent même acheter un produit, remplir un formulaire ou réserver un rendez-vous.

Ces nouveaux comportements remettent en question la définition même d’une visite web.

C’est précisément ce qui rend leur mesure beaucoup plus complexe.

Comment ChatGPT, Gemini, Claude et Perplexity utilisent-ils votre contenu ?

Depuis l’arrivée des assistants conversationnels, une question revient systématiquement :

« Est-ce que ChatGPT lit directement mon site ? »

La réponse est plus complexe qu’un simple oui ou non.

Chaque assistant IA possède sa propre architecture, ses propres mécanismes de recherche et ses propres règles pour accéder aux contenus du Web. Certains s’appuient principalement sur leur base de connaissances, d’autres disposent d’une recherche Web intégrée, tandis que les plus récents peuvent naviguer directement sur Internet lorsqu’ils estiment que cela est nécessaire.

Comprendre ces différences est indispensable.

D’abord parce qu’elles influencent votre visibilité.

Ensuite parce qu’elles déterminent la manière dont votre contenu pourra — ou non — être mesuré.

Tous les assistants IA ne fonctionnent pas de la même manière

Pour répondre à une question, un assistant peut utiliser plusieurs sources d’information.

Le scénario le plus simple consiste à répondre uniquement à partir des connaissances déjà intégrées au modèle.

Utilisateur
      │
      ▼
 Modèle de langage
      │
      ▼
    Réponse

Dans ce cas, aucune requête n’est envoyée vers votre site.

Aucune visite.

Aucun log.

Aucun trafic.

Lorsque la question nécessite des informations récentes ou plus précises, l’assistant peut décider d’effectuer une recherche.

Le fonctionnement devient alors très différent.

Utilisateur
      │
      ▼
Assistant IA
      │
      ▼
Recherche Web
      │
 ┌────┼─────┐
 ▼    ▼     ▼
Site A Site B Site C
      │
      ▼
Analyse des contenus
      │
      ▼
Réponse

Votre site peut alors être consulté.

Mais cela ne signifie pas automatiquement qu’un utilisateur viendra ensuite le visiter.

Pourquoi une consultation ne génère-t-elle pas toujours une visite ?

C’est probablement le point le plus difficile à comprendre.

Imaginons que ChatGPT consulte votre article afin de répondre à une question.

Deux situations sont possibles.

Dans la première, votre contenu apporte uniquement un élément de contexte.

L’assistant reformule l’information.

L’utilisateur est satisfait.

La conversation s’arrête.

Votre article a bien été consulté.

Il n’y a pourtant ni clic, ni session Analytics.

Dans la seconde, l’assistant estime que votre contenu apporte une réelle valeur ajoutée.

Il cite votre page comme source.

L’utilisateur souhaite approfondir.

Il clique sur le lien.

Cette fois, une véritable visite est créée.

Autrement dit, la consultation d’une page et la génération d’une visite sont deux événements distincts.

Les confondre conduit souvent à surestimer — ou au contraire à sous-estimer — l’impact réel des assistants IA.

Les principaux assistants utilisent-ils tous le Web ?

Aujourd’hui, les principaux acteurs proposent tous des fonctionnalités de recherche ou de navigation.

En revanche, leur manière de les utiliser reste différente.

* Selon les fonctionnalités disponibles et les évolutions du produit.

Le paysage évolue très rapidement.

De nouvelles capacités apparaissent régulièrement.

Il est donc préférable de considérer ce tableau comme une photographie de l’écosystème plutôt qu’un état définitif.

Les assistants lisent-ils réellement toute une page ?

Pas nécessairement.

Contrairement à un internaute, un assistant ne cherche pas à parcourir visuellement un site.

Son objectif est d’extraire rapidement les informations utiles.

Selon son architecture, il peut privilégier :

• le contenu textuel ;
• les titres ;
• la structure HTML ;
• les listes ;
• les tableaux ;
• les données structurées ;
• certains documents comme les PDF.

À l’inverse, les éléments purement visuels ou décoratifs présentent généralement beaucoup moins d’intérêt.

Cette différence explique pourquoi une page parfaitement optimisée pour un lecteur humain ne constitue pas toujours la meilleure source pour une intelligence artificielle.

Pourquoi certains contenus sont-ils davantage cités ?

La réponse exacte reste inconnue.

Aucun éditeur ne publie l’ensemble des critères utilisés par ses modèles.

En revanche, plusieurs tendances se dégagent.

Les contenus les plus souvent cités présentent généralement plusieurs caractéristiques.

• Ils répondent clairement à une question.
• Ils sont structurés avec des titres explicites.
• Ils développent réellement le sujet.
• Ils citent des sources fiables.
• Ils sont régulièrement mis à jour.
• Ils utilisent un vocabulaire précis.
• Ils évitent les affirmations non démontrées.

Ces bonnes pratiques ne sont d’ailleurs pas nouvelles.

Elles correspondent déjà aux recommandations utilisées depuis plusieurs années pour produire un contenu de qualité.

Les assistants IA semblent simplement les valoriser davantage.

Une nouvelle discipline émerge : le GEO

Cette évolution a donné naissance à un nouveau terme : Generative Engine Optimization (GEO).

Le GEO cherche à comprendre comment améliorer la visibilité d’un contenu auprès des moteurs génératifs.

Contrairement au SEO traditionnel, l’objectif n’est plus uniquement d’obtenir un clic.

Il s’agit également de devenir une source utilisée, comprise et potentiellement citée par les intelligences artificielles.

Le SEO et le GEO poursuivent donc des objectifs proches, mais utilisent des indicateurs différents.

Le GEO reste un domaine très jeune.

Les méthodes évoluent rapidement et peu d’indicateurs sont aujourd’hui standardisés.

Il est donc préférable de rester prudent face aux promesses de certains outils qui prétendent mesurer précisément votre visibilité dans les IA.

Les assistants ne représentent qu’une partie de l’écosystème

ChatGPT, Claude, Gemini ou Perplexity sont les acteurs les plus visibles.

Pourtant, ils ne représentent qu’une partie des usages de l’intelligence artificielle.

La prochaine évolution est déjà en marche.

Les assistants conversationnels laissent progressivement place à des systèmes capables d’agir directement sur le Web.

Ces agents IA ne se contentent plus de répondre à une question.

Ils exécutent des tâches, utilisent plusieurs outils, consultent des sites, prennent des décisions et interagissent avec des services en ligne.

Leur comportement se rapproche beaucoup plus de celui d’un véritable utilisateur… tout en restant entièrement automatisé.

Ils constituent probablement le prochain grand défi pour la Web Analytics.

Les agents IA changent-ils complètement la notion de visite ?

Pendant longtemps, la Web Analytics s’est construite autour d’un principe simple : une visite correspond à un utilisateur qui consulte un site web.

Même les moteurs de recherche respectaient cette logique.

Google explorait les pages.

Les internautes cliquaient.

Les outils Analytics mesuraient leur navigation.

Les agents IA remettent progressivement ce modèle en question.

Contrairement à un assistant conversationnel, un agent n’a pas pour objectif de répondre à une question.

Son objectif est d’accomplir une mission.

Cette différence change profondément la manière dont il interagit avec votre site… et la façon dont vous devrez bientôt mesurer son activité.

Quelle est la différence entre un assistant et un agent IA ?

Les deux utilisent un modèle de langage.

Mais leur rôle est très différent.

Prenons un exemple.

Vous demandez à ChatGPT :

Quelle est la meilleure formation Google Analytics ?

L’assistant compare plusieurs sources puis vous répond.

Vous prenez ensuite votre décision.

Maintenant, demandons à un agent.

Inscris-moi à la meilleure formation Google Analytics disponible le mois prochain.

Cette fois, l’objectif n’est plus de répondre.

L’objectif est d’agir.

L’agent devra probablement :

• rechercher plusieurs organismes ;
• comparer leurs programmes ;
• consulter les dates disponibles ;
• vérifier les tarifs ;
• remplir un formulaire ;
• envoyer une demande d’inscription.

Le comportement observé n’a plus grand-chose à voir avec celui d’un visiteur traditionnel.

Comment travaille un agent IA ?

Contrairement à un navigateur classique, un agent enchaîne plusieurs actions.

Mission confiée
        │
        ▼
Analyse de l'objectif
        │
        ▼
Recherche d'informations
        │
        ▼
Consultation de plusieurs sites
        │
        ▼
Comparaison des résultats
        │
        ▼
Choix de la meilleure option
        │
        ▼
Exécution de l'action

Chaque étape peut générer plusieurs dizaines de requêtes HTTP.

Certaines ressemblent à celles d’un utilisateur.

D’autres à celles d’un crawler.

D’autres encore passent directement par des API.

Le résultat est un comportement hybride, beaucoup plus difficile à interpréter.

Pourquoi les agents compliquent-ils la Web Analytics ?

Prenons un exemple concret.

Vous recevez dix demandes de devis.

Avec un site traditionnel, vous pouvez raisonnablement supposer que dix personnes ont rempli votre formulaire.

Demain, ce ne sera peut-être plus le cas.

Une partie de ces demandes pourra provenir d’agents ayant effectué tout le travail préparatoire à la place de leurs utilisateurs.

Ils auront :

• consulté votre catalogue ;
• comparé vos offres ;
• analysé vos conditions ;
• rempli automatiquement le formulaire.

Votre CRM enregistrera bien un nouveau prospect.

Votre serveur enregistrera bien une visite.

Mais le comportement observé ne ressemblera plus à celui d’un internaute classique.

Les agents utilisent-ils toujours un navigateur ?

Non.

C’est une différence essentielle.

Selon leur architecture, ils peuvent utiliser plusieurs méthodes.

Autrement dit, une partie des actions réalisées par un agent ne passe même plus par votre site web.

Si votre application expose une API publique, un agent pourra parfois l’utiliser directement sans jamais ouvrir la moindre page HTML.

Google Analytics ne verra alors absolument rien.

Les agents utilisent-ils déjà le Web ?

Oui.

Et leur nombre augmente rapidement.

Parmi les exemples les plus connus figurent :

• Operator (OpenAI)
• Computer Use (Anthropic)
• Browser Use
• Gemini avec capacités d’action
• Microsoft Copilot Actions
• de nombreux frameworks open source comme LangGraph, CrewAI ou AutoGen

Leur point commun est simple.

Ils ne se limitent plus à produire du texte.

Ils exécutent réellement des tâches.

Cette évolution marque probablement le début d’une nouvelle génération d’applications.

Comment reconnaître un agent dans vos données ?

Il n’existe aujourd’hui aucune méthode universelle.

En revanche, plusieurs indices peuvent attirer votre attention.

Par exemple :

• des parcours très courts mais très efficaces ;
• plusieurs consultations réalisées en quelques secondes ;
• des appels API précédant immédiatement une action ;
• une absence totale de mouvements de souris ou de scroll (lorsqu’ils sont mesurés) ;
• des séquences extrêmement régulières.

Pris individuellement, ces signaux ne suffisent pas.

En revanche, leur combinaison peut révéler un comportement automatisé.

À mesure que les agents se généraliseront, il est probable que de nouveaux indicateurs apparaîtront dans les outils Analytics.

Une nouvelle génération d’utilisateurs

Pendant des décennies, les visiteurs d’un site étaient presque exclusivement des humains.

Aujourd’hui, trois catégories coexistent.

Cette évolution est loin d’être anecdotique.

Elle remet progressivement en question plusieurs notions fondamentales de la Web Analytics :

• Qu’est-ce qu’une visite ?
• Qu’est-ce qu’un utilisateur ?
• Qu’est-ce qu’une conversion ?
• Comment attribuer une action lorsqu’un agent agit pour le compte d’un humain ?

Les réponses à ces questions évolueront probablement au cours des prochaines années.

Une chose est déjà certaine : les modèles de mesure conçus pour le Web des années 2010 devront s’adapter au Web agentique qui se dessine.

Pour y parvenir, il ne suffira plus d’analyser Google Analytics ou les logs serveur séparément.

Il faudra construire une véritable stratégie de mesure capable de réunir plusieurs sources de données et de les faire dialoguer.

C’est précisément l’objectif de la section suivante.

Comment construire une stratégie fiable de mesure du trafic IA ?

À ce stade, une chose est claire : aucun outil ne permet, à lui seul, de mesurer l’ensemble du trafic IA.

Google Analytics mesure les visiteurs.

Les logs enregistrent toutes les requêtes HTTP.

Cloudflare observe le trafic avant qu’il n’atteigne votre serveur.

BigQuery permet de consolider plusieurs sources de données.

Chaque solution apporte donc une pièce du puzzle.

Chercher à mesurer le trafic IA avec un seul outil revient à essayer de reconstituer une image complète à partir d’un seul morceau.

La véritable question n’est donc plus :

Quel est le meilleur outil ?

Mais plutôt :

Comment combiner plusieurs sources de données pour obtenir une vision fiable de l’activité des intelligences artificielles ?

Pourquoi un seul outil ne suffit-il plus ?

Prenons un exemple concret.

Un utilisateur demande à ChatGPT de comparer plusieurs formations n8n.

L’assistant consulte votre site.

L’utilisateur clique ensuite sur votre page.

Quelques minutes plus tard, un agent IA revient récupérer le programme détaillé afin de préparer un devis.

Enfin, GPTBot repasse dans la nuit pour explorer vos nouvelles pages.

Toutes ces interactions concernent votre contenu.

Pourtant, elles ne seront pas visibles au même endroit.

                 Votre site
                      │
      ┌───────────────┼────────────────┐
      ▼               ▼                ▼
Google Analytics     Logs        Cloudflare
      │               │                │
Visiteurs        Toutes les      Bots, trafic
humains          requêtes HTTP   réseau, sécurité
                      │
                      ▼
                 BigQuery
          Consolidation & analyses

Chaque outil observe une partie différente de la réalité.

Aucun ne possède une vision complète.

Quel rôle joue chaque outil ?

Avant de construire une architecture de mesure, il est important de comprendre les forces et les limites de chaque solution.

Ce tableau résume une idée essentielle.

Chaque outil répond à une question différente.

Le problème n’est donc pas de choisir le meilleur.

Le problème est de savoir comment les faire travailler ensemble.

Une architecture moderne de mesure

Pendant longtemps, une architecture Analytics se résumait à ceci.

Site web
    │
    ▼
Google Analytics
    │
    ▼
Rapports

Cette approche reste parfaitement adaptée pour analyser le comportement des visiteurs.

Elle devient en revanche insuffisante dès que l’on souhaite mesurer les interactions des intelligences artificielles.

Une architecture plus complète ressemble désormais davantage à ceci.

                  Site web
                     │
      ┌──────────────┼──────────────┐
      ▼              ▼              ▼
   GA4 / Matomo     Logs       Cloudflare
      │              │              │
      └──────┬───────┴───────┬──────┘
             ▼               ▼
          BigQuery      Data Warehouse
                 │
                 ▼
      Dashboard décisionnel

Chaque source apporte sa propre vision.

Le tableau de bord final ne présente plus uniquement le comportement des visiteurs.

Il devient un véritable observatoire de l’activité du site.

Quels indicateurs peut-on produire ?

Une fois les données regroupées, il devient possible de construire des indicateurs beaucoup plus riches que de simples sessions.

Par exemple.

Activité humaine

• Sessions IA
• Utilisateurs
• Engagement
• Conversions
• Chiffre d’affaires

Activité des crawlers

• Nombre de requêtes
• Robots les plus actifs
• Pages explorées
• Fréquence d’exploration
• Volume de données téléchargées

Activité des agents

• Appels API
• Automatisations détectées
• Tâches exécutées
• Temps moyen d’exécution

Infrastructure

• Bande passante consommée
• Charge serveur
• Temps de réponse
• Erreurs HTTP
• Volume transféré

Ces indicateurs décrivent des réalités très différentes.

Les mélanger dans un seul graphique n’aurait aucun sens.

BigQuery devient-il indispensable ?

Pas nécessairement.

Pour un petit site vitrine, Google Analytics et quelques analyses de logs peuvent suffire.

En revanche, dès que l’on souhaite :

• croiser plusieurs sources ;
• conserver un historique important ;
• produire des analyses avancées ;
• créer des tableaux de bord personnalisés ;
• automatiser les traitements ;

un entrepôt de données comme BigQuery devient rapidement un atout majeur.

Il ne remplace ni Google Analytics, ni les logs.

Il joue le rôle de point de convergence.

C’est lui qui permet de relier les différents signaux afin de produire une vision globale.

Une stratégie de mesure doit évoluer avec les usages

L’écosystème IA évolue extrêmement vite.

De nouveaux assistants apparaissent.

Les agents deviennent plus autonomes.

Les navigateurs intègrent progressivement des fonctionnalités d’intelligence artificielle.

Il serait donc illusoire de construire un système figé.

Une bonne stratégie de mesure doit pouvoir évoluer.

Elle doit permettre :

• d’ajouter facilement de nouvelles sources de données ;
• d’intégrer de nouveaux robots ;
• d’identifier de nouveaux User-Agent ;
• d’enrichir progressivement les tableaux de bord.

Autrement dit, elle doit être pensée comme un système vivant.

La mesure n’est qu’un moyen

L’objectif n’est pas de collecter toujours plus de données.

L’objectif est de prendre de meilleures décisions.

Mesurer le trafic IA permet notamment de répondre à des questions très concrètes.

• Quels contenus sont les plus utilisés par les assistants IA ?
• Quels robots explorent réellement mon site ?
• Dois-je optimiser certaines pages ?
• Mon infrastructure supporte-t-elle cette nouvelle charge ?
• Les visiteurs provenant des assistants convertissent-ils mieux que les autres ?

C’est uniquement lorsque ces questions trouvent une réponse que la mesure devient réellement utile.

Reste alors une dernière étape : déterminer quels indicateurs suivre en priorité.

Car vouloir tout mesurer conduit souvent… à ne plus rien comprendre.

Quels KPI faut-il suivre pour mesurer le trafic IA ?

Une fois la stratégie de mesure en place, une autre difficulté apparaît rapidement : que faut-il réellement mesurer ?

La tentation est grande de créer un tableau de bord contenant des dizaines d’indicateurs.

Nombre de robots détectés.

Nombre de sessions provenant de ChatGPT.

Volume de requêtes HTTP.

Pages explorées.

Temps de réponse.

Conversions.

Citations.

Le résultat est souvent contre-productif.

On dispose de beaucoup de données…

…mais de très peu d’informations réellement utiles pour prendre des décisions.

Comme pour toute démarche Analytics, les KPI doivent répondre à une question métier.

Avant de construire un tableau de bord, demandez-vous toujours :

Quelle décision vais-je prendre grâce à cet indicateur ?

Si la réponse est « aucune », ce KPI n’a probablement pas sa place dans votre reporting.

Tous les KPI ne poursuivent pas le même objectif

Les indicateurs liés au trafic IA peuvent être regroupés en cinq grandes familles.

              KPI Trafic IA
                    │
    ┌────────┬────────┬────────┬────────┬────────┐
    ▼        ▼        ▼        ▼        ▼
 Acquisition Visibilité Crawlers Agents Business

Chaque famille répond à une problématique différente.

Les mélanger dans un seul graphique conduit souvent à des interprétations erronées.

Les KPI d’acquisition

Ces indicateurs répondent à une question simple :

Les assistants IA m’envoient-ils des visiteurs ?

Ils sont généralement calculés à partir de Google Analytics ou de Matomo.

Les principaux KPI sont :

• Sessions provenant des assistants IA
• Utilisateurs uniques
• Nouveaux visiteurs
• Pages vues
• Durée moyenne d’engagement
• Taux d’engagement
• Conversions
• Chiffre d’affaires généré

Ces indicateurs restent indispensables.

Ils permettent de mesurer la valeur business des visiteurs provenant des intelligences artificielles.

En revanche, ils ne disent absolument rien des interactions invisibles.

Les KPI de visibilité

Le trafic n’est plus le seul indicateur de performance.

Un contenu peut aujourd’hui être utilisé par une intelligence artificielle sans générer de visite.

Il devient donc intéressant de suivre des indicateurs de visibilité.

Par exemple :

• nombre de citations observées ;
• présence dans les réponses génératives ;
• fréquence d’apparition ;
• évolution des mentions de votre marque ;
• évolution des contenus cités.

Ces indicateurs sont encore difficiles à mesurer précisément.

Ils reposent souvent sur des outils spécialisés ou des observations ponctuelles.

Ils doivent donc être interprétés avec prudence.

Les KPI liés aux crawlers

Les robots IA génèrent une activité qui n’apparaît jamais dans Google Analytics.

Les logs serveur permettent en revanche de construire de nombreux indicateurs.

Par exemple.

Ces indicateurs sont particulièrement utiles pour les sites éditoriaux, les documentations techniques ou les plateformes e-commerce comportant plusieurs milliers de pages.

Les KPI liés aux agents IA

Les agents introduisent une nouvelle catégorie d’indicateurs.

L’objectif n’est plus uniquement de mesurer une consultation.

Il devient nécessaire d’observer les tâches réalisées.

Selon votre activité, il peut être pertinent de suivre :

• appels API réalisés par des agents ;
• formulaires remplis automatiquement ;
• créations de comptes ;
• recherches effectuées ;
• réservations ;
• commandes initiées ;
• temps nécessaire pour accomplir une tâche.

Ces indicateurs sont encore peu présents dans les outils Analytics traditionnels.

Ils devraient prendre une importance croissante dans les prochaines années.

Les KPI techniques

Le trafic IA a également un impact sur votre infrastructure.

Un crawler particulièrement actif ou un agent mal configuré peut générer plusieurs milliers de requêtes en quelques minutes.

Il devient donc pertinent de surveiller certains indicateurs techniques.

• Temps moyen de réponse du serveur
• Charge CPU
• Consommation mémoire
• Bande passante
• Nombre de requêtes HTTP
• Taux d’erreurs HTTP (404, 429, 500…)
• Volume de données transférées

Ces informations sont généralement disponibles dans vos logs, votre CDN ou vos outils de supervision.

Tous les KPI n’ont pas la même valeur

Le tableau suivant résume les principaux indicateurs à suivre selon votre objectif.

Construire un bon tableau de bord consiste à sélectionner quelques indicateurs réellement utiles plutôt qu’à accumuler toutes les données disponibles.

Les KPI évolueront avec les usages

La mesure du trafic IA n’en est encore qu’à ses débuts.

Il est probable que de nouveaux indicateurs apparaissent rapidement.

On peut déjà imaginer des KPI tels que :

• taux de citation par assistant ;
• part de visibilité dans les réponses génératives ;
• fréquence d’utilisation d’un contenu comme source ;
• taux de conversion des visiteurs assistés par une IA ;
• proportion de tâches réalisées par des agents.

Ces indicateurs ne sont pas encore standardisés.

Ils illustrent cependant l’évolution de la Web Analytics vers une mesure beaucoup plus large que le simple comptage des visites.

La difficulté n’est donc plus de produire des indicateurs.

Elle consiste à les alimenter avec des données fiables.

C’est précisément ce que nous allons voir en commençant par l’outil le plus utilisé au monde : Google Analytics 4.

Comment mesurer le trafic IA dans Google Analytics 4 ?

Google Analytics 4 est souvent le premier outil utilisé pour mesurer le trafic provenant des intelligences artificielles.

C’est logique.

Il est déjà installé sur des millions de sites et permet d’analyser précisément les sessions, les événements, les conversions et les parcours utilisateurs.

En revanche, une idée reçue mérite d’être corrigée immédiatement.

Google Analytics 4 ne mesure pas le trafic IA. Il mesure uniquement les visiteurs qui arrivent réellement sur votre site.

Cette distinction est essentielle.

Lorsqu’un utilisateur clique sur un lien proposé par ChatGPT, Perplexity ou Gemini, GA4 peut enregistrer cette visite.

En revanche, si une IA consulte votre contenu sans envoyer d’utilisateur, ou si un crawler explore votre site, Google Analytics ne verra absolument rien.

Avant de créer un rapport, il faut donc savoir exactement ce que GA4 est capable de mesurer.

Quel trafic IA Google Analytics peut-il réellement mesurer ?

Le tableau suivant résume la situation.

On comprend immédiatement la principale limite de GA4.

Il ne mesure pas l’activité des IA.

Il mesure les visiteurs provenant des IA.

La nuance est fondamentale.

Où trouver ce trafic dans GA4 ?

Dans la majorité des cas, ces visites apparaissent comme n’importe quelle autre source de trafic.

Le premier réflexe consiste à consulter le rapport :

Acquisition → Acquisition de trafic

Les dimensions suivantes sont particulièrement utiles :

• Source de la session
• Support de la session
• Source / Support
• Groupe de canaux
• Référent complet (si disponible)

Selon les informations transmises par le navigateur, vous pourrez observer des sources telles que :

Cette liste évolue régulièrement.

De nouveaux domaines apparaissent au fur et à mesure des évolutions des différents assistants.

Pourquoi certaines visites apparaissent-elles en trafic direct ?

C’est probablement la question qui revient le plus souvent.

Vous constatez quelques visites provenant de ChatGPT.

Puis, le lendemain, elles disparaissent.

À la place, vous observez une augmentation du trafic Direct.

La raison est simple.

Google Analytics dépend des informations transmises par le navigateur.

Or celles-ci ne sont pas systématiquement disponibles.

Par exemple :

• certains navigateurs suppriment le Referer ;
• certaines applications ouvrent une WebView ;
• certains assistants utilisent un navigateur intermédiaire ;
• certaines redirections font disparaître la source d’origine.

Résultat.

Deux visiteurs ayant effectué exactement la même recherche peuvent être attribués différemment.

L’un apparaîtra comme provenant de ChatGPT.

L’autre sera classé en trafic direct.

Ce comportement est normal.

Il ne s’agit pas d’une erreur de configuration.

Créer un segment dédié au trafic IA

Pour faciliter les analyses, il est recommandé de regrouper les principales sources IA dans un même segment.

Le principe consiste à filtrer les sessions dont la source contient le nom des principaux assistants.

Par exemple.

Ce segment permettra notamment de répondre à des questions telles que :

• Les visiteurs provenant des IA consultent-ils davantage de pages ?
• Convertissent-ils mieux ?
• Restent-ils plus longtemps sur le site ?
• Reviennent-ils plus souvent ?

Une fois ce segment créé, toutes les explorations de GA4 pourront être comparées au reste du trafic.

Faut-il créer un canal personnalisé « IA » ?

Dans la plupart des projets, oui.

Créer un groupe de canaux personnalisé présente plusieurs avantages.

Il permet :

• de suivre l’évolution du trafic IA dans le temps ;
• de comparer facilement les assistants entre eux ;
• d’analyser les conversions ;
• d’alimenter des tableaux de bord Looker Studio ou BigQuery.

Attention toutefois à une limite importante.

Ce canal ne représentera jamais l’ensemble du trafic IA.

Il ne contiendra que les visiteurs effectivement arrivés sur votre site.

Les crawlers, les agents et les consultations sans clic resteront invisibles.

Quels rapports créer dans GA4 ?

Une fois votre segment ou votre canal créé, plusieurs rapports deviennent particulièrement intéressants.

Ces rapports répondent à une question essentielle :

Les visiteurs provenant des assistants IA ont-ils un comportement différent des autres visiteurs ?

Dans de nombreux cas, la réponse est oui.

Ils arrivent avec une intention déjà clarifiée.

Ils consultent moins de pages.

Mais ils convertissent parfois davantage.

Ces observations devront naturellement être confirmées par vos propres données.

Les limites de Google Analytics 4

Google Analytics reste un excellent outil.

Mais il ne faut pas lui demander ce qu’il n’a jamais été conçu pour mesurer.

Il ne verra jamais :

• les crawlers IA ;
• les robots d’exploration ;
• les appels API ;
• les agents n’utilisant pas de navigateur ;
• les consultations sans clic.

Autrement dit, il ne mesure qu’une partie du phénomène étudié dans ce guide.

C’est précisément pour cette raison qu’il est indispensable de compléter ses analyses par d’autres sources de données.

Matomo répond en partie aux mêmes besoins que Google Analytics.

Il présente toutefois quelques différences intéressantes, notamment grâce à son mode d’hébergement, à ses possibilités d’analyse avancée et à son module d’analyse des logs.

Voyons maintenant comment il peut contribuer à la mesure du trafic IA.

Comment mesurer le trafic IA dans Matomo ?

Pendant longtemps, Google Analytics et Matomo ont été présentés comme deux solutions poursuivant le même objectif : mesurer l’audience d’un site web.

En pratique, leurs capacités sont très proches lorsqu’il s’agit d’analyser le comportement des visiteurs.

Les différences apparaissent surtout dans leur philosophie.

Google Analytics est un service cloud fortement intégré à l’écosystème Google.

Matomo est une plateforme que vous pouvez héberger vous-même et dont vous maîtrisez entièrement les données.

Cette indépendance offre plusieurs avantages lorsqu’il s’agit d’analyser le trafic IA.

Matomo voit-il davantage de trafic IA que Google Analytics ?

La réponse est souvent surprenante.

Non… du moins pas avec une installation standard.

Comme Google Analytics, Matomo repose principalement sur un script JavaScript exécuté par le navigateur.

Autrement dit, il souffre exactement des mêmes limitations.

Si un crawler consulte votre site sans exécuter JavaScript :

• aucune visite n’est créée ;
• aucun parcours n’est enregistré ;
• aucune conversion n’est calculée.

Le tableau suivant résume la situation.

Contrairement à une idée reçue, Matomo ne mesure donc pas automatiquement davantage de trafic IA que Google Analytics.

Pourquoi Matomo reste-t-il particulièrement intéressant ?

La véritable force de Matomo ne réside pas uniquement dans son script de collecte.

Elle vient surtout de son ouverture.

Selon votre infrastructure, Matomo peut être enrichi par d’autres sources de données.

Par exemple :

• les journaux HTTP du serveur ;
• les données issues d’un reverse proxy ;
• les informations de votre CDN ;
• des événements envoyés directement via son API.

Cette approche permet de dépasser progressivement les limites d’une collecte exclusivement basée sur JavaScript.

Le module Log Analytics change-t-il la donne ?

Oui.

C’est probablement l’une des fonctionnalités les plus intéressantes de Matomo dans le contexte du trafic IA.

Contrairement au tracker JavaScript, Log Analytics analyse directement les journaux de votre serveur web.

Le principe est simple.

Serveur Web
      │
      ▼
Fichiers de logs
      │
      ▼
Matomo Log Analytics
      │
      ▼
Rapports Matomo

Cette approche présente plusieurs avantages.

Elle permet notamment d’analyser :

• les requêtes ne déclenchant jamais JavaScript ;
• les robots correctement identifiés ;
• les erreurs HTTP ;
• les téléchargements ;
• les ressources consultées.

En revanche, il est important de comprendre ses limites.

Le module Log Analytics ne transforme pas automatiquement tous les crawlers en visiteurs.

Il exploite simplement une source de données différente.

Autrement dit, il complète Matomo.

Il ne modifie pas la manière dont les robots utilisent votre site.

Peut-on identifier les assistants IA dans Matomo ?

Oui.

Comme avec Google Analytics, plusieurs approches sont possibles.

La plus simple consiste à analyser les référents.

Par exemple :

• chatgpt.com
• perplexity.ai
• gemini.google.com
• claude.ai
• copilot.microsoft.com

Vous pouvez ensuite :

• créer un segment dédié ;
• construire un rapport personnalisé ;
• comparer les conversions ;
• suivre l’évolution de ce trafic dans le temps.

Le principe reste exactement le même que dans Google Analytics.

Peut-on identifier les robots IA ?

Lorsque les robots exécutent uniquement des requêtes HTTP, ils restent invisibles pour le tracker JavaScript.

En revanche, ils deviennent beaucoup plus faciles à analyser si vous exploitez les logs serveur.

Les User-Agent permettent alors d’identifier de nombreux robots.

Par exemple.

GPTBot

ClaudeBot

PerplexityBot

CCBot

Google-Extended

Ces informations peuvent ensuite être utilisées pour produire des rapports spécifiques.

Vous pourrez notamment connaître :

• les robots les plus actifs ;
• les pages les plus explorées ;
• la fréquence des visites ;
• les erreurs rencontrées ;
• le volume de données téléchargées.

Google Analytics ou Matomo : lequel choisir ?

Cette question revient souvent.

La réponse dépend davantage de votre stratégie que de l’outil lui-même.

Les deux solutions restent parfaitement capables d’analyser les visiteurs provenant des assistants IA.

En revanche, si votre objectif consiste à construire une plateforme complète d’observabilité du trafic IA, Matomo offre davantage de possibilités grâce à son ouverture et à son module d’analyse des logs.

Matomo ne remplace pas les logs

Il est important d’éviter une confusion.

Même avec Log Analytics, Matomo ne remplace pas vos journaux serveur.

Les logs constituent toujours la source de vérité.

Matomo apporte :

• des rapports ;
• des tableaux de bord ;
• des segments ;
• des visualisations.

Les logs, eux, conservent l’information brute.

Dans une architecture moderne, les deux approches sont complémentaires.

Les logs alimentent l’analyse.

Matomo facilite son exploitation.

Une source de données ne suffit toujours pas

À ce stade du guide, une idée devrait être clairement établie.

Ni Google Analytics.

Ni Matomo.

Ni même les logs.

Ne suffisent à eux seuls pour comprendre l’ensemble du trafic IA.

Plus les interactions deviennent complexes, plus il devient nécessaire de croiser plusieurs sources de données.

C’est précisément ce que permet un entrepôt de données comme BigQuery.

En regroupant les données Analytics, les logs serveur et d’autres sources techniques dans une même plateforme, il devient possible de produire des analyses impossibles à réaliser avec un seul outil.

C’est cette approche que nous allons explorer dans la prochaine section.

Comment analyser le trafic IA dans les logs serveur ?

Nous avons déjà vu que les logs serveur constituent la source de données la plus complète pour observer les interactions techniques avec votre site.

Encore faut-il savoir les exploiter.

Pour beaucoup d’équipes marketing, un fichier de logs ressemble à une succession interminable de lignes incompréhensibles. Pourtant, une fois décodé, il devient une véritable mine d’informations sur les robots, les assistants IA, les agents autonomes et, plus largement, sur tout ce qui interagit avec votre infrastructure.

Où trouve-t-on les logs serveur ?

Tout dépend de votre hébergement.

Sur un serveur Apache ou Nginx, les journaux sont généralement enregistrés dans des fichiers texte mis à jour en temps réel.

Par exemple :

/var/log/nginx/access.log

/var/log/apache2/access.log

Sur des plateformes Cloud (AWS, Google Cloud, Azure, Cloudflare, OVH…), ils peuvent être exportés vers différents services de stockage ou de supervision.

L’emplacement importe finalement assez peu.

Ce qui compte, c’est le contenu.

Une ligne de log raconte une histoire

Prenons un exemple simplifié.

66.249.66.1 - - [05/Aug/2026:09:14:03 +0200]
"GET /formation-n8n HTTP/2"
200
15423
"https://chatgpt.com/"
"Mozilla/5.0 (...)"

À première vue, cette ligne paraît peu exploitable.

En réalité, elle répond déjà à plusieurs questions.

Une seule ligne contient déjà suffisamment d’informations pour commencer une analyse.

Comment identifier les robots IA ?

La méthode la plus simple consiste à rechercher certains User-Agent connus.

Par exemple :

Dans la pratique, cette approche fonctionne bien…

…mais elle reste incomplète.

Un User-Agent peut être modifié ou falsifié.

Il est donc préférable de le croiser avec d’autres informations.

Les comportements sont souvent plus révélateurs que le User-Agent

Un robot laisse généralement une signature comportementale très différente de celle d’un humain.

Prenons deux exemples.

Navigation humaine

09:12  /formation-ga4

09:16  /programme

09:21  /tarifs

09:27  /contact

Le rythme est irrégulier.

Le visiteur prend le temps de lire.

Il hésite.

Il revient parfois en arrière.

Exploration automatisée

09:12:01  /formation-ga4

09:12:01  /formation-gtm

09:12:02  /formation-bigquery

09:12:02  /formation-n8n

09:12:03  /formations

09:12:03  /contact

Six pages consultées en moins de trois secondes.

Même si le User-Agent était absent, ce comportement est très peu compatible avec une navigation humaine.

L’analyse comportementale constitue donc un excellent complément.

Quelles questions peut-on poser à ses logs ?

Les possibilités sont nombreuses.

Par exemple :

Quels robots consultent mon site ?

→ Classement par User-Agent.

Quelles pages sont les plus explorées par les IA ?

→ Classement des URL consultées.

À quelle fréquence GPTBot revient-il ?

→ Analyse temporelle.

Quels robots provoquent le plus d’erreurs 404 ?

→ Analyse des codes HTTP.

Quelle part de la bande passante est consommée par les robots IA ?

→ Somme des volumes transférés.

Ces analyses sont impossibles à réaliser uniquement avec Google Analytics.

Les logs permettent-ils de mesurer les assistants IA ?

Pas directement.

Les logs voient les requêtes HTTP.

Ils ne savent pas pourquoi elles ont été effectuées.

Prenons un exemple.

Si un utilisateur clique depuis ChatGPT, vous pourrez éventuellement observer :

• un Referer indiquant chatgpt.com ;
• un navigateur Chrome ou Safari ;
• un comportement humain classique.

En revanche, si ChatGPT consulte votre page pour préparer une réponse sans envoyer l’utilisateur sur votre site, tout dépendra de la manière dont cette consultation a été réalisée.

Les logs montrent ce qui s’est passé.

Ils ne permettent pas toujours d’identifier pourquoi cela s’est produit.

C’est une nuance importante.

Peut-on automatiser cette analyse ?

Oui.

Et c’est même recommandé dès que votre site reçoit plusieurs centaines de milliers de requêtes par jour.

Les approches les plus courantes consistent à :

• importer les logs dans BigQuery ;
• les analyser avec SQL ;
• créer des tableaux de bord dans Looker Studio, Grafana ou Power BI ;
• produire des alertes lorsqu’un nouveau robot apparaît ;
• suivre automatiquement les principaux User-Agent IA.

Cette approche évite de parcourir manuellement des fichiers contenant parfois plusieurs millions de lignes.

Les logs constituent la source de vérité technique

Les logs ne remplacent pas Google Analytics.

Ils répondent simplement à d’autres questions.

Ils permettent notamment de savoir :

• qui consulte réellement votre serveur ;
• quand cette consultation a eu lieu ;
• quelles ressources ont été demandées ;
• quelles erreurs ont été rencontrées ;
• quelle charge représente chaque type de trafic.

En revanche, ils ne permettent pas de mesurer directement les conversions, le chiffre d’affaires ou l’engagement des utilisateurs.

C’est précisément la raison pour laquelle une stratégie moderne combine toujours plusieurs sources de données.

Les logs apportent la vision technique.

Google Analytics et Matomo apportent la vision marketing.

BigQuery permet ensuite de relier ces deux mondes.

C’est cette dernière étape qui ouvre la voie aux analyses les plus avancées.

Comment exploiter BigQuery pour analyser le trafic IA ?

À mesure que votre stratégie de mesure gagne en maturité, une limite apparaît rapidement.

Les données sont dispersées.

Google Analytics contient les sessions.

Les logs enregistrent les requêtes HTTP.

Cloudflare mesure les robots.

Votre CRM stocke les conversions.

Votre serveur conserve les appels API.

Chaque outil raconte une partie de l’histoire.

Aucun ne possède une vision complète.

C’est précisément le rôle d’un entrepôt de données comme BigQuery.

Son objectif n’est pas de remplacer Google Analytics ou les logs.

Il consiste à centraliser toutes ces informations afin de produire des analyses impossibles à réaliser avec chaque outil pris isolément.

Pourquoi utiliser BigQuery ?

Prenons un exemple.

Vous souhaitez répondre à une question pourtant très simple.

Les visiteurs provenant de ChatGPT consultent-ils des pages également explorées par GPTBot ?

Google Analytics connaît les visiteurs.

Les logs connaissent GPTBot.

Aucun des deux ne peut répondre seul.

En réunissant les deux sources dans BigQuery, la réponse devient possible.

C’est toute la force d’un entrepôt de données.

Il ne collecte rien.

Il relie les données.

Une architecture de données moderne

Voici à quoi ressemble généralement une architecture de mesure orientée IA.

               Site web
                  │
    ┌─────────────┼─────────────┐
    ▼             ▼             ▼
Google      Logs serveur    Cloudflare
Analytics
    │             │             │
    └─────────────┼─────────────┘
                  ▼
              BigQuery
                  │
        Nettoyage / Enrichissement
                  │
                  ▼
      Dashboards & analyses avancées

Chaque source apporte une information différente.

BigQuery devient le point de convergence.

Quelles données centraliser ?

Plus vous disposez de sources, plus vos analyses seront riches.

Voici les principales données qu’il est intéressant de regrouper.

L’objectif n’est pas de tout stocker.

Il est de pouvoir relier les informations lorsqu’une analyse l’exige.

Quels croisements deviennent possibles ?

Une fois les données réunies, de nouvelles analyses apparaissent.

Par exemple.

Les pages les plus explorées par les robots IA sont-elles aussi celles qui convertissent le mieux ?

Les visiteurs provenant de ChatGPT consultent-ils davantage certaines catégories de contenus ?

Les crawlers IA explorent-ils les nouvelles pages plus rapidement que Googlebot ?

Une hausse de l’activité de GPTBot précède-t-elle une augmentation du trafic provenant de ChatGPT ?

Ce type de question est impossible à traiter dans un outil Analytics traditionnel.

Exemple d’analyse

Imaginons que votre base contienne :

• les pages consultées par GPTBot ;
• les visites provenant de ChatGPT ;
• les conversions enregistrées dans GA4.

Vous pouvez alors construire un tableau comme celui-ci.

Ce tableau ne prouve évidemment aucun lien de causalité.

En revanche, il permet d’identifier des corrélations intéressantes qui méritent d’être approfondies.

BigQuery permet-il d’identifier les IA ?

Non.

BigQuery ne détecte rien.

Il exploite les données que vous lui fournissez.

Par exemple.

Vous pouvez importer :

• les User-Agent détectés dans les logs ;
• les Referer ;
• les sessions GA4 ;
• les informations Cloudflare.

BigQuery se contente ensuite de les relier.

Cette nuance est importante.

L’intelligence ne vient pas de BigQuery.

Elle vient des analyses que vous construisez.

Quelques analyses particulièrement utiles

Au fil des projets, certaines analyses reviennent régulièrement.

Par exemple.

Évolution du trafic provenant des assistants IA

→ Google Analytics.

Évolution du nombre de robots IA

→ Logs serveur.

Répartition des robots par éditeur

→ Logs + User-Agent.

Comparaison entre Googlebot et GPTBot

→ Logs.

Temps moyen entre l’exploration d’une page et ses premières visites IA

→ Logs + GA4.

Charge serveur générée par les robots IA

→ Logs + Cloudflare.

Répartition des conversions selon la source IA

→ GA4 + CRM.

Toutes ces analyses deviennent relativement simples une fois les données centralisées.

BigQuery n’est pas réservé aux très grands sites

Beaucoup imaginent que BigQuery est réservé aux entreprises traitant plusieurs milliards de lignes.

Ce n’est plus le cas.

Aujourd’hui, même un site de taille moyenne peut bénéficier d’un entrepôt de données.

Par exemple pour :

• conserver plusieurs années d’historique ;
• produire des tableaux de bord personnalisés ;
• automatiser des analyses SQL ;
• rapprocher plusieurs sources de données ;
• alimenter des modèles de Machine Learning.

Le véritable intérêt n’est donc pas le volume.

C’est la capacité à relier des informations auparavant isolées.

Une stratégie de mesure devient une stratégie de données

À ce stade du guide, une conclusion s’impose.

Mesurer le trafic IA ne consiste plus uniquement à installer un outil Analytics.

Cela revient à construire une véritable architecture de données.

Les visiteurs.

Les robots.

Les agents.

Les API.

Les conversions.

Les performances techniques.

Toutes ces informations doivent être rapprochées afin de produire une vision cohérente.

C’est précisément cette évolution qui explique pourquoi les métiers de la Web Analytics se rapprochent progressivement de ceux de la Data Engineering.

Une dernière étape reste cependant indispensable.

Avant de déployer une telle stratégie, mieux vaut connaître les pièges les plus fréquents.

Car certaines erreurs reviennent dans presque tous les projets.

Quelles sont les erreurs les plus fréquentes ?

Le trafic IA est un domaine encore récent.

Les outils évoluent rapidement.

Les assistants ajoutent régulièrement de nouvelles fonctionnalités.

Les standards commencent à peine à émerger.

Dans ce contexte, il est normal de commettre quelques erreurs.

En revanche, certaines reviennent tellement souvent qu’elles faussent complètement les analyses. Les identifier permet de gagner un temps considérable et d’éviter des conclusions parfois totalement erronées.

Erreur n°1 : croire que le trafic IA se limite à ChatGPT

C’est sans doute la confusion la plus répandue.

Lorsqu’une entreprise décide de mesurer le trafic IA, elle commence souvent par créer un rapport contenant uniquement les visites provenant de ChatGPT.

Cette approche est beaucoup trop restrictive.

Le trafic IA englobe aujourd’hui :

• les assistants conversationnels ;
• les moteurs génératifs ;
• les crawlers IA ;
• les agents autonomes ;
• les applications exploitant un modèle de langage.

Limiter l’analyse à ChatGPT revient à ignorer une grande partie du phénomène.

Erreur n°2 : penser que Google Analytics mesure tout

Google Analytics reste un excellent outil.

Mais il n’a jamais été conçu pour mesurer l’ensemble des interactions entre les intelligences artificielles et votre site.

Il ne voit que les visites qui déclenchent son script de collecte.

Les robots.

Les appels API.

Les consultations sans clic.

Les agents n’utilisant pas de navigateur.

Tout cela lui échappe naturellement.

Chercher à mesurer le trafic IA uniquement avec Google Analytics conduit donc inévitablement à sous-estimer son importance.

Erreur n°3 : confondre visibilité et trafic

Pendant longtemps, ces deux notions étaient très proches.

Aujourd’hui, elles ne le sont plus forcément.

Votre contenu peut :

• être consulté par une IA ;
• être résumé ;
• être comparé à d’autres sources ;
• être cité dans une réponse.

…sans générer le moindre clic.

À l’inverse, quelques dizaines de visiteurs provenant d’un assistant IA peuvent produire davantage de conversions que plusieurs centaines de visites issues d’un moteur de recherche.

Le trafic reste un indicateur essentiel.

Il ne mesure plus, à lui seul, l’influence réelle d’un contenu.

Erreur n°4 : parler de « trafic RAG »

Cette expression apparaît de plus en plus souvent.

Pourtant, elle est techniquement incorrecte.

Le RAG (Retrieval-Augmented Generation) est une architecture permettant à une application de récupérer des informations externes avant de produire une réponse.

Ce n’est ni un robot.

Ni un assistant.

Ni un visiteur.

Dire qu’un site reçoit du trafic RAG revient à confondre une technologie avec le système qui l’utilise.

Il est beaucoup plus juste de parler :

• d’assistants utilisant un RAG ;
• d’agents exploitant un RAG ;
• d’applications reposant sur une architecture RAG.

Cette précision peut sembler anodine.

Elle évite pourtant de nombreuses confusions dès le début d’un projet.

Erreur n°5 : identifier les robots uniquement grâce au User-Agent

Le User-Agent constitue un excellent indice.

Mais il ne suffit pas.

Pourquoi ?

Parce qu’il est déclaratif.

Un robot peut modifier sa signature.

Un navigateur peut l’usurper.

Une application peut utiliser un User-Agent générique.

Pour identifier correctement un robot, il est préférable de croiser plusieurs informations.

• le User-Agent ;
• l’adresse IP ;
• la fréquence des requêtes ;
• les URL consultées ;
• les horaires de passage ;
• les codes HTTP.

Plus les indices convergent, plus l’identification devient fiable.

Erreur n°6 : bloquer tous les robots IA

Certaines entreprises choisissent de bloquer systématiquement tous les robots liés à l’intelligence artificielle.

Cette décision peut avoir du sens dans certains contextes.

Par exemple :

• documentation privée ;
• contenu réservé aux abonnés ;
• contraintes juridiques particulières.

En revanche, l’appliquer sans réflexion peut également réduire votre visibilité dans les assistants IA ou empêcher certains services d’accéder à vos contenus.

Comme pour le référencement naturel, il n’existe pas de règle universelle.

La bonne stratégie dépend de vos objectifs.

Erreur n°7 : construire un tableau de bord uniquement technique

À l’inverse, certains projets tombent dans l’excès opposé.

Ils mesurent :

• les User-Agent ;
• les robots ;
• les codes HTTP ;
• les volumes transférés.

Mais oublient complètement les indicateurs métier.

Au final, ils savent que GPTBot a consulté 3 200 pages…

…mais sont incapables de dire si cette activité a généré davantage de prospects ou de ventes.

Une stratégie de mesure doit toujours relier les indicateurs techniques aux objectifs business.

Erreur n°8 : vouloir tout mesurer

Le trafic IA évolue extrêmement vite.

De nouveaux robots apparaissent chaque mois.

Les assistants changent régulièrement de comportement.

Les agents deviennent plus autonomes.

Chercher à mesurer absolument tout est une erreur.

Il vaut mieux commencer par quelques indicateurs robustes.

Par exemple :

• sessions provenant des assistants IA ;
• principaux robots détectés ;
• pages les plus explorées ;
• conversions issues du trafic IA ;
• évolution de la charge serveur.

Ces indicateurs répondront déjà à la majorité des besoins.

Vous pourrez ensuite enrichir progressivement votre dispositif.

Erreur n°9 : considérer la mesure comme un projet ponctuel

La mesure du trafic IA n’est pas un projet que l’on réalise une fois avant de passer à autre chose.

C’est un processus d’amélioration continue.

Les assistants évoluent.

Les User-Agent changent.

De nouveaux services apparaissent.

Les tableaux de bord devront donc évoluer eux aussi.

Une stratégie efficace est une stratégie capable de s’adapter.

Ce qu’il faut retenir

La plupart des erreurs proviennent finalement d’une même idée reçue.

Le trafic IA serait une simple extension de la Web Analytics traditionnelle.

Ce n’est plus le cas.

Nous sommes en train de passer d’une logique centrée sur les visiteurs à une logique beaucoup plus large, où humains, assistants, robots, agents et applications cohabitent.

Les outils.

Les indicateurs.

Les méthodes.

Les compétences.

Tout évolue.

La bonne nouvelle, c’est que les fondamentaux restent les mêmes : observer, comprendre, mesurer puis décider.

Ce sont simplement les acteurs du Web qui changent.

Et cette transformation ne fait probablement que commencer.

Dans la dernière section de ce guide, nous allons prendre un peu de recul et nous projeter dans les prochaines années. Car les évolutions observées aujourd’hui ne sont sans doute qu’une première étape vers une Web Analytics profondément transformée par l’intelligence artificielle.

Que va changer l’IA dans la Web Analytics d’ici 2030 ?

Depuis la création de Google Analytics en 2005, le principe est resté relativement stable.

Un utilisateur visite un site.

Le navigateur exécute un script.

Les interactions sont enregistrées.

Des rapports permettent ensuite d’analyser son comportement.

L’intelligence artificielle ne remet pas seulement en question certains indicateurs.

Elle transforme progressivement le fonctionnement même du Web.

Les prochaines années verront probablement cohabiter trois types d’acteurs :

• les humains ;
• les assistants conversationnels ;
• les agents autonomes.

Cette évolution modifiera profondément la manière dont nous mesurerons l’audience, les performances et même la notion de visite.

Le visiteur humain ne sera plus le seul utilisateur du Web

Aujourd’hui déjà, une partie importante des requêtes adressées à un site ne provient plus directement d’un humain.

Les moteurs de recherche explorent les contenus.

Les robots techniques vérifient les ressources.

Les assistants IA consultent des pages.

Les agents exécutent des actions.

Demain, cette proportion continuera probablement d’augmenter.

Le schéma suivant illustre cette évolution.

            Aujourd'hui

        Humains
           ██████████████

        Robots
           ███

        Agents IA
           █


            Horizon 2030

        Humains
           ████████

        Assistants IA
           █████

        Agents IA
           ██████

        Crawlers IA
           ████

L’objectif n’est pas de remplacer les utilisateurs.

Il est de comprendre que le Web sera de plus en plus fréquenté par des systèmes automatisés.

Les indicateurs traditionnels perdront progressivement de leur importance

Pendant des années, quelques KPI suffisaient à piloter un site.

• Sessions
• Utilisateurs
• Pages vues
• Taux de rebond
• Durée moyenne
• Conversions

Ces indicateurs resteront utiles.

Mais ils ne permettront plus de décrire toute la réalité.

De nouveaux indicateurs devraient progressivement apparaître.

Par exemple :

• fréquence de citation dans les moteurs génératifs ;
• exposition auprès des assistants IA ;
• activité des agents autonomes ;
• consommation des API ;
• taux d’utilisation des contenus comme sources ;
• coût d’exploitation du trafic IA.

Le tableau de bord d’un responsable Analytics sera probablement beaucoup plus hybride qu’aujourd’hui.

Les sites web deviendront des plateformes de services

Pendant longtemps, un site web avait principalement pour vocation d’être lu.

Demain, il devra également être exploitable par des machines.

Cela implique plusieurs évolutions.

Les contenus devront rester compréhensibles par les humains.

Mais ils devront également être :

• facilement structurés ;
• accessibles par API lorsque cela est pertinent ;
• correctement documentés ;
• riches en données structurées ;
• accompagnés de métadonnées exploitables.

Cette tendance est déjà visible avec les API, les flux de données, les protocoles comme MCP ou les interfaces destinées aux agents.

Le site web devient progressivement une plateforme d’échange d’informations.

Les outils Analytics devront évoluer

Les solutions actuelles sont principalement conçues pour observer des visiteurs humains.

Demain, elles devront probablement distinguer plusieurs catégories d’interactions.

Par exemple.

On peut également imaginer l’apparition de nouveaux rapports dédiés aux IA directement dans les principales plateformes Analytics.

Certaines briques existent déjà.

Elles devraient progressivement gagner en maturité.

La frontière entre Analytics et observabilité va disparaître

Historiquement, plusieurs métiers coexistent.

Les équipes marketing analysent Google Analytics.

Les administrateurs système surveillent les serveurs.

Les équipes Data exploitent les entrepôts de données.

Les équipes sécurité analysent les logs.

Le trafic IA brouille progressivement ces frontières.

Pour comprendre ce qui se passe réellement sur un site, il faudra de plus en plus rapprocher ces différentes sources de données.

L’Analytics se rapprochera donc naturellement de l’observabilité.

Cette évolution est déjà visible dans les grandes entreprises, où les équipes Data, DevOps, Sécurité et Marketing travaillent de plus en plus sur des jeux de données communs.

L’important ne sera plus seulement de mesurer

Depuis le début de ce guide, nous avons beaucoup parlé de mesure.

Pourtant, la véritable valeur de la Web Analytics ne réside pas dans la collecte des données.

Elle réside dans la capacité à prendre de meilleures décisions.

Mesurer le trafic IA n’a d’intérêt que si cela permet de répondre à des questions concrètes.

• Quels contenus sont réellement utilisés par les intelligences artificielles ?
• Les visiteurs provenant des assistants convertissent-ils mieux ?
• Quels robots consomment le plus de ressources ?
• Quels contenus méritent d’être enrichis ?
• Faut-il ouvrir ou limiter l’accès à certains robots ?
• Les agents IA deviennent-ils une nouvelle source de clients ?

La mesure reste donc un moyen.

Jamais une finalité.

Ce qu’il faut retenir

L’intelligence artificielle ne signe pas la fin de la Web Analytics.

Elle marque le début d’une nouvelle étape.

Pendant plus de vingt ans, nous avons appris à mesurer le comportement des internautes.

Au cours des prochaines années, nous devrons apprendre à mesurer un écosystème beaucoup plus riche, dans lequel humains, assistants, crawlers, agents et applications interagissent simultanément avec nos contenus.

Les outils évolueront.

Les indicateurs aussi.

Mais les fondamentaux resteront les mêmes.

Comprendre les usages.

Mesurer ce qui compte réellement.

Transformer les données en décisions.

C’est précisément ce qui continuera à faire la différence entre une organisation qui accumule des statistiques… et une organisation réellement pilotée par la donnée.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.