Undetected Chromedriver : alternative côté navigateur

L’expression « navigateur sans détection » décrit un résultat attribué par un détecteur, pas une propriété stable du binaire du navigateur. Le projet public undetected-chromedriver se présente comme un ChromeDriver modifié, tandis qu’un profil côté navigateur constitue une autre façon de configurer le navigateur. Ces approches ont des responsables, des cycles de mise à jour et des besoins de preuve différents. Pour les comparer, il faut d’abord identifier la couche qui modifie une valeur, puis mesurer uniquement une page autorisée que l’équipe contrôle. BotBrowser documente la configuration de profils côté navigateur et les limites de cohérence de l’automatisation ; il ne modifie pas undetected-chromedriver, n’assure pas la compatibilité avec ce paquet et ne promet pas le verdict d’un site ou d’un détecteur.

TL;DR

• Le README de undetected-chromedriver décrit un driver téléchargé et modifié automatiquement. Il s’agit de la présentation du projet, pas d’un résultat vérifié indépendamment pour chaque version ou chaque cible.
• Un paquet de navigateur, un driver WebDriver et le cœur du navigateur ont des responsables distincts. Modifier une couche ne prouve ni qu’une autre a changé ni qu’un site a accepté la session.
• Consignez les versions exactes du paquet et du navigateur, les options demandées, les capabilities retournées, l’origine de la fixture, l’API observée et la comparaison avec la valeur attendue. Signalez les exemples comme illustratifs.
• Utilisez uniquement une fixture que vous possédez ou êtes explicitement autorisé à tester. Cette comparaison n’explique pas comment contourner un détecteur ou interagir avec un défi tiers.
• Une valeur visible par la page, telle que navigator.webdriver, renseigne sur cette session ; elle ne prouve ni identité, ni autorisation, ni décision d’un détecteur.

Sommaire

• La description publique du projet a un périmètre
• Trois couches ont des responsables distincts
• Les changements de version entraînent différents travaux de maintenance
• Mesurer une fixture contrôlée sans rendre de verdict
• Lire le compte rendu selon la couche en échec
• La place de la configuration du navigateur
• Conclusion pratique

La description publique du projet a un périmètre

Le README du dépôt présente undetected-chromedriver comme un projet de modification de ChromeDriver. Il indique que le paquet télécharge et modifie automatiquement le binaire du driver ; son exemple crée un driver Python avec headless=True et use_subprocess=False. Ces énoncés permettent de décrire ce que le projet publie et ce qu’invoque son exemple. Ils n’établissent pas une matrice de compatibilité actuelle, ne prouvent pas que chaque modification est active dans une installation précise et ne montrent pas la décision d’un autre site.

Cette distinction importe lorsqu’un README emploie un langage catégorique sur les résultats. L’introduction du dépôt nomme des services anti-bot et affirme que le projet ne les déclenche pas. Il est exact de signaler que cette affirmation figure dans le README, mais elle ne constitue pas une mesure universelle : elle ne précise pas toutes les versions des services, les builds du navigateur, les comptes, les réseaux, les profils ou les dates concernés. Aucun test de ces services n’est effectué ici ; cette introduction n’est donc pas traitée comme un résultat. Le résultat d’un détecteur dépend de sa configuration et des conditions dans lesquelles le contrôle a été exécuté.

La page du projet et un paquet installé correspondent également à des moments différents. La branche par défaut du dépôt peut évoluer après l’installation d’une version. La version du paquet Python, le commit source, le driver téléchargé, la version de Chrome et les options de session doivent donc être enregistrés dans des champs distincts pour permettre une reproduction. Le nom du paquet ne suffit pas pour reconstruire une configuration ou interpréter un échec.

Selenium documente séparément le comportement du driver propre à Chrome et les options du navigateur, d’une part, et la réponse d’un site, d’autre part. La documentation Chrome explique l’intégration du driver ; la documentation WebDriver générale présente la création de session et les capabilities. Ces sources étayent la distinction entre une configuration demandée et une session négociée observée. Elles ne valident pas une modification tierce et ne déterminent pas ce qu’un site distant juge acceptable.

