Contexte de publication
Cette réflexion est issue d'un vocal enregistré le lundi 6 juillet 2026. L'article restitue fidèlement mon analyse à cette date, sans la retravailler à la lumière d'évolutions ultérieures. Les plateformes IA changent vite : certaines fonctionnalités mentionnées ici ont pu être ajoutées, modifiées ou retirées depuis. Ce texte est une photographie d'un raisonnement, pas un état des lieux permanent.
Dans un précédent article, le jour où la sécurité de mon compte IA est devenue un critère de choix, je racontais comment une vérification de routine avait déplacé mon regard sur la confiance que j'accorde aux plateformes IA. Ce que je décris ici est différent, mais complémentaire : ce n'est plus une question de confiance, c'est une question d'architecture. Ce lundi 6 juillet 2026, une évolution de la plateforme OpenAI, découverte presque par hasard en configurant ChatGPT, m'a fait comprendre que ces plateformes ne resteraient pas longtemps de simples interfaces de conversation.
Le contexte de juillet 2026
À ce moment-là, mon environnement de travail personnel repose déjà sur plusieurs briques que je fais tourner et maintenir moi-même : un cluster Kubernetes qui héberge une partie de mes applications, plusieurs serveurs MCP que j'expose pour connecter mes outils à différents assistants IA, des services auto-hébergés, et un ou deux agents personnels que j'ai construits pour automatiser certaines tâches. Je développe aussi, dans un cadre plus large, des SaaS et des applications métier — la question de savoir comment un système externe s'intègre proprement dans une architecture n'est donc pas nouvelle pour moi, c'est une préoccupation que j'ai déjà côté conception logicielle. Rien d'exotique dans cette liste pour qui travaille déjà avec ce type d'infrastructure — mais c'est précisément ce terrain qui a rendu la découverte du jour aussi immédiate, et qui explique pourquoi elle a retenu mon attention bien au-delà de ce qu'elle aurait représenté pour un utilisateur classique de ChatGPT.
Ce que je faisais déjà avec mes MCP
Avant ce lundi, mon usage des MCP suivait un schéma que je pense assez répandu chez ceux qui expérimentent avec ces protocoles : exposer un serveur MCP sur Internet, généralement derrière un reverse proxy ou une passerelle que je contrôle, pour qu'un assistant IA puisse s'y connecter et interagir avec mes outils. Ça fonctionne, mais ça implique une décision que je prends chaque fois avec un peu de prudence : accepter d'exposer directement un service sur Internet, même protégé, pour le rendre accessible depuis l'extérieur.
La découverte des tunnels
En configurant une intégration MCP sur mon compte ChatGPT ce jour-là, je suis tombé sur une option que je n'attendais pas, portée par l'écosystème OpenAI plutôt que par la seule interface de conversation : la possibilité de créer un tunnel. Le principe, une fois vérifié, correspondait exactement à ce que j'avais imaginé en voyant le terme : mon serveur MCP peut rester chez moi, sur mon cluster local, derrière une sorte de relais qui fait le lien avec ChatGPT — sans que j'aie besoin d'ouvrir ce service directement sur Internet.
Face à une nouvelle capacité comme celle-ci, je ne me suis pas arrêté à ce qu'elle permet aujourd'hui. C'est une habitude que j'ai prise dans ma pratique d'architecte : regarder une fonctionnalité en essayant d'imaginer ce qu'elle rendra possible demain dans les systèmes que je conçois, plutôt que de la juger sur son seul usage immédiat. C'est ce réflexe qui m'a fait, presque aussitôt, comprendre les implications techniques de ce tunnel avant même d'avoir fini de le tester.
Le déclic
Ce qui m'a arrêté net, ce n'est pas la fonctionnalité elle-même — techniquement, un tunnel n'a rien de révolutionnaire. C'est ce qu'elle rend possible pour quelqu'un qui, comme moi, héberge déjà ses propres services. En quelques secondes, j'ai projeté cette fonctionnalité sur mon infrastructure existante : mon MCP local, mes agents personnels, mon cluster Kubernetes à la maison — tout ça devenait connectable à ChatGPT sans exposition directe. Ce n'est plus l'assistant qui vient chercher une information ponctuelle. C'est un assistant qui peut venir consommer un agent que j'héberge chez moi, en continu, comme s'il s'agissait d'un service de plus dans mon architecture.
Le véritable basculement s'est produit à cet instant précis. Avant cette découverte, je considérais ChatGPT comme un outil externe, que j'utilisais ponctuellement, au même titre qu'un service tiers parmi d'autres. Après cette réflexion, j'ai commencé à le considérer différemment : comme un composant potentiel de mon propre système d'information, au même titre qu'un service que j'aurais moi-même déployé dans mon cluster. Ce glissement, d'outil externe à composant intégrable, est ce qui a réellement changé ma perspective ce jour-là — bien plus que la mécanique du tunnel elle-même.
Sans exagérer la portée de l'analogie, j'ai eu, sur le moment, le sentiment d'assister à une nouvelle étape dans la manière dont les plateformes numériques s'articulent entre elles — pas au sens où ce tunnel serait comparable à l'arrivée du Web ou du Cloud, mais au sens où il matérialisait, à mon échelle, un changement de paradigme dans la façon dont une IA peut interagir avec un système qu'on héberge soi-même. C'est un ressenti personnel, daté à ce lundi précis, pas une thèse sur l'histoire du numérique.
Pourquoi cela change ma manière de voir les plateformes IA
Jusque-là, je pensais les plateformes IA comme des points d'entrée : on leur pose une question, elles répondent, éventuellement en s'appuyant sur un outil qu'on leur a connecté ponctuellement. Ce que ce tunnel m'a fait comprendre, c'est qu'elles sont en train de devenir autre chose : des plateformes d'exécution à part entière, capables de s'intégrer directement dans une architecture existante, au même titre qu'un service cloud ou qu'une passerelle réseau. La conversation devient une couche parmi d'autres, pas le seul mode d'interaction.
Ce que j'imagine pour mes propres infrastructures
Immédiatement, plusieurs pistes concrètes se sont dessinées. Connecter mes agents personnels à ChatGPT sans jamais les exposer sur Internet. Faire dialoguer mon cluster Kubernetes local avec un assistant IA comme s'il s'agissait d'un service interne supplémentaire. Repenser certains de mes MCP non plus comme des services exposés en permanence, mais comme des points d'accès activés à la demande, via un tunnel plutôt qu'une exposition publique classique. Rien de tout cela n'est encore stabilisé dans ma tête à ce stade — c'est plutôt une liste de directions que cette découverte a ouvertes d'un coup.
Pourquoi je considère qu'il s'agit d'une évolution majeure
Pour un usage grand public, cette fonctionnalité peut sembler anecdotique — un détail de configuration parmi d'autres. Pour quelqu'un qui conçoit et héberge déjà ses propres systèmes, elle change la nature de la relation entre l'assistant IA et l'infrastructure personnelle. Elle déplace la question de "comment je connecte mon outil à cette IA" vers "comment j'intègre cette IA dans mon architecture existante" — un changement de posture, pas seulement un changement de fonctionnalité.
J'ai vérifié ce même jour si Claude AI proposait une option comparable : sur mon compte, à cette date du 6 juillet 2026, je n'ai pas trouvé d'équivalent aux tunnels que je viens de découvrir sur ChatGPT. Je le mentionne comme un constat daté, propre à mon compte et à ce moment précis — pas comme une comparaison durable entre les deux plateformes, dont l'écart, s'il existe, peut évoluer rapidement.
Ouverture
Ce que je retiens de ce lundi, ce n'est pas l'existence des tunnels MCP en tant que tels. C'est la confirmation d'une évolution plus large : les assistants IA ne sont plus seulement des outils auxquels nous nous connectons. Ils deviennent progressivement des composants capables de s'intégrer à nos propres architectures.
Pendant longtemps, notre travail d'intégration a surtout consisté à connecter nos applications à des services cloud — faire venir le cloud vers nos systèmes. Avec l'émergence des MCP et de mécanismes comme ces tunnels, j'ai eu ce lundi le sentiment que le mouvement commence à s'inverser : ce sont désormais les plateformes IA elles-mêmes qui cherchent à s'intégrer directement à nos propres systèmes, plutôt que l'inverse. Cette inversion de perspective, encore naissante et sans doute promise à évoluer vite, constitue à mes yeux le véritable sujet de cette réflexion — bien plus que la fonctionnalité qui me l'a révélée.
Après une première réflexion sur la confiance numérique et la sécurité des comptes IA, celle-ci porte sur l'architecture. Ce ne sont pas deux sujets indépendants, mais deux étapes d'une même réflexion sur ma pratique d'ingénieur : à mesure que ces plateformes s'intègrent plus profondément dans nos environnements de travail, comment je choisis de les y accueillir, et à quelles conditions je leur laisse une place dans les systèmes que je conçois. C'est une question que je compte continuer à explorer dans de prochains retours d'expérience, à mesure que ces usages se préciseront.