Trafic de bots ou humain : comment faire la différence

Si vos analyses montrent soudain un pic de trafic, la première question est généralement : s’agit-il d’une vague de clients, d’un crawler utile ou d’une attaque automatisée ? La réponse compte. Bloquer tous les bots peut nuire à la visibilité dans les moteurs de recherche et aux intégrations, tandis que faire confiance à chaque requête qui ressemble à celle d’un navigateur peut exposer les points de terminaison de connexion, de paiement, de recherche et d’API au scraping, au credential stuffing et au déni de service.

La réponse pratique n’est pas un détecteur de bots unique. Le trafic humain et le trafic de bots se recouvrent : une personne peut utiliser une extension de navigateur, une application mobile ou un réseau de protection de la vie privée, tandis qu’un bot peut exécuter JavaScript, conserver des cookies et faire tourner son adresse IP. Traitez la classification comme une décision de risque, pas comme une étiquette permanente.

Commencez par le modèle de menace

Listez les comportements automatisés qui nuiraient à votre activité avant de choisir une règle. Le projet Automated Threats to Web Applications d’OWASP décrit le scraping, le credential stuffing, la création de comptes, l’achat automatisé, le déni d’inventaire et la distorsion des métriques comme des menaces distinctes. Ils n’ont pas les mêmes indicateurs ni la même réponse.

• Scraping : consomme du contenu et de la bande passante, souvent avec une couverture large et répétable des URL.
• Credential stuffing : cible les routes de connexion ou de réinitialisation de mot de passe avec de nombreux comptes et de faibles taux de succès.
• Abus d’inventaire : se concentre sur les parcours de recherche, panier, réservation ou paiement.
• Déni de service : peut viser des pages coûteuses, des API ou l’infrastructure plutôt qu’un seul compte.
• Automatisation utile : comprend les crawlers de recherche, vérifications de disponibilité, outils d’accessibilité et intégrations approuvées.

Associez chaque menace aux routes, données, identités et coûts amont qu’elle peut affecter. Votre politique doit être plus stricte sur un point de terminaison de réinitialisation de mot de passe que sur un article public, et plus stricte sur une réservation de stock que sur l’image d’un produit.

Les signaux qui améliorent la classification

1. Considérez les déclarations d’identité comme un point de départ

L’en-tête User-Agent est utile pour grouper le trafic, mais il est auto-déclaré. Un client peut prétendre être un navigateur, un crawler de recherche ou un agent IA sans l’être. Si vous autorisez un crawler connu, vérifiez-le en appliquant la méthode documentée par son propriétaire, comme une vérification DNS inverse puis directe publiée lorsque disponible. N’autorisez pas un crawler sur la seule base d’une chaîne correspondante.

L’adresse IP et l’ASN apportent du contexte, pas de certitude. L’infrastructure cloud peut héberger dans les mêmes plages des services légitimes et de l’automatisation abusive. Les réseaux résidentiels et mobiles peuvent aussi produire de nombreux visiteurs non liés derrière des adresses partagées. Utilisez la réputation réseau comme une entrée et évitez les blocages larges qui pénalisent tout un fournisseur ou pays sans raison métier.

2. Observez la cohérence du client

Les vrais navigateurs produisent généralement un profil de requêtes cohérent : comportement TLS et HTTP moderne, en-têtes plausibles, types de contenu acceptés, cookies persistants entre les requêtes et signaux de navigation adaptés à la route. L’automatisation peut présenter des combinaisons impossibles, des en-têtes de navigateur absents, une empreinte fixe sur de nombreux comptes ou un taux élevé de requêtes sans séquence de pages normale.

Ce sont des indicateurs, pas une autorisation de prendre l’empreinte de tout le monde indéfiniment. Ne collectez que ce que le risque exige, documentez la finalité, protégez les données et fixez une période de conservation. Pour les parcours sensibles, un signal de risque de courte durée est généralement plus approprié qu’une identité d’appareil permanente.

3. Mesurez le comportement et la vélocité

