Un agent IA vient de visiter votre site. Comment savoir s'il est authentique ?

Un agent IA vient de demander une page et la ligne de log affiche GPTBot/1.2. Cette chaîne ne prouve rien. Un User-Agent est rédigé par le client, donc n'importe qui peut l'envoyer, et la seule façon fiable de vérifier un agent IA consiste à examiner l'adresse depuis laquelle il s'est connecté. Trois contrôles font le vrai travail : comparer l'IP source au fichier de plages publié par l'opérateur, effectuer une résolution DNS inverse confirmée dans les deux sens, ou vérifier que l'IP est annoncée par l'ASN de l'opérateur.

Lequel des trois s'applique dépend entièrement de l'opérateur, et c'est là que ça se complique. OpenAI publie des fichiers JSON de plages par bot. Anthropic publie un fichier de préfixes unique qui couvre ensemble ClaudeBot, Claude-User et Claude-SearchBot. Apple accepte à la fois le reverse DNS et un fichier de plages. Meta ne publie ni l'un ni l'autre et attend un contrôle contre AS32934. Beaucoup de crawlers ne publient rien du tout, et le nom dans l'en-tête n'est alors qu'un ornement : vous décidez sur l'origine et le comportement.

L'affirmation est gratuite, la vérification non

Regardez ce que dit vraiment une règle d'allowlist du type « si le User-Agent contient GPTBot, ignorer les règles anti-bots ». Elle dit : tout client prêt à taper neuf caractères obtient le traitement que vous réserviez à un crawler de confiance. Les scrapers lisent votre robots.txt, repèrent les agents que vous accueillez, et s'habillent en conséquence. Cette usurpation n'a rien d'astucieux, elle est simplement bon marché, et elle fonctionne sur tout site qui ne regarde jamais au-delà de l'en-tête.

La vérification coûte plus cher. Il vous faut les plages à jour de l'opérateur, un résolveur DNS ou des données de routage, opérateur par opérateur, actualisés à chaque changement. Des chercheurs ont déjà signalé du trafic se réclamant de PerplexityBot depuis des adresses situées hors des plages publiées par Perplexity. C'est exactement le scénario d'échec : le nom était emprunté, le réseau non.

Chaque opérateur documente cela à sa façon

Il n'existe aucun standard commun, la vérification est donc une recherche par opérateur. Un échantillon tiré de l'annuaire des crawlers IA, qui recense 150 agents :

Google-Extended mérite un second regard, car il casse le modèle mental habituel. C'est une directive robots.txt permettant de refuser l'entraînement de Gemini, pas un crawler. Si une requête arrive en se réclamant de Google-Extended, c'est une contrefaçon par définition. Il n'en existe aucune version authentique.

Sur les 150 agents de l'annuaire, 33 offrent un contrôle exploitable via des plages publiées, le reverse DNS ou un ASN. Neuf sont documentés comme ignorant purement et simplement robots.txt. Le reste se situe entre les deux : un nom, et rien pour l'étayer.

À quoi ressemble une usurpation dans vos logs

Deux requêtes, le même en-tête, à quelques minutes d'intervalle :

198.51.100.7  "Mozilla/5.0 ...; compatible; GPTBot/1.2; +https://openai.com/gptbot"
203.0.113.44  "Mozilla/5.0 ...; compatible; GPTBot/1.2; +https://openai.com/gptbot"

Rien dans la ligne ne les distingue. Résolvez les adresses et la différence saute aux yeux : l'une tombe dans les plages de sortie publiées par OpenAI, l'autre est annoncée par un hébergeur qui loue des serveurs à l'heure. La seconde a par ailleurs demandé 400 pages produit en quatre-vingt-dix secondes sans jamais charger une feuille de style, ce qu'aucun crawler respectant son propre budget de crawl publié ne fait.

Le schéma se répète chez tous les opérateurs. Un faux ClaudeBot depuis une plage de VPS. Un faux Applebot dont l'enregistrement PTR pointe vers le domaine d'un hébergeur, ou n'existe pas. Un faux Amazonbot dont le PTR paraît plausible jusqu'à ce que la résolution directe renvoie une autre adresse, ce qui est précisément la raison d'être de l'étape de confirmation. À chaque fois, l'en-tête correspondait parfaitement et le réseau non.

Vérifié, invérifiable et hostile sont trois réponses différentes

Dès que vous cessez de prendre l'en-tête pour une preuve, le trafic se répartit en groupes qui appellent des traitements distincts, et un simple drapeau bot binaire ne sait pas exprimer cela.

