Personne ne l'a entendu, parce que chaque avertissement s'écrivait dans un fichier que personne ne lit.
Un vendredi, au petit matin, la page d'atterrissage d'un client a cessé de s'ouvrir dans tous les navigateurs. Le certificat de sécurité était expiré. Notre surveillance a signalé la panne en sept minutes et, une fois sur le dossier, nous avons remis le site en ligne en quatre.
La cause remontait à des semaines. Lors d'une migration de serveur, ce certificat était resté lié à un compte qui n'existait pas sur le nouveau serveur. Depuis, il tentait de se renouveler deux fois par jour. Soixante tentatives, soixante échecs, aucune alerte.
Trois choses ont amplifié le problème :
1. En fermant la migration, nous avons vérifié que le site s'ouvrait, pas que le certificat pouvait se renouveler.
2. L'outil de renouvellement échoue en silence.
3. Nous surveillions l'expiration du domaine, pas celle du certificat. Ce sont deux expirations distinctes et une seule avait une sonde.
Le plus précieux est venu ensuite. Nos agents ont lancé le test de renouvellement sur les treize certificats du serveur et dix autres ont échoué : le site, le bot WhatsApp, les automatisations, le CRM. Tous expiraient le même jour, 45 jours plus tard. Ç'aurait été le même incident multiplié par dix. Les agents ont corrigé les dix et vérifié les treize au vert.
La décision de fond nous revenait : réparer ne suffit pas, il faut le savoir avant. Aujourd'hui, une sonde avertit 21 jours avant chaque expiration. Avec elle, cet incident nous aurait avertis trois semaines avant la panne.
Les règles que nous appliquons aujourd'hui sur chaque serveur que nous exploitons :
1. Ce qui roule tout seul (renouvellements, sauvegardes, alertes) se teste en l'exécutant une fois, pas en le regardant.
2. Une erreur que personne ne lit n'est pas un avertissement.
3. Chaque expiration a sa propre sonde.
4. Une étape reportée a besoin de quelque chose qui la reprenne.
Un site en panne, ça se remarque. Dix sur le point de tomber, non.