Comment bloquer les bots IA sur votre serveur

Pourquoi bloquer des bots IA ?

Les crawlers IA font désormais partie du trafic Internet courant. Certains parcourent des contenus pour le développement de modèles, d'autres construisent des index pour des moteurs de recherche alimentés par l'IA, et d'autres encore récupèrent une page parce qu'un utilisateur a demandé à un service d'IA d'y accéder.

Ces usages sont différents. Un éditeur peut souhaiter rester visible dans la recherche IA tout en refusant les crawls destinés à l'entraînement de modèles. Un site e-commerce peut apprécier le trafic de référence tout en voulant empêcher des scrapers inconnus de solliciter en permanence des pages produits, de recherche ou d'API coûteuses.

Parmi les raisons fréquentes de limiter le trafic IA automatisé :

• empêcher des scrapers indésirables de consommer des contenus originaux ;
• réduire la charge PHP, applicative, base de données, moteur de recherche et bande passante ;
• protéger des endpoints dynamiques et des API coûteux ;
• écarter les faux crawlers de recherche ou d'IA ;
• contrôler quels services peuvent crawler pour le développement de modèles ;
• réduire le bruit dans les logs, les analytics et le monitoring opérationnel.

Méthode 1 : publier votre politique dans robots.txt

Le point de départ standard est /robots.txt. Le Robots Exclusion Protocol fournit aux opérateurs de crawlers un moyen lisible par machine de savoir quels chemins vous leur demandez d'autoriser ou d'éviter.

Une politique simple qui bloque plusieurs crawlers liés au développement de modèles tout en conservant l'accès orienté recherche peut ressembler à ceci :

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Google-Extended
Disallow: /

User-agent: PerplexityBot
Allow: /

Il s'agit d'un exemple, pas d'une recommandation universelle. La bonne configuration dépend de votre choix concernant l'entraînement, la visibilité dans les recherches IA et les récupérations déclenchées par des utilisateurs.

OpenAI : GPTBot et OAI-SearchBot sont des contrôles distincts

OpenAI documente actuellement GPTBot et OAI-SearchBot comme des contrôles robots.txt indépendants. Un site peut autoriser OAI-SearchBot pour rester visible dans la recherche ChatGPT tout en refusant GPTBot afin d'indiquer que le contenu crawlé ne doit pas être utilisé pour l'entraînement des modèles fondamentaux d'IA générative d'OpenAI.

Anthropic : des bots différents selon l'usage

Anthropic documente ClaudeBot pour les contenus susceptibles de contribuer au développement de modèles, Claude-SearchBot pour la recherche et Claude-User pour les récupérations déclenchées par l'utilisateur. Anthropic indique que ces bots respectent les directives robots.txt.

Google-Extended est un token de contrôle robots.txt

Google-Extended est un cas particulier car il ne possède pas sa propre chaîne HTTP User-Agent. Google indique que ce token contrôle certains usages de contenus déjà crawlés par Google pour l'entraînement et le grounding de Gemini, sans affecter l'inclusion ni le classement dans Google Search.

Perplexity distingue le crawling de recherche et les récupérations initiées par l'utilisateur

Perplexity documente PerplexityBot pour faire apparaître des sites dans les résultats de recherche et Perplexity-User pour les récupérations déclenchées par l'utilisateur. Sa documentation indique que Perplexity-User ignore généralement robots.txt, car la récupération a été demandée par un utilisateur. Cela montre pourquoi le paysage actuel des crawlers ne peut pas être réduit à un seul interrupteur global « bot IA ».

Pourquoi robots.txt ne suffit pas lorsque l'accès doit réellement être bloqué

La principale limite est inscrite dans le standard lui-même. La RFC 9309 précise que les règles robots.txt ne constituent pas une autorisation d'accès. Google formule la même idée de manière pratique : les instructions robots.txt ne peuvent pas forcer un crawler arbitraire à les respecter.

La requête atteint toujours votre serveur. Un crawler coopératif lit la politique et décide s'il poursuit. Un scraper inconnu peut ignorer complètement le fichier.

Cela ne rend pas robots.txt inutile. Cela signifie simplement que robots.txt et le contrôle d'accès répondent à des problèmes différents.

Méthode 2 : bloquer des User-Agents connus avec nginx ou Apache

Pour un blocage simple et ferme, le serveur web peut rejeter certaines chaînes User-Agent avant que la requête n'atteigne l'application.

if ($http_user_agent ~* "(GPTBot|ClaudeBot|PerplexityBot)") {
    return 403;
}

Avec Apache et mod_rewrite, la même idée peut s'écrire ainsi :

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ClaudeBot|PerplexityBot) [NC]
RewriteRule ^ - [F,L]

Ces exemples sont utiles lorsque vous souhaitez explicitement rejeter une identité de crawler connue. Ils ne vérifient toutefois pas que le crawler est réellement celui qu'il prétend être.

Le problème d'identité : un User-Agent n'est qu'une chaîne de caractères

N'importe quel client HTTP peut prétendre être Googlebot, GPTBot, ClaudeBot ou un navigateur Chrome ordinaire. Google avertit explicitement que les User-Agents de ses crawlers peuvent être usurpés et recommande de vérifier l'identité plutôt que de faire confiance au nom seul.

Le blocage simple par User-Agent échoue donc dans deux directions :

