La détection de bots en 2026Diagnostiquer les échecs de scraping face à Cloudflare, DataDome et Akamai

Un scraper qui fonctionnait il y a un mois se met à renvoyer des 403, des pages de challenge ou des réponses HTTP 200 sans les données attendues. Le premier suspect est en général une nouvelle version anti-bot de Cloudflare, DataDome ou Akamai, et c'est parfois la bonne piste. Mais la cause est tout aussi souvent un template de page modifié, un cookie de session expiré, une nouvelle redirection ou un pool de workers qui a discrètement doublé sa concurrence.

Avant de faire tourner les proxies ou de reconstruire les empreintes de navigateur, déterminez où l'échec se produit réellement. C'est plus important en 2026 qu'auparavant, car la détection regarde de plus en plus au-delà de la requête isolée : le comportement de session, l'intégrité du navigateur et la façon dont un client parcourt un site dans la durée peuvent tous décider si la requête suivante est autorisée ou soumise à un challenge.

Cet article présente ce que les trois éditeurs ont réellement documenté en 2026, ce que chaque changement implique pour un pipeline de scraping, ainsi qu'une méthode pratique pour diagnostiquer les échecs, escalader de façon sélective et mesurer le rétablissement. Le code se trouve dans ScraperHub/what-changed-in-cloudflare-datadome-and-akamai-bot-detection-in-2026, un framework de diagnostic en Python qui classe les réponses et rend compte des résultats exploitables. Il ne résout aucun challenge et ne modifie pas l'identité des requêtes, et rien dans cet article ne le fait non plus.

Ce qui a changé dans la détection de bots en 2026

Aucune des évolutions pertinentes ne se résume à une nouvelle empreinte ou à un challenge obligatoire. Elles changent quand une décision est prise, quelles preuves l'éclairent, et comment les opérateurs de sites peuvent traiter différents types de trafic automatisé.

Il s'agit d'annonces et de sorties documentées, pas de preuves que chaque site protégé les utilise. Plusieurs fonctionnalités ont été annoncées sans date publique de disponibilité générale.

Cloudflare : la détection se poursuit après la première requête

Precursor, présenté en juillet, évalue les signaux du navigateur et du comportement sur toute une session. La documentation de Cloudflare explique que l'évaluation, au fil de son évolution, met à jour l'état de session stocké dans le cookie cf_clearance ; cet état peut être revu à la baisse ou invalidé. Pour un scraper, réussir le premier challenge n'est plus un résultat stable : sur les zones où Precursor est activé, les requêtes suivantes peuvent changer le verdict.

La disponibilité doit être vérifiée zone par zone. Le changelog de lancement évoque un déploiement auprès de tous les clients, tandis que l'annonce présente Precursor comme une composante d'Enterprise Bot Management, gratuite jusqu'à la disponibilité générale prévue plus tard dans l'année.

Adaptive Intelligence a suivi le 31 août. Son modèle est réentraîné en continu sur le trafic réel et s'active via Auto Update Machine Learning pour les clients Enterprise Bot Management, ce qui rend les sorties périodiques de modèles numérotés moins marquantes. L'annonce décrivait des règles jetables et éphémères comme une composante encore à venir : considérez-les donc comme prévues plutôt que livrées.

En parallèle, Cloudflare a scindé sa politique envers les crawlers IA en contrôles Search, Agent et Training distincts. À partir du 15 septembre, les nouvelles zones reçoivent des préréglages recommandés, plus stricts pour les sites financés par la publicité, que les opérateurs peuvent modifier à tout moment. Ce sont des choix d'opérateur, pas une interdiction de toute requête automatisée, et Bot Preference Sync peut inscrire les préférences choisies dans robots.txt.

DataDome : intégrité des challenges et preuves issues du navigateur

La nouvelle obfuscation basée sur une VM de DataDome compile la logique de Device Check et de Slider en bytecode exécuté par un interpréteur personnalisé dans le navigateur. Son effet principal est de rendre le challenge plus difficile à rétro-concevoir et à rejouer à moindre coût, pas d'ajouter une nouvelle catégorie d'empreinte réseau.

Son analyse consacrée à Proof of Browser décrit des contrôles combinant rendu, WebGL, mutations du DOM et timing. Il s'agit de mécanismes décrits par l'éditeur ; ni cet article ni le dépôt compagnon ne mesurent leur efficacité de détection. La documentation de Device Check explique comment les résultats de détection déclenchent le challenge.

