Tous les articles

JA4 et le TLS post-quantique ont brisé le scraper de base

Votre header User-Agent n'a plus d'importance. Les empreintes JA4 classifient les bots avec une précision de 98,6 % avant même la lecture des headers. Voici ce qui a changé en 2026.

Le handshake TLS est le niveau de base de la détection de bots

98,6 %.

C'est la précision de classification atteinte par un modèle CatBoost en utilisant uniquement les caractéristiques JA4. Pas de headers. Pas d'IP. Pas de comportement. Juste la structure du handshake TLS. L'article arXiv est paru en février 2026, et ce résultat n'est pas une anomalie. Cloudflare, AWS, VirusTotal et Akamai exécutent tous JA4 (ou son ancien cousin JA3) en production. Si vous scrapez en 2026 avec un simple client HTTP, le verdict est tombé avant même que votre request n'atteigne la couche applicative.

C'est la partie que les tutoriels de détection de bots ignorent. La plupart des articles sur le contournement des anti-bots tournent encore autour de la rotation de User-Agent, des cookies et des CAPTCHAs. Ce sont les couches faciles. Mais la couche TLS est celle que vous ne pouvez pas tromper avec un header.

Ce que JA4 voit réellement

JA4 est une empreinte du ClientHello TLS. Il encode le protocole (TCP ou QUIC), la version TLS, la présence du SNI, l'ordre des suites de chiffrement, les extensions, les algorithmes de signature et l'ALPN. Le résultat est une chaîne compacte comme t13d1516h2_8daaf6152771_e5627906d626. Deux clients prétendant être le même navigateur produiront le même hash JA4. Un script Python requests prétendant être Chrome produit un JA4 qui n'existe nulle part ailleurs dans le monde que dans les scrapers.

La famille JA4 (développée par FoxIO, le même groupe derrière JA3) a résolu la plus grande faiblesse de JA3 : la permutation des extensions, que Chromium a introduite en 2023 pour briser le fingerprinting naïf. JA4 trie les extensions et les compte, de sorte que l'aléatorisation n'aide pas. Il n'y a pas d'échappatoire facile.

Akamai a révélé une précision de classification des bots de 92 à 98 % grâce à une analyse multi-couches (cross-layer). Cette dimension multi-couches est cruciale. Le TLS seul est le signal dominant, mais le combiner avec l'ordonnancement des trames HTTP/2, l'ordre des headers et le timing des requests réduit le taux de faux positifs bien en dessous de ce que la plupart des scrapers peuvent tolérer.

Le tournant post-quantique

C'est la partie que personne n'a vue venir. Le 31 janvier 2026, Akamai a fait de l'échange de clés post-quantique le choix par défaut pour toutes les connexions. Début 2026, 57,4 % des connexions réelles initiées par un navigateur incluent le partage de clés X25519MLKEM768. La part de Chrome compatible PQ se situe autour de 93 %. Firefox 132 est à 85 %. Safari est en cours de déploiement.

Le partage de clés PQ est volumineux. 1 124 octets contre 36 octets pour le X25519 classique. Le ClientHello est passé de 300-500 octets à plus de 1 400. Cette augmentation se reflète dans JA4, dans la capture de paquets et dans l'observation passive au niveau du WAF.

Si votre client de scraping n'inclut pas le partage de clés PQ, vous prétendez être un navigateur que ni Chrome ni Firefox actuels ne simuleraient. Deux CVE du premier trimestre 2026 signalent exactement cette incohérence : CVE-2026-26995 (padding extension) entraîne une probabilité de détection de 25 à 50 % par request, et CVE-2026-27017 (incohérence ECH et GREASE) se situe autour de 50 %. Cumulée sur l'ensemble d'une session, l'exposition frôle la certitude.

C'est un problème à 12 mois qui se transforme en problème à 3 mois. La plupart des stacks de scraping open-source n'ont pas encore intégré de TLS compatible PQ. Celles qui l'ont fait ont des semaines de retard sur le vrai Chromium.

