Le 13 juillet 2026, Cloudflare a commencé à déployer pour tous les clients Precursor — un moteur client qui évalue non pas une demande individuelle ou le passage d'un captcha, mais le comportement au sein de toute la session. La formulation du CTO de Cloudflare, Dane Knecht, est courte et précise : «Au lieu de simplement vérifier une ID à l'entrée, nous examinons le comportement pendant toute la visite».
Pour ceux qui automatisent le navigateur — scrapers, multi-comptes, automatisation SMM, agents IA — c'est un changement d'unité de mesure du risque. Auparavant, l'unité était la demande : vous avez passé le défi, obtenu cf_clearance, vous travaillez. Maintenant, l'unité est la session, et elle vit, accumule une évaluation et peut «se détériorer» à tout moment après que vous ayez déjà passé la vérification.
Qu'est-ce que Cloudflare a lancé exactement
Precursor est un script que Cloudflare intègre dans les pages via son réseau. Il s'active par un interrupteur dans le panneau (Sécurité → Paramètres → Precursor), ne nécessite pas de modifications dans le code du site, fonctionne sur toute la zone à la fois ; le comportement est ajusté de manière ciblée via les Règles de Precursor. Il est positionné non pas comme un remplacement de Turnstile, mais comme un complément : Turnstile est une vérification ponctuelle, Precursor est continue.
Ce que le script collecte, selon la description de Cloudflare :
- mouvement du pointeur — trajectoires, vitesse, nature des courbes ;
- rythme de défilement ;
- cadence de frappe — temps et rythme, mais pas les touches enfoncées elles-mêmes ;
- activité du presse-papiers ;
- changement de focus des éléments et visibilité de la page/onglet.
Ensuite, cela devient intéressant. Cloudflare décrit clairement qu'il recherche dans ces données non pas une «empreinte», mais la physique et la physiologie humaine : les courbes de mouvement de la souris, limitées par la rotation du poignet, au lieu de mouvements linéaires d'automatisation ; des délais cognitifs mesurables entre l'apparition d'un stimulus à l'écran et la réaction ; des micro-vibrations de la main — tremblement — comme bruit naturel dans la trajectoire.
Le deuxième niveau — vérifications croisées des contradictions internes. Le pointeur se déplace-t-il alors que la page est cachée ? Des événements de clavier arrivent, mais aucun champ de texte n'est en focus ? Chaque signal pris séparément semble normal, mais ensemble, ils ne forment pas un tableau cohérent d'une personne vivante — et cela est détecté moins cher que toute analyse d'un clic individuel.
Le troisième point, le plus désagréable pour l'automatisation : l'évaluation s'accumule au cours de la session et n'est pas réinitialisée par le rechargement de la page. Le classique «j'ai reçu un blocage — F5 / nouvel onglet» cesse d'être une réinitialisation de l'état. Les résultats de la vérification continue mettent à jour ce fameux cf_clearance, et Cloudflare indique clairement qu'une confirmation de clearance déjà délivrée peut être réduite ou annulée en plein milieu de la session, et peut également déclencher un défi supplémentaire.
Deux modes — et pourquoi il est important de le savoir à l'avance
- Minimize Friction (par défaut) — vérification en arrière-plan sans interstitiels. L'utilisateur ne voit rien, mais la garantie «la session est valide» est plus faible.
- Maximize Security (recommandé par Cloudflare) — un léger défi interstitiel, établissant une session valide, avec une dégradation consciente de l'UX.
Conclusion pratique : le comportement de protection sur un site spécifique dépend désormais des paramètres que vous ne voyez pas de l'extérieur. Un même script, un même proxy et un même site peuvent se comporter différemment avant et après que le propriétaire ait changé de mode. Les déclenchements sont visibles pour le propriétaire du site dans Sécurité → Analytique → Trafic → Analyse des bots — dans la même ligne que la répartition du score de bot et les correspondances WAF.
Échelle : pourquoi ce n'est pas «encore un anti-bot»
Le contexte qui rend cette nouvelle plus importante qu'un simple lancement. Cloudflare traite plus de 1 trillion de requêtes par jour, Turnstile fonctionne presque 3 milliards de fois par jour. Selon l'estimation de l'entreprise, le trafic automatisé a pour la première fois dépassé le trafic humain et représente environ 57 % de toutes les requêtes web. L'activation d'un niveau comportemental par un simple interrupteur sur une telle base signifie que la part d'Internet où un détecteur de comportement de session est actif pourrait augmenter brusquement — sans aucun engagement du côté des sites.
Et l'objectif déclaré est précisément ce dont on se sert aujourd'hui : «une automatisation avancée qui exécute JavaScript, fonctionne dans un environnement de navigateur réel et passe des captchas individuels sans éveiller de soupçons». Autrement dit, Playwright/Puppeteer avec des patches stealth, navigateurs anti-détection et navigateurs agents — c'est exactement la cible que Precursor décrit ouvertement.
Pour être honnête : Cloudflare n'a pas publié de données quantitatives — ni sur la précision, ni sur la part de faux positifs, ni sur le surcoût du suivi continu dans le navigateur. Pour l'instant, ce sont des capacités déclarées, et non mesurées indépendamment. Il n'y a pas non plus de vague publique de plaintes concernant des blocages massifs de faux positifs après deux semaines de déploiement.
Ce que cela signifie en pratique
1. La qualité de l'IP n'est plus «une condition suffisante» — mais reste nécessaire
La conclusion séduisante «puisque la détection est comportementale, les proxies ne comptent plus» est incorrecte. Precursor fonctionne par-dessus les couches précédentes : réputation de l'IP, fingerprinting TLS/HTTP, score de bot. Une IP de centre de données provenant d'un sous-réseau exposé obtient un score de bot élevé et un mode de défi strict avant même que l'analyse de la souris ne commence. Le comportement est un examen supplémentaire, et non un remplacement du filtre d'entrée : des proxies résidentiels ou des proxies mobiles avec un ASN vivant donnent simplement une chance d'atteindre le deuxième examen.
2. La session — un nouvel objet d'hygiène
Auparavant, l'erreur typique était «trop de requêtes d'une seule IP». Maintenant, elle est complétée par «trop d'activités non humaines au sein d'une seule session». D'où la pratique :
- Ne réutilisez pas un seul contexte de navigateur pour des centaines de tâches. Une longue session est une longue chaîne de comportements, où toute anomalie a le temps de s'accumuler. Une session plus courte signifie moins de matériel pour le scoring.
- Maintenez la liaison «session ↔ IP» stable. Changer l'IP de sortie en plein milieu d'une session est une contradiction évidente ; pour les scénarios avec connexion, des sessions collantes avec une durée de vie adaptée à la tâche sont nécessaires, et non une rotation agressive à chaque requête.
- Ne mélangez pas les profils. Un compte — un ensemble stable : profil de navigateur, IP, fuseau horaire, langue, motif comportemental.
3. Le comportement synthétique devra être plus honnête — ou ne pas être fait du tout
Les émulations «humaines» naïves (mouvement linéaire vers le centre du bouton, pauses régulières de 100 ms, clic instantané après le chargement) fonctionnent contre vous sous les vérifications croisées : elles ajoutent un signal, au lieu de l'éliminer. Si le scénario ne nécessite pas d'imitation humaine — il est plus sûr de ne pas générer de comportement du tout que de générer un mauvais comportement. Nous avons approfondi ce niveau dans un article sur la biométrie comportementale et les proxies.
4. Les points de terminaison API et les clients non-navigateur — une histoire à part
Precursor nécessite l'exécution de JavaScript. Les clients sans navigateur — curl, backends mobiles — et les requêtes XHR/fetch vers des points de terminaison protégés doivent correctement porter les informations d'identification de la session, c'est-à-dire cf_clearance. En pratique, cela signifie : d'abord, le navigateur établit une session valide, puis les requêtes «rapides» se font avec ses cookies et dans le même contexte réseau (même IP, profil TLS convenu). Un décalage entre la session du navigateur et le client HTTP est cette contradiction interne que l'on recherche.
5. Les points de collecte de données se déplacent
Là où le site activera Maximize Security, la collecte sans tête bon marché deviendra sensiblement plus coûteuse. La réaction raisonnable n'est pas d'escalader «l'émulation intelligente» à tout prix, mais de revoir la source : API officielle de la plateforme, flux partenaires, points de terminaison mobiles, ensembles de données publics. Le chemin entièrement basé sur le navigateur a du sens là où les données ne peuvent pas être obtenues autrement.
Où cela mène
Precursor s'intègre logiquement dans la ligne Cloudflare de l'année dernière : blocage par défaut des crawlers IA, AI Crawl Control avec des règles granulaires, Pay Per Crawl comme tentative de rendre l'accès au contenu payant, et à partir du 15 septembre 2026 — blocage par défaut des crawlers IA à usage mixte sur les pages avec publicité. La direction générale : le site veut savoir non pas «es-tu un humain au moment de l'entrée», mais «qui es-tu tout au long de la visite et pourquoi es-tu venu».
Pour le marché de l'automatisation, cela signifie un déplacement lent mais unidirectionnel : le coût d'une session «humanoïde» augmente, le coût d'une requête cesse d'être la métrique principale. Gagnent ceux qui collectent moins, mais plus précisément : sessions soignées, IP propres adaptées à la tâche, empreintes convenues — et une évaluation claire de quelles données valent vraiment le chemin du navigateur.
En bref
- Depuis le 13 juillet 2026, Cloudflare déploie Precursor — un détecteur comportemental de session, activé par un simple interrupteur sans modifications de code du côté du site.
- Signaux : pointeur, défilement, rythme de frappe (sans contenu), presse-papiers, focus et visibilité ; plus des vérifications croisées pour les contradictions.
- L'évaluation s'accumule au cours de la session ; le rechargement de la page ne réinitialise pas la signature, la clearance peut être annulée en plein milieu de la visite.
- Les proxies ne sont pas «annulés» : la couche IP est restée un filtre d'entrée, le comportement est un deuxième examen.
- Cloudflare n'a pas encore publié de données quantitatives sur la précision et les faux positifs — il est trop tôt pour tirer des conclusions sur la rigueur réelle.