Comment les éditeurs de navigateurs rendent discrètement l’automatisation plus difficile à détecter

Les éditeurs de navigateurs ont toujours eu une position officielle sur l’automatisation : la transparence.

Lorsque le W3C a rédigé la spécification WebDriver — avec la contribution de Google, Microsoft et d’autres grands éditeurs de navigateurs — il a inclus une exigence claire. Les navigateurs contrôlés par des outils d’automatisation doivent s’identifier comme automatisés. Le mécanisme est une propriété JavaScript appelée navigator.webdriver. Elle est définie sur true, et tout site web peut la vérifier.

Pendant des années, cette transparence était une évidence. Les entreprises qui expédiaient les navigateurs étaient également celles qui aidaient à rédiger les règles. On partait du principe que leur respect resterait la norme.

Mais à mesure que les agents d’IA prennent en charge de plus en plus de tâches que les humains faisaient autrefois manuellement — naviguer, cliquer, remplir des formulaires en leur nom — la frontière entre « automatisé » et « humain » devient plus difficile à tracer. Et les navigateurs commencent à en tenir compte.

La règle et son fonctionnement

La spécification WebDriver existe sous sa forme actuelle depuis 2018, bien que l’automatisation des navigateurs remonte à bien plus loin. Le drapeau navigator.webdriver a été intégré dès le départ : un signal simple et lisible qui disait : « Ce navigateur est contrôlé par un script. »

En pratique, ce n’était jamais le seul signal. Les opérateurs de bots déterminés ont toujours su comment basculer navigator.webdriver sur false manuellement, donc les outils de détection ont construit des méthodes plus sophistiquées par-dessus : analyser les empreintes digitales JavaScript, les incohérences du navigateur, les modèles de comportement et, plus récemment, les signaux du Chrome DevTools Protocol (CDP). Nous avons longuement écrit sur cette histoire.

Ce que l’on a toujours supposé, cependant, c’est que le navigateur lui-même resterait en dehors de cela. Le jeu opposait les développeurs de bots aux outils de détection. Le navigateur était une infrastructure neutre une plateforme qui transportait le signal, et non une plateforme qui le modifiait. Ce n’est plus le cas.

Playwright 1.53.0 : quand l’automatisation pilotée par l’IA a cessé de s’annoncer

Playwright de Microsoft est l’un des frameworks d’automatisation de navigateurs les plus utilisés au monde. Il alimente des suites de tests légitimes, des outils de développement et une part importante du trafic de bots. En juin 2025, la version 1.53.0 a été livrée avec une modification qui n’était mentionnée ni dans la documentation ni dans les notes de mise à jour.

Lorsqu’un agent d’IA pilote Playwright, navigator.webdriver est désormais défini sur false, soit la même valeur que renvoie un navigateur normal piloté par un humain. Le navigateur ne reste pas silencieux quant à son statut automatisé, mais signale le contraire.

Dans les tests Playwright normaux, navigator.webdriver est indiqué comme true.

Dans les tests Playwright MCP, navigator.webdriver est indiqué comme false.

Notre équipe de recherche sur les menaces Galileo a découvert cela lors de tests de routine. Des améliorations connexes ont continué à être livrées aussi récemment qu’en mai 2026, le tout sans commentaire public. 

Dans le fichier Playwright MCP, le code désactive webdriver en définissant un flag Chrome.

Microsoft propose désormais des agents Copilot qui naviguent sur le web au nom d’utilisateurs réels. À mesure que l’IA prend en charge davantage de tâches autrefois effectuées manuellement par les humains, la dichotomie traditionnelle — humain contre automatisé — commence à s’effriter. Que cela ait motivé cette décision ou non, l’effet est le même : un agent IA agissant en votre nom ne s’annonce plus comme tel.

V8 : Google ferme la fenêtre de détection CDP

Un autre changement récent suit le même schéma.

En mai 2025, Google a publié deux correctifs pour V8, le moteur JavaScript qui alimente Chrome et Edge. Les deux visaient la même chose : une méthode bien connue pour détecter quand un navigateur est contrôlé via le Chrome DevTools Protocol (CDP).

• Correctif 1 : Prévenir les effets secondaires lors de l’aperçu des objets — soumis le 7 mai 2025
• Correctif 2 : Prévenir les effets secondaires lors de l’aperçu des erreurs — soumis le 9 mai 2025

CDP est le protocole sous-jacent que Playwright, Puppeteer et la plupart des frameworks d’automatisation modernes utilisent pour contrôler les navigateurs basés sur Chromium. Détecter qu’un navigateur y est connecté permet de détecter efficacement la plupart des bots modernes en une seule vérification, quels que soient les autres signaux qu’ils ont réussi à masquer.

Nous avons documenté l’une des techniques de détection CDP les plus efficaces en 2024 : lorsque le CDP est actif et que le framework d’automatisation a envoyé une commande Runtime.enable, V8 sérialise les objets d’une manière qui déclenche un getter personnalisé sur l’objet Error de JavaScript. Un script peut observer si ce getter est déclenché. Si c’est le cas, le navigateur a un client CDP connecté. Sinon, il ne l’a pas.

