Social Rocket
Nous avions le Bot Fight Mode de Cloudflare activé. Un trafic suspect atteignait malgré tout le site.
D'après notre expérience d'exploitants, les challenges navigateur n'ont pas non plus été fiables. Il en allait de même pour une approche essayée auparavant, appelée « precursor ». Au final, ce qui a fait la différence n'était pas une fonction générique de plus contre les bots, mais une règle taillée précisément pour les schémas de requêtes réellement observés.
Nos agents IA ont isolé deux schémas de scraping distincts dans le trafic et les ont traduits en une stratégie de blocage Cloudflare ciblée. Les règles combinent les caractéristiques du navigateur, les métadonnées Fetch, les réseaux d'origine, les referrers, les pages d'entrée et le marquage des crawlers vérifiés par Cloudflare. Les requêtes correspondantes sont interrompues directement sur le edge avec HTTP 403.
Nous ne publions volontairement pas les empreintes complètes. Une règle anti-scraping n'est pas le bon endroit pour un changelog public destiné aux scrapers.
Ce qui a d'abord attiré notre attention
Le premier signal ne venait pas d'un événement de sécurité isolé, mais de la combinaison de plusieurs points de mesure.
Un instantané Minilytics montrait 544 sessions directes pour zéro conversion sortante mesurée. Entre deux heures complètes, les sessions directes sont passées de 24 à 163.
Parallèlement, Cloudflare a enregistré dans une fenêtre d'analyse de 30 minutes environ 17.700 requêtes HTTP, dont environ 15.400 ont atteint l'origine. Un extrait de cinq minutes de l'origine contenait 1.980 requêtes provenant de 1.238 adresses IP différentes.
Il est important de bien distinguer les grandeurs : une requête HTTP n'est pas une session. Et « zéro conversion » signifie dans ce contexte zéro événement sortant configuré déclenché – et non pas zéro vente ou zéro chiffre d'affaires avéré.
Nous disposions néanmoins de suffisamment de signal pour décomposer ce trafic plus finement.
Schéma 1 : le navigateur se disait Chrome – les métadonnées de requête ne correspondaient pas
Le premier groupe changeait massivement d'adresses IP et de pays. Les clients se présentaient comme des navigateurs Chrome sous Windows et alternaient entre plusieurs identités Chrome.
Dans l'extrait analysé, 1.628 requêtes provenant de 1.120 adresses IP dans 100 pays relevaient de ce schéma. Une part importante interrogeait en outre les données de pages Next.js.
Cela ne suffit pas à prouver qu'il s'agit d'un bot. Des requêtes RSC apparaissent aussi lors d'une navigation normale sur des pages Next.js.
La contradiction est devenue intéressante à un autre endroit : les requêtes prétendaient avoir l'identité d'un navigateur moderne, mais un marqueur Fetch Metadata que nous aurions attendu pour cette classe de requêtes manquait totalement.
Notre première nouvelle logique de blocage combine donc plusieurs conditions :
- Requête vers un hôte Srocket
- GET
- identité Chrome sous Windows correspondant au schéma observé
- en-tête Fetch Metadata absent
- pas de bot vérifié par Cloudflare
- pas de chemins internes Next.js ou d'API
Nous ne publions pas la liste précise des versions.
C'est la différence décisive avec une règle grossière du type « bloquer la version X de Chrome » : ce n'est pas une propriété isolée qui déclenche le blocage, mais la contradiction entre l'identité de navigateur annoncée et le contexte réel de la requête.
Cloudflare fournit avec `cf.client.bot` un champ qui signale les bons bots connus et les crawlers. Nous excluons ces crawlers vérifiés de la logique de blocage.
Schéma 2 : cette fois, la requête du navigateur semblait plausible
Peu après, un second schéma est apparu.
Ces requêtes avaient des en-têtes proches de ceux d'un navigateur et utilisaient aussi une valeur `Sec-Fetch-Site` normale. Elles ne tombaient donc pas sous la première empreinte.
Ici, le signal résidait dans la combinaison de l'origine, du profil de navigateur et de la page ciblée.
Nous observions des accès HTML directs depuis un pool rotatif de réseaux sources. Les requêtes n'utilisaient que quelques profils de navigateur exactement récurrents, arrivaient sans referrer et visaient spécifiquement un petit groupe de nos pages comparatives.
Ces réseaux sources changeants sont aussi la raison pour laquelle les adresses IP seules constituent une empreinte peu fiable. Pour mieux comprendre le côté technique, notre comparatif de proxys présente les différences entre les types de proxys courants et leurs fournisseurs.
Notre seconde logique de blocage combine donc :
- un pool source observé
- l'un des profils de navigateur exactement récurrents
- GET
- referrer vide
- un petit groupe défini de pages d'entrée concernées
- pas de bot vérifié par Cloudflare
Important : nous ne bloquons pas un ASN entier de façon générale, ni les visiteurs sans referrer en général. C'est seulement la combinaison des caractéristiques qui déclenche le blocage.
Les réseaux concrets, les user agents et les combinaisons de pages restent également en interne.
Pourquoi `Sec-Fetch-Site: none` n'est pas un signal de bot
Le second schéma montre bien pourquoi des en-têtes isolés peuvent être de très mauvais critères de blocage.
`Sec-Fetch-Site: none` est, selon MDN, un comportement de navigateur tout à fait normal, par exemple lorsqu'on saisit directement une URL dans la barre d'adresse ou ouvre un marque-page.
Une requête avec cette valeur n'est donc pas automatiquement suspecte.
C'est pourquoi nous ne bloquons ce groupe que lorsque le pool source, le profil de navigateur exact, un referrer vide et la page d'entrée concernée correspondent simultanément.
C'est plus restrictif qu'une règle bot générique – et c'est voulu.
L'IA n'a pas « détecté un bot » – elle a construit deux modèles de règles
La partie qui nous intéressait n'était pas qu'un modèle examine le trafic et dise « bot ».
L'IA n'est devenue utile que lorsque, à partir de nombreuses requêtes isolées, sont apparus deux schémas techniques distincts :
1. Contradiction d'identité : le profil du navigateur et les Fetch Metadata ne correspondent pas. 2. Empreinte de source : l'origine, le profil de navigateur, l'entrée directe et la page cible apparaissent régulièrement ensemble.
À partir de ces schémas, nos agents IA ont dérivé une stratégie Cloudflare que nous avons ensuite testée face à de vraies requêtes et à des accès de navigateur normaux.
C'est, pour nous, la forme d'IA la plus intéressante en exploitation : non pas un chatbot qui explique la sécurité, mais des agents qui traduisent une télémétrie réelle en règle de bord contrôlée.
Nous avons déjà décrit ailleurs pourquoi le trafic bot peut fausser l'attribution et le retargeting. Parallèlement, le débat actuel sur les obligations de transparence pour les crawlers IA montre à quel point il est devenu difficile d'attribuer proprement le trafic automatisé.
Pas de déploiement supplémentaire : la règle réside directement chez Cloudflare
La solution finale fonctionne comme une règle personnalisée Cloudflare existante avec l'action Block.
Nous n'avons pas eu besoin de déployer l'application ni de consommer un emplacement de règle supplémentaire. La règle existante de scanner/flood a été étendue avec les deux motifs supplémentaires.
La logique ne peut être résumée qu'au niveau du principe :
- Les scanners déjà confirmés restent bloqués.
- Le motif 1 ne s'applique que si l'identité du navigateur et les Fetch Metadata sont contradictoires de la manière observée, que la requête est un GET, qu'aucun bot vérifié n'est détecté et qu'aucun chemin interne de framework ou d'API n'est concerné.
- Le motif 2 ne s'applique que dans le cas de la combinaison d'un pool de sources observé, d'un profil de navigateur exactement récurrent, d'un accès direct sans referrer et d'une des pages d'entrée concernées.
- Ce n'est que lorsqu'une branche correspond entièrement que l'action Block est appliquée.
Nous ne publions pas les réseaux concrets, les versions de navigateurs, les user agents ni l'expression Cloudflare de production. Un scraper n'a pas besoin d'en savoir plus sur la règle.
Cloudflare recommande lui-même les Custom Rules lorsque plusieurs champs de requête doivent être combinés. Une action Block terminante s'applique alors déjà au niveau des Custom Rules et empêche les requêtes correspondantes de passer plus loin dans les mécanismes de bot en aval.
Ce qui s'est passé après l'activation
Nous n'avons pas seulement vérifié si Cloudflare acceptait la règle. Nous avons contrôlé si elle atteignait effectivement le motif voulu et si le trafic normal continuait de fonctionner.
Les tests de contrôle ont donné :
- Requête de test avec la première empreinte : Cloudflare 403
- même famille de navigateur avec des caractéristiques de navigation normales : 200
- page de comparaison publique en accès normal : 200
- événement réel issu du second motif : Custom rules / Block
- correspondances de règle affichées pendant le test : environ 1.300
L'évolution côté origin était particulièrement claire : pour le premier motif, les requêtes correspondantes de 626 sont tombées à zéro sur un intervalle complet d'une minute, dans le dernier intervalle de 18 secondes de l'extrait examiné.
Lors d'un contrôle Minilytics ultérieur, aucune nouvelle session directe sans conversion sortante n'est venue s'ajouter pendant 156 secondes.
Cela ne prouve pas que le trafic indésirable a disparu pour toujours. Mais cela montre que la nouvelle règle a effectivement intercepté les motifs observés au niveau de l'edge.
Pourquoi nous ne prétendons pas qu'il ne peut y avoir aucun faux positif
Nous avons testé la règle avec des accès normaux de type navigateur et l'avons délibérément restreinte.
Affirmer « garanti sans fausse alerte » serait malhonnête.
Un visiteur direct légitime pourrait en théorie également remplir plusieurs caractéristiques du second motif en même temps – par exemple depuis un réseau source concerné, avec l'un des profils de navigateur récurrents et sur une des pages concernées.
C'est pourquoi nous ne considérons pas cette règle comme une solution anti-bot universelle, mais comme une empreinte spécifique à l'incident, avec une possibilité de retrait documentée.
Il en va de même pour le premier schéma. Si les scrapers modifient leur identité de requête, une empreinte peut aussi perdre son efficacité.
L'avantage tient justement au fait que nous ne prétendons pas disposer d'une solution miracle permanente : nous pouvons observer, reclassifier et ajuster la règle edge de manière ciblée.
Ce que nous retenons de l'incident
Le mode Bot Fight n'était pas inutile. Mais une défense anti-bot générique n'a pas suffi à bloquer ces deux types de trafic chez nous.
Seule la combinaison de notre propre télémétrie, d'une analyse de schémas assistée par IA et d'une règle personnalisée Cloudflare précise a fait la différence.
Nos empreintes concrètes ne sont pas transférables à d'autres sites. La méthode, en revanche, l'est :
Ne pas traquer les adresses IP. Ne pas bloquer isolément des en-têtes. Combiner plusieurs caractéristiques indépendantes de la requête, exclure les crawlers vérifiés, tester les accès de navigateurs normaux, puis mesurer l'effet.
C'est ainsi que nos agents IA ont transformé un problème de trafic en une règle edge vérifiable, sans fournir aux scrapers un mode d'emploi universel.