Temps de lecture : 18 min

Akamai Anti-Bot Version 3 en 2026 : comment fonctionne la détection qui met les scrapers en échec ?

40 milliards de robots traversent chaque jour la plateforme Akamai. Face à ce déluge, la protection Akamai Anti-Bot Version 3 ne se contente plus de vérifier votre adresse IP : elle analyse chaque mouvement de souris et chaque image rendue par votre GPU. Concrètement, la version 3 est devenue un mur pour les développeurs, les scrappeurs et les équipes SEO : délais dépassés, défis JavaScript, payload chiffré sensor_data illisible.

Dans cet article, je vous propose un audit technique complet de cette protection. Nous allons voir comment fonctionne sensor_data, à quoi sert le cookie bm_sz, pourquoi contourner Akamai exige une vraie stratégie, et comment protéger un site sans bloquer Googlebot. Soyons réalistes : il n’y a pas de baguette magique. Mais il y a des méthodes documentées, des limites à connaître et des choix d’architecture à faire.

Akamai Anti-Bot Version 3 : qu’est-ce qui change réellement ?

Akamai Anti-Bot Version 3 est un système de détection de bots qui exécute un script JavaScript appelé sensor.js. Ce script analyse plusieurs centaines de signaux du navigateur (rendu GPU, audio, WebRTC, souris) et génère un payload chiffré nommé sensor_data. Ce payload alimente un score de 0 à 100 qui décide de la réponse à envoyer au visiteur.

Cette définition paraît simple, mais la version 3 est beaucoup plus profonde que l’ancien Bot Manager. Dans les faits, le moteur v3 ne se limite plus à vérifier les en-têtes HTTP ou la réputation de l’adresse IP. Il construit une empreinte complète du navigateur et de l’humain derrière l’écran.

Pour comprendre l’enjeu, rappelons une statistique d’Akamai : plus de 60 % du trafic Web d’une organisation peut être généré par des bots (source : PRNewswire / Akamai Technologies, 2016). Cette proportion n’a fait qu’augmenter. Aujourd’hui, la plateforme Akamai annonce une visibilité sur plus de 40 milliards de robots par jour (source : page produit Bot Manager, 2026).

Ce qui change vraiment la donne, c’est la finesse de la décision. La v3 ne répond plus par un simple blocage ou une autorisation binaire. Elle calcule un score de confiance, puis laisse l’éditeur du site choisir le niveau de sévérité.

Du Bot Manager classique au moteur v3

Le Bot Manager classique utilisait un modèle à base de règles : liste noire, liste blanche, limites de débit. La v3 a introduit un moteur de machine learning qui apprend des signaux collectés en temps réel. Chaque visite devient une série de mesures comparées à des modèles de comportement humain ou automatisé.

Version	Payload généré	Niveau d’obfuscation	Difficulté de contournement
v1	paramètres simples	faible	faible
v2	paramètres chiffrés	moyen	moyenne
v3	sensor_data chiffré	élevé via JSScrambler	élevée

Les indices techniques d’une page protégée par Akamai v3

Vous pouvez identifier une page protégée sans outil complexe. Ouvrez la console développeur, onglet Réseau, et cherchez le script sensor.js. Si vous voyez aussi un cookie bm_sz et une requête vers un endpoint contenant sensor_data, le site utilise bien Akamai v3.

Définition : sensor_data est le payload chiffré généré par le navigateur après exécution de sensor.js. Il contient les mesures de l’environnement navigateur et du comportement utilisateur, puis il est envoyé à la plateforme Akamai pour calculer le score du visiteur.

Cette collecte de signaux est précisément le cœur de la v3. Voyons maintenant comment elle fonctionne dans le détail.

Comprendre sensor_data : le cœur technique de la version 3

Le script sensor.js dépasse souvent 50 Ko. Selon une analyse communautaire relayée par vhub_systems sur DEV Community, il analyse notamment le rendu GPU, le contexte audio et la pile WebRTC (2026). Ce script est volontairement obfusqué pour ralentir l’analyse humaine. Une fois injecté dans la page, il collecte des signaux passifs et actifs.

