Pourquoi quitter votre éditeur ? Microsoft Dev Tunnels vs. ngrok en 2026

Les développeurs exposant un serveur local à Internet avaient une procédure simple : télécharger une CLI, créer un compte, coller un authtoken, et basculer entre leur éditeur et une fenêtre de terminal séparée. Microsoft a réduit cet écart ces dernières années en intégrant le port forwarding directement dans la vue Ports de VS Code, soutenu par son service Dev Tunnels. Pas besoin d’extension, pas de binaire séparé — juste un clic droit dans un panneau déjà ouvert.

Cela ne rend pas ngrok obsolète. Cela rend le choix plus intéressant, car les deux outils ont convergé vers des formes similaires dans leur version gratuite tout en restant différents dans leur objectif principal. Cet article détaille où Dev Tunnels l’emporte vraiment, où la narrative populaire sur la version gratuite de ngrok est dépassée, et où ngrok reste la seule option viable.

Le coût du changement de contexte

Le développement local au début des années 2020 était fragmenté : écrire du code dans VS Code, lancer l’application dans le terminal intégré, puis ouvrir un second terminal pour utiliser un outil de tunneling avec une URL HTTPS publique. Chaque fois que vous deviez tester un webhook Stripe ou partager un lien de prévisualisation, vous quittiez votre éditeur, vérifiiez si votre authtoken avait expiré, et copiez-collez des URLs dans un tableau de bord tiers.

La vue Ports de VS Code regroupe tout cela en un seul endroit. Si votre application tourne déjà dans le terminal intégré, le forwarding d’un port ne nécessite qu’un clic droit, pas un nouvel outil.

À quoi ressemble réellement la version gratuite de ngrok en 2026

Pendant des années, “utilisez simplement ngrok” était la réponse par défaut sur StackOverflow, et beaucoup de ce que les gens répètent sur sa version gratuite est maintenant faux. Deux affirmations en particulier sont souvent répétées et ne tiennent pas face à la documentation actuelle de ngrok :

“Les tunnels gratuits expirent après quelques heures.” Plus vrai. La documentation de ngrok indique clairement que les endpoints gratuits n’ont pas de timeout et peuvent fonctionner indéfiniment — vous pouvez même en faire un service en arrière-plan. Cela était vrai (les sessions expiraient après 8 heures dans l’ancienne version gratuite de ngrok), mais ngrok a supprimé cette limite.

“Vous obtenez une nouvelle URL aléatoire à chaque redémarrage.” Également dépassé. Depuis 2023, chaque compte ngrok — y compris gratuit — reçoit un “domaine dev” statique (comme your-name.ngrok-free.app) lié au compte et qui reste fixe même après redémarrage de l’agent. Les URLs aléatoires par session sont désormais une option payante, pas une contrainte de la version gratuite.

Ce qui reste vrai concernant la version gratuite, directement tiré de la page des limites de ngrok :

Ressource	Limite version gratuite
Transfert de données sortant	1 GB / mois
Requêtes HTTP	20 000 / mois
Connexions TCP	5 000 / mois
Endpoints en ligne	Jusqu’à 3 simultanément
Agents concurrents	3
Page d’avertissement interstitielle	Oui, pour le trafic HTML
Domaines personnalisés/vanity	Non disponible (toutes les autres offres)
Endpoints TLS (auto-terminés)	Non disponible

La page d’interstitiel est réelle et affiche un avertissement “ce site est servi par ngrok” lors de la première visite. Mais elle n’affecte pas les clients API ou les webhooks — les requêtes programmatiques la sautent, et vous pouvez aussi la contourner dans un navigateur en envoyant un header ngrok-skip-browser-warning ou un user-agent non par défaut.

Les offres payantes de ngrok, avec leur tarification réelle

Plan	Prix	Ce qu’il débloque
Gratuit	0 $	Crédit unique de 5 $, 3 endpoints, 1GB/20k requêtes, domaine dev uniquement
Hobbyist	8 $/mo annuel (10 $/mo mensuel)	5GB, 100k requêtes, pas d’interstitiel, pool de domaines ngrok (pas entièrement custom)
Pay-as-you-go	20 $/mo de base + usage	Endpoints illimités, domaines personnalisés, wildcard, SSO/RBAC

