La panne vient-elle du site ou de l’hébergement
Avant de chercher quoi réparer, il faut savoir à qui parler. Un incident qui relève de l’hébergement ne se corrige pas dans le code, et un incident applicatif ne sera jamais résolu par un ticket au support. Cette page donne la méthode que j’applique en premier, avant même de demander un accès : elle prend quelques minutes et évite des journées de renvois de responsabilité.
La frontière exacte entre les deux
L’hébergement, c’est la machine, le service web qui écoute, le service de base de données, l’espace disque, les limites de ressources et le réseau qui mène jusqu’à vous. Le site, c’est ce qui s’exécute dessus : le CMS, ses modules, son thème, ses fichiers de configuration, ses données.
La règle la plus simple est celle-ci : si le serveur a répondu quelque chose, l’hébergement fonctionne. Une page d’erreur, un message du CMS, une page blanche, une page à moitié construite : tout cela suppose qu’une machine a reçu la demande et a renvoyé une réponse. Le problème est alors applicatif dans l’immense majorité des cas. À l’inverse, l’absence totale de réponse, un message émis par le navigateur lui-même, ou une page générée par l’hébergeur sont les signes d’un incident en amont du site.
Cinq observations qui suffisent à trancher
-
Lire qui parle
Un message affiché avec la charte du navigateur vient du navigateur. Un message avec le logo de l’hébergeur vient de l’hébergeur. Un message aux couleurs du site vient du site. C’est trivial et pourtant c’est l’indice le plus fiable.
-
Tester une adresse qui ne dépend pas du CMS
Déposez un fichier texte à la racine, ou ouvrez une image existante directement. Si ce fichier s’affiche alors que les pages échouent, le serveur web est parfaitement opérationnel : la panne est dans l’exécution du site.
-
Comparer partie publique et administration
Si l’une répond et pas l’autre, l’hébergement est hors de cause : les deux passent par le même serveur, le même disque et la même base.
-
Regarder si un autre site du même compte fonctionne
Quand plusieurs sites partagent le même hébergement, un seul en panne désigne le site ; tous en panne désignent la machine ou le compte.
-
Vérifier la constance dans le temps
Une panne qui va et vient toutes les quelques minutes évoque une limite de ressources, donc l’hébergement. Une panne stable, identique à chaque essai, évoque du code.
Ce qui relève de chaque côté
- Hébergement : machine arrêtée, quota de disque ou de base atteint, compte suspendu, version de PHP modifiée, pare-feu qui bloque une adresse, panne réseau, certificat non renouvelé par le panneau.
- Site : module incompatible, surcharge fautive, cache compilé obsolète, requête trop lourde, fichier de configuration incorrect, données incohérentes après un import.
- Zone commune : droits sur les fichiers, tâches planifiées, envoi de courrier, réécriture d’adresses. Ces quatre sujets dépendent des deux à la fois, et c’est là que se perdent le plus de journées.
Quand la réponse est « les deux »
Certains incidents sont réellement mixtes, et c’est là que la méthode compte le plus. Un site qui consomme trop fait intervenir une limite d’hébergement, mais la cause est une requête mal écrite. Un envoi de courrier qui échoue met en jeu la configuration du serveur et le paramétrage du CMS. Un changement de version de PHP décidé par l’hébergeur casse un module qui n’était plus à jour.
- Dans ces cas, augmenter la ressource fait disparaître le symptôme sans traiter la cause, et le problème revient quelques mois plus tard.
- Corriger le code sans ajuster la limite laisse parfois une marge insuffisante pour les pics.
- La bonne démarche est de mesurer d’abord, puis de décider ce qui relève d’un réglage et ce qui relève d’une correction.
Je travaille seul et j’interviens des deux côtés : je lis le code comme les journaux du serveur. Cela évite l’aller-retour entre un développeur qui accuse l’hébergement et un support qui accuse le site.
Continuer sur la bonne page
-
Mon site ne répond plus du tout
Si rien ne s’affiche : les quatre vérifications à faire avant d’appeler qui que ce soit.
-
Erreur 502, 503 ou 504
Si un intermédiaire renvoie un code sans que le site réponde : quel maillon a lâché.
-
Mon hébergeur m’a envoyé un avertissement
Si le message vient de l’hébergement : quota, disque, processeur, base verrouillée.
-
Mon site est devenu lent du jour au lendemain
Si le site répond mais mal : séparer une lenteur serveur d’une lenteur applicative.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.