1. Le navigateur charge sensor.js.
2. Le script exécute des tests sur le rendu GPU, le contexte audio, WebRTC, canvas et d’autres API navigateur.
3. Les mesures sont chiffrées dans le payload sensor_data.
4. Le navigateur envoie sensor_data en POST ou via un paramètre de requête.
5. Akamai calcule un score de 0 à 100.
6. Le cookie bm_sz stocke un identifiant lié à la session et à l’empreinte.

Concrètement, Akamai Bot Manager a une visibilité sur plus de 40 milliards de robots par jour selon la page produit officielle (2026). Cette échelle explique pourquoi la détection doit être entièrement automatisée et capable de s’adapter en permanence.

Les signaux analysés par sensor.js

Le payload sensor_data ne contient pas une simple liste d’en-têtes. Il embarque des centaines de signaux, dont certains paraissent anodins. Le tableau ci-dessous résume les grandes familles de signaux utilisées par Akamai v3.

Signal	Type de donnée	Rôle dans la détection
Rendu GPU	performance WebGL	détecte les navigateurs automatisés sans interface
AudioContext	empreinte audio	crée une signature unique du navigateur
WebRTC	adresses IP locales	révèle la présence d’un proxy ou d’un NAT
Canvas	rendu texte et image	aide à distinguer les navigateurs réels des moteurs simplifiés
Événements souris	biométrie comportementale	mesure la fluidité et la trajectoire du curseur

Le cookie bm_sz est souvent présenté comme un simple traceur. Dans les faits, il stocke un hash qui associe la session à l’empreinte du navigateur. Il permet à Akamai de relier la requête sensor_data à la session HTTP en cours et de conserver une mémoire du défi JavaScript.

Du score bot à la réponse : Cautious, Strict, Aggressive

Le score Akamai se lit simplement : plus il est bas, plus la requête ressemble à un bot. En dessous d’un seuil configurable, Akamai peut répondre par un défi JavaScript, un blocage ou une page d’attente. Au-dessus, le trafic est autorisé.

Dans la console Bot Manager, l’administrateur définit trois niveaux de réponse. Le niveau Cautious observe sans bloquer. Le niveau Strict applique des défis aux scores moyens. Le niveau Aggressive bloque immédiatement les scores faibles. Chaque site peut appliquer un niveau différent selon la page concernée.

Astuce : pour repérer Akamai v3, ouvrez les outils développeur, onglet Réseau, rechargez la page et cherchez sensor_data dans les requêtes. Si le cookie bm_sz apparaît dans l’onglet Application, la protection est active.

Comprendre cette mécanique est essentiel avant de parler contournement. Passons maintenant aux méthodes réellement documentées en 2026.

Contourner Akamai Anti-Bot Version 3 : méthodes et limites en 2026

La question « comment contourner Akamai anti-bot » est très active. Je comprends pourquoi : un formulaire bloqué, une collecte de données légitime interrompue, un test produit impossible. Mais soyons réalistes : la v3 ne se contourne pas avec une simple requête Python.

Avant d’écrire la moindre ligne de script, vérifiez que le site utilise bien Akamai v3. Voici cinq indices rapides.

• Présence d’un cookie nommé bm_sz.
• Requête visible vers sensor_data dans la console réseau.
• Script externe nommé sensor.js.
• Réponse 403 ou page de défi JavaScript après quelques secondes.
• Comportement différent entre un navigateur normal et un outil HTTP classique.

Reproduire une empreinte TLS et HTTP cohérente

Le premier obstacle est l’empreinte TLS. Akamai compare le handshake TLS de votre client à celui des navigateurs connus. Un script Python utilisant la bibliothèque requests envoie une signature TLS différente de Chrome, Safari ou Firefox. Même si vous copiez les en-têtes HTTP, la signature TLS reste visible.

C’est là que curl-cffi est utile : il imite l’empreinte TLS de Chrome. Concrètement, vous pouvez faire une requête qui ressemble à un vrai navigateur au niveau du protocole. Le hash JA3 ou JA4, qui identifie cette empreinte, devient alors plus proche de celui d’un navigateur légitime.

Mais cela ne suffit pas. Akamai attend ensuite un sensor_data cohérent avec la session. Si le payload est manquant, vide ou invalide, le score de confiance reste faible.

Utiliser des proxies résidentiels pour éviter les blocages IP