La surface observable doit être décrite avec la même précision. MDN documente navigator.webdriver comme une propriété en lecture seule qui indique si l’agent utilisateur est contrôlé par l’automatisation. C’est un signal exposé par l’API du navigateur. Ce n’est ni une identité du navigateur, ni un jeton d’autorisation, ni une description publique de tous les signaux qu’un service distant pourrait collecter. Une page qui lit cette propriété peut en rapporter la valeur ; elle ne peut pas déduire cette seule valeur tous les détails de l’implémentation du driver ou du paquet.

Cette limite des sources évite deux erreurs de catégorie fréquentes. Premièrement, le code source peut établir qu’un projet contient un chemin de code ; il ne prouve pas à lui seul que ce chemin a été exécuté dans un processus précis. Deuxièmement, une fixture locale peut établir ce qu’elle a lu ; elle ne prouve pas qu’un autre site ait recueilli les mêmes champs ou leur ait appliqué la même interprétation. Chaque affirmation doit rester associée à sa source et à ses conditions de mesure.

Trois couches ont des responsables distincts

L’expression « modification du navigateur » est trop large pour indiquer ce qui a changé. Une comparaison utile distingue le JavaScript de la page, le code WebDriver ou du paquet de driver, et le comportement du cœur du navigateur. Ces couches ont des entrées et des responsabilités de mise à jour différentes. Un problème de maintenance dans l’une ne doit pas être attribué automatiquement à une autre ; l’inventaire des signaux lus par un détecteur et la référence d’intégration d’un profil Selenium couvrent les surfaces voisines.

Couche	Responsable habituel	Ce que son artefact peut établir	Surface de mise à jour	Ce qu’il ne peut pas établir seul
Script de page	Application ou script injecté	Quel code JavaScript a été chargé et quelles API il a tenté d’envelopper	Bundles du site, extension ou script de préchargement, ordre d’exécution	Que le comportement natif du navigateur ou un verdict distant a changé
Driver ou paquet	Implémentation WebDriver et son paquet	Options de session demandées, code du driver et éventuellement version de l’exécutable téléchargé	Version du paquet, téléchargement du driver, compatibilité Selenium/navigateur	Qu’une valeur du cœur a changé ou qu’un site a accepté la session
Cœur du navigateur	Build du navigateur et configuration prise en charge	Valeurs et comportement du build sous les conditions de démarrage consignées	Version du navigateur, options du build, profil et plateforme	Que chaque page lise ces valeurs ou leur donne le même sens

Un wrapper de page s’exécute dans un contexte JavaScript. Il peut affecter les lectures des objets qu’il touche, mais la page peut aussi disposer d’autres contextes, de chemins natifs ou de valeurs contrôlées par le navigateur qui ne lui appartiennent pas. Leur pertinence doit être vérifiée avec une fixture autorisée et délimitée. La présence de noms d’API dans un fichier de modification ne prouve pas que chaque consommateur observe un résultat modifié.

Un paquet de driver gère la création de session et les artefacts de driver qu’il distribue ou modifie. L’objet d’options Selenium décrit les demandes envoyées à la création de la session. Les capabilities retournées décrivent la session négociée par l’extrémité distante. Une option demandée et une capability retournée sont donc des preuves différentes. Aucune ne dresse l’inventaire complet du comportement visible par la page : il faut le mesurer dans une page précise, avec un build et une configuration d’exécution spécifiés.

Le cœur du navigateur constitue une autre limite. Un profil peut fournir au démarrage des valeurs ou paramètres pris en charge au lieu de dépendre uniquement d’un script qui remplace une API après le début d’exécution du document. Cela décrit l’emplacement de la configuration ; cela n’affirme pas que chaque propriété est prise en charge, que toutes les plateformes se comportent pareil ou qu’un détecteur distant acceptera le résultat. La documentation du profil fait autorité pour les champs et entrées pris en charge ; le mot « profil » ne justifie aucune déduction sur un comportement non documenté.