Pourquoi les proxies ne résolvent pas ce problème

Une idée rassurante circule selon laquelle des pools de proxies plus grands résoudraient la détection moderne de bots. C'est faux. L'incident de scalping de janvier 2026 couvert par Security Boulevard a généré 16 millions de requests sur 3,9 millions d'IP uniques. Le blocage par IP était inutile. La défense qui a fonctionné reposait principalement sur le TLS et le fingerprinting comportemental.

L'économie des proxies résidentiels s'est également effondrée ce trimestre. Help Net Security a rapporté en avril 2026 que la perturbation du réseau IPIDEA en janvier a réduit la capacité résidentielle du secteur d'environ 40 % du jour au lendemain. La bataille de brevets entre Bright Data et Oxylabs (la Cour suprême a rejeté la requête de Bright Data le 23 février 2026, le procès étant fixé au 18 mai) est un événement secondaire à côté de cet impact sur la capacité. Les acheteurs qui recherchent des IP résidentielles pour se défendre contre le fingerprinting paient plus cher pour une solution dont le WAF n'a que faire.

Les proxies restent importants, mais pas pour la raison que la plupart des gens imaginent. La distribution géographique et le type de FAI influencent les décisions de routage et les profils de rate limit. Ils ne vous aident pas à survivre au handshake.

Ce que cela signifie pour les équipes data

Trois choses changent si vous construisez ou achetez une infrastructure de scraping en 2026.

Premièrement, la stack TLS est désormais une exigence absolue. Tout client qui n'imite pas le handshake TLS d'un vrai navigateur (partage de clés PQ, ordre des extensions, ALPN, algorithmes de signature) produit une empreinte classée comme bot avec un niveau de confiance élevé. Envelopper Python requests avec de meilleurs headers ne résout rien. Le transport est l'élément révélateur.

Deuxièmement, la détection des navigateurs headless s'est détériorée, elle ne s'est pas améliorée. Le rapport State of Web Scraping 2026 de Browserless indique que l'écart entre le Chromium headless et le Chromium classique se creuse. Les fournisseurs de solutions anti-bots ont répertorié les différences d'empreintes et partagent les informations sur les menaces entre les sites de leurs clients en quasi-temps réel. Une instance headless qui fonctionnait en décembre peut être classée comme bot en mai. Les signaux comportementaux se superposent au TLS, et ces deux éléments sont des cibles mouvantes.

Troisièmement, le calcul du build-vs-buy a changé. Maintenir une empreinte TLS qui correspond à une cible mouvante (Chromium publie des mises à jour PQ toutes les quelques semaines, l'ordre des extensions change entre les versions mineures, les préférences de suites de chiffrement évoluent) est désormais un travail à plein temps. Les équipes qui consacraient 20 % du temps d'un ingénieur à la maintenance des scrapers en 2024 y consacrent plus d'un demi-équivalent temps plein en 2026. Nous avons déjà écrit sur les raisons pour lesquelles les scrapers cessent constamment de fonctionner. En 2026, la réponse est plus souvent "TLS" que "DOM".

Le scraper le moins cher est celui qui n'est pas classifié

La prédiction intéressante n'est pas de savoir si les fournisseurs d'anti-bots continueront à élever le niveau. Ils le feront. La prédiction intéressante est de savoir quels outils de scraping survivront dans un marché où une précision de 98 % est le seuil de détection minimal.

La plupart n'y parviendront pas. Mais ceux qui réussiront traiteront le handshake TLS comme une partie intégrante de la request, et non comme un simple détail de transport. Et les acheteurs commenceront à poser aux fournisseurs une question qui ne figurait pas sur la liste d'évaluation il y a douze mois : quelle empreinte TLS proposez-vous, et à quelle vitesse la mettez-vous à jour ?

Le handshake règle la question avant même que la request n'ait la possibilité de faire valoir ses arguments.