Scraping avec Selenium : capacités et relevés

Selenium peut piloter un navigateur pour une collecte autorisée, mais la création d'une session WebDriver valide n'en est qu'une frontière. Une exécution utile identifie aussi le binaire et la session négociée, attend le véritable signal de disponibilité de la page contrôlée, valide chaque enregistrement extrait et s'arrête lorsque la politique d'accès ou la réponse du site l'exige. BotBrowser documente les profils transmis par fichier et les paramètres CLI de lancement ; ces options configurent les entrées du navigateur, mais BotBrowser ne garantit pas le chargement du profil, la compatibilité Selenium/Grid ni la réponse d'un site tiers. Selenium reste responsable de sa session WebDriver et du contrat de collecte propre à l'application.

Résumé

• Sélectionnez explicitement l'exécutable avec l'API des options du navigateur, puis consignez les capacités retournées par la session créée au lieu de supposer que les valeurs demandées ont été acceptées.
• Séparez le fichier de profil BotBrowser, le répertoire de données Chromium, le service Selenium et les résultats de l'exécution ; attribuez un responsable à chacun.
• driver.get() marque une limite de navigation du document ; un catalogue rendu côté client exige une condition de disponibilité distincte et bornée.
• Validez une ligne comme une donnée : titre, URL de détail de même origine et prix ou état de disponibilité explicite sont requis avant acceptation.
• navigator.webdriver et les capacités décrivent une session automatisée ; ils ne prouvent ni identité, ni autorisation, ni chargement du profil, ni décision d'un site.

Sommaire

• Définir l'exécution et ses éléments de preuve
• Choisir le navigateur et configurer la session
• Consigner les capacités sans les surinterpréter
• Attendre la disponibilité du catalogue
• Valider les enregistrements et classer les résultats
• Expliciter la frontière d'identité
• Conclusion pratique

Définir l'exécution et ses éléments de preuve

Commencez par un catalogue que vous possédez ou que vous êtes autorisé à collecter. Précisez son URL d'entrée permise, les champs nécessaires au traitement suivant, le nombre maximal d'enregistrements, la cadence approuvée par son propriétaire et les conditions d'arrêt. Ce contrat distingue une liste réellement vide d'un script qui a accepté des données mal formées. Une exécution limitée peut lire une page et produire une ligne JSON pour chacune de 40 cartes visibles au maximum. La limite de 40 appartient à cette tâche ; elle ne recommande aucune cadence pour d'autres sites.

Placez le contrat de données près du code. Par exemple, title doit être un texte non vide après suppression des espaces ; href, une URL absolue sur l'origine autorisée ; price, un montant décimal et sa devise ou un état explicite tel que out-of-stock. Ne remplacez pas une valeur absente par un défaut inventé comme zéro. Un prix nul, un prix manquant et un prix masqué derrière une demande de consentement sont trois états différents. Conservez cette distinction afin que le consommateur décide si la ligne est exploitable.

Le relevé d'exécution décrit les entrées qui peuvent modifier le résultat sans retenir inutilement le contenu de la page : révision du fixture applicatif, URL initiale, identifiant du binaire, versions du driver et du navigateur, stratégie de chargement, langue si nécessaire, heure de début et nombres de lignes acceptées ou rejetées. Excluez secrets, cookies, en-têtes d'autorisation, répertoires de profil entiers et texte sans rapport avec la tâche. Si un échec nécessite une capture ou un fragment DOM, utilisez uniquement le fixture contrôlé ou la plus petite région autorisée, masquez les données personnelles et respectez la durée de conservation.

Avant de connecter une tâche proche de la production, utilisez un fixture connu. Il peut fournir un marqueur prévisible, quelques lignes, un prix manquant et un état d'accès refusé. Le script peut ainsi vérifier qu'il accepte les lignes valides, rejette les lignes incomplètes et s'arrête à une frontière de politique. Le fixture teste le contrat d'extraction ; il ne démontre pas la réponse d'un autre site ni l'interprétation d'un détecteur.

