Modifier le fichier hosts sous Windows (2026)

Sous Windows, modifier le fichier hosts est une étape quasi obligatoire pour simuler des domaines locaux, tester un site avant migration DNS, ou bloquer des domaines au niveau système. Pourtant, la procédure surprend encore beaucoup de développeurs : le fichier est caché, protégé, et une simple ouverture double-clic dans le Bloc-notes échoue silencieusement à l’enregistrement.

Ce guide couvre Windows 10 et 11 (hors spécificités exclusives à Windows 11, traitées dans notre guide Windows 11). Pour une vue multi-plateforme, consultez le guide pilier Windows, Mac et Linux.

Emplacement et rôle du fichier hosts Windows

Chemin canonique :

C:\Windows\System32\drivers\etc\hosts

Le dossier etc reprend la convention Unix ; seul le fichier hosts nous intéresse ici (avec éventuellement lmhosts pour NetBIOS, rarement modifié manuellement).

Windows lit ce fichier avant d’interroger le résolveur DNS configuré (souvent votre routeur ou un DNS public). Toute entrée locale prime donc sur le DNS public pour ce poste.

Cas d’usage typiques :

• IIS / ASP.NET local : 127.0.0.1 app.local.test
• Docker Desktop : pointer un nom vers l’IP du conteneur ou 127.0.0.1
• Test de migration : IP du nouveau serveur + domaine de production
• Blocage : 0.0.0.0 pub.example.com — voir bloquer un site

Prérequis : droits administrateur

Sans élévation, Windows affiche parfois « Accès refusé » à l’enregistrement, ou semble enregistrer dans un emplacement temporaire incorrect. Consultez le guide droits administrateur pour les détails.

Règle d’or : toujours lancer l’éditeur via Exécuter en tant qu’administrateur.

Méthode 1 : Bloc-notes (recommandée pour débuter)

Étape par étape

1. Démarrer → taper Bloc-notes 2. Clic droit sur Bloc-notes → Exécuter en tant qu’administrateur 3. Fichier → Ouvrir 4. Naviguer vers C:\Windows\System32\drivers\etc 5. En bas à droite, choisir **« Tous les fichiers (*.*) » — sinon `hosts` n’apparaît pas 6. Ouvrir `hosts` 7. Ajouter vos lignes à la fin 8. Fichier → Enregistrer** (Ctrl+S)

Contenu par défaut (extrait) :

# Copyright (c) 1993-2009 Microsoft Corp.
#
127.0.0.1       localhost
::1             localhost

Exemple développement :

# Projet CRM 2026
127.0.0.1       crm.dev.test
127.0.0.1       api.crm.dev.test

Étape cruciale : flush DNS

ipconfig /flushdns

Exécutez cette commande dans une invite de commandes administrateur après chaque modification.

Méthode 2 : Invite de commandes

Pour les utilisateurs à l’aise avec la ligne de commande :

:: Ouvrir avec l'éditeur par défaut (admin requis)
notepad C:\Windows\System32\drivers\etc\hosts

Ou copie de sauvegarde avant modification :

copy C:\Windows\System32\drivers\etc\hosts C:\Users\%USERNAME%\Desktop\hosts.backup

Méthode 3 : PowerShell (administrateur)

Start-Process notepad "C:\Windows\System32\drivers\etc\hosts" -Verb RunAs

Ajout programmatique (attention à la duplication) :

Add-Content -Path C:\Windows\System32\drivers\etc\hosts -Value ([Environment]::NewLine + "127.0.0.1 nouveaudomaine.test")
ipconfig /flushdns

Utilisez cette approche avec prudence en production : vérifiez qu’une ligne identique n’existe pas déjà.

Syntaxe et bonnes pratiques

Référence complète : syntaxe /etc/hosts.

Rappels Windows :

• Séparateur : espaces ou tabulation entre IP et nom
• Commentaires : # en début de ligne
• Pas de wildcard natif
• Encodage : UTF-8 ou ANSI ; évitez UTF-8 avec BOM si des outils legacy lisent le fichier

Organisation recommandée pour les gros fichiers :

# ========== DEV ==========
127.0.0.1   app1.dev.test
127.0.0.1   app2.dev.test

# ========== STAGING TEMP ==========
# Retirer après 2026-07-01
203.0.113.8   demo.client.com

Vérifier vos modifications

ping

ping crm.dev.test

Réponse attendue : 127.0.0.1 (ou l’IP configurée).

nslookup (attention)

nslookup interroge souvent le DNS externe sans lire le fichier hosts de la même manière que les applications. Préférez ping ou test direct dans le navigateur.

