Pourquoi un site Web fonctionne-t-il avec les données mobiles mais pas avec le Wi-Fi ?

Si un site fonctionne avec les données mobiles, mais pas en Wi-Fi, il n'est pas hors ligne pour tout le monde. Ce qui change est le chemin entre votre appareil et le réseau Wi-Fi : les causes les plus probables sont le DNS local, le routeur, un VPN ou un filtre, l'état du navigateur ou le routage du fournisseur d'accès. Commencez par tester l'URL avec le vérificateur de disponibilité des sites ClockTools. Testez ensuite la même URL sur le même appareil via Wi-Fi et données mobiles, en modifiant une seule variable à la fois.

Que prouve ce symptôme ?

Cela prouve qu'au moins un chemin réseau atteint le site à cet instant. Cela ne prouve pas que toutes les pages, actions de compte, régions ou connexions y accèdent. Les données mobiles et le Wi-Fi domestique peuvent utiliser des résolveurs DNS, des adresses IP publiques, des routes, des filtres et des chemins IPv4/IPv6 différents.

Consultez ce petit tableau de diagnostic avant de modifier les réglages :

L'expression « même URL » est importante. Une page d'accueil et un tableau de bord authentifié peuvent parcourir différents chemins d'application. Copiez l'adresse complète plutôt que de saisir uniquement le domaine.

Le site Web est-il réellement en panne ?

Vérifiez le site depuis l'extérieur de votre réseau avant de redémarrer quoi que ce soit. ClockTools effectue des contrôles DNS et HTTP externes et indique l'état, la résolution A/AAAA, les redirections, l'URL finale, le statut de réponse, certains en-têtes et les durées. Lors d'un contrôle le 2026-08-31, https://example.com a été déclaré en ligne, avec HTTP 200, un DNS résolu et aucune redirection depuis le point de présence MAA. Un nom d'hôte .invalid volontairement inexistant a été déclaré inaccessible, avec un DNS non résolu et aucun résultat HTTP.

Ces deux tests montrent l'importance de l'ordre : un échec de résolution DNS et un serveur HTTP accessible demandent des corrections différentes. Ils montrent aussi les limites de l'outil. Un contrôle depuis un point de présence externe constitue un indice solide, pas une preuve de disponibilité depuis toutes les villes ou tous les fournisseurs d'accès.

Si le résultat externe est accessible mais que votre Wi-Fi échoue toujours, continuez localement. S'il est inaccessible en externe et sur les données mobiles, attendez ou contactez le propriétaire du site avant de changer de routeur.

Où devriez-vous tester ensuite ?

Suivez l'arbre de diagnostic dans le schéma ci-joint :

1. Gardez le même appareil et l'URL exacte ; ne changez que la connexion, Wi-Fi ou données mobiles.
2. Sur Wi-Fi, essayez une fenêtre privée ou un deuxième navigateur.
3. Essayez un autre appareil sur le même réseau Wi-Fi.
4. Suspendez temporairement un VPN ou un proxy juste assez longtemps pour exécuter une comparaison, puis restaurez-le.
5. Comparez le comportement de DNS avant de remplacer le résolveur.
6. Redémarrez le routeur uniquement après avoir enregistré les preuves que vous auriez autrement effacées.

Une fenêtre privée peut contourner certains cookies en cache et certaines extensions, mais elle ne crée pas une nouvelle route chez le fournisseur d'accès. Un deuxième appareil sur le même Wi-Fi aide davantage à distinguer l'état de l'appareil de celui du réseau. Pour examiner le chemin réseau, utilisez Traceroute; pour connaître l'adresse de sortie, comparez Quelle est mon adresse IP ? sur chaque réseau.

Le DNS peut-il expliquer la différence ?

Oui. Votre routeur Wi-Fi peut annoncer le résolveur du fournisseur d'accès, tandis que les données mobiles utilisent celui de l'opérateur. L'un peut avoir un enregistrement obsolète, une politique de filtrage ou une défaillance que l'autre n'a pas.

Commencez par l’observation, pas par un remplacement permanent. Notez si la vérification externe résout les enregistrements A ou AAAA. Sur l'appareil concerné, déconnectez-vous et reconnectez-vous au Wi-Fi, puis réessayez. Si votre système d'exploitation fournit un vidage du cache DNS, utilisez sa méthode documentée. Ensuite seulement, comparez avec un autre résolveur réputé. Cloudflare documente son Interface DNS-over-HTTPS JSON pour une comparaison explicite des résolveurs.

N'interprétez pas « le DNS fonctionne » comme « la page doit s'afficher ». Le DNS ne fait que résoudre le nom. TLS, le routage, la politique du serveur et l'application doivent aussi fonctionner.

Le routeur, le VPN ou le fournisseur d'accès peuvent-ils bloquer le chemin ?

Chacun peut produire exactement cette différence :

• Un routeur peut conserver un état défectueux, appliquer un contrôle parental, privilégier un chemin IPv6 défaillant ou bloquer une catégorie.
• Un VPN, un proxy, la protection web d'un antivirus ou un profil d'entreprise peut modifier le DNS et le routage.
• Un fournisseur d'accès peut subir un incident de routage ou de résolution touchant une destination.
• Un site peut limiter le débit ou bloquer l'adresse IP publique du réseau Wi-Fi tout en acceptant l'adresse IP de l'opérateur mobile.

Déterminez l'étendue du problème avant de désactiver des protections. Si tous les appareils échouent uniquement sur un même Wi-Fi, concentrez-vous sur ce réseau. Si seul un appareil administré échoue, ne retirez pas ses protections ; demandez à l'administrateur. La procédure de dépannage Wi-Fi de Windows de Microsoft et le guide de dépannage des connexions Android de Google commencent tous deux par des vérifications de base, puis distinguent progressivement l'état de l'appareil et celui du réseau.

Que devez-vous réinitialiser et dans quel ordre ?

Utilisez en premier le changement le moins perturbateur :

Évitez de réinitialiser le routeur en usine à moins que vous ne disposiez de sa configuration et de ses informations d'identification. Évitez de laisser un pare-feu, VPN ou un produit de sécurité désactivé simplement parce que la page s'est chargée une seule fois. Si la page s'ouvre mais semble incomplète, exécutez le Test de rendu de site Web car les ressources statiques ou les scripts peuvent échouer même si la réponse HTTP principale réussit.

Quand devez-vous arrêter le dépannage localement ?

Arrêtez les essais locaux et contactez le responsable lorsque les indices désignent une cause hors de votre contrôle : échec externe et sur données mobiles ; traces qui s'arrêtent systématiquement au-delà du routeur ; échec de tous les appareils chez un fournisseur d'accès alors qu'un autre réseau fonctionne ; ou réponse de politique d'accès liée à votre IP publique. Transmettez l'URL exacte, les horodatages avec fuseau, l'état externe, le résultat DNS, le réseau concerné et les tests déjà réalisés. Ces éléments sont bien plus utiles que « Internet est en panne ».

Questions fréquemment posées