Windows ne voit pas les autres PC : faire fonctionner réellement la découverte réseau

février 7, 2026 • février 7, 2026 • Lecture : 25 min • Views: 0

Cet article vous a aidé ?

C’est toujours le même scénario : vous ouvrez l’Explorateur de fichiers, cliquez sur Réseau, et c’est un désert. Pour autant vous pouvez pinguer l’autre PC, naviguer sur Internet, et Teams bouffe le CPU comme si chaque cycle comptait. Alors pourquoi Windows ne « voit »‑t‑il pas une machine qui est pourtant juste là ?

Parce que la « découverte réseau » n’est pas une seule chose. C’est un empilement de services, de règles de pare‑feu, de chemins de résolution de noms, de comportements hérités de navigation SMB et de ce que votre routeur décide d’autoriser aujourd’hui. Nous allons rendre ça à nouveau ennuyeux — dans le bon sens.

Ce qu’est vraiment la « découverte réseau » (et pourquoi elle ment)

Quand les utilisateurs disent « Windows ne voit pas les autres PC », ils veulent généralement dire l’un des cas suivants :

La vue Réseau de l’Explorateur est vide ou manque certaines machines.
Le mappage d’un lecteur par nom échoue (par ex. \\FILES01\Share).
L’accès par IP fonctionne (par ex. \\192.168.1.50\Share) mais les noms non.
Ping fonctionne mais SMB ne fonctionne pas.
SMB fonctionne mais l’ordinateur n’apparaît pas dans les listes de navigation.

Ce sont des modes de défaillance différents. Traitez‑les différemment.

Voici la vérité gênante : le dossier Réseau dans l’Explorateur n’est pas un système de supervision fiable. C’est une interface utilisateur alimentée par des mécanismes de découverte qui peuvent être bloqués par le profil réseau, le pare‑feu, l’état des services, ou par la posture de sécurité moderne. Il peut être faux même quand le partage de fichiers fonctionne parfaitement.

Donc l’objectif n’est pas « faire apparaître des icônes ». L’objectif est :

Les noms d’hôtes se résolvent de façon cohérente.
Les ports SMB sont joignables sur le bon réseau.
Les partages sont accessibles avec la bonne authentification.
La découverte fonctionne là où vous la voulez (généralement le LAN Privé), et est bloquée ailleurs (Wi‑Fi public, aéroports, etc.).

Une citation à coller sur votre écran : « L’espoir n’est pas une stratégie. » — Gordon R. Sullivan. (Si vous gérez des systèmes en production, vous l’avez déjà appris à la dure.)

Mode opératoire de diagnostic rapide (vérifiez ça d’abord)

Voici la séquence « débloquez‑moi en cinq minutes ». Exécutez‑la sur le PC qui ne voit pas les autres et, si besoin, sur le PC cible qui devrait être visible.

1) Confirmez que vous êtes sur le bon profil réseau

Si le profil est Public, la découverte est censée être bridée. Corrigez cela avant de toucher à autre chose.

2) Testez la résolution de noms vs. la reachabilité

Essayez ping TARGET et ping TARGET_IP.
Essayez Test-NetConnection TARGET -Port 445 et par IP.

Si l’IP fonctionne et que le nom échoue : c’est DNS/LLMNR/mDNS/NetBIOS, pas « partage ».

3) Vérifiez les groupes de règles du pare‑feu et les services de découverte

Windows peut joyeusement indiquer « Découverte réseau activée » alors que les règles de pare‑feu sont désactivées, ou que les services Function Discovery sont arrêtés.

4) Ignorez l’Explorateur et testez SMB directement

Ouvrez \\TARGET\Share. Si ça marche, vous avez un problème de navigation/découverte, pas de partage de fichiers.

5) Si c’est un domaine d’entreprise, supposez une GPO

Surtout si « ça marchait hier ». La stratégie de groupe peut rétablir des services, des règles de pare‑feu et le comportement de résolution de noms. Ne luttez pas manuellement — corrigez la politique.

Faits intéressants & brève histoire (vous arrêterez d’accuser la mauvaise chose)

