Les robots IA recherchent-ils réellement vos fichiers secrets ? Enquête sur un phénomène observé dans les logs web

Depuis quelques mois, un détail intrigue les administrateurs de sites qui prennent le temps d’ouvrir leurs journaux d’accès. Entre deux passages de robots d’indexation, on voit apparaître des requêtes qui n’ont rien à faire là : quelqu’un, quelque part, demande à votre serveur de lui livrer un fichier nommé serviceAccountKey.json, secrets.yml ou rclone.conf. Et à côté de ces requêtes, un nom familier : GPTBot, Google-Extended, Cohere-AI.

La lecture immédiate est tentante : « Les IA ne se contentent plus de lire mes articles, elles fouillent mes fichiers de configuration. » C’est une bonne histoire. Elle est aussi presque entièrement fausse — et la vraie explication est bien plus intéressante. Voici ce que révèlent réellement les logs.

Ce que montrent vraiment les journaux d’accès

Le point de départ n’est pas une théorie, mais une observation de terrain, sur plusieurs sites de mon réseau éditorial. Un soir de juillet 2026, à quelques secondes d’intervalle, ces lignes apparaissent :

19:25:25  GPTBot           /rclone.conf
19:25:28  GPTBot           /key.json
19:25:28  Google-Extended  /serviceAccountKey.json
19:25:28  Google-Extended  /secrets.json
19:25:28  Cohere-AI        /secrets.yml

Cinq fichiers de secrets, trois « robots IA » différents, le tout compressé dans une fenêtre de trois secondes. Aucun de ces fichiers n’existe sur le serveur : tous renvoient un 404 Not Found. Et surtout, chaque fichier n’est demandé qu’une seule fois.

Sur un autre site, le motif est encore plus parlant. En agrégeant les passages, une seule et même adresse IP se présente successivement sous treize User-Agents de bots IA différents : GPTBot, ClaudeBot, Google-Extended, PerplexityBot, Cohere-AI, Amazonbot, Meta-ExternalAgent, OAI-SearchBot… en allant chercher des fichiers comme env.js, config.js, __env.js ou runtime-config.js.

Une adresse IP unique qui porte treize identités de crawlers concurrents en même temps, ce n’est pas un comportement de robot d’IA. C’est la signature d’un scanner. Le reste de cet article explique pourquoi.

À retenir Ce que vous voyez n’est pas OpenAI ou Google en train de fouiller votre serveur. C’est un outil d’analyse de vulnérabilités qui emprunte le nom de ces robots. Le nom affiché ne prouve rien.

Quels fichiers sont visés, et ce qu’ils contiennent

Les fichiers demandés ne sont jamais choisis au hasard. Ce sont des noms conventionnels, universellement utilisés par les développeurs, et connus pour contenir des identifiants critiques lorsqu’ils traînent au mauvais endroit.

Le point commun de tous ces fichiers : ils n’ont aucune raison légitime d’être accessibles depuis le Web. Leur présence en clair à la racine d’un site est presque toujours le symptôme d’une erreur de déploiement — un fichier oublié, une sauvegarde laissée en place, un dossier .git déployé par mégarde.

Pourquoi ces fichiers valent de l’or

Une seule de ces fuites peut suffire à compromettre une infrastructure entière. Un serviceAccountKey.json exposé, c’est potentiellement un accès complet à un projet Google Cloud : bases de données, stockage, facturation. Un .env mal placé, c’est d’un coup la clé de la base de données, les identifiants SMTP, les tokens de paiement et les clés d’API tierces.

C’est pourquoi des scanners parcourent le Web en permanence à la recherche de ces erreurs. Leur logique est purement statistique : ils savent qu’à l’échelle de millions de sites, un petit pourcentage aura laissé traîner l’un de ces fichiers. Plutôt que d’attaquer un serveur en particulier, ils testent quelques dizaines d’URL classiques sur des millions de domaines, automatiquement.

Un seul passage par fichier : la signature du scan opportuniste

C’est le détail qui trahit tout. Un vrai robot d’indexation revient, suit des liens, explore en profondeur, respecte un rythme de crawl. Un scanner de secrets, lui, fonctionne en tir unique :

1. il tente une liste figée d’URL connues ;
2. si le serveur répond 404, il abandonne immédiatement et passe au site suivant ;
3. si le serveur répond 200 OK, alors seulement il approfondit.

Un passage unique par fichier, des dizaines de noms différents testés en rafale, puis plus rien : c’est exactement le profil d’un scan opportuniste, à l’opposé du comportement d’un crawler éditorial qui reviendrait consulter vos pages.

Mais est-ce vraiment GPTBot ou Google-Extended ?

Nous arrivons à la question centrale. Comment un robot officiel d’OpenAI ou de Google peut-il apparaître dans les logs en train de réclamer un fichier de secrets ?

