Les agents IA prennent le contrôle : serveurs MCP et automatisation des tunnels en 2026

Les développeurs n’utilisent plus simplement l’IA pour autocompléter du boilerplate ou générer des regex. En 2026, de nombreux assistants de codage IA ont un accès complet au terminal et à l’environnement, et peuvent exécuter des commandes, lire le système de fichiers et configurer le réseau de manière autonome. Un exemple clair est l’exposition du réseau local : partager un serveur de développement ou configurer un webhook signifiait autrefois quitter l’éditeur, lancer une commande CLI manuellement, puis coller une URL temporaire dans un tableau de bord tiers. Aujourd’hui, certains fournisseurs de tunneling proposent un serveur Model Context Protocol (MCP) dédié et une « compétence d’agent » permettant à un assistant IA de faire ce travail lui-même, à partir d’une invite en langage naturel.

Ce document explique comment fonctionne réellement le tunneling MCP aujourd’hui, ce que Claude Code et Cursor peuvent faire ou non avec, et — puisque le protocole sous-jacent a connu sa plus grande révision à ce jour — ce qui a changé dans la façon dont les agents peuvent toucher votre réseau.

1. Le Model Context Protocol : un connecteur partagé pour les outils IA

Pour comprendre le tunneling piloté par agent, il faut commencer par le protocole qui le rend possible.

Anthropic a open-sourcé le Model Context Protocol le 25 novembre 2024, en tant que norme pour connecter les assistants IA à des outils et sources de données externes. Le problème visé est parfois appelé le « problème M×N » : sans protocole partagé, connecter M applications IA différentes à N outils nécessite environ M×N intégrations personnalisées. MCP simplifie cela à M+N — chaque côté implémente le protocole une seule fois.

L’architecture comporte trois parties :

• Hôte — l’application IA elle-même (Claude Code, Cursor, Claude Desktop, Windsurf, et maintenant ChatGPT et Copilot le supportent aussi).
• Client — la connexion protocolée que l’hôte maintient avec un serveur donné.
• Serveur — un processus local ou distant exposant un ensemble d’outils, ressources ou prompts via cette connexion.

L’adoption a été plus rapide que la plupart des standards ouverts. Microsoft et GitHub ont rejoint le comité de pilotage de MCP lors de Build 2025, et OpenAI a intégré le support MCP dans son SDK Agents et Response API la même année. En décembre 2025, Anthropic a donné MCP à la nouvelle Fondation Agentic AI, un fonds dirigé sous la Linux Foundation cofondé avec OpenAI et Block, avec Google, Microsoft, AWS, Cloudflare et Bloomberg comme membres platine. Au moment du don, Anthropic citait plus de 10 000 serveurs MCP publics actifs et une adoption dans ChatGPT, Cursor, Gemini, Copilot et VS Code.

Le protocole lui-même a continué d’évoluer. La dernière révision, 2026-07-28, a été livrée dans les délais et constitue le plus grand changement depuis le lancement : elle supprime l’ancien modèle de poignée de main de session au profit d’un noyau sans état, plus facile à faire fonctionner derrière un load balancer, favorise les MCP Apps (UI rendue côté serveur) et une extension Tasks en tant que fonctionnalités de première classe, et renforce l’autorisation autour des flux OAuth 2.1. Avec les SDK Python et TypeScript combinés, MCP atteint environ 500 millions de téléchargements par mois. Rien de tout cela ne modifie la façon dont un serveur MCP de tunneling se sent à l’usage, mais il est important de savoir que le terrain a changé si vous en construisez ou en auditez un — les hypothèses basées sur une session de 2025 peuvent ne plus être valides.

2. La compétence d’agent de Pinggy et le serveur MCP

Pinggy — le service de tunneling basé sur SSH — est l’un des outils qui ont adopté cette approche. Il fournit deux composants distincts, installables indépendamment.

La compétence d’agent est un ensemble d’instructions packagées (flags SSH, usage CLI, exemples SDK) que l’agent lit puis exécute lui-même avec un accès terminal ordinaire. Elle s’installe avec npx skills add https://pinggy.io et écrit dans le répertoire skills du client — ~/.claude/skills/pinggy/ pour Claude Code, par exemple.

Le serveur MCP va plus loin : au lieu que l’agent reconstruise une commande SSH à partir de la documentation, il appelle directement un outil et obtient un tunnel actif. C’est ce qui correspond réellement à « exposer mon serveur de développement sur le port 3000 » en une URL publique sans commande manuelle.

Voici quelques points importants souvent négligés :

• Le serveur MCP, pinggy_mcp, est un package Python, pas un package npm. Il nécessite Python 3.10+ et uv.
• Il est explicitement marqué expérimental dans son README — « partagé pour retours précoces, prévoir des imperfections » — ce qui est important si vous décidez de l’intégrer dans un système critique.
• Vous ne l’installez pas à l’avance comme un logiciel classique. Votre client MCP exécute uvx, qui récupère et lance pinggy-mcp à la demande.