Un peu de contexte aide car le réseau Windows est un musée où les pièces sont toujours branchées.

La tradition de la « liste de navigation » vient de NetBIOS/Computer Browser, un système hérité qui utilisait des élections par broadcast pour décider qui liste les machines. C’est pourquoi c’était instable sur des réseaux multi‑sous‑réseaux.
SMBv1 était autrefois lié au comportement de navigation. Quand SMBv1 a été largement désactivé pour des raisons de sécurité, beaucoup ont interprété la vue Réseau plus vide comme « le réseau est cassé ».
WS‑Discovery (WSD) est devenu une méthode de découverte plus moderne pour les appareils et certains scénarios Windows, mais il dépend fortement du pare‑feu et du comportement multicast.
LLMNR existe parce que DNS n’est pas toujours présent sur les petits réseaux. C’est pratique, et aussi une cible commune pour l’interception d’identifiants en environnement hostile.
mDNS n’est plus « juste pour Apple ». Windows supporte mDNS dans les builds modernes, et il apparaît dans les foyers mixtes plus souvent qu’on ne le croit.
Les profils réseau (Public/Privé/Domaine) ont été introduits pour réduire les incidents « je me connecte au Wi‑Fi du café et j’expose mes partages ». Les échecs de découverte sont souvent une fonctionnalité, pas un bug.
SMB sur TCP/445 a remplacé NetBIOS sur TCP/139 pour la plupart des environnements Windows modernes, mais certains outils et habitudes touchent encore l’ancienne pile.
La vue Réseau de l’Explorateur est volontairement conservative dans Windows moderne. Ce n’est pas un annuaire canonique ; c’est une UI de commodité qui favorise la sécurité et la réduction du bruit.

Principes de base : profil, pare‑feu, services, noms, SMB

1) Le profil réseau décide de la posture de sécurité par défaut

Si votre interface réseau est définie sur Public, Windows bloquera ou limitera le trafic utilisé pour la découverte et le partage de fichiers. Vous pouvez activer « Découverte réseau » dans les Paramètres toute la journée et obtenir des résultats incohérents si le profil sous‑jacent est incorrect.

2) Les règles de pare‑feu comptent plus que l’application Paramètres

Windows a des groupes de règles de pare‑feu comme Network Discovery et File and Printer Sharing. Si ceux‑ci sont désactivés, la découverte ne fonctionnera pas. S’ils sont activés sur le mauvais profil, vous pouvez accidentellement annoncer votre machine sur des réseaux où vous ne le devriez pas.

3) Les services sont la salle des machines

Deux services sont souvent en cause :

Function Discovery Provider Host (FDPHost)
Function Discovery Resource Publication (FDResPub)

Si ceux‑ci sont arrêtés/désactivés, votre machine peut ne pas se publier et vous pouvez ne pas découvrir les autres de façon fiable.

4) La résolution de noms est une bête à plusieurs têtes

Quand vous tapez \\TARGET, Windows peut résoudre ce nom en utilisant :

DNS (meilleure option sur les réseaux gérés)
LLMNR
mDNS
NetBIOS name service (hérité)
Fichier hosts (override manuel)

Différents environnements en désactivent différents (souvent pour de bonnes raisons de sécurité). Vous devez savoir sur lequel vous vous appuyez.

5) Le partage SMB peut fonctionner même si la découverte est cassée

La découverte sert à trouver les choses. SMB sert à se connecter. Ne confondez pas les deux. Si vous pouvez accéder à \\IP\Share, votre partage est valide. Vous avez un problème de nommage ou de navigation.

Blague #1 : La découverte réseau Windows, c’est comme les commérages au bureau : rapide, peu fiable, et ça s’arrête quand la direction (aka le pare‑feu) débarque.

Tâches pratiques avec commandes : diagnostiquer et décider

Ce sont de vraies tâches que vous pouvez exécuter. Chacune inclut : une commande, ce que signifie la sortie, et quelle décision prendre ensuite. Exécutez‑les dans PowerShell élevé quand c’est possible.

Task 1: Check the network profile (Public vs Private)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-List Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name            : Corp-WiFi
InterfaceAlias  : Wi-Fi
NetworkCategory : Public
IPv4Connectivity: Internet

