Comment DataDome détecte réellement les bots

La plupart des gens découvrent DataDome de la même manière : un scraper qui fonctionnait hier se met à renvoyer un 403, ou un captcha à curseur apparaît là où se trouvait la page. Le réflexe est d'ajouter un proxy ou de changer le user agent. Ça n'aide presque jamais, car DataDome ne regarde pas un signal isolé. Il score une image complète de la requête, et la solution consiste à envoyer une image qui a l'air vraie.

Voici ce qu'il regarde réellement.

Le fingerprint device

Le JavaScript de DataDome s'exécute dans la page et collecte un fingerprint du client : dimensions de l'écran et de la fenêtre, fuseau horaire, langue, polices installées, hashs canvas et WebGL, la liste des codecs supportés, et des dizaines de signaux plus petits. À lui seul, ce fingerprint n'est pas un verdict. C'est une identité que DataDome suit d'une requête à l'autre, si bien qu'une combinaison incohérente ou impossible (un user agent « Chrome sur Windows » associé à un renderer WebGL Linux) ressort immédiatement.

Le TLS et l'ordre des en-têtes

Avant que le moindre JavaScript ne s'exécute, DataDome dispose déjà de deux signaux forts issus de la connexion elle-même :

• Le fingerprint TLS (JA3/JA4). Les cipher suites et extensions exactes que propose votre client HTTP correspondent rarement à un vrai navigateur. Un handshake requests ou axios par défaut se distingue trivialement de celui de Chrome.
• L'ordre et la casse des en-têtes. Les navigateurs envoient les en-têtes dans un ordre précis et stable. La plupart des bibliothèques HTTP ne le font pas, et DataDome lit cet ordre comme un indice avant même de lire la moindre valeur d'en-tête.

C'est pourquoi changer uniquement la chaîne User-Agent ne change rien. La chaîne dit Chrome ; le handshake dit Python.

Les tags comportementaux

Une fois la page chargée, DataDome envoie en flux un payload de tags comportementaux vers son endpoint de collecte : mouvements de la souris, timing du scroll, cadence de frappe, événements focus et blur, et le timing entre eux. Une vraie session produit un flux désordonné, à forme humaine. Un navigateur headless produit soit rien, soit quelque chose de trop propre et de trop rapide.

La réponse à ce payload est ce qui définit le cookie datadome. Réussissez le payload et le cookie revient dans un état de confiance. Ratez-le, ou sautez-le, et on vous sert l'interstitiel ou le curseur.

Pourquoi les navigateurs headless se font quand même prendre

Faire tourner Puppeteer ou Playwright génère de vrais tags et un vrai handshake TLS, donc ça passe davantage qu'un client HTTP brut. Mais c'est lent (des secondes par session, des centaines de Mo de RAM par worker) et ça laisse ses propres fingerprints : navigator.webdriver, des bizarreries de rendu spécifiques au headless, et des patterns de timing propres aux frameworks d'automatisation que les plugins stealth patchent avec une release de retard. Vous finissez par entretenir une ferme de navigateurs et un tapis roulant de plugins pour lutter contre un détecteur qui se met à jour plus vite que vous.

À quoi ressemble une requête qui passe

Une requête à laquelle DataDome fait confiance porte trois choses qui concordent entre elles :

1. Un cookie datadome valide dans son état validé.
2. Le fingerprint TLS et le jeu d'en-têtes contre lesquels le cookie a été émis.
3. Une requête en aval depuis une IP qui correspond à la politique de la cible (apportez votre propre proxy).

La partie difficile, c'est de produire les deux premières sans navigateur. C'est exactement ce que nous faisons : générer le payload de tags, résoudre la vérification device et le curseur côté serveur, et vous rendre le cookie datadome plus le jeu d'en-têtes contre lequel il a été signé. Vous les attachez à votre propre requête et vous allez droit aux données. Pas de Chrome headless, pas de plugins stealth, pas de jeu du chat et de la souris.

Si vous voulez la mécanique et un exemple qui marche, voir la page de bypass DataDome. Si vous êtes bloqué par un autre vendor, la liste complète des protections couvre Akamai, Cloudflare, PerimeterX, Imperva et les autres.