--- title: "Comment contourner Kasada en 2026" slug: how-to-bypass-kasada date: 2026-10-07T06:18:04+00:00 modified: 2026-10-07T06:18:06+00:00 permalink: https://brightdata.fr/blog/savoir-faire/how-to-bypass-kasada type: blog --- [ Blog ](https://brightdata.fr/blog "Blog") / [How Tos](https://brightdata.fr/blog/savoir-faire) [How Tos](https://brightdata.fr/blog/savoir-faire) # Comment contourner Kasada en 2026 Pourquoi le jeton x-kpsdk-ct de Kasada bloque les scrapers, ce que vérifie sa VM ips.js, et quand construire un solveur ou utiliser le Web Unlocker de Bright Data. 26 min de lecture [ ![Satyam Tripathi](https://media.brightdata.fr/2024/09/Satyam-Tripathi-50x50.png) ](https://brightdata.com/blog/authors/satyam-tripathi) [Satyam Tripathi Technical Writer ](https://brightdata.com/blog/authors/satyam-tripathi) ![How to Bypass Kasada](https://media.brightdata.fr/2026/10/How-to-Bypass-Kasada-in-2026.png) Si votre scraper reçoit un code HTTP 429 ou 403 avec des en-têtes `x-kpsdk-*`, Kasada le bloque, et la réponse n’explique pas pourquoi. Kasada est une plateforme anti-bot qui protège les sites web, les API et les applications mobiles contre le trafic automatisé. Elle exécute un défi JavaScript obfusqué dans le navigateur, évalue le client, et émet un jeton à courte durée de vie que chaque requête ultérieure doit inclure. Pour contourner Kasada, vous devez d’abord savoir ce que ce script de défi vérifie. J’en ai analysé un réel, et ce que j’ai trouvé détermine si vous devez construire un solveur ou en acheter un. ## TL;DR - Kasada nécessite un jeton valide : `x-kpsdk-ct` provient uniquement de la complétion de son défi JavaScript, donc l’usurpation TLS seule ne peut pas le franchir. - Le défi change à chaque requête : c’est une machine virtuelle personnalisée, donc un solveur copié cesse de fonctionner en quelques heures. - Les navigateurs automatisés laissent des signaux : une configuration par défaut expose `navigator.webdriver`, un user agent `HeadlessChrome`, et des noms de frameworks d’automatisation que Kasada peut détecter. - Vous pouvez construire ou acheter : maintenir un solveur est un travail continu, tandis que le Web Unlocker de Bright Data exécute le défi pour vous et facture par requête réussie. ## Comment confirmer qu’un site utilise Kasada Un 403 ou 429 vous indique que quelque chose a bloqué la requête. Il ne vous indique pas quel système l’a fait, et cette réponse détermine tout ce que vous faites ensuite. Cloudflare, DataDome, Akamai et Kasada renvoient tous les mêmes codes de statut, donc le code seul ne peut pas identifier le système. Les en-têtes et cookies de chaque fournisseur l’identifient, et vous pouvez les lire avec 1 requête : ```none curl -sI https://target.example/ | grep -i \ -e '^x-kpsdk' -e '^set-cookie: kp_uidz' \ -e '^cf-ray:' -e '^set-cookie: __cf_bm' -e '^server: cloudflare' \ -e '^x-datadome' -e '^set-cookie: datadome' \ -e '^server: akamaighost' -e '^set-cookie: _abck' ``` Faites correspondre à partir du début de la ligne d’en-tête (c’est ce que fait le `^`), et non n’importe où dans la ligne. Un `grep -i akamai` large correspond aussi à des en-têtes non liés qui contiennent un nom d’hôte CDN, comme la Content-Security-Policy de la page, et renvoie des faux positifs. Chaque système a une signature différente. La ligne Kasada provient de ma propre capture, et les autres lignes proviennent de la documentation publique de chaque fournisseur : Ce que contient la réponseLe système estEn-têtes `x-kpsdk-*` et un cookie `KP_UIDz`, plus un script `ips.js` qui définit `window.KPSDK`KasadaEn-tête `cf-ray`, cookie `__cf_bm`, `server: cloudflare`CloudflareEn-tête `x-datadome` et un cookie `datadome`DataDome`server: AkamaiGHost` sur une réponse bloquée, ou un cookie `_abck` sur une réponse autoriséeAkamaiSi vous voyez un en-tête `x-kpsdk-*`, le système est Kasada. Si vous voyez l’un des autres, les étapes spécifiques à Kasada qui suivent ne s’appliquent pas, et les guides de Bright Data pour [contourner Cloudflare](/blog/web-data/bypass-cloudflare) et [la détection de bots Akamai](/blog/web-data/bypass-akamai-bot-detection) couvrent ces systèmes. ## Ce que Kasada vérifie avant d’accorder l’accès à un client Kasada ne repose pas sur un seul signal. Il utilise plusieurs couches, et une requête doit toutes les franchir pour recevoir un jeton. Comprendre les couches explique pourquoi une solution qui fonctionne contre un système plus simple n’a aucun effet ici. La première couche est la réputation de l’IP. Kasada vérifie la réputation de l’adresse IP et de son numéro de système autonome (le réseau auquel appartient l’adresse). Une plage d’IP de centre de données déjà utilisée par de nombreux scrapers a une mauvaise réputation avant même que vous n’envoyiez un seul en-tête. Les adresses IP résidentielles provenant de vrais FAI grand public ont une meilleure réputation, car de vrais utilisateurs se connectent depuis ces mêmes réseaux. La deuxième couche est l’empreinte TLS. Kasada lit la négociation TLS et les paramètres HTTP/2, puis les compare à ce qu’un vrai navigateur envoie. Un client Python par défaut propose des suites de chiffrement et des extensions dans un ordre qu’aucun navigateur n’utilise, donc l’empreinte ne correspond pas au user agent qu’il prétend être. [Comment fonctionne l’empreinte TLS](/blog/web-data/tls-fingerprinting) couvre cela plus en détail. La troisième couche est le défi JavaScript. Kasada envoie un script obfusqué à votre client et vérifie ce qu’il renvoie. Le script construit une empreinte du runtime, exécute un calcul de preuve de travail (un puzzle que le client doit résoudre), et combine les deux en un paquet chiffré. La quatrième couche est le cycle de vie du jeton, que j’ai déduit du fonctionnement du protocole sans le capturer directement, et la cinquième est l’analyse comportementale, que je n’ai pas testée. Une bonne IP et une négociation TLS correspondante ne satisfont que les couches 1 et 2, donc les sections ci-dessous se concentrent sur les couches 3 et 4. Dans l’ordre où une requête les traverse, les couches se présentent ainsi : ![Diagramme des couches de détection de Kasada qu'une requête doit franchir pour recevoir un jeton, de la réputation IP à l'analyse comportementale.](https://media.brightdata.com/2026/10/Hyceka1sMx.png)## Comment fonctionne le défi ips.js de Kasada Le défi ips.js est une machine virtuelle personnalisée, donc lire le script ne montre pas ce qu’il vérifie. Pour le voir directement, j’ai demandé une page protégée par Kasada et lu la réponse. La cible était un site immobilier public, et la réponse était un 429 plutôt que la page. ### La réponse 429 et le script ips.js La réponse incluait les en-têtes Kasada et un petit corps HTML qui démarre le défi : ```none HTTP/2 429 x-kpsdk-r: 1-AA x-kpsdk-ct: content-type: text/html; charset=utf-8 access-control-expose-headers: x-kpsdk-ct,x-kpsdk-r,x-kpsdk-c,x-kpsdk-h,x-kpsdk-fc set-cookie: KP_UIDz-ssn= ``` Vous pouvez voir les mêmes en-têtes vous-même dans Chrome DevTools, sur la première requête dans l’onglet Network (l’entrée rouge en haut de la liste) : ![Panneau Headers de DevTools pour la réponse 429, montrant x-kpsdk-ct, x-kpsdk-r et les cookies KP_UIDz avec les valeurs masquées.](https://media.brightdata.com/2026/10/Hyef1a1jfx.png)Le 429 est le défi lui-même, pas une limite de débit, et il inclut un jeton initial et une balise script. Le corps définit un objet `window.KPSDK` et charge le script de défi depuis un chemin unique à chaque site protégé : ```none ``` Dans DevTools, tout l’échange apparaît comme le document 429 suivi du script qu’il charge, et la colonne Initiator relie le script à ce document : ![Liste Network de DevTools avec un document renvoyant le statut 429, puis le script ips.js renvoyant 200, lancé par ce document.](https://media.brightdata.com/2026/10/rkkXJaJoze.png)Le script, `ips.js`, est un fichier de 641 Ko avec presque tout son code sur 1 ligne. Ouvert dans un éditeur de texte, il est illisible : ![Le script de défi ips.js dans un éditeur de texte, montrant du code minifié sans noms de fonctions ou de variables lisibles.](https://media.brightdata.com/2026/10/ryNEy6yjfe.png)Il n’y a pas de noms lisibles pour les vérifications, pas de chaîne `navigator.webdriver`, et pas de fonction appelée `detectHeadless`. Tout le programme est une machine virtuelle (VM) personnalisée avec sa logique compilée en bytecode, donc le code source que vous pouvez lire est l’interpréteur, et les vérifications restent cachées dans le bytecode. ### Décoder le bytecode et la table des chaînes Pour regarder à l’intérieur de l’interpréteur, j’ai exécuté son étape de décodage dans un processus Node.js isolé et affiché ce qu’il produisait. Le résultat montre la taille réelle du programme : ```none BYTECODE len: 268444 STRING POOL len: 38459 ``` Donc la charge utile est un programme en bytecode plus une table de chaînes (la ligne `STRING POOL`), tous deux décodés au moment de l’exécution à partir d’une grande chaîne au début du script. Comme le programme se décode lui-même à l’exécution, les chaînes que vous chercheriez n’existent pas tant que la VM ne les construit pas pendant son exécution. Récupérez à nouveau le même script et les tailles changent. Dans 3 requêtes consécutives supplémentaires vers la même URL, le programme décodé comptait 266 322, 275 713 et 266 322 entrées de bytecode. Différentes parties changent selon des calendriers différents. Une fenêtre de 5 heures contrôle la clé qui décode le contenu reçu par une requête. Le contenu lui-même, c’est-à-dire le remplissage et les valeurs stockées dans le script, change aléatoirement à chaque réponse, indépendamment de cette clé. Donc une copie sauvegardée échoue pour deux raisons : sa clé expire, et chaque nouvelle récupération a un contenu différent. ### Pourquoi une copie sauvegardée du script cesse de fonctionner Quelques propriétés du décodeur comptent si vous prévoyez de construire un solveur à partir d’une copie sauvegardée du script. D’abord, la clé dépend de l’heure actuelle. Le décodeur la dérive de `Math.round(Date.now() / 18000081)`, et `18000081` millisecondes correspondent à presque exactement 5 heures. Quand j’ai avancé l’horloge système au-delà de cette fenêtre et relancé le décodage, il a renvoyé un programme vide : ```none 0h -> bytecode len 268444, pool len 38459 6h -> bytecode len 0, pool len undefined ``` Le décodeur accepte une clé d’environ 1 fenêtre temporelle avant ou après la fenêtre actuelle, donc la durée pendant laquelle un script sauvegardé reste fonctionnel dépend du moment de sa fenêtre où vous l’avez capturé. Dans ma reprise à 6 heures d’avance, il ne renvoyait déjà plus rien, donc un script sauvegardé reste utile pendant quelques heures, pas une journée. Ensuite, la charge utile vérifie sa propre intégrité. Quand j’ai échangé 2 caractères dans l’alphabet de 72 caractères utilisé par le décodeur, tout le programme a échoué à se décoder plutôt que de produire une sortie incorrecte. Un vérificateur dans la boucle de décodage maintient une somme de contrôle courante et s’arrête si un octet a été modifié. Rien de tout cela ne vous donne du code valant la peine d’être copié. Le défi est polymorphe (il change à chaque récupération), donc la logique que vous copiez d’1 capture ne continuera pas à fonctionner longtemps. Un solveur qui récupère le script à nouveau évite la copie obsolète, mais il doit ensuite décoder un contenu différent sous une nouvelle clé à chaque exécution, ce qui constitue le travail de maintenance décrit dans la section construire ou acheter. Les chiffres ci-dessus proviennent d’1 site protégé et d’1 exécution, et Kasada peut en modifier n’importe lequel dans une version ultérieure. Ce qui s’applique aux autres sites, c’est la conception. Le script se vérifie lui-même, la clé dépend de l’heure, et la preuve de travail est liée à l’empreinte. ## Pourquoi le jeton, et non la preuve de travail, bloque les scrapers La preuve de travail est légère pour un vrai navigateur et peu coûteuse à vérifier pour le serveur, donc elle n’est pas assez coûteuse pour bloquer l’automatisation par le coût seul. Le jeton est ce qui bloque un scraper, car Kasada n’en émet un valide que pour un résultat provenant d’une exécution complète de la VM, et la preuve de travail n’est qu’une partie de ce résultat. La preuve de travail exige que le client exécute la VM. La VM calcule la preuve et collecte l’empreinte, puis combine les deux en 1 paquet chiffré. Le script vérifie sa propre intégrité pendant qu’il se décode, donc un client doit exécuter la VM et laisser l’empreinte fonctionner normalement pour renvoyer un résultat valide. Calculer la preuve sur un serveur et attacher une empreinte séparée n’aide pas, car Kasada n’accepte un jeton que d’1 exécution complète de la VM. Ce flux se termine par un jeton. Je n’ai pas capturé cet échange directement, donc ce qui suit est déduit du fonctionnement du protocole. Le client renvoie le paquet chiffré avec une requête POST, et si elle réussit, Kasada remplace la valeur initiale de `x-kpsdk-ct` par une valeur valide qui accorde l’accès. Chaque requête ultérieure doit inclure ce jeton dans son en-tête et son cookie, et le jeton expire. Comme le jeton expire, un scraper doit répéter l’échange pour en obtenir un nouveau. Du premier 429 à un jeton valide, l’échange entre client et serveur se présente ainsi : ![Diagramme de séquence de l'échange de jeton Kasada, du 429 initial à travers la preuve de travail de la VM jusqu'à un jeton d'accès valide.](https://media.brightdata.com/2026/10/H1SH1pkjGe.png)Le jeton diffère aussi entre les réponses. Sur 3 requêtes consécutives, le même 429 de Kasada a renvoyé 3 valeurs différentes de `x-kpsdk-ct`, donc le jeton n’est pas une valeur fixe que vous pouvez capturer une fois et renvoyer. ## Comment Kasada détecte les navigateurs headless Si la VM a besoin d’un runtime qui se comporte comme un vrai navigateur, la démarche évidente est d’automatiser un vrai navigateur. Cela fonctionne mieux qu’un client HTTP, mais un navigateur automatisé par défaut envoie encore des signaux, et la table de chaînes décodée contient les noms que Kasada recherche. ### Signaux dans un navigateur headless par défaut Un Chromium headless non modifié montre qu’il est automatisé. J’en ai lancé un avec Playwright et lu les propriétés du navigateur que la charge utile vérifie : ```none # pip install playwright, si vous ne l'avez pas déjà from playwright.sync_api import sync_playwright with sync_playwright() as p: page = p.chromium.launch().new_page() print(page.evaluate("[navigator.webdriver, navigator.userAgent, navigator.plugins.length, window.chrome]")) ``` Les valeurs qu’il affiche, présentées ici une par ligne : ```none navigator.webdriver true userAgent ...HeadlessChrome/ Safari/537.36 navigator.plugins 0 (un vrai navigateur avec interface en liste plusieurs) window.chrome null (présent sur un Chrome de bureau normal) ``` Chaque ligne est un signal. `navigator.webdriver` vaut `true` sous automatisation et `false` sur un navigateur normal. La chaîne du user agent contient `HeadlessChrome`. La liste des plugins est vide, et l’objet `window.chrome` qu’un Chrome de bureau expose est absent. Vous pouvez masquer ces signaux, mais la manière dont vous les masquez compte quand la cible est Kasada. Un Playwright modifié en mode furtif change ces propriétés avec du JavaScript après le démarrage du navigateur, donc une vérification conçue pour trouver de telles substitutions peut quand même les détecter. Une construction au niveau source, comme le [fork Firefox Camoufox](/blog/web-data/web-scraping-with-camoufox) ou un Chromium modifié comme BotBrowser, change les valeurs dans le code C++ propre du navigateur avant qu’aucun script ne s’exécute. Cela ne laisse aucune substitution JavaScript que la vérification pourrait trouver. Une version obsolète de Chrome est également un signal, car sa version ne correspond pas à ce que les vrais utilisateurs exécutent. Mais mettre à jour le navigateur ne supprime pas les propres signaux du framework d’automatisation. ### Signaux des frameworks d’automatisation Playwright laisse des noms dans la page qu’un navigateur normal n’a pas. Quand j’ai ajouté une seule liaison à une page Playwright, elle a créé ces variables globales : ```none from playwright.sync_api import sync_playwright with sync_playwright() as p: page = p.chromium.launch().new_page() page.expose_binding("demo", lambda source: None) print([k for k in page.evaluate("Object.keys(window)") if "playwright" in k.lower()]) ``` Il affiche ces noms : ```none ['__playwright__binding__', '__playwright__binding__controller__'] ``` Les noms ci-dessus sont uniquement ce qu’une seule liaison crée. Séparément, j’ai recherché dans la table de chaînes décodée les noms de liaison internes de Playwright. Environ la moitié des noms de la version de Playwright que j’ai testée y apparaissaient sous forme de chaînes simples, aux côtés de `webdriver`, `HeadlessChrome` et `electron`. Les noms apparus sont ses liaisons d’enregistreur et de devtools. Un nom dans la table de chaînes décodée ne prouve pas que la VM agit dessus. Néanmoins, le fait de les y trouver montre que Kasada connaît ces outils par leur nom, donc il n’a pas besoin de deviner quelle bibliothèque d’automatisation il détecte. ### Détection CDP et les outils qui l’évitent Même sans liaison, le Chrome DevTools Protocol (CDP) que les frameworks d’automatisation utilisent pour contrôler le navigateur les expose. Un [article sur l’empreinte CDP](https://svebaa.github.io/personal/blog/cdp-fingerprinting/) a montré que l’appel à `Runtime.enable`, que Playwright et Puppeteer font par défaut, fait que le navigateur sérialise immédiatement (convertit en texte) les objets passés aux méthodes `console`. Un court script peut détecter cela sans mesures de timing, en passant un objet `Proxy` à un appel `console` : ```none let detected = false; const trap = new Proxy({}, { ownKeys() { detected = true; return []; } }); console.groupEnd(Object.create(trap)); // detected est true sur Chromium plus ancien quand un client CDP a appelé Runtime.enable ``` L’auteur a rapporté que la technique fonctionnait lors de sa publication, et je l’ai confirmée indépendamment sur des versions plus anciennes de Chromium, où l’extrait renvoie `true` sur une page Playwright par défaut car Playwright appelle `Runtime.enable` par défaut. Sur les versions plus récentes de Chromium que j’ai testées, le même extrait renvoie `false`, même après que j’appelle `Runtime.enable` moi-même, donc Chrome a changé sa façon de gérer les arguments de console. Testez-le sur votre propre version de navigateur avant de vous y fier. Une vérification comme celle-ci ne nécessite aucune permission ni extension, elle est donc peu coûteuse à exécuter pour un système anti-bot et difficile à remarquer pour vous. Une solution consiste à contrôler Chrome sans le code du framework qui appelle `Runtime.enable`. Des outils comme [nodriver](/blog/web-data/nodriver-web-scraping), son fork zendriver, et le CDP Mode de SeleniumBase communiquent directement avec Chrome via CDP et n’appellent jamais `Runtime.enable`. Des forks Playwright modifiés comme patchright corrigent le même problème à l’intérieur de Playwright. Sur l’ancienne version où l’extrait renvoyait `true` pour Playwright, il renvoyait `false` contre la page par défaut de zendriver, car aucun appel à `Runtime.enable` n’est jamais effectué. Chacun de ces outils aide, mais aucun n’est permanent, car le signal, la correction et la vérification de Kasada changent tous selon leurs propres calendriers, et le changement de navigateur ci-dessus en est un exemple. ## Scraper avec un client HTTP et ses limites De nombreuses équipes essaient de se passer entièrement du navigateur, pour une bonne raison. Un navigateur est lent et gourmand en ressources, et un client HTTP qui présente la bonne empreinte coûte bien moins cher par requête. La question est de savoir dans quelle mesure cette approche fonctionne contre Kasada. Vous pouvez passer la vérification d’empreinte TLS avec des bibliothèques comme `curl_cffi` en Python ou `surf` en Go, qui modifient la négociation TLS pour correspondre à un vrai navigateur. Pour vérifier cela, utilisez un service qui rapporte la négociation TLS qu’il reçoit. Il rapporte JA4, une empreinte calculée à partir de la négociation seule, et liste les paramètres HTTP/2 (que Kasada lit aussi) comme une empreinte séparée : ```none # pip install curl_cffi, si vous ne l'avez pas déjà from curl_cffi import requests as cf r = cf.get("https://tls.peet.ws/api/all", impersonate="chrome") print(r.json()["tls"]["ja4"]) # retirez impersonate= pour voir le JA4 du client par défaut à la place ``` Exécutez-le des deux façons et comparez. Voici les valeurs que j’ai obtenues, et les vôtres différeront à mesure que les navigateurs et bibliothèques se mettent à jour, donc vérifiez-les face à un vrai Chrome sur le même service : ```none curl_cffi impersonate="chrome" JA4=t13d1516h2_8daaf6152771_806a8c22fdea curl_cffi (sans impersonate) JA4=t13d2712h2_b4f9224df7c1_9ced094328c9 ``` Le client usurpé envoie un JA4 qui correspond à un vrai navigateur, tandis que le client par défaut envoie un JA4 qu’aucun navigateur n’utilise. Si vous figez une version de navigateur spécifique, le User-Agent continue de revendiquer cette version après que le vrai Chrome a été mis à jour, ce qui fait paraître votre client obsolète. Utiliser `impersonate="chrome"` à la place laisse la bibliothèque choisir la version de Chrome, donc vous n’avez pas à mettre à jour un numéro de version. Le [guide curl\_cffi](/blog/web-data/web-scraping-with-curl-cffi) montre la configuration complète. J’ai relancé l’extrait via un second service, `https://tls.browserleaks.com/json`, et le JA4 usurpé était identique. Il rapporte la valeur sous `r.json()["ja4"]`, donc cela fonctionne comme solution de repli si `tls.peet.ws` est inaccessible, ce qui s’est produit une fois depuis mon réseau. Le problème est que la négociation TLS n’est pas l’endroit où Kasada prend sa décision. Un client HTTP qui passe la vérification TLS reçoit quand même le défi, et il ne peut pas exécuter la VM. Pour obtenir un jeton avec une approche HTTP uniquement, vous devriez porter l’interpréteur, la collecte d’empreinte et la preuve de travail dans votre propre code, puis mettre à jour ce code à chaque modification de la charge utile. Des services de résolution spécialisés vendent exactement cela en tant qu’API, générant le jeton et la preuve de travail via HTTP. Dans les deux cas, vous payez un coût continu, qu’il s’agisse de votre propre maintenance ou d’un tarif par résolution, et le solveur doit s’adapter à chaque changement de charge utile. L’approche HTTP gère la vérification TLS rapidement et correctement, mais elle ne peut pas produire le jeton requis par Kasada. Un autre point affecte la façon dont vous décidez si une requête a réussi. [Le propre CTO terrain de Kasada a décrit](https://www.itnews.com.au/news/rea-group-mutates-site-scraping-credential-stuffing-defences-537873) l’approche qu’ils préfèrent. Au lieu de bloquer avec une erreur, ils servent une page qui semble correcte mais est fausse, de sorte que l’opérateur continue de croire que le bot fonctionne. Une réponse avec du contenu n’est pas toujours une réponse correcte, donc tout test contre Kasada doit comparer le contenu avec ce qu’un navigateur affiche, et non simplement vérifier que quelque chose a été renvoyé. ## Construire ou acheter pour Kasada Ensemble, l’analyse montre qu’un solveur que vous construisez vous-même n’est pas un problème difficile unique. C’est un travail de maintenance continu. Vous devriez maintenir tous les éléments suivants : - Un interpréteur de VM qui s’adapte à une charge utile auto-vérifiante et une clé qui tourne fréquemment - Un profil d’empreinte qui correspond aux vérifications changeantes de Kasada - Une gestion des jetons qui fonctionne quand un jeton expire pendant une session - Un pool de proxies avec une réputation suffisamment bonne pour passer la vérification de réputation IP Construire peut avoir du sens quand vous ciblez un seul site et avez des ingénieurs capables de maintenir le solveur à jour. Quand vous ciblez plusieurs sites ou ne pouvez pas dédier de temps d’ingénierie, un service géré retire ce travail de votre équipe. ### Web Unlocker pour les requêtes uniques Un service géré est l’alternative à l’embauche d’ingénieurs pour ce travail continu. Le [Web Unlocker de Bright Data](/products/web-unlocker) prend une URL cible et gère le défi, la session, et le choix de l’IP de sortie (l’adresse que voit la cible) pour vous, afin que votre code envoie 1 requête et lise le résultat : ```none curl -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{"zone":"YOUR_ZONE_NAME","url":"https://target.example/listing","format":"raw"}' \ https://api.brightdata.com/request ``` Remplacez les deux marqueurs par votre propre nom de zone et clé API, et définissez `url` sur votre propre cible, avant de l’exécuter. Les deux valeurs se trouvent dans l’onglet Overview de votre zone Web Unlocker. Le panneau d’accès direct à l’API liste votre clé et une requête prête à l’emploi incluant déjà votre nom de zone : ![Onglet Overview de la zone Web Unlocker avec le panneau d'accès direct à l'API, le champ de clé API, et une requête curl prête à l'emploi.](https://media.brightdata.com/2026/10/ryYL16kjMx.png)Pour voir un appel réussir avant de l’utiliser sur une cible réelle, l’onglet Playground de la zone exécute la même requête contre l’URL de test de Bright Data et affiche la réponse : ![Onglet Playground du Web Unlocker montrant une réponse 200 avec un court corps JSON pour une URL de test.](https://media.brightdata.com/2026/10/H1XvJpkiMl.png)Un appel réussi renvoie le corps de la page débloquée. Web Unlocker facture par requête réussie, et son niveau gratuit inclut 5 000 requêtes par mois sans carte de crédit requise, donc vous pouvez l’essayer contre votre propre cible. La résolution Kasada est intégrée, comme décrit sur la [page du solveur Kasada de Bright Data](/products/web-unlocker/captcha-solver/kasada). Les plans et tarifs actuels se trouvent sur la [page de tarification Web Unlocker](/pricing/web-unlocker). Des champs de requête optionnels vous permettent de choisir le pays de sortie avec `country` et de charger les pages nécessitant du JavaScript avec `render`, tous deux listés dans la [référence API](https://docs.brightdata.com/api-reference/rest-api/unlocker/unlock-website). Pour les sites plus difficiles, activez l’option de domaines premium dans l’onglet Configuration de la zone pour ajouter les ressources supplémentaires dont ces sites ont besoin : ![L'onglet Configuration d'une zone Web Unlocker Bright Data, avec le commutateur de domaines premium activé.](https://media.brightdata.com/2026/10/BkkdkaJsGx.png)### API Browser pour les pages interactives Quand la cible nécessite une interaction complète avec la page, comme un flux de connexion ou une recherche en plusieurs étapes, l’[API Browser](/products/scraping-browser) exécute un navigateur géré auquel vous vous connectez. Playwright et Puppeteer le contrôlent via CDP. L’URL de connexion contient votre ID client, le nom de zone, et le mot de passe de zone, et l’onglet Overview de la zone les liste tous sous Détails d’accès : ![Onglet Overview de la zone API Browser avec le panneau Détails d'accès, le mot de passe masqué, et l'URL de connexion wss.](https://media.brightdata.com/2026/10/Hy8FyTkszg.png)Après avoir saisi ces valeurs, elle se connecte comme n’importe quel navigateur distant : ```none # pip install playwright, si vous ne l'avez pas déjà from playwright.sync_api import sync_playwright CDP = "wss://brd-customer-CUSTOMER_ID-zone-ZONE_NAME:[email protected]:9222" with sync_playwright() as p: browser = p.chromium.connect_over_cdp(CDP) page = browser.new_page() page.goto("https://target.example/search") page.wait_for_selector("YOUR_CONTENT_SELECTOR") # remplacez par un sélecteur pour le contenu dont vous avez besoin print(page.title()) browser.close() ``` Quand vous vous connectez de cette façon, le déblocage intégré de l’API Browser gère le défi Kasada, donc votre script fonctionne avec une page ordinaire. Attendez le contenu dont vous avez besoin avec un sélecteur, et utilisez ce contenu, et non un code de statut, pour confirmer le succès. L’API Browser prend aussi en charge Selenium, et pour une cible Kasada, commencez par la connexion CDP montrée ci-dessus. L’onglet Overview de la zone renvoie aussi vers un playground en direct et un débogueur Chrome DevTools, afin que vous puissiez observer une session pendant que vous construisez. Les tarifs actuels de l’API Browser figurent sur sa [page de tarification](/pricing/scraping-browser). Pour les pages plus simples, une requête Web Unlocker unique est l’option la plus rapide, et les [techniques anti-blocage standard](/blog/web-data/web-scraping-without-getting-blocked) couvrent les cas restants. ## Agents IA et bots vérifiés Kasada continue d’évoluer, et le trafic des agents IA change ce qu’il doit détecter. Il a lancé [AI Agent Trust](https://www.kasada.io/blog/kasada-launches-ai-agent-trust-to-secure-agentic-commerce), un produit qui gère le trafic des agents IA. Il classe les agents selon leur capacité à prouver leur identité, et permet à un site d’autoriser certains agents et d’en bloquer d’autres. L’identification des agents repose sur une norme appelée Web Bot Auth. Elle permet à un bot de prouver son identité à chaque requête, en utilisant les signatures de message HTTP (définies dans la [RFC 9421](https://www.rfc-editor.org/info/rfc9421/)), un en-tête signé, et un répertoire de clés publié. Le [groupe de travail de l’Internet Engineering Task Force (IETF)](https://datatracker.ietf.org/wg/webbotauth/documents/) maintient les brouillons, donc vérifiez le statut actuel avant de vous y fier. Cloudflare [vérifie déjà ces signatures](https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/) pour les bots qui s’enregistrent auprès d’eux. La direction est un web où un agent vérifié est autorisé à accéder et un agent non vérifié doit compléter le défi entier. Rien de tout cela ne rend un jeton Kasada facultatif pour un scraper. ## Réflexions finales Kasada bloque les requêtes qui manquent d’un jeton valide, et n’en émet un qu’après que le client ait complété son défi auto-vérifiant. L’usurpation TLS ne passe que la vérification TLS, donc le problème à résoudre est le jeton `x-kpsdk-ct`. Comparez un solveur que vous construisez et maintenez, qui peut cesser de fonctionner en quelques heures, avec le Web Unlocker de Bright Data, qui exécute le défi pour vous et inclut 5 000 requêtes gratuites par mois sans carte de crédit requise. Si vous décidez où concentrer votre temps d’ingénierie, commencez par l’option gérée en envoyant 1 requête à l’URL exacte qui renvoie vos 429, et vérifiez le corps de la réponse plutôt que le code de statut. ## FAQ ### Comment fonctionne Kasada ? Kasada sert un défi JavaScript obfusqué depuis un chemin comme `/ips.js`. Le script exécute une machine virtuelle qui prend l’empreinte du runtime, calcule une preuve de travail, et renvoie un paquet chiffré. S’il réussit, Kasada émet un jeton `x-kpsdk-ct`, et chaque requête doit l’inclure ou recevoir une réponse 429. ### Peut-on contourner Kasada avec un solveur open source gratuit ? Un solveur gratuit de GitHub peut fonctionner au début, mais il cesse rapidement de fonctionner. La charge utile change souvent sa clé de décodage (environ toutes les 5 heures dans ma capture) et vérifie sa propre intégrité, donc la logique capturée cesse de décoder en quelques heures. Un solveur public peut être obsolète, utilisez-le donc pour étudier, pas en production. ### Mettre à jour Chrome contourne-t-il Kasada ? Mettre à jour aide mais ne résout pas le problème. Une ancienne version de Chrome est un signal en soi, donc une version actuelle supprime ce signal. Cela ne supprime pas les autres signaux, comme `navigator.webdriver`, une liste de plugins vide, ou les propres signaux du framework d’automatisation, que le défi vérifie aussi. ### Que sont les en-têtes x-kpsdk ? Ce sont les en-têtes de Kasada. `x-kpsdk-ct` est le jeton client (un jeton valide accorde l’accès), `x-kpsdk-r` et `x-kpsdk-c` sont des en-têtes de défi associés, et les cookies `KP_UIDz` correspondants suivent la session. Voir n’importe quel en-tête `x-kpsdk-*` sur un 429 ou 403 est un signe fiable que Kasada a refusé la requête. ### Quelle est la façon la plus rapide de contourner un 429 Kasada ? Acheminez la requête via le Web Unlocker de Bright Data, qui prend l’URL, gère le défi pour vous, et facture par requête réussie. Pour les pages nécessitant une connexion ou une interaction en plusieurs étapes, utilisez l’API Browser via CDP, dont le déblocage intégré gère le défi. Contacter ventesEssai gratuit![google social icon](/wp-content/themes/brightdata/assets/images/ic_google.svg) Table des matières Dedicated Scraper APIs & No-Code Scrapers Over 1000 scrapers for all popular domains. Simplify your web scraping. [See pricing](/pricing/web-scraper "See pricing") Just want data? Skip scraping. Hundreds of ready-to-use datasets from all popular domains. [See pricing](/pricing/datasets "See pricing") [ ](https://news.ycombinator.com/submitlink?t=Comment+contourner+Kasada+en+2026&u=https://brightdata.fr/blog/savoir-faire/how-to-bypass-kasada) [ ](https://www.linkedin.com/shareArticle?mini=true&title=Comment+contourner+Kasada+en+2026&url=https://brightdata.fr/blog/savoir-faire/how-to-bypass-kasada) [ ](http://www.reddit.com/submit?title=Comment+contourner+Kasada+en+2026&url=https://brightdata.fr/blog/savoir-faire/how-to-bypass-kasada) ## Vous pourriez aussi être intéressé par [ ![Kimi code CLI with Bright Data](https://media.brightdata.fr/2026/10/Kimi-code-CLI-with-Bright-Data.png) ](https://brightdata.fr/blog/ai/kimi-code-cli-with-bright-data "Donnez à Kimi Code CLI un accès web avec Bright Data CLI (+ MCP)") [AI ![Antonello Zanini](https://media.brightdata.fr/2022/12/Antonello-Zanini-2-50x50.jpg) Antonello Zanini Technical Writer ### Donnez à Kimi Code CLI un accès web avec Bright Data CLI (+ MCP) Étendez Kimi Code CLI avec Bright Data pour un accès web en direct. Obtenez recherche web, scraping et automatisation de navigateur pour le codage IA. 07-Oct-2026 13 min de lecture ](https://brightdata.fr/blog/ai/kimi-code-cli-with-bright-data) [ ![Auto parts and tire data](https://media.brightdata.fr/2026/10/Auto-parts-and-tire-data.png) ](https://brightdata.fr/blog/donnees-web/auto-parts-and-tire-data "Données sur les pièces auto et pneus : tarification, compatibilité, correspondance produit et couverture marché") [Données Web ![Satyam Tripathi](https://media.brightdata.fr/2024/09/Satyam-Tripathi-50x50.png) Satyam Tripathi Technical Writer ### Données sur les pièces auto et pneus : tarification, compatibilité, correspondance produit et couverture marché Pourquoi une même pièce affiche des prix différents selon les détaillants, comment faire correspondre les annonces par numéro de pièce, et comment Bright Data livre les données de pièces auto et pneus. 05-Oct-2026 23 min de lecture ](https://brightdata.fr/blog/donnees-web/auto-parts-and-tire-data) [ ![Audio Web Scraping for AI Processing](https://media.brightdata.fr/2026/09/Audio-Web-Scraping-for-AI-Processing.png) ](https://brightdata.fr/blog/donnees-web/audio-web-scraping "Scraping Audio Web pour le Traitement IA : Un Tutoriel Complet") [Données Web ![Antonello Zanini](https://media.brightdata.fr/2022/12/Antonello-Zanini-2-50x50.jpg) Antonello Zanini Technical Writer ### Scraping Audio Web pour le Traitement IA : Un Tutoriel Complet Scrapez de l’audio à grande échelle pour le traitement IA avec Bright Data. Apprenez la conversion de format et la transcription IA pour des résultats de qualité entreprise. 05-Oct-2026 18 min de lecture ](https://brightdata.fr/blog/donnees-web/audio-web-scraping)