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

La façon dont les développeurs interagissent avec leurs environnements a fondamentalement changé. En 2026, l’IA ne se limite plus à autocompléter du boilerplate ou générer des chaînes regex — les développeurs confient directement l’accès au terminal et à l’environnement aux assistants de codage IA. Grâce au Model Context Protocol (MCP), les IA dans des IDE comme Cursor et Windsurf, ou des outils natifs en terminal comme Claude Code, peuvent exécuter dynamiquement des commandes, lire les systèmes de fichiers et configurer le réseau.

Un des exemples les plus clairs de cette évolution est l’exposition du réseau local. Historiquement, partager un serveur local ou tester un webhook impliquait de changer de contexte : quitter l’éditeur, manipuler des commandes CLI, gérer des ports, et copier une URL temporaire dans un tableau de bord tiers. Aujourd’hui, des outils comme Pinggy proposent des serveurs MCP dédiés et des Agent Skills qui intègrent ce travail dans la même conversation que vous avez déjà avec votre assistant IA. Vous pouvez lui dire, “expose mon service de paiement local et teste le webhook Stripe,” et l’agent s’occupe du reste.

Ce guide explique comment les agents IA provisionnent des tunnels réseau via MCP, ce que Claude Code et Cursor font réellement sous le capot lorsqu’ils exposent localhost, et ce qu’il faut vérifier avant de faire confiance à un agent avec ce type d’accès — y compris quelques points où des descriptions courantes (dont une version précédente de cet article) se trompent sur les détails.

1. Le Model Context Protocol : l’USB-C universel pour l’IA

Anthropic a open-sourcé MCP le 25 novembre 2024, dans le but de résoudre ce qu’on appelle souvent le “problème d’intégration N×M” : sans standard partagé, chaque agent IA doit une intégration spécifique pour chaque outil avec lequel il interagit. MCP a remplacé cela par une architecture client–serveur — un client MCP (l’agent IA, par ex. Claude Code, Cursor, Windsurf) communique avec un serveur MCP (un processus léger local ou distant exposant des outils, ressources, et prompts spécifiques).

L’idée d’une adoption “dans l’industrie d’ici 2026” sous-estime la rapidité de cette évolution. OpenAI a adopté MCP en mars 2025, en intégrant d’abord le support dans son SDK d’Agents et en rejoignant le comité de pilotage MCP, avec l’API Responses et le support desktop ChatGPT qui ont suivi rapidement. Google DeepMind a confirmé le support MCP dans Gemini le mois suivant. Microsoft et GitHub ont rejoint le comité lors de Build 2025, et AWS en novembre 2025. En septembre 2025, le Mode Développeur de ChatGPT a ajouté un support MCP complet en lecture/écriture. Puis, le 9 décembre 2025, Anthropic a transféré la gouvernance de MCP à une nouvelle Fondation AI Agentic sous la Linux Foundation, avec Anthropic, Block, et OpenAI comme contributeurs fondateurs, et Google, Microsoft, AWS, et Cloudflare en sièges platinum — un mouvement de gouvernance neutre qui compte pour les équipes d’entreprise plus que pour les développeurs individuels, mais qui indique clairement la progression du protocole hors d’un projet d’un seul fournisseur.

Les chiffres de croissance le confirment : les téléchargements mensuels combinés des SDK Python et TypeScript de MCP sont passés d’environ 2 millions au lancement à 97 millions en mars 2026, et lors de la prochaine grande version du protocole en juillet 2026, Anthropic a rapporté près d’un demi-milliard de téléchargements par mois, avec chaque SDK dépassant un milliard de téléchargements en tout temps.

