Serveur MCP et proxy API : changement automatique d'IP pour l'agent IA.

Un parseur classique obtient une liste de proxies, les parcourt de manière répétitive et échoue dès que le système anti-bot détecte un motif. L'agent IA fonctionne différemment : il détecte le blocage, prend lui-même la décision de changer d'IP, modifie les en-têtes, ralentit les requêtes — et tout cela sans votre intervention. Nous allons voir comment lier l'agent, le serveur MCP et l'API proxy dans une configuration fonctionnelle qui maintient les sessions actives même sur des sites protégés.

Qu'est-ce que le serveur MCP et pourquoi est-il nécessaire pour le parseur

MCP (Model Context Protocol) — un protocole ouvert qui permet à l'agent IA (par exemple, basé sur Claude ou tout LLM prenant en charge l'appel d'outils) d'accéder à des outils externes via une interface unique. Auparavant, pour donner à un modèle accès à une API externe, il fallait écrire un wrapper personnalisé pour chaque tâche. Le serveur MCP résout cela différemment : il décrit un ensemble d'« outils » — des fonctions que l'agent peut appeler lui-même lorsqu'il comprend qu'elles sont nécessaires.

Dans le contexte du scraping, cela se présente ainsi : l'agent reçoit la tâche « collecte des prix de 500 produits sur le marketplace ». Il commence à faire des requêtes via l'outil fetch_page, voit une réponse 403 ou un captcha, appelle lui-même l'outil rotate_proxy, obtient une nouvelle IP et répète la requête — sans intervention de l'opérateur. Le serveur MCP joue ici le rôle de « pont » entre la logique de l'agent et l'infrastructure réelle des proxies.

La principale différence par rapport à un script ordinaire avec rotation par minute : l'agent prend la décision de changer d'IP en fonction du contexte — code de réponse, contenu de la page, vitesse de blocage d'un domaine spécifique. Il peut maintenir une IP pour une session d'autorisation et changer d'IP uniquement pour les requêtes « froides » de collecte de données, combinant des stratégies à la volée.

Pourquoi l'agent IA a besoin d'un changement d'IP et non simplement d'une liste de proxies

Si vous donnez simplement à l'agent une liste statique de 50 proxies et lui demandez de les parcourir, vous obtiendrez exactement la même chose qu'avec un script ordinaire : le motif des requêtes est rapidement calculé par le système anti-bot en fonction des intervalles, des en-têtes et de la séquence des IP. Wildberries, Ozon, Avito et d'autres grandes plateformes utilisent l'analyse comportementale — elles ne se contentent pas de regarder l'IP, mais aussi comment changent le User-Agent, les cookies, le fingerprint TLS et la vitesse des requêtes en lien avec une adresse spécifique.

L'agent IA résout cette tâche de manière fondamentalement différente. Il peut :

Déterminer par le code de réponse (403, 429, redirection vers un captcha) que l'IP actuelle est « brûlée » et demander une nouvelle IP spécifiquement pour ce domaine ;
Maintenir une session « collante » (sticky session) sur une seule IP pour des scénarios multi-étapes — par exemple, autorisation + scraping du tableau de bord ;
Adapter la fréquence des requêtes en fonction de la réaction du site, plutôt que de fonctionner sur un minuteur rigide ;
Combiner le changement d'IP avec le changement d'en-têtes et l'émulation de navigateur via des outils anti-détection comme Dolphin Anty ou AdsPower, si le scraping se fait via un navigateur sans interface graphique.

C'est pourquoi la combinaison « agent + serveur MCP + API proxy » réduit considérablement le pourcentage de bans par rapport à une rotation statique : la décision de changer d'IP est prise en cas de blocage, et non selon un calendrier.

Architecture de la configuration : agent → MCP → API proxy → parseur

Le schéma de fonctionnement se compose de quatre couches, et il est important de comprendre la zone de responsabilité de chacune :