La réponse tient en une phrase : le User-Agent est déclaratif. C’est une simple chaîne de caractères que le client envoie lui-même, et que n’importe quel programme peut remplir avec la valeur de son choix. Se faire passer pour GPTBot, Googlebot ou Chrome ne demande qu’une ligne de code. Le nom inscrit dans vos logs indique ce que le visiteur prétend être, jamais ce qu’il est.

Aucune documentation d’OpenAI, de Google ou de Cohere n’indique que leurs robots de collecte cherchent des fichiers de configuration. Ces robots sont documentés comme des explorateurs de contenu public, soumis au protocole robots.txt. Voir leur nom accolé à une requête vers secrets.json devrait donc éveiller le soupçon, pas la conclusion.

Le cas Google-Extended, qui démasque le scanner à lui seul

Voici la preuve la plus nette, et elle est vérifiable par tout le monde. Selon la documentation officielle de Google, Google-Extended n’est pas un robot et n’émet aucun User-Agent HTTP. C’est uniquement un token de contrôle que l’on place dans robots.txt pour autoriser ou refuser l’utilisation de son contenu dans l’entraînement de Gemini. Le crawl, lui, reste effectué par Googlebot, avec le User-Agent habituel de Googlebot.

La conséquence est sans appel : si vos logs affichent « Google-Extended » comme User-Agent, ce n’est pas Google. Google n’envoie jamais ce nom dans une requête HTTP. Une ligne de log portant ce User-Agent est, par construction, une usurpation. Dans mon exemple ci-dessus, les deux requêtes « Google-Extended » vers serviceAccountKey.json et secrets.json sont donc, avec certitude, du trafic déguisé.

Le scanner qui porte treize masques

Le second indice est arithmétique. Les vrais crawlers d’IA opèrent depuis des plages d’adresses IP identifiables, propres à chaque fournisseur. Il est impossible que GPTBot, ClaudeBot, PerplexityBot et dix autres partagent tous, à la même seconde, la même adresse IP. Or c’est exactement ce que l’on observe : une IP unique se présentant sous treize identités de bots. Un seul acteur, treize masques. Le diagnostic est immédiat.

Comment vérifier si un bot est authentique

Puisque le nom ne prouve rien, la seule méthode fiable consiste à vérifier l’origine réseau de la requête. Deux techniques se combinent.

1. La liste d’IP publiée par le fournisseur. Les principaux acteurs publient les plages d’adresses depuis lesquelles leurs robots opèrent. Il suffit de vérifier que l’IP de la requête figure bien dans la liste correspondant au User-Agent annoncé.

2. Le reverse DNS confirmé (FCrDNS). Quand aucune liste n’est disponible, on interroge l’adresse IP dans les deux sens :

# 1. Reverse : à quel nom d'hôte correspond cette IP ?
host 66.249.66.1
# -> crawl-66-249-66-1.googlebot.com

# 2. Forward : ce nom d'hôte renvoie-t-il bien à l'IP de départ ?
host crawl-66-249-66-1.googlebot.com
# -> doit renvoyer 66.249.66.1

Si le nom d’hôte n’appartient pas au domaine du fournisseur, ou si la résolution inverse ne boucle pas sur l’IP d’origine, la requête est usurpée — quel que soit le User-Agent affiché.

À retenir La règle d’or : User-Agent + IP vérifiée = confiance ; User-Agent seul = rien du tout. Tant que l’IP n’est pas confirmée, un « GPTBot » dans vos logs n’est qu’un client qui a tapé « GPTBot » dans un en-tête.

Pourquoi des pirates se déguisent-ils précisément en IA ?

Le choix n’est pas anodin. Il y a deux raisons très concrètes.

D’abord, beaucoup de sites et d’hébergeurs ont mis les robots d’IA en liste blanche. Depuis l’essor des moteurs de réponse, on veut être lu par ChatGPT ou Perplexity. Résultat : des règles de pare-feu ou de CDN laissent délibérément passer les User-Agents d’IA. Un scanner qui se déguise en GPTBot profite alors d’un tapis rouge que le trafic « inconnu » n’aurait pas.

Ensuite, cela brouille l’analyse. Un administrateur qui voit « GPTBot » dans ses logs a tendance à ne pas s’inquiéter. Le déguisement achète de la discrétion : le scan se fond dans un trafic réputé légitime.

Comment protéger son serveur (pour les administrateurs)

La bonne nouvelle : ces scans ne sont dangereux que si les fichiers convoités existent réellement et sont accessibles. Trois niveaux de protection.

Ne jamais exposer ces fichiers. Les secrets doivent vivre en dehors de la racine web (public_html, www). Un .env doit se trouver au-dessus du répertoire servi, jamais dedans. Un dossier .git n’a rien à faire sur un serveur de production.

Bloquer explicitement les noms sensibles. Sous Apache (.htaccess) :

<FilesMatch "(^\.env|^\.git|serviceAccountKey\.json|secrets\.(ya?ml|json)|rclone\.conf|.*\.(bak|sql|conf))$">
    Require all denied