Un crawler IA vérifié relève d'une décision de politique : l'autoriser, le facturer, ou le bloquer nommément parce que vous ne voulez pas de votre contenu dans ce corpus. Une requête qui revendique un nom et échoue au contrôle d'IP ne relève d'aucune politique, c'est une contrefaçon, et elle ne doit jamais hériter de l'accès accordé au véritable agent. Un crawler invérifiable, qui ne publie rien, appelle des limites de débit plutôt qu'un verdict. Et un navigateur headless issu d'une plage de datacenter qui ne revendique aucun nom de bot est justement le cas que votre allowlist ne regardait pas.

C'est pourquoi Agentscan renvoie une classe plutôt qu'un booléen. Chaque requête revient en human, known_bot, ai_agent ou malicious_automation, avec une valeur de confiance et les signaux qui ont produit le verdict.

Les signaux qui survivent à un faux User-Agent

L'origine de l'IP répond à l'essentiel de la question, mais pas à tout. Un agent peut tourner depuis une adresse résidentielle, et un scraper peut louer une IP propre sans historique. Trois autres signaux tiennent quand l'en-tête ment :

Empreinte TLS JA4. Le client révèle sa façon de parler TLS avant même d'envoyer le moindre en-tête : ordre des ciphers, extensions, ALPN, version. Un script Python qui se présente comme Chrome 124 produit une négociation qu'aucune version de Chrome n'a jamais produite. L'en-tête est une déclaration, la négociation est un comportement.

Traces de headless. Le drapeau webdriver, les surfaces de navigateur manquantes et les marqueurs d'automatisation laissés par Playwright, Puppeteer ou une build HeadlessChrome brute. Isolément, chacun est faible. Combiné à une origine datacenter, le tableau n'a plus rien d'ambigu.

Cohérence des en-têtes. Les vrais navigateurs envoient Accept, Accept-Language et Accept-Encoding en bloc, dans un ordre stable, cohérent avec la version annoncée. Les objets de requête construits à la main n'en envoient souvent qu'une partie, et ces manques sont assez réguliers pour servir de signal.

Aucun de ces signaux ne tranche seul, et c'est précisément l'idée. Seule leur combinaison sépare un crawler vérifié d'un imitateur compétent, et les deux d'un visiteur ordinaire. La même logique s'applique aux crawlers plus anciens, détaillée dans comment vérifier Googlebot.

Une politique qui résiste au trafic réel

La vérification ne sert que si quelque chose en découle. Une base de travail :

1. Vérifiez la revendication avec la méthode de l'opérateur avant qu'une règle d'allowlist ne se déclenche. Fichier de plages, reverse DNS ou ASN, selon ce que cet opérateur publie.
2. Un échec de vérification n'est pas un signal faible. Une requête se réclamant de ClaudeBot depuis l'extérieur des préfixes d'Anthropic est une usurpation. Traitez-la comme n'importe quel scraper non identifié, pas comme un cas douteux.
3. Séparez la décision d'autorisation selon la finalité. Crawlers d'entraînement, crawlers de recherche IA et récupérateurs d'assistants méritent des règles distinctes. Bloquer un crawler de recherche vous retire des réponses citées par ce moteur : c'est une décision de trafic, pas de sécurité.
4. Limitez le débit de l'invérifiable. Pour Bytespider, CCBot et tout ce qui ne publie aucun contrôle, le nom ne dit rien. La cadence des requêtes, le motif des chemins et l'origine en disent long.
5. Journalisez la classe, pas seulement le blocage. Savoir que le trafic d'agents IA a triplé le mois dernier vaut plus qu'un compteur de requêtes bloquées, surtout quand vous cherchez encore ce qu'il faut monétiser.

Agentscan exécute tout cela via un POST vers /v1/agentscan/check : allowlist vérifiée par reverse DNS, correspondance avec les plages publiées, origine de l'IP, indicateurs headless et JA4 en un seul appel, avec mise en cache pour que les recherches répétées reviennent en moins de 50 ms. Assez rapide pour tenir dans un middleware plutôt que dans une revue de logs nocturne.

En résumé

Vous ne pouvez pas vérifier un agent IA à partir du nom qu'il se donne. Confrontez l'IP source à ce que l'opérateur publie réellement, traitez un échec de contrôle comme une contrefaçon, et servez-vous de JA4, des traces de headless et de l'origine de l'IP pour tout ce dont l'allowlist ne peut pas se porter garante. La question n'a jamais été « est-ce un bot ». Elle est de savoir laquelle des quatre sortes de trafic vient d'arriver, et ce que vous voulez faire de chacune.