Sens : NetworkCategory : Public explique pourquoi la découverte et SMB peuvent être bloqués par défaut.

Décision : Si c’est votre LAN de confiance, passez en Privé. Si c’est vraiment non fiable, cessez d’espérer la découverte et utilisez VPN + DNS.

Task 2: Switch a network to Private (only if appropriate)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetConnectionProfile -InterfaceAlias 'Wi-Fi' -NetworkCategory Private; Get-NetConnectionProfile -InterfaceAlias 'Wi-Fi' | Select-Object InterfaceAlias,NetworkCategory"
InterfaceAlias NetworkCategory
-------------- ---------------
Wi-Fi          Private

Sens : L’interface est maintenant Privée, donc Windows permettra les règles de découverte (si activées) sur ce profil.

Décision : Retestez la découverte/SMB. Si ça marche maintenant, vous étiez en conflit avec la politique, pas avec le réseau.

Task 3: Confirm basic IP configuration

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias      : Ethernet
IPv4Address         : {192.168.10.21}
IPv4DefaultGateway  : {192.168.10.1}
DnsServer           : {192.168.10.10}

Sens : Vous avez une IP, une passerelle et un DNS. Bien. Si le DNS est l’IP d’un routeur random, la résolution de noms peut être faible.

Décision : Si le DNS pointe au mauvais endroit (ou est vide), corrigez le DHCP/DNS avant de faire des manips avancées.

Task 4: Test name resolution (DNS path)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FILES01 -ErrorAction SilentlyContinue | Select-Object Name,IPAddress"
Name   IPAddress
----   ---------
FILES01 192.168.10.50

Sens : DNS résout le nom de l’hôte. Idéal.

Décision : Si ça échoue, vous devez soit réparer DNS, soit retomber sur LLMNR/NetBIOS/mDNS (qui peuvent être désactivés). Réparez DNS (recommandé) ou acceptez des rustines pair‑à‑pair.

Task 5: Test reachability to SMB port 445 (by name and by IP)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection FILES01 -Port 445 | Select-Object ComputerName,RemoteAddress,TcpTestSucceeded"
ComputerName     RemoteAddress   TcpTestSucceeded
------------     -------------   ---------------
FILES01          192.168.10.50   True

Sens : TCP/445 est joignable. Le pare‑feu et le routage permettent probablement SMB.

Décision : Si False, stoppez. Corrigez les règles de pare‑feu sur la cible, l’isolation VLAN, ou les paramètres « réseau invité » du routeur. La découverte ne réparera pas un SMB bloqué.

Task 6: If name fails but IP works, prove it

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 192.168.10.50 -Port 445 | Select-Object RemoteAddress,TcpTestSucceeded"
RemoteAddress   TcpTestSucceeded
-------------   ---------------
192.168.10.50   True

Sens : Le service est joignable ; votre problème est la résolution de noms ou l’identité (SPN/identifiants), pas la connectivité.

Décision : Corrigez DNS ou utilisez une entrée hosts comme pansement temporaire. N’apprenez pas aux utilisateurs à taper des IP pour toujours.

Task 7: Check required discovery services

cr0x@server:~$ powershell -NoProfile -Command "Get-Service FDResPub,FDPHost,SSDPSRV,upnphost | Select-Object Name,Status,StartType"
Name     Status  StartType
----     ------  ---------
FDResPub Stopped Manual
FDPHost  Running Automatic
SSDPSRV  Stopped Manual
upnphost Stopped Manual

Sens : Si FDResPub est arrêté, votre machine peut ne pas se publier pour la découverte. Certains environnements n’ont pas besoin de SSDP/UPnP ; ne les activez pas aveuglément.

Décision : Sur un petit LAN où vous voulez la découverte, mettez FDResPub en Démarrage automatique (Delayed Start) et démarrez‑le. Dans un réseau d’entreprise verrouillé, vérifiez d’abord la politique.

Task 8: Start and set Function Discovery Resource Publication properly

