C'est probablement l'erreur Chrome qui génère le plus d'appels paniqués à l'atelier. Le scénario est toujours le même : le client ouvre son navigateur pour lire ses courriels ou regarder Radio-Canada, et au lieu du site attendu, il se retrouve avec une page blanche sur laquelle flotte un grand « DNS_PROBE_FINISHED_NO_INTERNET » menaçant. Le Wi-Fi marche pourtant, l'icône en bas à droite est correcte, et tout le reste de l'appartement a Internet sans problème. Comment peut-on avoir Internet mais pas Internet en même temps ?
Un client de Sainte-Foy nous l'a amené la semaine passée après avoir passé une soirée complète à redémarrer son modem Vidéotron, à débrancher son routeur, à changer de câble Ethernet, à appeler Vidéotron qui lui a dit « tout va bien de notre côté ». En cinq minutes au téléphone, on avait trouvé : son fils avait installé un bloqueur de publicité au niveau système qui avait configuré un DNS local qui avait crashé sans se relancer. Un simple changement de DNS vers Cloudflare, et tout est rentré dans l'ordre. Ce genre de diagnostic n'est pas sorcier quand on sait où regarder, et c'est justement le but de ce guide.
Pour comprendre l'erreur, il faut savoir comment Internet fait pour trouver un site. Quand on tape radio-canada.ca dans le navigateur, l'ordinateur ne sait pas où se trouve physiquement ce site. Il doit d'abord demander à un serveur DNS (Domain Name System) : « où est radio-canada.ca ? ». Le serveur DNS lui répond avec une adresse IP (quelque chose comme 142.205.68.120), et seulement alors l'ordinateur peut se connecter au site.
Si le serveur DNS ne répond pas, ou répond n'importe quoi, ou met trop de temps, Chrome attend un peu puis abandonne en affichant DNS_PROBE_FINISHED_NO_INTERNET. Le « probe » signifie que Chrome a bien envoyé sa question DNS — mais n'a reçu aucune réponse exploitable. Le « no internet » est trompeur : Internet fonctionne généralement très bien, c'est juste la résolution de noms qui est cassée.
Les serveurs DNS utilisés par défaut sont ceux du fournisseur Internet. Pour un client Vidéotron, ce sont les DNS Vidéotron. Pour un client Bell, les DNS Bell. Pour un client Cogeco, les DNS Cogeco. Ces serveurs fonctionnent la plupart du temps, mais ils ont leurs mauvais jours, leurs pannes silencieuses, et ils sont parfois surchargés le soir à heure de pointe quand tout le monde écoute Netflix en même temps.
Avant de toucher à quoi que ce soit, quatre commandes permettent de cerner le problème. Ouvrir une invite de commandes (Windows + R, taper cmd) ou un Terminal sur Mac, puis taper une par une les commandes suivantes.
Première commande : ping 8.8.8.8. Si ça répond avec des millisecondes, Internet fonctionne mais le DNS ne répond pas. C'est un problème DNS. Si ça ne répond pas, le problème est plus profond — routeur, modem, câble réseau, ou fournisseur.
Deuxième commande : ping google.com. Si la précédente fonctionnait et que celle-ci échoue avec « hôte inconnu », confirmation que c'est DNS. Le PC peut joindre Internet mais ne peut pas traduire les noms de domaines.
Troisième commande : nslookup google.com 1.1.1.1. Ça force la requête DNS à passer par Cloudflare. Si ça répond avec une adresse IP, votre DNS actuel est en panne mais d'autres fonctionnent. Si ça échoue aussi, le problème est entre votre PC et Internet (firewall, routeur, fournisseur qui bloque).
Quatrième commande : nslookup google.com (sans spécifier de serveur). Ça utilise votre DNS par défaut. Si ça échoue ici mais que la précédente fonctionnait, changer de DNS règle immédiatement le problème.
Voici ce qu'on identifie en atelier et à distance chez les clients de la région de Québec.
Plus fréquent qu'on pense. Vidéotron, Bell, Cogeco, Telus — tous ont des pannes DNS silencieuses plusieurs fois par an. Le reste d'Internet fonctionne chez eux, mais leurs serveurs DNS répondent mal ou pas du tout. Solution immédiate : passer sur un DNS alternatif.
Windows et macOS gardent en mémoire les réponses DNS récentes pour aller plus vite la fois d'après. Quand ce cache se remplit de mauvaises entrées (à cause d'une panne temporaire, d'un changement de serveur d'un site, ou d'un bug), il faut le vider pour forcer une nouvelle résolution.
NordVPN, ExpressVPN, Surfshark, Proton VPN et leurs concurrents installent leurs propres DNS quand ils sont actifs. Quand le VPN se désactive mal (crash, déconnexion brutale), les DNS du VPN peuvent rester configurés sans pointer vers rien. Résultat : aucun site ne charge tant qu'on ne remet pas les DNS manuellement.
Les modules « protection Web » ou « filtrage DNS » de Kaspersky, ESET, Avast et d'autres peuvent casser la résolution quand leur base de données se désynchronise. On le voit particulièrement après une mise à jour de l'antivirus qui ne s'est pas terminée proprement.
Certains logiciels malveillants configurent leurs propres serveurs DNS pour rediriger l'utilisateur vers des sites frauduleux ou injecter de la publicité. Quand le serveur malveillant tombe, plus rien ne marche. On voit ça chez des clients qui ont téléchargé un « convertisseur YouTube gratuit » ou un faux utilitaire de nettoyage.
Certains routeurs ont leur propre serveur DNS interne qui peut planter après des semaines sans redémarrage. Le symptôme : tous les appareils de la maison ont le même problème en même temps. Redémarrer le routeur (vrai redémarrage, pas juste un Wi-Fi éteint/rallumé) règle presque toujours.
Sous Windows, le fichier C:\Windows\System32\drivers\etc\hosts permet de forcer des correspondances nom-IP locales. Certains malwares, certains outils piratés, et même certains antivirus modifient ce fichier pour rediriger ou bloquer des sites. Quand les redirections pointent vers des IP qui ne répondent plus, DNS_PROBE_FINISHED_NO_INTERNET garanti sur les sites concernés.
Certaines extensions installent des proxy ou des DNS sécurisés (DoH) qui prennent le contrôle de la résolution. Quand leur serveur tombe, Chrome échoue alors que Firefox continue de marcher. Tester en navigation privée (sans extensions) permet de confirmer.
On commence par les solutions qui règlent le plus de cas et qui ne cassent rien.
Alternatives selon les préférences : 8.8.8.8 / 8.8.4.4 (Google Public DNS, très fiable) ou 9.9.9.9 / 149.112.112.112 (Quad9, filtre les domaines malveillants).
ipconfig /flushdns ipconfig /release ipconfig /renew netsh winsock reset netsh int ip reset
Les trois dernières commandes renouvellent le bail DHCP et réinitialisent la pile TCP/IP. Redémarrer le PC après. Ça règle beaucoup de cas de corruption réseau profonde.
sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder
Débrancher physiquement le routeur (et le modem s'ils sont séparés) pendant trente secondes. Le « Wi-Fi éteint » depuis l'interface ne suffit pas. Rebrancher le modem d'abord, attendre deux minutes qu'il soit stable, puis le routeur. Tester. Ça règle les pannes DNS du routeur lui-même.
Pour éliminer ces deux suspects : fermer complètement le VPN (pas juste se déconnecter, quitter l'application) et désactiver le module de protection Web de l'antivirus. Tester. Si le problème disparaît, on sait lequel des deux est en cause.
Ouvrir le Bloc-notes en tant qu'administrateur (clic droit, Exécuter en tant qu'administrateur), puis Fichier, Ouvrir, et naviguer vers C:\Windows\System32\drivers\etc\hosts (afficher tous les fichiers). Un fichier hosts sain contient seulement des lignes qui commencent par # (commentaires) et éventuellement 127.0.0.1 localhost. Si on y trouve des lignes qui pointent des sites connus vers des IP bizarres, c'est probablement un malware. Sur Mac, le fichier est /etc/hosts, à vérifier avec sudo nano /etc/hosts.
Tester dans une fenêtre incognito de Chrome (Ctrl + Maj + N sous Windows, Cmd + Maj + N sur Mac). Si ça fonctionne là, c'est une extension. Tester aussi dans Firefox ou Edge. Si Firefox fonctionne et Chrome pas, c'est spécifique à Chrome — souvent lié à son mécanisme DoH (DNS over HTTPS).
Chrome utilise par défaut un mécanisme de DNS chiffré qui peut entrer en conflit avec certaines configurations. Aller dans chrome://settings/security, descendre jusqu'à « Utiliser un DNS sécurisé », désactiver. Tester. Cette option peut aussi être réactivée plus tard avec un fournisseur précis (Cloudflare) une fois le problème principal réglé.
Plusieurs configurations reviennent souvent en dépannage dans la région de Québec.
Clients Vidéotron avec modem Helix intégré — le modem-routeur Helix gère parfois mal le DNS après plusieurs semaines sans redémarrage. Un simple débranchement de 30 secondes règle la plupart des cas. Si le problème revient, configurer un DNS manuel sur chaque appareil évite de dépendre du modem.
PC avec ExpressVPN mal désinstallé — quand ExpressVPN est supprimé sans son utilitaire propre, il laisse des DNS configurés qui pointent vers ses serveurs. Ces DNS peuvent disparaître après quelques jours, ce qui casse tout. Solution : reconfigurer les DNS manuellement en DHCP automatique ou avec Cloudflare.
PME avec ESET Endpoint Protection — le module de protection Web d'ESET a eu plusieurs bugs en 2025 et début 2026 qui cassaient la résolution DNS après les mises à jour. Désactiver temporairement le module le temps d'une mise à jour suivante règle le problème.
Utilisateurs avec Pi-hole sur le réseau — quand un Pi-hole local tombe (Raspberry Pi qui a manqué d'alimentation, carte SD corrompue), toute la maison perd le DNS. Reconfigurer temporairement le routeur pour qu'il pousse 1.1.1.1 le temps de redémarrer le Pi-hole.
Ordinateurs après coupure Hydro-Québec — les coupures fréquentes l'hiver au Québec laissent parfois le modem-routeur dans un état instable. Si après une panne de courant plus rien ne fonctionne côté DNS, débrancher complètement tout le matériel réseau cinq minutes avant de remettre en route dans l'ordre modem-routeur-PC.
Les solutions ci-dessus règlent plus de 95 % des DNS_PROBE_FINISHED_NO_INTERNET. Les cas qui persistent malgré tout sont généralement liés à un malware, une corruption de pile TCP/IP non récupérable par les commandes standard, ou une configuration réseau complexe (VPN d'entreprise, proxy automatique, politique de groupe).
Un diagnostic professionnel permet d'analyser le trafic réseau avec Wireshark pour voir exactement où la requête DNS s'arrête, de vérifier l'intégrité de la pile Winsock avec des outils avancés, et de nettoyer les configurations résiduelles laissées par des VPN ou antivirus mal désinstallés. Le tout se fait généralement en moins d'une heure à distance si Internet basique fonctionne, ou en atelier si le problème empêche toute connexion.
Un cas récent illustre bien ce genre de dépannage : un travailleur autonome de Québec avec un HP ProBook qui avait DNS_PROBE_FINISHED_NO_INTERNET uniquement à la maison, mais qui fonctionnait partout ailleurs (café, bureau client, aéroport). Après investigation, on a trouvé que son routeur Bell Home Hub 4000 avait configuré automatiquement un DNS interne pour la gestion familiale, mais ce service avait planté. Aucune façon de le redémarrer depuis l'interface Bell — il fallait contacter Bell pour qu'ils réinitialisent à distance. En attendant, configurer Cloudflare sur son portable a débloqué sa journée.
Si vous n'arrivez pas à régler le problème vous-même, on vous offre deux options selon votre situation :
Téléphone : (418) 255-8998
