Laissez les agents IA gérer vos tunnels locaux

Pendant des années, la friction d’exposer un serveur de développement local à Internet était hors de portée des assistants de codage IA. Vous pouviez demander à un agent d’écrire un gestionnaire de webhook, mais dès que vous aviez besoin d’une URL publique — pour Stripe, un client mobile, une démo client — vous quittiez la conversation, ouvriez un second terminal, lanciez une commande de tunneling, copiez une URL, et la colliez ailleurs. Le code a été automatisé il y a des années. Le lien réseau, lui, ne l’était pas, jusqu’à ce que le Model Context Protocol donne aux agents un appel de fonction qui contacte directement le tunnel.

Ce n’est pas une révolution achevée — la plupart des développeurs utilisent encore manuellement cloudflared ou ssh -p 443 -R0:localhost:3000 a.pinggy.io, et les serveurs MCP qui automatisent cela, selon leurs propres mainteneurs, sont encore à leurs débuts. Mais les éléments sont là, ils sont documentés, et il vaut la peine de les comprendre avant de les intégrer dans un agent avec accès terminal.

Le goulot d’étranglement remplacé

Tester une intégration webhook n’a jamais été une question de code. Stripe, Shopify, ou une app GitHub ont besoin d’une URL publique pour envoyer des événements, et votre serveur local n’écoute que sur localhost. La boucle traditionnelle :

1. Démarrer le serveur local.
2. Ouvrir un second terminal.
3. Lancer une commande de tunneling et attendre la connexion.
4. Copier l’URL générée.
5. La coller dans un tableau de bord tiers.
6. Envoyer un événement de test.
7. Répéter les étapes 3–6 à chaque redémarrage du tunnel et changement d’URL.

Ce n’est pas difficile, mais cela brise le flux, et c’est exactement le genre de tâche mécanique, multi-étapes qu’un agent capable d’appeler des outils peut absorber — à condition que le tunnel soit accessible comme un outil plutôt qu’une commande shell mémorisée.

MCP, la norme qui rend cela possible

Anthropic a open-sourcé le Model Context Protocol le 25 novembre 2024, comme norme pour connecter les applications IA aux systèmes où résident données et outils. Avant MCP, connecter un modèle à un outil externe signifiait une intégration sur mesure pour chaque paire modèle–outil — le problème “N×M”, où N modèles ont chacun besoin d’un connecteur personnalisé pour M outils. MCP réduit cela à un seul serveur par outil, utilisable par tout client MCP-aware.

L’architecture comporte trois parties :

• Host — l’application utilisateur : IDE, client chat desktop, agent personnalisé.
• Client — la partie dans le host qui parle MCP et route les appels vers les serveurs.
• Server — le processus externe exposant outils (actions exécutables), ressources (données contextuelles), et prompts (modèles réutilisables) au client.

Les messages s’échangent en JSON-RPC 2.0, et le flux requête/réponse s’inspire du Language Server Protocol — le même pattern qui permet à tout éditeur de parler à tout backend d’autocomplétion sans intégration spécifique.

La couche de transport a déjà changé deux fois

La première version de MCP (05-11-2024) utilisait deux transports : stdio pour processus locaux à client unique, et HTTP+SSE pour serveurs distants. La révision du 26-03-2025 a remplacé HTTP+SSE par Streamable HTTP — un seul endpoint supportant le déploiement sans état derrière des load balancers et des sessions résumables, mieux adapté que le design SSE à deux endpoints. SSE est conservé pour compatibilité, mais plusieurs fournisseurs ont déjà prévu sa suppression.

Ce n’était pas la dernière étape. Le 28-07-2026 — une semaine après la rédaction —, les mainteneurs ont publié la révision du 28-07-2026, décrite par le lead mainteneur David Soria Parra comme le plus gros changement depuis le lancement. Elle supprime complètement la poignée de main de session au niveau protocole, rendant MCP sans état par défaut : un serveur n’a plus besoin de suivre un client entre les appels, ce qui permet à toute instance derrière une infrastructure HTTP ordinaire de répondre à une requête, sans affinité de session. Elle formalise aussi un cadre d’extensions (pour les MCP Apps, qui permettent à un outil de rendre sa propre UI) et une politique de cycle de vie des fonctionnalités garantissant au moins douze mois entre dépréciation et suppression. Les clients et serveurs existants du 25-11-2024 continuent de fonctionner — la nouvelle version est en mode opt-in lors de la mise à jour, et un serveur compatible peut répondre aux deux versions depuis un seul endpoint.