Le deuxième obstacle est la réputation de l’adresse IP. Les IP de datacenter sont souvent déjà blacklistées. Les proxies résidentiels passent par des adresses appartenant à des fournisseurs d’accès grand public. Cela augmente les chances de passer les contrôles de réputation.

Attention toutefois : un proxy résidentiel ne remplace pas une empreinte navigateur cohérente. En 2026, le meilleur proxy résidentiel pour Akamai v3 est celui qui propose des adresses fraîches, peu utilisées et géographiquement proches de la cible. La qualité du pool compte plus que la vitesse brute.

Les risques techniques, éthiques et juridiques du contournement

Le contournement d’Akamai v3 peut violer les CGU du site et les lois applicables. Même si votre intention est de récupérer des données publiques, l’accès automatisé peut être interdit par les conditions d’utilisation. Dans certaines juridictions, la violation de mesures techniques de protection entraîne des sanctions civiles ou pénales.

Avertissement : le contournement peut violer les CGU et enfreindre la loi selon la juridiction et l’usage. Je déconseille toute utilisation en production sans validation juridique.

Un contournement n’est jamais garanti non plus. Akamai met à jour ses mécanismes fréquemment. La meilleure approche reste donc l’analyse et la compréhension, pas la course au bypass permanent.

Outils open source pour décrypter et analyser sensor_data

Pour comprendre la mécanique Akamai v3, la communauté sécurité a publié plusieurs outils open source. Ce sont des postes d’observation, pas des clés de contournement magiques. Leur intérêt principal est de rendre lisible un payload volontairement opaque.

Décrypter le payload avec Node.js

Le projet akamai-sensordata-decrypt permet de déchiffrer le payload à partir des paramètres collectés. Vous pouvez ainsi visualiser quels signaux sont envoyés et comment ils sont encodés. C’est un excellent point de départ pour un audit de sécurité ou une recherche universitaire.

Explorer la VM Akamai et désobfusquer JSScrambler

Akamai exécute une partie de sa logique dans une machine virtuelle JavaScript. Les projets akamai-vm-reverse et akamai-drm-deobf explorent cette VM. JSScrambler, l’outil d’obfuscation utilisé par Akamai, est l’une des cibles principales. Désassembler cette VM demande du temps, mais permet de comprendre les transformations appliquées au payload sensor_data.

Pourquoi ces outils ne sont pas des solutions magiques

La protection évolue souvent. Un payload qui fonctionne aujourd’hui peut devenir invalide demain. Akamai déploie des modifications côté serveur sans prévenir. Les outils open source sont donc des terrains de recherche, pas des béquilles de production.

Outil	Fonction	Stack	Usage recommandé
akamai-sensordata-decrypt	déchiffre sensor_data	Node.js	analyse de recherche
akamai-vm-reverse	explore la VM JavaScript	Python / JavaScript	comprendre l’obfuscation
akamai-drm-deobf	désobfusque JSScrambler	JavaScript	laboratoire de sécurité
akamai-sensor	génère un payload sensor cohérent	Node.js	tests sur site autorisé
Akamai Tools Web App	interface web de parsing	Web	vue d’ensemble rapide

Conseil : utilisez ces outils uniquement sur des sites dont vous possédez les droits ou dans un laboratoire de recherche dédié. Le but est de comprendre, pas de lancer un scraping massif.

Après cette plongée dans l’écosystème open source, il est temps de comparer Akamai v3 à son principal concurrent.

Akamai v3 ou Cloudflare : comparatif anti-bot 2026

On me demande souvent quelle est la différence entre Akamai et Cloudflare pour stopper les bots. La réponse dépend du besoin. Cloudflare s’appuie beaucoup sur le handshake TLS et des cookies de vérification. Akamai v3 ajoute une couche d’analyse JavaScript et comportementale beaucoup plus lourde.

Différences d’architecture de détection

Chez Cloudflare, le trafic transite par le réseau edge. Une partie de la décision est prise au niveau du handshake TLS et des cookies comme cf_clearance. Chez Akamai, le script sensor.js tourne dans la page et envoie un payload chiffré. Ce n’est pas la même philosophie.