Décidez avant l'implémentation si les URL des cartes mèneront aux pages de détail. L'exemple se limite aux cartes du catalogue et ne visite pas leurs liens : naviguer vers un détail crée un deuxième contrat de page, des requêtes supplémentaires et une nouvelle limite d'autorisation. Une tâche distincte peut en définir les règles si le propriétaire des données l'autorise. Cette séparation rend l'instantané de liste vérifiable et empêche une boucle pratique d'élargir silencieusement la collecte.

Choisir le navigateur et configurer la session

La documentation Chrome de Selenium montre comment sélectionner un binaire et ajouter des arguments via les options Chrome. Ce mécanisme choisit un exécutable installé dans l'environnement ; il ne certifie pas la compatibilité de tous les navigateurs dérivés ni de toutes les versions du driver. Épinglez navigateur et driver selon le processus de versionnement de l'environnement et consignez leurs versions. Si la session ne démarre pas, vérifiez d'abord la découverte du binaire et la compatibilité du driver, pas les sélecteurs de page ou le schéma de données.

Les recettes CLI de BotBrowser montrent un fichier de profil passé avec --bot-profile et un --user-data-dir distinct. La référence de configuration des profils indique que les options CLI priment sur la configuration de profil et les valeurs par défaut, que les anciens fichiers .enc publics sont en lecture seule, que l'entrée de profil est un fichier et que la version majeure du profil doit correspondre à celle du binaire. Ce sont des entrées de lancement, pas des capacités Selenium créées avec Options.set_capability(). Dans un environnement qui prend explicitement en charge le binaire et le driver sélectionnés, une tâche autorisée peut transmettre les arguments documentés par les options Chrome. Elle doit utiliser un chemin absolu permis et un répertoire de données séparé, conformément aux règles applicables.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.support.ui import WebDriverWait

options = Options()
options.binary_location = "/opt/approved-browser/chrome"
options.add_argument("--bot-profile=/srv/browser-inputs/profile.enc")
options.add_argument("--user-data-dir=/srv/browser-state/run-2026-11-08-01")
options.page_load_strategy = "eager"

driver = webdriver.Chrome(options=options)
try:
    driver.set_page_load_timeout(35)
    driver.get("https://catalogue.example.test/items")
    WebDriverWait(driver, 18).until(
        lambda browser: browser.find_element(
            "css selector", "[data-testid='catalogue-ready']"
        ).get_attribute("data-state") == "ready"
    )
finally:
    driver.quit()

Les chemins sont des exemples à remplacer par ceux du runner autorisé. Ne placez pas d'identifiants dans l'argument de profil, le code source ou les journaux. Ne réutilisez pas simultanément le même profil ou répertoire de données. Un répertoire géré peut conserver des états entre exécutions : attribuez-lui un propriétaire, décidez s'il est éphémère et fermez le navigateur avant de le réutiliser. Le guide des sessions driver Selenium explique que la construction du driver crée la session et que quit() la termine. Le bloc finally est important car la navigation, l'attente ou l'extraction peuvent échouer avant la fermeture normale.

Avec WebDriver distant ou Grid, le binaire et les chemins sont interprétés sur le nœud qui démarre le navigateur, pas nécessairement sur le processus qui envoie les commandes Python. Un chemin absolu sur la machine cliente n'existe pas automatiquement sur le nœud distant. Documentez l'image de ce nœud, le provisionnement des versions, la livraison du profil, le stockage temporaire et la propriété du répertoire. Si personne ne peut vérifier le montage du profil et le responsable du répertoire de données, ne démarrez pas une session dont l'état est ambigu.

Choisissez la stratégie de chargement pour la limite du document, pas comme raccourci vers la disponibilité de l'application. Selenium décrit normal comme l'attente de l'état complet du document, eager comme un retour lorsque le document est interactif et none comme l'absence d'attente d'un état de chargement. Le réglage vaut pour toute la session WebDriver. Il ne détermine pas quand les données d'un catalogue monopage sont disponibles ; une condition explicite doit définir ce contrat applicatif. Pour commencer, conservez normal par défaut, sauf si l'application exige un retour plus tôt et qu'un prédicat explicite est défini.

Consigner les capacités sans les surinterpréter

