La bataille des domaines apex : tunnels abordables pour domaines racine en 2026

Si vous êtes développeur, freelance ou propriétaire d’agence, vous connaissez déjà la magie de tunneliser votre localhost vers Internet public. Vous construisez une application web, la lancez sur le port 3000, démarrez un tunnel, et partagez instantanément un lien en direct avec un client à l’autre bout du monde.

Mais il y a un piège qui brise l’illusion d’un produit poli et prêt pour la production : l’URL.

Depuis des années, la norme du secteur limite les développeurs à des URLs auto-générées et aléatoires comme 1a2b3c.ngrok-free.app. Si vous souhaitez utiliser votre propre domaine avec un domaine racine personnalisé, on vous oriente souvent vers un sous-domaine (app.votredomaine.com). Mais que faire si vous voulez votre vrai domaine racine — votredomaine.com ?

Bienvenue dans la bataille des domaines apex. Et c’est un combat plus déséquilibré que la plupart des articles de comparaison le laissent entendre : le leader du marché, ngrok, ne se contente pas de rendre les domaines racine coûteux — sa propre documentation indique clairement qu’il ne les supporte pas du tout, sur aucun plan, à aucun prix. Ce seul fait redéfinit toute cette comparaison, et c’est la première chose à bien comprendre avant de recommander quoi que ce soit.

Cet article explique pourquoi les domaines apex sont difficiles à tunneliser, ce que ngrok offre ou ne offre pas en 2026, et comment trois architectures vraiment différentes — le relais DNS de Pinggy, la délégation complète de serveurs de noms de Localtonet, et le flattening CNAME de Cloudflare Tunnel — résolvent le problème en pratique.

1. Comprendre le domaine apex et le problème du CNAME

Avant d’aborder les alternatives, il est utile de comprendre pourquoi les domaines racine (aussi appelés domaines apex ou nus) sont notoirement plus difficiles à tunneliser que les sous-domaines.

Qu’est-ce qu’un domaine apex ?

Dans la hiérarchie DNS, le domaine apex est la “racine” de votre nom de domaine — sans préfixe de sous-domaine.

• Domaine apex/racine : exemple.com
• Sous-domaine : www.exemple.com, api.exemple.com, staging.exemple.com

La limitation du CNAME

Lorsque vous pointez un domaine personnalisé vers un service de tunnel, celui-ci vous demande généralement de créer un enregistrement CNAME (Canonical Name). Un CNAME mappe votre domaine au nom d’hôte du fournisseur (par exemple, faire pointer app.exemple.com vers tunnel.provider.com).

Le problème, c’est qu’un enregistrement CNAME ne peut pas coexister avec d’autres types d’enregistrements DNS au même nom, et un domaine apex (exemple.com) doit contenir des enregistrements SOA (Start of Authority) et NS (Name Server) à sa racine. Comme un CNAME écraserait ces enregistrements, la norme DNS ne permet pas d’en avoir un au sommet de la zone — c’est une contrainte du protocole, pas une politique d’un fournisseur.

Comment les fournisseurs contournent ce problème

Il n’existe pas de solution universelle — différents services utilisent réellement différentes mécanismes, et le choix influence ce que vous pouvez faire ou non par la suite :

• Relais A/AAAA. Le fournisseur vous donne des adresses IP statiques IPv4/IPv6 à mettre directement dans vos enregistrements A et AAAA du domaine racine. C’est ce que fait Pinggy.
• Flattening CNAME (ALIAS/ANAME). Certains fournisseurs DNS — Cloudflare en natif, DNSimple ou DNS Made Easy via un type d’enregistrement ALIAS/ANAME — résolvent la cible du CNAME sur leurs serveurs et renvoient une réponse A/AAAA aplatie. Cloudflare Tunnel s’appuie sur cette technique, ce qui implique de déplacer la gestion DNS de votre domaine vers Cloudflare.
• Délégation complète de serveurs de noms. Plutôt que d’ajouter quelques enregistrements, vous déléguez tout le domaine à un fournisseur qui devient votre hébergeur DNS — avec tous les enregistrements (MX, TXT, etc.). C’est un engagement plus lourd, mais cela évite le problème du CNAME au sommet, car le fournisseur contrôle directement la zone. Localtonet utilise ce modèle.
• Aucun support. Certains fournisseurs ne proposent tout simplement aucune de ces options pour le domaine apex — comme ngrok, qui ne supporte pas du tout les domaines racine.