Une correction importante : un domaine personnalisé comme api.votredomaine.com n’est pas une fonctionnalité du plan Hobbyist. Ce dernier ne débloque que des domaines issus du pool de ngrok. Pour apporter votre propre domaine, il faut passer à Pay-as-you-go, à partir de 20 $/mo plus la consommation supplémentaire.

Microsoft Dev Tunnels : Qu’est-ce que c’est réellement

Dev Tunnels est intégré dans la vue Ports de VS Code — pas besoin d’extension pour le forwarding de base. Lancez un serveur local, ouvrez la vue Ports, forwardez le port, et authentifiez-vous avec le même compte GitHub ou Microsoft que vous utilisez déjà. L’agent établit une connexion SSH sortante vers un relais hébergé par Microsoft dans Azure ; aucune règle de firewall entrante à configurer, aucun listener local exposé.

Voici quelques points que la présentation “basculez simplement vers Dev Tunnels” oublie souvent :

C’est encore une préversion publique sans SLA. La documentation officielle de Microsoft est claire : “Cette version préliminaire est fournie sans accord de niveau de service, et il n’est pas recommandé pour la production.” Ce profil de risque est différent d’un service avec un engagement de disponibilité, ce qui est important si vous pointez un webhook de fournisseur de paiement dessus.

Il a ses propres limites d’utilisation, pas “aucune limitation de bande passante.” Selon la documentation de Microsoft, qui se réinitialise mensuellement :

Ressource	Limite
Bande passante	5 GB par utilisateur
Tunnels	10 par utilisateur
Ports par tunnel	10
Connexions actives	1 000 par port
Taux de requêtes HTTP	1 500/min par port
Débit de transfert	Jusqu’à 20 MB/s par tunnel
Taille maximale du corps de requête	16 MB

Les 5 GB sont plus généreux que la version gratuite de ngrok, mais équivalent à ce que le plan Hobbyist à 8 $/mo offre — pas la capacité illimitée et sans throttling que la formule “gratuit à vie” laisse entendre.

Il y a un timeout HTTP fixe de 60 secondes par requête, non configurable. Toute requête dépassant 60 secondes échoue, selon la documentation de Microsoft. Pour la plupart des webhooks, cela suffit, mais c’est une contrainte réelle si votre traitement est synchrone et long.

Les URLs “persistantes” expirent après inactivité. La durée par défaut est de 30 jours sans trafic ; vous pouvez définir une expiration personnalisée, mais la limite maximale reste à 30 jours. Fermer votre ordinateur pendant un week-end et le rouvrir lundi reste dans cette fenêtre, donc la déclaration selon laquelle le webhook survit au week-end est correcte. Laisser un tunnel inactif pendant plus d’un mois ne l’est pas.

L’interstitiel anti-phishing existe aussi. Dev Tunnels affiche la même alerte de premier accès dans le navigateur que ngrok — la documentation de Microsoft décrit une page anti-phishing pour les requêtes HTML, qu’on peut sauter via un header (X-Tunnel-Skip-AntiPhishing-Page: True) ou un Accept non-HTML, comme ngrok avec ngrok-skip-browser-warning. Ce n’est pas un avantage spécifique de Dev Tunnels, les deux outils le gèrent de la même façon, et tous deux le sautent pour le trafic API ou programmatique.

Rien de tout cela ne fait de Dev Tunnels un mauvais choix pour ses usages : partage ad hoc, tests webhook en développement actif, liens de prévisualisation mobile. Mais cela nuance l’idée de “zéro-friction, sans limite, et qui remplace ngrok”.

Comparatif direct

Coût. Dev Tunnels est gratuit, sans offre payante. Mais ses limites d’utilisation sont proches du plan Hobbyist de ngrok, pas de l’illimité. La version gratuite de ngrok est plus restrictive (1GB/20k requêtes contre 5GB pour Dev Tunnels), mais 8 $/mo suppriment ces limites. Aucun n’est clairement gagnant ; cela dépend si vous préférez rester dans les limites mensuelles de Dev Tunnels ou payer pour des limites plus élevées et publiées de ngrok.

Installation. Dev Tunnels gagne si vous utilisez déjà VS Code — il n’y a vraiment rien à installer. ngrok nécessite un binaire et un authtoken, mais l’installation prend moins d’une minute.

