Aucun en-tête magique unique ne détecte un navigateur stealth. Vous attrapez les petites incohérences que l'automatisation et le tooling de spoofing de fingerprint laissent derrière eux, puis vous les confirmez par le comportement sur la session. Un setup stealth moderne patche les signaux évidents (navigator.webdriver, l'objet window.chrome manquant, les quirks de rendu headless), donc la détection doit lire les couches que ces patches ne couvrent pas totalement : la surface de contrôle d'automatisation, la cohérence interne du fingerprint, et la façon dont la session se comporte une fois sur la page.
C'est le guide opérateur. Voici les classes de signaux concrètes qu'il vaut la peine d'instrumenter, ce que chacune capture, et ce qu'un navigateur stealth bien configuré défait. cside collecte ces signaux depuis l'intérieur du runtime navigateur, donc l'objectif ici est de rendre les signaux lisibles. Si vous voulez le contexte conceptuel sur ce que sont les navigateurs stealth et anti-detect, lisez d'abord l'explainer sur les navigateurs stealth ; ce post suppose que vous voulez déjà les trouver.
Quels signaux révèlent vraiment un navigateur stealth ?
Aucune classe isolée ne suffit. Une détection forte empile les quatre et les pondère selon la difficulté à les falsifier.
| Classe de signal | Ce qu'elle capture | Ce qu'un bon tooling stealth défait |
|---|---|---|
| Signaux automation / CDP | Sessions headless et DevTools-driven non patchées | Override navigator.webdriver, window.chrome injecté |
| Quirks de rendu headless | Chrome headless vanilla | Chrome headful piloté via CDP, serveurs de display virtuel |
| Incohérence de fingerprint | Appareils spoofés avec des mismatches internes | Profils anti-detect bien construits et auto-cohérents |
| Signaux comportementaux | Timing machine, entropie d'input, rythme de navigation | Sessions ralenties, jitterées ou human-in-the-loop scriptées |
Signaux d'automatisation et CDP
Les signaux les moins chers viennent de la surface de contrôle d'automatisation elle-même. Un Chrome piloté par Playwright ou Selenium sans couche stealth met navigator.webdriver à true, livre un objet window.chrome manquant ou creux, et expose un comportement de permissions.query qui ne correspond pas à ce qu'un vrai Chrome renvoie (par exemple, la permission de notification lisant denied alors que Notification.permission dit default). Chacun de ces signaux se lit en une ligne.
Les bibliothèques stealth existent précisément pour effacer ça. playwright-stealth et ses pairs override navigator.webdriver, injectent un window.chrome réaliste, normalisent navigator.plugins, et corrigent le mismatch de permissions, ce qui explique pourquoi bloquer l'automatisation Playwright demande plus que de lire un seul flag. La recherche sécurité web 2026 de cside rapporte que les installations de playwright-stealth ont augmenté d'environ 10x sur 2025, un proxy utile de la vitesse à laquelle cette évasion est passée dans le tooling grand public (recherche 2026 de cside).
Les flags patchés deviennent une preuve de confirmation plutôt qu'une preuve primaire. Le signal plus dur est la liaison Chrome DevTools Protocol sous-jacente à l'automatisation. Les sessions pilotées par CDP peuvent fuiter via des effets de bord : le comportement du runtime sous des interactions Runtime/Console spécifiques, des quirks de sérialisation dans les stacks d'erreur, ou des différences de timing quand le protocole est attaché. Ceux-là sont bien plus coûteux à supprimer totalement qu'un simple booléen, parce qu'ils émergent de la façon dont le navigateur est contrôlé, pas d'une propriété qu'ils peuvent réécrire.
Rendu headless et quirks d'environnement
Le Chrome headless vanilla se trahit encore par le rendu et l'environnement appareil. Les classiques : un user-agent contenant HeadlessChrome, zéro plugin installé alors qu'un Chrome desktop réel reporte un petit ensemble, une fenêtre externe manquante ou de taille fixe, des APIs batterie ou media-device non peuplées, et des différences subtiles dans la façon dont les polices et images se rasterisent sans vrai display.
En 2026, les opérateurs sérieux ont dépassé le mode headless. Un agent IA peut piloter un Chrome headful complet via CDP sur un display virtuel, ce qui supprime chaque signal spécifique headless tout en gardant l'automatisation en dessous. La détection headless attrape la couche paresseuse et force tout le reste à monter d'un niveau, où les couches fingerprint et comportement prennent le relais. C'est aussi là que les outils de détection de bots legacy passent à côté des agents IA : ils ont été conçus pour signaler les signatures headless, pas la surface de contrôle sous un navigateur headful.
Incohérences de fingerprint : les fissures d'un appareil spoofé
Les navigateurs anti-detect remplacent les APIs génératrices de fingerprint par des valeurs synthétiques pour que chaque session ressemble à un nouvel appareil. Le mode de défaillance détectable est l'incohérence interne : les valeurs spoofées ne s'accordent pas entre elles. Les profils de qualité inférieure sont là où les fissures apparaissent.
- Liste de polices vs. OS déclaré. Un profil qui prétend macOS mais énumère des polices uniquement Windows (ou omet les polices que tout Mac livre) est spoofé. L'ensemble de polices doit correspondre à la plateforme qu'il prétend être.
- Renderer WebGL vs. matériel plausible. Une chaîne
WEBGL_debug_renderer_infoqui nomme un GPU qu'aucun appareil commercial ne couple avec l'OS et le profil d'écran déclarés est un signal. Les spoofers piochent dans une bibliothèque de chaînes réelles, mais les apparier cohéremment avec tout le reste est difficile. - Sortie Canvas et AudioContext. Les navigateurs anti-detect renvoient des pixels canvas et une sortie audio synthétiques et déterministes pour battre le hashing. Une sortie statistiquement improbable, trop uniforme, ou identique entre des sessions « différentes » signale la synthèse.
- Concurrence matérielle, mémoire et géométrie d'écran.
navigator.hardwareConcurrency,deviceMemoryet les dimensions d'écran/viewport qui contredisent la classe d'appareil déclarée (un UA de téléphone reportant un desktop 32 cœurs) cassent la cohérence.
Un profil anti-detect bien construit maintient tout ça cohérent entre eux, ce qui est exactement pourquoi le fingerprinting seul ne peut pas être toute la réponse. Il élève le coût et attrape la couche bâclée ; le comportement ferme le reste.
Signaux comportementaux : ce que le spoofing ne peut pas supprimer
La couche fingerprint décrit l'appareil. La couche comportementale décrit l'opérateur, et c'est bien plus difficile à falsifier parce que ça doit être produit en direct, à chaque session. Les humains interagissent avec imprécision : les trajectoires de souris courbent et dépassent, la vitesse de scroll varie, les remplissages de formulaire incluent des pauses, des fautes de frappe et des corrections, et il existe un écart mesurable entre page prête et première interaction.
Les sessions automatisées tendent vers l'inverse : remplissages instantanés sans correction, navigation sans hésitation, scroll à intervalles fixes, et timing d'événements avec un jitter quasi nul. Rien de tout ça n'est supprimé par un override navigator.webdriver ou un hash canvas propre, parce que ça vient de la façon dont l'agent agit, pas de ce qu'il prétend être. La corrélation cross-session termine le travail. De nombreuses sessions dans un court intervalle qui partagent des traits structurels de fingerprint, de timing comportemental et d'actions post-session révèlent une coordination qu'aucune session unique n'exposerait. Pour voir comment le tooling agentic tente spécifiquement d'imiter le rythme humain, lisez comment les agents OpenClaw contournent la détection de bots.
Comment transformer les signaux en décision
La détection n'est utile que si elle entraîne une réponse graduée. Ne bloquez pas sur un seul signal ; pondérez-en plusieurs et agissez sur la convergence.
- Instrumentez les quatre classes de signaux au runtime, à l'intérieur de la session navigateur.
- Comparez l'environnement déclaré (user-agent, plateforme, classe d'appareil) à l'environnement observé et enregistrez chaque mismatch.
- Ajoutez le contexte réseau (IP datacenter vs. résidentielle, ASN, comportement proxy et geo-shift) comme poids, jamais comme verdict unique.
- Scorez la session sur la convergence de signaux indépendants, et conservez l'ensemble des signaux bruts, le motif de risque et le résultat du challenge comme preuve.
- Bloquez les sessions haute confiance aux points les plus critiques, comme l'enregistrement, où la détection au niveau navigateur attrape la création de faux comptes, et le checkout. Challengez celles à confiance moyenne avec une friction step-up, et autorisez-avec-monitoring pour le trafic agent légitime.
AI Agent Detection de cside exécute ça depuis l'intérieur de la page : il lit les signaux d'automatisation et CDP, capture les signaux appareil et IP réelle, fait émerger les incohérences de fingerprint, et observe le comportement sur la session, puis laisse les équipes autoriser l'automatisation bonne connue, challenger les sessions suspectes, et bloquer les agents à haut risque avec une traîne d'audit complète.
