Confirmer une panne d’hébergeur, c’est écarter les causes qui se trouvent chez vous : DNS mal délégué, certificat, erreur PHP, formulaire cassé. Tant que ces pistes ne sont pas séparées, le ticket décrit « le site est down » et la réponse arrive à côté. L’ordre est fixe. Nommer le symptôme, reproduire depuis l’extérieur, puis seulement écrire à l’hébergeur si le symptôme est bien de son ressort.
Nommer ce que vous voyez
Les mots changent la suite du diagnostic.
- Le nom ne se résout pas (NXDOMAIN, SERVFAIL). Aucune connexion au serveur web n’a lieu. Piste domaine ou DNS, détaillée dans le monitoring de nom de domaine, avant la piste hébergeur.
- La connexion expire ou est refusée. Le nom pointe quelque part, mais rien n’accepte la connexion sur le port. Piste réseau, pare-feu ou machine arrêtée.
- 502 ou 504. Un intermédiaire (reverse proxy, répartiteur) a répondu à la place de l’application, qui n’a pas répondu à temps ou pas du tout. L’hébergeur est souvent concerné, surtout si vous ne gérez pas ce proxy.
- 503. Peut être une maintenance voulue ou une saturation. Le guide erreur 503 sépare les deux. Un 503 dont le corps est votre page de maintenance n’est pas une panne d’hébergeur.
- 500 avec le HTML de votre application. La requête est arrivée jusqu’au code. L’hébergeur a fait aboutir la connexion. Cherchez le déploiement, le plugin, la base.
Notez l’heure en UTC et l’URL exacte, y compris le nom d’hôte. « Le site » n’est pas une URL.
Reproduire hors de votre réseau
Votre navigateur peut afficher une page en cache, ou échouer à cause du résolveur du bureau. Ouvrez un test d’URL depuis un service extérieur, ou un autre accès (partage de connexion téléphone, hors Wi-Fi de l’entreprise).
Comparez trois cibles, dans cet ordre :
- L’URL publique qui pose problème.
- Une seconde URL du même site qui ne passe pas par le même code (un fichier statique, si vous en avez un).
- La page de statut de l’hébergeur, quand il en publie une.
Si le fichier statique répond et que seule l’URL dynamique renvoie 500, l’hébergeur livre encore des fichiers. L’incident est dans l’application. Si rien ne répond, y compris le statique, et que la page de statut annonce un incident sur la plateforme, vous avez la confirmation. Si rien ne répond mais que la page de statut est verte, votre nom peut pointer vers une mauvaise adresse, ou seule votre offre est arrêtée : le ticket doit citer l’adresse IP obtenue et l’heure.
Un seul échec depuis une seule ville ne suffit pas quand vous disposez de plusieurs points de mesure. La règle de majorité est dans le monitoring multi-localisations. Une sonde isolée peut voir un chemin réseau défaillant alors que l’hébergeur va bien.
Le message qui se traite
Écrivez quatre lignes : heure UTC de début, URL, symptôme (pas « ça ne marche pas »), résultat du test extérieur. Ajoutez si un statique sur le même nom répond. Joindre une capture du seul navigateur du bureau fait perdre un aller-retour.
Pendant l’attente, laissez le contrôle tourner. L’historique dira si la reprise a eu lieu avant la réponse au ticket, et combien de minutes compter. Ne redémarrez pas des services au hasard si vous n’administrez pas la machine : sur un mutualisé, vous n’avez souvent pas ce levier, et sur un serveur dédié un redémarrage non motivé efface l’état à observer.
SiteGarde fournit le relevé extérieur utilisé dans ce tri. Il ne distingue pas à lui seul « panne d’hébergeur » et « panne d’application » : c’est le type d’échec (DNS, 502, 500) qui tranche, pas le mot panne.