Après le démarrage du driver, enregistrez une projection réduite et vérifiée de driver.capabilities. La référence des options navigateur Selenium documente notamment browserName, browserVersion, platformName et pageLoadStrategy ; la classe d'options définit le nom du navigateur. Ces valeurs constituent un reçu de session WebDriver négociée. Elles permettent de comparer la demande à ce que le driver rapporte. Elles ne prouvent pas l'acceptation d'un profil chiffré, le chargement de chaque surface du profil ou l'acceptation du navigateur par un site.

capabilities = driver.capabilities
capability_receipt = {
    "browserName": capabilities.get("browserName"),
    "browserVersion": capabilities.get("browserVersion"),
    "platformName": capabilities.get("platformName"),
    "pageLoadStrategy": capabilities.get("pageLoadStrategy"),
}

Validez le reçu avant la navigation. Si browserName ne désigne pas la famille attendue ou si browserVersion sort de l'intervalle autorisé, arrêtez et classez le problème comme configuration de session. Ne remplacez pas la version retournée par celle déduite du chemin demandé. Gardez d'autres champs spécifiques au fournisseur seulement si leur sens est documenté et utile. Copier toutes les capacités peut conserver des métadonnées d'implémentation sans rendre la comparaison plus claire.

Séparez la configuration demandée du reçu retourné. Si page_load_strategy="eager" était demandé mais qu'une autre valeur a été négociée, rendez l'écart visible. De même, un chemin de profil dans la configuration du runner est une entrée, pas une preuve de chargement. La vérification du profil doit utiliser la preuve de démarrage prévue par le produit et la procédure autorisée. Aucune exécution BotBrowser n'est affirmée ici.

Écrivez le reçu avant la navigation puis ajoutez le résultat terminal. Les catégories peuvent inclure session-start-failed, navigation-timeout, readiness-timeout, access-boundary, schema-rejected, complete et cleanup-failed. Gardez comme résultat principal le premier échec qui explique l'arrêt ; consignez séparément une erreur de nettoyage ultérieure. Une réponse de politique ne devient ainsi pas une erreur de sélecteur parce que le script a continué à chercher dans la page.

Attendre la disponibilité du catalogue

La fin de driver.get() ne signifie pas que toutes les lignes ont été insérées ou hydratées. Elle marque la limite de navigation du document choisi. Le code client peut demander les données ensuite, afficher un indicateur de chargement puis le remplacer par des cartes. À l'inverse, la page peut encore charger des recommandations sans rapport après que la liste demandée est prête. Attendre la fin de tout le réseau ne constitue pas toujours un résultat métier pertinent. La collecte doit nommer le marqueur qui indique que le catalogue contrôlé est réellement prêt.

Utilisez un WebDriverWait explicite autour d'une condition stable publiée par la page autorisée. Un élément documenté avec data-state="ready", un message d'état accessible ou un nombre de résultats connu peuvent servir de prédicat. Évitez une classe d'animation ou une pause fixe de 10 secondes. Une pause fixe gaspille du temps si les résultats arrivent tôt et échoue s'ils arrivent plus tard. Une attente bornée fournit un résultat exploitable. Les 18 secondes de l'exemple sont illustratives et non universelles : choisissez la limite selon l'objectif de service de l'application contrôlée.

Le prédicat doit être en lecture seule. WebDriver peut l'évaluer plusieurs fois ; il ne doit donc pas cliquer, soumettre de formulaire, faire défiler pour charger davantage de lignes ou modifier la page. Si la pagination est autorisée, traitez chaque transition séparément : vérifiez l'état courant, collectez les lignes acceptées, déclenchez une seule action suivante puis attendez un nouvel état ou identifiant de page. Arrêtez-vous à la limite convenue et consignez-la. Ne cliquez pas en boucle si le numéro de page ne change pas.

Une limitation de débit peut donner des résultats distincts. Une réponse bornée avec délai de reprise, un état d'application demandant d'attendre, une page de challenge, une redirection de connexion et un sélecteur absent ne sont pas interchangeables. Respectez la politique publiée et le budget de requêtes permis par le propriétaire. Si une frontière d'accès apparaît, arrêtez et conservez uniquement la catégorie minimale. N'automatisez pas la résolution de challenges, le contournement de contrôles ou l'augmentation de cadence pour forcer un résultat. Le script peut signaler l'absence de l'état attendu ; il ne décide pas si l'accès peut continuer.