2. Le vrai problème avec ngrok en 2026

Ngrok a été pionnier dans le tunnel localhost et reste un excellent produit pour le tunneling TCP/TLS/HTTP avec OAuth, SAML, et des fonctionnalités d’observabilité. Mais pour les domaines apex, la limitation n’est pas une question de tarif — c’est le produit lui-même. La documentation de ngrok pour les domaines personnalisés dit en quatre mots : “ngrok ne supporte pas actuellement les domaines apex.” Pas de note de bas de page pour l’Enterprise, pas de solution de contournement, pas d’option A-record. Si vous voulez votredomaine.com sans préfixe pointant vers un tunnel ngrok, ngrok ne peut pas le faire, peu importe ce que vous payez.

C’est important à comprendre, car la plupart des comparaisons — y compris des versions antérieures de cet article — présentent cela comme ngrok “réservant les domaines racine à ses plans supérieurs,” ce qui sous-entend que payer plus vous y donne accès. Ce n’est pas le cas. Ce que vous payez en plus, c’est un sous-domaine personnalisé (app.votredomaine.com), configuré via un CNAME standard, et uniquement sur le plan Pay-as-you-go ou supérieur.

Voici la tarification réelle de ngrok en 2026, vérifiée avec leur documentation :

• Gratuit — un crédit d’usage unique de 5$, limité à 1 Go de transfert, 20 000 requêtes HTTP, jusqu’à 3 points de terminaison en ligne. Vous avez un domaine de développement auto-attribué ; les points de terminaison HTTP(S) affichent une page d’avertissement avant de transférer le trafic.
• Hobby ($10/mois, ou $8/mois annuel) — supprime la page d’interstitiel, inclut 5 Go de transfert, 100 000 requêtes HTTP, et jusqu’à 10 sous-domaines ngrok (non personnalisés). Aucun domaine personnalisé de quelque nature que ce soit dans ce plan.
• Pay-as-you-go ($20/mois + usage) — le plan nécessaire pour un vrai domaine personnalisé, mais uniquement en sous-domaine via CNAME. La facturation est de 0,01$ par heure d’endpoint actif, en plus du forfait de base ; si vous apportez votre propre certificat TLS, des frais de 0,27$/domaine/heure actif s’appliquent.

Si vous laissez un tunnel avec sous-domaine personnalisé actif ²⁴⁄₇ pendant un mois (730 heures), cela coûte environ 7,30$ en facturation de domaine, en plus des 20$ de base — soit environ 27$/mois, et cela ne résout pas le problème du domaine apex, car ngrok ne peut pas le faire sur aucun plan.

Une vraie solution de contournement ngrok : pour TCP, ngrok décrit dans sa documentation comment faire pointer un sous-domaine vers le nom d’hôte TCP aléatoire (par exemple, tcp.mondomaine.com → 5.tcp.ngrok.io) pour que le nom d’hôte reste stable. C’est une vraie fonctionnalité, mais c’est une astuce pour TCP, pas une solution pour HTTP(S) sur domaine apex.

3. Pourquoi les développeurs ont besoin de tunnels pour domaines racine

Étant donné que ngrok est hors course ici, pourquoi se battre pour ça plutôt que d’utiliser staging.exemple.com ?

A. Démos client en marque blanche. Envoyer un lien comme https://59d3a1.ngrok-free.app donne l’impression d’un “travail en cours.” https://staging.votreagence.com est mieux. https://client-startup-nom.com — qui pointe directement vers votre machine locale — donne l’impression d’un produit fini en pleine réunion Zoom, sans CI/CD.

B. Tests stricts de webhooks. Les fournisseurs de paiement et API (Stripe, Shopify, Mailgun, etc.) exigent des webhooks HTTPS, et certains valident contre le domaine enregistré exact plutôt qu’un sous-domaine arbitraire. Un domaine personnalisé stable — apex ou sous-domaine — évite de devoir reconfigurer les URL de callback à chaque redémarrage de tunnel.

