Comment diagnostiquer l'erreur « Impossible d'accéder à ce site »

« Impossible d'accéder à ce site » (ou la formule équivalente de votre navigateur) est volontairement vague : elle couvre aussi bien une faute de frappe dans l'URL qu'un serveur totalement hors service ou une panne de votre propre connexion. Pour s'en sortir efficacement, il faut vérifier d'abord les choses les plus simples et les plus rapides.

Commencez par une simple recherche DNS

Avant de supposer qu'un serveur est en panne, résolvez le domaine seul, indépendamment de votre navigateur. S'il renvoie une adresse IP propre, le DNS n'est pas le problème et vous pouvez passer à la vérification de la connexion elle-même (le port est-il ouvert, TLS négocie-t-il, le serveur répond-il vraiment). S'il renvoie NXDOMAIN, un délai dépassé ou une adresse privée ou d'apparence injoignable, vous avez isolé le problème au niveau du DNS, ce qui écarte immédiatement toute une catégorie d'autres diagnostics.

Ce que chaque résultat vous apprend

C'est aussi pourquoi un outil de recherche rapide et sans inscription est vraiment utile en plein incident : il vous donne la réponse de la couche DNS en quelques secondes, sans ouvrir de terminal ni retenir la syntaxe de dig ou nslookup, et vous savez tout de suite si vous avez réellement affaire à un problème DNS avant de perdre du temps ailleurs.

Au-delà du DNS : les vérifications suivantes, dans l'ordre

1. La connectivité TCP vers l'IP résolue sur le port attendu (généralement 443) : un pare-feu ou un serveur totalement arrêté refusera ou laissera la connexion en suspens ici, même avec un DNS parfait.
2. La validité du certificat TLS : un certificat expiré ou non conforme provoque un avertissement de sécurité du navigateur qui paraît alarmant mais n'a rien à voir avec le DNS ni avec l'accessibilité du serveur.
3. La réponse au niveau HTTP : un serveur qui accepte la connexion mais renvoie une erreur 5xx est en marche et joignable, il échoue simplement au niveau applicatif, plusieurs étapes après tout ce que le DNS aurait pu causer.

Passer ces étapes dans l'ordre (DNS, puis transport, puis TLS, puis application) fait que chaque élément écarté réduit sensiblement les possibilités restantes, au lieu de deviner sur l'ensemble de la pile à la fois.

Pourquoi cet ordre précisément

Chaque couche de cette séquence dépend entièrement de la réussite de la précédente, ce qui explique pourquoi les vérifier dans l'ordre (plutôt que de sauter à celle qui semble la plus probable) est l'approche efficace. Inspecter un certificat TLS n'a aucun sens si la connexion TCP n'a jamais abouti, et vérifier les codes de réponse HTTP n'en a pas davantage si la négociation TLS a échoué. Partir du DNS, la toute première chose qui doit fonctionner pour que le reste soit possible, et avancer d'une couche à la fois, vous évite de perdre du temps sur un symptôme qu'un problème plus simple, situé dans une couche antérieure, causait depuis le début.