Quel TLD utiliser pour le développement local (.test vs .localhost)
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.
Gérez vos fichiers hosts sans terminal
ToggleHosts vous permet de gérer vos environnements visuellement sur Windows, macOS et Linux, avec flush DNS automatique et sauvegardes.
Paiement unique
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
| TLD | Statut | Pour le dev local ? |
|---|---|---|
| .test | Réservé (RFC 6761) | Oui, recommandé |
| .localhost | Réservé (RFC 6761) | Oui |
| .example | Réservé (RFC 6761) | Oui (moins courant) |
| .dev | Vrai TLD, HSTS preload | Non, force le HTTPS |
| .local | mDNS/Bonjour | Non, conflits de résolution |
| .app | Vrai TLD, HSTS preload | Non |
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.testVoir 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
- Comment fonctionne le DNS (Cloudflare Learning)
- Le fichier hosts expliqué (Wikipédia)
- Page de manuel hosts(5) (man7.org)
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
Développement WordPress local avec un domaine .test (fichier hosts)WordPress
Développement WordPress local avec un domaine .test (fichier hosts)
3 min de lecture
macOS 26 Tahoe : vider le cache DNS (2026)Vider le cache DNS
macOS 26 Tahoe : vider le cache DNS (2026)
6 min de lecture
Comment trouver et modifier le fichier hosts sous Windows 11 (Guide 2026)Modifier le fichier hosts
Comment trouver et modifier le fichier hosts sous Windows 11 (Guide 2026)
7 min de lecture