C. Comportement des cookies et CORS. Si votre frontend définit des cookies pour le domaine apex (.exemple.com) en production, tester sur un domaine généré automatiquement ou un sous-domaine différent peut faire apparaître des bugs liés aux cookies ou CORS, qui ne se manifestent que si le domaine ne correspond pas à la production. Utiliser le domaine apex en local élimine ces bugs spécifiques à l’environnement.

4. Les options abordables pour les domaines apex

1. Pinggy — l’approche de relais documentée

Tarification : plan Pro à environ 3$/mois facturé mensuellement (~2,37–2,50$/mois annuel). La version gratuite est toujours gratuite, mais les tunnels sont limités à 60 minutes avec des URLs non persistantes.

Pinggy est un bon choix pour les domaines apex car il propose une vraie solution au problème du CNAME au sommet, appelée relai. Vous vérifiez la propriété du domaine via un enregistrement TXT, choisissez une région de relai proche de votre trafic, et Pinggy vous fournit des adresses IP statiques A et AAAA à mettre dans votre enregistrement @ DNS.

Une nuance que les pages de tarification ne mettent pas en avant : la documentation de Pinggy indique que le domaine personnalisé basé sur relais fonctionne pour HTTP(S), TLS, et TCP, mais pas UDP — si vous avez besoin d’un tunnel UDP sur domaine apex, le sous-domaine persistant de Pinggy (pas le domaine racine) est la seule option supportée.

Configuration (syntaxes réelles) :

# 1. Démarrez votre serveur local
npm run start
# Écoute sur http://localhost:3000

# 2. Dans le tableau de bord Pinggy (Domaines personnalisés), ajoutez votre domaine racine,
# vérifiez l’enregistrement TXT, choisissez une région de relai, et ajoutez les enregistrements A/AAAA
# fournis chez votre DNS (host : @)

# 3. Une fois validé et le certificat émis, démarrez le tunnel
# avec votre token Pro — le domaine configuré pour ce token est
# utilisé automatiquement :
ssh -p 443 -R0:localhost:3000 your-token@pro.pinggy.io

Il n’y a pas d’option spéciale dans la CLI pour “utiliser mon domaine personnalisé” — vous associez le domaine à votre token dans le dashboard une fois, et chaque tunnel lancé avec ce token passe par lui. Pinggy fournit automatiquement un certificat Let’s Encrypt une fois la validation DNS terminée.

2. LocalXpose — excellent pour sous-domaines, non confirmé pour domaine racine

Tarification : plan Pro à 8$/mois (96$/an), 10 tunnels actifs, bande passante illimitée sous réserve de politique d’utilisation acceptable. La version gratuite inclut 2 tunnels HTTP actifs.

LocalXpose est un outil de tunneling complet — supporte HTTP(S), TCP, TLS, UDP, avec une interface graphique native, sous-domaines génériques, et contrôles d’accès IP/authentification basique. La documentation indique qu’il supporte “domaines personnalisés,” ce qui est vrai et utile pour les sous-domaines.

Mais pour le domaine racine, la documentation officielle pour la configuration d’un domaine personnalisé (loclx domain reserve --domain exemple.com) montre la création d’un enregistrement CNAME — le même mécanisme que, selon la règle DNS, ne peut pas légalement résider au sommet d’une zone. Il n’y a pas de processus publié pour relayer via A/AAAA, TXT + IP statique, ou délégation de serveurs de noms, comme pour Pinggy ou Localtonet. Cela ne veut pas dire que c’est impossible — certains DNS avec flattening (Cloudflare, DNSimple) pourraient faire fonctionner un CNAME au sommet — mais la documentation de LocalXpose ne fournit pas de méthode confirmée pour cela. Si un domaine racine est nécessaire, il vaut mieux contacter leur support plutôt que de supposer une compatibilité totale.

3. Localtonet — support du domaine racine via délégation complète

Tarification : environ 2$/tunnel/mois, facturé uniquement quand le tunnel est actif (pay-as-you-go). Version gratuite : 1 tunnel, 1 Go/mois, timeout de 30 minutes.