La technique s’est rapidement répandue. Elle est devenue bien documentée dans la communauté du développement de bots et a été intégrée dans les suites de tests pour les frameworks anti-détection. Certains frameworks avancés travaillaient déjà à la contourner en évitant complètement Runtime.enable. Les correctifs V8 retirent cette possibilité de contournement des mains des développeurs de bots individuels et l’intègrent directement dans le navigateur.

Ces deux correctifs V8 ferment cette fenêtre. Ils modifient la manière dont V8 gère les aperçus d’objets et d’erreurs dans l’inspecteur afin que le getter ne soit plus déclenché lors des sessions activées par CDP. 

Dans la revue de code, l’auteur du correctif a explicitement référencé la détection CDP comme l’un des mauvais usages connus que les changements visaient à adresser. Les changements ont été présentés comme une amélioration de la sécurité — empêchant l’utilisation abusive des outils d’inspection du navigateur. L’effet sur la détection des bots est une conséquence de cela, qu’il soit intentionnel ou non. Les deux correctifs ont été fusionnés dans la branche principale de V8 sans discussion plus large dans l’industrie. Les navigateurs basés sur Chromium — Chrome, Edge, Brave et autres — ne présentent plus le comportement qui rendait cette méthode de détection efficace.

Quand l’automatisation devient la norme 

Les éditeurs de navigateurs ont toujours été confrontés à un dilemme entre permettre l’automatisation et permettre la détection. Pendant la majeure partie de la dernière décennie, ce dilemme s’est résolu en faveur de la transparence : les outils officiels devaient s’annoncer, tandis que les outils non officiels pouvaient tenter de se cacher.

L’essor des agents IA a fondamentalement changé la signification de l’automatisation. Pendant la majeure partie de l’histoire d’Internet, l’automatisation était un outil de développement, parfois utilisé pour tester des logiciels ou, entre de mauvaises mains, pour faire fonctionner des bots à grande échelle.

Aujourd’hui, les agents IA naviguent sur le Web au nom d’utilisateurs réels en tant que fonctionnalité courante des produits. Cela modifie le contexte dans lequel des signaux comme navigator.webdriver ont été conçus pour fonctionner. Ils ont été conçus pour un monde où l’automatisation était toujours distincte de la navigation humaine. Ce monde est en train de changer.

Ce qui est frappant, c’est l’absence de débat plus large au sein du secteur autour de cette évolution. La spécification du W3C qui a établi ces signaux n’a pas été mise à jour pour refléter ce nouveau paysage, et il n’y a eu aucune réflexion publique sur ce que ces changements signifient pour l’écosystème Web au sens large. Les outils évoluent plus vite que les normes.

Ce que cela signifie pour le secteur

Ce n’est pas une nouvelle technique d’attaque de la communauté des bots. C’est quelque chose de plus difficile à contrer : un changement structurel effectué par les fournisseurs qui contrôlent les navigateurs.

Les équipes de sécurité et de lutte contre la fraude qui s’appuient sur des outils de détection de bots fortement basés sur des signaux au niveau du navigateur —navigator.webdriver, détection CDP, indicateurs de mode headless — devraient se poser une question précise : Dans quelle mesure notre protection dépend-elle de signaux qui s’estompent à mesure que la nature même de l’automatisation des navigateurs évolue ?

Pour les outils plus simples ou plus anciens, la réponse honnête peut être : plus qu’ils ne voudraient l’admettre. Les signaux du navigateur qui indiquaient autrefois de manière fiable l’automatisation ne sont plus une évidence, et le changement vient de l’intérieur de la plateforme, pas du paysage des menaces. 

Pourquoi l’approche de DataDome a été conçue pour cela 

Ces changements n’affectent pas matériellement la détection de DataDome. C’est voulu.

Les signaux navigator.webdriver et CDP font partie de notre ensemble de signaux, mais ils n’ont jamais été la vérité absolue. Les développeurs de bots trouvent des moyens de cacher l’automatisation depuis les premiers jours de Selenium — basculer navigator.webdriver sur false est devenu une pratique courante presque dès que le flag a été introduit.

Nous avons toujours supposé que ces signaux sont peu fiables car quiconque contrôle le navigateur peut les changer. Construire autour de cette hypothèse est la raison pour laquelle notre détection n’est pas exposée maintenant que les fournisseurs font la même chose à grande échelle.

La détection de DataDome est multicouche. Elle analyse des milliers de signaux en temps réel, y compris des signaux que les fournisseurs ne connaissent pas, des modèles de comportement qui reflètent comment les utilisateurs réels interagissent avec les pages, et des heuristiques basées sur l’intention qui évaluent ce qu’un visiteur essaie réellement de faire. 

Ce que ces changements de fournisseurs exposent, c’est le risque d’une détection monocouche ou dépendante des signaux du navigateur. 

Il y a un schéma dans ces deux changements qui va au-delà des spécificités : tout signal qui vit dans le navigateur est un signal que les fournisseurs peuvent supprimer. Le comportement et l’intention, c’est une autre histoire.

Vous voulez comprendre comment DataDome détecte les bots et les agents d’IA que d’autres outils ne repèrent pas ? Réservez une démo pour en savoir plus.