Navigateur

Si ping OK mais pas le site :

1. ipconfig /flushdns 2. Chrome : chrome://net-internals/#dns → Clear host cache 3. Edge : équivalent via edge://net-internals/#dns

Dépannage Windows

« Access denied » à l’enregistrement

• Relancer Bloc-notes en administrateur
• Désactiver temporairement l’édition « protégée » si un suite bureautique intercepte (rare)
• Vérifier qu’Windows Defender ou un EDR n’ verrouille pas hosts

Le fichier semble se réinitialiser

Causes :

• Antivirus « protection hosts file »
• GPO entreprise qui repousse un template
• Outil de « optimisation » tiers

Action : consulter l’IT, ajouter une exception, ou utiliser un profil de test VM.

Modification ignorée par une application

Certaines apps Java ou .NET mettent en cache les résolutions au démarrage. Redémarrez l’application après flush DNS.

Conflit avec WSL

WSL2 possède son propre /etc/hosts dans la distro Linux. Une entrée Windows ne s’applique pas automatiquement à Ubuntu sous WSL. Éditez les deux si vous testez des deux côtés — voir guide Ubuntu pour la partie Linux.

Windows 10 vs Windows 11

Les chemins et commandes sont identiques. Windows 11 change surtout l’interface Démarrer et les raccourcis UAC. Détails visuels : guide Windows 11.

Sécurité

Modifier hosts est sûr si vous contrôlez le contenu. Risques : listes bloquantes trop larges, entrées de phishing local (rare), suppression accidentelle de localhost. Analyse : est-ce sûr ?.

Ne téléchargez jamais un fichier hosts « tout-en-un » sans le relire ligne par ligne.

Équipes de développement Windows

Standardisez un README projet :

## Hosts requis
127.0.0.1 app.projet.test
127.0.0.1 api.projet.test

Flush : ipconfig /flushdns

Pour les collègues Mac, partagez le même tableau de domaines ; eux utiliseront /etc/hosts ou Locahl — guide Mac.

Alternatives au fichier hosts

• DNS local : dnsmasq, Pi-hole (réseau entier)
• Proxy dev : Fiddler, mitmproxy
• Variables d’environnement pour les URLs en CI (pas de hosts en pipeline cloud)

Le fichier hosts reste le plus simple pour un poste isolé.

Intégration IIS et développement .NET

Sur Windows, la stack Microsoft reste très liée au fichier hosts pour le développement local :

IIS Express et Visual Studio

Visual Studio lance souvent des sites sur https://localhost:44300. Pour utiliser un nom réaliste (https://crm.dev.test), configurez :

1. Entrée hosts : 127.0.0.1 crm.dev.test 2. Binding IIS ou applicationhost.config avec le bon host 3. Certificat de développement (dotnet dev-certs) pour HTTPS

Sans l’entrée hosts, IIS ne recevra pas la requête avec le bon en-tête Host.

ASP.NET Core avec Kestrel

// launchSettings.json — profil local
"applicationUrl": "https://crm.dev.test:5001"

Combinez avec hosts + ipconfig /flushdns après chaque ajout.

Windows Server en VM

Les procédures sont identiques, mais vérifiez que Windows Defender sur Server n’applique pas une politique stricte sur System32. En Remote Desktop, lancez Notepad admin dans la session RDP, pas depuis votre poste local.

Automatisation prudente (scripts PowerShell)

Pour équipes qui provisionnent des postes Windows :

$entry = "127.0.0.1    app.projet.test"
$hostsPath = "$env:windir\System32\drivers\etc\hosts"
if (-not (Select-String -Path $hostsPath -Pattern "app.projet.test" -Quiet)) {
    Add-Content -Path $hostsPath -Value ([Environment]::NewLine + $entry)
    ipconfig /flushdns | Out-Null
}

Exécutez uniquement en session administrateur. Versionnez le script dans Git, pas le fichier hosts entier (contient souvent des entrées perso).

Journal de bord Windows : erreurs fréquentes en support

Ces patterns reviennent chaque semaine en équipe mixte — documentez-les dans votre wiki interne avec lien vers guide pilier.

Conclusion

Sur Windows, la clé est triple : Bloc-notes administrateur, filtre Tous les fichiers, ipconfig /flushdns. Une fois ces trois réflexes acquis, éditer C:\Windows\System32\drivers\etc\hosts devient routine.

Pour le contexte global (Mac, Linux, comparatif flush DNS), revenez au guide pilier multi-plateforme et au guide complet fichier hosts.