PC introuvables sur le réseau après la fibre : et si le problème n’était pas Windows ?

Un changement de box ou l’installation de la fibre peut parfois provoquer des problèmes qui semblent, au premier abord, venir directement de Windows. C’est un peu le même genre de piège que celui décrit dans notre article sur un PC qui se bloque à cause d’un logiciel de sécurité mal configuré : le symptôme pointe vers un endroit, alors que la cause réelle se cache ailleurs.

C’est exactement ce qui s’est produit lors d’une intervention dans une petite entreprise : les ordinateurs étaient bien connectés au réseau, mais certains postes ne parvenaient plus à communiquer correctement entre eux. Un simple \\PC-A, qui permettait auparavant d’accéder à un ordinateur du réseau, ne fonctionnait plus.

Et comme souvent dans ce genre de situation, les recherches sur Internet ont rapidement proposé plusieurs solutions… dont certaines n’étaient pas forcément celles à appliquer.

Le problème : les ordinateurs sont connectés, mais ne se trouvent plus

Le premier constat était assez déroutant. Les ordinateurs disposaient bien d’une connexion réseau et Internet fonctionnait normalement. Pourtant, les communications entre les machines de l’entreprise étaient perturbées.

Le problème se manifestait notamment lors de l’utilisation des noms des ordinateurs : au lieu d’accéder au partage du poste PC-A, Windows ne trouvait tout simplement pas la machine.

Pour un utilisateur, cela peut facilement donner l’impression que le partage Windows est cassé, que le réseau local ne fonctionne plus, que le pare-feu bloque les connexions, ou qu’un composant Windows manque. Mais avant de modifier Windows, il faut déjà vérifier une chose essentielle : est-ce réellement Windows qui est en cause ?

Première piste : le profil réseau

Avant même de parler de résolution de noms, un premier détail est apparu en vérifiant la configuration réseau des postes : la carte réseau de l’un des ordinateurs était classée en profil « Public » au lieu de « Privé ».

Or, sur ce type de profil, Windows désactive par défaut la découverte réseau et le partage de fichiers, indépendamment de tout ce qui peut se passer du côté de la box. C’est un comportement de sécurité normal, pas un bug — mais dans un contexte de petit réseau d’entreprise où tous les postes doivent se voir, ça suffit à tout bloquer.

Un changement de box (et donc une nouvelle interface réseau détectée par Windows) peut très bien remettre ce profil à « Public » par défaut, sans que rien d’autre n’ait changé. Ce point a été corrigé rapidement. Mais la disparition de \\PC-A a persisté malgré tout, ce qui a orienté la suite du diagnostic vers autre chose.

Deuxième piste : IPv6

Le problème étant apparu après l’installation de la fibre, la configuration réseau a été examinée plus en détail. Une présence d’anciennes configurations IPv6 a notamment été constatée sur les postes concernés — en particulier des adresses IPv6 temporaires, qui changent régulièrement par conception (c’est une fonctionnalité de confidentialité de Windows, pas une anomalie en soi).

Des tests ont donc été réalisés en désactivant IPv6 pour privilégier IPv4 sur les postes concernés. Cette modification a permis de stabiliser une partie des comportements, mais elle ne suffisait pas non plus, à elle seule, à expliquer complètement pourquoi l’accès par nom ne fonctionnait pas de façon fiable. Il fallait donc continuer à chercher — et c’est là qu’un détail plus profond est apparu.

Le détail qui change tout : la box

La vérification de la configuration de la box a finalement apporté l’élément le plus intéressant de cette intervention. Les postes du réseau étaient bien connus de la box. Mais en comparant ce que Windows recevait comme réponse quand il cherchait PC-A, un point surprenant est ressorti : le nom se résolvait bien vers une adresse… mais une adresse IPv6 qui ne menait nulle part, une sorte d’adresse fantôme ne correspondant à aucun équipement joignable.

Autrement dit, la box répondait correctement « oui, je connais PC-A », mais l’associait à une adresse injoignable, pendant que la bonne adresse IPv4 restait, elle, parfaitement valide et accessible en direct.

Cela peut sembler anodin. Ça ne l’est pas forcément. Lorsqu’un utilisateur demande à Windows d’ouvrir \\PC-A, il ne demande pas directement à une adresse IP de se connecter. Il demande au système : « Trouve-moi l’ordinateur qui s’appelle PC-A. » Et par défaut, Windows privilégie une réponse en IPv6 si elle existe — même périmée — plutôt que de retomber directement sur l’IPv4 qui, elle, fonctionnait très bien.

Une adresse IP peut fonctionner alors que le nom ne fonctionne pas

