N'importe qui peut se dire GPTBot
Un scraper malveillant se présente comme GPTBot et aspire tout le site. Ne faites jamais confiance à un User-Agent qui se falsifie en une seule ligne de code.
Une ligne de code, une fausse identité
Un pic de trafic inattendu frappe l’infrastructure. L’équipe technique consulte vos fichiers journaux et constate une vague de requêtes signées « GPTBot ». Pensant nourrir l’index de ChatGPT, on ouvre grand la porte. C’est une erreur fondamentale de sécurité réseau.
La chaîne User-Agent n’est qu’un en-tête HTTP strictement déclaratif. N’importe quel script Python de dix lignes peut se faire passer pour le crawler d’OpenAI ou PerplexityBot en modifiant un simple paramètre lors de la requête. Autoriser ou bloquer un accès sur cette seule foi équivaut à laisser entrer un inconnu dans un bâtiment sécurisé simplement parce qu’il a écrit « Sécurité » sur son badge au marqueur.
L’usurpation est triviale, indétectable par une simple lecture de chaîne de caractères. Le bénéfice immédiat d’abandonner cette naïveté est de fermer instantanément la porte aux aspirateurs de contenu qui pillent votre propriété intellectuelle sous une fausse bannière.
Les deux risques symétriques
Fonder sa politique d’accès sur le User-Agent expose l’infrastructure à deux failles critiques. La première est l’intrusion de l’imposteur. Un scraper malveillant, masqué sous l’identité d’un bot IA légitime, génère une charge serveur inutile, siphonne la base de données et contourne vos restrictions de scraping sans jamais vous citer en retour.
Le second risque est le faux positif. En tentant de bloquer le crawler d’OpenAI via des expressions régulières approximatives sur l’en-tête, un pare-feu mal configuré peut rejeter des requêtes légitimes, y compris celles d’utilisateurs naviguant via des proxys spécifiques ou des outils de test internes.
Un système de filtrage basé sur le User-Agent n’est pas une barrière, c’est une passoire qui laisse passer les menaces et bloque parfois les opportunités.
La symétrie de ces risques impose de changer de paradigme. En abandonnant la lecture de l’en-tête au profit d’une vérification cryptographique et réseau, l’équipe technique sécurise la bande passante tout en garantissant que les véritables moteurs génératifs accèdent au contenu sans entrave.
Vérifier par IP et reverse DNS
L’identité d’un bot ne se lit pas, elle se prouve. La seule méthode robuste repose sur la couche réseau. Les éditeurs sérieux de modèles de langage documentent et publient les plages d’adresses IP (CIDR) utilisées par leurs crawlers. La première étape consiste à confronter l’IP entrante à ces listes officielles.
Si le bot appartient à un acteur qui ne publie pas ses plages de manière statique, la vérification exige un reverse DNS forward-confirmé (FCrDNS). L’opération s’exécute en deux temps : une requête PTR sur l’adresse IP pour obtenir le nom de domaine associé, suivie d’une requête A ou AAAA sur ce domaine pour vérifier qu’elle pointe bien vers l’IP initiale.
Si la boucle réseau ne se ferme pas sur le domaine officiel de l’opérateur, la requête est frauduleuse. Le bénéfice technique est absolu : cette méthode de résolution garantit l’identité du visiteur avec un niveau de certitude que l’usurpateur ne peut pas falsifier.
La même exigence que sur les sources
Cette rigueur dans l’identification des bots s’inscrit dans la continuité directe de la méthodologie Sonar appliquée à l’analyse des citations IA. Lorsque nous qualifions une mention générée par un modèle, nous n’accordons aucune confiance à l’URL citée en source telle qu’elle apparaît à l’écran.
Une citation apparente peut cacher un redirecteur proxy, un agrégateur tiers ou une version en cache obsolète. Pour valider l’autorité d’une source, notre pipeline résout la chaîne de redirection complète et vérifie la présence exacte du passage dans le DOM final.
C’est le même geste de méfiance technique. On ne fait jamais confiance à ce qui se déclare, on vérifie systématiquement ce qui se prouve. Appliquer cette hygiène de vérification aux crawlers unifie la posture de l’agence : de l’ingestion du contenu par le bot jusqu’à la restitution de la source par le LLM, chaque maillon est audité et certifié.
Industrialiser la vérification
La vérification par IP ou FCrDNS ne doit pas être une tâche manuelle ou une rustine post-incident. Elle doit s’intégrer nativement dans le pipeline de readiness de l’infrastructure. L’ingénierie de détection se déplace de l’application vers la périphérie du réseau.
Les listes d’IP publiées par les opérateurs IA évoluent. L’automatisation consiste à synchroniser quotidiennement ces plages CIDR avec les règles de votre CDN. Pour les résolutions DNS, les mécanismes de cache en bordure de réseau permettent d’exécuter la double vérification sans introduire de latence pénalisante pour le routage des requêtes.
Industrialiser ce contrôle d’identité transforme une vulnérabilité réseau en un filtre déterministe. L’infrastructure ne subit plus les assauts des usurpateurs et l’équipe garantit contractuellement que les ressources allouées au crawl profitent exclusivement aux véritables moteurs d’intelligence artificielle.