Le Model Context Protocol (MCP) a résolu la question de l'interface : comment un agent IA parle à un outil. Nous l'avons détaillé dans notre guide MCP. Reste une question d'infrastructure que ce protocole ne tranche pas à lui seul : comment laisser un agent dans le cloud accéder à un ERP, un CRM ou une base de données qui vivent derrière votre pare-feu, sans exposer ces systèmes à internet ?
C'est le rôle des MCP tunnels, annoncés par Anthropic le 19 mai 2026 en research preview. L'idée : connecter un agent et vos outils internes via un canal sortant contrôlé, sans ouvrir de port entrant ni publier vos systèmes sur internet. Le serveur MCP reste chez vous ; seule une liaison maîtrisée le relie à l'agent.
Cet article ne répète pas les bases de MCP. Il se concentre sur le tunnel : pourquoi l'exposition directe est risquée, comment fonctionne un tunnel, comment le sécuriser par des scopes et de l'identité, et comment concevoir une liaison qui restera valable sur 2 à 5 ans, quel que soit le modèle ou le fournisseur d'agent.
Le problème : exposer le SI à un agent sans l'ouvrir
Un agent IA utile a besoin de vos données internes : l'historique client du CRM, l'état des stocks dans l'ERP, une requête sur la base métier. Or ces systèmes ne sont pas, et ne doivent pas être, accessibles depuis internet. Trois mauvaises solutions sont fréquemment tentées.
- Ouvrir un port entrant vers le serveur MCP interne. C'est la porte d'entrée préférée des attaquants : toute la surface du SI devient potentiellement atteignable depuis l'extérieur.
- Copier les données dans le cloud pour que l'agent y accède. On duplique la donnée sensible, on perd la maîtrise de sa fraîcheur et de sa localisation, et on crée un nouveau périmètre à protéger.
- Donner à l'agent un accès VPN large. L'agent se retrouve avec une visibilité réseau bien supérieure à ce dont il a besoin — un confused deputy en puissance.
Le besoin réel est plus fin : exposer quelques outils précis (lire un client, vérifier un stock, lancer une requête en lecture) à un agent, sans rien ouvrir d'autre, sans copier la donnée, et en gardant une trace de chaque appel. C'est exactement ce que le tunnel MCP industrialise.
Qu'est-ce qu'un MCP tunnel
Un MCP tunnel est un canal sécurisé qui relie un agent IA (souvent hébergé dans le cloud) à un serveur MCP qui tourne dans votre réseau interne, sans exposer ce serveur ni vos systèmes à internet. Le serveur MCP reste derrière le pare-feu ; c'est lui qui établit une connexion sortante vers le point de rendez-vous, et l'agent passe par ce canal pour appeler les outils.
Annoncés par Anthropic le 19 mai 2026 en research preview, les MCP tunnels répondent à un besoin précis : connecter agents et outils internes sans tout exposer. Le principe est comparable à celui d'un tunnel inverse (reverse tunnel) : aucun port entrant à ouvrir, c'est l'intérieur qui initie la liaison vers l'extérieur, ce que les pare-feu autorisent déjà pour le trafic sortant.
Trois propriétés caractérisent un bon tunnel MCP :
- Connexion sortante uniquement : pas de port entrant, pas de surface d'attaque ajoutée côté SI.
- Périmètre minimal : seuls les outils MCP explicitement exposés transitent, pas un accès réseau général.
- Identité et traçabilité : chaque appel est authentifié et journalisé, comme pour un serveur MCP classique.
Le tunnel ne remplace pas MCP : il en est la couche de transport sécurisée pour le cas particulier où l'agent et l'outil sont de part et d'autre d'une frontière réseau.
Comment fonctionne un tunnel MCP
Le mécanisme repose sur l'inversion de l'initiative de connexion. Voici le flux, étape par étape.
- Le serveur MCP interne démarre dans votre réseau et établit une connexion sortante chiffrée vers un point de rendez-vous (relais du fournisseur ou relais que vous hébergez). Aucun port entrant n'est ouvert sur votre pare-feu.
- L'agent IA, côté cloud, s'adresse à ce point de rendez-vous pour appeler un outil exposé par le serveur interne.
- Le relais achemine l'appel dans le tunnel déjà établi jusqu'au serveur MCP interne, qui exécute l'action (lecture CRM, requête base) avec les droits du compte applicatif dédié.
- Le résultat repart par le même canal jusqu'à l'agent. À aucun moment l'agent n'a eu de route réseau directe vers vos systèmes.
Du point de vue du modèle, rien ne change : il appelle un tool MCP comme n'importe quel autre. Toute la complexité réseau est masquée par le tunnel. Du point de vue de la sécurité, le gain est majeur : la surface exposée se réduit aux quelques outils déclarés, et le SI ne reçoit aucune connexion entrante.
Tunnel vs exposition directe d'un serveur MCP
On peut exposer un serveur MCP de deux façons : directement (le serveur écoute sur une URL publique, derrière un API Gateway) ou via un tunnel (connexion sortante, aucun port ouvert). Le choix dépend de la sensibilité des systèmes derrière.
Exposition directe
Le serveur MCP est publié sur une URL accessible, protégé par OAuth, WAF et API Gateway. C'est adapté quand le serveur est déjà dans une zone exposable (un SaaS, un service cloud isolé) et qu'ouvrir un endpoint public est acceptable. C'est l'approche par défaut pour les serveurs MCP en HTTP streamable.
Tunnel
Le serveur reste strictement interne et n'ouvre aucun port. Le tunnel est le bon choix quand l'outil donne accès à des systèmes critiques qui ne doivent jamais figurer sur internet — ERP, CRM on-premise, base de production. On accepte une dépendance au relais en échange d'une surface d'attaque réduite à zéro côté entrant.
Règle de décision
- Système déjà exposable, faible criticité → exposition directe avec OAuth + WAF.
- Système interne critique, jamais public → tunnel MCP.
- Doute → tunnel par défaut : le coût marginal est faible, le gain de surface d'attaque est élevé.
Les deux approches partagent la même couche applicative MCP. Passer de l'une à l'autre est un changement d'infrastructure, pas une réécriture de l'agent — un atout pour la pérennité.
Cas d'usage : ERP, CRM, bases internes
Le tunnel MCP brille dès qu'un agent doit lire ou agir sur un système métier hébergé en interne. Voici les usages les plus fréquents en PME et ETI.
CRM : enrichir une réponse commerciale
Un agent d'aide à la vente lit l'historique d'un compte dans un CRM on-premise (commandes passées, tickets ouverts, encours) pour préparer une proposition. Le tunnel expose un seul outil read_customer en lecture, sans donner accès au reste du CRM ni au réseau.
ERP : vérifier stocks et disponibilités
Un agent de back-office consulte l'état des stocks et les délais dans l'ERP avant de confirmer une commande. Le tunnel n'expose que check_stock et get_lead_time ; l'ERP reste invisible depuis internet. C'est un terrain typique de notre offre d'automatisation métier.
Base interne : reporting conversationnel
Un copilot interroge une base de production en lecture seule (compte applicatif restreint, row-level security) via un tunnel, pour répondre à des questions métier en langage naturel. La donnée ne quitte jamais le réseau interne ; seul le résultat agrégé transite.
Outil métier maison
Une application interne (PIM, outil de gestion développé sur mesure) expose quelques actions à l'agent via un serveur MCP custom et un tunnel. Pour ce type d'intégration, voir nos outils internes sur mesure.
Le dénominateur commun : on expose des capacités précises, pas un accès réseau, et on garde la donnée chez soi.
Sécuriser un tunnel : scopes, identité, audit
Un tunnel réduit la surface réseau, mais ne dispense pas du travail de sécurisation applicative. Quatre piliers à mettre en place.
Scopes et moindre privilège
Le serveur MCP interne ne doit exposer que les outils strictement nécessaires, chacun sur un compte applicatif dédié et restreint : lecture seule sur la base, accès à un seul module de l'ERP, jamais un compte admin. Un tunnel mal scopé reste un risque même sans port ouvert.
Identité de l'appelant
Chaque appel transitant par le tunnel doit porter l'identité de l'utilisateur au nom duquel l'agent agit, pas une identité de service générique. C'est la parade au confused deputy : l'outil applique les droits de l'utilisateur réel, et l'audit sait qui a déclenché quoi.
Validation humaine des actions sensibles
Les actions à effet de bord (modifier une commande, écrire dans le CRM) passent par une confirmation humaine ou une politique de tool gating. Le tunnel protège le réseau, pas contre une décision erronée de l'agent.
Journalisation et audit
Tous les appels passant par le tunnel sont journalisés (qui, quel outil, quels arguments, quel résultat, quand) et exportés vers le SIEM. C'est indispensable pour le RGPD, l'ISO 27001 et la réponse à incident. Les secrets ne transitent jamais en clair et ne persistent pas côté agent.
En résumé : le tunnel sécurise le transport, les scopes et l'identité sécurisent l'usage. Les deux sont nécessaires.
Un tunnel pérenne à 2-5 ans
Le tunnel est une brique d'infrastructure qui doit survivre aux changements de modèle et de fournisseur d'agent. Quelques principes garantissent sa pérennité sur 2 à 5 ans.
S'appuyer sur le standard ouvert MCP
En exposant vos outils via MCP, standard ouvert et mature, vous restez indépendant du fournisseur d'agent. Un serveur MCP interne écrit aujourd'hui fonctionnera avec un agent Claude, Gemini ou un futur modèle, à travers le même tunnel.
Découpler l'agent du modèle
Faites passer le raisonnement par une couche d'abstraction multi-modèles. Le tunnel et les outils ne changent pas quand le modèle change ; seule la configuration d'appel évolue.
Garder la maîtrise du relais
Le point de rendez-vous (relais) peut être fourni par l'éditeur ou hébergé par vous. Pour l'anti lock-in, conservez la possibilité de relais self-hosted : si le research preview du fournisseur évolue, votre tunnel reste opérable.
Posséder les données et évaluer la non-régression
Les données restent chez vous par construction (c'est tout l'intérêt du tunnel). Ajoutez des évals de non-régression sur les appels d'outils internes pour détecter toute dérive de comportement lors d'une mise à jour de modèle ou de relais.
Le tunnel, parce qu'il garde la donnée et la logique côté client, est par nature un choix favorable à la souveraineté et à la pérennité.
Mettre en place un tunnel en entreprise
Voici l'approche progressive recommandée pour déployer un tunnel MCP en production sans surinvestir.
Étape 1 — Un outil interne, en lecture
Commencez par exposer un seul outil en lecture seule (par exemple read_customer sur le CRM) via un serveur MCP interne et un tunnel. Compte applicatif restreint, journalisation activée. Mesurez la valeur sur un cas concret avant d'élargir.
Étape 2 — Identité et scopes
Ajoutez l'identité de l'utilisateur appelant et durcissez les scopes. Validez avec l'équipe sécurité que la surface exposée correspond exactement au besoin métier.
Étape 3 — Actions à effet de bord
Introduisez progressivement des actions d'écriture, chacune protégée par une validation humaine ou une politique de tool gating, avec audit complet.
Étape 4 — Industrialisation et pérennité
Packagez les configurations de tunnels, centralisez les logs vers le SIEM, mettez en place la couche d'abstraction multi-modèles et les évals de non-régression. Évaluez l'option d'un relais self-hosted pour réduire la dépendance fournisseur.
Pour cadrer l'exposition sécurisée de vos systèmes internes à un agent, de l'ERP au CRM en passant par vos bases métier, contactez l'équipe Genee. Nous intégrons aussi ces agents dans des projets de développement sur mesure.
FAQ — MCP Tunnels : connecter vos agents IA à vos outils internes sans tout exposer
Qu'est-ce qu'un MCP tunnel ?
C'est un canal sécurisé qui relie un agent IA (souvent dans le cloud) à un serveur MCP tournant dans votre réseau interne, sans exposer ce serveur ni vos systèmes à internet. Annoncés par Anthropic le 19 mai 2026 en research preview, les MCP tunnels reposent sur une connexion sortante initiée par l'intérieur : aucun port entrant à ouvrir, seuls les outils MCP explicitement déclarés transitent.
En quoi un tunnel diffère-t-il d'exposer directement un serveur MCP ?
Une exposition directe publie le serveur MCP sur une URL accessible, protégée par OAuth et WAF : adaptée à des systèmes déjà exposables. Un tunnel garde le serveur strictement interne, sans aucun port ouvert, et fait passer les appels par une connexion sortante. Le tunnel est le bon choix pour des systèmes critiques (ERP, CRM on-premise, base de production) qui ne doivent jamais figurer sur internet.
Un tunnel MCP suffit-il à sécuriser l'accès à mon SI ?
Non. Le tunnel sécurise le transport et supprime la surface réseau entrante, mais il faut compléter par la sécurité applicative : scopes minimaux et compte applicatif restreint par outil, identité de l'utilisateur appelant (contre le confused deputy), validation humaine des actions sensibles, et journalisation vers le SIEM. Le tunnel protège le réseau, pas contre une mauvaise décision de l'agent.
Quels systèmes internes peut-on connecter via un tunnel MCP ?
Typiquement un CRM on-premise (lecture de l'historique client), un ERP (vérification de stocks et délais), une base de production en lecture seule pour du reporting conversationnel, ou un outil métier maison qui expose quelques actions. Dans chaque cas, on n'expose que des capacités précises via des tools MCP, jamais un accès réseau général, et la donnée ne quitte pas le réseau interne.
Comment garder un tunnel MCP pérenne sur plusieurs années ?
En s'appuyant sur MCP comme standard ouvert (indépendant du fournisseur d'agent), en découplant l'agent du modèle via une couche d'abstraction multi-modèles, en gardant la possibilité d'un relais self-hosted pour limiter le lock-in, en conservant la propriété des données (intrinsèque au tunnel) et en maintenant des évals de non-régression. Ainsi, changer de modèle ou de fournisseur reste un changement de configuration, pas une réécriture.
Faut-il ouvrir un port sur le pare-feu pour un tunnel MCP ?
Non, et c'est tout l'intérêt. C'est le serveur MCP interne qui initie une connexion sortante chiffrée vers un point de rendez-vous, comme le ferait n'importe quel client web. Les pare-feu autorisent déjà ce trafic sortant. Aucun port entrant n'est ouvert, ce qui n'ajoute aucune surface d'attaque côté SI tout en permettant à l'agent d'appeler les outils exposés.