Observez les séquences plutôt que les requêtes isolées. Citons par exemple des centaines de pages produit demandées dans un ordre prévisible, des tentatives de connexion réparties sur de nombreux identifiants, des réinitialisations de mot de passe répétées ou un parcours de paiement effectué trop rapidement pour être plausible. Comparez le débit de requêtes par route, session, compte, IP, ASN, signal d’appareil et résultat.

Le comportement devient plus utile lorsqu’il est rapproché d’événements métier. Un visiteur qui lit des pages et finalise un achat ne doit pas être traité comme un client qui demande chaque SKU sans jamais charger d’assets ni soumettre de session valide. Utilisez la limitation de débit pour contenir la vélocité pendant que votre détection s’améliore.

Établissez une réponse graduée

Utilisez des niveaux de confiance plutôt qu’une règle immédiate d’autorisation ou de blocage :

1. Confiance faible : journalisez le signal et servez normalement.
2. Suspect : réduisez la vitesse des requêtes, ajoutez une légère étape supplémentaire ou restreignez uniquement l’action coûteuse.
3. Confiance élevée : bloquez la route, la session, l’identifiant ou la source d’automatisation qui cause le préjudice.
4. Connu comme légitime : autorisez le crawler ou l’intégration documenté, mais conservez un budget distinct de débit et d’erreurs.

La réponse doit correspondre à la menace. Un scraper public peut recevoir du contenu en cache ou une réponse plus lente. Une attaque par identifiants doit recevoir un échec générique et des limites fortes sur la source comme sur le compte ciblé. Un crawler de recherche doit recevoir le contenu qu’il est autorisé à explorer, pas un accès sans restriction aux routes de compte ou de paiement.

Un contrôle de périphérie peut réduire le trafic indésirable avant qu’il n’atteigne l’application, mais la logique métier doit toujours rester dans l’application. Une politique de gestion des bots peut identifier des schémas ; l’application doit toujours appliquer la propriété des comptes, les limites d’achat, l’autorisation et les contrôles antifraude. Pour les API, associez la décision de périphérie à l’authentification, aux vérifications de schéma et aux quotas, comme décrit dans la protection des API.

Déployez sans casser le parcours client

Commencez en mode observation seule. Créez un tableau de bord avec les requêtes par route, statut, pays, ASN, catégorie de client, temps de réponse, résultat d’authentification et raison de la décision. Échantillonnez de vraies sessions sur les principaux appareils, réseaux, régions, crawlers et partenaires. Testez la connexion, la recherche, le paiement, les API et les parcours d’accessibilité plutôt que de vous fier à la page d’accueil.

Ensuite, appliquez une règle étroite à une route à haut risque. Comparez les faux positifs, les connexions réussies, les étapes de conversion, la couverture des crawlers, les signalements au support et la charge sur l’origine avant d’étendre la règle. Conservez un contournement d’urgence authentifié, audité, limité dans le temps et inaccessible via les en-têtes ordinaires des requêtes. Revoyez les règles après les lancements, promotions, sorties d’applications mobiles et changements de partenaires.

Erreurs fréquentes

• Bloquer chaque ASN cloud ou IP de centre de données, ce qui bloque également des intégrations légitimes et des outils de sécurité.
• Faire confiance à User-Agent, Referer ou à un cookie côté client comme preuve d’identité.
• Appliquer un seuil global unique aux pages statiques, à la connexion, aux API et au paiement.
• Renvoyer des raisons d’échec détaillées qui aident un attaquant à ajuster la requête suivante.
• Traiter un CAPTCHA comme le contrôle principal au lieu d’utiliser une étape supplémentaire fondée sur le risque seulement lorsqu’elle est nécessaire.
• Conserver indéfiniment des empreintes brutes ou des données IP sans décision sur la confidentialité et la conservation.
• Ne mesurer que le volume de requêtes et ignorer les connexions réussies, commandes, erreurs, latence et consommation de ressources à l’origine.

Pour un plan de contrôle plus large, associez ce guide à Comprendre la limitation de débit, Protection des API à la périphérie et à la checklist des en-têtes de sécurité.

Références faisant autorité

• OWASP Automated Threats to Web Applications
• OWASP Bot Management and Anti-Automation Cheat Sheet
• Google crawler verification guidance

Il n’y a que deux choses difficiles en informatique : l’invalidation du cache et nommer les choses.