Akamai Bot Manager v2 Deep-Dive : signaux, sensor_data et stratégies de contournement en 2026

Avertissement légal : Cet article s'adresse aux équipes de sécurité, chercheurs autorisés et ingénieurs d'automatisation agissant dans le respect des Conditions d'Utilisation des sites cibles, du Computer Fraud and Abuse Act (CFAA) et du RGPD européen. Les techniques décrites ici concernent exclusivement l'automatisation légitime — monitoring de vos propres assets, recherche en sécurité, tests d'intrusion autorisés. Toute utilisation frauduleuse est strictement proscrite.

Akamai Bot Manager v2 représente en 2026 l'un des systèmes anti-bot les plus sophistiqués du marché. Contrairement aux WAF classiques qui se contentent de filtrer par User-Agent ou rate-limiting, Bot Manager v2 construit un score de confiance continu côté serveur, alimenté par des dizaines de signaux côté client et réseau. Pour les ingénieurs d'automatisation, comprendre cette pile de signaux n'est pas optionnel — c'est la condition préalable à tout contournement Akamai Bot Manager propre et durable.

La pile de signaux d'Akamai Bot Manager v2 : vue d'ensemble

Bot Manager v2 repose sur trois couches de détection qui se renforcent mutuellement :

• Cookies de session — _abck (challenge principal) et ak_bmsc (session de base).
• Télémétrie bmak / sensor.js — un moteur JavaScript obfusqué qui collecte en continu les interactions utilisateur et les propriétés du navigateur.
• Score de confiance côté serveur — un modèle agrégeant la réputation IP, les empreintes TLS/HTTP/2, la cohérence du sensor_data et le comportement de navigation.

Le cookie _abck est le pivot. Il est déposé lors de la première requête par le serveur Akamai via l'en-tête Set-Cookie, puis validé (ou invalidé) à chaque requête suivante. Sa valeur contient une signature cryptographique liée au sensor_data calculé par sensor.js. Si le sensor_data ne correspond pas à ce que le serveur attend pour cet environnement, _abck est marqué comme invalide — typiquement avec un suffixe ~-1~-1~-1 — et les requêtes suivantes reçoivent un challenge ou un blocage 403.

Le cookie ak_bmsc, plus simple, sert de jeton de session initial. Il est posé même quand le navigateur n'exécute pas JavaScript, ce qui permet à Akamai de distinguer un client sans JS (suspect) d'un client qui a résolu le challenge (de confiance).

Le moteur sensor.js / bmak : collecte télémétrique en continu

