Le message « le site ne fonctionne plus » peut décrire des situations très différentes : page lente, erreur DNS, certificat expiré, serveur indisponible ou erreur de l’application. Le premier objectif n’est pas de réparer immédiatement, mais de localiser la couche en cause.
1. Confirmer la panne depuis un autre accès
Rechargez la page sans utiliser un ancien onglet, puis testez depuis un autre navigateur. Essayez ensuite un autre réseau, par exemple la connexion mobile du téléphone. Si le site fonctionne ailleurs, le problème peut venir du cache, du DNS local, d’un proxy ou du réseau utilisé.
Notez l’adresse exacte, l’heure et le message affiché. Une erreur « domaine introuvable », une alerte de certificat et une réponse HTTP 500 n’orientent pas vers la même cause.
2. Vérifier que le domaine pointe au bon endroit
Le DNS traduit le nom du site en adresse réseau. Contrôlez les enregistrements A et AAAA, ainsi que les éventuels CNAME. Une modification récente peut ne pas être visible partout au même moment à cause des caches et de la durée TTL.
- le domaine renvoie-t-il bien une adresse attendue ;
- les versions avec et sans
wwwsont-elles cohérentes ; - un ancien serveur ou une ancienne adresse IPv6 reste-t-il publié ;
- les serveurs DNS autoritaires répondent-ils correctement.
Évitez de remplacer les enregistrements DNS tant que vous n’avez pas identifié une valeur incorrecte. Une modification inutile peut prolonger l’incident.
3. Contrôler HTTPS et le certificat TLS
Si le domaine se résout mais que le navigateur affiche une alerte, vérifiez la date de validité du certificat, les noms qu’il couvre et la chaîne de certification. Confirmez également que le serveur présente le bon certificat pour le domaine demandé.
Une redirection en boucle entre HTTP et HTTPS, ou entre deux noms de domaine, peut aussi rendre le site inutilisable alors que le serveur répond.
4. Tester la disponibilité du serveur
Si DNS et TLS sont corrects, observez le code HTTP. Une absence totale de réponse oriente vers le réseau, le pare-feu, le reverse proxy ou le service web. Une réponse 502 ou 504 indique souvent que le proxy ne parvient pas à joindre l’application. Une réponse 500 signifie que l’application a reçu la requête mais a rencontré une erreur.
Sur le serveur, vérifiez l’espace disque, la mémoire, l’état des services et les journaux autour de l’heure de la panne. Ne redémarrez pas tout immédiatement : un redémarrage peut effacer des indices utiles.
5. Examiner l’application et ses dépendances
Une base de données indisponible, un secret expiré, une migration incomplète ou une API tierce lente peuvent bloquer le site. Testez d’abord un point de santé local lorsqu’il existe, puis les dépendances une par une.
| Symptôme | Couche probable | Premier contrôle |
|---|---|---|
| Domaine introuvable | DNS | NS, A, AAAA et CNAME |
| Alerte de sécurité | TLS | Validité et noms du certificat |
| 502 ou 504 | Proxy ou application | Service amont et délais |
| 500 | Application | Journaux applicatifs |
| Lenteur | Ressources ou dépendance | Temps de réponse par composant |
Obtenir un premier diagnostic public
DomainCheck vérifie les informations publiques du domaine, notamment DNS, HTTPS, TLS et messagerie. Ce contrôle aide à écarter rapidement plusieurs causes sans intervenir sur le serveur.
Analyser mon domaine6. Documenter avant de refermer l’incident
Après le rétablissement, conservez la chronologie, la cause, la correction et les signaux qui auraient permis de détecter le problème plus tôt. Ajoutez ensuite un contrôle utile : expiration TLS, changement DNS, point de santé ou alerte de disponibilité.
Pour automatiser ces contrôles, consultez aussi le guide Surveiller un domaine, son certificat TLS et DMARC.
Publié le 5 août 2026.