Comment sais-tu que ton site est en panne avant qu'un client ne te le dise ?

Toute panne a deux coûts. Le premier, ce sont les commandes que tu n’as pas prises. Le second, c’est la phrase « votre site est en panne depuis hier », écrite par un client qui l’a appris avant toi — et celui-là se paie en confiance, sur une bien plus longue durée.

Pourquoi le client s’en aperçoit-il avant toi ?

Parce que le client fait quelque chose de précis : acheter, se connecter, payer. Toi, tu regardes un tableau de bord, ou tu ne regardes pas du tout.

Les histoires se ressemblent. Un site en panne pendant au moins une journée, remarqué seulement parce qu’un service tiers sans rapport affichait la page par défaut d’Apache. Un autre, où l’alerte de panne avait bien été envoyée et avait atterri dans les indésirables. Dans les deux cas, ce n’est pas la surveillance qui a échoué : c’est le fait de s’en apercevoir.

La page d’accueil suffit-elle ?

C’est le minimum, et elle répond à une question plus étroite qu’on ne le croit. Une page d’accueil qui renvoie 200 prouve qu’un serveur web répond à cette adresse. Elle ne prouve pas que la connexion fonctionne, que le panier accepte un article, que l’étape de paiement se charge, que la recherche renvoie quelque chose, ni que le courriel de commande sort de la maison.

Les pannes qui font mal à une boutique en ligne sont presque toutes en aval de la page d’accueil. Le contrôle doit donc descendre en aval lui aussi : une séquence enregistrée qui ouvre une page, suit un lien, soumet une étape et attend un code de statut précis ou un mot précis à l’écran. Si l’étape quatre cesse de renvoyer la page de paiement, tu le sais avant que le premier client n’abandonne.

Deux autres contrôles appartiennent au même groupe, parce qu’ils échouent sur un calendrier et non au hasard : le certificat TLS, compté en jours restants, et la date d’échéance du domaine. Un certificat expiré est une panne complète pour chaque visiteur, annoncée des semaines à l’avance à qui prenait la peine de compter.

Que doit-il se passer entre la panne et le coup de téléphone ?

L’alerte doit être confirmée, savoir à qui appartient la panne de réseau, t’atteindre là où tu es, ne pas se répéter neuf fois et revenir si tu oublies : c’est cette partie qui décide si la surveillance est utile ou seulement bruyante.

Elle doit être confirmée. Un seul contrôle échoué ne veut pas dire grand-chose : un moment de lenteur, un paquet perdu, un hoquet de réseau quelque part entre les deux bouts. Exiger que la panne se répète, et demander l’avis d’un deuxième point d’observation, enlève la plupart des fausses alertes sans ajouter de délai réel.

Elle doit savoir à qui appartient le problème de réseau. Si celui qui a perdu sa connexion est l’observateur et non l’observé, ce n’est pas ta panne et elle ne doit pas être comptée comme telle. Ces échecs doivent être mis de côté et signalés comme un avis de plateforme, pas comme neuf incidents sur ton compte.

Elle doit arriver là où tu es. Le courriel est la trace, pas l’alarme ; il est filtré, replié et lu le matin. Un message de discussion t’atteint dans la journée. Un appel téléphonique, c’est ce que tu veux pour les deux ou trois services où une heure de silence coûte vraiment cher — et il doit respecter les heures de repos, pour que ceux qui sonnent la nuit veuillent dire quelque chose.

Elle ne doit pas se répéter neuf fois. Quand un serveur tombe, tout ce qu’il porte tombe avec lui. Une alerte pour une panne, avec un seul message de rétablissement, c’est la différence entre une alerte que tu lis et une alerte que tu coupes.

Elle doit revenir si tu oublies. Un rappel tant que le service est encore à terre — après une heure, après six, puis chaque jour — attrape l’incident acquitté à minuit par quelqu’un qui s’est ensuite rendormi.

Et les clients qui écrivent quand même

Pendant que tu répares, il faut bien que quelqu’un réponde au téléphone. Une page d’état publique, avec un court message écrit dans la langue du visiteur, transforme vingt interruptions en un lien — et c’est aussi la trace de ce qui s’est passé, dont tu auras besoin plus tard, quand on te demandera combien de temps ça a duré.

Que faire cette semaine

1. Liste ce qu’un client fait vraiment sur ton site : se connecter, chercher, ajouter au panier, payer. Ce sont là tes contrôles, pas la page d’accueil.
2. Construis une séquence qui parcourt le plus précieux de ces chemins et qui attend un mot précis à la dernière étape.
3. Mets les jours restants du certificat et l’échéance du domaine quelque part où tu les verras.
4. Choisis un service qui justifie un appel à trois heures du matin — un seul, choisi honnêtement — et dirige-le vers un appel.
5. Écris la page d’état avant d’en avoir besoin. Personne n’en écrit une bonne pendant une panne.

Le but n’est pas un tableau de bord parfait. C’est que la prochaine fois que quelque chose casse, tu sois déjà en train de le réparer quand le premier client écrit.