Le script sensor.js (souvent référencé via l'objet bmak dans le DOM) est la pièce maîtresse de Bot Manager v2. Il est servi avec une obfuscation lourde — noms de variables aléatoires, contrôle-flow flattening, chaînes chiffrées — et change de version régulièrement (parfois plusieurs fois par semaine sur les sites à fort trafic).

Son rôle : assembler un payload appelé sensor_data, une longue chaîne encodée transmise au serveur via une requête POST silencieuse (souvent vers /_bm/...). Ce payload encode :

• Événements de pointeur — coordonnées de souris, timestamps précis au milliseconde, vitesse et accélération du curseur, événements touchstart/touchmove sur mobile.
• Événements de scroll — direction, vélocité, position relative dans le viewport.
• Propriétés d'écran et GPU — navigator.userAgent, screen.width, screen.height, window.devicePixelRatio, WebGLRenderingContext.getParameter() (vendor et renderer GPU), navigator.hardwareConcurrency, navigator.deviceMemory.
• Timing — intervalles entre événements, temps de résolution du challenge, performance.now() au moment de l'exécution du script.
• Signaux d'environnement — détection de navigator.webdriver, présence de window.cdc_adoQpoasnfa76pfcZLmcfl_Array (artefact ChromeDriver), Notification.permission, état des plugins, timezone Intl.DateTimeFormat().resolvedOptions().timeZone.

Pourquoi un seul champ mismatch invalide _abck ? Parce qu'Akamai ne valide pas chaque champ indépendamment — elle construit un hash composite du sensor_data et le compare à la signature attendue. Si navigator.hardwareConcurrency indique 8 cœurs mais que navigator.deviceMemory rapporte 2 GB (incohérent pour une machine moderne), ou si WebGL renderer dit "Apple GPU" mais que le User-Agent est Windows, le serveur recalcule le hash, constate l'écart, et marque _abck comme ~-1~-1~-1. Le client a alors une fenêtre de quelques requêtes avant un blocage complet.

Signaux protocole 2026 : post-quantum, JA4 et HTTP/2

En 2026, Akamai ne se contente plus d'analyser le JavaScript. Les signaux de transport sont devenus une couche de détection à part entière, et ils doivent cohérer avec le User-Agent déclaré.

X25519MLKEM768 : le key share post-quantum par défaut

Depuis Chrome 131 (fin 2024), Google a activé le key share post-quantum X25519MLKEM768 dans le ClientHello TLS par défaut. En 2026, tous les navigateurs Chromium récents (Chrome, Edge, Brave, Opera) envoient ce key share hybrid Kyber/X25519 dans leur supported_groups. Firefox a suivi avec NSS 3.101+ début 2025.

Conséquence pratique : si votre outil d'automatisation utilise une bibliothèque TLS qui n'envoie pas X25519MLKEM768 (par exemple, une vieille version de Python ssl ou un client Go compilé sans support post-quantum), le ClientHello ne correspondra à aucun navigateur réel de 2026. Akamai le détecte immédiatement : un User-Agent "Chrome 131+" sans X25519MLKEM768 dans les supported_groups est un signal de bot flagrant.

Pour vérifier votre propre empreinte TLS, vous pouvez utiliser le service tls.peet.ws qui affiche le JA3 et JA4 de votre ClientHello en temps réel.

Empreinte JA4 TLS

JA4 est le successeur de JA3, introduit par FoxIO en 2024. Contrairement à JA3 qui concatène tous les cipher suites en une seule chaîne, JA4 sépare les composants :

• q ou t — QUIC ou TCP
• 13 — version TLS (1.3)
• d — cipher suites triées par ordre (descending)
• ja4s_ — extensions triées
• 00 — SNI présent

Un Chrome 131+ sur Windows 11 produira un JA4 comme t13d1516h2_8daaf6152771_b186095e22b6. Si votre client HTTP envoie un JA4 différent tout en déclarant Chrome dans le User-Agent, c'est une incohérence immédiate. Akamai maintient une base de correspondances User-Agent → JA4 attendu.

HTTP/2 SETTINGS fingerprint

Au-delà de TLS, le fingerprint HTTP/2 compte. Les SETTINGS frames envoyées au début de la connexion HTTP/2 varient selon le client :

• Chrome envoie SETTINGS_INITIAL_WINDOW_SIZE = 12517377, SETTINGS_MAX_CONCURRENT_STREAMS = 1000, SETTINGS_ENABLE_PUSH absent (supprimé depuis Chrome 106).
• Firefox utilise des valeurs différentes — SETTINGS_INITIAL_WINDOW_SIZE = 131072, pas de SETTINGS_MAX_CONCURRENT_STREAMS.
• Python httpx ou requests via h2 envoie encore d'autres valeurs, souvent avec SETTINGS_ENABLE_PUSH = 0.

Akamai vérifie que l'ordre et les valeurs des paramètres HTTP/2 SETTINGS correspondent au navigateur déclaré. Un client Python qui déclare "Chrome/131" mais envoie SETTINGS_ENABLE_PUSH=0 est immédiatement identifié.

Pourquoi les proxies résidentiels sont indispensables

Akamai Bot Manager v2 pondère lourdément la réputation IP dans son score de confiance. Les plages d'adresses IP attribuées aux datacenters (AWS, Google Cloud, Azure, OVH, Hetzner, DigitalOcean) sont pré-notées comme bot dans la base de réputation d'Akamai. Ce n'est pas une heuristique — c'est une liste d'ASN connus.

Quand une requête arrive depuis l'ASN 14618 (Amazon AWS) ou 15169 (Google), Akamai applique un score de départ négatif. Même si votre sensor_data est parfait, même si votre JA4 correspond exactement, le score IP peut suffire à déclencher un challenge additionnel ou un CAPTCHA silencieux.

À l'inverse, les adresses IP résidentielles — attribuées par des FAI à des particuliers (Orange, Comcast, Vodafone, Deutsche Telekom) — bénéficient d'un score de départ neutre ou positif. C'est pourquoi tout contournement Akamai Bot Manager sérieux passe par des proxies résidentiels de qualité.

Les proxies mobiles (4G/5G) offrent un score encore plus favorable, car les opérateurs mobiles NATent massivement leurs utilisateurs, rendant la rotation IP naturelle indiscernable d'un comportement humain normal.

Approche pratique avec ProxyHat : automatisation légitime

Voyons comment configurer un environnement d'automatisation légitime avec ProxyHat pour que sensor_data et _abck se génèrent correctement. L'objectif n'est pas de "bypasser" Akamai par ruse, mais de présenter un profil cohérent que le système reconnaît comme légitime.

Étape 1 : ProxyHat residential proxy configuration

ProxyHat fournit un gateway unique pour tous ses proxies résidentiels. La configuration se fait via le format d'authentification standard :

# HTTP proxy - résidentiel US
http://user-country-US:PASSWORD@gate.proxyhat.com:8080

# HTTP proxy - résidentiel Allemagne, Berlin
http://user-country-DE-city-berlin:PASSWORD@gate.proxyhat.com:8080

# SOCKS5 proxy
socks5://user-country-US:PASSWORD@gate.proxyhat.com:1080

# Sticky session (même IP pendant la session)
http://user-session-myresearch42-country-DE:PASSWORD@gate.proxyhat.com:8080

Pour du scraping Akamai, utilisez toujours des sticky sessions — le cookie _abck est lié à l'IP qui l'a généré. Si l'IP change en milieu de session, Akamai invalide le cookie et déclenche un nouveau challenge.

Étape 2 : Navigateur stealth avec Playwright

Un navigateur headless nu ne passera pas Bot Manager v2. Il faut un contexte navigateur qui :

1. Exécute le vrai sensor.js d'Akamai (pas de blocage de scripts tiers).
2. Ait des propriétés matérielles cohérentes (GPU, screen, memory).
3. Émette un ClientHello TLS correspondant au navigateur réel (Chrome 131+ avec X25519MLKEM768).
4. Utilise une IP résidentielle via ProxyHat.

# Python avec Playwright + proxy ProxyHat
from playwright.sync_api import sync_playwright

proxy_config = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-session-akamai-research-country-DE",
    "password": "YOUR_PASSWORD"
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # headful pour les propriétés GPU réelles
        proxy=proxy_config,
        args=[
            "--disable-blink-features=AutomationControlled",
            "--disable-features=IsolateOrigins,site-per-process"
        ]
    )
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                   "AppleWebKit/537.36 (KHTML, like Gecko) "
                   "Chrome/131.0.0.0 Safari/537.36",
        viewport={"width": 1920, "height": 1080},
        locale="de-DE",
        timezone_id="Europe/Berlin"
    )
    page = context.new_page()
    page.goto("https://example-target.com")
    
    # Attendre que _abck soit résolu (pas de ~-1~-1~-1)
    cookies = context.cookies()
    abck = [c for c in cookies if c["name"] == "_abck"]
    if abck and "~-1~-1~-1" not in abck[0]["value"]:
        print("_abck valide - session établie")
    
    page.screenshot(path="akamai_result.png")
    browser.close()

