MCP Tunnels : Claude qui dialogue avec votre LAN privé

Vous utilisez Claude au quotidien, mais une question revient souvent : comment lui faire toucher les outils qui vivent à l'intérieur de votre entreprise, sans publier ces outils sur Internet ? C'est exactement ce que les MCP Tunnels permettent. Un tunnel MCP est un petit pont chiffré qui laisse passer Claude vers vos serveurs internes (NAS, GitLab interne, base de données, ERP), sans qu'aucun de ces services ne soit visible depuis le web. Cet article explique le mécanisme en mots simples, et raconte ce que ça change concrètement quand on l'installe au studio.

D'abord, un MCP, c'est quoi ?

Pour suivre la suite, il faut poser un mot. Un MCP, pour Model Context Protocol, est une sorte de prise de courant standardisée qui permet à Claude de se brancher sur un outil tiers. Quand Claude a un MCP « Notion » actif, il sait lire et écrire dans Notion sans copier-coller. Quand il a un MCP « GitHub » actif, il sait ouvrir une pull request, lire un fichier, fermer une issue. Il existe aujourd'hui plus d'une centaine de MCP officiels, des géants comme Slack ou Figma jusqu'à des services plus spécialisés.

Pour un panorama complet, lisez notre annuaire des MCP avec les lignes de commande prêtes à copier. Ici, retenez juste ceci : un MCP, c'est l'adaptateur qui transforme Claude en collègue qui sait faire des choses dans vos outils, et plus seulement répondre à des questions.

Le problème : Claude reste à la porte du LAN

Maintenant, le souci concret. La grande majorité des MCP officiels sont hébergés sur le web : leurs URL ressemblent à https://mcp.notion.com/mcp, https://mcp.linear.app/mcp, https://mcp.stripe.com. Claude, qui tourne dans le cloud d'Anthropic, sait les joindre sans difficulté : tout se passe sur Internet, à la lumière du jour.

Le problème arrive quand l'outil que vous voulez brancher n'est pas sur Internet. Il vit à l'intérieur de votre réseau : un GitLab self-hosted derrière le pare-feu de la boîte, une instance Jira on-premise, un NAS Synology dans le local technique, un Postgres interne, un dossier réseau partagé qui ne sort jamais du LAN. Ces services sont volontairement invisibles depuis le web, parce que ce qu'ils contiennent (du code propriétaire, des données clients, des contrats) n'a pas vocation à être public.

Dès lors, vous avez deux mauvaises options. Soit vous publiez vos services internes sur Internet, ce qui ouvre une surface d'attaque énorme. Soit vous renoncez à les brancher à Claude, ce qui prive vos équipes d'un gain de productivité majeur. Les MCP Tunnels existent précisément pour sortir de ce dilemme.

La solution : un tunnel chiffré qui traverse le pare-feu

L'idée d'un tunnel est ancienne. On la retrouve dans tous les outils de type Cloudflare Tunnel, Tailscale ou ngrok. Le principe se résume en une phrase : au lieu d'ouvrir un trou dans votre pare-feu pour laisser entrer le monde, vous lancez depuis l'intérieur du LAN un petit logiciel qui sort une connexion vers un service de confiance, et qui maintient ce canal ouvert. Toutes les requêtes destinées à votre service interne passent désormais par ce canal, dans les deux sens. Votre pare-feu ne voit qu'une connexion sortante, autorisée, vers une adresse connue.

Appliqué à Claude, le principe est le même. Un service de tunnel MCP, hébergé par votre éditeur ou par votre équipe, expose une URL publique du type https://votre-entreprise.mcp.tunnel.app/gitlab. Sur votre poste interne, un agent léger relie cette URL au GitLab local. Claude appelle l'URL publique, le tunnel transporte la requête jusqu'à votre GitLab, le GitLab répond, le tunnel renvoie la réponse. À aucun moment GitLab n'a quitté le LAN.

💡 Un tunnel MCP, c'est l'inverse d'un trou dans le pare-feu. C'est un canal sortant et chiffré, contrôlé bout en bout, qui laisse Claude utiliser vos outils internes sans les rendre visibles depuis l'extérieur.

Trois propriétés rendent l'approche acceptable du point de vue sécurité. La connexion part de l'intérieur, donc votre pare-feu ne voit qu'un flux sortant. Le canal est chiffré bout en bout, donc personne n'écoute ce qui transite. L'identité de l'utilisateur reste tracée, donc vous savez qui, depuis Claude, a appelé quoi sur votre serveur interne. Avec ces trois propriétés, le service de sécurité de l'entreprise dort tranquille.

Concrètement, ce que ça change au studio