Agent IA (LLM avec appel d'outils) — prend des décisions : quelle page parser ensuite, faut-il changer d'IP, vaut-il mieux ralentir ;
Serveur MCP — fournit à l'agent un ensemble d'outils : get_page, rotate_ip, check_proxy_status ;
API du fournisseur de proxy — fournit une nouvelle IP sur demande, montre la géolocalisation, le type de connexion (résidentiel, mobile, centre de données) ;
Parseur/client HTTP — exécute la requête réelle vers le site cible avec les paramètres de proxy obtenus.

Un point important : le serveur MCP ne parse pas le site lui-même — il fournit seulement des possibilités à l'agent. La logique « que faire en cas de 403 » reste dans le modèle, et le serveur MCP exécute simplement les commandes et renvoie le résultat. Cette séparation permet de changer de fournisseur de proxy ou de parseur sans réécrire la logique de l'agent — il suffit de mettre à jour l'implémentation de l'outil sur le serveur MCP.

Conseil pratique

Ne donnez pas à l'agent un accès direct à l'API « brute » du fournisseur de proxy — encapsulez-le dans un outil MCP distinct avec un ensemble limité de paramètres (pays, type d'IP, session_id). Cela réduit le risque que le modèle génère accidentellement une requête incorrecte et « brûle » le quota.

Quel type de proxy choisir pour le parsing par agent

Le type de proxy influence directement la fréquence à laquelle l'agent devra appeler rotate_ip et combien de requêtes passent sans blocage. Ci-dessous — une comparaison des tâches pertinentes pour le parsing par agent.

Type de proxy	Quand l'utiliser pour l'agent	Avantages	Inconvénients
Proxies résidentiels	Scraping de marketplaces, sites avec protection anti-bot (Wildberries, Ozon)	IP réelles des utilisateurs, faible pourcentage de blocages	Plus cher que les proxies de centre de données, la vitesse dépend du nœud
Proxies mobiles	Travail avec les réseaux sociaux et les tableaux de bord publicitaires dans le flux de l'agent	Confiance maximale des sites, IP comme celle de l'opérateur de télécommunications	Coût plus élevé, vitesse de rotation limitée
Proxies de centre de données	Collecte massive de données sur des sites sans protection anti-bot stricte	Haute vitesse, faible coût par IP	Facilement détectables, nécessitent souvent une rotation via l'agent

En pratique, l'agent peut combiner les types : commencer une session via des proxies résidentiels pour « chauffer », puis pour contourner techniquement le rate-limit, passer à des proxies de centre de données — si l'outil MCP permet de spécifier le type d'IP comme paramètre de requête.

Configuration étape par étape du serveur MCP avec rotation de proxy

Examinons une configuration minimale fonctionnelle en Python. Le serveur MCP décrit deux outils : obtenir une page et changer d'IP via l'API du fournisseur de proxy.

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("proxy-parser-agent")

# Stockage de la session proxy actuelle
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """Demande une nouvelle IP au fournisseur de proxy via son API"""
    response = httpx.get(
        "https://api.proxycove.com/v1/get-endpoint",
        params={"country": country, "type": "residential"},
        headers={"Authorization": "Bearer YOUR_API_KEY"},
    )
    data = response.json()
    return f"http://{data['username']}:{data['password']}@{data['host']}:{data['port']}"

@mcp.tool()
def rotate_ip(country: str = "ru") -> str:
    """Outil pour l'agent : changement d'adresse IP vers une nouvelle de ce pays"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP mise à jour, région : {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """Outil pour l'agent : obtenir une page via le proxy actuel"""
    if not current_session["proxy_url"]:
        current_session["proxy_url"] = get_new_proxy(current_session["country"])

    proxies = {"http://": current_session["proxy_url"], "https://": current_session["proxy_url"]}
    try:
        r = httpx.get(url, proxies=proxies, timeout=15)
        return {"status_code": r.status_code, "content": r.text[:3000]}
    except httpx.RequestError as e:
        return {"status_code": 0, "error": str(e)}

if __name__ == "__main__":
    mcp.run()

La logique est simple : l'agent appelle fetch_page, voit dans la réponse status_code: 403 et décide alors d'appeler rotate_ip. Pas de règles codées en dur « changer d'IP après 10 requêtes » — le modèle s'oriente sur la réponse réelle du serveur.

Pour la production, il convient d'ajouter à ce code : la journalisation de chaque rotation avec un timestamp, une limitation du nombre de rotations par minute (pour éviter que le modèle ne « boucle » sur le changement d'IP au lieu de résoudre un problème réel) et des timeouts au niveau de la session, afin que l'IP « collante » ne reste pas plus longtemps que nécessaire.

Intégration avec Claude, LangChain et AutoGPT

Le MCP est initialement promu comme un protocole pour Claude Desktop et Claude API, mais grâce à sa spécification ouverte, il est également pris en charge par des frameworks tiers. Si vous construisez un agent sur LangChain, le serveur MCP se connecte via l'adaptateur langchain-mcp-adapters, qui transforme les outils MCP en outils LangChain ordinaires — l'agent les voit comme n'importe quelle autre fonction.

Pour les agents similaires à AutoGPT, où il n'y a pas de support natif pour MCP, il est possible de mettre en place un pont HTTP local : le serveur MCP fonctionne comme un service REST ordinaire, et l'agent appelle les points de terminaison via son mécanisme standard d'appel de fonction. C'est un peu moins élégant, mais c'est une option fonctionnelle pour les équipes déjà liées à une pile spécifique.

Il convient également de mentionner la combinaison avec des navigateurs anti-détection. Si le scraping ne se fait pas via des requêtes HTTP directes, mais via Chrome/Playwright sans interface graphique (nécessaire pour les sites avec une protection JS lourde), le serveur MCP peut gérer non seulement les proxies, mais aussi le profil du navigateur — en transmettant à l'agent un outil pour lancer un profil dans Dolphin Anty ou Octo Browser avec un point de terminaison proxy déjà lié. Dans ce cas, l'agent indique simplement quel profil et quel pays utiliser, tandis que toute la partie technique est cachée derrière l'outil MCP.

Cas pratiques : Wildberries, Ozon, analyse SMM

Surveillance des prix sur Wildberries. L'agent obtient une liste de 2000 SKU, parcourt les fiches produits, et en cas de captcha ou de réponse vide, change lui-même d'IP via des proxies résidentiels et répète la requête avec un délai. Contrairement à un script statique avec une rotation fixe, cette combinaison maintient une vitesse de collecte stable même en cas de renforcement de la protection du côté de la plateforme — l'agent réagit simplement « plus lentement » aux motifs de blocage, réduisant la fréquence des requêtes au lieu de simplement parcourir les IP jusqu'à ce que toutes soient bannies.

Collecte de données via l'API Ozon Seller et l'interface web. Ici, l'agent combine deux modes : les requêtes autorisées vers le tableau de bord se font via une IP « collante » pour toute la journée de travail (afin de ne pas déclencher une nouvelle authentification à deux facteurs), tandis que le scraping public des fiches produits se fait avec rotation à chaque requête.

Analyse SMM des concurrents sur Instagram et TikTok. L'agent collecte des statistiques publiques (likes, commentaires, portée) sur une liste de comptes concurrents, répartissant les requêtes via des proxies mobiles pour imiter le trafic normal des utilisateurs de l'application, et non un bot avec une IP de centre de données.

Dans les trois cas, l'économie de temps pour l'équipe ne réside pas dans le scraping lui-même (qui pouvait être automatisé auparavant), mais dans l'absence de nécessité d'écrire et de maintenir une logique manuelle complexe de retries, de backoffs et de règles de rotation. L'agent s'adapte aux changements de protection du site par lui-même, sans réécriture de code.

Erreurs fréquentes lors de la liaison de l'agent IA et des proxies

Rotation trop fréquente. Si vous permettez à l'agent de changer d'IP à chaque petite action, le site peut commencer à bannir toute la plage de sous-réseaux en raison d'une vitesse anormale de changement d'adresses avec un seul User-Agent.
Absence de liaison des cookies à l'IP. Si l'agent change d'IP mais continue d'utiliser les anciens cookies de session, le système anti-bot détecte immédiatement l'incohérence entre la géolocalisation et la session.
Pas de limite sur le nombre de rotations. Sans limitation, le modèle en boucle d'erreurs peut « brûler » tout le quota de trafic sur des tentatives inutiles en cas de problème systémique (par exemple, le site est complètement hors ligne, et non pas en train de bannir une IP spécifique).
Ignorer le fingerprint TLS. Changer d'IP sans changer de client HTTP ne sert à rien si le site détecte les bots par la signature du handshake TLS — il faut ici une combinaison avec un navigateur sans interface graphique, et non simplement des requêtes httpx.
Accès direct de l'agent aux « crédits » bruts du proxy. En donnant au modèle un accès direct au login/mot de passe de l'API proxy dans le prompt, vous risquez une fuite lors de la journalisation des dialogues — utilisez l'outil MCP comme intermédiaire.

Conclusion

La combinaison de l'agent IA avec le serveur MCP et l'API proxy change la logique même du scraping : au lieu de règles rigides de rotation basées sur un minuteur, l'agent prend la décision de changer d'IP en cas de blocage, combine des sessions « collantes » et ponctuelles, et s'adapte à un site spécifique sans réécriture de code. Cela est particulièrement visible sur les plateformes avec une protection anti-bot active — marketplaces, réseaux sociaux, plateformes publicitaires.

Pour le scraping de marketplaces et de sites avec une protection sérieuse, il est préférable d'intégrer dès le départ des proxies résidentiels dans l'architecture — ils offrent à l'agent plus d'« espace » de manœuvre sans épuisement rapide des IP. Si la tâche concerne les réseaux sociaux et les applications mobiles, portez votre attention sur les proxies mobiles — ils suscitent moins de soupçons auprès des systèmes anti-bot. Et pour la collecte massive de données techniques à partir de sources moins protégées, des proxies de centre de données rapides et accessibles conviennent, que l'agent peut utiliser en combinaison avec des IP résidentielles pour optimiser le budget.