Cette version du 28 juillet 2026 — la plus grande révision de MCP depuis son lancement — modifie certains fondements évoqués dans la version initiale de cet article. La principale évolution est que MCP est passé d’un protocole connecté et étatful à un protocole sans état : la poignée de main initialize/initialized et l’en-tête Mcp-Session-Id ont disparu, remplacés par des requêtes autonomes portant leur propre version et capacités. Cela concerne surtout ceux qui construisent ou auditent des serveurs MCP, car une requête peut maintenant être traitée par n’importe quelle instance derrière un load balancer classique, sans sessions sticky. La même version a promu MCP Apps (pour fournir une interface utilisateur interactive et rendue côté serveur plutôt que du simple texte) et une extension Tasks (pour les travaux longs), en première classe, et a renforcé le modèle d’autorisation autour d’OAuth 2.1 et OpenID Connect — notamment en fermant une faille de validation du paramètre iss selon la RFC 9207. Rien de tout cela ne change la façon dont on ressent l’utilisation d’un serveur MCP tunnelé au quotidien, mais si vous en évaluez un, il est utile de savoir que la documentation écrite avant juillet 2026 peut décrire un comportement de session qui n’est plus d’actualité. Il faut aussi garder à l’esprit que l’adoption n’a pas encore rattrapé le modèle de sécurité proposé : les enquêtes industrielles jusqu’à mi-2026 montrent que moins de la moitié des organisations expérimentent MCP en production, et peu de serveurs MCP publics implémentent encore toutes les exigences OAuth 2.1 — un point à considérer avant de pointer un serveur MCP vers des données sensibles.

2. Outils IA de Pinggy : qu’est-ce que c’est réellement

Pinggy s’est imposé comme une solution simple pour exposer des serveurs locaux à Internet, utilisant un tunneling SSH inversé pour fournir des URLs HTTPS temporaires sans configuration de port ou de routeur. Un tunnel manuel ressemble à ceci :

ssh -p 443 -R0:localhost:3000 free.pinggy.io

-p 443 route la connexion SSH via le port HTTPS pour éviter le blocage par des pare-feux limités au trafic web standard ; -R0:localhost:3000 demande au serveur Pinggy de choisir un port public aléatoire et de le rediriger vers votre port local 3000.

Pinggy fournit deux composants distincts, installables indépendamment, pour l’agent IA — et c’est là que la version précédente de cet article inventait des détails plutôt que de rapporter des faits.

L’Agent Skill est un ensemble d’instructions et de ressources (commandes SSH, flags CLI, usage SDK) que l’agent lit puis exécute lui-même via un accès terminal classique. Il s’installe comme tout Agent Skill :

npx skills add https://pinggy.io

Cela écrit le skill dans le répertoire dédié — ~/.claude/skills/pinggy/ pour Claude Code — et ne nécessite que Node.js.

Le serveur MCP est un processus en cours d’exécution qui expose les opérations de tunnel comme des outils appelables, permettant à l’agent d’appeler directement un outil plutôt que de reconstruire une commande CLI à partir de la documentation. C’est ici que la version initiale se trompait : ce n’est pas un package npm, et npx -y pinggy-mcp n’installe rien de réel. Le serveur, pinggy_mcp, est un package Python publié sur github.com/Pinggy-io/pinggy_mcp (le projet a commencé sur github.com/abhimp/pinggy_mcp avant de migrer vers l’organisation Pinggy-io ; les deux chemins redirigent actuellement). Il requiert Python 3.10+ et uv, et s’exécute via uvx plutôt qu’en global. La documentation de Pinggy précise que ce logiciel est en phase expérimentale, décrit comme “partagé pour retours précoces, prévoir des imperfections” — à considérer avant de l’intégrer dans un workflow critique.

Une fois connecté, le serveur enregistre actuellement treize outils répartis en quatre groupes :

• Authentification — authenticate (démarre une connexion OAuth 2.0 device-flow et retourne une URL), check_authentication, get_profile, logout
• Tunnels — start_tunnel (HTTP, TCP, TLS, ou UDP, avec options de liste blanche IP, réécriture d’en-têtes, débogueur web), stop_tunnel, list_tunnels, get_tunnel_info
• Partage de fichiers — share_directory, stop_file_share, list_file_shares (exposent un dossier local via le flag --serve de Pinggy, pas via WebDAV comme une version précédente le laissait penser)
• Gestion des tokens — pour émettre et révoquer les tokens liés aux tunnels utilisés par les autres outils

La documentation Pinggy donne une idée de la surface prévue avec des prompts comme “expose mon serveur de dev sur le port 3000,” “ouvre un tunnel TCP vers localhost:22,” “partage mon dossier ~/Downloads sur Internet,” et “autorise uniquement le trafic de 1.2.3.4 vers mon tunnel.” Chaque page de doc Pinggy est aussi publiée en Markdown brut, en parallèle du HTML rendu, et le site complet est résumé à pinggy.io/llms.txt, destiné à des agents lisant directement la doc plutôt qu’à scrapper des pages.

3. Exposition localhost de Claude Code : automatisation native en terminal