La configuration pour Claude Code est :

claude mcp add pinggy-mcp -- uvx --from git+https://github.com/abhimp/pinggy_mcp.git pinggy-mcp
claude mcp list   # vérifier l’enregistrement

Pour Cursor, Windsurf ou Claude Desktop, l’équivalent est un bloc JSON dans le fichier de configuration MCP du client (~/.cursor/mcp.json pour Cursor, ~/.codeium/windsurf/mcp_config.json pour Windsurf) :

{
  "mcpServers": {
    "pinggy-mcp": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/abhimp/pinggy_mcp.git", "pinggy-mcp"]
    }
  }
}

Une fois enregistré, le serveur expose treize outils répartis en quatre groupes : authentification (authenticate, check_authentication, get_profile, logout — via OAuth 2.0 device-flow, pas de copie de token), tunnels (start_tunnel, stop_tunnel, list_tunnels, get_tunnel_info, supportant HTTP/TCP/TLS/UDP avec liste blanche IP optionnelle et débogueur web), partage de fichiers (share_directory expose un dossier local via WebDAV avec une URL Pinggy — « partager mon dossier ~/Downloads » étant un exemple), et gestion des tokens pour les tokens par application. En général, vous ne les appelez pas par leur nom ; l’agent choisit en fonction de votre demande en langage naturel.

Un détail pratique : les tunnels vivent dans le processus du serveur MCP, donc si votre IA redémarre, le serveur redémarre aussi, et les tunnels en cours meurent avec lui. Si un tunnel doit survivre à un redémarrage de Claude Code, il faut le relancer manuellement, ce que l’agent ne fait pas automatiquement aujourd’hui.

3. Claude Code et exposition localhost

Claude Code — l’agent de codage natif d’Anthropic — fonctionne directement dans le shell, ce qui en fait un candidat naturel pour ce type d’automatisation. Indiquez-lui un dépôt et demandez-lui d’exposer un port, il peut lire votre package.json ou .env, lancer le serveur de développement, appeler l’outil MCP de tunneling, et vous fournir à la fois l’URL et un résumé de ce qu’il a trouvé — tout cela sans quitter le terminal.

Les permissions ont changé de sens depuis l’apparition de ce workflow. Claude Code supporte plusieurs modes de permission ; celui qui compte ici est le mode complet sans restriction, invoqué avec --dangerously-skip-permissions ou l’équivalent --permission-mode bypassPermissions. Il évite l’approbation interactive pour les modifications de fichiers, commandes bash, et appels aux outils MCP pour la session — la documentation d’Anthropic le décrit comme destiné uniquement à des environnements isolés (conteneurs, VMs, sandbox sans accès internet) où une action compromise ne peut pas atteindre des éléments critiques, et une alerte s’affiche une seule fois avant exécution. Depuis 14 août 2026, Anthropic a mis en place un mode « auto » par défaut pour Pro, Max et Team, plutôt que l’approbation manuelle — leur propre test montre qu’un classificateur repère la majorité des commandes dangereuses implantées, ce qui explique ce changement.

Le point pratique pour exposer localhost : la portée MCP — le fait qu’un serveur n’expose que les outils qu’il a été conçu pour — limite ce que l’agent peut appeler, mais ne constitue pas une barrière de sécurité contre une session compromise ou une invite malveillante atteignant l’agent via une page web ou autre. La sandboxing et l’isolation réseau sont ce qui limite réellement ce risque, pas la liste d’outils.

4. Cursor et test de webhook

L’interface autonome de Cursor pour le codage s’appelle désormais Agent Mode plutôt que Composer — Composer existe toujours comme interface d’édition multi-fichiers, mais la boucle longue, autonome, et auto-corrigée est maintenant en Agent Mode, qui enchaîne réellement les appels aux outils MCP. (Cursor limite aussi le nombre d’outils MCP actifs dans une seule session — actuellement environ 40 — ce qui est une contrainte réelle si vous faites tourner plusieurs serveurs MCP en parallèle.)

Une version réaliste du workflow webhook : vous demandez à Cursor d’écrire un gestionnaire webhook Stripe, de l’exposer, et de le tester. L’agent peut écrire la route, lancer le serveur de développement, et appeler un outil MCP de tunneling pour obtenir une URL publique — cette étape fonctionne parfaitement aujourd’hui. La nuance réside dans la étape « configurer Stripe automatiquement » : Stripe publie un serveur MCP officiel à mcp.stripe.com avec des outils pour lire les données du compte, rechercher dans la documentation, et une fonction stripe_api_write/execute qui peut créer un webhook — mais les outils dédiés à l’enregistrement d’un endpoint webhook ne font pas partie de l’ensemble principal, contrairement aux opérations client, paiement ou remboursement. En pratique, un agent peut généralement y parvenir via l’outil API générique, mais c’est plus proche de « l’agent écrit et exécute l’appel API équivalent » que de « un outil dédié en un mot ». La commande stripe listen --forward-to du CLI Stripe reste la méthode la plus fiable pour tester localement un webhook sans dépendre d’un appel API générique.

