Pourquoi votre hébergeur ne vous prévient pas quand votre site tombe

Votre serveur n'a pas bougé. Le disque va bien, le réseau répond, le processeur se tourne les pouces. Et votre page d'accueil renvoie une erreur 500 à tous les visiteurs depuis six heures.

Les deux affirmations sont vraies en même temps, et c'est tout le malentendu. Votre hébergeur ne vous ment pas et ne vous néglige pas : il regarde autre chose que ce que vous croyez qu'il regarde.

Ce qu'il surveille, ce qu'il ne voit pas, qui le voit

La colonne de droite est celle qui compte : dans cinq cas sur huit, la seule personne au courant est un visiteur, et un visiteur ne vous écrit pas.

Deux objets différents

Un hébergeur surveille la machine : est-elle alimentée, joignable, a-t-elle de l'espace disque, le réseau passe-t-il. Sa surveillance existe pour tenir son propre engagement, qui porte sur l'infrastructure.

Votre site est une application qui tourne sur cette machine. Une erreur PHP, une extension mise à jour de travers, un certificat expiré, une base de données arrêtée : rien de tout cela ne rend la machine malade. Du point de vue de l'hébergeur, tout est normal, et factuellement, il a raison.

Les cinq pannes qu'un hébergeur ne signalera jamais

Le certificat expiré. Le serveur répond parfaitement, c'est le navigateur qui refuse d'afficher. Aucun indicateur d'infrastructure ne bouge, et cette panne-là ne laisse aucune trace dans vos journaux.

Le déploiement raté. La racine de documents pointe au mauvais endroit, une route est fausse, un fichier de configuration manque. La machine sert consciencieusement une page d'erreur, ce qui est exactement son travail.

L'erreur applicative. Une mise à jour d'extension, une dépendance incompatible, une base qui refuse les connexions. Le serveur web répond, et il répond une 500.

La lenteur. Huit secondes par page, c'est une réponse valide pour une supervision d'infrastructure. Pour un visiteur, c'est un site cassé.

La panne partielle. L'accueil va bien, le tunnel de commande est mort. Aucun outil qui ne teste que la racine du domaine ne le verra, y compris le vôtre si vous l'avez réglé ainsi.

Ce qu'un hébergeur ne peut sincèrement pas savoir

Même avec la meilleure volonté, un prestataire ignore :

• ce que votre page d'accueil est censée afficher ;
• si une redirection 302 est volontaire ou le résultat d'un déploiement raté ;
• si une page blanche est un parti pris ou une erreur fatale attrapée trop tard ;
• si votre certificat couvre bien le sous-domaine que vos clients utilisent ;
• si le formulaire de contact envoie encore quelque chose à quelqu'un.

Répondre à ces questions suppose de charger vos pages et de savoir ce qu'on devrait y trouver. Ce n'est pas son métier, et honnêtement, ce ne devrait pas l'être : un hébergeur qui inspecterait le contenu de vos pages poserait d'autres problèmes, autrement plus gênants.

Lire une page d'état sans se faire piéger

Une page d'état verte ne dit pas « votre site fonctionne ». Elle dit « nous n'avons pas déclaré d'incident sur nos services ». Trois nuances valent la peine.

Elle est déclarative. Un incident y apparaît quand quelqu'un l'y écrit, souvent après confirmation interne, parfois avec une heure de retard sur le moment où vous, vous l'avez vu.

Elle est globale. Un incident qui touche trois cents serveurs sur cinquante mille peut ne jamais y figurer, ce qui est compréhensible et ne vous console pas si vous êtes dans les trois cents.

Elle ne couvre pas les services voisins. Le registrar, le fournisseur de messagerie, le CDN, la passerelle de paiement ont chacun la leur, et une panne chez l'un d'eux se lit sur votre site sans apparaître nulle part chez votre hébergeur.

Le cas de l'infogérance