Adoption rapide

OpenAI a ajouté le support MCP à son SDK Agents le 26-03-2025 (“disponible aujourd’hui”, selon Sam Altman, avec Responses API et support desktop ChatGPT). Google DeepMind a confirmé que Gemini adopterait MCP en avril 2025. En décembre 2025, Anthropic a transféré la gouvernance du protocole à la Agentic AI Foundation, sous la Linux Foundation, cofondée par Anthropic, Block, et OpenAI, avec AWS, Google, Microsoft, Cloudflare, et Bloomberg comme membres fondateurs. À cette date, MCP comptait plus de 10 000 serveurs publics actifs et plus de 97 millions de téléchargements SDK mensuels. En juillet 2026, le nombre de téléchargements mensuels approchait le demi-milliard, avec les SDK TypeScript et Python dépassant chacun un milliard de téléchargements totaux. La gouvernance reste communautaire : l’appartenance au processus technique est liée aux individus, pas aux entreprises.

Compétences et serveurs MCP, deux choses différentes

Les fournisseurs de tunneling présentés ci-dessous utilisent tous un mécanisme lié, distinct de MCP : Compétences d’agent. Une compétence est un ensemble d’instructions et de références — flags CLI, usage SDK, prompts d’exemple — que l’agent lit une fois et exécute en utilisant un accès terminal classique. Un serveur MCP, en revanche, est un processus en cours que l’agent appelle directement comme un outil, sans reconstruire une commande à partir de la documentation. Ils sont publiés selon une norme communautaire partagée (skills CLI, distribué via npx skills add <url>) et installés dans le répertoire skills de l’agent — pour Claude Code, c’est ~/.claude/skills/<nom>/. La recommandation des fournisseurs est la même : commencez par la compétence si vous voulez que l’agent comprenne l’outil ; ajoutez le serveur MCP si vous souhaitez qu’il l’utilise de façon autonome.

La compétence et le serveur MCP de Pinggy

Pinggy fournit les deux, et ils peuvent être installés séparément.

La compétence :

npx skills add https://pinggy.io

Cela récupère le manifeste depuis https://pinggy.io/.well-known/skills/ et écrit les fichiers de compétence dans le répertoire skills de l’agent. La seule exigence est Node.js.

Le serveur MCP — source sur github.com/Pinggy-io/pinggy_mcp — nécessite Python 3.10+ et uv:

curl -LsSf https://astral.sh/uv/install.sh | sh

Rien ne s’installe globalement ; chaque client lance pinggy-mcp à la demande via uvx. Pour Claude Code, l’enregistrement se fait par une commande CLI, pas un fichier de config :

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

Claude Desktop, Cursor, et Windsurf utilisent une clé mcpServers dans un fichier JSON (chemins différents selon le client et le système d’exploitation) ; VS Code utilise une clé servers en haut niveau. À noter : la documentation de Pinggy qualifie le serveur MCP de “précoce et expérimental” et invite à donner des retours, plutôt que de le présenter comme prêt pour la production.

Une fois connecté, les prompts d’exemple documentés par Pinggy donnent une idée concrète :

• “Expose mon serveur dev sur le port 3000.”
• “Ouvre un tunnel TCP vers localhost:22.”
• “Partage mon dossier ~/Downloads sur Internet.”
• “Liste mes tunnels actifs.”
• “Autorise uniquement le trafic de 1.2.3.4 vers mon tunnel.”
• “Arrête le tunnel.”

Un détail destiné à la consommation par l’agent, pas par l’humain : chaque page de documentation Pinggy est aussi publiée en Markdown simple à la même URL avec un suffixe index.md, et le site entier est résumé dans pinggy.io/llms.txt — permettant à un agent de lire la doc directement, sans scraper du HTML rendu.

La surface MCP de Cloudflare est plus large que “tunnels”

