Empreinte TLS (JA3/JA4) : pourquoi un scraper se fait repérer

Vous avez soigné votre scraper. User-Agent d'un vrai Chrome, en-têtes parfaits, belle IP résidentielle. Et pourtant, le serveur répond 403 avant même d'avoir servi une ligne de HTML. Ce qui vous a trahi se joue une couche plus bas que tout ce que vous contrôlez habituellement : dans la poignée de main TLS, la toute première chose qu'un client envoie en HTTPS.

Ce qui se passe avant le HTTP

Quand un client ouvre une connexion sécurisée, il commence par un message appelé ClientHello. Ce message part en clair, avant tout chiffrement complet, et avant le moindre en-tête HTTP. Il annonce les capacités techniques du client :

• les versions de TLS supportées ;
• la liste des algorithmes de chiffrement (les « cipher suites »), dans un ordre précis ;
• les extensions activées ;
• les courbes elliptiques et formats de points supportés.

Le point clé : cette liste et son ordre varient selon la bibliothèque logicielle qui établit la connexion. Le Chrome de votre machine, Firefox, la bibliothèque requests de Python ou curl ne négocient pas le TLS de la même manière. Chacun a sa façon de se présenter.

De la signature au hash : JA3

En 2017, des ingénieurs de Salesforce ont eu une idée simple. Puisque le ClientHello est stable et caractéristique, autant en faire une empreinte. La méthode, baptisée JA3, prend cinq champs du message, les met bout à bout, et en calcule un hash. Le résultat est une chaîne courte qui identifie la façon de négocier, donc le logiciel réel derrière la connexion.

Le serveur ne vous croit pas sur parole. Il calcule votre empreinte TLS et la compare à celles qu'il connaît.

La bibliothèque requests de Python produit une empreinte immédiatement reconnaissable comme non-navigateur. Peu importe que votre User-Agent affiche fièrement « Chrome » : si l'empreinte TLS dit « Python », le serveur voit la contradiction et augmente son score de suspicion.

Pourquoi JA3 a laissé place à JA4

En 2023, Chrome a introduit une nouveauté : l'ordre des extensions dans le ClientHello est désormais tiré au hasard à chaque connexion. Bonne pratique côté sécurité, mais effet de bord immédiat : l'empreinte JA3 d'un vrai Chrome devenait différente à chaque session, rendant le signal inutilisable.

La réponse fut JA4, une nouvelle méthode qui trie les éléments avant de les hasher. L'empreinte redevient stable, malgré la randomisation. En 2026, la bascule de JA3 vers JA4 est quasiment achevée chez tous les grands éditeurs de protection.

Et ça ne s'arrête pas au TLS

Une fois la connexion chiffrée établie, une autre couche prend le relais : le protocole HTTP/2. Là encore, la façon d'ouvrir le dialogue est caractéristique, notamment l'ordre des pseudo-en-têtes et certains paramètres techniques. Un ordre d'en-têtes strictement alphabétique, par exemple, est une signature classique de client automatisé, qu'aucun navigateur réel ne produit.

La leçon pour qui collecte de la donnée

La conclusion est un peu contre-intuitive. On croit souvent que scraper proprement, c'est une affaire de proxys et d'en-têtes bien copiés. En réalité, le vrai sujet est la cohérence de bout en bout. Tout doit raconter la même histoire :

• l'empreinte TLS doit correspondre à un vrai navigateur (JA4) ;
• la poignée de main HTTP/2 doit suivre ;
• les en-têtes et leur ordre doivent être ceux du navigateur annoncé ;
• et derrière, le comportement doit tenir la route.

Reproduire cette cohérence à la main est un travail sans fin, car les empreintes de référence évoluent à chaque version de navigateur. C'est la raison d'être d'un service comme WyndPath : présenter, à chaque requête, une signature complète et cohérente, sans que vous ayez à courir après la dernière version de Chrome. Vous demandez une URL, vous recevez la page, dans le respect des règles publiées par le site.