Il existe des contrats qui couvrent réellement l'application : infogérance, support managé, offres avec engagement de disponibilité applicative. Ils sont plus chers, et ils tiennent parfois leur promesse.

Deux vérifications avant d'y compter. Lisez ce que le contrat surveille exactement : « supervision 24/7 » désigne le plus souvent l'infrastructure, pas vos pages. Et demandez ce qui déclenche une intervention : un seuil de charge n'est pas la même chose qu'un code HTTP inattendu sur votre page d'accueil.

Le test qui tranche tient en une question à poser au support : si ma page d'accueil renvoie une erreur 500 pendant deux heures un dimanche, est-ce que quelqu'un chez vous s'en aperçoit ? La réponse est instructive, quelle qu'elle soit.

Ce que vous pouvez raisonnablement attendre de votre hébergeur

Le but de cet article n'est pas de lui faire un procès. Il rend un service précis, et il est utile de savoir lequel, ne serait-ce que pour ne pas payer deux fois la même chose.

Attendez-en la disponibilité de la machine, un réseau qui répond, des sauvegardes qui existent réellement et se restaurent, une page d'état honnête, et un support capable de dire si l'incident vient de chez lui.

N'en attendez pas la connaissance de votre application, la vérification de vos certificats applicatifs, la relecture de vos déploiements, ni une alerte quand votre contenu change de forme.

Une bonne façon de résumer : votre hébergeur répond de la maison, vous répondez de ce qui s'y passe. Les deux sont nécessaires, et confondre les deux périmètres est la cause la plus fréquente d'une panne longue.

Le test en une soirée

Si vous n'êtes pas certain de ce que couvre votre installation actuelle, faites l'expérience plutôt que la théorie. Sur un environnement de préproduction, provoquez volontairement trois pannes et regardez qui vous prévient, et en combien de temps.

Coupez le service applicatif : vous devriez recevoir quelque chose. Laissez expirer un certificat de test : c'est là que la plupart des installations découvrent leur angle mort. Enfin, cassez une seule page en laissant le reste du site debout : c'est la panne la plus fréquente en production, et celle que presque aucune surveillance ne détecte par défaut.

Le résultat de cet exercice vaut mieux que n'importe quelle promesse commerciale, y compris la mienne.

L'angle mort, au milieu

Entre « la machine est debout » et « le site fonctionne », il existe un espace où vivent la plupart des pannes. Pas les défaillances spectaculaires : celles-là se remarquent. Les discrètes : une erreur sur une page, un certificat qui expire un dimanche, un formulaire qui cesse de partir après une mise à jour.

Personne ne surveille cet espace par défaut. Ni votre hébergeur, dont le travail s'arrête avant. Ni vos visiteurs, qui partent plutôt que d'écrire. Et c'est précisément là que le coût d'une panne se joue, puisqu'il dépend moins de la panne elle-même que du temps qu'elle a passé à l'écran.

Regarder d'où regardent vos visiteurs

Le seul point de vue qui corresponde à la réalité est celui de l'extérieur : charger la page comme un visiteur, lire le code de réponse, vérifier le certificat, et comparer avec ce qui devrait se produire.

C'est exactement la différence entre la surveillance d'infrastructure et la surveillance de site. Les deux sont complémentaires, pas interchangeables, et une seule des deux vous dira que votre page d'accueil est cassée depuis ce matin. Reste à décider qui la met en place : votre propre script ou un service extérieur, et à quel rythme la vérification doit tourner.

Cette règle ne s'arrête d'ailleurs pas à votre serveur. Les liens que d'autres sites vous ont donnés disparaissent exactement de la même façon, sans que personne ne vous écrive et sans qu'aucun rapport ne l'affiche : c'est le même angle mort, une couche plus loin.

Et le jour où l'alerte tombe, elle ne vous dira pas quoi faire : les quinze premières minutes restent les mêmes, avec ou sans hébergeur au bout du fil.