Au-delà du schéma, l'effet pratique se mesure rapidement. Voici quelques situations qu'on retrouve souvent chez nos clients, et la différence entre « sans tunnel » et « avec tunnel ».

Situation	Sans tunnel MCP	Avec tunnel MCP
Documentation interne sur un wiki self-hosted	Copier-coller manuel dans Claude	Claude lit le wiki directement, cite ses sources
Code propriétaire sur un GitLab privé	Pas d'accès, ou exposé sur Internet	Claude ouvre des PR sans rien exposer
Base de données interne d'un ERP	Export CSV à la main	Claude interroge en lecture seule, en direct
Dossier réseau de production	Téléchargement local puis upload	Claude accède au fichier, le travaille, le repose

Dans chaque cas, le gain est le même : Claude travaille là où vivent les données, au lieu de les forcer à transiter par le presse-papier. Le second effet, plus discret, c'est la traçabilité. Les requêtes passent toutes par le tunnel, donc tout est journalisé. On sait qui a demandé quoi, à quel moment, sur quel service interne. C'est précieux pour les équipes qui doivent rendre des comptes en cas d'audit.

Comment ça s'installe, vu de loin

Le détail technique varie selon le fournisseur que vous choisissez, l'écosystème des tunnels MCP étant en pleine maturation. Mais la trajectoire d'installation se ressemble toujours, en trois étapes. D'abord, on crée un compte sur le service de tunnel et on génère une URL publique dédiée à l'entreprise. Ensuite, on installe sur un poste interne (un serveur, un mini-PC, un container Docker) un petit agent qui ouvre la connexion sortante vers cette URL. Enfin, on configure dans Claude le MCP correspondant à l'URL publique, comme on le ferait pour n'importe quel autre MCP officiel.

À ce stade, Claude « voit » l'outil interne comme s'il était public, mais le pare-feu n'a jamais été ouvert. Le seul flux qui le traverse est la connexion sortante de l'agent, vers un endpoint connu et autorisé. La sécurité opérationnelle reste donc maîtrisée.

Au studio, nous installons régulièrement ce type de pont chez nos clients. Cela fait partie de nos prestations AI Studio, et nous l'enseignons dans nos masterclasses, à côté des autres briques d'écosystème Claude. Si vous voulez en discuter sur votre contexte précis, contactez-nous. L'accompagnement va du diagnostic réseau jusqu'à la mise en service, en passant par la formation interne pour que vos équipes prennent le relais.

Les pièges à éviter

Trois écueils reviennent souvent lorsque l'on déploie son premier tunnel MCP. Le premier, le plus visible, est de l'installer en mode « tout permis », c'est-à-dire un seul tunnel qui donne accès à tout le LAN. C'est le contraire de la bonne pratique. Un tunnel se configure par service, pas par réseau. Chaque MCP interne (GitLab, Postgres, NAS) a son propre tunnel, avec ses propres droits.

Le deuxième écueil concerne la gestion des secrets. Un tunnel donne accès à un service, mais c'est encore Claude qui doit s'authentifier au service derrière. Les tokens d'accès doivent être stockés du côté de l'agent local, jamais transmis à Claude en clair, et idéalement rotés régulièrement.

Le troisième est plus subtil : la journalisation. Un tunnel donne une traçabilité par construction, mais encore faut-il que cette journalisation soit centralisée, indexée et auditable. Sinon, le jour où vous devez expliquer ce que Claude a fait sur votre Postgres interne le mois dernier, vous n'aurez pas la réponse.

Pourquoi vous y viendrez tôt ou tard

Pour les studios créatifs comme pour les PME industrielles, la question n'est plus de savoir si Claude va devenir un collaborateur du quotidien. Cette bascule est déjà engagée. La vraie question est : qui contrôle ce que Claude voit ? Et la réponse, ce sont les MCP Tunnels qui la rendent praticable. Ils permettent d'ouvrir Claude à vos outils internes sans renoncer au socle qui justifie l'existence même d'un LAN : la maîtrise du périmètre.

Pour acquérir la méthode complète, du choix des MCP jusqu'au déploiement en réseau privé, parcourez nos masterclasses. Pour une mise en place sur mesure dans votre infrastructure (audit réseau, choix du fournisseur de tunnel, configuration des secrets, formation interne), écrivez-nous depuis la page contact. Nous accompagnons régulièrement ce type de déploiement chez nos clients via nos prestations AI Studio.

Pour approfondir le sujet du côté du protocole, la documentation officielle d'Anthropic sur le Model Context Protocol donne le détail des messages échangés à travers un tunnel. Et pour comprendre le pattern dans son histoire plus large, la documentation Cloudflare reste la référence pédagogique en la matière.