Site en panne : ce que l'incident de 2016 m'a appris

Le 15 novembre 2016, à minuit passé, je publiais un billet intitulé « Mon blog est inaccessible ». J'y expliquais, sur le site même qui venait de tomber, pourquoi il ne répondait plus, avec l'enthousiasme un peu candide de celui qui découvre qu'une bonne pratique de sécurité peut se retourner contre lui. Dix ans plus tard, j'ai maintenu des plateformes où l'indisponibilité ne se mesure plus en visiteurs perdus mais en communes privées de leur outil électoral. Ce billet part de l'incident de 2016 et en tire la méthode que j'applique aujourd'hui quand un site tombe.

Novembre 2016 : enfermé dehors par ma propre sécurité

À l'époque, mon blog était servi en HTTPS avec un certificat gratuit Let's Encrypt. J'avais aussi activé HSTS moi-même, jusqu'à inscrire le domaine sur la liste de préchargement des navigateurs. HSTS dit en substance au navigateur : ce site se sert uniquement en connexion sécurisée, refuse tout le reste, sans exception.

Ce jour-là, j'ai migré vers un serveur avec plus de ressources. Pendant la migration, j'ai dû régénérer mon certificat SSL, via un outil « en un clic ». Un champ était erroné, le certificat l'a donc été aussi. Et comme HSTS interdisait toute connexion non sécurisée, les navigateurs ont fait exactement ce que je leur avais demandé : ils ont refusé de charger mon site. Pas de piratage, pas de données perdues. Un site verrouillé par la règle que j'avais moi-même écrite, le temps de régénérer un certificat correct.

Je précisais déjà à l'époque que je ne blâmais pas Let's Encrypt, la régénération « en un clic » ne venait pas d'eux. La vraie leçon n'était pas « la sécurité est risquée ». C'était : une opération critique exécutée à la va-vite, sans vérification, se paie tout de suite.

Ce que j'avais fait de juste sans le savoir

En relisant ce billet, une chose me frappe. Mon premier réflexe, en pleine nuit, n'a pas été de faire comme si de rien n'était. J'ai écrit publiquement ce qui s'était passé, ce que j'avais raté et ce que j'en retirais. C'est, sans que je le formule ainsi à l'époque, la base de la gestion d'incident : dire ce qu'on sait, quand on le sait.

Un client qui apprend la panne par votre message la pardonne. Un client qui la découvre tout seul, puis constate votre silence, retient surtout le silence.

Leçon 1 : on ne constate pas une panne, on la mesure

En 2016, j'ai découvert le problème en visitant mon propre site. Autrement dit, j'étais mon seul outil de monitoring. Aujourd'hui, mon site vérifie lui-même ses services en continu et publie le résultat sur une page de statut publique : serveur web, application, base de données, courriel, galeries, avec un historique jour par jour sur 90 jours et la liste des incidents passés.

Une page de statut change deux choses. D'abord, la détection ne dépend plus du hasard d'une visite. Ensuite, la transparence devient vérifiable : quand j'annonce un taux de disponibilité, n'importe qui peut regarder les barres vertes.

Leçon 2 : la sauvegarde se prépare avant, jamais pendant

Détail amusant, le billet de 2016 conseillait déjà « d'effectuer une sauvegarde avant de procéder ». J'avais compris le principe avant d'en mesurer le poids. Une panne de certificat se répare sans perte. Une base de données corrompue, un disque mort ou un piratage, non : là, seule la sauvegarde d'avant l'incident vous sauve.

C'est pour cela que mes formules d'hébergement infogéré incluent d'office les sauvegardes sur 14 jours (30 jours en formule Business), les mises à jour gérées et le monitoring de disponibilité. Pas en option, dans la base. La question à poser à votre hébergeur n'est pas « faites-vous des sauvegardes ? » mais « quand avez-vous testé une restauration pour la dernière fois ? ».

Leçon 3 : la fiabilité se chiffre, puis se prouve

En 2024, à l'Imprimerie Wallonne des Communes, j'ai construit et maintenu l'infrastructure numérique sur laquelle 123 communes belges comptaient pour les élections législatives et communales, dont gebel.be, la plateforme multilingue de gestion des bureaux électoraux. De 2 000 à 4 500 visiteurs par jour, quatre langues, et une obligation simple : tout devait tourner le jour du vote, week-ends et jours fériés compris. La moindre erreur pouvait compromettre le processus électoral d'un pays entier. La plateforme n'est jamais tombée.

Une soirée électorale ne se rejoue pas. Ce genre de projet force à traiter la fiabilité comme une exigence de départ : redondance, surveillance, procédures écrites, et pas d'opération « en un clic » non vérifiée sur un système en production. Exactement l'inverse de ma migration de 2016.

Votre site est en panne : la méthode, dans l'ordre

Si votre site est inaccessible là, maintenant, voici ce que je ferais à votre place.

1. Confirmez la panne. Testez depuis un autre appareil ou en 4G. Si le site répond ailleurs, le problème est de votre côté (cache, DNS local, réseau).
2. Lisez le message d'erreur exact. « Connexion non sécurisée » pointe vers le certificat, comme chez moi en 2016. Une erreur 500 pointe vers l'application, un délai d'attente vers le serveur, une page de parking vers un domaine expiré.
3. Vérifiez les échéances. Nom de domaine et certificat expirés restent des causes de panne banales et évitables.
4. Ne changez qu'une chose à la fois. Notez chaque action. Trois modifications simultanées, c'est trois fois plus de mal à comprendre ce qui a fonctionné.
5. Communiquez tôt. Un message court et honnête à vos clients vaut mieux qu'une heure de silence : « le site est en panne, j'ai identifié la piste, retour prévu vers telle heure ».
6. Restaurez si nécessaire. Si des données sont touchées, repartez de la dernière sauvegarde saine plutôt que de bricoler un système corrompu.
7. Écrivez le post-mortem. Même trois lignes. Mon billet de 2016 en était un, et c'est grâce à lui que je peux écrire celui-ci.

Dix ans entre deux billets

En 2016, une panne de mon blog était un contretemps et une anecdote à raconter. En 2026, une panne chez un client, c'est du chiffre d'affaires qui s'arrête, et mon travail consiste à ce qu'elle soit rare, courte et annoncée. Si votre site vient de tomber, ou si vous voulez qu'une panne ne soit plus jamais une surprise, parlons-en.