Ces couches peuvent coexister dans une même exécution. Selenium peut créer la session, le navigateur charger un profil configuré et la page exécuter ses propres scripts. Un inventaire utile attribue chaque donnée à son responsable. Par exemple, requestedOptions appartient à la requête WebDriver, returnedCapabilities à la session négociée, profileInput au démarrage du navigateur et pageReads à la fixture contrôlée. Tout regrouper sous une étiquette comme « état sans détection » masque les limites nécessaires au diagnostic.

La surface de mise à jour suit le responsable. Un bundle de page peut changer sans mise à jour du navigateur ; un paquet de driver peut évoluer alors que le binaire du navigateur reste identique ; un nouveau navigateur peut modifier des API ou des valeurs par défaut alors que le wrapper Python n’a pas changé. Si un résultat évolue, comparez d’abord les artefacts versionnés. Sinon, une régression risque d’être imputée à un composant inchangé alors que l’entrée réellement modifiée reste inconnue.

Les changements de version entraînent différents travaux de maintenance

La gestion automatique du driver est pratique, mais l’automatisation doit savoir quel artefact elle a sélectionné. Le README indique que le paquet télécharge et modifie un driver. La version résolue du paquet, la décision de téléchargement, le chemin du driver obtenu et la version du navigateur sont donc des éléments importants. Ne déduisez pas l’exécutable téléchargé d’une instruction d’importation ni l’exécutable du navigateur de la version du paquet du driver.

Conservez au minimum un manifeste d’exécution comportant des champs de ce type :

Champ	Signification de l’exemple	Pourquoi c’est utile
packageVersion	Version de la distribution Python installée	Identifie le code du paquet, pas nécessairement le binaire Chrome sélectionné
sourceRevision	Tag ou commit si l’installation vient des sources	Distingue une branche mouvante d’une version publiée
driverVersion	Version annoncée par l’exécutable WebDriver sélectionné	Aide à diagnostiquer le démarrage de session et la compatibilité driver/navigateur
browserVersion	Version retournée par la session du navigateur	Identifie l’environnement d’exécution de la page
requestedOptions	Options explicitement configurées, secrets retirés	Montre ce que le client a demandé au driver
returnedCapabilities	Champs publics retenus pour la session	Montre ce que la négociation a retourné
fixtureRevision	Commit de la page ou fixture contrôlée	Maintient stable la cible observée
observedAt	Horodatage et identifiant de l’environnement	Permet de comparer des exécutions contrôlées

La politique de compatibilité exacte relève du projet et de sa documentation de version. Ne transformez pas la formule « testé jusqu’aux versions bêta actuelles de Chrome » d’un README en garantie pour une version Chrome, un système, un driver ou une image de CI précis. Si une combinaison compte, consignez-la et testez-la dans un environnement contrôlé. Si le projet ne documente aucune matrice pour elle, indiquez « inconnu » plutôt que de combler le manque par une déduction.

Le téléchargement géré par le paquet a également un effet sur la reproductibilité. Un agent CI neuf peut télécharger un artefact différent d’une station de travail utilisée depuis longtemps si la version du paquet, le cache ou le navigateur sélectionné diffère. Consignez le chemin résolu et la version binaire, mais ne publiez pas de secrets ni de chemins propres à une machine. Un hash stable peut distinguer des binaires si la politique autorise son partage ; il n’indique toujours pas ce que le binaire a fait auprès d’un service distant.

Un changement de version peut entraîner au moins quatre familles d’échec :

1. La résolution a changé : le paquet a sélectionné ou téléchargé un autre driver. Comparez la version du paquet, le chemin résolu et la version du driver avant d’examiner la page.
2. La négociation de session a changé : Selenium n’a pas créé la session demandée ou les capabilities retournées diffèrent. Conservez la requête et la réponse expurgées, puis vérifiez les options documentées et la compatibilité de cette version.
3. L’exécution du navigateur a changé : la session démarre, mais une valeur de la fixture diffère. Comparez la version, la plateforme, l’entrée du profil et la révision de la fixture en ne changeant qu’une variable à la fois.
4. Le résultat applicatif a changé : la fixture lit les valeurs attendues, mais le test applicatif échoue pour une autre raison. Séparez la navigation, l’autorisation et l’acceptation applicative de la configuration du navigateur.