Localtonet adopte une approche différente et plus engagée : au lieu d’ajouter des enregistrements chez votre DNS, vous enregistrez le domaine dans le gestionnaire DNS de Localtonet, puis remplacez les serveurs de noms autoritaires chez votre registrar par ns1.localtonet.com et ns2.localtonet.com. À partir de là, Localtonet devient votre hébergeur DNS pour le domaine — tous les enregistrements (A, CNAME, MX, TXT) sont gérés depuis leur interface.

L’avantage : c’est une configuration uniforme : une fois la délégation propagée (environ 1-2 heures, jusqu’à 48 en cas rare), vous pouvez pointer des tunnels HTTP, TCP ou UDP vers le domaine racine en laissant le champ sous-domaine vide — pas besoin de relais séparé, aucun protocole exclu. HTTPS automatique avec Let’s Encrypt inclus. La contrepartie : vous confiez tout le contrôle DNS, y compris les enregistrements MX pour email, ce qui est une étape plus importante que de simplement ajouter quelques enregistrements. Si vous avez déjà des MX, il faut les recréer dans le gestionnaire DNS de Localtonet avant de couper.

4. Cloudflare Tunnel — gratuit, mais très lourd en infrastructure

Tarification : le tunnel Cloudflare (cloudflared) est gratuit et sans limite de bande passante — intégré à la plateforme Zero Trust de Cloudflare, qui propose une version gratuite (jusqu’à 50 utilisateurs) et une option payante à 7$/utilisateur/mois pour des fonctionnalités avancées. La configuration consiste à faire passer le trafic via le réseau Cloudflare vers un processus léger sur votre machine. Comme Cloudflare est aussi fournisseur DNS, le flattening CNAME au sommet s’applique automatiquement dès que votre domaine pointe vers Cloudflare — pas besoin de gérer des IP ou relai.

Le défi : il faut migrer vos serveurs de noms vers Cloudflare, installer et authentifier cloudflared, et configurer des règles d’entrée — une étape initiale plus complexe qu’une simple commande SSH. Pour un domaine destiné à une utilisation longue et en production, c’est une option solide et gratuite. Pour une démo client rapide, c’est excessif.

5. Comparaison rapide

Fournisseur	Prix d’entrée	Support du domaine racine	Mécanisme	UDP sur domaine racine
ngrok	10$/mois Hobbyist, 20$/mois+usage Pay-as-you-go	Non — non supporté sur aucun plan	N/A (CNAME sous-domaine uniquement sur plans payants)	Non (ngrok ne supporte pas UDP)
Pinggy	~3$/mois	Oui, documenté	Vérification TXT + relais A/AAAA	Non (relai exclut UDP)
LocalXpose	8$/mois	Non confirmé	CNAME uniquement (d’après la doc officielle)	Oui, pour sous-domaines
Localtonet	~2$/tunnel/mois	Oui, documenté	Délégation complète de serveurs de noms	Oui
Cloudflare Tunnel	Gratuit	Oui, documenté	Flattening CNAME (nécessite migration NS)	Non (HTTP/TCP uniquement)

6. Performances et sécurité

Exposer localhost à Internet — surtout sur un domaine racine visible — contourne le pare-feu NAT de votre routeur, donc quelques précautions sont essentielles.

TLS automatique. N’utilisez pas un outil de tunnel 2026 qui ne supporte pas HTTPS automatique. Pinggy, LocalXpose, et Localtonet provisionnent tous des certificats Let’s Encrypt automatiquement.

Latence géographique. Si votre client est à Londres et vous à Tokyo, un relai dans la mauvaise région ajoute de la latence. Pinggy permet de choisir une région de relai ; choisissez celle la plus proche de votre trafic.

Contrôle d’accès. Si votre panneau d’administration ou votre base de données est accessible via votre domaine racine, n’importe qui peut le trouver. Utilisez l’authentification basique ou la liste blanche IP — supportée par Pinggy et LocalXpose — et whiteliste les IPs connues.

7. Conclusion