Valider les enregistrements et classer les résultats

Transformez chaque ligne en enregistrement typé avant sérialisation. Supprimez les espaces du texte visible, résolvez les liens par rapport à l'URL du catalogue, exigez l'origine permise et rejetez les valeurs invalides. Si le prix utilise un séparateur local, analysez-le selon la langue déclarée plutôt que de supprimer arbitrairement la ponctuation. Si la page affiche prix et disponibilité, conservez les deux. Ne stockez pas une description si la tâche ne requiert que le titre, l'URL et le prix ou l'état.

from urllib.parse import urljoin, urlparse

def normalized_origin(url):
    try:
        parsed = urlparse(url)
        hostname = parsed.hostname
        port = parsed.port
    except ValueError:
        return None
    scheme = parsed.scheme.lower()
    if scheme not in {"http", "https"} or not hostname or parsed.username is not None or parsed.password is not None:
        return None
    effective_port = port if port is not None else (443 if scheme == "https" else 80)
    return scheme, hostname.lower(), effective_port

def parse_card(card, page_url, allowed_origin):
    title = card.find_element("css selector", "[data-testid='title']").text.strip()
    href = card.find_element("css selector", "a[data-testid='detail-link']").get_attribute("href")
    absolute_url = urljoin(page_url, href or "")
    price_nodes = card.find_elements("css selector", "[data-testid='price']")
    status_nodes = card.find_elements("css selector", "[data-testid='availability']")
    price = price_nodes[0].text.strip() if price_nodes else None
    status = status_nodes[0].text.strip() if status_nodes else None

    if not title or normalized_origin(absolute_url) != allowed_origin:
        return None, "schema-rejected"
    if not price and not status:
        return None, "missing-price-or-status"
    return {"title": title, "href": absolute_url, "price": price, "status": status}, None

Calculez allowed_origin une fois depuis une URL de départ autorisée avec la même fonction normalized_origin, jamais à partir d'un lien extrait. Cet exemple accepte uniquement HTTP et HTTPS et compare le schéma, l'hôte et le port effectif normalisés, y compris les ports par défaut 80 et 443 ; un port mal formé est rejeté. Centralisez la normalisation des URL et testez les ports par défaut, les hôtes internationalisés, les redirections et les liens relatifs. N'ouvrez pas un href simplement parce qu'une carte en contient un. Extraction et navigation relèvent de permissions distinctes.

Ne considérez pas un ensemble vide comme une collecte correcte par défaut. Un catalogue vide peut être valide, mais le marqueur peut aussi apparaître avant l'insertion des données, un filtre peut supprimer tous les résultats ou le contrat de page peut avoir changé. Exigez un compte ou un état vide explicite. Si la page déclare zéro résultat, émettez empty-catalogue avec la révision de page puis arrêtez. Si le marqueur attendu manque, classez un délai d'attente dépassé au lieu de produire un fichier vide réputé valide.

Comptez les résultats et consignez la raison de chaque rejet. Par exemple, 36 lignes acceptées, deux prix manquants et deux URL d'autre origine diffèrent de 40 lignes acceptées. Un résumé peut indiquer accepted=36, rejected=4 et les totaux par motif sans conserver le corps de la page. Rejetez les URL normalisées en double si le consommateur attend une ligne par produit, mais indiquez le nombre de doublons au lieu d'écraser silencieusement l'ancienne ligne.

Résultat	Preuve minimale	Propriétaire suivant
Le navigateur ou le driver ne crée pas la session	erreur assainie, identifiant du binaire et versions	image du runner
Les capacités sont hors liste permise	reçu à quatre champs et stratégie demandée	configuration WebDriver
La navigation dépasse la limite	hôte d'entrée, catégorie de délai et dernier état	application ou réseau
Le catalogue n'atteint pas son état prêt	nom de condition, durée écoulée et compte éventuel	contrat de page
Une ligne échoue au schéma	champ rejeté et nombre de lignes invalides	contrat d'extraction
Le site présente une limite d'accès	catégorie de réponse ou état visible, sans contenu du challenge	responsable de la politique
quit() échoue après une autre erreur	erreur initiale et catégorie de nettoyage	cycle de vie du runner