Sécurité et contrôle d’accès. ngrok l’emporte ici. Son moteur Traffic Policy supporte OAuth/OIDC/SAML en edge, IP allowlist, TLS mutuel, règles au niveau des requêtes — même dans ses offres payantes, bien en dessous du prix enterprise. Dev Tunnels propose trois niveaux d’accès (Privé, Organisation via Entra, Public) et des contrôles Group Policy pour les flottes gérées sous Windows, ce qui est plus simple mais moins configurable.

Domaines personnalisés. ngrok l’emporte, mais uniquement à partir du plan Pay-as-you-go (20 $/mo+). Hobbyist ne propose que des domaines du pool de ngrok, pas de bring-your-own. Dev Tunnels n’offre pas de domaine personnalisé à aucun niveau ; vous utilisez toujours *.devtunnels.ms.

Persistance. Les deux proposent des URLs stables par défaut — le domaine dev statique de ngrok et l’ID de tunnel persistant de Dev Tunnels. La différence est que celui de Dev Tunnels expire après 30 jours d’inactivité.

Prêt pour la production. ngrok l’emporte ici : offre un SLA et est explicitement destiné à la production. Dev Tunnels est en préversion publique, sans SLA, et indiqué pour le développement et les tests uniquement.

Posture de sécurité comme cible. Les domaines des deux outils ont été documentés comme vecteurs d’abus. ngrok figure dans le cadre MITRE ATT&CK (ID logiciel S0508) pour phishing et C2, et certains équipes de sécurité bloquent ses domaines. Microsoft dev tunnels ont aussi été documentés par des chercheurs en red team comme pouvant servir à du C2, car le trafic vers un domaine Microsoft est moins susceptible d’être bloqué. Aucun des deux n’est intrinsèquement dangereux, mais dans un environnement sensible, attendez-vous à une surveillance.

Tunnels pour agents IA et serveurs MCP

Ce cas d’usage récent concerne les deux outils, et mérite d’être mentionné séparément, car il n’existait pas quand “utiliser ngrok pour les webhooks” était la règle. Les serveurs MCP (Model Context Protocol) locaux pour agents de codage tournent souvent en stdio ou localhost, et les exposer à un agent cloud nécessite un tunnel.

ngrok propose un guide dédié : faire tourner l’agent ngrok devant un serveur MCP local, en utilisant ses fonctionnalités d’identité, Traffic Policy, et observabilité pour que chaque requête MCP soit authentifiée et auditable. Plusieurs wrappers open-source (ngrok-mcp-host par exemple) automatisent la mise en place d’un serveur MCP derrière un tunnel ngrok et fournissent la configuration nécessaire.

Microsoft documente une autre approche : utiliser la CLI devtunnel pour exposer un serveur MCP ou API REST local, permettant à l’agent Microsoft 365 Copilot d’y accéder lors du développement, avec l’option tunnel persistant recommandée pour éviter de mettre à jour le manifeste à chaque changement d’URL.

Aucun des deux outils n’a créé une infrastructure spécifique pour MCP — ils appliquent leurs primitives existantes à ce nouveau cas d’usage. Si vous avez besoin de contrôle de politique ou de journalisation, ngrok avec Traffic Policy est plus mature. Si vous travaillez déjà dans l’écosystème VS Code/Copilot pour un test rapide, Dev Tunnels évite d’installer quoi que ce soit.

Mise en place du port forwarding dans VS Code

1. Démarrez votre serveur local dans le terminal intégré de VS Code (npm run dev, ou équivalent).
2. Ouvrez la vue Ports — dans le même panneau que Terminal et Debug Console, ou via Ports: Focus on Ports View dans la palette de commandes.
3. Forwardez le port en cliquant sur “Forward a Port” ou en tapant le numéro de port. La première fois, vous devrez vous connecter avec GitHub ou Microsoft.
4. Définissez la visibilité. Par défaut, les forwards sont privés (seul votre compte y accède). Pour tester un webhook, faites clic droit sur le port, choisissez Port Visibility, et passez en Public.
5. Copiez l’URL — elle ressemblera à https://random-string-3000.usw2.devtunnels.ms — et utilisez-la comme vous le feriez avec une URL ngrok.

Tout le processus peut aussi se faire via le clavier : Cmd/Ctrl+Shift+P → Ports: Forward a Port.

Le bon choix pour vous

Optez pour ngrok si vous avez besoin d’authentification en edge (OAuth/OIDC/SAML), d’un domaine personnalisé, de règles de trafic au niveau de la requête, ou si vous approchez de la production. Ses offres payantes existent parce que ces fonctionnalités ont une vraie valeur, pas parce que la version gratuite est limitée.

