L'automatisation de navigateur — Chrome headless, Playwright, Puppeteer, Selenium — se connecte à un proxy autrement qu'un client HTTP classique : l'adresse se renseigne dans les paramètres de lancement du driver, et non dans la configuration système de l'OS. Une erreur dans cette liaison trahit le bot avant même que le moindre réglage antidetect n'entre en jeu, et l'automatisation consomme beaucoup plus de trafic qu'il n'y paraît au départ. Voyons comment le canal s'intègre dans la chaîne navigateur—driver—réseau, d'où vient la surconsommation de gigaoctets et ce qui la réduit réellement.
Comment un proxy se connecte à un navigateur headless et à son driver
Pour un navigateur headless, l'adresse n'est pas « système » : elle est inscrite dans les paramètres de lancement. Avec Chromium, c'est le drapeau « --proxy-server=host:port » ; avec Playwright et Puppeteer, le champ proxy dans les options du contexte ; avec Selenium, l'objet Proxy dans les capabilities du driver. Un réglage système redirige tout le trafic de la machine, y compris les processus d'arrière-plan ; un réglage au niveau du driver n'agit qu'à l'intérieur de la session du navigateur — c'est précisément ce qu'il faut lorsque des dizaines de profils avec des adresses différentes tournent en parallèle sur une même machine.
L'authentification se fait par identifiant et mot de passe dans l'URL (cela fonctionne dans Playwright et Puppeteer via les paramètres du contexte, mais pas lors d'un lancement de Chromium avec un simple drapeau) ou par liaison à l'adresse IP blanche du serveur d'automatisation. La seconde méthode est plus fiable pour un runner CI doté d'une adresse sortante fixe : il n'est pas nécessaire de stocker le mot de passe du proxy dans les variables d'environnement.
Pourquoi l'automatisation consomme plus de trafic qu'il n'y paraît
Quand un humain fait défiler une page, il n'en voit que la partie haute de l'écran. Le driver, lui, charge par défaut la page entière : polices (des centaines de kilo-octets par famille), scripts d'analytique et de régies publicitaires, pixels de retargeting, websockets des chats de support. Aucun de ces éléments n'est nécessaire pour vérifier un prix ou un texte, mais tous sont téléchargés avec le contenu visé.
Sur une fiche produit, les données utiles — le HTML avec le prix et les caractéristiques — pèsent quelques dizaines de kilo-octets, tandis que les 2 à 5 Mo restants de la page sont des images, des polices et des scripts tiers dont la tâche n'a que faire. C'est un surcoût pour un trafic qui n'arrivera jamais dans le résultat. Une analyse détaillée de ce qu'il faut désactiver et du calcul des économies étape par étape se trouve dans l'article comment réduire la consommation de Go sur un proxy.
Désactiver les médias : le principal levier d'économie
Le principal levier d'économie consiste à bloquer, au niveau du driver, tout ce qui n'entre pas dans le résultat du parsing, plutôt qu'à choisir un canal moins cher. Avec Playwright et Puppeteer, il s'agit d'intercepter les requêtes et d'annuler les types image, media, font, parfois stylesheet. Avec Selenium et Chrome, le même effet s'obtient par un paramètre de profil désactivant le chargement des images.
Le résultat : un poids de page divisé par 3 à 10 selon le nombre initial d'images et de vidéos. Pour les tâches où seul le texte compte — prix, disponibilité, statut d'une commande —, le blocage des médias n'affecte pas le résultat : les données se trouvent dans le HTML, et non dans les images elles-mêmes. Chercher le canal le moins cher au lieu de désactiver les médias produit souvent l'effet inverse — la différence est expliquée dans l'article proxys bon marché ou proxys chers.
Cohérence de la locale, du fuseau horaire et de la langue de la requête avec la géolocalisation de l'adresse
Changer d'IP ne modifie automatiquement ni la locale du navigateur, ni le fuseau horaire du système, ni l'en-tête Accept-Language. Si l'adresse est présentée comme américaine alors que le contexte indique le fuseau Europe/Moscow et la langue russe, le site reçoit des signaux contradictoires. Certains sites servent le contenu selon la langue de l'en-tête et non selon l'IP : le décalage modifie alors le contenu affiché lui-même, et pas seulement le niveau de suspicion de la session.
Avec Playwright et Puppeteer, locale, timezoneId et en-têtes se définissent dans les options du contexte lors de la création de la page, et doivent être synchronisés avec la géolocalisation de l'adresse à chaque lancement, et non une seule fois pour tous les profils à la fois. La check-list de l'association « profil plus canal », avec vérification de WebRTC et du DNS, figure dans l'article proxy pour navigateur antidetect pas à pas.
Profils parallèles et port dédié par profil
Lorsque l'automatisation lance plusieurs profils simultanément, un seul port pour tous pose deux problèmes. Le premier est d'ordre réseau : les sessions se partagent la bande passante et la limite de threads, d'où des délais d'attente dépassés et des nouvelles tentatives. Le second est comportemental : si le fournisseur change l'IP sortante d'un port lors d'une reconnexion, le site voit l'adresse changer au sein d'une session et peut y voir une anomalie.
La règle est simple : un port dédié et une adresse stable pendant toute la session pour chaque profil parallèle. Cela augmente le nombre de canaux à acheter, mais supprime les deux sources de nouvelles tentatives. La rotation par API permet de piloter par programme le changement d'adresse sur chaque port, sans reconstruire manuellement la configuration avant chaque lancement ; elle est détaillée dans l'article comment configurer la rotation d'IP par API.
Questions fréquentes
Peut-on utiliser un seul proxy pour plusieurs profils headless simultanément ?
Techniquement oui, mais ce n'est pas recommandé : des sessions parallèles via un même port se partagent la bande passante et provoquent des délais d'attente dépassés, et le site peut interpréter l'alternance de requêtes depuis une même adresse comme une activité suspecte. Pour un lancement en parallèle, prenez un port dédié par profil.
Désactiver les images et les polices risque-t-il de casser le parsing des données ?
Non, si les données recherchées se trouvent dans le HTML et ne sont pas rendues sous forme d'image ou d'élément canvas. Avant un lancement massif, il vaut mieux exécuter la tâche avec et sans médias et comparer le résultat — pour les prix, la disponibilité et les champs textuels, il n'y a généralement aucune différence.
Comment vérifier que la locale et le fuseau horaire du navigateur correspondent à la géolocalisation du proxy ?
Avec n'importe quel service de vérification d'empreinte de navigateur : il affiche l'IP, le pays, le fuseau horaire et la langue que voit le site. Mieux vaut intégrer cette vérification au script d'automatisation lui-même, comme première étape avant la tâche principale, plutôt que de la faire à la main de temps en temps.
Un port dédié par profil d'automatisation, l'authentification par IP blanche pour la CI et le choix du canal selon la tâche — adresses résidentielles et mobiles facturées au trafic, ou adresses de datacenter au mois — se trouvent dans la section proxys.