Cloudflare Bot Management en production : guide de configuration

Tout le monde sait activer Bot Management. Peu d'équipes savent le régler.

Sur les zones Cloudflare que nous reprenons en production, le constat est presque toujours le même : la fonctionnalité est en route, le tableau de bord est vert, le seuil est resté au niveau initial. Et personne n'a regardé depuis. D'après Cloudflare Radar, près d'un tiers des requêtes Internet sont automatisées. La proportion exacte change d'une zone à l'autre, mais l'enjeu reste le même : votre politique de filtrage se trompe sur un tiers du trafic.

Six mois après l'activation, trois symptômes apparaissent en même temps. Du trafic mobile légitime se fait défier. Les robots de récupération automatisée (scraping) figurent toujours dans les journaux. Et les attaquants ont migré vers les endpoints (points d'entrée API) que personne ne surveille.

Ce guide reprend la méthode que nous appliquons chez Brixio, Authorized Cloudflare Service Delivery Partner (ASDP), sur les zones que nous opérons. Il décrit ce que font les paramètres natifs, où ils décrochent, et comment durcir Bot Management sans pénaliser vos utilisateurs. Toutes les règles citées renvoient à la documentation Cloudflare à jour en mai 2026.

Les paramètres natifs : un point de départ, pas une cible

Les réglages par défaut de Bot Management sont volontairement prudents. Ils couvrent l'ensemble d'un domaine avec des règles larges, calibrées pour éviter tout faux positif. Cette prudence se justifie le jour de l'activation. Elle devient un plafond dès la semaine suivante.

Trois limites se voient rapidement en production.