Ces catégories sont opérationnellement distinctes. Réinstaller le paquet n’expliquera pas un sélecteur de fixture cassé ; modifier le profil ne corrigera pas une négociation WebDriver ; une réponse 403 ne prouve pas qu’une empreinte particulière en est la cause. Le compte rendu doit identifier la première limite en échec et conserver les éléments utiles à son responsable.

Un changement de paquet mérite d’être examiné même si la version du navigateur ne bouge pas. Le paquet peut modifier la résolution du driver ou la construction de la session. À l’inverse, le navigateur peut changer le résultat tandis que le code du paquet reste figé. Consignez les deux côtés afin d’identifier le composant modifié au lieu de ne garder que le résultat final.

Mesurer une fixture contrôlée sans rendre de verdict

Une fixture contrôlée peut vérifier si le harnais de test observe les valeurs attendues. Elle ne doit pas envoyer de trafic à un détecteur ni chercher à classer un service commercial de protection. Il peut s’agir d’une application locale ou d’un domaine de test interne où l’équipe contrôle le balisage, les appels API et le résultat attendu. La mesure devrait rester en lecture seule lorsque c’est possible et utiliser des valeurs synthétiques plutôt que des données de comptes ou de clients réels.

La première exécution sert de référence avec une configuration de navigateur déclarée. La seconde ne change qu’une variable, par exemple le build du navigateur ou une entrée de profil documentée. Ne changez pas simultanément paquet, navigateur, profil, bundle, viewport et système d’exploitation. Une modification multiple peut produire un écart, sans permettre d’en identifier la cause.

Le JSON ci-dessous est un schéma de compte rendu proposé, pas un résultat mesuré. Les valeurs entre chevrons sont des exemples à remplacer ; aucune exécution de BotBrowser ou d’undetected-chromedriver n’est revendiquée.

{
  "fixtureOrigin": "https://owned-fixture.example.test",
  "fixtureRevision": "<commit-sha>",
  "package": {
    "name": "<package-name>",
    "version": "<resolved-version>",
    "sourceRevision": "<release-tag-or-commit>"
  },
  "browser": {
    "driverVersion": "<reported-driver-version>",
    "browserVersion": "<reported-browser-version>",
    "platformName": "<reported-platform>"
  },
  "requestedOptions": ["<sanitized-option-name>"],
  "observations": [
    {
      "surface": "navigator.webdriver",
      "expected": "<fixture-specific-expectation>",
      "observed": "<actual-fixture-value>",
      "match": false
    }
  ],
  "applicationResult": {
    "httpStatus": 200,
    "fixtureSchemaValid": true
  },
  "observedAt": "<UTC-timestamp>"
}

Remplacez chaque marqueur par les données d’une exécution réelle avant de considérer le compte rendu comme une preuve. La valeur attendue doit être propre à la fixture ; une attente booléenne ne définit pas une politique pour des sessions sans rapport. Si un champ manque, utilisez null et expliquez pourquoi. Ne qualifiez pas un exemple de « réussi », n’inventez pas d’horodatage et ne présentez pas un JSON fictif comme une observation.

La fixture doit exposer une réponse réduite et explicite au lieu de collecter une empreinte complète du navigateur. Par exemple, un endpoint peut renvoyer la révision de la fixture et la valeur observée de navigator.webdriver. Un journal côté serveur peut noter séparément le chargement de la page. Il n’est pas nécessaire de recueillir canvas, polices, adresses locales, identifiants de compte ou attributs d’appareil sans rapport pour comparer le paquet et le navigateur. La minimisation des données lie la mesure à son cas d’acceptation.

Un tableau de comparaison utile comporte une ligne par exécution contrôlée :

Exécution	Entrée modifiée	Identifiants du paquet et du navigateur	Observation de page	Résultat de la fixture	Interprétation
A	Référence	Versions consignées du paquet, du driver et du navigateur	Valeur exacte renvoyée par la page contrôlée	Schéma et statut	Décrit uniquement la référence
B	Une entrée documentée	Mêmes versions sauf si l’une est la variable	Valeur exacte renvoyée par la page contrôlée	Schéma et statut	L’écart est associé à l’entrée modifiée, pas à un verdict tiers