Akamai mise sur la finesse comportementale et la profondeur de l’empreinte. Cloudflare mise sur la répartition mondiale, la rapidité et la simplicité de mise en œuvre. Dans les faits, un site protégé par Akamai v3 demande plus d’investissement en configuration, mais offre une granularité plus fine.

Critère	Akamai v3	Cloudflare
Empreinte principale	sensor.js + sensor_data	TLS + cookies
Script dédié	sensor.js 50 Ko+	défi JS / Turnstile
Difficulté de contournement	élevée	moyenne à élevée
Coût	échelle entreprise	accessible
Transparence	faible	moyenne

Critères de choix selon le type de site

Pour un site vitrine avec peu de données sensibles, Cloudflare est souvent suffisant. Pour une application à forte valeur ajoutée, un formulaire critique ou une API publique, Akamai v3 apporte une protection plus fine. Le coût, la volumétrie et la performance sont les vrais critères de décision.

Ce comparatif reste théorique tant qu’on ne regarde pas des cas concrets. Voici trois situations où Akamai v3 fait échouer une automatisation.

Études de cas : quand Akamai v3 fait échouer une automatisation

Les exemples qui suivent sont inspirés de retours documentés et de mon expérience sur le terrain. Ils montrent pourquoi un diagnostic rapide est essentiel.

Le cas du formulaire automatisé

Un développeur voulait remplir un formulaire de devis sur un site protégé. Son script Python remplissait les champs, cliquait sur envoyer, puis restait bloqué sans message d’erreur. Je me souviens de son diagnostic : après trois heures de débogage, il a ouvert la console réseau et découvert sensor_data dans les requêtes.

Le site n’était pas en panne : il exécutait un défi anti-bot invisible. La solution demandait bien plus qu’un simple remplissage : il fallait générer un sensor_data valide et maintenir le cookie bm_sz tout au long de la session.

Le cas du scraper Scrapy qui dépasse le délai

Un scraper Scrapy lancé sur des milliers de pages commençait bien, puis chaque requête dépassait le délai. Symptôme typique : les premières URL passent, puis Akamai commence à envoyer des défis JavaScript. Le robot reçoit du HTML contenant du code de challenge au lieu des données attendues.

Il ne sait pas exécuter JavaScript. Résultat : délais dépassés et téléchargements incomplets. Ce cas est devenu un classique des problèmes Akamai anti-bot rencontrés sur Scrapy.

Le cas du SDK Akamai dans une application mobile

Sur Android, des équipes ont extrait le SDK Akamai Bot Manager d’une application comme celle d’Aldi au Royaume-Uni. Le SDK embarque une version spécifique de la protection, avec un payload propre à l’application. Analyser ce SDK est possible, mais chaque mise à jour de l’application peut changer le comportement.

Dans les faits, c’est un travail de réingénierie permanent, souvent trop lourd pour un simple besoin de collecte de données.

Pour vérifier si Akamai est la cause d’un délai dépassé, suivez ces étapes.

• Ouvrez la console réseau.
• Cherchez une requête vers sensor_data.
• Vérifiez la présence du cookie bm_sz.
• Regardez si la réponse contient un script de défi.
• Testez la même URL dans un navigateur normal.

Ces symptômes sont évitables si la protection est bien réglée. C’est ce que nous allons voir côté SEO.

Akamai v3 et SEO : protéger son site sans bloquer les bons robots

Akamai v3 bloque-t-il le Googlebot ? Pas si Bot Manager est correctement configuré. Akamai peut autoriser les robots légitimes en vérifiant le user-agent, la réputation IP et le reverse DNS de Googlebot. Une mauvaise configuration peut toutefois bloquer Googlebot et dégrader le référencement.

Cette question est devenue stratégique avec l’essor des bots d’IA et des crawlers SEO. L’objectif est de laisser passer les bons robots tout en bloquant les menaces. C’est un équilibre entre sécurité et performance.

Configurer les règles pour les user-agents légitimes

Dans Bot Manager, vous pouvez créer des règles qui identifient Googlebot, Bingbot ou vos propres robots de surveillance. Le plus sûr est de conserver une stratégie Cautious pour eux, avec une vérification DNS. Ainsi, le budget de crawl n’est pas gaspillé dans des défis JavaScript inutiles.

