En bref : Le 15 septembre 2026, Cloudflare a annoncé Disallow AI Training et de nouveaux paramètres recommandés qui séparent le trafic Search, Training et Agent. Cette mise à jour s'ajoute à Precursor (détection comportementale au niveau de la session, déployée en juillet) et à la pile habituelle Managed Challenges / Turnstile. Si vos scrapes ou monitors ont calé ce mois-ci, vous ne rêvez pas.
Est-ce que le job finit quand même ? C'est la seule question qui compte pour la plupart des équipes data. Piloterr fait déjà tourner ce type de collecte via WebUnlocker et les autres produits website.
Ce que Cloudflare a vraiment livré en septembre
L'annonce datée, c'est la mise à jour 15 septembre Bot Management / AI Crawl Control, détaillée dans le billet de blog Cloudflare et le communiqué de presse.
Ce qu'ils ont publié :
- Un nouveau réglage Disallow AI Training pour refuser l'entraînement tout en restant dans la recherche (pour les crawlers que Cloudflare classe Accountable).
- Un sens plus clair pour Block et Block on pages with ads : ces actions s'appliquent aussi aux crawlers mixtes comme Googlebot, Bingbot et Applebot. Si vous voulez seulement couper l'entraînement et garder la recherche, utilisez Disallow AI Training plutôt que Block.
- Dépréciation du gros interrupteur Block AI Bots au profit de contrôles séparés Search, Training et Agent.
- Bot Preference Sync qui remplace Managed Robots.txt.
- Pour les nouveaux domaines onboardés à partir de cette date, des presets recommandés sur les sites monétisés par la pub : Search autorisé, Training en Disallow AI Training, Agents bloqués sur les pages avec pubs. Le changelog de juillet avait déjà annoncé ces défauts.
Les zones existantes ont été migrées selon leurs réglages précédents. Beaucoup d'opérateurs ont quand même basculé des options à la main après le buzz médiatique. Dans les deux cas, davantage de domaines classent désormais les fetchers de chat, les agents navigateur et les crawlers style entraînement comme indésirables par défaut.
C'est un vrai changement produit. À part ça, ce que beaucoup de collecteurs voient dans le navigateur, c'est l'ancienne pile de challenges qui se durcit en pratique parce que plus de zones activent les fonctionnalités.
Pourquoi des jobs qui passaient maintenant échouent
Le changelog Cloudflare et la doc Precursor décrivent un basculement commencé plus tôt dans l'été et qui continue de se déployer chez les clients : détection sur toute la session, pas un seul portail à l'entrée.
Precursor injecte du JavaScript côté client, collecte des signaux comportementaux dans le temps, et met à jour l'état de session dans le cookie cf_clearance. Cloudflare indique que le clearance peut être réduit ou invalidé en cours de session, et que des challenges supplémentaires peuvent partir après qu'un visiteur a déjà « passé » une fois. Un refresh de page n'efface pas cette signature de session comme le faisait un CAPTCHA one-shot.
Résultat : un monitor qui a l'air humain sur le premier fetch HTML peut encore se faire challenger au troisième hop de pagination. Un scraper de prix qui passe un interstitial puis enchaîne les URLs produit en boucle serrée se met à ressembler à du trafic Agent sous la nouvelle taxonomie Search / Training / Agent.
Rien de tout ça n'exige d'être un crawler IA nommé. Les éditeurs basculent les contrôles Agent et Training parce qu'ils ont vu les défauts de septembre. Votre job d'enrichissement B2B légitime tombe dans le même seau automatisé, sauf si l'éditeur a prévu une exception.
« Le HTTP a l'air bon » mais vous n'êtes pas sur la vraie page
C'est là que les pipelines se taisent pour la mauvaise raison.
Cloudflare documente qu'une Challenge Page interstitial complète pose l'en-tête de réponse cf-mitigated: challenge, sert content-type: text/html, et (pour Managed Challenge / Under Attack Mode) renvoie un 403 avec du HTML de challenge plutôt que votre payload produit. Voir Detect a Challenge Page response et les types de pages d'erreur.
Sur le terrain, les équipes disent encore « HTTP 200 mais coincé sur un challenge ». Souvent, elles parlent d'un échec plus soft que l'interstitial documenté.
Certains collecteurs ne regardent que les codes de statut et traitent n'importe quel corps HTML comme un succès. Un HTML de challenge reste du HTML. Si votre check est status < 400, vous pouvez stocker « Checking your browser… » comme un prix.
Les JavaScript Detections et Precursor, c'est encore autre chose : Cloudflare les injecte dans les réponses HTML sans figer le visiteur comme un interstitial. Vous obtenez un 200 qui a l'air vrai pendant que le edge continue de scorer la session, puis déclenche un challenge plus tard ou fait chuter le bot score. Un Turnstile embarqué sur un formulaire qui a déjà renvoyé 200 se comporte pareil du point de vue opérateur. La page charge. L'action protégée ne finit pas tant que le widget n'est pas validé.
Les Managed Challenges restent adaptatifs. Beaucoup d'humains voient une courte attente non interactive ; le trafic qui a l'air automatisé se fait demander une interaction. Ce comportement est dans la doc Challenge Pages, pas dans une note de version exclusive à septembre. Septembre a surtout poussé plus de politiques vers le trafic Agent et Training. La machinerie de challenge, c'est ce que ces politiques appellent.
Ce que les opérateurs doivent anticiper jusqu'à l'automne
Toutes les zones n'ont pas basculé le même jour. Malgré tout, si vous lancez des collecteurs contre des propriétés Cloudflare, prévoyez plus de Managed Challenges interactifs quand l'empreinte et le comportement dévient, et un clearance qui ne dure pas tout le job une fois Precursor en Maximize Security ou dès que la session dérive.
Les échecs soft restent fréquents : des réponses qui ont l'air réussies jusqu'à ce que vous regardiez cf-mitigated, la longueur du corps, ou la présence réelle des champs à extraire. Les sites monétisés par la pub qui ont pris les nouveaux presets d'onboarding traiteront davantage de trafic Agent (au sens Cloudflare) comme indésirable. Les stacks maison qui « avaient résolu Cloudflare » en 2024 ou début 2025 ont souvent besoin d'un nouveau cycle de maintenance. Le scoring de session et les défauts Agent changent le mode d'échec plus vite que les seuls tweaks de fingerprint TLS ne peuvent le rattraper.
Si vous possédez les collecteurs, budgétez des retries qui renvoient encore du HTML de challenge, et une validation qui regarde le contenu plutôt que le seul statut.
Si le pipeline coince sur Cloudflare
La plupart des équipes avec qui on parle veulent les données, pas un second projet anti-bot à temps plein. Piloterr fait déjà tourner des collecteurs contre des cibles protégées par Cloudflare via Website WebUnlocker (domaines allowlistés, mode HTTP) et Website Rendering quand la page elle-même a besoin d'un vrai navigateur. Pour choisir l'outil : Crawler vs Rendering vs WebUnlocker.
Les changements Cloudflare de septembre sont réels. Absorber ce genre de bascule vendeur, c'est une partie de notre job pour que votre roadmap produit n'ait pas à le faire.
Besoin de faire passer un domaine en revue après les defaults de mi-septembre ? Commencez par Website Rendering quand la page demande un vrai navigateur, ou par la doc API WebUnlocker pour les cibles HTTP allowlistées. Ouvrez une conversation depuis le site si vous voulez qu'on dise si la cible est dans le scope et quel taux de succès attendre.
