Un scraper fonctionne parfaitement lors des tests.
Puis, lorsque vous le dirigez vers un vrai site web, vous obtenez :
403 Accès interdit.
Ou un CAPTCHA.
Ou bien la page se charge dans Chrome mais renvoie un résultat complètement différent de celui de votre script.
Vous changez d’adresse IP. Cela fonctionne pour quelques requêtes, puis vous êtes à nouveau bloqué.
C’est exactement le genre de problème que DataDome est conçu pour créer en matière de trafic automatisé.
Ce qu’il faut bien comprendre, c’est que DataDome ne se contente pas de demander :
« Cette adresse IP est-elle suspecte ? »
La détection moderne des bots s’apparente davantage à :
« Cette adresse IP, cette connexion réseau, ce navigateur, cet appareil, ce modèle de requête et cette session forment-ils un ensemble cohérent ? »
Cette distinction explique pourquoi changer de proxy aide parfois, pourquoi cela ne fonctionne souvent pas, et pourquoi un scraper qui semble parfaitement normal au niveau HTTP peut tout de même échouer.
Ce guide explique comment fonctionne DataDome, quels signaux il peut utiliser, à quoi ressemble un blocage par DataDome, pourquoi les navigateurs et les scripts se comportent différemment, et quel est le rôle des proxys, de l’automatisation des navigateurs et des API de scraping dans ce contexte.
Qu'est-ce que DataDome ?
DataDome est une plateforme de protection contre les bots et la fraude en ligne utilisée par les sites web, les applications mobiles et les API pour distinguer les utilisateurs légitimes du trafic automatisé ou malveillant.
Les propriétaires de sites web utilisent des systèmes tels que DataDome pour réduire les activités suivantes :
- le scraping non autorisé ;
- le « credential stuffing » ;
- les tentatives de piratage de comptes ;
- la création de faux comptes ;
- l'abus d'inventaire ;
- la fraude aux paiements ;
- l'analyse automatisée des vulnérabilités ;
- les bots agressifs ;
- les agents IA indésirables.
Pour toute personne collectant des données publiques sur le Web, DataDome se trouve de l’autre côté de la barrière.
Votre requête parvient à un site Web protégé, mais avant que l’application ne décide quel contenu renvoyer, DataDome peut évaluer la requête et déterminer si elle semble légitime, suspecte ou automatisée.
Le résultat peut être :
Autoriser
La requête se poursuit normalement.
Vérification de l'appareil
Une vérification supplémentaire du navigateur ou de l'appareil est effectuée.
CAPTCHA
Le client reçoit un test interactif.
Blocage
La requête est rejetée.
C’est pourquoi deux requêtes adressées à une URL exactement identique peuvent produire des réponses complètement différentes.
L’URL n’a pas changé.
C’est le client qui a changé.
Comment fonctionne DataDome
Voici un modèle simplifié utile :
Client → site web protégé/DataDome → décision de détection → site web
C'est au niveau de l'étape de détection que surviennent la plupart des problèmes liés aux scrapers.
DataDome est capable d’évaluer les signaux provenant de plusieurs couches d’une connexion, au lieu de se fier à un seul indicateur simple.
Ces couches peuvent inclure :
| Couche | Exemples de signaux |
|---|
| Réseau | Adresse IP, ASN, réputation du réseau |
| TLS | Empreinte TLS et caractéristiques de la connexion |
| HTTP | En-têtes, cohérence des en-têtes, propriétés des requêtes |
| Navigateur | Empreinte du navigateur et environnement |
| Appareil | Système d’exploitation, matériel et signaux d’exécution |
| JavaScript | Résultats des vérifications côté client |
| Session | Cookies et continuité entre les requêtes |
| Comportement | Timing et schémas d’interaction |
| Réputation | Activité antérieure associée à l’infrastructure |
Aucune ligne prise isolément ne prouve nécessairement qu’une requête est automatisée.
La valeur réside dans leur comparaison globale.
Une adresse IP résidentielle associée à une empreinte de navigateur invraisemblable peut tout de même paraître suspecte.
Un User-Agent en apparence parfait provenant d’un client TLS incohérent peut tout de même paraître suspect.
Un véritable navigateur générant des centaines de requêtes très répétitives peut tout de même paraître suspect.
C’est là la différence fondamentale entre les systèmes anti-bots modernes et les anciens systèmes de blocage d’adresses IP.
Détection DataDome : les principales couches
1. Réputation IP
La réputation IP reste un critère important.
Une adresse IP peut avoir un historique.
Par exemple, une infrastructure peut se forger une mauvaise réputation lorsque de grands volumes de trafic abusif ou manifestement automatisé proviennent de celle-ci.
DataDome peut déterminer si le trafic provient :
- d’une infrastructure d’hébergement connue ;
- de plages d’adresses de centres de données ;
- de proxys partagés ;
- de proxys résidentiels ;
- de réseaux de proxys publics gratuits ;
- d’adresses précédemment suspectes.
Mais la réputation IP n’est qu’un indicateur parmi d’autres.
C’est pourquoi des affirmations telles que :
« Utilisez un proxy résidentiel et DataDome ne pourra pas vous détecter. »
sont trompeuses.
Une adresse résidentielle peut donner à une requête réseau l’apparence d’un trafic grand public ordinaire.
Elle ne peut pas pour autant garantir automatiquement la cohérence du reste de la requête.
2. En-têtes HTTP
Les navigateurs envoient un ensemble reconnaissable d’en-têtes.
Les outils d’automatisation envoient également des en-têtes.
Ce qui est intéressant, ce n’est pas simplement de savoir si une requête contient un en-tête « User-Agent
».
C’est de savoir si la requête est cohérente dans son ensemble.
Par exemple, imaginez un client prétendant être une version récente de Chrome tout en envoyant un ensemble d’en-têtes qui ne correspondent normalement pas à ce navigateur.
Prises individuellement, toutes ces valeurs peuvent sembler raisonnables.
Mais prises ensemble, elles peuvent ne pas l’être.
Les systèmes modernes de détection des bots peuvent rechercher ces incohérences.
Le simple fait de modifier :
User-Agent: Mozilla/5.0...
ne transforme pas une simple bibliothèque HTTP en Chrome.
3. Empreintes TLS
Avant que les données HTTP ne soient échangées via HTTPS, le client établit une connexion TLS.
Différents clients peuvent présenter des caractéristiques TLS différentes.
Un navigateur, une bibliothèque HTTP Python, un client en ligne de commande et un autre environnement d’exécution peuvent établir des connexions chiffrées de manière différente.
Ces schémas peuvent être résumés sous forme d’empreintes.
La documentation de DataDome fait spécifiquement référence aux empreintes TLS, y compris aux informations JA3 et JA4, parmi les données pouvant être utilisées lors de l’évaluation du trafic.
Cela pose un problème important pour les configurations de scraping simplistes.
Vos en-têtes HTTP peuvent indiquer :
Chrome sous Windows
alors que la connexion réseau sous-jacente ne ressemble en rien à la version de Chrome que vous prétendez utiliser.
La modification d’un en-tête HTTP ne modifie pas automatiquement la pile TLS sous-jacente.
C’est l’une des raisons pour lesquelles l’usurpation d’identité « HTTP-only » finit par atteindre ses limites.
4. Empreinte du navigateur
Dès que JavaScript peut s'exécuter, la détection anti-bot dispose d'un environnement bien plus riche.
Un véritable navigateur divulgue une grande quantité d'informations sur lui-même et sur l'appareil qui l'exécute.
Les signaux potentiels comprennent des caractéristiques liées à :
- la version du navigateur ;
- le système d’exploitation ;
- le matériel ;
- le processeur ;
- la mémoire ;
- l’environnement graphique ;
- les API du navigateur prises en charge ;
- le comportement de rendu ;
- la prise en charge des fonctionnalités ;
- les artefacts d’automatisation.
La difficulté pour l’automatisation ne réside pas dans la production d’une seule valeur crédible.
C’est de produire des centaines de valeurs cohérentes entre elles.
Supposons qu’un navigateur automatisé prétende fonctionner sous un système d’exploitation, mais que d’autres éléments de son environnement se comportent comme s’il s’agissait d’un autre.
Ou que les caractéristiques matérielles déclarées ne correspondent pas à l’appareil déclaré.
Ou encore que l’automatisation modifie les propriétés courantes de l’empreinte numérique tout en laissant inchangés les signaux secondaires.
Le navigateur peut paraître convaincant si l’on examine cinq propriétés évidentes.
Un système de détection ne doit pas s’arrêter à cinq.
5. Détection des navigateurs « headless » et automatisés
Playwright, Puppeteer et Selenium sont incroyablement utiles.
Ils ne sont pas non plus invisibles.
Le lancement de Chromium fournit à votre scraper un véritable moteur de navigateur, ce qui résout de nombreux problèmes qu’un client HTTP basique ne peut pas résoudre :
- l’exécution de JavaScript ;
- le rendu ;
- les cookies ;
- les API du navigateur ;
- le contenu dynamique ;
- l’état de navigation.
Mais « véritable moteur de navigateur » ne signifie pas « impossible à distinguer d’un utilisateur normal ».
Les frameworks d’automatisation peuvent introduire des différences observables.
La documentation de DataDome sur la détection mentionne explicitement des catégories de détection pour les navigateurs automatisés et « headless », y compris ceux pilotés par Puppeteer, Selenium et Playwright.
Cela signifie que cette architecture simple :
Playwright + proxy
ne doit pas être considérée comme une solution anti-bot universelle.
Elle peut fonctionner parfaitement sur un site web et échouer rapidement sur un autre.
6. JavaScript et Device Check
DataDome peut également demander une vérification supplémentaire au client.
L’un de ces mécanismes est Device Check.
Au lieu d’afficher immédiatement un CAPTCHA visible, JavaScript s’exécute dans le navigateur et évalue l’environnement.
Selon DataDome, son « Device Check » recueille des centaines de signaux et effectue de multiples vérifications destinées à détecter les frameworks d’automatisation, les environnements usurpés et les accès programmatiques.
Pour un véritable visiteur, ce processus peut se dérouler sans interruption perceptible.
Pour un scraper, cela crée une différence importante entre :
un client HTTP
et :
un navigateur capable d’exécuter la logique côté client attendue
Si votre scraper se contente de télécharger le code HTML initial et ignore tout ce qui se passe dans le navigateur, il risque de ne jamais reproduire l’interaction complète attendue par le site protégé.
7. Détection comportementale
Même un navigateur techniquement performant peut présenter un comportement inhabituel.
Prenons deux sessions.
Session A
Un utilisateur :
- ouvre la page d’un produit ;
- passe 14 secondes à la lire ;
- ouvre une autre page ;
- fait défiler la page ;
- revient ;
- effectue une recherche ;
- ouvre un résultat.
Session B
Un robot d’indexation :
- demande le produit 1 ;
- 300 ms plus tard, demande le produit 2 ;
- 300 ms plus tard, demande le produit 3 ;
- répète cette opération des centaines de fois.
Les deux sessions peuvent utiliser Chrome.
Les deux peuvent utiliser des adresses IP résidentielles.
Leur comportement est manifestement différent.
La détection comportementale permet à un système anti-bot de prendre en compte des schémas plutôt que des requêtes individuelles.
Cela revêt une importance particulière à grande échelle.
Un scraper qui réussit une fois n’est pas nécessairement un scraper capable de générer 100 000 requêtes.
8. Cohérence de la session
Les sites web modernes sont « avec état ».
Les cookies, l’état du navigateur, les adresses IP et l’historique des requêtes font tous partie d’une session.
L’automatisation devient plus facile à détecter lorsque ces éléments se contredisent.
Par exemple :
- l’adresse IP change constamment alors que le même cookie de session est conservé ;
- l’identité du navigateur change en cours de session ;
- la navigation passe soudainement d’une ressource à une autre sans lien entre elles ;
- les cookies attendus à une étape précédente n’apparaissent jamais ;
- chaque requête se comporte comme celle d’un tout nouveau visiteur.
C’est pourquoi la rotation aveugle d’une adresse IP à chaque requête peut parfois rendre un scraper moins crédible plutôt que plus crédible.
La rotation est utile.
La continuité est utile.
Le choix approprié dépend de la charge de travail.
À quoi ressemble un blocage DataDome ?
DataDome ne répond pas nécessairement de la même manière à chaque requête suspecte.
Plusieurs cas de figure peuvent se présenter.
Réponse 403
Le signe le plus évident est une réponse HTTP « 403 Forbidden ».
Mais ne partez pas du principe que chaque code 403 rencontré sur Internet provient de DataDome.
Vérifiez toujours la réponse réelle.
Page CAPTCHA
Au lieu de la page cible, la réponse peut contenir un test de sécurité DataDome.
Vérification de l'appareil
Le navigateur peut effectuer une vérification invisible avant de poursuivre l'accès.
Cela prête particulièrement à confusion lors du débogage, car la page peut finir par fonctionner dans votre navigateur habituel sans que vous ayez jamais vu de CAPTCHA.
Page de blocage
Le trafic jugé suffisamment suspect peut recevoir une réponse de blocage direct.
Comportement différent entre Chrome et votre scraper
C’est l’un des indices les plus probants indiquant que le problème ne provient pas de l’URL elle-même.
Si :
Chrome → contenu
mais :
requêtes/cURL/script personnalisé → défi
la différence se situe probablement au niveau du client, de l’identité réseau, de l’exécution du navigateur ou de la session.
Pourquoi changer d'adresse IP ne suffit pas
Un proxy modifie un élément important de la requête :
l'origine apparente du trafic.
C'est un atout précieux.
Mais cela ne modifie pas automatiquement :
- votre implémentation HTTP ;
- l'empreinte TLS ;
- l'environnement du navigateur ;
- l’exécution JavaScript ;
- l’empreinte du navigateur ;
- les cookies ;
- la durée de la requête ;
- le comportement de navigation ;
- la logique de session.
Pensez à la pile complète :
**IP
- TLS
- HTTP
- navigateur
- appareil
- session
- comportement**
Un proxy modifie principalement la première couche.
Cela peut suffire lorsque la réputation de l’adresse IP est la cause de l’échec d’une requête.
Ce n’est pas suffisant lorsque plusieurs couches ne concordent pas.
Proxys de centre de données vs proxys résidentiels avec DataDome
Il n’existe pas de « proxy DataDome » universel.
Différents types de proxys résolvent différents problèmes de réseau.
Proxys de centre de données
Les adresses IP de centre de données sont rapides, peu coûteuses et extrêmement utiles pour de nombreuses tâches d’automatisation.
Leur inconvénient sur les sites web grand public fortement protégés est que leur origine réseau est plus facile à classer comme une infrastructure d’hébergement.
Cela ne signifie pas que toutes les requêtes provenant d’un centre de données sont bloquées.
Cela signifie simplement que l’adresse IP elle-même fournit moins d’indices permettant de considérer que le client ressemble à un consommateur lambda.
Proxys résidentiels
Les proxys résidentiels acheminent les requêtes via des adresses IP associées à des connexions Internet grand public.
Cela peut fournir un profil réseau plus adapté aux tâches impliquant des sites web publics destinés aux particuliers.
Mais une adresse IP résidentielle n’est pas synonyme d’utilisateur humain.
DataDome documente explicitement des modèles capables d’identifier le trafic automatisé acheminé via des proxys résidentiels.
Il convient donc de considérer les proxys résidentiels comme :
une meilleure identité réseau
et non :
un contournement automatique de la protection anti-bots
Proxys FAI
Les proxys FAI peuvent offrir des sessions stables tout en utilisant l’espace IP associé aux FAI grand public.
Pour les workflows nécessitant une identité cohérente sur une session prolongée, cette stabilité peut s’avérer précieuse.
Encore une fois, le reste du client reste déterminant.
Pourquoi une rotation constante des proxys peut se retourner contre vous
« Roter plus souvent » semble être un conseil évident.
Ce n’est pas toujours vrai.
Imaginez une session sur un site web d’une durée de cinq minutes.
Un utilisateur réel conserverait normalement la même identité réseau pendant la majeure partie de cette session.
Si votre automatisation change de pays ou de réseau toutes les trois requêtes tout en conservant les mêmes cookies et la même session de compte, cette combinaison peut paraître artificielle.
Pour certaines charges de travail, la rotation des sessions est appropriée.
Pour d’autres, les sessions persistantes produisent un comportement plus cohérent.
Une stratégie de proxy doit correspondre à la structure de l’application à laquelle vous accédez.
Qu'en est-il des outils de résolution de CAPTCHA ?
Le CAPTCHA ne constitue pas nécessairement la première étape du processus de décision de DataDome.
Il peut s'agir d'une réponse intermédiaire après qu'un autre système de détection a déjà signalé la session comme suspecte.
Cette distinction est importante.
La résolution d'un CAPTCHA ne corrige pas automatiquement :
- une empreinte de navigateur suspecte ;
- une pile TLS incohérente ;
- une mauvaise réputation IP ;
- un comportement de session impossible.
DataDome a publiquement évoqué la détection des fermes de CAPTCHA et des environnements automatisés, même après la résolution d’un défi.
Considérer la résolution du CAPTCHA comme le seul problème revient donc à négliger le système plus large qui l’entoure.
Pourquoi un scraper peut fonctionner aujourd’hui et échouer demain
Il s’agit là d’une autre source courante de confusion.
Rien ne change dans votre code.
Soudain, le taux de réussite chute.
Cela ne signifie pas nécessairement que la cible a remanié son site web.
Les systèmes de gestion des bots modifient en permanence leur logique de détection.
D’autres variables changent également :
- la réputation des adresses IP évolue ;
- les versions des navigateurs sont mises à jour ;
- les politiques des sites web changent ;
- le volume de trafic augmente ;
- votre modèle de requêtes change ;
- une cible active une protection plus stricte pour un point de terminaison spécifique.
Le scraping face aux systèmes anti-bots modernes est donc un problème opérationnel, et non un simple problème de configuration ponctuel.
DataDome et Playwright
Playwright s’avère utile lorsqu’un site web nécessite une exécution en véritable navigateur.
Il permet de charger du JavaScript, d’interagir avec les pages et de conserver l’état du navigateur.
Cela le rend nettement plus performant qu’une simple bibliothèque de requêtes HTTP pour les sites web modernes.
Cependant, Playwright ne rend pas automatiquement le trafic « humain ».
Le site protégé peut toujours évaluer :
- les caractéristiques du navigateur ;
- les artefacts d’automatisation ;
- l’identité réseau ;
- les sessions ;
- la fréquence des requêtes ;
- le comportement.
C’est pourquoi un scraper Playwright peut fonctionner correctement en phase de développement, mais devenir peu fiable à grande échelle.
L’automatisation du navigateur résout le problème de l’exécution dans le navigateur.
Elle ne résout pas tous les mécanismes anti-bot qui entourent le navigateur.
DataDome et Puppeteer
Le même principe s’applique à Puppeteer.
L’utilisation de Chromium offre au crawler un environnement client bien plus riche que le HTTP brut.
Cela s’avère utile pour :
- les applications rendues côté client ;
- les pages dynamiques ;
- la navigation via JavaScript ;
- le contenu chargé après le code HTML initial ;
- les applications nécessitant des cookies ou l’état du navigateur.
Mais le navigateur, l’adresse IP et le comportement doivent tout de même former une session cohérente.
Puppeteer est un framework d’automatisation de navigateur.
Ce n’est pas une couche d’invisibilité.
La pile de scraping qui compte vraiment
Au lieu de se demander :
« Quel proxy permet de contourner DataDome ? »
il est plus utile de raisonner par couches.
| Problème | Couche concernée |
|---|
| Mauvaise réputation IP | Proxy/réseau |
| Localisation erronée | Proxy géolocalisé |
| JavaScript requis | Navigateur/rendu |
| Contenu dynamique | Navigateur/rendu |
| Incohérence TLS | Pile HTTP/navigateur |
| Non-correspondance de l'empreinte du navigateur | Environnement du navigateur |
| Instabilité de session | Gestion des cookies/sessions |
| Modèle de requêtes excessif | Architecture de crawl |
| CAPTCHA/défi | Gestion des défis |
| Maintenance anti-bot constante | Infrastructure de scraping gérée |
Cela accélère considérablement le dépannage.
Vous cessez d’essayer de résoudre chaque problème en remplaçant le proxy.
Trois façons de collecter des données à partir d'un site protégé par DataDome
Pour une collecte de données légitime, lorsque vous êtes autorisé à accéder à la cible, il existe globalement trois architectures.
1. Développer soi-même le scraper
Vous contrôlez tout :
- le client HTTP ;
- le navigateur ;
- le proxy ;
- session ;
- logique de réessai ;
- analyse syntaxique ;
- rendu ;
- surveillance.
Avantages :
Contrôle maximal.
Inconvénients :
Maintenance maximale.
Cette approche est pertinente lorsque votre workflow est suffisamment atypique pour justifier la gestion de l’ensemble de la pile.
2. Utiliser des proxys avec votre propre navigateur ou scraper
Architecture :
votre scraper → réseau de proxys → cible
Cela vous permet de garder le contrôle de l’application tout en externalisant l’infrastructure réseau.
C’est utile lorsque vos principaux problèmes concernent :
- la réputation IP ;
- le ciblage géographique ;
- la concurrence ;
- la rotation des adresses réseau ;
- la stabilité des sessions.
Les proxys résidentiels Geonode, par exemple, prennent en charge le ciblage géographique ainsi que les configurations de sessions à rotation et persistantes.
Mais votre application reste responsable de tout ce qui se trouve au-dessus de la couche proxy.
3. Utiliser une API de scraping
Architecture :
votre application → API de scraping → cible
Au lieu de gérer vous-même les navigateurs, la sélection des proxys et l’infrastructure d’extraction, vous envoyez l’URL à un service conçu pour la collecte de données Web.
Cette solution est souvent plus adaptée lorsque le véritable besoin est :
« Donnez-moi le contenu de la page. »
plutôt que :
« Je souhaite gérer une équipe chargée de l’infrastructure anti-bot/navigateur. »
Scraper API’s , par exemple, peut renvoyer le contenu de la page rendue au format HTML ou Markdown et propose un rendu JavaScript, une infrastructure de proxys gérée, le ciblage géographique, le traitement par lots et l’exploration.
La distinction importante réside dans la maîtrise de la complexité.
Avec les proxys :
vous contrôlez la pile.
Avec une API de scraping :
la plateforme de scraping gère une plus grande partie de la pile.
Aucun des deux modèles n’est universellement meilleur.
Ils résolvent des problèmes techniques différents.
Proxy vs navigateur vs API de scraping
| Solution | Change d'adresse IP | Exécute du code JS | Gère le navigateur | Gère l'extraction | Maintenance à votre charge |
|---|
| Proxy uniquement | Oui | Non | Non | Non | Élevée |
| Playwright + proxy | Oui | Oui | Vous | Vous | Élevée |
| Puppeteer + proxy | Oui | Oui | Vous | Vous | Élevée |
| API de scraping | Gérée | Oui, si prise en charge | Gérée | Gérée | Moins élevée |
C'est pourquoi dire à quelqu'un de « simplement utiliser des proxys résidentiels » est un conseil incomplet.
Parfois, c'est exactement ce dont il a besoin.
Parfois, le proxy n'est qu'un élément d'un problème bien plus vaste.
Comment dépanner les blocages de DataDome
Lorsque les requêtes commencent à échouer, ne modifiez pas dix éléments en même temps.
Diagnostiquez la couche concernée.
Problème : cela fonctionne dans le navigateur, mais échoue dans le script
Éléments à examiner :
- l'exécution de JavaScript ;
- les différences entre les clients HTTP/TLS ;
- l'empreinte du navigateur ;
- les cookies ;
- l'état de la session.
Changer l'adresse IP peut ne pas avoir d'effet si l'échec provient du client.
Problème : cela fonctionne au départ, puis est bloqué
Vérifiez :
- le débit des requêtes ;
- les schémas de navigation répétitifs ;
- la rotation des adresses IP et des sessions ;
- les problèmes croissants de réputation des adresses IP ;
- la cohérence des sessions.
La première requête et la millième requête ne sont pas équivalentes.
Problème : l’IP du centre de données échoue, tandis que l’IP résidentielle fonctionne
La réputation du réseau joue probablement un rôle important dans la décision.
Cela ne prouve toutefois pas que d’autres signaux soient ignorés.
Problème : le proxy résidentiel échoue également
Ne concluez pas immédiatement que le proxy résidentiel est défaillant.
Vérifiez :
- l’empreinte du navigateur/client ;
- les caractéristiques TLS ;
- les exigences JavaScript ;
- les cookies ;
- les schémas de requêtes ;
- la conception de la session.
Problème : le CAPTCHA s’affiche de manière répétée
Une boucle CAPTCHA peut indiquer que la session dans son ensemble continue de paraître suspecte.
Considérez ce défi comme un symptôme, et non nécessairement comme la cause profonde.
Problème : des résultats différents selon les pays
Vérifiez si :
- le site lui-même se comporte différemment selon la zone géographique ;
- la disponibilité du contenu change ;
- l’état des cookies reste cohérent ;
- la géolocalisation de l’adresse IP correspond à la session prévue.
DataDome détecte-t-il les proxys résidentiels ?
Oui, c'est possible.
Ceci est clairement indiqué dans la documentation de DataDome consacrée à la détection.
Cela ne signifie pas pour autant que toutes les requêtes provenant de proxys résidentiels sont bloquées.
Si tel était le cas, les utilisateurs légitimes se connectant via des réseaux grand public partagés généreraient d'énormes problèmes de faux positifs.
Une formulation plus précise serait :
Une adresse IP résidentielle est un indice parmi d’autres, et non la preuve qu’il s’agit d’un visiteur humain.
Les systèmes de détection modernes combinent cet indice avec d’autres éléments.
DataDome détecte-t-il Playwright ?
DataDome documente des modèles de détection couvrant les navigateurs instrumentés via des frameworks d’automatisation, notamment Playwright, Puppeteer et Selenium.
Cela ne signifie pas que chaque session Playwright est automatiquement bloquée.
Cela signifie que l’hypothèse suivante :
« Playwright utilise un vrai navigateur, il ne peut donc pas être détecté »
est erronée.
DataDome utilise-t-il l’empreinte digitale du navigateur ?
Oui.
L’empreinte digitale du navigateur et de l’appareil fait partie intégrante de l’architecture de détection de DataDome.
Cela permet au système de comparer les informations exposées par le navigateur et l’environnement d’exécution, plutôt que de se fier à de simples identifiants tels que l’en-tête User-Agent.
DataDome utilise-t-il l’empreinte TLS ?
La documentation de DataDome fait référence aux empreintes TLS et recommande les empreintes JA3 et JA4 comme signaux disponibles pour ses intégrations d’API de protection.
C’est important car la connexion TLS est établie avant que la logique habituelle de l’application web ne détecte la requête.
Un scraper peut donc avoir des en-têtes HTTP parfaitement modifiés tout en exposant une empreinte réseau de niveau inférieur différente.
DataDome utilise-t-il l’apprentissage automatique ?
DataDome décrit ses modèles de détection des menaces comme étant basés sur l’apprentissage automatique et mis à jour en continu.
L’apprentissage automatique n’a rien de magique.
Sa valeur pratique réside ici dans sa capacité à combiner de nombreux signaux et modèles plutôt que de s’appuyer sur une seule règle statique telle que :
bloquer l’adresse IP après 100 requêtes.
DataDome peut-il bloquer les agents IA ?
Oui.
Le marché de la gestion des bots s’étend de plus en plus au-delà des scrapers traditionnels pour inclure les agents IA et les crawlers LLM.
DataDome prend désormais explicitement en charge l’identification et l’authentification des bots commerciaux et des agents IA, tandis que le trafic automatisé non authentifié peut être soumis à ses politiques de détection des menaces.
Cela devrait prendre de plus en plus d’importance à mesure que de plus en plus de systèmes d’IA naviguent et interagissent directement avec les sites web.
Peut-on contourner DataDome ?
Il s’agit généralement d’une mauvaise question d’un point de vue technique.
Il n’existe aucun en-tête, type de proxy ou indicateur de navigateur permanent capable de faire disparaître un système de détection moderne.
Une configuration qui fonctionne pour un point de terminaison donné, avec un certain volume de trafic, peut échouer :
- sur un autre point de terminaison ;
- à plus grande échelle ;
- avec une autre version de navigateur ;
- après une mise à jour des modèles de détection.
Pour les charges de travail légitimes liées aux données Web, la question la plus pertinente est la suivante :
Quelle partie de ma pile de scraping entraîne la classification de la requête comme automatisée, et est-ce que je souhaite gérer cette couche moi-même ?
Parfois, la réponse réside dans l’infrastructure réseau.
Utilisez une configuration de proxy adaptée.
Parfois, la réponse réside dans le rendu.
Utilisez un navigateur.
Parfois, la réponse réside dans l’ensemble de la pile opérationnelle.
Utilisez une API de scraping gérée.
Et parfois, la bonne réponse consiste à utiliser plutôt une API officielle ou une autre source de données autorisée.
DataDome vs Cloudflare
DataDome et Cloudflare se chevauchent sur certains segments du marché de la gestion des bots, mais ils ne doivent pas être considérés comme des produits identiques.
Cloudflare propose une vaste plateforme d’infrastructure qui inclut un CDN, un DNS, un WAF, des fonctionnalités de protection contre les attaques DDoS et de gestion des bots.
DataDome se concentre plus spécifiquement sur la détection des bots et de la fraude en ligne sur les sites web, les applications mobiles et les API.
Du point de vue d'un développeur de scrapers, cependant, le principe est similaire :
les protections anti-bots modernes opèrent à plusieurs niveaux.
Une stratégie efficace ne peut pas reposer uniquement sur la modification d’un seul en-tête HTTP.
DataDome vs CAPTCHA
DataDome n’est pas un service CAPTCHA.
Le CAPTCHA est l’une des réponses possibles après la détection.
Le système qui détermine si un client est suspect intervient en amont.
Cette distinction est importante car les développeurs consacrent souvent d’énormes efforts à essayer de « résoudre le CAPTCHA » tout en ignorant les signaux qui ont provoqué l’apparition de ce défi.
La bonne question est :
Pourquoi cette session a-t-elle été remise en cause au départ ?
Quand les proxys résidentiels sont-ils pertinents ?
Les proxys résidentiels sont utiles lorsque la couche réseau joue un rôle important.
On peut citer, à titre d'exemple, les charges de travail légitimes impliquant :
- du contenu public spécifique à une zone géographique ;
- des résultats de recherche localisés ;
- des tarifs régionaux ;
- la disponibilité des produits ;
- des études de marché ;
- la collecte de données Web distribuée.
Ils sont particulièrement utiles lorsque vous souhaitez garder le contrôle total de votre propre outil de scraping.
Les proxys résidentiels de Geonode offrent un routage IP résidentiel avec ciblage géographique et un comportement de session configurable.
Mais un proxy doit rester ce qu’il est réellement :
une infrastructure réseau.
Ce n’est pas un navigateur.
Ce n’est pas un système CAPTCHA.
Ce n’est pas un moteur de scraping.
Et il ne répare pas automatiquement une empreinte digitale endommagée.
Quand un service «Scraper API» prend tout son sens
Un service «Scraper API» devient intéressant lorsque la gestion anti-bot commence à prendre le pas sur le développement.
Vous devriez au moins envisager une API gérée lorsque votre équipe consacre plus de temps à :
- les mises à jour de navigateurs ;
- la logique de réessai ;
- l’orchestration des proxys ;
- le rendu ;
- l’extraction ;
- la gestion des sessions ;
- les requêtes ayant échoué ;
qu’à l’utilisation des données elles-mêmes.
Avec Geonode Scraper API, une application peut envoyer des URL et recevoir du code HTML ou Markdown extrait, tandis que le service gère le rendu et l’infrastructure de proxy en arrière-plan de la requête.
Le compromis est simple :
Développer soi-même offre plus de contrôle.
Utiliser une API élimine le travail lié à l’infrastructure.
Faites votre choix en fonction des besoins réels de votre produit.
FAQ
Qu'est-ce que DataDome ?
DataDome est une plateforme de protection contre les bots et la fraude en ligne, conçue pour identifier le trafic automatisé et malveillant sur les sites web, les applications mobiles et les API.
Comment DataDome détecte-t-il les bots ?
Il combine plusieurs signaux, notamment la réputation de l’adresse IP, les empreintes HTTP et de navigateur, les caractéristiques TLS, les informations sur l’appareil, les modèles comportementaux et les modèles de détection basés sur l’apprentissage automatique.
Pourquoi DataDome bloque-t-il mon scraper ?
Il y a rarement une seule raison universelle. L’adresse IP, le client HTTP/TLS, l’environnement du navigateur, la prise en charge de JavaScript, la cohérence de la session ou le comportement des requêtes peuvent tous jouer un rôle.
DataDome utilise-t-il le CAPTCHA ?
Oui, le CAPTCHA peut constituer une réponse face à un trafic suspect. DataDome peut également effectuer une vérification invisible de l’appareil (Device Check) ou bloquer directement les requêtes.
Qu’est-ce que le « Device Check » de DataDome ?
Le « Device Check » est un mécanisme de vérification supplémentaire qui effectue des contrôles côté client sans nécessiter nécessairement d’interaction visible de la part de l’utilisateur. Il évalue les signaux liés à l’appareil et à l’exécution et peut autoriser, soumettre à un test ou bloquer le client en fonction du résultat.
Le fait de modifier mon User-Agent permet-il de contourner DataDome ?
La modification de l’User-Agent ne change qu’une seule valeur HTTP. Elle ne modifie pas automatiquement la connexion TLS, l’environnement du navigateur, l’empreinte digitale de l’appareil, les cookies ou le comportement.
DataDome peut-il détecter Chrome en mode « headless » ?
DataDome documente spécifiquement les catégories de détection pour les navigateurs « headless » et automatisés, y compris les navigateurs instrumentés via Puppeteer, Selenium et Playwright.
DataDome peut-il détecter Playwright ?
Il peut identifier les caractéristiques associées à l’automatisation des navigateurs, y compris les environnements pilotés par Playwright. L’utilisation de Playwright ne signifie pas automatiquement qu’une session sera bloquée, mais celle-ci ne doit pas pour autant être considérée comme intrinsèquement invisible.
DataDome peut-il détecter Puppeteer ?
Oui, DataDome documente des modèles de détection couvrant l’automatisation basée sur Puppeteer et Puppeteer Extra Stealth.
DataDome peut-il détecter les proxys résidentiels ?
DataDome dispose de modèles de détection liés au trafic acheminé via des proxys résidentiels. Une adresse IP résidentielle peut tout de même s’avérer utile car elle modifie l’identité réseau, mais elle ne rend pas pour autant le trafic automatisé automatiquement légitime.
Les proxys résidentiels sont-ils préférables aux proxys de centre de données pour les sites protégés par DataDome ?
Les proxys résidentiels peuvent fournir une identité réseau plus proche du trafic des consommateurs lambda, ce qui peut s’avérer utile sur les sites destinés au grand public. Le choix approprié dépend toutefois de la cible, de la charge de travail et d’autres couches de détection.
Ai-je besoin d’un navigateur pour extraire des données d’un site protégé par DataDome ?
Toutes les pages protégées ne nécessitent pas un navigateur. Cependant, les sites web s’appuyant sur le rendu côté client ou sur Device Check peuvent nécessiter une exécution JavaScript authentique et un état de navigateur qu’un client HTTP basique ne peut pas fournir.
Pourquoi est-ce que je reçois des erreurs 403 de la part de DataDome ?
Une erreur 403 peut indiquer que la requête a été classée comme suspecte ou automatisée. Vérifiez que la réponse provient bien de DataDome avant de supposer que le système anti-bot en est responsable.
Pourquoi la page fonctionne-t-elle manuellement mais pas en Python ?
Votre navigateur habituel et la bibliothèque HTTP de Python génèrent des environnements réseau, TLS, HTTP, JavaScript et de navigation très différents. Un système anti-bot peut détecter certaines de ces différences.
Pourquoi mon scraper fonctionne-t-il pendant quelques requêtes puis s'arrête-t-il ?
Parmi les causes possibles, on peut citer la détection comportementale, les schémas de fréquence, les changements de réputation de l'adresse IP ou des sessions incohérentes. Les systèmes anti-bot peuvent évaluer l’activité sur plusieurs requêtes plutôt que de juger chaque requête isolément.
La rotation des proxys permet-elle de contourner DataDome ?
Pas à elle seule.
La rotation modifie l’identité réseau. Elle ne modifie pas automatiquement l’empreinte du navigateur, le client TLS, l’environnement JavaScript ou le comportement des requêtes.
Une API de scraping est-elle préférable aux proxys ?
Elles répondent à des besoins différents.
Utilisez des proxys lorsque vous souhaitez contrôler votre scraper et que vous avez principalement besoin d’une infrastructure réseau.
Utilisez une API de scraping lorsque vous souhaitez que l’infrastructure liée au navigateur, au proxy, au rendu et à l’extraction soit davantage gérée à votre place.
En résumé
Ce qu’il faut surtout retenir à propos de DataDome, c’est qu’il n’existe pas de « signal de bot » unique.
Les systèmes modernes de détection anti-bot analysent plusieurs couches.
Une requête ne se résume pas à une simple adresse IP.
Il s’agit :
d’une adresse IP
établissant une connexion TLS
envoyant des en-têtes HTTP
à partir d’un navigateur ou d’une application
dans le cadre d’une session
avec un historique
et un profil de comportement.
Plus ces éléments concordent entre eux, plus le client semble cohérent.
C’est pourquoi changer d’adresse IP peut résoudre un problème tout en en laissant cinq autres intacts.
C’est pourquoi Playwright résout l’exécution JavaScript sans pour autant résoudre tous les problèmes de détection.
Et c’est pourquoi les API de scraping gérées existent en premier lieu.
Si vous avez besoin d’un contrôle total, construisez vous-même la pile et utilisez des proxys comme infrastructure réseau.
Si vous avez principalement besoin d’un contenu web fiable sans avoir à gérer les navigateurs ni l’orchestration des proxys, utilisez une API de scraping.
L’essentiel est de savoir quelle couche vous essayez réellement de corriger.