• un scraper peut contourner la règle en modifiant son User-Agent pour ressembler à un navigateur ;
• un client malveillant peut se faire passer pour un crawler de confiance et espérer que vos règles d'autorisation se fient uniquement au nom.

Lorsque l'identité du crawler compte, combinez l'identité déclarée avec des signaux réseau, de réputation et de contexte de requête.

Méthode 3 : utiliser une intelligence bot côté serveur avec BotDetect

BotDetect est conçu pour les situations où une règle User-Agent statique ne suffit plus, sans vous obliger à déplacer votre site derrière un autre CDN ou un reverse proxy supplémentaire.

Votre backend envoie les métadonnées de la requête à un nœud API régional BotDetect et reçoit une décision explicable que votre application peut utiliser :

Bot intelligence as an API — not another CDN

La différence architecturale essentielle est le contrôle. Vous conservez votre hébergement, votre DNS, votre CDN éventuel, votre reverse proxy et votre application. BotDetect ajoute une couche d'intelligence au lieu de devenir le chemin obligatoire de tout votre trafic.

De l'explicabilité plutôt qu'un oui/non de boîte noire

BotDetect renvoie un score de 0 à 10 avec une raison et les signaux contributifs. Une décision concernant un crawler suspect peut donc être expliquée en termes opérationnels, par exemple :

{
  "score": 9,
  "reason": "fakecrawler",
  "action": "block",
  "signals": [
    "googlebot_asn_mismatch",
    "browser_headers_missing",
    "ip_reputation"
  ]
}

Les signaux exacts disponibles dépendent de la requête et de la logique de scoring en vigueur. L'important est que l'administrateur puisse comprendre pourquoi une requête a été jugée suspecte au lieu de recevoir uniquement blocked=true.

Réputation partagée : bénéficier des abus observés ailleurs

Un site isolé ne voit que son propre trafic. BotDetect utilise aussi une réputation partagée construite à partir d'observations de sécurité sur les services protégés et distribuée aux nœuds régionaux de détection. Lorsqu'une même source abusive apparaît ailleurs, une réputation peut donc déjà exister comme signal supplémentaire.

La réputation n'est pas une sanction automatique permanente. Elle constitue un signal parmi d'autres, combiné au contexte de la requête actuelle.

Pourquoi c'est plus fort que robots.txt

BotDetect ne remplace pas robots.txt. Il complète la couche d'application et de vérification :

• robots.txt indique aux opérateurs de crawlers légitimes la politique souhaitée ;
• BotDetect aide à évaluer la requête qui est réellement arrivée ;
• votre serveur décide de l'autoriser ou de la rejeter.

Sur WordPress, la protection anti-bot apporte aussi de la visibilité sur le trafic automatisé

Sur WordPress, une requête indésirable peut être disproportionnellement coûteuse, car elle peut déclencher PHP, le bootstrap WordPress, des plugins, des requêtes de base de données et le rendu du thème.

Le plugin WordPress BotDetect sert donc à plus qu'à renvoyer une réponse de blocage. Le propriétaire du site peut commencer en mode monitor, voir où l'automatisation touche le site, examiner les décisions et seulement ensuite activer une application plus stricte.

Zones WordPress typiques à surveiller :

• wp-login.php et le trafic d'authentification ;
• XML-RPC ;
• l'API REST WordPress ;
• admin-ajax.php ;
• la recherche, les formulaires, les commentaires et les URL paramétrées ;
• les contenus frontend ciblés par des scrapers IA ou de faux crawlers.

Le trafic IA indésirable a un coût réel pour l'infrastructure

Une requête HTTP isolée paraît presque gratuite. À grande échelle, elle peut impliquer le traitement TLS, l'exécution de l'application, des cache misses, des requêtes base de données ou moteur de recherche, des appels API, des logs, du stockage et de la bande passante.

À titre d'illustration volontairement simple, si le coût effectif d'une requête dynamique n'était que de 0,0001 € :

Ces chiffres sont illustratifs et ne constituent pas une estimation universelle. Le coût réel dépend de l'hébergement, du cache, de l'architecture applicative, du travail de la base de données, de la bande passante et de la charge.

L'idée est économique : un coût minuscule par requête devient significatif lorsque le trafic automatisé atteint des millions de requêtes. Rejeter l'automatisation indésirable avant des traitements applicatifs coûteux peut donc économiser de la capacité réelle.

robots.txt vs blocage User-Agent vs BotDetect

Une politique pratique en plusieurs couches

1. Décidez quel accès IA vous souhaitez réellement. Séparez le crawling pour le développement de modèles, la recherche IA et les récupérations initiées par l'utilisateur.
2. Publiez la politique dans robots.txt. Les opérateurs coopératifs ont besoin d'un signal standard clair.
3. Surveillez le trafic réel. Ne supposez pas que les bots documentés sont les seules automatisations qui touchent votre site.
4. Ne faites pas confiance au nom du crawler seul. Un User-Agent est auto-déclaré et peut être usurpé.
5. Appliquez les restrictions importantes côté serveur. Si l'accès doit réellement être refusé, votre serveur doit prendre la décision finale.
6. Commencez par le monitoring avant un blocage agressif. Vérifiez ce qui serait bloqué et réduisez le risque de faux positifs.

Questions fréquentes