DataDome a également formalisé l'offre Agent Trust le 5 mai, après avoir ajouté la prise en charge de Web Bot Auth en janvier. La preuve d'identité peut provenir d'une authentification signée ou d'autres mécanismes de confiance. Copier le user agent d'un crawler connu n'établit ni l'identité ni l'autorisation.

Enfin, les versions 3.0 des modules Apache, Nginx, Cloudflare Worker et Fastly de DataDome ont modifié la gestion des chemins et l'exclusion des ressources statiques. Ce sont des changements d'intégration qui dépendent de la mise à jour par chaque opérateur, pas un nouveau détecteur TLS ou HTTP/2.

Akamai : validation adaptative et politique anti-bot plus fine

En mars, Akamai a annoncé des améliorations de Content Protector, dont la protection des applications natives et son Advanced Validation Framework. L'AVF peut demander davantage de données sur l'appareil ou le comportement lorsque l'analyse passive n'est pas concluante, avec un challenge interactif optionnel. L'annonce ne donne aucune date publique de disponibilité générale.

Akamai a aussi réparti son trafic de bots IA en catégories plus fines, à savoir Training Crawlers, Search Crawlers et Fetchers and Agents, avec les filtres correspondants dans Web Security Analytics. Elles donnent aux opérateurs un contrôle plus fin sans imposer d'action par défaut.

Les sources examinées ici ne fournissent aucune base publique permettant d'affirmer qu'Akamai a livré un nouveau modèle central pour Bot Manager, un nouveau format _abck ou un nouveau détecteur de proxies résidentiels en 2026. La même retenue vaut pour des techniques bien connues : l'empreinte TLS, les empreintes de navigateur et la réputation IP comptent toujours, mais leur existence n'a rien d'une annonce de 2026.

Diagnostiquer l'échec avant de modifier votre scraper

Partez d'une seule réponse en échec, conservée. Notez son horodatage, l'URL demandée et l'URL finale, les en-têtes et le corps de la réponse, la version du scraper, le point de sortie, l'identifiant de session le cas échéant et la concurrence, puis comparez-la à une capture de référence qui fonctionnait. Sans ces dimensions, relier un incident à une sortie d'éditeur relève surtout de la devinette.

Écartez d'abord les causes applicatives courantes :

1. Dérive du markup ou du parser : l'élément attendu existe-t-il encore dans le HTML brut ?
2. Rendu JavaScript : les données n'apparaissent-elles qu'après exécution côté client ou dans une réponse réseau ultérieure ?
3. Authentification : la requête a-t-elle été redirigée vers une page de connexion, a-t-elle perdu un cookie ou rencontré un token CSRF expiré ?
4. Profil de trafic : le nombre de workers, le débit de requêtes ou le point de sortie ont-ils changé ?
5. Redirections et variantes : l'URL canonique, la locale, la version d'appareil ou le type de contenu ont-ils changé ?

Classez ensuite la réponse elle-même, et non l'exception levée par votre parser.

Les marqueurs propres aux éditeurs restreignent la recherche, mais ne suffisent pas à eux seuls à attribuer un blocage de façon fiable. Cloudflare documente cf-mitigated: challenge, tandis qu'un en-tête cf-ray seul n'est pas un verdict de blocage, puisque chaque réponse passant par son proxy en porte un. Les cookies ou endpoints de challenge DataDome ajoutent du contexte, et des noms de cookies associés à Akamai comme _abck et bm_sz ne prouvent rien quant à une décision de blocage précise.

Séparer le verdict de récupération du succès du contenu

La Crawling API rend cette distinction observable. cb_status est le verdict de Crawlbase sur la réponse, y compris ses propres contrôles de blocage et de contenu. original_status correspond normalement au statut renvoyé par la cible. Le champ url final révèle les redirections ; avec format=json activé, ces champs arrivent avec le corps de la réponse et le domain_complexity (palier tarifaire). Une requête vers https://example.com/ le 7 octobre 2026 a renvoyé :

{
  "original_status": 200,
  "pc_status": 200,
  "cb_status": 200,
  "url": "https://example.com/",
  "domain_complexity": "standard"
}

Aucun de ces statuts n'indique qu'un titre de produit, un prix ou tout autre champ métier est valide. Un pipeline robuste valide explicitement ces champs, comme une troisième couche.

Le classifieur du dépôt compagnon, dans final/bot_diag/classify.py, rend la distinction concrète :