Étape 3 : Vérification avec curl (diagnostic rapide)

Pour un diagnostic rapide de la réputation IP sans navigateur complet :

# Test de connectivité via ProxyHat
curl -x http://user-country-DE:PASSWORD@gate.proxyhat.com:8080 \
  -s -o /dev/null -w "%{http_code} %{time_total}s" \
  https://httpbin.org/ip

# Vérifier le JA4 via tls.peet.ws à travers le proxy
curl -x http://user-country-DE:PASSWORD@gate.proxyhat.com:8080 \
  -s https://tls.peet.ws/api/all | jq '.tls.ja4'

Erreurs courantes et cas limites

1. Incohérence User-Agent / TLS / HTTP/2

L'erreur la plus fréquente : déclarer Chrome 131 dans le User-Agent mais utiliser un client HTTP dont la bibliothèque TLS ne supporte pas X25519MLKEM768. requests en Python utilise OpenSSL, qui n'envoie pas X25519MLKEM768 par défaut avant OpenSSL 3.4+ (fin 2024). Vérifiez votre version :

python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"

Si vous êtes en OpenSSL 3.0.x, votre ClientHello ne correspondra à aucun navigateur réel de 2026.

2. Rotation IP en milieu de session

Changer d'IP en milieu de session casse _abck. Utilisez des sticky sessions ProxyHat avec un identifiant de session stable. La rotation d'IP ne doit se faire qu'au démarrage d'une nouvelle session, pas pendant une session active.

