Comment vérifier qu’un agent IA est authentique dans les logs sans se raconter d’histoires
Une chaîne user-agent déclarée n’est pas la même chose qu’un agent vérifié.
Cela paraît évident. Mais c’est encore là que beaucoup d’équipes se trompent.
Elles voient Google-Agent, ChatGPT-User, Claude-SearchBot, ou Applebot dans les logs, puis supposent immédiatement identité, finalité, et conformité.
C’est beaucoup trop de confiance pour beaucoup trop peu de preuve.
La bonne règle est simple :
d’abord classifier la requête telle qu’elle se présente, puis vérifier ce qui peut réellement être vérifié.
La version courte
Un workflow pratique de vérification comporte 5 étapes :
- identifier la chaîne user-agent revendiquée ;
- appliquer les méthodes de vérification documentées par le fournisseur lorsqu’elles existent ;
- utiliser le reverse DNS, le forward confirmation, ou les plages IP publiées quand le fournisseur les documente ;
- exploiter les signaux de bots vérifiés du CDN ou du WAF lorsqu’ils existent ;
- si la vérification reste faible ou impossible, le dire explicitement.
Cette dernière étape compte autant que les autres.
Pourquoi la chaîne user-agent ne suffit pas
Les grands opérateurs le disent eux-mêmes.
Google rappelle explicitement que la chaîne user-agent peut être usurpée.
Cela signifie qu’une ligne de log contenant Google-Agent ou Googlebot ne constitue pas une preuve suffisante à elle seule.
Le même principe doit être appliqué aux autres opérateurs :
- une chaîne déclarée est une revendication d’identité ;
- elle ne vaut pas preuve complète d’authenticité.
C’est aussi pour cela que Comment lire les logs de crawl et identifier les bots indésirables et cet article vont ensemble, sans être le même article.
La lecture des logs dit ce que la requête prétend être. La vérification dit dans quelle mesure on peut faire confiance à cette revendication.
Ce qu’on peut bien vérifier
Certains opérateurs publient des méthodes publiques de vérification assez solides.
Google
Google documente à la fois ses fetchers déclenchés par l’utilisateur et la vérification des requêtes.
Pour les user-triggered fetchers, Google publie des objets JSON de plages IP pertinentes et explique que ces requêtes résolvent vers des hôtes google.com ou gae.googleusercontent.com, selon la classe de fetcher.
Cela donne un workflow utile :
- extraire l’IP de la requête ;
- vérifier qu’elle appartient à une plage publiée ;
- effectuer un reverse DNS puis une confirmation directe si nécessaire ;
- seulement ensuite classifier le trafic comme requête Google vérifiée.
OpenAI
OpenAI publie des fichiers JSON d’adresses IP pour :
OAI-SearchBotGPTBotChatGPT-User
Cela veut dire que ces 3 surfaces ne reposent pas seulement sur une chaîne user-agent déclarée. Elles disposent aussi de références publiques de plages IP utilisables pour la vérification.
OpenAI documente séparément ChatGPT agent comme un agent signé qu’on peut allowlister dans des écosystèmes edge comme Akamai, Cloudflare, et HUMAN.
Cela signifie qu’une partie de la vérification OpenAI peut se faire au niveau de l’infrastructure, et pas seulement à partir des logs d’origine.
Apple
Apple indique que le trafic Applebot s’identifie généralement via le reverse DNS dans le domaine *.applebot.apple.com.
Apple publie aussi des préfixes CIDR dans un fichier JSON.
Apple dispose donc d’une histoire publique de vérification assez solide :
- reverse DNS ;
- préfixes publiés ;
- nomenclature Applebot cohérente.
Ce qui est plus difficile à vérifier
Tous les opérateurs ne publient pas le même niveau de preuve.
Anthropic
Anthropic indique explicitement qu’elle ne publie pas actuellement de plages IP, car elle utilise des IP publiques de prestataires.
Anthropic avertit aussi que le blocage IP peut ne pas fonctionner correctement ou durablement comme garantie d’opt-out, parce qu’il peut empêcher la lecture du robots.txt.
Cela veut dire que le trafic Anthropic est plus difficile à vérifier fortement par des méthodes publiques de plages IP que Google, OpenAI, ou Apple.
Le workflow honnête est donc différent :
- lire la chaîne user-agent revendiquée ;
- examiner le comportement de la requête et sa cohérence ;
- s’appuyer sur les surfaces de politique publiées comme
robots.txt; - éviter de prétendre disposer d’une preuve forte quand ce n’est pas le cas.
Ici, l’honnêteté vaut davantage qu’une fausse précision.
Pourquoi les signaux d’edge comptent davantage
La vérification n’est plus seulement un problème de logs à l’origine.
Le système de bots vérifiés de Cloudflare permet de segmenter le trafic via cf.verified_bot_category, avec notamment des catégories comme :
AI AssistantAI CrawlerAI Search
C’est utile parce que cela permet de passer de :
« la requête dit qu’elle est telle chose »
à :
« l’edge a classifié cette requête dans un cadre de bots vérifiés sur lequel on peut agir ».
Cela ne remplace pas toutes les vérifications spécifiques par fournisseur. Mais c’est parfois l’un des signaux opérationnels les plus propres dont on dispose.
C’est aussi l’une des raisons pour lesquelles Robots.txt vs allowlisting d’agents signés est devenu un article central, et non une note technique marginale.
Un workflow pratique de vérification
Utilisez la séquence suivante.
Étape 1. Capturer les bases
Pour chaque requête machine suspecte ou importante, capturez :
- l’horodatage ;
- l’adresse IP ;
- la chaîne user-agent complète ;
- le chemin demandé ;
- le volume et le rythme des requêtes ;
- le code de réponse.
Étape 2. Classifier le rôle revendiqué
Avant même de parler d’authenticité, classez la requête revendiquée par rôle :
- crawler Search ;
- crawler d’entraînement ;
- fetcher déclenché par l’utilisateur ;
- système de réponse ou de récupération ;
- agent signé ou vérifié ;
- bot inconnu ou abusif.
Cela rend la suite beaucoup plus claire.
Étape 3. Appliquer la vérification documentée par le fournisseur
- Google : objets IP publiés et motifs d’hôtes documentés
- OpenAI : fichiers JSON d’IP publiés pour
OAI-SearchBot,GPTBot, etChatGPT-User - Apple : reverse DNS et CIDR publiés par Apple
- Anthropic : pas de plages IP publiques, donc vérification forte plus limitée
Étape 4. Vérifier les métadonnées d’infrastructure
Si vous utilisez Cloudflare, Akamai, ou une autre pile edge capable, vérifiez si la requête remonte comme bot vérifié ou de confiance.
Ce signal peut être plus fiable que les seuls logs d’origine.
Étape 5. Nommer explicitement l’incertitude
Si une requête ne peut pas être vérifiée fortement, n’écrivez pas des notes de politique comme si elle avait été pleinement authentifiée.
Écrivez plutôt :
- « agent Anthropic revendiqué »
- « user-agent de style IA non vérifié »
- « requête Google vérifiée par IP et DNS »
- « crawler Search OpenAI vérifié par plage publiée »
Ce langage garde les décisions honnêtes.
Trois erreurs fréquentes
1. Traiter une chaîne user-agent comme une preuve complète
Ce n’est pas le cas.
Ce n’est que le début du travail de vérification.
2. Supposer que tous les fournisseurs publient le même type de données de vérification
Ce n’est pas le cas.
Google, OpenAI, Apple, et Anthropic exposent actuellement des modèles publics de vérification différents.
3. Confondre authenticité de l’agent et permission d’usage
Une requête peut être authentique tout en restant interdite par votre politique.
La vérification et la permission sont 2 questions distinctes.
Où Better Robots.txt se place
Better Robots.txt ne remplace ni l’analyse de logs, ni la vérification edge.
Ce qu’il fait, en revanche, c’est aider à classifier correctement les requêtes avant de les transformer en politique.
C’est important parce que la qualité de la politique publiée dépend de la qualité de la classification qui la précède.
Si l’on confond un fetcher déclenché par l’utilisateur avec un crawler d’entraînement, ou un agent signé avec un crawler classique, la politique devient fausse avant même d’être publiée.
Le bon modèle mental
Le modèle de vérification le plus sûr est celui-ci :
- chaîne user-agent = revendication
- IP et DNS = preuve plus forte quand l’opérateur les publie
- métadonnées de bot vérifié à l’edge = classification opérationnelle plus forte
- absence de méthode publique de vérification = incertitude explicite, pas confiance inventée
C’est ainsi qu’on lit des logs sans se raconter d’histoires.