Proxy pour les agents IA : Playwright MCP et browser-use 2026

```html

L'agent IA qui navigue sur les sites par lui-même — Claude avec Playwright MCP, browser-use, Browserbase dans le cloud — se heurte au même mur qu'un parseur classique : une poignée de requêtes depuis une seule adresse, et ensuite, au lieu de la page, un défi Cloudflare apparaît. La différence est que l'agent ne sait pas se fâcher et se bloque simplement, brûlant des jetons dans des tentatives de « cliquer sur un bouton qui n'existe pas ».

La solution est un proxy. Mais connecter un proxy à l'agent s'avère étonnamment peu évident : la moitié des instructions sur Internet proposent une syntaxe que Chromium ignore silencieusement. Ci-dessous se trouvent des configurations fonctionnelles pour les trois piles les plus courantes de 2026 et une analyse des pièges sur lesquels tout le monde trébuche.

À qui cela s'adresse

Guide pour ceux qui ont déjà lancé l'agent et ont rencontré l'un des symptômes :

l'agent exécute 10 à 20 étapes, puis chaque étape suivante renvoie un captcha ou une page « Vérifiez que vous êtes humain » ;
l'agent ne voit pas le même contenu que vous : les prix, les résultats et la disponibilité des produits sont affichés selon votre IP serveur, et non selon le pays souhaité ;
l'agent est lancé dans le cloud (VPS, GitHub Actions, conteneur), et l'adresse du centre de données de l'hébergeur est déjà marquée comme bot ;
vous avez configuré le proxy avec un nom d'utilisateur et un mot de passe, mais le navigateur démarre comme si le proxy n'existait pas du tout.

Si vous êtes encore à l'étape « pourquoi les agents sont-ils bloqués » — lisez d'abord l'analyse sur comment les systèmes anti-bot distinguent un navigateur d'agent d'un humain : là, il est question des signaux de détection, et ici — de la pratique pure de la connexion.

Piège n°1 : Chromium n'accepte pas le nom d'utilisateur et le mot de passe dans la chaîne de proxy

La faute la plus courante, et elle coûte des heures de débogage. La forme classique de la chaîne du fournisseur est user:pass@host:port. Vous l'insérez dans le drapeau de lancement du navigateur :

--proxy-server="http://user:[email protected]:8080"

Et rien ne fonctionne. Chromium ne prend pas en charge la transmission des informations d'identification dans le drapeau --proxy-server : une erreur de proxy non pris en charge apparaît dans la console, et le trafic passe à côté. Si vous retirez les identifiants et laissez seulement host:port, le navigateur en mode normal affichera une fenêtre système demandant le nom d'utilisateur et le mot de passe — et c'est tout, car en mode headless, il n'y a pas de fenêtre et personne pour cliquer dessus.

De cela découlent trois chemins fonctionnels, et il faut choisir consciemment :

Autorisation par IP (whitelist). La solution la plus propre pour les agents. Vous ajoutez l'adresse de la machine où l'agent fonctionne à la liste blanche dans le tableau de bord du fournisseur — et ensuite, vous vous connectez sans nom d'utilisateur ni mot de passe, avec une simple chaîne host:port. Le drapeau --proxy-server commence à fonctionner comme prévu, le mode headless ne demande plus rien. ProxyCove prend en charge les deux méthodes — avec nom d'utilisateur : mot de passe et IP-whitelist, même simultanément, donc pour l'agent, vous pouvez créer une liste blanche, et pour les tâches manuelles, laisser le mot de passe.
Transmettre les identifiants au niveau de l'API, et non du drapeau. Playwright, Puppeteer et browser-use savent accepter username et password comme champs séparés — ce n'est pas le même mécanisme que le drapeau de ligne de commande, et cela fonctionne. Cela convient lorsque vous écrivez vous-même le code de l'agent.
Relais local. Vous configurez un proxy sans mot de passe qui transfère les requêtes vers l'upstream avec un mot de passe, et vous indiquez à l'agent l'adresse locale. C'est une option pour les cas où la liste blanche n'est pas disponible : par exemple, l'IP de la machine change.

Playwright MCP : configuration qui fonctionne vraiment

Playwright MCP de Microsoft — aujourd'hui le standard de facto pour les agents qui ont besoin d'un véritable navigateur. Le proxy est défini par des arguments de serveur directement dans la configuration du client MCP :

{"mcpServers":{"playwright":{"command":"npx","args":["@playwright/mcp@latest","--browser","chromium","--headless","--proxy-server","http://gate.example.com:8080","--proxy-bypass",".local,.internal","--isolated","--viewport-size","1920x1080"]}}}

Ce qui est important ici, point par point :

--proxy-server accepte à la fois les adresses HTTP et SOCKS5 sous la forme socks5://host:port. Sans informations d'identification — voir le piège ci-dessus.
--proxy-bypass — liste de domaines séparés par des virgules qui passent à côté du proxy. Ce n'est pas une option décorative : si l'agent a des services internes ou une API locale, les faire passer par un canal résidentiel représente un trafic supplémentaire au coût par gigaoctet.
--isolated conserve le profil en mémoire et ne l'écrit pas sur le disque. Utile lorsque chaque tâche doit commencer avec une ardoise vierge. L'inconvénient est que les cookies ne survivent pas au redémarrage, et chaque session pour le site apparaît comme un nouvel visiteur.
--user-data-dir — au contraire, un profil permanent. Pour les scénarios avec authentification, utilisez-le plutôt que l'isolation, et assurez-vous de fixer l'IP (voir la section sur le sticky ci-dessous).
--storage-state permet d'injecter des cookies et localStorage sauvegardés dans une session isolée — un compromis entre les deux précédents.
--allowed-origins et --blocked-origins limitent où l'agent peut aller. Une économie sous-estimée : un agent passionné par l'analyse et les domaines publicitaires peut facilement tripler la consommation de trafic.
--device (par exemple, "iPhone 15") et --user-agent modifient le navigateur avec lequel l'agent se présente. Assurez-vous de les définir en accord avec le type de proxy : un User-Agent mobile sur une IP de centre de données — c'est une contradiction que le système anti-bot détecte instantanément.

À part --cdp-endpoint : il connecte MCP à un navigateur déjà lancé. Dans ce cas, le proxy est configuré non pas par les drapeaux MCP, mais lors du démarrage de ce navigateur — une raison typique pour laquelle « le proxy est configuré, mais l'IP reste la même ».

browser-use : proxy via ProxySettings

Si l'agent est construit sur browser-use, la configuration se fait dans un objet de paramètres, et ici, il est possible de transmettre le nom d'utilisateur et le mot de passe — ils passent par l'API, et non par la ligne de commande :

from browser_use import Browser, ProxySettings proxy = ProxySettings(server='http://gate.example.com:8080', username='user', password='pass', bypass='localhost,127.0.0.1') browser = Browser(proxy=proxy)

Le champ server est obligatoire, les autres sont optionnels. Le même principe s'applique dans Playwright pur : le proxy est défini soit globalement lors du lancement du navigateur, soit séparément pour chaque contexte via browser.newContext({ proxy: { server: ... } }). La seconde option est la clé pour les agents parallèles : chaque contexte obtient sa propre adresse de sortie, et dix tâches ne partagent pas une seule IP.

Navigateurs cloud : proxy au niveau de la session

Avec Browserbase et des services similaires, le navigateur vit dans le cloud d'un tiers, donc les drapeaux de lancement ne vous sont pas accessibles — le proxy est configuré dans les paramètres de session, généralement sous la forme http://login:password@gateway:port dans la variable d'environnement du serveur MCP. La limitation de Chromium ici ne pose pas de problème : le fournisseur cloud analyse lui-même la chaîne et configure le navigateur de l'intérieur.

Un détail pratique : les navigateurs cloud ont leur propre pool de proxies, et il est partagé par tous les clients. Si la tâche est sensible à la réputation de l'adresse — connexion à un compte, travail sur une plateforme où vous êtes déjà connu — votre propre canal est plus prévisible que le général.

Rotation ou fixation : choisissez selon le type de tâche

L'erreur des débutants est d'activer la rotation à chaque requête et de s'étonner de voir l'agent se déconnecter. Les scénarios d'agent ont deux modes, et ils ne sont pas interchangeables :

Rotation à chaque requête (chez ProxyCove, c'est le port 824) — pour l'exploration : contourner cent fiches produits, collecter des résultats, vérifier les prix dans différentes régions. Chaque requête part d'une nouvelle adresse, il est difficile de les relier entre elles.
Session fixe (ports 10000+, intervalle de changement de 1 à 120 minutes) — pour tout ce qui consiste en étapes : connexion, panier, formulaire multi-pages, long dialogue avec l'interface. Si l'IP change au milieu de la chaîne, le site demandera au mieux de se reconnecter, au pire marquera la session comme suspecte.

L'agent fonctionne presque toujours en mode fixe : il effectue par définition une séquence d'étapes, et non un seul tir. Les détails sur le choix de l'intervalle et les erreurs typiques sont abordés dans le guide sur quand utiliser des sessions sticky et comment les configurer.

Cinq pièges à éviter

SOCKS5 avec authentification dans Chromium. La syntaxe socks5:// existe dans Playwright, mais la combinaison « SOCKS5 plus nom d'utilisateur et mot de passe » dans les navigateurs basés sur Chromium est historiquement problématique — une demande correspondante est ouverte dans le tracker Playwright depuis novembre 2021. Si vous avez le choix, pour les agents, optez pour un canal HTTP(S), il est plus prévisible.
Fuite DNS et WebRTC. Le trafic passe par le proxy, mais les noms sont résolus directement ou WebRTC renvoie l'adresse réelle — et toute la dissimulation perd son sens. Il faut vérifier cela avant, et non après le lancement de l'agent : comment masquer WebRTC lors de l'utilisation d'un proxy.
Désynchronisation géo et locale. IP en Allemagne, fuseau horaire de la machine à Moscou, langue de l'interface en anglais — un ensemble qui, par lui-même, ressemble à de l'automatisation. Dans Playwright, la locale et le fuseau horaire sont définis par les paramètres de contexte, alignez-les avec le pays du proxy.
Trafic que vous n'avez pas demandé. L'agent ouvre la page dans son intégralité, avec des images, des polices et des scripts publicitaires. Sur un canal résidentiel avec paiement par gigaoctet, cela représente une dépense notable — bloquez les domaines superflus et, si possible, désactivez le chargement des médias.
Le proxy n'est pas configuré là où le navigateur démarre. Lors de l'utilisation de --cdp-endpoint, via un wrapper Docker ou un service cloud, les drapeaux MCP n'affectent pas la connexion réelle. La première chose à faire après la configuration est de faire ouvrir à l'agent n'importe quel service de vérification IP et de s'assurer que l'adresse et le pays sont corrects.

Quel type de proxy choisir pour l'agent

La règle est simple : plus la tâche est proche d'un utilisateur réel, plus l'adresse doit être « humaine ».

Proxies résidentiels — la base pour les agents. Ce sont des adresses de fournisseurs domestiques, et pour le site, l'agent apparaît comme un visiteur ordinaire. Nécessaires partout où il y a Cloudflare, des prix régionaux et toute allusion à un anti-bot.
Proxies mobiles — l'artillerie lourde pour les réseaux sociaux et les plateformes où les comptes sont particulièrement surveillés. Derrière une seule adresse mobile se cachent des milliers de véritables abonnés, donc bannir complètement cette adresse coûte cher à la plateforme.
Proxies de centre de données — pour les API internes, les environnements de test et les sources ouvertes sans protection. Rapides et bon marché, mais sur des sites protégés, l'agent se heurtera presque immédiatement à un défi.

Détail utile pour les scénarios d'agent : le changement de protocole chez ProxyCove se fait en remplaçant le préfixe dans la chaîne de connexion — HTTP, HTTPS et SOCKS5 sont disponibles sur le même proxy, il n'est pas nécessaire de reconfigurer le proxy lui-même. Il y a plus de 195 pays dans le pool, donc « montrer à l'agent les résultats locaux » se résout par le choix du pays lors de l'achat.

Conclusion

Connecter un proxy à un agent IA n'est pas une simple ligne, mais trois solutions consécutives : comment s'authentifier (pour un agent headless, c'est presque toujours une liste blanche d'IP, pas un mot de passe), où définir le proxy (drapeaux MCP, objet de paramètres ou paramètres de session cloud — mais toujours là où le navigateur démarre réellement) et dans quel mode travailler (pour les scénarios à plusieurs étapes — adresse fixe, pas de rotation à chaque requête). Plus une vérification obligatoire des fuites DNS et WebRTC avant le lancement opérationnel.

Faites-le une fois avec soin — et l'agent cessera de gaspiller des jetons à discuter avec des captchas. Les proxies résidentiels ProxyCove se connectent à Playwright MCP et browser-use en quelques minutes, paiement par trafic, la liste blanche IP pour le mode headless est activée dans le tableau de bord.