Ce tableau n'autorise pas la collecte de diagnostics supplémentaires. Un HAR, une copie de profil, une base du navigateur ou une capture authentifiée peuvent contenir secrets et activité sans rapport. Commencez avec le minimum utile et élargissez uniquement avec autorisation et conformément à la politique de confidentialité. Limitez les chemins de sortie à l'exécution et appliquez la durée de conservation du projet.

Expliciter la frontière d'identité

Le fichier de profil, le binaire, les options WebDriver et les valeurs visibles depuis JavaScript sont des couches liées mais différentes. La configuration du profil peut fournir des réglages documentés ; les options CLI priment sur la configuration puis sur les valeurs par défaut. Selon la documentation produit, le binaire et le profil doivent avoir la même version majeure. Les capacités décrivent la session négociée. Aucun de ces éléments ne prouve à lui seul toutes les valeurs visibles par la page, la continuité d'une identité entre exécutions ou la classification d'une requête par un serveur.

MDN décrit navigator.webdriver comme un booléen en lecture seule indiquant que l'agent utilisateur est contrôlé par l'automatisation. C'est un signal d'automatisation visible par la page, pas un jeton d'identité, une autorisation, une empreinte complète ni un verdict de détection. Si un fixture contrôlé et autorisé doit le relever pour un test de compatibilité, consignez le booléen avec son contexte de page et de navigateur ; n'en faites pas un score d'accès.

Conservez la même limite dans les rapports. « La session WebDriver a démarré avec la version X et le fixture a retourné 36 enregistrements valides » est une affirmation vérifiable. « Le navigateur avait l'air humain », « le profil prouve l'identité du compte » ou « le site acceptera cette session » ne le sont pas. La première découle des capacités retournées et des validations propres. Les autres prêtent des décisions externes à des observations qui ne les établissent pas.

Les références publiques BotBrowser sur la configuration de profil et les recettes CLI décrivent les entrées du navigateur ; elles ne certifient pas la compatibilité Selenium et ne modifient pas le protocole WebDriver. Chaque équipe doit valider son binaire, son driver, son paquet de profil, son système d'exploitation et sa configuration dans l'environnement pris en charge. Un exemple Selenium générique n'est ni une certification produit ni une promesse d'accès à une application tierce.

Pour distinguer les sujets proches, Intégration Selenium des profils et propriété de session traite du stockage et du cycle de vie ; Attentes WebDriver Selenium et tests stables détaille les attentes. Le relevé de collecte reste limité aux capacités, une condition de disponibilité, un schéma de ligne et une frontière d'arrêt. Les détails du navigateur ne remplacent ni l'autorisation du propriétaire des données ni le contrat applicatif.

Questions fréquentes

La fin de driver.get() signifie-t-elle que le catalogue est prêt ?

Non. La stratégie de chargement décrit un état du document. Une application peut remplir les résultats ensuite ; attendez un signal propre et borné.

Les capacités prouvent-elles que le profil a été chargé ?

Non. Elles décrivent la session négociée. Le chargement du profil exige une preuve de démarrage prise en charge par le produit et la procédure autorisée.

Faut-il visiter chaque lien extrait ?

Non. Les pages de détail élargissent la tâche et le nombre de requêtes. Faites-le uniquement si le périmètre et l'autorisation définissent ce second contrat.

Sources

• Fonctionnalités Chrome spécifiques de Selenium
• Sessions driver Selenium
• Options et capacités navigateur Selenium
• Recettes CLI BotBrowser
• Configuration des profils BotBrowser
• MDN : propriété Navigator.webdriver

Conclusion pratique

Traitez la collecte Selenium comme une suite de frontières vérifiables : autorisation et schéma, navigateur et driver sélectionnés, reçu de capacités, condition bornée de disponibilité, lignes validées et fermeture normale. Séparez le profil du répertoire de données, attribuez le premier échec à son responsable et arrêtez-vous à une limite d'accès. Le relevé explique ce que le runner a observé dans un catalogue contrôlé ; il ne prouve pas le chargement du profil sans preuve produit et ne prédit pas la décision d'un tiers.