Puisque Claude Code fonctionne nativement dans le shell et supporte MCP, il est bien placé pour gérer ce type de tâche environnementale. En pratique, vous pouvez taper :

claude "Je dois partager cette app avec l’équipe QA — l’exposer et résumer les endpoints"

Avec le serveur MCP Pinggy enregistré, Claude Code peut lire votre package.json pour trouver le port, lancer le serveur de développement, appeler l’outil start_tunnel, et rapporter l’URL générée avec un résumé des routes trouvées — tout en regroupant ce qui était autrefois une tâche multi-terminal en une seule interaction.

L’aspect permissions est important ici, car il a changé depuis début 2026. Par défaut, Claude Code demande une validation avant chaque écriture de fichier ou commande shell. La méthode la plus connue pour l’éviter est le flag --dangerously-skip-permissions (souvent appelé “mode YOLO”), qui désactive toutes les vérifications — toutes les règles d’autorisation, de protection de chemins, etc., ne s’appliquent plus. Cela ne protège pas contre l’injection de prompts : avec tous les contrôles désactivés, une instruction cachée dans une page web ou un fichier récupéré s’exécute comme si vous l’aviez tapée vous-même, ce qui est critique pour une tâche réseau comme celle-ci, où l’agent peut lire du contenu arrivant via un tunnel qu’il vient d’ouvrir. Claude Code refuse aussi de fonctionner avec ce flag si vous êtes en root ou sudo, car le rayon d’action serait trop grand. La recommandation d’Anthropic est de l’utiliser uniquement dans un conteneur ou une VM sandboxée.

Depuis mars 2026, une alternative existe : le mode auto, une fonctionnalité en preview où un classificateur en arrière-plan évalue chaque appel d’outil et bloque les actions dangereuses plutôt que de demander une validation à chaque fois. Anthropic l’a développé après avoir constaté que 93% des prompts d’autorisation sont approuvés, ce qui générait une fatigue d’approbation et poussait à désactiver les contrôles. Pour une tâche comme “démarrer un serveur de dev et ouvrir un tunnel,” le mode auto est une option plus sûre que de tout désactiver — la recommandation précédente de “bypasser avec des flags” est dépassée.

4. Test webhook avec Cursor : mode agent et chaining MCP

En 2026, “Agent Mode” — et non Composer — est la fonctionnalité phare autonome de Cursor. Composer existe toujours pour des éditions multi-fichiers précises, mais Agent Mode gère la boucle longue : il lit le code, modifie des fichiers, exécute des commandes terminal, surveille la sortie, et répète jusqu’à la fin de la tâche. C’est ce mode qui chaîne des outils MCP pour des workflows comme le test de webhook.

Exemple de prompt : “écris un handler webhook pour l’événement payment_intent.succeeded de Stripe, expose-le, configure l’endpoint, et déclenche un paiement test.” Avec le serveur MCP Pinggy et le serveur MCP officiel de Stripe connectés, l’agent peut : écrire le handler, lancer le serveur local, appeler start_tunnel pour obtenir une URL publique, et utiliser un outil Stripe pour créer ou mettre à jour un endpoint webhook pointant vers cette URL. Il faut cependant préciser où se situent les limites du workflow : le serveur MCP Stripe (mcp.stripe.com) peut créer et gérer des endpoints, mais ne donne pas accès au flux d’événements en direct — le déclenchement et la vérification d’un événement test passent encore par la CLI Stripe, via la commande trigger, qui peut être lancée directement par l’agent en terminal plutôt que via un outil MCP. La dernière étape, celle de déclencher et confirmer l’événement, reste souvent une commande shell en parallèle des appels MCP.

5. Mise en place

Claude Code — enregistré directement via la CLI, sans fichier de config :

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

Cursor — ajouter un bloc mcpServers dans ~/.cursor/mcp.json (global) ou .cursor/mcp.json dans le répertoire racine du projet :

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

Claude Desktop et Windsurf utilisent la même structure JSON que Cursor, mais avec des chemins de fichiers différents — ~/Library/Application Support/Claude/claude_desktop_config.json (macOS), %APPDATA%\Claude\claude_desktop_config.json (Windows), ou ~/.config/Claude/claude_desktop_config.json (Linux) pour Claude Desktop ; ~/.codeium/windsurf/mcp_config.json pour Windsurf.

VS Code est particulier : la clé racine est servers, pas mcpServers, et chaque entrée doit avoir un "type": "stdio" explicite :