Privilégiez Dev Tunnels si vous utilisez déjà VS Code, souhaitez un lien public rapide pour une revue de design ou un test webhook en développement, et que vous n’avez pas besoin qu’il survive un mois d’inactivité. La simplicité d’installation est un vrai avantage.

Ne supposez pas que l’un remplace l’autre immédiatement. Dev Tunnels étant en préversion sans SLA est une contrainte pour des usages critiques ; ngrok, avec ses limites, n’est pas forcément une solution illimitée. Choisissez en fonction des besoins précis — persistance, sécurité, ou simplement partager une URL pour cinq minutes — plutôt que de privilégier la nouveauté.

---

Historique des modifications

Corrections et ajouts lors de la vérification des faits, avec sources :

1. Suppression de l’affirmation erronée selon laquelle ngrok en version gratuite a des timeout de session. La documentation officielle indique que les endpoints gratuits n’ont pas de timeout et peuvent fonctionner indéfiniment. (Ancienne limite avant 2023, maintenant supprimée.) Source : ngrok Free Plan Limits

2. Suppression de l’affirmation erronée selon laquelle les URLs ngrok aléatoires changent à chaque redémarrage. Depuis août 2023, chaque compte ngrok, y compris gratuit, possède un domaine dev statique lié au compte, qui persiste. Sources : ngrok Free Plan Limits, ngrok blog: Static dev domains for all ngrok users

3. Vérification et maintien des chiffres de 1GB/mois et 20 000 requêtes/mois, ajout du tableau complet des limites actuelles (connexions TCP, taux, etc.) provenant de la page officielle de ngrok. Source : ngrok Pricing

4. Correction sur la disponibilité des domaines personnalisés. Seul le plan Pay-as-you-go (20 $/mo+) permet d’apporter son propre domaine. Hobbyist ne propose que des domaines du pool de ngrok. Source : ngrok Pricing

5. Vérification des prix (8 $/mo pour Hobbyist, facturé annuellement ; 10 $/mo facturé mensuellement ; 20 $/mo pour Pay-as-you-go) contre la page officielle, pas des sources tierces obsolètes. Source : ngrok Pricing

6. Ajout de la mention que Dev Tunnels est en préversion publique sans SLA, conformément à la documentation officielle, et qu’il n’est pas destiné à la production. Source : What are dev tunnels? — Microsoft Learn

7. Ajout des limites d’utilisation de Dev Tunnels (5GB/mois, 10 tunnels, 10 ports/tunnel, 1 500 req/min, etc.), qui contredisent la présentation initiale d’aucune limitation stricte. Source : Dev tunnels service limits — MicrosoftDocs/azure-docs

8. Ajout du timeout HTTP fixe de 60 secondes sur Dev Tunnels, documenté par Microsoft, important pour le cas des webhooks. Source : Microsoft Q26A: Do Dev Tunnels Have an HTTP Timeout Issue?

9. Ajout de l’expiration de 30 jours d’inactivité pour les URLs “persistantes” de Dev Tunnels, correction de la perception d’une persistance illimitée. Source : Dev tunnels FAQ — Microsoft Learn

10. Correction sur la page d’avertissement anti-phishing. Dev Tunnels affiche une alerte de premier accès dans le navigateur, équivalente à ngrok, et non une différence avantageuse. Source : Dev tunnels security — Microsoft Learn, Dev tunnels in Visual Studio 2022 — Microsoft Learn

11. Vérification que le port forwarding dans VS Code ne nécessite pas d’extension pour l’usage de base. Source : Port Forwarding — VS Code docs

12. Ajout d’un paragraphe sur le tunneling des serveurs MCP et agents IA, avec références : Using ngrok as your MCP gateway, Debug MCP and API plugins locally — Microsoft Learn

13. Ajout d’une note de sécurité sur l’historique d’abus des domaines des deux outils (ngrok dans MITRE ATT&CK, dev tunnels documenté comme pouvant servir à du C2). Sources : Huntress: Abusing Ngrok, ngrok: How ngrok Actively Combats Phishing Attacks

14. Réécriture de la conclusion pour éviter le ton de gagnant absolu et de hype, en proposant une approche basée sur les besoins et compromis.

15. Suppression de tout front matter/metadata et reformattage en Markdown propre.