</FilesMatch>

Sous Nginx :

location ~ /\.(?!well-known) { deny all; }
location ~* \.(env|bak|sql|conf|ya?ml)$ { deny all; }
location = /serviceAccountKey.json { deny all; }

Filtrer au niveau du pare-feu ou du CDN. Une règle Cloudflare ou un WAF peut bloquer les requêtes vers ces chemins avant même qu’elles n’atteignent le serveur. C’est aussi là qu’on peut, à terme, croiser User-Agent et plage IP officielle pour ne laisser passer que les vrais robots.

Un rappel essentiel : robots.txt n’est pas un outil de sécurité. Il exprime une préférence que seuls les robots honnêtes respectent. Un scanner malveillant le lit surtout comme une liste de bonnes adresses à visiter.

Analyser ses propres logs en quelques commandes

Pas besoin d’outil sophistiqué pour repérer ces motifs. Quelques lignes suffisent.

Repérer les requêtes vers des fichiers sensibles :

grep -E "serviceAccountKey|secrets\.(ya?ml|json)|\.env|rclone\.conf|\.git/" access.log

Identifier une IP qui porte plusieurs identités de bots (le signal d’usurpation) :

grep " 203.0.113.42 " access.log \
  | grep -oiE "GPTBot|ClaudeBot|Google-Extended|PerplexityBot|Cohere-AI|Amazonbot" \
  | sort | uniq -c

Si cette dernière commande renvoie plusieurs noms de bots pour une même IP, vous tenez votre scanner.

Ce que ce phénomène dit du Web en 2026

Cette petite énigme de logs raconte une évolution plus large. L’identité des robots d’IA est devenue une monnaie de confiance : parce qu’on veut être lu par les assistants, on leur ouvre des portes. Et dès qu’une identité vaut un accès, elle devient un déguisement rentable pour ceux qui veulent forcer ces portes.

La leçon pratique dépasse le sujet des secrets : à mesure que le trafic IA prend de l’ampleur, l’analyse des logs ne peut plus se contenter du nom du bot. La question n’est plus « quel robot est passé ? » mais « ce robot était-il bien celui qu’il prétendait être ? ». C’est un changement de posture, et il vaut pour le SEO, pour la sécurité et pour la mesure de visibilité dans les IA.

Questions fréquentes

GPTBot ou ClaudeBot volent-ils vraiment mes fichiers de configuration ? Rien ne l’indique. Leur documentation les décrit comme des explorateurs de contenu public. Les requêtes vers des fichiers de secrets proviennent presque toujours de scanners qui usurpent leur nom.

Comment être sûr qu’un « GPTBot » est authentique ? En vérifiant que son adresse IP figure dans les plages publiées par OpenAI, ou via un reverse DNS confirmé. Le User-Agent seul ne suffit jamais.

Pourquoi « Google-Extended » apparaît-il dans mes logs ? Ce ne devrait jamais être le cas : Google-Extended est un token robots.txt, pas un robot, et Google n’envoie pas ce nom en User-Agent. Sa présence dans un log signale une usurpation.

Ces scans sont-ils dangereux ? Seulement si les fichiers ciblés existent et sont accessibles. Sur un serveur correctement configuré, ils se soldent par des 404 sans conséquence.

Faut-il bloquer les robots d’IA pour s’en protéger ? Non : bloquer les vrais robots ne stoppe pas les faux, qui ignorent vos règles. La protection passe par la configuration du serveur et le filtrage par IP, pas par le blocage des noms.

robots.txt peut-il empêcher ces requêtes ? Non. Il n’est respecté que par les robots honnêtes. Un scanner de secrets ne s’y soumet pas.

Conclusion

Le phénomène est réel : oui, des requêtes vers des fichiers secrets, estampillées du nom des grands robots d’IA, apparaissent bel et bien dans les logs. Mais l’interprétation spectaculaire — « les IA fouillent nos serveurs » — ne résiste pas à l’examen. Ce que révèlent vraiment les journaux, c’est l’usurpation systématique des identités de robots d’IA par des scanners de vulnérabilités, qui exploitent la confiance nouvelle accordée à ces noms.

La vraie compétence, en 2026, n’est plus de lire les logs, mais de les lire avec méfiance : distinguer le crawl éditorial, l’exploration IA légitime et le scan de sécurité déguisé. C’est précisément cette lecture croisée — nom du bot, comportement, et surtout adresse IP vérifiée — qui sépare le constat hâtif de l’analyse solide.

Sources et pour aller plus loin

• Documentation Google sur Google-Extended et les User-Agents de crawl (developers.google.com).
• Plages IP publiées par OpenAI : openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json.
• Liste de vérification IP publiée par Anthropic pour ClaudeBot (documentation Anthropic).
• Méthode de reverse DNS confirmé (FCrDNS) recommandée par Google et Bing pour authentifier les crawlers.