Quand prévenir un client que son site est en panne ?

Dès que vous avez confirmé qu'il s'agit d'une vraie panne et pas d'un problème local, idéalement dans la première heure. Un message court avec ce que vous savez, qui vous avez contacté et quand vous ferez le point suffit. Un client pardonne une panne bien plus facilement que de l'apprendre par un de ses propres clients.

Faut-il restaurer une sauvegarde tout de suite ?

Pas tant que vous ne savez pas quelle couche est en cause. Une sauvegarde ne règle ni un domaine expiré, ni une modification DNS, ni une panne d'hébergeur, et restaurer une ancienne copie peut effacer des contenus récents et ramener d'anciens réglages. Restaurez quand le problème vient clairement des fichiers ou de la base de données.

Et si le site est en panne seulement pour certaines personnes ?

Les pannes partielles viennent souvent d'une modification DNS encore en propagation, d'un nœud CDN défaillant dans une région ou d'une règle de pare-feu qui bloque certains pays ou réseaux. Demandez aux personnes concernées d'où elles se connectent et quelle erreur elles voient, et testez depuis plusieurs endroits avant d'appeler l'hébergeur.

Une courte panne nuit-elle au référencement Google ?

Une panne brève a très peu de chances de laisser des traces durables. Les problèmes arrivent quand le site renvoie des erreurs longtemps ou de façon répétée, car l'exploration ralentit et des pages peuvent sortir de l'index. Pendant une maintenance prévue, renvoyer un 503 est la façon standard de signaler un problème temporaire.

Un outil de monitoring peut-il dire pourquoi le site est tombé ?

En partie seulement. Un outil de monitoring enregistre le code HTTP, le temps de réponse et l'heure du début du problème, ce qui réduit les pistes. La vraie raison, par exemple une base de données bloquée ou des ressources d'hébergement épuisées, se trouve dans les logs du serveur et chez l'hébergeur.

← Retour au blog

Site client en panne : que faire, et dans quel ordre

Quand le site d'un client est en panne, que faire suit un ordre précis : vérifier qu'il est vraiment inaccessible et pour qui, identifier la couche qui a lâché (domaine, DNS, SSL, serveur ou application), contacter celui qui la contrôle, et prévenir le client avant qu'il ne vous prévienne. Une fois le site revenu, vérifiez qu'il n'est pas revenu avec un problème SEO en prime.

Confirmer la panne avant de toucher à quoi que ce soit

Un site qui ne s'ouvre pas sur votre portable n'est pas encore une panne. Testez-le depuis la 4G plutôt que le wifi du bureau, et avec un outil en ligne qui l'interroge depuis un autre endroit. Puis regardez ce qui revient vraiment :

délai dépassé ou aucune réponse : en général le serveur ou l'hébergement
500, 502, 503 ou 504 : quelque chose répond, mais l'application ou un service derrière est tombé
403 ou page de challenge : un pare-feu vous bloque peut-être, le site n'est pas forcément hors ligne
alerte de certificat : le site tourne, mais le certificat SSL est expiré ou incorrect
DNS_PROBE_FINISHED_NXDOMAIN dans Chrome : le nom de domaine ne se résout plus

En ligne de commande, curl -I https://example.com donne le code HTTP et les en-têtes d'un coup, et dig example.com indique si le DNS renvoie encore une adresse IP.

Vérifier d'abord le domaine et le DNS

Un domaine expiré fait tout tomber en même temps, site et e-mails compris. Lancez une recherche WHOIS ou RDAP et lisez la date d'expiration et le statut. Un statut comme clientHold ou redemptionPeriod signifie que le registrar l'a suspendu, souvent après un renouvellement impayé, et la solution est entre les mains du titulaire du compte registrar.

Si le domaine est en règle mais que le DNS ne répond pas, ou renvoie une IP différente de la semaine dernière, cherchez qui a modifié les serveurs de noms ou les enregistrements. Notre guide sur la surveillance de l'expiration des domaines explique comment éviter que le cas du domaine expiré n'arrive jusque-là.

Qui contacter, selon ce que vous avez trouvé

Choisissez l'interlocuteur selon la couche en cause :