cr0x@server:~$ powershell -NoProfile -Command "Set-Service FDResPub -StartupType Automatic; Start-Service FDResPub; Get-Service FDResPub | Select-Object Name,Status,StartType"
Name     Status  StartType
----     ------  ---------
FDResPub Running Automatic

Sens : Le service tourne et persistera après redémarrage.

Décision : Re‑vérifiez la vue Réseau après une minute. Si elle est toujours vide, le pare‑feu ou le profil est encore incorrect — ou le réseau bloque le multicast.

Task 9: Verify firewall rule groups are enabled for Private profile

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'Network Discovery' | Select-Object -First 5 DisplayName,Enabled,Profile | Format-Table -Auto"
DisplayName                                              Enabled Profile
-----------                                              ------- -------
Network Discovery (NB-Name-In)                            True    Private
Network Discovery (NB-Datagram-In)                        True    Private
Network Discovery (NB-Session-In)                         True    Private
Network Discovery (SSDP-In)                               True    Private
Network Discovery (UPnP-In)                               True    Private

Sens : Les règles de découverte sont activées pour Privé. Bien. Si elles sont désactivées, Windows ne peut pas « voir » les appareils utilisant ces méthodes.

Décision : Activez le groupe pour Privé si vous voulez la découverte ; laissez‑le désactivé pour Public.

Task 10: Enable the firewall rule groups (Network Discovery + File and Printer Sharing)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayGroup 'Network Discovery' -Enabled True; Set-NetFirewallRule -DisplayGroup 'File and Printer Sharing' -Enabled True; 'done'"
done

Sens : Cela active un grand ensemble de règles entrantes. C’est pourquoi on le fait seulement sur des profils Privé/Domaine de confiance.

Décision : Si l’activation « règle tout », vous avez identifié le goulot d’étranglement : la configuration du pare‑feu, souvent gérée par GPO en entreprise.

Task 11: Confirm SMB server is enabled on the target machine

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RejectUnencryptedAccess"
EnableSMB1Protocol EnableSMB2Protocol RejectUnencryptedAccess
------------------ ------------------ ------------------------
False              True               True

Sens : SMB2 est activé (bien). SMB1 est désactivé (également bien, généralement). Certains appareils très anciens nécessitent SMB1 ; traitez‑les comme un problème de containment, pas une demande de fonctionnalité.

Décision : N’activez pas SMB1 sauf si vous isolez cet appareil/réseau et comprenez le risque. Préférez la mise à jour de l’appareil ou un autre protocole.

Task 12: List shares and validate you’re not chasing a non-existent path

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Select-Object Name,Path,Description | Format-Table -Auto"
Name   Path                 Description
----   ----                 -----------
IPC$                        Remote IPC
Public C:\Shares\Public     Common drop

Sens : Le partage existe. Si les utilisateurs ne peuvent pas y accéder, c’est un problème de permissions ou d’authentification — pas de découverte.

Décision : Confirmez les permissions de partage et les ACL NTFS ; vérifiez que l’utilisateur s’authentifie avec l’identité attendue.

Task 13: Verify you can enumerate the target via SMB (client-side)

cr0x@server:~$ powershell -NoProfile -Command "net view \\FILES01"
Shared resources at \\FILES01

Share name  Type  Used as  Comment
----------  ----  -------  -------
Public      Disk           Common drop
The command completed successfully.

Sens : La négociation SMB, l’authentification et l’énumération des partages ont fonctionné par nom. Si la vue Réseau de l’Explorateur ne l’affiche toujours pas, ignorez l’Explorateur. Vous êtes opérationnel.

Décision : Apprenez aux utilisateurs à épingler/mont er via UNC ou à mapper des lecteurs via GPO/script. Ne comptez pas sur la navigation.

Task 14: Check credential/session state if access is weird

cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use'"
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
OK                     \\FILES01\Public          Microsoft Windows Network
The command completed successfully.

Sens : Il y a une session existante. Si de mauvaises informations d’identification ont été utilisées plus tôt, Windows les réutilisera et échouera de façon déroutante.

Décision : Supprimez la session et reconnectez‑vous avec la bonne identité si nécessaire.

Task 15: Clear SMB connections (use with care)

cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use \\FILES01\Public /delete'"
\\FILES01\Public was deleted successfully.

Sens : La connexion mise en cache est supprimée.

Décision : Réessayez l’accès. Si ça fonctionne maintenant, votre « problème de découverte réseau » était en fait un problème d’authentification/session.

Task 16: Check Windows features/services that often break discovery in “hardened” images

cr0x@server:~$ powershell -NoProfile -Command "Get-Service LanmanServer,LanmanWorkstation,Browser | Select-Object Name,Status,StartType"
Name            Status  StartType
----            ------  ---------
LanmanServer    Running Automatic
LanmanWorkstation Running Automatic
Browser         Stopped Disabled

Sens : Les services Server et Workstation tournent (nécessaires pour SMB). L’ancien service Computer Browser est désactivé (normal sur Windows moderne).

Décision : Ne tentez pas de ressusciter le service Browser comme solution. Résolvez la résolution de noms et la reachabilité SMB à la place.

Task 17: Confirm your machine is actually listening on SMB (target-side)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object -First 5 LocalAddress,LocalPort,State"
LocalAddress LocalPort State
------------ --------- -----
0.0.0.0      445       Listen
::           445       Listen

Sens : SMB écoute sur IPv4 et IPv6. Si rien n’écoute, le partage de fichiers ne fonctionnera pas quelle que soit la découverte.

Décision : Si rien n’écoute, vérifiez le service LanmanServer et la configuration du serveur ; assurez‑vous que le partage de fichiers est activé et non bloqué par un produit de sécurité endpoint.

Task 18: Check event logs for discovery publication failures

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 20 | Where-Object {$_.ProviderName -match 'FDResPub|FDPHost'} | Select-Object -First 3 TimeCreated,ProviderName,Id,Message | Format-List"
TimeCreated  : 2/5/2026 9:10:22 AM
ProviderName : FDResPub
Id           : 7023
Message      : The Function Discovery Resource Publication service terminated with the following error: Access is denied.

Sens : Le service échoue ; « Access is denied » pointe souvent vers des permissions, du durcissement, ou une interférence d’un produit de sécurité endpoint.

Décision : Arrêtez de basculer les paramètres. Corrigez la défaillance du service (baseline d’image, GPO, ou règle du produit de sécurité) ou acceptez que la découverte soit volontairement désactivée.

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire #1 : L’incident causé par une fausse hypothèse

Nous avions un petit site de bureau avec un serveur de fichiers, quelques machines Windows 10, et une exigence « simple » : tout le monde doit voir le serveur dans l’Explorateur sous Réseau. Un ticket est arrivé : « Le serveur a disparu. Il doit être en panne. » Les utilisateurs paniquaient. La direction demandait un ETA.

Le serveur allait bien. SMB par IP fonctionnait immédiatement. Même SMB par nom fonctionnait depuis PowerShell. Seule la vue Réseau était vide, et c’est ce à quoi les utilisateurs faisaient confiance.

La fausse hypothèse était que la vue Réseau est autoritaire. Ce n’est pas le cas. C’est une UI opportuniste. Une fois expliqué « connectez‑vous via le chemin UNC ; ne naviguez pas », l’urgence est retombée. Mais il fallait tout de même corriger le problème de perception.

La cause réelle était qu’une mise à jour de baseline de sécurité avait basculé le profil NIC en Public après la réinstallation d’un pilote Wi‑Fi. Ce changement a silencieusement désactivé les règles de découverte du pare‑feu. Le système n’était pas cassé ; il a juste cessé de s’annoncer.

Nous avons corrigé le profil via la politique, activé les règles de découverte uniquement sur Domaine/Privé, et publié un raccourci bureau vers \\FILES01\Public. La panne a pris fin dès que nous avons cessé de prendre le comportement de l’UI pour l’état du service.

Mini‑histoire #2 : L’« optimisation » qui s’est retournée contre eux

Un autre environnement a voulu « nettoyer le bruit réseau ». Quelqu’un a lu que LLMNR et NetBIOS sont peu sûrs (et c’est vrai), et a poussé une GPO de durcissement : désactiver LLMNR, désactiver NetBIOS sur TCP/IP, et restreindre agressivement les règles entrantes. L’intention était raisonnable : réduire la surface d’attaque.