Premier point. Les paramètres natifs appliquent le même seuil à toutes les pages. La page de connexion, où se concentre le credential stuffing (bourrage d'identifiants), reçoit le même filtrage que la page marketing publique. Le risque n'est pourtant pas le même.

Deuxième point. Bot Management produit un score par requête de 1 à 99, mais les actions natives ne portent que sur deux catégories : « definitely automated » (score 1) et « likely automated » (scores 2 à 29). Tout ce qui se trouve entre 30 et 99 passe pour humain. La zone intéressante, celle où se loge l'essentiel des bots évolués, se situe entre 30 et 50. Les paramètres natifs n'agissent pas dans cette zone.

Troisième point. Ils ne combinent pas les signaux. Un score de 25 venant de l'empreinte d'une application mobile reconnue n'a pas la même portée qu'un score de 25 venant d'un ASN inconnu hors de votre zone géographique. Cette distinction passe par des règles sur mesure.

Les attaquants connaissent ces limites. Dès que le front web est durci par Bot Management et un WAF (Web Application Firewall, pare-feu applicatif), ils basculent sur les canaux restés au défaut. L'API mobile est leur cible privilégiée, parce que le défi CAPTCHA côté client n'y tourne pas.

Bot Management ne vaut que par les règles sur mesure qu'on lui ajoute.

Trois produits Bot chez Cloudflare, plus Bot Shield

Cloudflare propose trois produits Bot natifs. Brixio ajoute une quatrième couche, Bot Shield, pour traiter l'angle mort qu'aucun des trois ne couvre par nature.

• Bot Fight Mode (Free) : pas de score par requête, pas de règles personnalisées, pas de JS Detections, pas d'empreintes JA3/JA4, pas de detection IDs, pas de contrôle bots IA.
• Super Bot Fight Mode (Pro, Business, Enterprise sans add-on) : pas de score, action Skip uniquement, pas de JS Detections, pas d'empreintes, pas de detection IDs, contrôles IA partiels.
• Bot Management for Enterprise (add-on) : score 1-99 complet, règles personnalisées complètes, JS Detections, empreintes JA3/JA4, detection IDs, contrôles IA complets.
• Bot Shield by Brixio (couche additionnelle) : signaux dédiés, règles personnalisées, réputation d'empreintes JA3/JA4.

Bot Fight Mode et Super Bot Fight Mode s'appuient sur le même moteur de détection que Bot Management Enterprise, mais ne donnent accès qu'à des interrupteurs au niveau du domaine. Pour un site vitrine, c'est suffisant. Pour l'e-commerce, la banque, les paiements, ou toute application où le coût d'un bot non détecté dépasse le prix de l'add-on Enterprise, ce n'est pas assez.

Le contrôle granulaire, le scoring par requête et la capacité à écrire des règles sur un endpoint précis n'existent qu'avec Bot Management for Enterprise. L'activation passe par votre interlocuteur Cloudflare. Le comparatif officiel des plans détaille la matrice complète.

Bot Shield by Brixio est la couche supplémentaire que nous posons au-dessus. C'est un produit de détection propriétaire, conçu pour compléter Cloudflare Bot Management, le WAF, API Shield et Turnstile. Il vise les canaux où les défenses Cloudflare sont aveugles par nature : les API natives mobiles, où le CAPTCHA ne s'exécute pas et où les attaquants concentrent leurs efforts une fois le canal web verrouillé. Bot Shield repose sur la réputation des empreintes JA3/JA4 comme signal principal, se déploie en mode LOG (journalisation sans application) avant toute mise en application, et fournit un tableau de bord par route d'API. Nous l'utilisons sur les zones où Bot Management seul laisse une exposition résiduelle. Un cas réel est décrit plus loin.

Que signifie le score de bot Cloudflare ?

Cloudflare attribue à chaque requête un score cf.bot_management.score entre 1 et 99. Un score de 1 correspond à une requête certainement automatisée. Un score de 99 à un comportement humain. C'est entre 30 et 50 que se joue l'essentiel de l'affinage.

Toute requête qui traverse une zone avec Bot Management activé reçoit ce score sur le champ cf.bot_management.score, un entier de 1 à 99. Plus le score est bas, plus le comportement est automatisé.

Cloudflare publie deux regroupements officiels :

• Score 1 : certainement automatisé. Le niveau de certitude est suffisant pour bloquer sans risque significatif de faux positif.
• Scores 2 à 29 : probablement automatisé. L'action recommandée est le Managed Challenge, qui laisse passer un humain derrière VPN ou Tor tout en stoppant les navigateurs sans interface (headless).
• Scores 30 à 99 : considérés comme humains par défaut. En pratique, la bande d'affinage utile se situe entre 30 et 50.

Le seuil de 30 est un point de départ, pas une règle universelle. Une page de connexion peut justifier un seuil plus strict, autour de 40. Un endpoint de recherche, qui sert du trafic anonyme par nature, peut très bien vivre à 20. La bonne méthode consiste à déployer les règles en action Log d'abord, observer pendant sept à quatorze jours, puis basculer en Block ou Managed Challenge une fois la distribution stabilisée. La documentation Cloudflare formule la même recommandation : démarrer bas, durcir au fil du temps.

Quelles règles personnalisées poser dans toute zone en production ?

Dans l'ordre : exempter les bots vérifiés, bloquer le score 1, défier les scores 2 à 29. Au-dessus de cette base, le reste se règle endpoint par endpoint.

Tous les déploiements Bot Management que nous opérons reposent sur les trois mêmes règles de base, dans cet ordre. Elles viennent des recommandations Cloudflare et de ce que nous avons consolidé sur nos zones.

Règle 1 : exempter les bots vérifiés

Expression : (cf.bot_management.verified_bot)
Action     : Skip → toutes les règles personnalisées suivantes

La liste des bots vérifiés est l'allowlist tenue par Cloudflare pour Googlebot, Bingbot, Pingdom, Datadog, les agents de monitoring et les autres automatisations légitimes. Les exempter empêche le reste du jeu de règles de défier du trafic qu'on souhaite justement laisser passer.

Un piège fréquent : tous les scanners internes légitimes ne sont pas dans cette liste. Un job d'intégration continue qui tape sur une pré-production, un scanner de vulnérabilités imposé par un audit PCI-DSS, ou une intégration partenaire qui interroge un flux d'inventaire vont ressembler à des bots et être scorés comme tels. À ajouter explicitement en allowlist par plage d'IP ou empreinte JA3/JA4 avant la règle 2.

Règle 2 : bloquer le trafic certainement automatisé

Expression : (cf.bot_management.score eq 1)
Action     : Block

Le score 1 est la catégorie la plus nette de Bot Management. Le niveau de certitude justifie un blocage dur. Sur nos zones, le taux de faux positifs observé sur cette règle reste sous 0,05 %.

Règle 3 : défier le trafic probablement automatisé

Expression : (cf.bot_management.score gt 1 and cf.bot_management.score lt 30)
Action     : Managed Challenge

Sur cette bande, le Managed Challenge vaut mieux que le blocage, parce que la population concernée inclut une longue traîne d'humains derrière proxys de confidentialité, VPN résidentiels et nœuds de sortie partagés. Le Managed Challenge de Cloudflare émet d'abord une vérification non interactive et ne bascule sur un défi interactif que si nécessaire.

Avec ces trois règles, la base est posée. Elle stoppe l'automatisation évidente sans pénaliser le trafic légitime. Tout ce qui suit est de l'affinage.

Comment affiner Bot Management par endpoint ?

Pages navigateur, API, endpoints de connexion, trafic mobile applicatif : quatre canaux, quatre lectures différentes d'un même score.

Pages navigateur

Pour les pages servies en HTML, activez les JavaScript Detections. Cloudflare injecte un snippet JavaScript invisible qui pose un cookie cf_clearance après vérification. Le résultat est exposé sur le champ cf.bot_management.js_detection.passed. Ajoutez une règle qui défie ou bloque les requêtes pour lesquelles ce champ est faux. À combiner avec les règles de base.

API

Une API ne doit jamais reposer uniquement sur le scoring de bot. La première ligne de défense est l'authentification : jetons signés (JSON Web Tokens), clés API validées au niveau du réseau de bord, ou mTLS (mutual TLS, authentification mutuelle au niveau du transport) sur les API internes. Ensuite, des règles personnalisées bloquent toute requête vers un chemin d'API versionné sans l'en-tête d'authentification attendu. La limitation de débit ferme la marche (abordée plus bas).

Une règle typique sur la surface API en production :

(starts_with(http.request.uri.path, "/api/")
 and not any(http.request.headers["x-api-key"][*] in {"<hashes-cles-valides>"})
 and not cf.bot_management.verified_bot)
Action : Block

Endpoints de connexion

La page de connexion est la surface la plus exposée d'un environnement en production. Le credential stuffing, les password sprays (attaque par dispersion de mots de passe) et les campagnes de takeover de compte y convergent. Resserrez le seuil à 30 ou 40, et combinez le score de bot avec la détection d'identifiants compromis si votre plan la propose.

Exemple de règle pour une connexion strictement protégée :

(http.request.uri.path eq "/login"
 and cf.bot_management.score lt 40
 and not cf.bot_management.verified_bot)
Action : Block

Sur les zones qui s'authentifient via un fournisseur d'identité fédérée (SSO), appliquez la même logique au chemin de callback SSO.

Trafic mobile

C'est sur le mobile que Bot Shield prend tout son sens. Les appels d'API natifs ne rendent pas de JavaScript, n'affichent pas de CAPTCHA, et arrivent à l'origine depuis des plages CGN (Carrier-Grade NAT) qui partagent une IP entre des milliers d'appareils. Avec les réglages par défaut, des utilisateurs légitimes se font défier.

Deux approches tiennent la route :

1. Inscrire l'empreinte JA3/JA4 de l'application officielle en liste de confiance. Capturez l'empreinte depuis la build de release, validez-la sur plusieurs versions récentes, et exemptez les règles bot pour les requêtes qui correspondent.
2. Différencier par user agent. Si vous contrôlez l'application, embarquez un user agent personnalisé et écrivez des seuils en fonction : plus stricts qu'un navigateur, plus larges qu'un client anonyme.

Quand ni l'une ni l'autre ne suffit, on superpose Bot Shield. C'est ce que nous avons fait sur le cas décrit plus bas.

Construire une allowlist qui ne se retournera pas contre vous

L'incident le plus courant en production sur Bot Management vient d'une liste de bots vérifiés que personne n'a tenue à jour. Un nouvel outil de monitoring est déployé, une nouvelle intégration partenaire passe en production, une nouvelle région ouvre avec un nouveau CDN, et le jeu de règles cesse d'être à jour.

Quatre méthodes d'allowlist, de la plus difficile à falsifier à la plus simple :

1. Signed agents, récemment introduits par Cloudflare. Identité signée cryptographiquement, liée à un opérateur identifié.
2. Correspondance d'empreinte JA3/JA4. L'autorisation est ancrée sur une signature du handshake TLS, beaucoup plus difficile à falsifier qu'une IP ou un user agent.
3. Plage d'IP en allowlist. Utile pour les partenaires avec une sortie statique.
4. Correspondance de chaîne user agent. La plus faible, parce qu'un user agent se falsifie en une ligne de code. À n'utiliser qu'en combinaison avec une des méthodes précédentes.

Chaque entrée d'allowlist doit avoir un propriétaire et une durée de vie attendue. La liste est à la fois un actif et un passif de sécurité.

Comment Bot Management se combine avec le WAF et la limitation de débit ?

Cloudflare évalue les règles dans un ordre fixe : Custom Rules d'abord, puis Bot Management, puis Managed Rules, puis Rate Limiting. Mal lire cet ordre est la première raison pour laquelle une règle personnalisée semble ne pas se déclencher.

L'ordre simplifié sur une zone en production avec Bot Management Enterprise :

1. WAF Custom Rules (vos règles personnalisées)
2. Super Bot Fight Mode (ignoré si Bot Management Enterprise est actif)
3. WAF Managed Rules et OWASP Core Ruleset
4. Rate Limiting Rules
5. Cache et origine

Une règle personnalisée avec action Skip à l'étape 1 court-circuite tout ce qui suit. Utile pour les bots vérifiés et les partenaires. Risqué si elle est posée trop largement.

Les combinaisons que nous déployons le plus souvent :

• Connexion plus limitation de débit : score de bot inférieur à 40, plus 5 requêtes par minute par IP, plus vérification d'identifiants compromis.
• Recherche plus score de bot plus limitation de débit : score de bot inférieur à 20, plus 60 requêtes par minute par cookie de session sur l'endpoint de recherche.
• Paiement plus navigateur strict : score de bot inférieur à 30, plus JavaScript Detections valide, plus limitation de débit par session.

Pour aller plus loin sur les volets WAF et limitation de débit, consultez la documentation officielle Cloudflare WAF et la référence des Rate Limiting rules.

Si vous préférez une approche packagée et managée, le bot management est l’un des piliers de notre service WAAP managé, aux côtés du WAF, de la protection des API et de l’anti-DDoS.

Bots IA : la couche 2025 à ne pas ignorer

Les crawlers d'IA générative sont passés du sujet de production en 2024 à la question de comité de direction en 2025. Cloudflare expose désormais trois contrôles à activer sur tout site de contenu ou surface applicative où la propriété intellectuelle compte.

• Block AI bots, paramètre managed. Bloque les principaux crawlers IA, dont Amazonbot, Applebot, Bytespider, ClaudeBot, GPTBot, Meta-ExternalAgent, PetalBot et CCBot. Deux modes : bloquer sur toutes les pages, ou bloquer uniquement sur les hostnames qui servent de la publicité.
• AI Labyrinth. Honeypot invisible de liens nofollow qui piège les crawlers IA qui ignorent robots.txt. Leurs empreintes sont ensuite partagées sur le réseau Cloudflare.
• AI Crawl Control, livré en octobre 2025. Autorisation ou blocage granulaire par crawler, avec analytics et un onglet Robots.txt qui trace les violations de directives. C'est là qu'on gère la politique IA à l'échelle.

Base défendable : activer le robots.txt managed (couche de signal), activer Block AI bots dans les paramètres de sécurité (couche d'application), et utiliser AI Crawl Control pour les exceptions par crawler.

Que faut-il surveiller chaque semaine ?

La distribution Bot Analytics, les déclenchements de Security Events, les champs Logpush exportés vers votre SIEM, et le backlog de faux positifs. Sans observation hebdomadaire, les jeux de règles dérivent.

Bot Management sans monitoring dérive. Les patterns d'attaque changent en quelques semaines, et une règle qui se déclenchait le trimestre précédent peut être silencieuse aujourd'hui sans qu'on s'en aperçoive. Notre revue hebdomadaire couvre quatre artefacts.

• Tableau de bord Bot Analytics : distribution des scores, top bots vérifiés, top detection IDs. Les anomalies y sont un indicateur précoce d'une campagne qui démarre.
• Journal Security Events : confirme que les règles personnalisées correspondent au trafic pour lequel elles ont été écrites. Une règle qui ne s'est pas déclenchée depuis deux semaines est soit mal configurée, soit obsolète.
• Flux Logpush, pour les zones avec journalisation activée. Exporter BotScore, BotScoreSrc, JA3Hash, JSDetectionPassed et LeakedCredentialCheckResult vers votre SIEM (Security Information and Event Management, plateforme de gestion des journaux et événements de sécurité).
• Backlog des faux positifs : une file de tickets, pas une métrique. Quand des utilisateurs se font défier alors qu'ils ne devraient pas, le jeu de règles est trop strict et la confiance s'érode.

L'objectif opérationnel sur les zones managées : taux de faux positifs sous 0,1 %, trafic certainement automatisé bloqué au-dessus de 95 %, et liste d'exceptions documentée revue chaque mois.

En pratique : Bot Shield sur une compagnie aérienne de taille moyenne

L'API native mobile d'une compagnie aérienne internationale de taille moyenne, anonymisée à la demande du client, était devenue le nouveau terrain d'affrontement après durcissement du canal web par WAF et Super Bot Fight Mode. Le pattern dans les journaux était précis : des bots exécutaient des parcours de réservation partiels sur les API iOS et Android. Ils cherchaient, posaient une option temporaire sur des sièges, et abandonnaient avant le paiement. Chaque option temporaire déclenchait le moteur de yield management qui faisait monter les tarifs, ce qui pénalisait les vrais clients sur la même classe tarifaire.

Les défenses Cloudflare côté web ne voyaient rien de tout ça. Le CAPTCHA ne tourne pas sur une API mobile native.

L'équipe Brixio a déployé Bot Shield en complément de Bot Management. Démarche retenue :

• Pilote de quatre semaines en mode LOG, observation pure, zéro application, zéro impact trafic.
• Quatorze signaux de détection sur mesure, affinés par route d'API : search, tempBooking, passenger, payment. Chaque route a reçu son propre profil de scoring, parce que le comportement légitime y était distinct.
• Réputation d'empreinte JA3/JA4 comme signal principal, évaluée contre des bases de trafic légitime iOS et Android capturées pendant le pilote.
• Tolérance ajustée au canal d'origine sur la base d'utilisateurs du marché domestique, pour éviter les faux positifs sur les zones géographiques où la compagnie réalise l'essentiel de son chiffre.
• Mise en application progressive, après revue par les parties prenantes et validation des métriques route par route.

Résultats observés une fois l'application active :

• Zéro faux positif sur la phase d'application.
• Coût d'infrastructure tenu sur l'offre gratuite Cloudflare : Bot Shield tourne sur des Workers standards et les champs Bot Management, sans passage à l'offre Enterprise pour ce déploiement.
• Familles de bots identifiées et documentées par session : signaux, empreintes, ASN, pays, chemin de requête, accessibles à l'équipe protection des revenus.
• Tableau de bord remis à l'opérationnel comme outil continu, dans le cadre d'un engagement de services managés Brixio.

Et après

Bot Management est une base solide. Ce n'est pas une configuration finie. Un déploiement qui dure n'a rien de particulier sauf le travail qui vient après l'activation : affinage par endpoint, superposition de signaux, observation continue, et la rigueur de rafraîchir le jeu de règles à mesure que la surface d'attaque bouge.

Brixio opère des zones Cloudflare en production en Europe, dans le Golfe et en Asie-Pacifique. En tant qu'Authorized Cloudflare Service Delivery Partner, avec une couverture Follow-the-Sun depuis Luxembourg, Paris, Dubai et Singapour, nous traitons Bot Management comme une opération continue, pas comme un projet ponctuel. Cet affinage, ce sont nos experts Cloudflare certifiés qui le font au quotidien, sur des dizaines de zones en production.

Pour un diagnostic en lecture seule de votre configuration Cloudflare actuelle, le rapport est livré en cinq minutes.

Lancer un audit Cloudflare gratuit →