domaine expiré ou suspendu : le titulaire du compte registrar, puis le registrar
enregistrements DNS erronés : celui qui gère la zone DNS (registrar, Cloudflare ou hébergeur)
délais dépassés ou 5xx sur tout le site : le support de l'hébergeur, avec le code HTTP et l'heure du premier constat
erreurs sur certaines pages seulement, ou juste après un déploiement ou une mise à jour d'extension : le développeur de la dernière modification
certificat invalide : l'hébergeur, ou celui qui gère les renouvellements

Quoi dire au client, et quand

Prévenez-le tôt. Un premier message dans l'heure, même s'il ne contient que ce que vous savez, passe bien mieux qu'une explication parfaite envoyée après son appel. Indiquez ce qui est touché, depuis quand, ce que vous avez vérifié, qui vous avez contacté et quand il aura des nouvelles.

N'avancez pas de cause dans le premier message, seulement ce qui est vérifié. Si plusieurs personnes côté client vous relancent, une page de statut pour le client vous évite d'envoyer cinq fois la même mise à jour.

Une fois le site revenu : que vérifier

Un site restauré depuis une sauvegarde, migré vers un autre serveur ou corrigé dans l'urgence peut revenir différent. Avant de clore l'incident, vérifiez que :

le robots.txt n'a pas été remplacé par une ancienne version ou celle de la préprod avec Disallow: /
les gabarits principaux ne portent ni balise noindex ni en-tête X-Robots-Tag
le sitemap XML s'ouvre et liste à peu près autant d'URL qu'avant
les balises canonical pointent toujours vers le domaine de production, pas vers la préprod
GA4, GTM et les pixels publicitaires se chargent sur les gabarits principaux

Les vieilles sauvegardes sont une source classique de noindex oublié, d'où l'intérêt de lire comment repérer un noindex en production.

Ce que Deltio couvre

Deltio vérifie chaque site en HTTP toutes les 10 minutes et le classe online, offline ou firewall blocked, avec le code HTTP et le temps de réponse. Vous recevez une notification par e-mail ou Slack quand un site tombe, puis une autre quand il revient, et chaque site peut avoir une page de statut publique à partager avec le client. Le même compte surveille la validité SSL, l'expiration du domaine, le robots.txt, le sitemap, les balises SEO et les tags marketing, ce qui couvre l'essentiel de la liste ci-dessus. Les analyses sitemap et SEO tournent sur un cycle quotidien : après un retour en ligne, lancez une analyse manuelle plutôt que d'attendre. Ce que Deltio ne peut pas vous dire, c'est pourquoi le serveur est tombé : pour cela, il faut l'hébergeur et ses logs.

Les offres démarrent à £24 par mois, avec un essai gratuit de 14 jours.

Questions fréquentes

Quand prévenir un client que son site est en panne ?: Dès que vous avez confirmé qu'il s'agit d'une vraie panne et pas d'un problème local, idéalement dans la première heure. Un message court avec ce que vous savez, qui vous avez contacté et quand vous ferez le point suffit. Un client pardonne une panne bien plus facilement que de l'apprendre par un de ses propres clients.
Faut-il restaurer une sauvegarde tout de suite ?: Pas tant que vous ne savez pas quelle couche est en cause. Une sauvegarde ne règle ni un domaine expiré, ni une modification DNS, ni une panne d'hébergeur, et restaurer une ancienne copie peut effacer des contenus récents et ramener d'anciens réglages. Restaurez quand le problème vient clairement des fichiers ou de la base de données.
Et si le site est en panne seulement pour certaines personnes ?: Les pannes partielles viennent souvent d'une modification DNS encore en propagation, d'un nœud CDN défaillant dans une région ou d'une règle de pare-feu qui bloque certains pays ou réseaux. Demandez aux personnes concernées d'où elles se connectent et quelle erreur elles voient, et testez depuis plusieurs endroits avant d'appeler l'hébergeur.
Une courte panne nuit-elle au référencement Google ?: Une panne brève a très peu de chances de laisser des traces durables. Les problèmes arrivent quand le site renvoie des erreurs longtemps ou de façon répétée, car l'exploration ralentit et des pages peuvent sortir de l'index. Pendant une maintenance prévue, renvoyer un 503 est la façon standard de signaler un problème temporaire.
Un outil de monitoring peut-il dire pourquoi le site est tombé ?: En partie seulement. Un outil de monitoring enregistre le code HTTP, le temps de réponse et l'heure du début du problème, ce qui réduit les pistes. La vraie raison, par exemple une base de données bloquée ou des ressources d'hébergement épuisées, se trouve dans les logs du serveur et chez l'hébergeur.