Deux semaines plus tard, la file d’assistance a débordé de « je ne trouve pas l’ordinateur », « je ne peux pas mapper le lecteur », et « l’imprimante a disparu ». Le pire : le DNS n’était pas configuré de façon cohérente pour les postes des petits sites. Ils s’appuyaient inconsciemment sur la résolution par diffusion/multicast.

Donc l’« optimisation » a supprimé les mécanismes de secours sans fournir de remplacement. Le réseau n’est pas devenu plus sûr ; il est devenu chaotique. Les utilisateurs ont commencé à partager des adresses IP dans les chats comme des vignettes de collection.

La correction n’était pas « tout remettre ». La correction était de finir le travail : rendre DNS fiable (y compris mises à jour dynamiques si nécessaire), s’assurer que les clients utilisent les bons serveurs DNS via DHCP, et documenter la méthode de connexion supportée (noms d’hôtes, pas navigation). Ensuite on pouvait garder LLMNR désactivé sur la plupart des réseaux et avoir une expérience prévisible.

Les améliorations de sécurité qui cassent les opérations de base ne sont pas adoptées — elles sont contournées en silence. Construisez la piste avant de demander aux pilotes d’atterrir.

Mini‑histoire #3 : La pratique ennuyeuse et correcte qui a sauvé la mise

Le département finance avait un petit « fichiers sur un poste » (oui, ça existe encore) que nous migrions vers un vrai serveur. Nous savions que la découverte serait fragile parce que le bureau avait un Wi‑Fi segmenté, plusieurs VLAN, et un routeur qui traitait le multicast comme une insulte personnelle.

Donc nous n’avons pas visé la navigation. Nous avons fait trois choses ennuyeuses : des enregistrements DNS stables, un seul chemin UNC qui ne change jamais, et des lecteurs mappés déployés via politique. Nous avons aussi configuré explicitement les groupes de règles du Pare‑feu Windows pour les profils Domaine/Privé au lieu de « ce que la valeur par défaut donne ».

Des mois plus tard, quelqu’un a remplacé le routeur. La découverte est devenue étrange sur plusieurs sous‑réseaux. La vue Réseau de l’Explorateur est redevenue une maison hantée. Mais personne ne l’a remarqué, parce que la voie opérationnelle — mapping des lecteurs et accès UNC direct — a continué de fonctionner. Les tickets sont restés bas. La migration a semblé « magiquement fluide ».

Ce n’est pas de la magie. C’est choisir des systèmes déterministes plutôt que des impressions. La navigation, c’est des impressions.

Erreurs courantes : symptôme → cause racine → correctif

C’est là où la plupart du temps est gaspillé. Évitez‑ça.

1) Symptom: Network folder is empty, but internet works

Cause racine : Le profil réseau est Public, ou les règles de découverte sont désactivées pour le profil actif.

Fix : Passez le réseau en Privé (si de confiance). Activez le groupe de pare‑feu « Network Discovery » pour Privé. Confirmez que FDResPub tourne.

2) Symptom: You can access `\\IP\Share` but not `\\HOST\Share`

Cause racine : Échec de résolution de noms (DNS manquant/incorrect ; LLMNR/NetBIOS désactivé ; multicast bloqué).

Fix : Rendez DNS autoritatif (préféré). Pour une mise en situation temporaire, ajoutez une entrée hosts ou utilisez l’IP pendant que vous corrigez DHCP/DNS.

3) Symptom: Ping works, but SMB fails (port 445 closed)

Cause racine : Le pare‑feu de la cible bloque SMB entrant, ou le réseau est segmenté (isolation Wi‑Fi invité, ACLs VLAN).

Fix : Activez les règles File and Printer Sharing sur Privé/Domaine. Corrigez l’isolation réseau. Ne « réparez » pas la découverte quand SMB est bloqué.

4) Symptom: One PC can see others, but others can’t see it

Cause racine : Le PC « invisible » ne se publie pas (FDResPub arrêté/désactivé), ou son pare‑feu bloque le trafic de découverte entrant.

