Analyse des logs pour les crawlers IA : qui est vraiment venu

L’analyse des logs lit l’agent utilisateur et l’IP déjà enregistrés par le serveur, puis vérifie l’identité avant de compter. Voici la commande, le tableau des champs, la liste des jetons et les limites de ce que le journal peut prouver.

Exploration et indexation6 min de lecture812 vues
Analyse des logs pour les crawlers IA : qui est vraiment venu

L’analyse des logs consiste à lire deux champs que votre serveur enregistre déjà, l’agent utilisateur et l’adresse IP, puis à séparer les requêtes d’un vrai crawler IA de celles qui prétendent seulement en être un. Elle répond à une question qu’un test d’accessibilité ne peut pas trancher : non pas « GPTBot pouvait-il atteindre cette page », mais « l’a-t-il fait, quel jour et combien de fois ». Un code 200 prouve que la porte s’ouvre. Le journal montre qui est entré.

Ce que l’analyse des logs peut dire, et ce qu’elle ne peut pas dire

Elle donne l’agent, le chemin demandé, l’heure, le code de statut et l’adresse IP. Elle ne dit pas si le contenu a ensuite servi dans une réponse ou dans un entraînement. Elle ne confirme pas non plus l’identité à elle seule : l’agent utilisateur est déclaratif, et n’importe qui peut le copier. Seule une IP correspondante transforme « une requête qui dit GPTBot » en « GPTBot ».

C’est pour cette raison que le sujet mérite une méthode et pas une astuce en une ligne. Une ligne de journal a deux moitiés. La moitié que tout le monde lit est l’agent. La moitié qui décide si la ligne est vraie est l’adresse IP.

Avant de commencer, il faut un accès en lecture au journal du serveur et un terminal. Si votre hébergeur ne fournit aucun journal, cette méthode n’a pas de substitut : aucun outil tiers ne peut voir des requêtes qu’il n’a jamais reçues.

Pourquoi le journal bat la vérification d’agent

Un test d’accessibilité envoie une requête avec un agent imité et observe la réponse. Un journal enregistre ce que de vrais clients ont fait, sans provocation. Les deux peuvent se contredire : être joignable ne signifie pas être visité, et un test peut échouer alors qu’un crawler passe par un autre chemin.

Le journal apporte aussi le champ qu’un test ne produit jamais : le temps. Un test donne oui ou non à un instant. Un journal donne un comptage par jour et par robot, seule façon de distinguer un crawler hebdomadaire de celui venu une fois puis reparti.

Faites-le dans cet ordre

Cinq étapes, chacune avec un point de contrôle avant de passer à la suivante.

  1. Trouvez le journal et confirmez son format. Chez nginx, le format par défaut est combined ; chez Apache, le format étendu/NCSA combined documente les champs %h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-agent}i". Terminé quand vous savez nommer chaque champ sur une ligne réelle.
  2. Comptez par agent avant de filtrer. Dans une ligne combined, le sixième champ entre guillemets est l’agent. Terminé quand vous avez une liste des trente agents les plus fréquents, pas seulement ceux que vous attendiez.
  3. Sortez les jetons des crawlers IA. Les chaînes exactes sont dans le tableau plus bas. Terminé quand chaque jeton a un nombre de requêtes et une première date d’apparition.
  4. Vérifiez les IP que vous croyez. DNS inversé puis direct pour Google, fichiers JSON publiés pour OpenAI. Terminé quand chaque ligne citée est vérifiée ou marquée « non vérifiée ».
  5. Notez la fenêtre, pas seulement le total. Un comptage sans nombre de jours ne veut rien dire. Terminé quand votre note ressemble à « 412 requêtes, du 1er au 31 août 2026, 5 sites ».

Le livrable : une commande et deux tableaux

Cette commande transforme un journal au format combined en comptage par agent. Elle suppose qu’aucun guillemet n’est échappé dans le champ agent, ce qui vaut pour les crawlers ci-dessous et pas pour certains scrapers.

awk -F'"' '{print $6}' access.log \
  | sed 's/;.*compatible;//' \
  | sort | uniq -c | sort -rn | head -30

L’étape sed existe parce que les navigateurs cachent le vrai jeton derrière un préfixe de compatibilité. Gardez aussi le champ brut pour pouvoir y revenir quand un comptage paraît faux.

