Skip to main content
Chaque session de navigateur révèle une signature identifiable : User-Agent, rendu canvas, chaîne du moteur WebGL, liste de polices, résolution d’écran, extensions installées, fuseau horaire, langues, sortie audio et bien d’autres éléments. Les systèmes anti-bot modernes combinent ces signaux en une empreinte numérique du navigateur, capable d’identifier une session plus sûrement qu’une adresse IP. Un outil qui ne la gère pas fournit à la détection un identifiant clair à chaque requête. Cette couche se situe sous le comportement : elle décrit ce que la session est, et non ce qu’elle fait. Pour échapper à un système anti-bot avancé, il faut à la fois une empreinte cohérente et un comportement humain.

​
Signaux suivis

Une empreinte moderne combine généralement :
  • User-Agent et en-têtes accept. C’est le point de départ évident. La présence de HeadlessChrome dans le User-Agent révèle l’automatisation.
  • Empreinte canvas. Le site demande au navigateur de dessiner un élément canvas masqué et hache le résultat. Les infimes différences entre GPU, pilotes et systèmes produisent une signature stable par machine.
  • Empreinte WebGL. Les chaînes du moteur de rendu et du fournisseur, ainsi que les extensions prises en charge, caractérisent fortement le GPU et ses pilotes.
  • Liste des polices. Les polices disponibles et leur ordre peuvent parfois identifier une session à elles seules.
  • Écran et zone d’affichage. Résolution, profondeur des couleurs et ratio de pixels. Un écran 1366×768 à l’échelle 200 % diffère d’un écran Retina 2560×1440.
  • Fuseau horaire et langue. Ils proviennent notamment de Intl.DateTimeFormat et navigator.languages.
  • Contexte audio. Comme canvas, le rendu audio génère une sortie propre à l’appareil.
  • Extensions, propriétés de navigator et parallélisme matériel. Ces signaux sont plus faibles, mais peuvent être combinés.
  • navigator.webdriver. Il révèle directement une automatisation non dissimulée.
Des dizaines de petits signaux se renforcent mutuellement. Il n’est pas nécessaire que chacun soit unique : leur combinaison doit seulement l’être suffisamment pour permettre le suivi.

​
Pourquoi les outils révèlent leur empreinte

Trois erreurs sont particulièrement fréquentes :
  • Répéter la même identité par défaut. Une instance Puppeteer standard exécutant 10 000 sessions présente le même hachage canvas, la même chaîne WebGL et les mêmes polices : 10 000 « utilisateurs » avec l’empreinte d’une seule machine, donc faciles à détecter.
  • Employer des valeurs qu’aucun utilisateur réel ne produit. Un navigator.plugins vide, un rendu canvas exactement identique au rendu Linux/Chrome standard ou l’absence de polices système courantes constituent des anomalies.
  • Créer des incohérences entre les signaux. Une langue en-US et le fuseau America/New_York associés à une IP russe, un User-Agent d’iPhone avec un affichage de bureau ou des polices réservées à macOS sur une empreinte Windows sont autant de contradictions détectables.

​
Gérer l’empreinte

Les solutions répondent directement à ces erreurs :
  • Unicité par session. Chaque instance de Tâche doit présenter une empreinte distincte afin de ne pas répéter la même identité pour différents « utilisateurs ».
  • Cohérence pendant la session. L’empreinte doit rester stable au sein d’une session ; la modifier en cours d’utilisation est également révélateur.
  • Cohérence géographique avec l’IP. Le fuseau, la langue et les en-têtes accept-language doivent correspondre à la région de l’IP du Proxy.
  • Réalisme plutôt qu’aléatoire pur. Des valeurs entièrement aléatoires sont elles-mêmes anormales. Utilisez des distributions observées dans le monde réel : GPU courants, listes de polices plausibles et tailles d’écran habituelles.
Ces principes constituent une gestion active des empreintes, contrairement à l’utilisation passive des valeurs par défaut de l’environnement.

​
L’approche d’Octoparse

En plus de l’avantage naturel de son environnement conçu avec interface, qui révèle moins de signaux que les outils headless, Octoparse gère activement l’empreinte. Les sessions présentent des profils distincts et réalistes plutôt qu’une identité par défaut répétée dans chaque Tâche. L’environnement associe la discrétion « passive » d’un navigateur avec interface et la discrétion « active » de la diversité des empreintes, sans service externe à configurer. Cette gestion complète la simulation comportementale : l’environnement ressemble à un utilisateur réel différent à chaque session, puis agit comme lui sur la page.

​
Quand est-ce nécessaire ?

La gestion active est superflue pour les sites statiques et les détections rudimentaires, mais devient utile face aux défenses plus fortes :
  • Défenses légères. Un navigateur avec interface suffit généralement.
  • Défenses moyennes (limitation de débit et détection basique). Les paramètres par défaut conviennent souvent si les autres couches sont cohérentes.
  • Défenses fortes (Cloudflare, DataDome, HUMAN, Akamai Bot Manager). Elle est indispensable. Sans empreintes distinctes et réalistes, la répétition d’une même identité finit par entraîner un blocage, même si tout le reste paraît normal.
Pour la dimension comportementale, consultez Un scraping au comportement humain. Pour les systèmes de défense concernés, consultez Contourner les CAPTCHA et Cloudflare.