Fix : Démarrez/activez FDResPub. Activez les règles Network Discovery sur le PC publiant pour Privé/Domaine.

5) Symptom: It worked until a Windows update or image refresh

Cause racine : Services passés en Manuel/Désactivé, règles de pare‑feu revenant à l’état par défaut, profil NIC changé, ou baseline de sécurité appliquée.

Fix : Rendez l’état désiré imposable (GPO/Intune). Arrêtez de compter sur des modifications locales que les mises à jour peuvent annuler.

6) Symptom: Domain environment, but discovery is flaky across subnets

Cause racine : Les protocoles de découverte reposent souvent sur broadcast/multicast et ne traversent pas bien les routeurs.

Fix : Utilisez DNS + chemins UNC directs. Si vous avez besoin d’un comportement type annuaire, utilisez AD, espaces de noms DFS, ou un inventaire géré — pas la navigation.

7) Symptom: “You don’t have permission” or repeated credential prompts

Cause racine : Incohérence d’identifiants, sessions mises en cache, restrictions NTLM, ou mismatch des ACL de partage/NTFS.

Fix : Effacez les sessions net use existantes et reconnectez‑vous ; validez les permissions de partage et les ACL NTFS. Alignez la politique d’authentification sur la réalité.

8) Symptom: New Windows 11 PC can’t access an old NAS

Cause racine : Le NAS exige SMB1 ou une authentification faible ; Windows moderne le bloque par défaut.

Fix : Mettez à jour le firmware/config du NAS vers SMB2/3. Si vous devez activer SMB1, isolez cet appareil/réseau et acceptez explicitement le risque.

Blague #2 : Activer SMB1 en 2026 pour « réparer la découverte » revient à colmater un robinet fuyant en installant un tuyau d’incendie.

Listes de contrôle / plan pas à pas (assurer le fonctionnement)

Checklist A: Home or small office (workgroup) where you actually want browsing

Mettez les appareils sur le même LAN (pas de Wi‑Fi invité, pas de SSID isolé). Si votre routeur a « AP isolation » ou « client isolation », désactivez‑le pour le réseau de confiance.
Définissez le profil réseau sur Privé sur chaque PC Windows qui doit partager/découvrir.
Activez Network Discovery + File and Printer Sharing (groupes de règles de pare‑feu) pour le profil Privé.
Assurez‑vous que FDResPub et FDPHost tournent (Automatic convient pour un LAN domestique).
Confirmez que SMB fonctionne directement : accédez à \\HOST\Share et \\IP\Share.
Corrigez la résolution de noms :
- Idéal : votre routeur fournit des entrées DNS (certains le font), ou vous exécutez un petit serveur DNS.
- Acceptable : entrées hosts pour quelques machines.
- Évitez : compter sur « ce que Windows découvre aujourd’hui ».
Rendez l’accès convivial : créez des raccourcis ou mappez des lecteurs ; apprenez aux utilisateurs à s’en servir plutôt que de naviguer.

Checklist B: Corporate LAN (domain) where reliability matters more than icons

Décidez l’UX supportée : chemins UNC directs, lecteurs mappés, espaces de noms DFS, ou SharePoint/OneDrive. Choisissez‑en un et standardisez.
Rendez DNS correct et complet : les clients doivent utiliser le DNS corporate (via DHCP), et les serveurs doivent avoir des noms stables.
Appliquez une politique de pare‑feu Windows :
- Activez File and Printer Sharing entrant seulement sur le profil Domaine (et parfois Privé pour le Wi‑Fi géré).
- Laissez‑le désactivé sur Public, toujours.
Définissez explicitement les services requis via GPO/Intune. Ne dépendez pas des valeurs par défaut que les images et mises à jour modifient.
Ne dépendez pas de la découverte par broadcast/multicast entre sous‑réseaux. C’est fragile et souvent bloqué pour de bonnes raisons.
Surveillez la reachabilité SMB (port 445) et les échecs d’authentification. C’est la santé réelle du service, pas l’Explorateur.

Checklist C: When you need to prove where the failure is (names vs ports vs auth)

