ToggleHosts
Acheter · 4,99 €
Quel TLD utiliser pour le développement local (.test vs .localhost)

Quel TLD utiliser pour le développement local (.test vs .localhost)

3 min de lecture

Quel TLD utiliser pour le développement local : préférez .test, évitez .dev et .local. Pourquoi .test est réservé, comment le mapper dans le fichier hosts, conseils HTTPS.

Utilisez .test pour le développement local. Il est officiellement réservé par l’IETF (RFC 6761) pour les tests : il ne deviendra jamais un vrai domaine public et ne peut pas entrer en conflit avec un site réel. Évitez .dev (vrai TLD Google qui force le HTTPS) et .local (réservé au mDNS/Bonjour). Les autres options réservées sûres sont .localhost et .example.

Meilleurs TLD pour le développement local

TLDStatutPour le dev local ?
.testRéservé (RFC 6761)Oui, recommandé
.localhostRéservé (RFC 6761)Oui
.exampleRéservé (RFC 6761)Oui (moins courant)
.devVrai TLD, HSTS preloadNon, force le HTTPS
.localmDNS/BonjourNon, conflits de résolution
.appVrai TLD, HSTS preloadNon

Pourquoi .test l’emporte

.test ne résout jamais sur l’internet public : monappli.test signifie toujours « mon projet local ». Aucun risque qu’une faute de frappe d’un collègue fuite vers un vrai site, et aucune coercition HTTPS du navigateur.

Pourquoi éviter .dev et .app

Les deux sont de vrais TLD présents dans la liste HSTS preload. Les navigateurs y forcent le HTTPS, donc un serveur de dev en HTTP simple sur monappli.dev ne se charge pas. Si vous avez besoin de HTTPS en local, configurez-le volontairement avec mkcert, voir HTTPS local avec mkcert.

Pourquoi éviter .local

.local est réservé au DNS multicast (Bonjour/Avahi). L’utiliser dans le fichier hosts provoque des recherches lentes, des échecs intermittents et des conflits avec la découverte d’appareils.

Comment configurer un domaine .test

Ajoutez-le au fichier hosts et videz le DNS :

127.0.0.1 monappli.test api.monappli.test
Vous retaperez cette commande combien de fois ce mois-ci ?Automatiser avec ToggleHosts

Voir le guide de syntaxe du fichier hosts puis, une fois terminé, vider le DNS. Pour de nombreux sous-domaines dynamiques (*.monappli.test), le fichier hosts ne gère pas les wildcards, utilisez dnsmasq, expliqué dans domaines locaux wildcard avec dnsmasq.

Les gérer sans éditer les fichiers à la main

Jongler avec plusieurs domaines .test entre projets devient vite confus. ToggleHosts stocke chaque association avec une bascule en un clic et vide le DNS automatiquement : changer de projet est instantané.

_Dernière révision : juin 2026._

Sources et ressources externes

Questions fréquentes

Utilisez .test. Il est réservé par l’IETF (RFC 6761) pour les tests et ne sera jamais un vrai TLD public : aucun risque de conflit avec un domaine réel.

.dev est un vrai TLD public détenu par Google et figure dans la liste HSTS preload, ce qui force le HTTPS dans les navigateurs et casse les sites locaux en HTTP simple.

Non. .local est réservé au mDNS/Bonjour et peut provoquer des résolutions lentes ou échouées et des conflits sur de nombreux systèmes.

Ajoutez une ligne au fichier hosts : 127.0.0.1 monappli.test, puis videz le DNS. Pour plusieurs sous-domaines, utilisez dnsmasq avec un wildcard.

Articles similaires