Les serveurs MCP de Cloudflare ne se limitent pas à cloudflared — ils couvrent toute l’API Cloudflare. Le principal, le serveur MCP API Cloudflare (github.com/cloudflare/mcp, hébergé à https://mcp.cloudflare.com/mcp), expose plus de 2 500 endpoints via seulement deux outils : search() et execute(). Plutôt que de charger un schéma pour chaque endpoint, le modèle écrit du JavaScript contre une représentation typée du spec OpenAPI, qui s’exécute dans un sandbox Dynamic Worker — le pattern “Code Mode” de Cloudflare. La raison : exposer toutes les 2 594 endpoints avec schémas complets coûterait environ 1,17 million de tokens juste pour lister les outils ; la version en mode code ne coûte qu’environ 1 000 tokens, quel que soit le catalogue.

Au-delà, Cloudflare déploie aussi des serveurs MCP ciblés, spécifiques à un domaine : un serveur de documentation, un serveur de bindings pour Workers, un serveur d’observabilité, un Radar pour le trafic internet, un serveur d’audit, un serveur d’analyse DNS, etc., chacun sous son propre sous-domaine (ex. docs.mcp.cloudflare.com/mcp). Il n’y a pas de serveur “Tunnel” dédié dans cette liste ; la gestion d’un Tunnel Cloudflare — liste des tunnels actifs, vérification du statut, mise à jour des règles d’entrée — se fait via le serveur API MCP général, avec le même pattern search()/execute() contre les endpoints Tunnel et Zero Trust, comme pour toute autre ressource Cloudflare. Si vous souhaitez qu’un agent lie un nouvel environnement de prévisualisation à un sous-domaine, il utilise le même catalogue de 2 500+ endpoints, pas un outil spécifique dédié au tunnel.

Cloudflare intègre aussi ses serveurs MCP avec des compétences contextuelles et commandes slash via un ** plugin Cloudflare Skills** (github.com/cloudflare/skills), installable via le marketplace Claude Code (/plugin marketplace add cloudflare/skills), le Marketplace Cursor, ou le même CLI npx skills add utilisé par Pinggy.

Portails MCP : le vrai contrôle d’entreprise

La réponse de Cloudflare à “on ne peut pas donner un token API à un LLM sans supervision” est les portails MCP, partie de Cloudflare One Zero Trust (certains chemins API portent encore l’ancien nom, Agents Gateway). Un portail centralise plusieurs serveurs MCP derrière un seul endpoint HTTP protégé par Cloudflare Access. Concrètement :

• Authentification : les utilisateurs se connectent via Cloudflare Access avec leur fournisseur d’identité ; le portail demande aussi OAuth si nécessaire.
• Exposition contrôlée des outils : les admins peuvent désactiver certains outils ou prompts par serveur, ou créer une liste blanche où seuls certains outils sont visibles — utile si un serveur expose plus que ce qu’une équipe doit toucher.
• Code Mode par défaut : tous les outils upstream sont regroupés dans un seul outil code que l’agent écrit en JavaScript, dans un sandbox Dynamic Worker — cela maintient la consommation de contexte à un niveau constant, peu importe le nombre de serveurs.
• Logs : logs par requête (temps, statut, serveur, outil, durée) disponibles dans le dashboard, avec export Logpush vers SIEM en option pour les plans Entreprise.
• Routage Gateway optionnel : le trafic du portail peut passer par Cloudflare Gateway pour DLP, permettant de bloquer une réponse contenant des données sensibles ou des identifiants.

L’honnêteté de Cloudflare : MFA indépendante, prompts de justification, politiques d’authentification temporaire ne s’appliquent pas aux serveurs MCP autorisés via un portail, même si ces politiques sont configurées ailleurs dans l’Access. Le “portail” offre OAuth centralisé, outils sélectionnés, et logs DLP, mais ne remplace pas toutes les fonctionnalités d’Access.

Exemple concret de webhook

Stripe est une cible courante pour ce workflow, et c’est un bon exemple pour bien faire : ses capacités MCP ne mappent pas tout à fait à “l’agent contrôle tout”.

Le serveur MCP Stripe est à https://mcp.stripe.com. Contrairement à un serveur MCP hébergé, il supporte à la fois le flux OAuth standard et une clé API restreinte en bearer token — une voie documentée et supportée pour agents headless ou autonomes, pas une lacune à contourner. Ses outils couvrent info compte, remboursements, recherche/fetch de ressources, recherche dans la doc, planification d’intégration, plus des outils génériques stripe_api_read, stripe_api_write, et API-search qui couvrent la majorité du REST sans alourdir la liste.

Voici la limite importante pour un workflow de test de tunnel : un agent peut créer ou mettre à jour une webhook — en pointant son URL vers un nouveau tunnel — via l’outil d’écriture générique. Il ne peut pas s’abonner ou consommer le flux d’événements webhook en direct via MCP ; cela reste une infrastructure REST/webhook hors protocole. La procédure réaliste :

1. Demander à l’agent de démarrer le serveur local et de l’exposer avec l’outil MCP de Pinggy ou Cloudflare.
2. Lui demander de mettre à jour l’URL du webhook Stripe vers le nouveau tunnel, via l’outil d’écriture Stripe.
3. Lancer un événement test depuis le dashboard ou CLI Stripe, ou le faire faire par l’agent si vous utilisez l’outil CLI Stripe.
4. Vérifier que le serveur local l’a bien reçu et analysé.

Stripe recommande d’activer la confirmation humaine sur ses outils d’écriture et de faire attention à la combinaison avec d’autres serveurs MCP, notamment à cause du risque d’injection de prompts — conseil valable pour tout serveur MCP pouvant déplacer de l’argent ou reconfigurer la facturation. (Pinggy publie aussi un guide pour tester les webhooks Stripe — utile, que vous passiez par un agent ou non.)

Où en sont les IDEs agentiques mi-2026

Les trois éditeurs liés à ce workflow ont tous évolué depuis leur dernière comparaison :

• Cursor (de Anysphere) est en pleine acquisition par SpaceX, dans la plus grande opération de rachat par venture-backed. La valorisation en novembre 2025 était de 29,3 milliards de dollars ; en avril 2026, SpaceX a exercé une option d’achat, et en juin 2026, ils ont signé un accord en actions valorisant Anysphere à 60 milliards, pour intégrer Cursor dans leurs ambitions IA. La transaction n’est pas encore finalisée, prévue pour le T3 2026.
• Windsurf a commencé comme IDE agentique de Codeium. En juillet 2025, Google DeepMind a racheté le CEO, un co-fondateur, et des chercheurs clés pour environ 2,4 milliards, laissant Google sans participation. Peu après, le 14 juillet 2025, Cognition AI a acquis le reste du produit, IP, marque, et 210 employés, pour environ 250 millions. Le 2 juin 2026, Cognition a rebaptisé le produit Devin Desktop via une mise à jour OTA — l’IDE, les plans, et extensions ont été conservés, mais l’agent local s’appelle maintenant Devin Local, et l’accès cloud intégré dans la version payante.
• Claude Code fonctionne désormais sur six surfaces partageant un seul moteur : terminal CLI, extension VS Code, plugin JetBrains, application desktop, web à claude.ai/code (lancé en octobre 2025), et intégration Slack, avec mobile comme surface de contrôle à distance. La configuration, la mémoire de projet (CLAUDE.md), et les connexions MCP sont partagées ; une seule inscription suffit pour accéder depuis n’importe quelle interface.

Tous sont des clients MCP, ce qui est l’essentiel : le tunnel ne se soucie pas de l’éditeur utilisé, et un serveur MCP Pinggy ou Cloudflare configuré une fois doit fonctionner de la même façon, quel que soit l’éditeur.

Considérations de sécurité

Aucune de ces mesures ne dispense du jugement. La documentation MCP de VS Code est claire : les serveurs MCP locaux peuvent exécuter du code arbitraire, donc n’ajoutez que ceux provenant de sources fiables et vérifiées. C’est une règle raisonnable pour le serveur Pinggy, qui se dit “précoce et expérimental”.

Un autre risque, plus général : les agents ont tendance à traiter la sortie des outils MCP comme des données fiables, comme un prompt système, pas comme une entrée non fiable. Des chercheurs ont montré qu’on peut injecter de faux événements d’erreur dans un service de suivi d’erreurs pour faire qu’un agent corrige un bug inexistant, en suivant des instructions malveillantes. La leçon : tout serveur MCP en qui votre agent a confiance fait partie de votre surface d’attaque. Limiter les privilèges — IP allowlist, outils sélectionnés, confirmation humaine — reste la seule mitigation aujourd’hui.

En résumé

Gérer un tunnel via un appel d’outil MCP est une pratique réelle et opérationnelle : le serveur et la compétence Pinggy, le serveur API MCP Cloudflare, et le serveur MCP Stripe sont tous actifs, documentés, et vérifiables. Mais “précoce et expérimental” décrit la partie qui gère le tunneling, le protocole a connu sa plus grande rupture depuis son lancement, et les IDEs impliqués sont en pleine acquisition ou rebranding. Si vous intégrez cela dans un workflow aujourd’hui, faites-le comme pour toute nouvelle infrastructure : vérifiez ce que le serveur fait réellement, limitez ses accès, et ne vous contentez pas de penser que “l’agent a demandé poliment” équivaut à “c’est sûr”.

---

Changelog

Ce texte a été réécrit à partir d’un brouillon antérieur. Corrections et ajouts, vérifiés contre les sources principales :

1. Suppression du cadre “obsolète” / “révolution”. La version initiale présentait les tunnels gérés par IA comme une révolution déjà achevée. La nouvelle version voit cela comme une tendance émergente, encore peu utilisée au quotidien, conformément à la mention de MCP comme “précoce et expérimental” (pinggy.io/docs/ai_agents/) plutôt que prête pour la production.

2. Correction de la commande d’installation de compétence Pinggy. La version initiale utilisait npx skills add pinggy/skills. La documentation Pinggy recommande npx skills add https://pinggy.io, qui installe depuis le manifeste à pinggy.io/.well-known/skills/. (pinggy.io/docs/ai_agents/)

3. Correction et complétion des détails du serveur MCP Pinggy. Ajout du vrai dépôt GitHub (github.com/Pinggy-io/pinggy_mcp), des prérequis Python 3.10+ et uv, de la commande d’enregistrement claude mcp add exacte, et la différence de clé de config (servers pour VS Code, mcpServers pour Claude Desktop/Cursor/Windsurf). Remplacement de l’exemple de prompt par la liste officielle :

• “Expose mon serveur dev sur le port 3000.”
• “Ouvre un tunnel TCP vers localhost:22.”
• “Partage mon dossier ~/Downloads sur Internet.”
• “Liste mes tunnels actifs.”
• “Autorise uniquement le trafic de 1.2.3.4 vers mon tunnel.”
• “Arrête le tunnel.”

1. Remplacement de la section vague sur le serveur Cloudflare MCP par des détails vérifiés. Ajout de l’architecture (search()/execute() en Code Mode, 2 500+ endpoints, coût comparatif), des serveurs spécifiques (documentation, bindings, observabilité, Radar, audit, DNS), et correction : pas de “Tunnel” MCP dédié, gestion via le serveur API général.

2. Reformulation de la section Portails MCP avec sources officielles, incluant OAuth, contrôle des outils, Code Mode, logs, routage DLP, et la restriction sur MFA et prompts de justification.

3. Correction de la description du protocole MCP : date de sortie, architecture N×M, architecture host/client/server, message JSON-RPC 2.0 / LSP, etc. (anthropic.com/news/model-context-protocol)

4. Ajout de l’historique des transports : dépréciation HTTP+SSE en mars 2025, passage à Streamable HTTP, puis en juillet 2026, passage à MCP sans état par défaut.

5. Ajout des faits sur l’adoption : support OpenAI (mars 2025), Gemini (avril 2025), MCP à la Linux Foundation (décembre 2025), chiffres d’utilisation.

6. Correction du tutoriel webhook Stripe : capacité à créer/mise à jour webhook via outil d’écriture, mais pas à consommer le flux en direct. Ajout de recommandations Stripe.

7. Mise à jour du panorama IDE : Cursor, Windsurf, Claude Code, avec dates, acquisitions, noms, et détails.

8. Ajout d’une section sécurité concrète : conseils, risques, exemples d’attaques.

9. Suppression de détails non vérifiables ou fictifs.

10. Suppression du style SEO et de la métaphore “junior DevOps”, remplacement par une conclusion claire sur les compromis.