3. Headless sans GPU réel

Le mode headless pur (headless=True dans Playwright) ne donne pas accès au GPU réel. WebGLRenderingContext.getParameter(37445) (UNMASKED_VENDOR_WEBGL) renvoie "Google Inc." et 37446 (UNMASKED_RENDERER_WEBGL) renvoie "SwiftShader" — un signal immédiat de headless. Préférez headless=False avec un serveur X virtuel (xvfb) sur Linux, ou utilisez headless=new (nouveau mode headless de Chrome qui préserve mieux les propriétés GPU).

4. Timezone et locale incohérents

Si votre proxy est en Allemagne (country-DE) mais que Intl.DateTimeFormat().resolvedOptions().timeZone renvoie "America/New_York", c'est une incohérence immédiate. Configurez systématiquement timezone_id et locale en cohérence avec le pays du proxy.

5. Trop de concurrence depuis la même IP

Akamai surveille le taux de requêtes par IP résidentielle. Si vous envoyez 1500 requêtes/seconde depuis une seule IP résidentielle, c'est incohérent avec un comportement humain. Limitez à 2-5 requêtes/seconde par session sticky, et parallélisez avec plusieurs sessions sur des IP différentes.

Où cette approche est appropriée

Les techniques décrites ici sont légitimes dans les contextes suivants :

• Monitoring de vos propres sites — tester que Bot Manager v2 protège correctement votre infrastructure.
• Recherche en sécurité — analyse académique des systèmes anti-bot, publication de CVE ou de rapports de recherche.
• Tests d'intrusion autorisés — dans le cadre d'un contrat d'audit avec le propriétaire du site.
• Collecte de données publiques légale — agrégation de prix, SERP tracking, recherche de marché, dans le respect des ToS et du RGPD.

Ces techniques ne sont jamais appropriées pour : création de comptes frauduleux, bypass de CAPTCHA pour scalping illégal, click fraud, contournement de paywalls, ou toute activité violant les ToS du site cible.

Points clés à retenir

Key Takeaways :

• Akamai Bot Manager v2 combine cookies _abck/ak_bmsc, télémétrie sensor.js/bmak, empreintes TLS/JA4/HTTP/2 et réputation IP en un score continu côté serveur.
• Un seul champ incohérent dans sensor_data (GPU, mémoire, timezone) invalide _abck et déclenche un challenge.
• En 2026, le key share post-quantum X25519MLKEM768 est attendu dans tout ClientHello Chrome 131+ — son absence est un signal de bot immédiat.
• Les proxies datacenter sont pré-notés comme bot par Akamai — seuls les proxies résidentiels et mobiles offrent un score de départ neutre.
• Utilisez des sticky sessions ProxyHat pour maintenir _abck valide pendant toute la durée d'une session d'automatisation.
• L'automatisation légitime (sécurité, monitoring, recherche) doit respecter CFAA, RGPD et ToS des sites cibles.

Pour aller plus loin, consultez notre tarification des proxies résidentiels, notre guide de web scraping, notre cas d'usage SERP tracking, la liste des localisations disponibles, et la documentation technique ProxyHat.