Ne répétez la mesure que si des conditions non déterministes peuvent expliquer le résultat et consignez chaque tentative. Répéter ne donne pas le droit de sonder une cible distante. Si la fixture contrôlée renvoie une erreur, le compte rendu indique le statut HTTP et si le contrat de la fixture est satisfait. Le statut et la validation du schéma sont distincts : une réponse HTTP réussie peut contenir des données invalides ; un refus peut signaler correctement que la fixture a bloqué une demande non autorisée.

Lire le compte rendu selon la couche en échec

Commencez par la première limite qui a échoué. Si le processus du navigateur n’a pas démarré, il n’existe aucune observation de page. Si la création de session a échoué, n’interprétez pas une ancienne valeur de page comme le résultat de la nouvelle session. Si la fixture s’est chargée mais que son schéma échoue, rapportez séparément le problème d’extraction et la version du navigateur. Cette séparation évite de condenser plusieurs faits sans rapport en un unique état rouge ou vert.

Élément de preuve	Ce qu’il étaye	Ce qui reste inconnu
Fichier de verrouillage et révision source du paquet	Quelle version ou quel snapshot source a été installé	Si chaque branche du paquet a été exécutée durant cette session
Journal de démarrage et version annoncée du driver	Quel driver a démarré et si la création de session a progressé	Comment un site distant a interprété la session
Capabilities WebDriver retournées	Quels champs de session l’extrémité distante a renvoyés	Si chaque option a modifié la sortie visible par la page
Observation d’une fixture contrôlée	Ce que la fixture a lu sous les conditions consignées	Ce qu’un service tiers a recueilli ou décidé
Statut HTTP et résultat de schéma de la fixture	Si l’application contrôlée a renvoyé un enregistrement accepté	Si l’accès à un site tiers est autorisé ou conforme

Si les versions du paquet et du navigateur sont connues mais que les capabilities demandées et retournées diffèrent, examinez la configuration de session. Si la session existe mais que la valeur de fixture change, comparez navigateur, profil, système et révision de fixture. Si la fixture donne le résultat attendu alors qu’un site distant affiche une page de refus, arrêtez-vous et suivez sa politique d’accès publiée. Cette réponse ne révèle pas le signal responsable sans preuve fournie par le service concerné.

Gardez les extraits de journaux courts et masquez cookies, en-têtes d’autorisation, données de compte, contenu du profil et secrets propres à la machine. Un manifeste d’exécution reste utile sans inclure le journal complet du driver. Conservez la révision source, les options expurgées, les catégories de résultat et assez d’horodatages pour relier le compte rendu au travail CI. L’objectif est la reproductibilité, pas la collecte de chaque donnée imaginable.

Avant de comparer deux paquets, normalisez les entrées contrôlées. Utilisez la même révision de fixture et les mêmes données applicatives. Si les paquets nécessitent des configurations de driver différentes mais documentées, indiquez-les comme partie de la comparaison au lieu de les présenter comme identiques. Ne combinez pas une comparaison de paquets et une mise à niveau du navigateur. La conclusion doit préciser les combinaisons observées et laisser les autres comme non testées.

La place de la configuration du navigateur

La configuration côté navigateur répond à une question de maintenance différente de la modification d’un paquet WebDriver. Elle fournit des réglages documentés au démarrage du navigateur ou dans son profil, au lieu de s’appuyer uniquement sur un wrapper de page ou sur une modification du driver gérée par un paquet. Le choix dépend de la configuration prise en charge, de l’interface d’automatisation nécessaire, des plateformes visées et de la politique de mise à jour de l’équipe.

La documentation des profils BotBrowser décrit les entrées de profil prises en charge. La référence de cohérence de l’automatisation décrit les limites du produit associées à l’automatisation. Ces sources étayent les déclarations de configuration et de périmètre documentés. Elles ne prouvent pas que Selenium, un Grid particulier ou undetected-chromedriver sont pris en charge sans documentation explicite de l’intégration correspondante. Le démarrage d’un exécutable navigateur ne vaut pas validation d’une intégration WebDriver.