Par nom : Resolve-DnsName, puis Test-NetConnection -Port 445.
Par IP : Test-NetConnection IP -Port 445.
Par énumération SMB : net view \\HOST.
Par chemin direct : ouvrez \\HOST\Share.
Si l’auth échoue : vérifiez les sessions net use ; effacez et reconnectez ; validez les ACL.

FAQ

1) Why can I ping a PC but not see it in Network?

Ping utilise ICMP. La découverte mélange multicast/broadcast et publication de services. Windows peut bloquer la découverte tout en autorisant le ping (ou l’inverse). Traitez‑les comme des tests séparés.

2) If the Network folder is empty, does that mean file sharing is broken?

Non. Le dossier Réseau n’est pas une source de vérité. Testez SMB directement avec \\HOST\Share ou Test-NetConnection -Port 445.

3) What services are actually required for Windows discovery?

Les principaux : FDResPub et FDPHost. SSDP/UPnP peuvent intervenir pour certains scénarios, mais les activer partout n’est pas forcément la meilleure idée.

4) Should I enable SMB1 to fix this?

Presque jamais. SMB1 est un protocole hérité avec un long historique de problèmes de sécurité. Si un appareil l’exige, isolez‑le et planifiez son remplacement.

5) Why does `\\192.168.x.x\share` work but `\\hostname\share` fails?

Parce que la résolution de noms échoue. Réparez DNS (meilleur choix), ou utilisez temporairement le fichier hosts. Désactiver LLMNR/NetBIOS sans préparer DNS est une erreur classique.

6) Why do some PCs appear and disappear randomly?

La découverte repose sur des annonces périodiques et des protocoles qui ne résistent pas toujours au veille, au roaming Wi‑Fi, aux clients VPN, aux réinitialisations de pilotes ou au filtrage multicast. Utilisez des lecteurs mappés et un accès basé sur DNS pour la stabilité.

7) I’m on guest Wi‑Fi. Can I make discovery work anyway?

Généralement non, et c’est voulu. Les réseaux invités isolent souvent les clients entre eux. Si vous avez besoin d’accès, utilisez un SSID/VLAN de confiance ou un VPN vers un réseau où DNS et SMB sont supportés.

8) How do I know if Windows Firewall is the issue?

Vérifiez si le port 445 est joignable (Test-NetConnection -Port 445) et si les groupes de règles du pare‑feu pour Network Discovery et File and Printer Sharing sont activés pour le profil actif.

9) Why does it work on Ethernet but not Wi‑Fi?

Profils différents (Privé vs Public), posture de pare‑feu différente, ou isolation client/filtrage multicast sur le point d’accès Wi‑Fi. Aussi, certains produits de sécurité appliquent des règles plus strictes sur le Wi‑Fi.

10) What’s the “best practice” fix in a business environment?

Cessez de dépendre de la navigation. Utilisez DNS + chemins UNC directs, lecteurs mappés via politique, et configuration explicite des pare‑feu/services. Rendez‑le déterministe.

Étapes suivantes (pour maintenir le fonctionnement)

Si vous voulez que ça reste corrigé, faites l’opérationnel, pas l’espérance :

Standardisez les chemins d’accès (UNC, lecteurs mappés, ou DFS) pour que les utilisateurs ne dépendent pas de la vue Réseau.
Rendez DNS fiable. Si les noms d’hôtes comptent, le DNS doit être correct — point final.
Appliquez la politique (GPO/Intune) pour :
- Attentes sur les profils réseau (là où c’est possible)
- Groupes de règles de pare‑feu sur Domaine/Privé
- Démarrage des services FDResPub/FDPHost
Testez ce qui compte : la reachabilité du port 445 et l’accès réel aux partages. L’Explorateur, c’est un plus.
Soyez explicite sur la posture de sécurité : découverte et partage uniquement sur réseaux de confiance ; verrouillé partout ailleurs.

La victoire n’est pas de rendre le dossier Réseau joli. La victoire est de rendre l’accès aux fichiers prévisible — aujourd’hui, après la prochaine mise à jour Windows, et lors du prochain remplacement de routeur quand tout le monde jure « rien n’a changé ».