Si votre bot de monitoring est bloqué, ajoutez son user-agent à la liste blanche, utilisez une IP fixe documentée et vérifiez que votre bot sait exécuter les défis JavaScript le cas échéant. Cette configuration évite les faux positifs.

Mesurer l’impact de la protection sur le crawl

Surveillez les logs de crawl depuis Google Search Console. Si Googlebot reçoit beaucoup de réponses 403, 429 ou des défis JavaScript, le référencement peut en souffrir. Réduisez le niveau de sévérité pour les user-agents connus et testez chaque changement avec l’outil d’inspection d’URL.

Segment de réponse	Exemple d’action	Effet sur le référencement
Cautious	défi JavaScript limité	impact faible si Googlebot reconnu
Strict	défis et vérifications	risque de dégradation si mal configuré
Aggressive	blocage immédiat	risque fort

Bonnes pratiques : configurez le Bot Score par segment, ne bloquez pas les robots connus avant de vérifier leur DNS, et gardez un niveau de protection adapté aux pages sensibles uniquement.

Bien configurer Akamai demande donc une vraie collaboration entre équipe sécurité et équipe SEO.

Questions fréquentes

Qu’est-ce que la version 3 de l’anti-bot Akamai ?

La version 3 est un moteur de détection qui exécute sensor.js dans le navigateur, génère un payload chiffré nommé sensor_data et calcule un score de confiance de 0 à 100. Plus le score est faible, plus le visiteur est considéré comme un bot.

Comment détecter si un site utilise Akamai Anti-Bot Version 3 ?

Ouvrez les outils développeur du navigateur, onglet Réseau, et cherchez sensor_data, bm_sz ou sensor.js. Ces marqueurs sont typiques de la protection Akamai v3.

Peut-on contourner Akamai Anti-Bot Version 3 ?

Oui, mais c’est difficile et fragile. Il faut reproduire une empreinte TLS cohérente, gérer le payload sensor_data et utiliser des proxies résidentiels. Les mises à jour de la protection cassent régulièrement les méthodes existantes.

Quelle est la différence entre Akamai Anti-Bot Version 2 et Version 3 ?

La version 3 renforce l’obfuscation du code, chiffre sensor_data et ajoute une analyse comportementale plus fine grâce au machine learning. La v2 reposait davantage sur des règles et des signatures.

Qu’est-ce que le cookie bm_sz chez Akamai ?

C’est un cookie de suivi posé par Akamai. Il stocke un hash lié à la session et à l’empreinte du navigateur, et il est souvent associé à sensor_data dans le processus de validation.

Akamai bloque-t-il le Googlebot ?

Pas si Bot Manager est bien configuré. Akamai peut vérifier les user-agents et le DNS des robots légitimes. Une configuration trop stricte peut cependant bloquer Googlebot et dégrader le SEO.

Quels outils existent pour analyser sensor_data Akamai ?

Des modules open source comme akamai-sensordata-decrypt, akamai-vm-reverse ou le service Akamai Tools permettent de décrypter et d’analyser le payload à des fins de recherche.

En résumé : comment aborder Akamai Anti-Bot Version 3 en 2026

La protection anti-bot version 3 d’Akamai n’est pas un simple pare-feu. C’est un système complet qui analyse le navigateur, le comportement humain, la réputation IP et l’empreinte TLS. Pour les développeurs, cela change la donne : un script ne suffit plus, il faut construire une session cohérente.

Pour les équipes SEO, le sujet est tout aussi stratégique. Une protection mal configurée peut dégrader le budget de crawl et faire chuter un site dans les résultats de recherche. Ce qui change vraiment la donne, c’est de considérer Akamai v3 comme un système à paramétrer, pas comme un ennemi à abattre.

• Détecter : identifiez sensor_data et bm_sz avant toute automatisation.
• Comprendre : analysez le payload, le score et les stratégies Cautious, Strict et Aggressive.
• Tester : utilisez curl-cffi et des proxies résidentiels uniquement sur des sites autorisés.
• Documenter : gardez une trace des versions et des changements de comportement.
• Sécuriser : respectez le cadre légal et protégez aussi vos propres sites.

La vraie question n’est pas « comment contourner Akamai ? » mais « comment construire une automatisation qui respecte les signaux de confiance du web ? »