# final/bot_diag/classify.py
def classify_response(
    status: int | None,
    body: str,
    headers: Mapping[str, str] | None = None,
    expected_fields: Sequence[str] | None = None,
) -> str:
    header_map = _header_map(headers)
    text = body or ""
    lowered = text.lower()
    if _is_cloudflare_challenge(lowered, header_map) or _is_datadome_challenge(lowered, header_map):
        return LABEL_CHALLENGED
    is_blocked = (
        _is_akamai_block(text, lowered)
        or _is_cloudflare_block(lowered, header_map)
        or _is_datadome_block(status, lowered, header_map)
        or (status in {401, 403, 429} and bool(text.strip()))
    )
    if is_blocked:
        return LABEL_BLOCKED
    return _content_label(status, text, expected_fields)

Il s'agit d'un extrait, pas d'un snippet autonome : les imports, les labels et les helpers se trouvent ailleurs dans le package. Il renvoie l'un de ces quatre labels : blocked, challenged, invalid_content et ok. Le validateur de champs est volontairement minimal et prend en charge des motifs JSON et HTML simples plutôt que des schémas de production : consultez donc l'étape 3 et ses fixtures avant de l'adapter à vos données.

Une extension pratique consiste à valider les types de champs, les plages plausibles, la cohérence entre champs et la fraîcheur, pas seulement la présence. Cela permet de détecter l'échec décrit dans l'empoisonnement silencieux des réponses, où une récupération techniquement réussie renvoie malgré tout des valeurs inutilisables ou trompeuses.

Choisir la remédiation selon la classe d'échec

Des échecs différents appellent des interventions différentes. La rotation à l'aveugle et les retries systématiques rendent les preuves plus difficiles à lire, tout en ajoutant de la charge et des coûts.

Cohérence des requêtes et de la session. Une identité de navigateur revendiquée doit être cohérente avec son transport, ses en-têtes, son historique de cookies et sa séquence de navigation. Changer uniquement le user agent ou l'IP de sortie aide rarement face à une évaluation de l'intégrité du navigateur ou au niveau de la session. Gardez des sorties stables lorsqu'un workflow repose sur une navigation authentifiée ou avec état.

Exécution dans le navigateur. Activez le rendu lorsque les champs dont vous avez besoin dépendent de JavaScript. C'est plus coûteux et plus lent : sur la Crawling API, une requête JavaScript est facturée au double du tarif standard. Le rendu ne vaut pas autorisation d'accéder à une cible, et ce n'est pas une solution universelle aux challenges. Pour le compromis opérationnel, consultez navigateurs headless ou API de scraping.

Retry et escalade. Appliquez un backoff plafonné aux échecs transitoires. Corrigez les URL et sélecteurs invalides au lieu de les relancer tels quels. Examinez un blocage confirmé plutôt que de le marteler avec la même requête. Sur la Crawling API, voici les codes que vous rencontrerez le plus souvent et la première chose à faire :

Un appel en échec renvoie également le statut HTTP 520. Il s'agit de la ligne de statut, pas d'un cb_status, donc basez toujours votre logique sur le cb_status présent dans la réponse. Le dépôt dispose d'une étape d'escalade qui déclenche l'escalade JavaScript sur 520 et 525 et ajoute page_wait=2000 et ajax_wait. Faites-la correspondre au tableau ci-dessus avant de la réutiliser : escaladez sur 503 et, s'il est inattendu, sur 207, et traitez 705 et 706 comme un signal pour ralentir. Les attentes aident pour le contenu rendu tardivement ; elles ne remédient pas à un challenge échoué.

Identité et politique. Pour des agents nommés et légitimes, une identité signée et un enregistrement peuvent constituer une meilleure voie que l'imitation d'un trafic de navigateur quelconque. Web Bot Auth de Cloudflare, Agent Trust de DataDome et les contrôles d'Akamai liés aux agents relèvent de cette couche. Une identité vérifiée ne garantit pas pour autant l'autorisation.

Récupération gérée. Crawlbase propose la Crawling API pour les intégrations orientées requête, le Smart AI Proxy pour les clients existants compatibles avec un proxy, et la solution Enterprise Crawler pour les jobs en masse mis en file d'attente et leur livraison. Une infrastructure gérée vous évite d'exploiter vous-même des flottes de navigateurs et des pools de proxies, mais les cibles prises en charge, la latence, les crédits et les taux d'échec restent à mesurer.

Évaluer le rétablissement avec le projet compagnon

Le dépôt nécessite Python 3.10+ et fournit six scripts incrémentaux dans steps/ ainsi qu'un package bot_diag dans final/. Il s'agit d'un framework de diagnostic, pas d'un benchmark de contournement en conditions réelles pour quelque éditeur que ce soit. Son pipeline :