Le deuxième livrable est le tableau des champs. La plupart des gens connaissent l’agent et s’arrêtent là, ce qui explique pourquoi leur premier passage rate les chemins.

ChampExempleCe qu’il dit
Adresse distante66.249.66.1Le seul champ vérifiable contre une liste publiée
Ligne de requêteGET /pricing HTTP/1.1La méthode et le chemin demandés
Statut200Contenu servi ou requête bloquée
Octets envoyés18432Le volume réellement renvoyé
Référent-Presque toujours vide pour un crawler
Agent... GPTBot/1.4 ...La déclaration, falsifiable, trop crue

Troisième livrable : la liste des jetons publiés par les opérateurs, relue le 22 septembre 2026 dans leur documentation. Elle n’est pas exhaustive et de nouveaux arrivent sans préavis — raison de plus pour compter tout avant de filtrer.

JetonOpérateurRôleVérifiable
GPTBotOpenAICollecte d’entraînementOui, via openai.com/gptbot.json
OAI-SearchBotOpenAIPrésence dans la rechercheOui, via openai.com/searchbot.json
ChatGPT-UserOpenAIRequête déclenchée par un humainOui, via openai.com/chatgpt-user.json
GooglebotGoogleCollecte pour la rechercheDNS inversé puis direct, plus fichiers JSON
Google-ExtendedGoogleJeton de contrôleNon : il n’envoie aucune requête propre
ClaudeBotAnthropicCollecteDocumenté, vérifier les plages sur leur page
PerplexityBotPerplexityCollecteDocumenté, vérifier les plages sur leur page

Deux lignes portent le raisonnement. Google-Extended est un jeton de contrôle, pas un crawler : la documentation de Google indique qu’il n’a pas de chaîne d’agent propre, donc son absence du journal n’est pas un échec. ChatGPT-User est déclenché par une personne : ses requêtes ne sont pas une collecte automatique.

Ce qui rate

Faire confiance à l’agent. C’est l’erreur par défaut, et elle produit une réponse confiante et fausse. La vérification Google demande deux résolutions DNS : inverse sur l’IP, puis directe sur le nom obtenu, avec correspondance obligatoire. Pour OpenAI, on compare l’IP au fichier de plages publié. Pour un crawler qui ne publie ni l’un ni l’autre, écrivez « non vérifié » au lieu de croire ou de supprimer le comptage.

Compter les lectures de robots.txt comme des pages. OpenAI précise que, lors d’une lecture de robots.txt, un marqueur peut être ajouté à l’agent pour distinguer ces requêtes. Si votre format supprime le chemin, une lecture de robots.txt et une page se ressemblent. Séparez par chemin avant d’annoncer un comptage de collecte.

Lire une fenêtre trop courte. Sept jours ne répondent pas à une question de trente jours, et la rotation des journaux tronque la fenêtre sans avertir. Indiquez le premier et le dernier horodatage réellement comptés.

Questions fréquentes

Peut-on croire l’agent utilisateur dans les journaux ?

Non. Traitez-le comme une déclaration jusqu’à ce que l’IP corresponde à une plage publiée ou passe le DNS inversé puis direct. Un journal est un enregistrement, pas une preuve.

Comment savoir si GPTBot est venu ?

Cherchez le jeton GPTBot, puis comparez chaque IP au fichier openai.com/gptbot.json. Un jeton sans IP correspondante est une autre requête qui a copié le nom.

Quelle profondeur de journal faut-il ?

Assez pour couvrir un cycle complet de collecte, ce qui dépend du site et n’a pas de chiffre universel. Trente jours est une valeur de départ raisonnable. Avec sept jours, dites-le : une fenêtre courte sous-estime, jamais l’inverse.

La limite à écrire noir sur blanc : un journal prouve qu’une requête a eu lieu ; il ne prouve pas que le contenu a été utilisé, classé ou cité. Quand vous voulez transformer ce constat en action publiée, c’est là que QueryWin intervient. Pour vérifier d’abord si les crawlers peuvent vous atteindre, commencez par vérifier si l’IA peut lire votre site. Et si la question est de savoir quels robots vous autorisez, la réponse est dans robots.txt pour les crawlers IA.

L’agent se présente lui-même. L’IP décide s’il dit vrai.

Fait partie du guide QueryWin · Niveau 2

Analyse des logs pour les crawlers IA : qui est vraiment venu