La comparaison ne répond donc pas à « quel outil gagne ? ». Posez plutôt trois questions précises : quel composant possède la modification ? Quelle version faut-il suivre ? Quelle preuve confirme la valeur sur une page contrôlée ? Une équipe dont l’application requiert une capability propre au driver peut choisir un flux WebDriver documenté. Une équipe ayant besoin de réglages côté navigateur évaluera les entrées de profil prises en charge et l’intégration exacte. Une équipe qui maintient des scripts de page testera les contextes réellement affectés par ces scripts. Il s’agit de choix d’ingénierie, pas de résultats universels de détection.

Les déclarations sur le produit doivent respecter le périmètre publié. BotBrowser fournit, via la configuration du profil, des valeurs documentées côté navigateur ; il ne modifie pas un driver tiers et ne suit pas le calendrier de sortie de ce projet. Il ne garantit ni verdict d’un détecteur, ni réponse d’un site, ni identité, ni autorisation, ni accès. L’existence d’un profil ne prouve pas son chargement ; cette affirmation nécessite la preuve de chargement documentée par le produit. La fixture du lecteur reste la preuve des valeurs qu’elle a observées.

Ce périmètre est volontairement plus étroit qu’un guide de contournement. Il ne donne pas d’étapes pour atteindre une page protégée, modifier un résultat de détection ou changer des signaux jusqu’à l’acceptation d’une session. Le résultat est une comparaison de maintenance et un schéma de compte rendu pour des tests contrôlés. Lorsqu’un site refuse l’accès, respectez sa politique et utilisez une intégration ou une procédure d’autorisation approuvée.

Questions fréquentes

Le README prouve-t-il qu’une version actuelle fonctionne partout ?

Non. Il décrit l’objectif déclaré du projet et un résumé de sa mise en œuvre. Il ne fournit pas de matrice datée et complète des versions de services, comptes, builds navigateur et environnements qui étayerait un résultat universel.

Une capability WebDriver prouve-t-elle que le profil a été chargé ?

Non. Une capability décrit des informations de session renvoyées par WebDriver. Le chargement du profil est un fait distinct du démarrage du navigateur et nécessite la preuve prise en charge par le produit.

navigator.webdriver est-il un score de détecteur ?

Non. MDN le décrit comme une propriété du navigateur signalant le contrôle par automatisation. Une page peut l’observer, mais cette valeur n’encode ni le modèle ni la décision d’un fournisseur.

Une fixture locale prédit-elle la décision d’un service commercial ?

Non. Elle vérifie uniquement son propre contrat dans les conditions consignées. Le service externe contrôle ses entrées, sa politique et son résultat.

Que faut-il inclure dans une comparaison de versions ?

Consignez le paquet et sa révision source, les versions du driver et du navigateur, les options expurgées, la révision de fixture, la valeur d’API observée ainsi que les résultats HTTP et de schéma séparément. Ne modifiez qu’une entrée par comparaison.

Lectures complémentaires

Pour distinguer les wrappers JavaScript de page, consultez les limites des modifications de page ; pour les entrées de profil, consultez l’intégration Selenium avec un profil.

Sources

• Dépôt public et README d’undetected-chromedriver
• Selenium : fonctionnalités propres à Chrome
• Selenium : options de navigateur
• Cohérence de l’automatisation BotBrowser
• Configuration des profils BotBrowser
• MDN : Navigator.webdriver

Conclusion pratique

Comparez d’abord les responsables, puis les affirmations. Le README présente un paquet qui télécharge et modifie un driver ; Selenium consigne la négociation de session ; les profils navigateur configurent des valeurs de démarrage documentées ; une page contrôlée ne rapporte que ce qu’elle lit. Suivez ces versions séparément, ne changez qu’une entrée contrôlée à la fois et conservez un compte rendu qui distingue le démarrage du navigateur, la négociation de session, les observations de page et les résultats applicatifs. Aucun de ces éléments ne prouve une identité ni ne prédit un verdict tiers. Utilisez cette comparaison pour choisir une intégration maintenable et documentée pour un usage autorisé, puis respectez la limite d’accès du site.