Le problème du domaine apex est une contrainte DNS réelle, pas une astuce marketing — mais le paysage des fournisseurs qui le supportent est plus varié qu’un simple comparatif de prix ne le laisse penser. Ngrok n’est pas l’option la plus chère ici ; c’est celle qui ne supporte pas cette fonctionnalité, sur aucun plan. Pinggy la résout à moindre coût avec un relais documenté et modéré. Localtonet la résout aussi, mais demande un contrôle DNS complet. Cloudflare Tunnel la supporte gratuitement, mais nécessite la délégation DNS et une configuration plus avancée. LocalXpose est un tunnel multi-protocoles très capable, mais n’a pas encore publié de mécanisme pour le domaine racine.

Quel que soit votre choix, ce n’est pas vraiment “pas cher vs cher” — c’est jusqu’où vous êtes prêt à déléguer le contrôle DNS, et si chaque protocole (notamment UDP si besoin) doit vivre sur le domaine racine.

FAQ

Q : Puis-je utiliser un enregistrement CNAME pour un domaine apex ? R : Non. La norme DNS ne permet pas à un CNAME de coexister avec les enregistrements SOA et NS au sommet d’une zone. Il faut des A/AAAA, un service de flattening CNAME/ALIAS/ANAME, ou une délégation complète.

Q : ngrok supporte-t-il les domaines racine sur un plan, y compris Enterprise ? R : La documentation de ngrok indique clairement qu’il ne supporte pas les domaines apex, sans exception. Même le plan Pay-as-you-go, qui supporte les domaines personnalisés, ne supporte que les sous-domaines via CNAME.

Q : Quels outils documentent explicitement le support des domaines racine ? R : Pinggy (via vérification TXT + relais A/AAAA) et Localtonet (via délégation DNS complète) proposent une méthode spécifique. Cloudflare Tunnel supporte aussi via flattening CNAME, une fois la délégation DNS en place. La documentation de LocalXpose ne montre qu’un flux basé sur CNAME, qui est une solution pour sous-domaines.

Q : Supportent-ils aussi les sous-domaines génériques ? R : Oui — Pinggy, LocalXpose, et Localtonet supportent tous le routage par wildcard (*.exemple.com), utile pour tester des SaaS multi-tenant.

Q : Ces services sont-ils sécurisés par défaut ? R : Tous proposent HTTPS automatique. Étant donné que vous exposez une machine locale, il est conseillé d’activer l’authentification basique ou la liste blanche IP pour les données sensibles — ces options sont disponibles mais pas activées par défaut.

---

Changelog

Vérifié le 5 septembre 2026 contre les sources officielles (ngrok, Pinggy, LocalXpose, Localtonet, Cloudflare). Modifications principales :

• Correction majeure : ngrok ne limite pas la prise en charge des domaines racine à ses plans supérieurs, mais ne supporte pas du tout cette fonctionnalité. La documentation indique explicitement, sans condition de plan, “ngrok ne supporte pas actuellement les domaines apex”.
• La tarification de ngrok a été précisée : crédit d’usage unique de 5$, limite à 1 Go, 20 000 requêtes, 3 endpoints, page d’avertissement.
• La version Hobbyist ne comprend pas de domaine personnalisé, seulement des sous-domaines ngrok.
• La facturation pour le domaine personnalisé en mode pay-as-you-go est de 0,01$/heure + 0,27$/domaine/heure si vous apportez votre propre certificat.
• La configuration de Pinggy pour le relais est corrigée : supporte HTTP(S), TLS, TCP, pas UDP.
• La configuration de LocalXpose est précisée : supporte HTTP(S), TCP, TLS, UDP, mais la documentation officielle ne montre pas de mécanisme confirmé pour le domaine racine.
• La délégation DNS de Localtonet est expliquée : changement des serveurs de noms pour gérer tout le domaine.
• La description de Cloudflare Tunnel est ajustée : gratuit, sans limite, nécessite migration DNS, configuration initiale plus complexe.
• La table de comparaison est actualisée avec les mécanismes précis et les limitations.
• La section sécurité insiste sur l’importance de TLS automatique, contrôle d’accès, et latence.
• La conclusion insiste sur la différence réelle dans le contrôle DNS et la nécessité de choisir selon ses besoins protocolaires.
• La FAQ clarifie la compatibilité DNS et support des plans.
• La correction de l’erreur sur ngrok et la précision des mécanismes est intégrée.