Le trafic de bots, c'est toute requête vers votre site émise par un logiciel plutôt que par une personne devant un écran. Cette seule définition recouvre des choses aussi différentes que Googlebot indexant une fiche produit, une sonde de disponibilité qui interroge votre page d'accueil toutes les soixante secondes, un aspirateur qui récupère vos prix, et un script de bourrage d'identifiants qui déroule une liste de mots de passe fuités. Les mettre dans le même sac est l'erreur. Ce guide porte sur la façon de les distinguer, parce que la bonne réponse à chacun est complètement différente.
À retenir
- Le trafic de bots n'est pas un phénomène unique. Il se divise en automatisation utile, automatisation hostile et trafic synthétique que vous avez vous-même généré, et chacun relève en général d'un responsable différent dans une organisation.
- Google Analytics 4 exclut automatiquement le trafic provenant de bots et de robots d'exploration connus à l'aide de la liste internationale IAB/MRC des robots et bots. Ce filtre est réel, mais il fonctionne à partir d'une liste de bots connus, ce qui est précisément le mauvais outil pour attraper une automatisation qui cherche à ne pas être connue.
- Les chaînes User-Agent et le fichier
robots.txtsont des déclarations, pas des contrôles. Les deux fonctionnent très bien sur les bots bien élevés et ne signifient rien pour les autres. - L'identité doit être vérifiée au niveau du réseau (DNS inverse ou plages d'IP publiées), et non reprise d'un en-tête que n'importe quel client peut définir.
- Dès lors que l'automatisation vise les connexions, le tunnel de commande, les formulaires ou les prix, elle a cessé d'être une gêne pour le reporting pour devenir une affaire de sécurité, avec un circuit d'escalade différent.
Qu'est-ce qui compte réellement comme trafic de bots ?
La frontière utile est l'intention de l'opérateur, pas la technologie. Un navigateur sans interface n'est pas malveillant en soi ; votre propre suite de tests en fait sans doute tourner un. Trois questions règlent la plupart des cas : qui fait tourner cela, que prend-il ou que fait-il, et s'est-il annoncé ? Un robot d'exploration qui s'identifie et respecte vos directives d'exploration est un invité muni d'une carte de visite. Un jeu d'IP résidentielles qui parcourt vos URL produit à trois requêtes par seconde derrière un User-Agent Chrome standard est autre chose, même si, techniquement, les deux se contentent de charger des pages.
Les trois catégories qu'il vaut la peine de séparer
L'automatisation utile
Ces bots existent parce que vous avez intérêt à être visible ou observable. Les robots d'exploration des moteurs de recherche, comme Googlebot et Bingbot, construisent l'index dont dépend votre trafic naturel. Les sondes de disponibilité chargent des pages selon un calendrier pour que vous appreniez une panne avant vos clients. Les robots de comparaison de prix et d'affiliation peuvent faire partie d'un canal de distribution que vous voulez activement. Les récupérateurs d'aperçu de lien composent la vignette que voit une personne à qui votre URL est partagée dans une messagerie.
Une arrivée plus récente dans ce groupe est le robot d'exploration d'IA. OpenAI documente GPTBot, Anthropic documente ClaudeBot, et Common Crawl exploite depuis longtemps CCBot. Chacun publie une documentation décrivant l'agent et la manière de l'autoriser ou de l'interdire. Savoir si vous les voulez est une décision d'entreprise sur l'usage fait de vos contenus, pas une question de défense technique. À noter : les bloquer est un vrai choix, avec un coût des deux côtés, ce qui n'est pas le cas de la catégorie suivante.
L'automatisation hostile
Ici, le gain de l'opérateur est votre perte. Les aspirateurs de contenu et de prix copient votre catalogue, souvent à un débit de requêtes qui vous coûte de la capacité serveur bien réelle. Les scripts de bourrage d'identifiants rejouent des couples identifiant/mot de passe issus de fuites sans rapport contre votre point de connexion, raison pour laquelle un pic d'échecs de connexion depuis de nombreuses IP mérite une attention dans les heures qui suivent plutôt qu'au prochain cycle de reporting. La fraude au clic consomme du budget publicitaire sur des clics qu'aucun humain n'a faits. Le spam de formulaires et de commentaires pollue votre CRM et, pire, vos données de conversion. Les bots d'accaparement de stock ajoutent des articles en quantité limitée à des paniers qu'ils n'ont aucune intention d'acheter.
Le comportement caractéristique est l'évitement. Ce trafic fait tourner les adresses IP, imite les empreintes de navigateur courantes, se cadence sous les seuils évidents et ignore tout ce que vous écrivez dans robots.txt, parce que s'y conformer ne ferait que réduire sa moisson.
Le trafic de test synthétique
La troisième catégorie est l'automatisation que vous avez commandée : tests de charge, campagnes de validation de la mesure, contrôles de disponibilité que vous avez configurés, sessions scénarisées servant à confirmer qu'un événement de conversion se déclenche avec les bons paramètres. Ce n'est pas hostile, mais ce n'est pas humain non plus, et cela faussera tout rapport qui l'inclut. Sa particularité est que vous la contrôlez, ce qui veut dire que vous pouvez la baliser, la programmer et l'exclure proprement. Que vous le fassiez ou non fait toute la différence entre une expérience réversible et une propriété de mesure durablement brouillée.
| Catégorie | S'identifie ? | Respecte robots.txt ? | À qui revient la réponse |
|---|---|---|---|
| Robots d'exploration de recherche et d'IA | Oui, et de façon vérifiable | En général oui | SEO / stratégie de contenu |
| Sondes de supervision et d'aperçu | Le plus souvent | Souvent exemptés par conception | Ingénierie / exploitation |
| Aspirateurs et bourrage d'identifiants | Non | Non | Sécurité |
| Fraude au clic et spam de formulaires | Non | Sans objet | Média payant / sécurité |
| Votre propre trafic synthétique | Seulement si vous le balisez | Sous votre contrôle | Responsable de la mesure |
Ce que GA4 filtre automatiquement, et ce qui passe au travers
Google Analytics 4 exclut par défaut le trafic provenant de bots et de robots d'exploration connus. La documentation de Google décrit ce mécanisme comme reposant sur la liste internationale IAB/MRC des robots et bots, combinée à l'identification interne de Google, et il s'applique automatiquement plutôt que comme un réglage que vous activez. Pour le cas courant, des robots d'exploration déclarés qui atteignent une page portant votre code de mesure, cela fonctionne bien et discrètement.
La limite découle directement du mécanisme. Un filtre fondé sur une liste attrape l'automatisation qui figure sur une liste. Il n'est pas conçu pour identifier un logiciel qui se présente comme une session Chrome ordinaire depuis une adresse IP résidentielle, et il ne faut pas l'attendre de lui. Trois angles morts pratiques méritent d'être nommés :
- L'automatisation non déclarée. Tout ce qui imite délibérément un navigateur sera généralement mesuré comme une session, avec un appareil, une zone géographique et un référent plausibles.
- Le trafic qui n'exécute jamais votre JavaScript. Beaucoup de bots chargent le HTML et s'arrêtent là. GA4 ne les voit jamais, si bien que vos statistiques sous-estiment la charge totale. C'est le mode de défaillance inverse du précédent, et c'est pourquoi les statistiques seules ne peuvent pas vous dire quelle quantité d'automatisation votre serveur encaisse.
- Vos propres sessions synthétiques. Rien dans le filtre automatique ne sait que le test de charge que vous avez commandé n'était pas un client. Cette exclusion, c'est à vous de la construire.
La leçon générale : le filtre anti-bots de GA4 est une fonction d'hygiène du reporting, pas un système de détection. Voyez-le comme un moyen de retirer le bruit évident, pas comme une réponse à la question « quelle part de ce trafic était humaine ? ».
Comment les distinguer dans les journaux serveur
Les journaux serveur consignent chaque requête arrivée, y compris celles qui n'ont jamais exécuté une ligne de JavaScript. Cela en fait la trace la plus complète, et l'endroit où la classification a réellement lieu.
Les signaux qui pèsent, à peu près par ordre de fiabilité :
- Identité vérifiée. Google publie une procédure de vérification pour ses robots d'exploration : une résolution DNS inverse sur l'IP émettrice, puis une résolution directe sur le nom d'hôte obtenu pour confirmer qu'il renvoie bien à la même adresse. Google publie également les plages d'IP de ses robots au format JSON, et OpenAI publie des plages pour GPTBot. Bing propose un outil de vérification comparable. C'est la seule classe de signal qu'un client ne peut pas simplement affirmer.
- Le motif des requêtes. Des intervalles parfaitement réguliers, une énumération séquentielle d'URL et des requêtes de HTML sans chargement associé de CSS, d'images ou de polices suggèrent tous un client qui n'est pas un navigateur.
- La concentration sur des points de terminaison. Un trafic lourd vers
/login, vers un point de recherche ou vers un gabarit portant des prix, avec peu d'intérêt pour le reste, décrit une intention. - L'origine réseau. L'espace d'adressage de centre de données est normal pour des robots déclarés et inhabituel pour des visites grand public. Le trafic passant par des proxys résidentiels inverse ce constat, et c'est une des raisons pour lesquelles l'origine seule n'est pas concluante.
- La chaîne User-Agent. Utile pour regrouper, sans valeur comme preuve. Ce n'est pas pour rien qu'elle arrive en dernier.
Un point supplémentaire propre à la classification : le groupe de clients qui apparaissent dans votre journal d'accès mais jamais dans vos statistiques est, presque par définition, de l'automatisation hors navigateur. Ce groupe est invisible pour quiconque travaille uniquement à partir des statistiques.
Pourquoi robots.txt et le User-Agent sont de faibles signaux
robots.txt est une demande de coopération volontaire. Le protocole d'exclusion des robots a été formalisé par la RFC 9309 en 2022, et la norme elle-même décrit le respect de ces règles comme volontaire de la part du robot d'exploration. Les grands moteurs de recherche l'honorent ; un aspirateur n'a aucune raison de le faire. Il y a un piège supplémentaire : publier une règle Disallow pour un chemin sensible signale ce chemin à quiconque lit le fichier, qui est public par définition. Servez-vous-en pour gérer le comportement et le budget d'exploration, jamais comme contrôle d'accès.
L'en-tête User-Agent souffre de la même faiblesse structurelle. C'est une chaîne que le client choisit. N'importe qui peut envoyer Googlebot dans ce champ, et n'importe qui peut y envoyer à la place une chaîne Chrome récente. C'est pour cela que l'étape de vérification ci-dessus existe. En pratique, considérez le User-Agent comme une étiquette servant à ranger un trafic que vous avez déjà classé par d'autres moyens.
Quelle part du Web est automatisée ?
Réponse honnête : personne ne peut vous donner un chiffre que vous devriez citer avec assurance. Les estimations publiées viennent surtout d'éditeurs de sécurité, au premier rang desquels le rapport annuel d'Imperva sur les bots malveillants, et de mesures similaires d'autres fournisseurs. Elles sont utiles pour donner une tendance, mais elles sont tirées du trafic transitant par la base de clients de chaque éditeur, laquelle penche vers des sites assez grands pour s'offrir une protection anti-bots et vers les surfaces d'attaque que ces sites présentent. Éditeurs différents, méthodologies différentes, chiffres différents.
Ce que l'on peut dire sans risque, qualitativement, c'est que la part automatisée est assez grande pour compter sur pratiquement tout site public, et qu'elle varie énormément selon le type de site. Un service grand public riche en connexions, une plateforme de billetterie et un site de documentation statique n'affrontent pas du tout le même mélange. Le chiffre qui doit guider vos décisions est celui de vos propres journaux, pas une moyenne du secteur.
Quand le trafic de bots devient un problème de sécurité
La ligne est comportementale, pas volumétrique. Le trafic de bots est un problème de mesure tant qu'il ne fait que gonfler des compteurs. Il devient un problème de sécurité dès l'instant où il interagit avec quelque chose qui a des conséquences.
Faites remonter plutôt que filtrer dès que vous constatez l'un des éléments suivants : une hausse des tentatives de connexion échouées réparties sur de nombreuses adresses sources, des envois de formulaires produisant des événements de conversion sans activité plausible en aval, des actions de commande ou de panier qui n'aboutissent jamais, une énumération systématique d'identifiants utilisateurs ou de numéros de commande, ou un volume de requêtes causant une vraie tension sur la capacité. Chacun de ces cas a un coût qui perdure, que vous excluiez ou non ce trafic d'un tableau de bord.
La conséquence pratique d'une erreur sur cette frontière, c'est qu'une campagne de bourrage d'identifiants est traitée comme un désagrément de reporting, filtrée hors d'une vue GA4, et laissée en activité contre le point de connexion. Le filtre a rendu le symptôme invisible sans toucher à la cause.
Questions fréquentes
Tout trafic de bots est-il mauvais ?
Non, et le traiter ainsi cause des dégâts réels. Bloquer les robots d'exploration des moteurs de recherche vous retire de l'index. Bloquer les récupérateurs d'aperçu de lien casse l'apparence de vos URL lorsqu'elles sont partagées. L'objectif est la classification et une réponse adaptée, pas l'élimination.
GA4 supprime-t-il tout le trafic de bots ?
Il supprime automatiquement le trafic des bots et robots d'exploration connus figurant sur la liste IAB/MRC. Il ne supprime pas l'automatisation qui se présente comme un navigateur ordinaire, et il ne voit jamais les clients qui n'exécutent pas votre code de mesure. Ce sont deux angles morts distincts, orientés en sens inverse.
Puis-je identifier Googlebot à partir de la seule chaîne User-Agent ?
Non. La documentation de Google recommande explicitement de vérifier par une résolution DNS inverse suivie d'une résolution directe, ou par correspondance avec les plages d'IP de robots publiées par Google. Le User-Agent est trivialement falsifiable et ne devrait jamais servir de base pour accorder un accès.
Faut-il bloquer les robots d'exploration d'IA comme GPTBot ou ClaudeBot ?
C'est une décision de licence de contenu plutôt qu'une décision de sécurité. Les deux sont documentés et les deux peuvent être interdits dans robots.txt. Mettez en balance l'intérêt d'apparaître dans les réponses générées par l'IA et votre position sur l'usage de vos contenus à des fins d'entraînement. Il n'y a pas de réponse techniquement correcte, seulement une réponse commerciale.
Quelle est la première chose à vérifier lors d'un pic de trafic inexpliqué ?
Les journaux serveur, pas les statistiques. Regardez quels points de terminaison ont été atteints, à quel intervalle, depuis quels réseaux, et si les requêtes ont chargé les ressources de la page ou seulement le HTML. Ces quatre observations identifient en général la catégorie en quelques minutes, et la catégorie détermine qui doit s'en occuper.