1. Commencer par une requête Crawling API avec le Normal token, en utilisant format=json.
2. Inspecter cb_status, original_status, l'URL finale et le contenu.
3. Classer la réponse et valider les champs requis.
4. Relancer ou escalader uniquement lorsque la politique d'échec le justifie.
5. Enregistrer un résultat par URL dans un CSV et résumer les résultats exploitables et le surcoût des retries.
6. Afficher, domaine par domaine, le choix entre Smart AI Proxy et la Crawling API.

Établir une référence reproductible

Clonez le dépôt, installez ses dépendances et commencez par le parcours synthétique, qui ne nécessite aucun token. Depuis le répertoire final :

python -m bot_diag evaluate urls.example.txt --fields price,title --dry-run

Pour une exécution réelle, définissez CRAWLBASE_TOKEN (et CRAWLBASE_JS_TOKEN pour l'escalade JavaScript), fournissez une liste d'URL que vous êtes autorisé à récupérer, puis lancez :

python -m bot_diag evaluate urls.txt --fields price,title \
  --concurrency 4 --max-retries 2 --out sample_results.csv

L'évaluateur plafonne la concurrence à huit. Il rapporte un taux ok calculé sur les URL d'entrée, les latences p50 et p95 par tentative de requête (méthode du rang le plus proche) et le surcoût des retries. Le chiffre de latence exclut les pauses de backoff entre les retries, et le CSV contient une ligne consolidée par URL, et non une par tentative. Ces deux points comptent lorsque vous comparez ces chiffres à la durée réelle d'un job de production.

Pour une comparaison pertinente, échantillonnez environ 100 à 200 URL couvrant des types de pages représentatifs, appliquez les mêmes règles de validation à chaque méthode de récupération et répétez l'opération sur plus d'une journée. Segmentez les résultats par domaine, classe de page, zone géographique et mode de rendu. Les fixtures synthétiques testent le déroulement du programme ; seuls des échantillons réels et autorisés mesurent la fiabilité d'une cible.

Router délibérément un domaine en échec

Le script d'exemple de routage compte les challenges observés par nom d'hôte normalisé. En dessous de son seuil par défaut de trois, il conserve Smart AI Proxy ; à partir de ce seuil, il bascule le domaine vers la Crawling API :

# final/bot_diag/routing.py
def route_domain(
    domain: str,
    challenge_counts: Mapping[str, int],
    *,
    threshold: int = DEFAULT_CHALLENGE_THRESHOLD,
) -> str:
    """Return ``api`` after ``threshold`` challenges, otherwise ``proxy``.

    ``proxy`` means the caller's existing HTTP client should keep using
    ``smartproxy.crawlbase.com:8013``. ``api`` means that domain should move
    to the Crawling API. Counts must already be keyed by ``domain_key``.
    """
    if threshold < 1:
        raise ValueError("threshold must be at least 1")
    key = domain_key(domain)
    if challenge_counts.get(key, 0) >= threshold:
        return API
    return PROXY

L'étape 6 affiche la décision ; elle n'ouvre pas de connexion proxy et ne déclenche aucun basculement automatique. L'endpoint HTTPS de Smart AI Proxy est smartproxy.crawlbase.com:8013 avec une authentification proxy par token, et la documentation de Smart AI Proxy décrit l'en-tête CrawlbaseAPI-Parameters et ses options, y compris celles liées à JavaScript. Dans l'exemple, l'escalade via la Crawling API s'appuie sur le JavaScript token, distinct du Normal token.

Un véritable service de routage a aussi besoin de compteurs qui expirent, d'observabilité, d'un comportement de type circuit breaker et d'un chemin de retour vers la route la moins coûteuse. Sans cela, une brève salve de trois challenges déplace définitivement le trafic d'un nom d'hôte.

Mesurer le coût par résultat exploitable, pas par HTTP 200

Une fois que le même échantillon d'URL validé est passé par deux approches, comparez ensemble la fiabilité et le coût d'exploitation total.

url_completion_rate    = urls_with_valid_final_result / input_urls
attempt_success_rate   = successful_attempts / all_fetch_attempts
cost_per_usable_result = total_allocated_cost / validated_results

Les dénominateurs diffèrent volontairement. La complétion par URL mesure la part du job qui a abouti ; le succès par tentative mesure l'efficacité du chemin de récupération. Ne mettez pas les deux côte à côte en les appelant tous deux « taux de succès ».

Comptabilisez les dépenses de proxy et de calcul, les crédits du fournisseur géré, le surcoût des retries, l'infrastructure de navigateurs et la maintenance d'ingénierie, sans compter deux fois ce qu'un tarif géré inclut déjà. Chez Crawlbase, seuls les appels réussis sont facturés : les 200, 404, 410 et redirections de la cible, les corps 200 vides (cb_status 207), ainsi que tout statut que vous ajoutez via custom_success_codes. Les blocages et les défaillances internes sont gratuits. domain_complexity est le palier tarifaire qui multiplie chaque requête facturée : relevez donc la consommation réelle dans l'usage de votre compte et la grille tarifaire de Crawlbase plutôt que de l'estimer à partir du nombre de requêtes.

Les clients autogérés peuvent être économiques sur des cibles prévisibles ou lorsqu'un contrôle complet du navigateur est indispensable. La récupération gérée devient plus intéressante dès que la maintenance de palliatifs propres à chaque domaine accapare le temps d'ingénierie. Aucune des deux approches ne dispense de valider les données renvoyées.

Conclusion

Les changements marquants de 2026 portent sur la collecte continue de preuves, l'intégrité du navigateur et une politique plus fine côté opérateurs. Aucun d'eux ne fait disparaître les anciens modes d'échec : sélecteurs cassés, sessions expirées, concurrence non maîtrisée et rendu incomplet.

Traitez la fiabilité du scraping comme un système observable : conservez les réponses brutes, séparez le verdict de récupération de la réponse de la cible, classez les échecs avec prudence, escaladez de façon sélective et jugez le résultat sur des données validées. Le dépôt compagnon constitue un point de départ pour ce workflow. Si votre infrastructure de récupération devient le goulot d'étranglement de la maintenance, faites passer les mêmes URL représentatives par Crawlbase et comparez le coût par résultat exploitable avant de modifier l'architecture.

Références principales

• Cloudflare : Precursor, Documentation de Precursor, Adaptive Intelligence, Contrôles du trafic IA, Politiques pour les crawlers IA à usage mixte
• DataDome : Obfuscation basée sur une VM, Proof of Browser, Agent Trust, Device Check
• Akamai : Améliorations de Content Protector, Catégories de trafic des bots IA, Mise à jour de Web Security Analytics

Foire aux questions (FAQ)

Pourquoi un scraper réussit-il un challenge puis échoue-t-il plus tard ?

Sur les sites qui utilisent une évaluation fondée sur la session, l'activité ultérieure peut modifier la décision de confiance. Comparez l'ordre des requêtes, les cookies, la continuité de session, le débit et le comportement de sortie avant de supposer que le premier challenge était le seul point de contrôle.

Un HTTP 200 signifie-t-il que le scraping a réussi ?

Non. Il confirme une réponse à une seule couche. Une page de challenge, une coquille vide, une page redirigée ou des données plausibles mais fausses peuvent toutes arriver avec un 200. Validez les champs et ce qu'ils signifient avant de marquer une URL comme terminée.

Les proxies résidentiels aident-ils encore face à la détection de bots moderne ?

Ils aident pour la réputation IP et l'accès géographique, pas en cas d'exécution navigateur absente ou de signaux de session incohérents. Une rotation agressive à chaque requête peut rendre les workflows avec état moins cohérents, pas plus.

Quelles réponses de la Crawling API sont facturées ?

Uniquement les réponses réussies : cb_status 200 (y compris les 404, 410 et redirections de la cible), les corps 200 vides signalés en tant que cb_status 207, et les statuts que vous ajoutez via custom_success_codes. Les blocages comme 503, 704, 705 et 706 ainsi que les défaillances internes ne sont pas facturés.

Crawlbase peut-il garantir l'accès aux sites protégés par Cloudflare, DataDome ou Akamai ?

Aucun fournisseur ne peut garantir l'accès à toutes les cibles et configurations. Le bon test est un échantillon d'URL reproductible et autorisé, avec validation au niveau des champs, suivi de la latence et comptabilisation des crédits, et non une seule requête réussie.

NZ

Neil Zamora

Architecte senior · Crawlbase

Architecte senior chez Crawlbase, axé sur les systèmes derrière le crawling à grande échelle : rotation de proxys, résilience anti-bot et les API qui masquent cette complexité.

IK

Ian Kalvin

Ingénieur support technique · Crawlbase

Ingénieur support technique chez Crawlbase, il écrit depuis la première ligne de ce qui casse réellement en production, sur les configurations de scraping et de proxys.