Tu arrives sur un poste qui n'a plus Internet. Tu tapes ipconfig par réflexe, et là, une adresse du genre 169.254.37.12 s'affiche. Pas de panique apparente, l'écran ne hurle aucune erreur. Et c'est justement ça qui piège la moitié des débutants : ils cherchent un message d'erreur qui n'existe pas, alors que la vraie info est déjà sous leurs yeux, planquée dans un chiffre. On va regarder ce que cette adresse raconte, et surtout, la question à se poser en premier pour ne pas perdre vingt minutes sur la mauvaise piste.
Pourquoi Windows invente une adresse au lieu de planter
Quand un PC démarre, il a besoin d'une adresse IP pour exister sur le réseau. Il ne la connaît pas d'avance, alors il la demande à voix haute : « quelqu'un peut m'en donner une ? ». Cette demande s'appelle DHCP, et normalement, un serveur quelque part lui répond en deux secondes avec une adresse propre, du genre 192.168.1.45.
Le détail qui change tout : Windows n'a pas été conçu pour planter bêtement si personne ne répond. À la place, il s'auto-attribue une adresse de secours dans une plage réservée à cet usage, qui commence toujours par 169.254. C'est un mécanisme volontaire, normalisé, pas un bug.
Tu arrives dans une ville pour une réservation d'hôtel. Personne ne répond à la réception, alors plutôt que de rester planté sur le trottoir, tu décides de dormir dans ta voiture, garée n'importe où. Tu es « quelque part », techniquement présent dans la ville. Mais tu n'es pas à l'hôtel, tu n'as pas la clé des bonnes portes, et personne ne sait que tu es là. C'est exactement ce que fait ton PC en 169.254 : il existe sur le réseau, mais il est seul, sans passerelle, sans DNS, sans accès à rien d'utile.
Ton cerveau te dit que si le PC a quand même une adresse, la carte réseau doit fonctionner et le souci vient forcément d'un réglage logiciel quelque part. C'est l'intuition naturelle. Et c'est faux : une carte réseau peut être en parfait état de marche et ne jamais recevoir de réponse DHCP, simplement parce que le câble est mort, le port du switch est désactivé, ou le serveur qui distribue les adresses est en panne ailleurs sur le réseau. L'adresse 169.254 ne te dit pas où est le problème. Elle te dit juste qu'une conversation n'a jamais eu de réponse.
169.254, ça se lit : « j'ai demandé, personne n'a répondu ». La question utile n'est pas « qu'est-ce qui cloche sur ce PC », mais « qui n'a pas répondu, et pourquoi ».
La question à poser avant de toucher quoi que ce soit
Voilà l'endroit où la plupart des débutants perdent du temps : ils foncent direct sur le poste en panne, ouvrent des fenêtres, relancent des trucs, sans s'être demandé une chose simple en premier. Cette question divise tout le dépannage en deux chemins complètement différents, et elle ne coûte rien à poser : est-ce qu'il y a un seul poste touché, ou plusieurs ?
Si c'est un seul poste, le problème est probablement local à cette machine ou à son raccordement : câble, port réseau, pilote, service Windows arrêté. Si plusieurs postes tombent en même temps, le problème dépasse la machine que tu as sous les yeux. Il est côté serveur ou côté infrastructure : le service qui distribue les adresses est en panne, ou il n'a tout simplement plus rien à distribuer.
C'est la différence entre une panne d'eau dans une seule pièce de l'appartement et une coupure dans tout l'immeuble. Si seul l'évier de la cuisine est à sec, tu regardes ton robinet, ta canalisation. Si tout l'immeuble n'a plus une goutte, inutile de démonter l'évier : va voir le compteur général, ou appelle le syndic. Le réflexe « combien de pièces sont touchées » t'évite de chercher au mauvais endroit.
L'intuition naturelle pousse à foncer sur ce qu'on voit : le PC devant soi, l'écran qui affiche le souci. Sauf que si tu passes vingt minutes à inspecter une machine parfaitement saine, pendant que c'est le serveur qui distribue les adresses qui est en rade pour quinze postes, tu as juste retardé le vrai diagnostic. Pose la question en premier. Toujours.
1 poste touché = tu regardes la machine et son raccordement. Plusieurs postes touchés en même temps = tu regardes le serveur ou l'infrastructure réseau. Cette question prend trois secondes et t'évite de creuser au mauvais endroit pendant un quart d'heure.
Les suspects habituels, du plus probable au plus rare
Une fois la question posée, tu sais où chercher. Sur le terrain en TPE/PME, voici les causes qui reviennent, classées de la plus fréquente à la plus exotique :
- Un câble débranché ou un port de switch mort. Le suspect numéro un, et le plus simple à éliminer : un coup d'œil et un changement de câble suffisent souvent.
- Le service qui gère le DHCP, arrêté sur le poste. Plus rare, mais ça arrive après une mise à jour ou une manipulation malheureuse.
- Le serveur qui distribue les adresses ne répond plus. Redémarrage en cours, service planté ailleurs sur le réseau.
- Le réservoir d'adresses disponibles est vide. Toutes les adresses du stock sont attribuées, ou retenues par des baux qui ne se sont jamais libérés.
- Le port réseau est configuré sur le mauvais segment. Fréquent après un déplacement de poste : le port du switch n'écoute pas le bon réseau, donc le bon serveur ne reçoit jamais la demande.
- Conflit d'adresse détecté par Windows. Rare, mais Windows peut refuser une adresse qu'il croit déjà prise par un autre poste.
- Une authentification réseau bloque le poste. Contexte plus avancé : le port refuse de laisser passer quoi que ce soit avant validation d'un certificat ou d'une identité.
Le contre-intuitif ici, c'est que la liste descend en fréquence pendant que la difficulté technique monte. Le cas le plus fréquent, c'est aussi le plus bête à régler.
Ce que tu fais en vrai, concrètement
- Sur un seul poste, commence toujours par la manipulation la moins chère : demander à Windows de relâcher puis redemander une adresse. Ça règle une bonne partie des cas où le service avait juste un coup de mou temporaire.
- Vérifie que le service réseau qui gère les adresses tourne côté poste. S'il est arrêté, relance-le avant de redemander une adresse.
- Toujours suspecter le câble et le port avant le logiciel. Change de câble, teste un autre port si possible. C'est gratuit en temps et ça élimine la cause numéro un.
- Si le poste vient d'être déplacé, pense immédiatement au port réseau mal configuré sur le mauvais segment — c'est l'oubli classique après un changement de bureau.
- Si plusieurs postes sont touchés au même moment, va directement vérifier le service qui distribue les adresses : est-il en marche, a-t-il encore des adresses à donner ?
- Vérifie toujours le résultat avec une commande qui affiche l'état complet de la carte, pas juste un coup d'œil rapide : une tentative de renouvellement peut échouer silencieusement et laisser l'ancienne adresse de secours affichée sans message d'erreur.
Demander une nouvelle adresse ne donne pas toujours un message d'erreur clair en cas d'échec. Le poste peut rester en 169.254 sans rien afficher de spécial. Vérifie systématiquement l'état complet après la tentative, pas seulement si la commande s'est « bien passée ».
Une fois l'adresse correcte récupérée, le test de validation est simple : l'adresse appartient à la bonne plage de l'entreprise, le poste arrive à joindre la passerelle, la résolution de noms fonctionne, et Internet répond. Si une seule de ces quatre choses manque encore, le diagnostic n'est pas terminé.
Tu sais maintenant lire un chiffre que la plupart des débutants regardent sans comprendre, et tu sais surtout dans quel ordre poser les questions avant d'agir. C'est exactement la différence entre suivre une procédure et vraiment savoir pourquoi elle marche. La prochaine fois qu'un ipconfig t'affiche ce fameux 169.254, tu ne seras plus seul devant l'écran à te demander par où commencer — tu sauras déjà.
Sources
Ce site est gratuit et le restera. Si un truc t'a aidé et que tu veux soutenir, tu peux m'offrir un café. Et si tu prends juste l'outil et que tu files, c'est très bien aussi.