C’est d’ailleurs un test particulièrement intéressant dans ce type de dépannage. Si \\192.168.1.X fonctionne, mais que \\PC-A ne fonctionne pas, cela donne une indication importante : le réseau entre les deux machines peut être parfaitement fonctionnel, et le problème se situer uniquement au niveau de la résolution du nom de la machine — sans qu’aucun câble, aucune carte réseau, ni aucun pare-feu ne soit en cause.

Dans le cas rencontré, la désactivation d’IPv6 sur les postes concernés a permis d’éliminer cette source d’erreur : sans IPv6 activé, Windows n’avait plus aucune raison d’aller chercher cette adresse fantôme, et retombait directement sur la bonne IPv4.

Un deuxième piège, plus discret

Un peu plus tard dans l’intervention, un autre symptôme du même genre est réapparu : après le remplacement d’un poste, celui-ci a reçu une nouvelle adresse IP attribuée par la box. Mais en tentant d’y accéder par son nom depuis un autre poste, la connexion pointait toujours vers… l’ancienne adresse IP, qui ne correspondait plus à rien.

Un simple vidage du cache DNS local n’y changeait rien : l’information périmée ne venait pas du poste qui cherchait à se connecter, mais bien de la box elle-même, qui n’avait pas encore mis à jour son enregistrement suite au changement d’adresse. Un renouvellement forcé du bail réseau (libération puis nouvelle demande d’adresse) a permis à la box de mettre à jour l’information, et la résolution du nom est redevenue correcte.

Deux symptômes très similaires en apparence — « le nom ne mène pas à la bonne machine » — mais deux causes distinctes : l’une liée à un enregistrement IPv6 qui n’aurait jamais dû être pris en compte, l’autre à un simple délai de mise à jour côté box après un changement d’adresse.

Et les solutions trouvées sur Internet ?

C’est probablement la partie la plus intéressante de cette intervention. En recherchant des solutions au problème de découverte et de communication entre ordinateurs Windows, on trouve rapidement des tutoriels recommandant l’installation ou l’activation de certains composants permettant de retrouver les anciennes méthodes de découverte réseau — voire, pour les plus zélés, de lancer coup sur coup des commandes comme DISM et SFC en espérant que ça règle le problème par magie.

Le problème ? Certaines de ces fonctionnalités existent justement parce que Windows doit pouvoir assurer une certaine compatibilité avec des environnements anciens. Et certaines sont désactivées par défaut pour des raisons de sécurité.

Il peut donc être tentant de lire « Activez cette fonctionnalité et vos ordinateurs seront de nouveau visibles » et de considérer que le problème est réglé. Mais ce n’est pas forcément une bonne approche.

Faire fonctionner n’est pas toujours réparer

C’est une distinction importante en dépannage informatique. Une manipulation peut faire disparaître le symptôme sans corriger la cause. Pire encore, elle peut réintroduire un protocole ou un service ancien uniquement parce qu’un tutoriel trouvé sur Internet le recommande.

La suite de cette intervention en a d’ailleurs donné un très bon exemple.

Troisième piège : quand le partage est ouvert, mais l’accès refusé quand même

Une fois le profil réseau corrigé et la résolution de nom rétablie, un dernier symptôme est apparu : un poste continuait de se voir refuser l’accès aux dossiers partagés d’un autre, avec un message évoquant un mot de passe invalide — alors qu’aucun mot de passe n’avait pourtant été demandé auparavant.

En vérifiant la configuration du partage concerné, tout semblait pourtant grand ouvert : les autorisations étaient réglées sur « Tout le monde » avec contrôle total, à la fois au niveau du partage et des fichiers.

La cause était ailleurs : le compte Invité de Windows était désactivé sur la machine hébergeant le partage. Or, sans ce compte actif, Windows ne peut tout simplement pas établir de session non authentifiée — peu importe à quel point les autorisations de partage sont permissives. Un partage grand ouvert « sur le papier » ne garantit donc pas un accès réellement fonctionnel si le mécanisme d’authentification qui doit le porter est lui-même coupé.

Réactiver ce compte a immédiatement débloqué la situation — mais ce choix n’est pas neutre : cela revient à autoriser un accès non authentifié aux dossiers partagés depuis n’importe quel appareil du réseau local. Sur un poste hébergeant des données sensibles, ce compromis sécurité/simplicité doit être posé consciemment, et non appliqué par réflexe.

C’est un excellent exemple de situation où plusieurs couches indépendantes peuvent chacune bloquer la communication entre deux machines : le réseau, la résolution de nom, et enfin l’authentification. Corriger une seule de ces couches ne suffit pas si les autres posent encore problème.

Le piège du « pack magique »

Lorsqu’un problème Windows est difficile à comprendre, Internet propose souvent une succession de commandes, de logiciels, de fonctionnalités à activer et de paramètres à modifier. Il faut garder un réflexe : ne pas installer ou activer quelque chose uniquement parce que cela apparaît dans les premiers résultats de recherche.