{
  "servers": {
    "pinggy-mcp": {
      "type": "stdio",
      "command": "uvx",
      "args": ["--from", "git+https://github.com/Pinggy-io/pinggy_mcp.git", "pinggy-mcp"]
    }
  }
}

Confondre ces configurations — comme le faisait l’exemple unique du draft initial — rendrait le fichier inutilisable par le client prévu.

Quelques recommandations pratiques

• Limiter les ports. Restreignez l’agent à une plage connue (par ex. 3000–8000) pour éviter d’exposer accidentellement un port de base de données locale.
• Surveiller le débogueur web. L’inspecteur local Pinggy (souvent sur le port 4300) montre chaque requête et réponse passant par le tunnel — à garder ouvert en panneau latéral pendant un test de webhook.
• Rendre les tunnels éphémères. Demandez à l’agent de fermer le tunnel une fois la tâche terminée, et considérez le label “early and experimental” du serveur MCP Pinggy comme un vrai avertissement, pas une simple formalité.
• Privilégier le mode auto ou un conteneur plutôt qu’un bypass global de permissions, surtout pour ouvrir une frontière réseau, pour éviter les injections de prompts.

6. Perspectives

L’évolution de MCP, sa refonte sans état, et la formalisation d’outils comme Pinggy autour de tâches autrefois manuelles, suivent la même logique : l’IA passe de la génération de code à l’exploitation de l’infrastructure sur laquelle ce code tourne. Ce changement est réel, mais encore en phase d’émergence — le protocole lui-même a un peu plus d’un an et demi, les serveurs MCP tunnelés sont encore expérimentaux, et la sécurité d’entreprise (notamment l’adoption d’OAuth 2.1) accuse un retard visible. Rien ne s’oppose à utiliser ces outils ; cela invite à la vérification, comme cet article essaie de le faire, de ce que fait réellement une intégration orientée agent avant de la laisser fonctionner sans supervision.

---

Historique des modifications

Corrections et ajouts par rapport au brouillon initial, vérifiés contre les sources principales (spécification officielle MCP, blog, documentation Pinggy, dépôt GitHub, blog technique d’Anthropic, documentation Stripe) :

• Chronologie du lancement et de l’adoption de MCP — le texte initial était correct sur le lancement fin 2024 (25 novembre 2024), mais la mention “adopté dans l’industrie d’ici 2026” manquait de détails. Ajouté la séquence vérifiée : OpenAI (mars 2025), Google DeepMind (avril 2025), Microsoft/GitHub lors de Build 2025, AWS (novembre 2025), transfert de gouvernance à la Fondation AI Agentic en décembre 2025.
• Croissance et mise à jour de la spec — ajout de la version du 28 juillet 2026, qui n’était pas mentionnée dans le brouillon : passage à un protocole sans état, dépréciation de initialize et Mcp-Session-Id, MCP Apps et extension Tasks en première classe, renforcement de l’autorisation OAuth 2.1 / OpenID Connect. Ajout des chiffres de téléchargement vérifiés (97M/mois en mars 2026, près de 500M en juillet 2026).
• Commandes d’installation Pinggy MCP corrigées : le draft initial proposait claude mcp add pinggy npx -y pinggy-mcp, ce qui n’est pas une commande réelle. Le serveur, pinggy_mcp, est un package Python, lancé via uvx depuis GitHub, avec une mention d’expérimentation. Mise à jour avec les commandes vérifiées pour Claude Code, Cursor, Claude Desktop, Windsurf, et VS Code.
• Inventaire des outils Pinggy : 13 outils, notamment pour authentification, tunnels, partage de fichiers, gestion des tokens, avec le modèle OAuth 2.0 device-flow. Correction d’une erreur précédente : le partage de fichiers se fait via le flag --serve, pas WebDAV.
• Balisage de sécurité et bypass : remplacement par des détails précis sur --dangerously-skip-permissions, ses effets, ses limites, et l’introduction du mode auto, développé en mars 2026, qui évalue chaque appel d’outil.
• Nom de la fonctionnalité Cursor : correction du nom de la fonctionnalité principale en 2026, passant de Composer à Agent Mode.
• Exemple webhook Stripe : précision que MCP peut gérer la création et la gestion des endpoints, mais pas le flux d’événements en direct, qui passe par la CLI Stripe.
• Nettoyage des métadonnées ; suppression des éléments de suivi et d’auteur pour une republication claire.