5. Mise en place

Claude Code :

claude mcp add pinggy-mcp -- uvx --from git+https://github.com/abhimp/pinggy_mcp.git pinggy-mcp
claude mcp list

Cursor — modifiez ~/.cursor/mcp.json (global) ou .cursor/mcp.json dans la racine du projet :

{
  "mcpServers": {
    "pinggy-mcp": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/abhimp/pinggy_mcp.git", "pinggy-mcp"]
    }
  }
}

Redémarrez le client après avoir sauvegardé la configuration. Ensuite, une simple demande comme “expose le port 3000 et donne-moi l’URL” suffit à déclencher l’appel à l’outil — pas besoin d’une autre fenêtre terminal ou de copier-coller.

6. Ce qui garantit réellement la sécurité

Confier à un agent la capacité d’ouvrir un tunnel public est une véritable autorisation, et la recherche en sécurité de 2026 sur MCP est plus prudente qu’il y a un an. Voici quelques points essentiels à intégrer dans toute configuration, pas seulement celle de Pinggy :

• L’injection de prompt est la menace réelle, pas une hypothèse. OWASP la classe comme la vulnérabilité numéro un des LLM, et MCP multiplie les risques : une instruction malveillante dissimulée dans une page web, un ticket ou un fichier lu par l’agent peut déclencher des appels d’outils, y compris ceux impliquant votre tunnel. Considérez tout ce que l’agent a récupéré via un tunnel public comme non fiable.
• Limitez délibérément les ports et services exposés. Ne laissez pas un agent exposer un port de base de données ou tout autre avec des identifiants de production, même si c’est techniquement possible ; limitez le tunneling aux ports de développement spécifiques et jetables.
• Rendez les tunnels éphémères. Comme le serveur MCP gère le tunnel en processus enfant, vous pouvez explicitement demander à l’agent de le détruire une fois le test réussi, et il est conseillé d’intégrer cette étape dans vos prompts plutôt que de compter sur la fermeture automatique lors du redémarrage.
• N’installez que des serveurs MCP dont vous avez vérifié la provenance. En particulier ceux encore marqués comme expérimentaux — le package du registre ne correspond pas toujours à la source GitHub, et une provenance non vérifiée a été à l’origine d’incidents dans la chaîne d’approvisionnement en 2026.
• Privilégiez les modes bypass-permission uniquement dans des sandbox. La recommandation d’Anthropic pour --dangerously-skip-permissions / bypassPermissions concerne des conteneurs ou VMs sans accès en production — pas un laptop de développeur avec clés SSH et identifiants cloud à proximité.

7. Perspectives

Les chiffres de l’écosystème MCP illustrent la tendance : depuis un lancement en novembre 2024 jusqu’à plus de 10 000 serveurs publics actifs et environ 500 millions de téléchargements SDK par mois à la mi-2026, avec une gouvernance neutre sous la Linux Foundation. Le tunneling représente une petite part mais concrète : c’est la partie du développement local qui doit forcément traverser la frontière entre votre machine et Internet, ce qui en fait un premier test pour « laisser l’agent gérer » versus « autoriser l’agent à faire cela sans supervision ». La réalité actuelle est : oui, un agent peut ouvrir un tunnel et vous donner une URL en une phrase — et cette commodité justifie que le modèle d’autorisation autour soit davantage surveillé.

---

Historique des modifications

Corrections apportées à la version initiale :

1. Date de lancement MCP — la date initiale était correcte (25 novembre 2024), mais la mention « adopté par l’industrie en 2026 » manquait de précisions ; ajout du détail Build 2025 et support SDK/Response d’OpenAI.
2. Commandes d’installation Pinggy MCP — corrigées pour refléter la réalité : le serveur MCP (pinggy_mcp) est un package Python nécessitant Python 3.10+ et uv, lancé via uvx en pointant vers le dépôt GitHub, et marqué comme expérimental. Remplacé par les commandes vérifiées du README.
3. Comptage et description des outils Pinggy — remplacés par la liste réelle (13 outils) et le modèle d’authentification OAuth2 device-flow, issus du README, pour plus de précision.
4. Section « sécurité et permissions » — actualisée avec les flags précis (--dangerously-skip-permissions, --permission-mode bypassPermissions), la recommandation d’usage dans des environnements isolés, et la modification du comportement par défaut depuis le 14 août 2026.
5. Suppression de la déclaration erronée sur la sécurité MCP — corrigée pour refléter la réalité : MCP limite ce que l’agent peut appeler, mais n’est pas une barrière de sécurité contre l’injection ou la compromission.
6. Clarification sur Cursor — distinction entre Composer et Agent Mode, limite de ~40 outils MCP actifs, correction terminologique.
7. Précision sur la configuration automatique de Stripe webhook — explication que Stripe propose un serveur MCP officiel avec outils pour données, mais pas pour la création de webhook, qui passe par une API générique.