Un tutoriel peut être ancien, prévu pour une autre version de Windows, adapté à une architecture réseau différente, destiné à un problème qui ressemble au vôtre mais dont la cause est différente, ou proposer une solution qui fonctionne, mais au prix d’une sécurité moindre.

Un bon dépannage commence donc par identifier la cause, et non par appliquer toutes les solutions disponibles.

Ce que cette intervention nous rappelle

Dans ce cas précis, plusieurs éléments pouvaient donner l’impression que Windows était responsable du problème. Pourtant, la vérification pas à pas a permis d’isoler trois causes bien distinctes, chacune à sa propre couche : un profil réseau mal classé, un enregistrement réseau périmé du côté de la box, et un compte système désactivé bloquant l’authentification.

Le cas du poste PC-A était particulièrement parlant : l’accès à \\PC-A ne fonctionnait pas correctement alors que le réseau, lui, était parfaitement opérationnel — la preuve en étant qu’un accès par adresse IP directe fonctionnait sans le moindre souci. Aucune de ces trois causes n’a nécessité l’installation précipitée d’un composant Windows ancien trouvé dans un tutoriel générique.

Avant de modifier Windows, voici l’ordre de vérification qui a permis de résoudre ce cas :

1. La connexion physique et Wi-Fi.
2. L’adresse IP de chaque poste.
3. Le profil réseau (Privé/Public) de chaque carte.
4. Le serveur DHCP.
5. Les équipements connus par le routeur ou la box.
6. Les noms associés aux machines et leur résolution.
7. L’accès par adresse IP (pour isoler un souci de nom d’un souci réseau).
8. Les partages Windows et leurs autorisations.
9. Les comptes système impliqués dans l’authentification (Invité, comptes locaux).
10. Le pare-feu.
11. Et seulement ensuite les composants ou protocoles supplémentaires.

En résumé

Après l’installation de la fibre, les ordinateurs de cette entreprise ne communiquaient plus correctement par leur nom sur le réseau local. Les investigations ont fait apparaître trois causes indépendantes :

• un profil réseau repassé en « Public »,
• un enregistrement réseau périmé côté box pointant vers une adresse injoignable,
• et un compte Invité désactivé bloquant l’accès malgré des partages grands ouverts.

La correction de la résolution de nom, du profil réseau et de l’authentification a permis de rétablir une communication cohérente entre les machines. Et surtout, aucune activation précipitée de composants Windows anciens n’a été nécessaire.

Avant d’installer un « correctif » trouvé sur Internet, cherchez pourquoi le problème existe réellement. En informatique, réparer consiste rarement à empiler des solutions jusqu’à ce que ça fonctionne. Le bon dépannage consiste plutôt à remonter la chaîne : machine → réseau → DHCP → résolution de nom → authentification → service → application. Et parfois, la solution se trouve simplement… dans la box située à côté de la fibre.

FAQ : réseau local, résolution de noms et partages Windows

Pourquoi \\NomDuPC ne fonctionne plus alors que le PC répond au ping par IP ?

Parce que l’accès par nom et l’accès par IP passent par deux mécanismes différents. Le ping ou l’accès par IP teste uniquement la connectivité réseau, tandis que \\NomDuPC nécessite en plus que le nom soit correctement résolu vers la bonne adresse — une étape distincte qui peut échouer même quand le réseau fonctionne parfaitement.

Faut-il désactiver IPv6 pour régler ce genre de problème ?

Ce n’est pas une règle générale, mais une option de dépannage utile quand un enregistrement IPv6 périmé ou incorrect perturbe la résolution de noms sur un petit réseau local. Sur un réseau plus large ou une configuration IPv6 correctement gérée, ce n’est pas nécessaire.

Un partage réglé sur « Tout le monde » garantit-il un accès sans mot de passe ?

Non. Les autorisations de partage définissent qui peut accéder si une session est établie, mais Windows a aussi besoin d’un mécanisme d’authentification fonctionnel (compte Invité actif, ou identifiants valides) pour établir cette session. Un partage ouvert avec un compte Invité désactivé se traduira par un accès refusé, malgré des autorisations en apparence permissives.

---

Des ordinateurs qui ne se voient plus après un changement de box ou l’installation de la fibre ? sephy lab peut diagnostiquer précisément la cause — profil réseau, résolution de nom ou authentification — et rétablir la communication entre vos postes sans réinstaller ni désactiver quoi que ce soit inutilement.

📡 Soutenir le labo

Sephy-Lab est un projet libre et gratuit. Si tu veux soutenir les expériences et maintenir le système en ligne, tu peux m’aider ici.

Payez-moi un café !