Cloudflare contourné par un outil open-source : repenser sa protection anti-bot

Depuis le 1er juillet 2025, Cloudflare bloque par défaut les robots d'intelligence artificielle sur tout nouveau domaine qu'elle protège, et a depuis refusé des centaines de milliards de requêtes de bots. Le 10 juillet 2026, un développeur a publié Fortress, un navigateur furtif open-source qui passe au travers de cette protection sur cinq des huit sites de son benchmark, sans toucher une ligne de code du site ciblé. Si un outil gratuit et public y parvient, la vraie question n'est plus de savoir si Cloudflare seul suffit à protéger votre site, mais sur quoi repose réellement votre défense anti-bot.

Le contexte : un mur JavaScript par défaut depuis 2025

Pour rappel, la protection anti-bot de Cloudflare, comme celles de PerimeterX, DataDome ou Akamai, repose largement sur le fingerprinting : elle observe la façon dont un navigateur s'exécute (moteur JavaScript, empreinte TLS, en-têtes, comportement de rendu) pour distinguer un humain d'un script automatisé. Une requête jugée suspecte reçoit une page d'interstitiel du type « Just a moment », un défi à résoudre avant d'accéder au contenu réel. C'est efficace contre un simple curl ou un fetch() basique. Ça l'est beaucoup moins contre un navigateur qui imite fidèlement un vrai Chrome de bureau.

Le benchmark : cinq sites sur huit passés à travers le mur

L'auteur de l'outil a testé huit sites, un par grand vendeur de protection anti-bot, de trois façons : une requête naïve (curl avec un user-agent Chrome standard), Fortress (le navigateur furtif open-source), et Tilion Cloud (la couche hébergée payante construite par-dessus). Résultat de la requête naïve : du contenu réel obtenu zéro fois sur huit, une page interstitielle « résumable » huit fois sur huit, et un signal d'échec exploitable par un agent zéro fois sur huit. Un script ou un agent IA qui interroge ces sites sans protection dédiée ne sait même pas qu'il a été bloqué : il reçoit une réponse HTTP avec un corps HTML complet, qu'il traite comme du contenu légitime.

Fortress, la version open-source, passe cinq de ces huit sites : Indeed, Zillow, Walmart, StockX et Booking. Sur Indeed, il récupère de vraies offres d'emploi avec intitulé, entreprise et fourchette de salaire, là où la requête naïve ne renvoie que 27 Ko de texte « Enable JavaScript and cookies to continue ». Sur Zillow, il obtient 878 annonces immobilières réelles avec prix, surface et agent, contre un 403 brut en requête naïve. Sur StockX, l'outil ne se contente pas de parser le HTML : il observe le trafic réseau de la page et intercepte directement l'appel à l'API GraphQL interne du site, ce qui donne des données structurées plus fiables qu'un scraping de page.

Ce qui reste hors de portée, et pourquoi

Trois cibles résistent à la version gratuite : Etsy et G2, protégés par DataDome, et Amazon, derrière un mur nécessitant un clic explicite avant d'afficher la fiche produit. DataDome ferme la porte avant même que l'application ne charge : il n'y a donc littéralement aucun appel réseau à intercepter. Ce sont ces trois cas que l'offre payante Tilion Cloud, avec des profils de navigateur persistants et une empreinte TLS calquée sur un vrai Chrome, annonce couvrir intégralement.

Comment ça marche techniquement

Techniquement, l'outil expose une fonction qui renvoie un indicateur explicite plutôt qu'un corps de page à interpréter à l'aveugle :

fortress.fetch_protected_page("https://www.zillow.com/homes/for_sale/San-Francisco_rb/")
# { blocked: False, title: "San Francisco CA Homes For Sale", text: "878 annonces..." }

fortress.fetch_protected_page("https://www.g2.com/products/notion/reviews")
# { blocked: True, text: "" }

Il s'installe avec pip install "tilion[mcp]" et s'expose comme serveur MCP (tilion-mcp), branchable directement dans Claude Desktop, Cursor, Cline ou Windsurf via un fichier de configuration mcpServers standard. Le dépôt est public sur GitHub.

Ce que ça change pour la protection de votre site

Pour une PME française qui expose des données de valeur derrière Cloudflare (catalogue produit, grille tarifaire, offres d'emploi, avis clients), ce constat a une conséquence directe : le défi JavaScript seul ne suffit plus à faire barrage à un scraping déterminé. Ce qui protège réellement, ce sont les couches qui ne dépendent pas du fingerprinting du navigateur :

• Limiter le débit côté serveur, par IP et par compte, sur les endpoints qui exposent la donnée sensible (recherche, API de pricing, listing), pas uniquement au niveau du CDN.
• Surveiller les anomalies de comportement applicatif. Un compte qui consulte des centaines de fiches produit en quelques minutes n'a pas le même profil qu'un visiteur humain, indépendamment de son fingerprint navigateur.
• Exiger une authentification ou une clé d'API pour les jeux de données à forte valeur, plutôt que de les laisser accessibles en lecture libre derrière un simple mur JavaScript.
• Ajouter des vérifications de cohérence côté serveur (délai entre chargement de page et soumission, ordre logique des requêtes) qu'un navigateur furtif, même fidèle, ne peut pas deviner.
• Journaliser et alerter sur les pics de trafic inhabituels, pour détecter une campagne de scraping même quand elle passe le mur anti-bot.

Aucune de ces mesures ne remplace Cloudflare : elles s'y ajoutent, en acceptant qu'un attaquant motivé finira presque toujours par passer la première ligne de défense.

Notre lecture chez CZSyn

Nous voyons régulièrement des clients traiter la protection anti-bot de leur CDN comme une case cochée une fois pour toutes. Ce cas montre l'inverse : un outil gratuit, documenté publiquement sur GitHub, suffit aujourd'hui à contourner plusieurs des plus grands vendeurs du marché sur au moins une partie de leur catalogue de sites. Ce n'est pas une faille exotique réservée aux grands comptes, c'est un outil qu'un développeur installe en une seule commande.

Notre recommandation concrète : si votre activité repose sur des données exposées publiquement (tarifs, stock, avis, offres), auditez ce qui se passe réellement quand quelqu'un contourne votre défi JavaScript. Le bon réflexe n'est pas d'empiler les couches de fingerprinting, c'est de construire une défense qui tient même quand le fingerprinting échoue : rate limiting côté serveur, authentification sur les endpoints sensibles, alerting sur l'anormal. C'est le type d'audit que nous menons chez nos clients avant de toucher au moindre code.

Sources primaires

• Tilion, « Cloudflare blocks AI agents by default », 10 juillet 2026.
• Dépôt officiel du projet, github.com/tiliondev/fortress.
• Cloudflare, documentation officielle, « Bot Management ».