Vous êtes sur le Wi‑Fi. Le signal a l’air correct. Windows vous dit poliment « Pas d’Internet, sécurisé » comme s’il vous rendait service. Pendant ce temps, votre navigateur tourne en rond, votre client VPN boude, Teams affiche « en cours de connexion », et votre café refroidit en temps réel.
Ce n’est généralement pas un problème « l’internet est en panne ». C’est un problème « votre machine a des opinions sur l’adaptateur à utiliser, et elles sont fausses ». La solution est souvent simple : réinitialiser le bon adaptateur réseau et la pile qui l’accompagne. La difficulté est de savoir quel adaptateur est réellement en jeu et quel dommage collatéral vous allez déclencher.
Ce que signifie réellement « Pas d’Internet, sécurisé »
Windows ne se contente pas de regarder l’icône de cadenas du Wi‑Fi. Il exécute des vérifications de connectivité et évalue s’il peut atteindre l’internet étendu. Lorsqu’il affiche « Pas d’Internet, sécurisé », cela veut généralement dire :
- Vous êtes associé à un point d’accès (handshake de sécurité Wi‑Fi réussi).
- Vous avez une certaine configuration IP (peut‑être valide, peut‑être aberrante).
- La sonde de connectivité de Windows a échoué, ou votre route par défaut/chemin DNS est cassé.
C’est pourquoi vous pouvez parfois accéder à des ressources internes (imprimante, NAS, intranet d’entreprise) alors que Windows affirme qu’il n’y a pas d’internet. La partie « sécurisé » concerne le chiffrement Wi‑Fi, pas la sécurité de votre navigation, votre proxy d’entreprise ou votre caractère moral.
Du point de vue SRE, la machine vous dit : « la couche 2 semble correcte, mais les couches 3/4/7 sont suspectes. » La solution n’est pas de cliquer frénétiquement sur l’icône Wi‑Fi comme si cela pouvait invoquer de meilleures tables de routage par la force du mental.
Règles rapides de diagnostic (premier/deuxième/troisième)
Si vous ne faites rien d’autre, faites ceci. C’est le chemin le plus court vers le goulot d’étranglement.
Premier : identifier le chemin actif (adaptateur, IP, passerelle)
- Trouvez l’adaptateur qui possède la passerelle par défaut.
- Confirmez que l’adresse IP est dans le sous‑réseau attendu pour ce réseau.
- Vérifiez si vous ne routez pas accidentellement via un VPN/adaptateur virtuel.
Décision : si la route par défaut pointe vers le mauvais adaptateur, réinitialisez/désactivez d’abord le mauvais. Ne « réinitialisez tout » qu’après avoir compris pourquoi Windows l’a choisi.
Deuxième : tester DNS vs routage (séparer le problème)
- Pinger la passerelle (routage local).
- Résoudre un nom (DNS).
- Se connecter directement à une IP (contourner le DNS).
Décision : si la connectivité IP fonctionne mais que la résolution de noms échoue, vous réglez le DNS/proxy, pas le Wi‑Fi.
Troisième : vérifier l’état de la pile réseau Windows (Winsock, pare‑feu, pilotes)
- Vérifiez si un VPN, un agent de sécurité ou un pilote de filtre intercepte le trafic.
- Réinitialisez Winsock/TCP/IP seulement après avoir confirmé un problème de pile.
- Mettez à jour ou restaurez le pilote Wi‑Fi si les symptômes se corrèlent avec veille/reprise ou des mises à jour récentes.
Décision : évitez les réinitialisations nucléaires durant la journée de travail si vous dépendez de profils VPN spécialisés ou de certificats d’entreprise qui pourraient devoir être réenregistrés.
Faits intéressants & courte histoire (pour mieux dépanner)
Ce ne sont pas des anecdotes pour l’anecdote. Elles expliquent pourquoi le problème existe et pourquoi certaines « solutions » fonctionnent.
- Windows ne « devine » pas l’accès internet ; il le sonde. Les versions modernes de Windows utilisent un mécanisme d’état de connectivité (souvent appelé NCSI) qui vérifie s’il peut atteindre des points de terminaison connus et si le DNS se comporte comme prévu.
- Les portails captifs perturbent volontairement les sondes. Les réseaux d’hôtels et invités détournent souvent le DNS ou HTTP pour forcer une page de connexion ; Windows interprète cela comme « pas un vrai internet » tant que l’authentification n’est pas faite.
- Le « metric » décide quel adaptateur gagne. Si vous avez plusieurs routes (Wi‑Fi, Ethernet, VPN, vSwitch Hyper‑V), Windows choisit la métrique la plus basse pour la route par défaut. Ce n’est pas toujours l’adaptateur que vous pensez utiliser.
- Winsock est la cicatrice du réseau Windows. Beaucoup de produits de sécurité et de clients VPN installent des Layered Service Providers ou des composants de filtrage ; quand ils dysfonctionnent, vous obtenez des bizarreries qui ressemblent à un « Wi‑Fi cassé ».
- IPv6 peut être une fausse piste. Certains réseaux annoncent IPv6 mais ne fournissent pas de connectivité montante fonctionnelle. Windows peut préférer IPv6, échouer, puis ne pas retomber correctement sur IPv4 selon la configuration et les délais.
- Les adaptateurs virtuels se multiplient comme des lapins. Hyper‑V, WSL, Docker Desktop et les VPN créent des adaptateurs. Chacun est une opportunité pour Windows de diriger le trafic vers un endroit non désiré.
- Les échecs DHCP peuvent sembler « sécurisé ». Si DHCP échoue, Windows peut s’autodonner une adresse APIPA (169.254.x.x). Vous serez toujours « connecté » au Wi‑Fi, mais en pratique sur une île.
- La gestion d’alimentation des pilotes est un récidiviste. Les bugs après veille/reprise et l’option « Autoriser l’ordinateur à éteindre ce périphérique pour économiser de l’énergie » ont causé plus de pannes du lundi matin que n’importe quel firmware de routeur que j’ai rencontré.
Choisir le bon adaptateur (avant toute réinitialisation)
« Réinitialiser votre adaptateur réseau » est un bon conseil comme « redémarrer le serveur » : ça marche, mais c’est irresponsable si vous ne savez pas ce que vous redémarrez.
Sur un portable Windows moderne vous avez probablement :
- Un adaptateur Wi‑Fi physique (Intel/Realtek/Qualcomm).
- Éventuellement un adaptateur Ethernet physique (ou un dongle USB).
- Un ou plusieurs adaptateurs VPN (WireGuard, AnyConnect, GlobalProtect, etc.).
- Des switches virtuels (Hyper‑V, VMware, VirtualBox).
- Adaptateurs loopback et tunnel (Teredo, ISATAP — moins courants aujourd’hui, mais encore vus).
Votre objectif est de trouver l’adaptateur que Windows utilise pour la route par défaut vers l’internet. Ensuite vous réinitialisez celui‑ci — ou vous corrigez la raison pour laquelle Windows a choisi le mauvais.
Petite blague #1 : Les adaptateurs réseau sont comme des cadres intermédiaires : vous ne les remarquez que quand ils « aident ».
Tâches pratiques : commandes, sorties, décisions (12+)
Ces tâches supposent que vous pouvez ouvrir un PowerShell ou un Invite de commandes en mode administrateur sur Windows. Les commandes sont réelles. Les exemples de « sortie » sont représentatifs — les vôtres seront différents. Chaque tâche se termine par la décision à prendre.
Task 1: See what Windows thinks is connected
cr0x@server:~$ netsh interface show interface
Admin State State Type Interface Name
------------------------------------------------------------------------
Enabled Connected Dedicated Wi-Fi
Enabled Disconnected Dedicated Ethernet
Enabled Connected Dedicated VPN - Corp
Enabled Connected Dedicated vEthernet (Default Switch)
Ce que cela signifie : Plusieurs interfaces « Connected » est normal. C’est aussi comme ça qu’on se retrouve routé dans un trou noir.
Décision : Si un VPN ou un vSwitch virtuel est connecté alors qu’il ne devrait pas l’être, vous avez probablement un problème de routage/métrique. Ne réinitialisez pas d’abord le Wi‑Fi ; identifiez quel adaptateur possède la route par défaut.
Task 2: Show IP configuration and find the default gateway
cr0x@server:~$ ipconfig /all
Wireless LAN adapter Wi-Fi:
Connection-specific DNS Suffix . : corp.example
Description . . . . . . . . . . : Intel(R) Wi-Fi 6 AX201
Physical Address. . . . . . . . . : 3C-52-82-11-22-33
DHCP Enabled. . . . . . . . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.1.57(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1
Ethernet adapter VPN - Corp:
IPv4 Address. . . . . . . . . . . : 10.44.12.8(Preferred)
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 10.44.0.53
Ce que cela signifie : L’adaptateur avec une passerelle par défaut est généralement celui qui offre la sortie. Les adaptateurs VPN n’affichent souvent pas de passerelle, mais peuvent malgré tout installer des routes.
Décision : Si le Wi‑Fi n’a pas de passerelle ou en a une étrange (0.0.0.0 ou vide), corrigez le DHCP ou la configuration statique. Si le Wi‑Fi a une passerelle mais pas d’internet, poursuivez l’investigation sur le routage, le DNS ou le filtrage.
Task 3: Inspect the route table and locate the default route
cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.57 35
10.0.0.0 255.0.0.0 On-link 10.44.12.8 5
192.168.1.0 255.255.255.0 On-link 192.168.1.57 291
===========================================================================
Ce que cela signifie : La route par défaut est 0.0.0.0/0. Ici elle pointe vers la passerelle Wi‑Fi 192.168.1.1, bien. Mais notez la route VPN pour 10.0.0.0/8 avec une métrique plus basse ; c’est normal pour le split‑tunnel.
Décision : Si 0.0.0.0/0 pointe vers un VPN/adaptateur virtuel de façon inattendue, désactivez cet adaptateur ou corrigez sa métrique. Réinitialiser le Wi‑Fi ne servira à rien si le trafic ne sort jamais via le Wi‑Fi.
Task 4: Check interface metrics (the “why did Windows choose that?” answer)
cr0x@server:~$ netsh interface ipv4 show interfaces
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
6 35 1500 connected Wi-Fi
17 5 1400 connected VPN - Corp
22 25 1500 connected vEthernet (Default Switch)
Ce que cela signifie : La métrique la plus basse gagne. Si un VPN affiche une métrique 5 et installe une route par défaut, il dominera.
Décision : Si Windows continue de préférer le mauvais chemin, fixez une métrique raisonnable ou désactivez « métrique automatique » sur l’interface fautive.
Task 5: Prove local connectivity: ping the gateway
cr0x@server:~$ ping 192.168.1.1
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Ce que cela signifie : Vous atteignez le routeur/AP passerelle au niveau Layer 3. Le lien Wi‑Fi n’est pas le problème principal.
Décision : Si le ping de la passerelle échoue, corrigez l’association Wi‑Fi, les problèmes RF, le pilote ou les règles de pare‑feu locales. S’il réussit, montez dans la pile.
Task 6: Prove internet routing without DNS: ping a public IP
cr0x@server:~$ ping 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Request timed out.
Request timed out.
Ce que cela signifie : Soit le routage en amont est cassé, soit l’ICMP est bloqué, soit votre table de routage ment. Ne supposez pas encore « ICMP bloqué » ; testez TCP ensuite.
Décision : Si le ping IP échoue, testez une connexion TCP (Tâche 8). Si TCP échoue aussi, vous avez un vrai problème d’egress/routage/filtrage.
Task 7: Prove DNS: resolve a name
cr0x@server:~$ nslookup example.com
Server: router.lan
Address: 192.168.1.1
Non-authoritative answer:
Name: example.com
Addresses: 93.184.216.34
Ce que cela signifie : La résolution DNS fonctionne via le serveur configuré.
Décision : Si le DNS échoue mais que la connectivité IP fonctionne, changez le serveur DNS, videz le cache DNS ou corrigez le VPN/proxy qui détourne le DNS.
Task 8: Test actual TCP connectivity (more trustworthy than ping)
cr0x@server:~$ powershell -Command "Test-NetConnection 1.1.1.1 -Port 443"
ComputerName : 1.1.1.1
RemoteAddress : 1.1.1.1
RemotePort : 443
InterfaceAlias : Wi-Fi
TcpTestSucceeded : True
Ce que cela signifie : Vous avez un vrai egress internet sur le port 443, même si le ping échoue. C’est courant sur des réseaux restrictifs.
Décision : Si le TCP fonctionne mais que Windows affiche toujours « Pas d’Internet, sécurisé », suspectez la détection de portail captif, les paramètres proxy ou le blocage du NCSI.
Task 9: Check proxy settings (classic corporate foot-gun)
cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:
Proxy Server(s) : 127.0.0.1:8080
Bypass List : (none)
Ce que cela signifie : Le trafic système WinHTTP est forcé via un proxy local sur le port 8080. Si ce proxy ne tourne pas (ou est bloqué), beaucoup d’apps échouent même si le navigateur peut marcher.
Décision : Si vous n’utilisez pas intentionnellement un proxy local, réinitialisez‑le en accès direct (Tâche 10).
Task 10: Reset WinHTTP proxy to direct
cr0x@server:~$ netsh winhttp reset proxy
Current WinHTTP proxy settings:
Direct access (no proxy server).
Ce que cela signifie : Les composants système arrêteront d’essayer de passer par le proxy.
Décision : Si la connectivité revient, vous avez trouvé le coupable : une configuration proxy résiduelle provenant d’un outil VPN/de sécurité ou d’un dépannage manuel mal nettoyé.
Task 11: Release/renew DHCP lease (fixes bad leases and stale options)
cr0x@server:~$ ipconfig /release
Windows IP Configuration
No operation can be performed on Ethernet while it has its media disconnected.
cr0x@server:~$ ipconfig /renew
Windows IP Configuration
An error occurred while renewing interface Wi-Fi : unable to contact your DHCP server. Request has timed out.
Ce que cela signifie : Le Wi‑Fi est connecté au niveau Layer 2, mais le trafic DHCP n’obtient pas de réponse. Cela peut venir d’un problème d’AP, de mauvaise configuration de VLAN, d’isolation sans fil ou d’un bug de pilote.
Décision : Si le renouvellement DHCP expire, essayez d’activer/désactiver l’adaptateur, d’oublier le réseau ou de vérifier si l’AP relie bien les clients au serveur DHCP.
Task 12: Flush DNS cache (quick, safe, often useless—but sometimes magic)
cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
Ce que cela signifie : Vous avez vidé le cache DNS.
Décision : Si seulement certains sites échouent après des changements réseau/déconnexion VPN, le vidage peut aider. Si rien ne fonctionne, n’en faites pas un rituel.
Task 13: Reset Winsock (fix broken LSP/filter chain symptoms)
cr0x@server:~$ netsh winsock reset
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.
Ce que cela signifie : Le catalogue Winsock a été réinitialisé. Cela peut supprimer/réparer les hooks installés par des VPN et des outils de sécurité.
Décision : Utilisez‑le quand vous suspectez une bizarrerie au niveau des sockets (les apps ne peuvent pas se connecter alors que le routage semble correct). Prévoyez un redémarrage.
Task 14: Reset TCP/IP stack (bigger hammer, still legitimate)
cr0x@server:~$ netsh int ip reset
Resetting Global, OK!
Resetting Interface, OK!
Restart the computer to complete this action.
Ce que cela signifie : Les paramètres TCP/IP ont été remis aux valeurs par défaut.
Décision : Faites‑le quand vous suspectez une corruption de route/pile et que les étapes précédentes n’ont rien donné. Attendez‑vous à ce que les réglages statiques personnalisés soient effacés.
Task 15: Disable and re-enable the specific adapter (surgical reset)
cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=disabled
cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=enabled
Ce que cela signifie : Vous avez redémarré l’interface Wi‑Fi, forçant la réassociation et le renouvellement DHCP.
Décision : Préférez cela plutôt que « Réinitialisation réseau » dans Paramètres quand vous voulez un rayon d’impact minimal.
Task 16: Show wireless state and confirm SSID/BSSID (catch sticky roaming issues)
cr0x@server:~$ netsh wlan show interfaces
Name : Wi-Fi
State : connected
SSID : CorpGuest
BSSID : aa:bb:cc:dd:ee:ff
Radio type : 802.11ax
Authentication : WPA2-Personal
Channel : 36
Receive rate (Mbps) : 1201
Transmit rate (Mbps) : 1201
Signal : 85%
Ce que cela signifie : Vous êtes connecté à un AP spécifique (BSSID). Si vous êtes sur le mauvais SSID (guest vs corporate), tout en aval peut « fonctionner » mais être inutile.
Décision : Si le SSID est incorrect, oubliez le réseau et reconnectez‑vous au bon. Si le BSSID est un AP éloigné et que le signal est médiocre, forcez la reconnexion ou provoquez le roaming.
Task 17: Check whether you got an APIPA address (DHCP failure detector)
cr0x@server:~$ ipconfig
Wireless LAN adapter Wi-Fi:
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 169.254.88.12
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
Ce que cela signifie : APIPA. Windows a abandonné le DHCP et s’est auto‑assigné. Vous n’aurez pas d’internet normal depuis ceci.
Décision : Arrêtez de bidouiller le DNS. Réparez l’accès DHCP : rebouclez l’adaptateur, essayez un autre SSID, redémarrez l’AP ou vérifiez le NAC/captive portal de l’entreprise.
Task 18: Confirm firewall isn’t blocking outbound in a weird profile state
cr0x@server:~$ netsh advfirewall show allprofiles state
Domain Profile Settings:
State ON
Private Profile Settings:
State ON
Public Profile Settings:
State ON
Ce que cela signifie : Le pare‑feu est activé pour tous les profils (normal). La vraie question : votre réseau est‑il passé en profil « Public » et une politique d’entreprise bloque maintenant le trafic ?
Décision : Si votre organisation applique des règles strictes sur le profil Public, assurez‑vous que le réseau est classé correctement (ou utilisez un VPN qui tolère le profil Public). Ne désactivez pas simplement le pare‑feu ; c’est comme ça qu’on finit dans un rapport d’incident.
Stratégie de réinitialisation : du moins destructeur au plus
Réinitialiser le « bon » adaptateur consiste à minimiser les dégâts. Les systèmes de production m’ont appris la valeur des petits changements avec retours rapides. Votre portable mérite la même attention.
Level 0: confirm you’re not chasing a real outage
- Vérifiez un autre appareil sur le même Wi‑Fi (le téléphone marche ? un collègue marche ?).
- Si personne n’a d’internet, cessez d’accuser votre NIC et commencez à accuser l’amont.
Level 1: bounce only the active interface
Désactivez/réactivez le Wi‑Fi (Tâche 15). Reconnectez‑vous au SSID. Cela force la réassociation et la renégociation sans effacer les paramètres.
Level 2: kill the wrong contenders
Si vous avez des adaptateurs VPN/virtuels connectés, désactivez‑les temporairement. Vous ne « réparez pas l’internet ». Vous retirez des routes alternatives confuses.
Fauteurs de troubles courants :
- VPN laissé connecté mais non fonctionnel (split tunnel mal configuré).
- vSwitch Hyper‑V prenant une route par défaut via le partage de connexion Internet.
- Ancien adaptateur TAP/TUN d’un client VPN supprimé.
Level 3: refresh addressing and naming
- Release/renew DHCP (Tâche 11).
- Vider le cache DNS (Tâche 12).
- Réinitialiser le proxy WinHTTP (Tâche 10) si l’environnement le permet.
Level 4: reset the stack (requires reboot, sometimes fixes “ghost” problems)
- Réinitialisation Winsock (Tâche 13).
- Réinitialisation TCP/IP (Tâche 14).
Level 5: driver and power settings (the “it broke after sleep” lane)
Si ce problème coïncide avec une mise à jour Windows, un nouveau pilote ou une veille/reprise, ne le traitez pas comme un problème DNS. Ce n’est probablement pas ça. Mettez à jour le pilote Wi‑Fi depuis l’OEM, ou restaurez‑le si la version la plus récente est problématique.
Petite blague #2 : « Vous avez essayé de l’éteindre et de le rallumer ? » n’est que « réinitialiser la machine d’état » avec un meilleur marketing.
Erreurs courantes : symptôme → cause racine → correctif
Voici les répétitions que j’ai vues à travers les parcs : portables, endpoints VDI et PC de salle de réunion « temporaires » qui sont restés temporaires depuis 2017.
1) Symptom: « Connected, no internet » but VPN is « connected » too
Cause racine : L’adaptateur VPN a une métrique plus basse et installe une route par défaut ; le tunnel est cassé, donc le trafic tombe dans un trou noir.
Correctif : Déconnecter le VPN ; désactiver son adaptateur ; ou corriger les métriques/routes pour que seuls les préfixes souhaités passent par le VPN.
2) Symptom: Browser works, but system apps (Store, Outlook, some updaters) fail
Cause racine : Proxy WinHTTP mal configuré (souvent laissé par un agent ou du débogage).
Correctif : netsh winhttp reset proxy et valider les paramètres proxy dans les paramètres système.
3) Symptom: You can ping the gateway, but nothing beyond it
Cause racine : Panne en amont, portail captif, ou pare‑feu/NAC bloquant les appareils inconnus.
Correctif : Essayez d’ouvrir un site HTTP non chiffré pour déclencher le portail captif ; réauthentifiez‑vous ; ou vérifiez si le SSID exige l’enregistrement de l’appareil.
4) Symptom: IP address is 169.254.x.x
Cause racine : Échec DHCP. Parfois l’AP est mal configuré ; parfois l’isolation client bloque le relais DHCP ; parfois le pilote est bloqué.
Correctif : Rebouncez l’adaptateur Wi‑Fi ; oubliez/reconnectez le réseau ; redémarrez l’AP ; vérifiez la portabilité VLAN et l’accessibilité du serveur DHCP.
5) Symptom: Only this one laptop fails on a known-good Wi‑Fi
Cause racine : Profil réseau corrompu, pilote de filtre cassé, ou réglages IP/DNS statiques obsolètes.
Correctif : Supprimez le profil Wi‑Fi et reconnectez‑vous ; réinitialisez Winsock/TCP/IP ; vérifiez que les propriétés de l’adaptateur ne sont pas configurées en statique par erreur.
6) Symptom: Works on 2.4 GHz but not 5/6 GHz (or vice versa)
Cause racine : Problèmes de pilote spécifiques à une bande, problèmes DFS/canal, ou incompatibilité de mode de sécurité (la transition WPA3 peut être chaotique).
Correctif : Mettez à jour le pilote ; changez le canal/la configuration de sécurité de l’AP ; forcez temporairement le client sur la bande stable pour confirmer l’hypothèse.
7) Symptom: After sleep, « No Internet, secured » until reboot
Cause racine : Bug de gestion d’alimentation/du pilote où la NIC ne se réinitialise pas correctement ou le renouvellement DHCP échoue.
Correctif : Désactivez les économies d’énergie agressives pour l’adaptateur ; mettez à jour/restaurez le pilote ; utilisez le rebond d’adaptateur comme solution d’attente.
8) Symptom: Internet works, but Windows still shows « No Internet »
Cause racine : Sonde NCSI bloquée par pare‑feu/proxy/détournement DNS ; ou un outil de confidentialité bloque les vérifications de connectivité.
Correctif : Si tout ce qui vous importe fonctionne, vous pouvez l’ignorer. Sinon, autorisez la sonde ou corrigez le comportement DNS/proxy.
Listes de contrôle / plan étape par étape
Checklist A: Quick recovery when you just need it working
- Confirmez le SSID est correct (Tâche 16).
- Désactivez/réactivez le Wi‑Fi (Tâche 15).
- Exécutez
ipconfiget confirmez une IP réelle et une passerelle par défaut (Tâche 2, Tâche 17). - Testez le ping de la passerelle (Tâche 5).
- Testez le TCP vers une IP externe (Tâche 8).
- Si le TCP fonctionne mais que les noms échouent, corrigez le DNS (Tâche 7, Tâche 12).
- Si les apps système échouent, réinitialisez le proxy WinHTTP (Tâche 10).
- Si rien ne fonctionne, réinitialisation Winsock (Tâche 13) puis redémarrage.
Checklist B: Correct diagnosis when it keeps coming back
- Capturez la table de routage et les métriques d’interface avant de modifier quoi que ce soit (Tâche 3, Tâche 4).
- Listez toutes les interfaces connectées (Tâche 1). Identifiez les adaptateurs « connectés inattendus ».
- Vérifiez APIPA et erreurs de renouvellement DHCP (Tâche 11, Tâche 17).
- Vérifiez la configuration proxy (Tâche 9).
- Corrélez les échecs avec des événements : veille/reprise, docking/undocking, connexion/déconnexion VPN, mises à jour Windows.
- Mettez à jour ou restaurez le pilote Wi‑Fi si la corrélation est forte.
Checklist C: “Reset the right adapter” decision tree
- Si 0.0.0.0/0 route par défaut pointe vers le mauvais adaptateur → désactivez le mauvais adaptateur ou corrigez sa métrique/routes.
- Si le Wi‑Fi n’a pas de passerelle ou a APIPA → réparez le DHCP (rebond d’adaptateur, réinitialiser le profil, problème AP/VLAN).
- Si l’IP fonctionne mais que le DNS échoue → réparez DNS/proxy, pas le Wi‑Fi.
- Si le TCP échoue mais que le ping de la passerelle fonctionne → suspectez portail captif/NAC ou pare‑feu en amont.
- Si tout semble correct mais que les apps échouent de manière incohérente → réinitialisation Winsock/TCP/IP et enquête sur les pilotes de filtre.
Trois mini‑histoires du monde corporate
Mini‑histoire 1 : La panne causée par une mauvaise hypothèse
La configuration était innocente : une salle de réunion avec une station d’accueil, Ethernet, et un Wi‑Fi « invité sécurisé » en secours. Une équipe visiteuse s’est plainte : tous les portables Windows affichaient Pas d’Internet, sécurisé sur le Wi‑Fi. Tout le monde a supposé que le SSID invité était en panne.
Les services ont redémarré le point d’accès. Toujours cassé. L’équipe réseau a vérifié l’uplink. Propre. Quelqu’un a ouvert un ticket intitulé « panne Wi‑Fi affectant les salles de réunion », ce qui explique comment cinq ingénieurs se sont retrouvés en conférence pour un problème de routage sur une seule machine.
La mauvaise hypothèse était subtile : ils ont supposé que l’adaptateur Wi‑Fi était le chemin. En réalité, les portables étaient dockés et un adaptateur Ethernet USB affichait « Disconnected » mais conservait la métrique la plus basse à cause d’un bug de pilote. Windows continuait d’essayer de router le trafic internet via le fantôme d’un Ethernet passé.
Nous l’avons prouvé en minutes en capturant route print et netsh interface ipv4 show interfaces. La route par défaut pointait vers une interface sans lien physique. La désactivation de cet adaptateur a immédiatement restauré l’internet via le Wi‑Fi sans toucher à l’AP.
La leçon, ennuyeuse et éternelle : ne dépannez pas ce que vous voyez (l’icône Wi‑Fi). Dépannez ce qui transporte la route par défaut. Le correctif est devenu une étape standard du helpdesk : vérifier la table de routage, puis réinitialiser le bon adaptateur.
Mini‑histoire 2 : L’optimisation qui s’est retournée contre nous
Une équipe sécurité a déployé une « amélioration de performance » pour les portables distants : VPN toujours actif agressif avec split tunneling pour réduire la charge sur les concentrateurs. Sur le papier, élégant — seuls les préfixes d’entreprise passaient dans le tunnel, le reste utilisait l’internet local.
Puis les rapports « Pas d’Internet, sécurisé » ont augmenté. Pas partout. Juste sur certains routeurs domestiques et quelques Wi‑Fi publics. Ce motif de défaillance partielle a retardé le diagnostic réel car cela ressemblait à une erreur utilisateur.
Le retour de bâton venait des métriques et du comportement DNS. Le client VPN installait les routes correctement, mais il injectait aussi des serveurs DNS d’entreprise inaccessibles tant que le tunnel n’était pas stable. Lors d’une instabilité du tunnel (courante sur Wi‑Fi capricieux), Windows tentait de résoudre des noms via des DNS inaccessibles. La connectivité IP existait, le DNS non. L’interface affichait « Pas d’Internet » et les utilisateurs y croyaient.
Pire, un script d’assistance tentait de « réparer le réseau » en réinitialisant toute la pile quand la sonde échouait. Cela a effacé des réglages soigneusement gérés et provoqué des douleurs de ré‑enrôlement pour les profils Wi‑Fi basés sur certificats. L’optimisation a été livrée avec un bouton de réinitialisation qui était essentiellement une attaque de déni d’aide‑desk distribuée.
La correction finale a été disciplinée : conserver les routes split‑tunnel, mais cesser de « polluer » le DNS pendant l’instabilité du tunnel. Aussi, arrêter d’exécuter des réinitialisations de pile automatiquement ; collecter des preuves d’abord. On peut automatiser le diagnostic, mais automatiser la panique reste de la panique.
Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée
Le département financier appliquait une politique stricte « pas de droits admin ». Les gens râlaient jusqu’au jour où cela les a discrètement sauvés. Un utilitaire tiers « amélioreur de Wi‑Fi » circulait comme remède miraculeux pour les appels vidéo. Il promettait un roaming plus intelligent et un « boost internet », ce qui n’existe pas vraiment, mais le marketing respecte rarement les limites.
Sur les machines où il était installé (petit groupe pilote avec accès admin), Pas d’Internet, sécurisé a commencé à apparaître après des redémarrages. L’utilitaire avait installé un pilote de filtre et modifié les paramètres proxy. Ça ne cassait pas tout de suite ; ça a cassé quand le fournisseur a mis à jour son app, changeant l’ordre des fournisseurs réseau. Classique misère à retardement.
Les machines finance n’avaient pas pu l’installer. Elles sont restées propres. Quand l’incident est survenu, la flotte « ennuyeuse » est devenue le groupe témoin. Même Wi‑Fi, mêmes VLAN, mêmes AP — pas de défaillance.
Parce que nous avions un groupe intact, nous avons rapidement isolé la différence : nouveau pilote de filtre + changement de proxy. Nous avons supprimé l’utilitaire, réinitialisé Winsock et standardisé les métriques sur les adaptateurs VPN. Le correctif a été direct parce que la baseline était stable et verrouillée.
Moral opérationnel : un contrôle strict des changements sur les endpoints n’est pas juste de la bureaucratie — c’est comment vous préservez un état connu‑bon quand le réseau devient bizarre.
Une citation opérationnelle (honnête)
Idée paraphrasée (attribuée) : Gene Kim souligne souvent que des opérations fiables viennent de retours rapides et de petits changements sûrs plutôt que de correctifs héroïques.
FAQ
1) Pourquoi Windows affiche « Pas d’Internet, sécurisé » alors que mon téléphone fonctionne sur le même Wi‑Fi ?
Votre portable peut router via une interface différente (VPN/adaptateur virtuel), utiliser un proxy cassé ou échouer au DHCP. Les téléphones ont généralement moins d’adaptateurs et moins d’accroches d’entreprise.
2) Dois‑je utiliser le bouton « Réinitialisation réseau » dans les Paramètres Windows ?
Uniquement après avoir essayé de reboucler l’adaptateur spécifique et vérifié les routes/métriques. « Réinitialisation réseau » a un large rayon d’impact : il supprime/réhydrate des adaptateurs, réinitialise de nombreux paramètres et peut casser des profils VPN.
3) Est‑ce généralement un problème DNS ?
Parfois. Mais « Pas d’Internet, sécurisé » est tout aussi souvent un problème de route par défaut ou un portail captif. Séparez‑les : testez le TCP vers une IP (Tâche 8) et la résolution DNS (Tâche 7). Puis décidez.
4) Quelle est la preuve la plus rapide que le mauvais adaptateur est utilisé ?
route print. Si 0.0.0.0/0 pointe vers un endroit surprenant, vous avez trouvé la raison. Ensuite vérifiez les métriques (Tâche 4) pour comprendre pourquoi.
5) Pourquoi désactiver un adaptateur VPN corrige‑t‑il le Wi‑Fi ?
Parce que l’adaptateur VPN peut installer des routes ou des paramètres DNS qui écrasent le chemin du Wi‑Fi. Le désactiver supprime ces routes et force Windows à utiliser la passerelle par défaut du Wi‑Fi.
6) Que signifie une IP 169.254.x.x ?
APIPA : Windows n’a pas pu obtenir de bail DHCP. Vous n’êtes pas « presque connecté ». Vous êtes isolé localement. Réparez l’accès DHCP et l’association.
7) IPv6 peut‑il être le problème ?
Oui, surtout sur des réseaux avec un IPv6 montante cassée. Mais ne désactivez pas IPv6 au hasard par superstition. Prouvez d’abord si les routes/DNS IPv6 échouent pendant qu’IPv4 marche, puis choisissez une action ciblée.
8) Pourquoi ne vois‑je cela que sur le Wi‑Fi invité ou dans des hôtels ?
Portails captifs, détournement DNS et sondes bloquées. Votre réseau peut exiger une authentification web avant d’autoriser le trafic, et les vérifications de connectivité Windows y sont sensibles.
9) Après netsh winsock reset, à quoi dois‑je m’attendre ?
Une exigence de redémarrage et, dans certains environnements, des clients VPN/clients de sécurité nécessitant réparation ou ré‑enregistrement. Cela corrige souvent des comportements de socket causés par des filtres/LSP défectueux.
10) Quand suspecter un bug de pilote plutôt qu’une mauvaise configuration ?
Si le problème se corrèle avec veille/reprise, docking, ou une mise à jour Windows/du pilote récente — et si reboucler l’adaptateur le corrige temporairement — placez les pilotes et les paramètres d’alimentation en tête de liste.
Conclusion : prochaines étapes que vous ferez vraiment
« Pas d’Internet, sécurisé » est rarement mystique. Windows est connecté à quelque chose, mais le chemin sortant est erroné ou la pile est compromise. Le bon mouvement est de cesser de considérer le Wi‑Fi comme une seule entité et de le voir comme un pipeline : adaptateur → IP → routes → DNS → proxy/filtrages.
Faites ceci ensuite, dans l’ordre :
- Exécutez
route printet identifiez qui possède 0.0.0.0/0. - Désactivez le concurrent fautif (VPN/virtuel) ou corrigez les métriques si nécessaire.
- Rebouclez le bon adaptateur (Wi‑Fi) et vérifiez que vous avez une IP réelle + passerelle.
- Séparez DNS du routage avec un test TCP vers une IP et une requête DNS.
- Si la pile est hantée, réinitialisez Winsock/TCP/IP — en connaissance de cause — et redémarrez une fois.
Soyez chirurgicaux. Collectez des preuves avant d’appuyer sur les boutons. Ce n’est pas seulement du bon génie logiciel ; c’est comment éviter de « réparer » votre portable au point de créer un problème plus coûteux.