Une campagne bien préparée peut partir en fumée en quelques minutes. Pas à cause d’un mauvais ciblage ou d’un budget mal calibré, mais parce que le site est inaccessible au moment précis où les visiteurs arrivent. Le 19 juillet 2024, une panne mondiale a coupé des millions de clients de nombreuses entreprises, rappelant que personne n’est à l’abri. Anticiper ce scénario, c’est décider à l’avance qui fait quoi, comment on prévient les clients et par quel moyen on remet le service en ligne.
Une panne n’arrive jamais au bon moment
Le scénario classique : vous lancez une opération commerciale, les premières visites arrivent, puis le serveur ne répond plus. Le 19 juillet 2024, une mise à jour de CrowdStrike a paralysé des postes sous Windows dans le monde entier, et des entreprises entières se sont retrouvées bloquées sans avoir rien changé à leur infrastructure. Un cas d’école que beaucoup d’équipes techniques citent encore aujourd’hui en réunion. Qui pouvait continuer à travailler pendant que les autres attendaient ?
Le problème, c’est que la plupart des équipes découvrent la panne par un client mécontent, pas par leur propre surveillance. Un site peut tomber pour mille raisons : un certificat expiré, une base de données saturée, un hébergeur en incident, ou un simple plugin mis à jour trop vite. La détection tardive coûte cher, parce que chaque minute d’indisponibilité pendant une campagne brûle du budget publicitaire pour envoyer du trafic vers une page d’erreur. Ce constat revient dans presque tous les retours d’expérience.
Un outil comme TotalBug surveille de nombreux services afin de tenir informé des éventuelles pannes ou bugs, et fournit les coordonnées pour faire une réclamation ainsi que les causes des incidents si elles sont connues. Ce genre de ressource ne remplace pas votre propre supervision. Il vous évite en revanche de chercher pendant une heure si le problème vient de chez vous ou d’un prestataire.
Détecter avant que le client ne vous appelle
La première brique d’un plan de continuité tient en une question simple : comment saurez-vous que le site est tombé ? Si la réponse est « un collègue me préviendra », il manque quelque chose. Une sonde qui teste la page d’accueil toutes les minutes, une alerte sur le taux d’erreur serveur, un contrôle du tunnel de commande : trois vérifications suffisent à repérer la majorité des coupures avant le premier appel mécontent.
L’outil d’audit SEO mentionné propose de scanner un site pour plus de 300 problèmes techniques et de surveiller la santé d’un site 24/7. Ce type de surveillance continue repère aussi bien une lenteur anormale qu’une page qui renvoie une erreur, et il envoie l’alerte au bon endroit. Un site de référencement comme referencement-site-entreprise.com explique d’ailleurs pourquoi une panne pendant une campagne ne se rattrape presque jamais sur le plan budgétaire.
Reste à définir qui reçoit l’alerte. Une astreinte à une personne, c’est une astreinte qui saute un week-end sur deux. Prévoyez au moins deux destinataires, avec un canal qui ne dépend pas de votre hébergeur : si le datacenter tombe, votre boîte mail professionnelle tombe souvent avec lui. Un groupe de discussion sur téléphone fait très bien l’affaire pour ce rôle.
Communiquer vite, même sans savoir
Quand un site tombe, le silence fait plus de dégâts que la panne elle-même. Les clients qui découvrent une page blanche sans explication imaginent le pire, et certains écrivent publiquement ce qu’ils pensent. Un message court, publié sur une page que vous contrôlez ailleurs (réseau social, page d’état hébergée sur un autre domaine), suffit à calmer l’inquiétude. Quelques mots simples rassurent plus qu’un long communiqué technique.
Cette page d’état ne doit pas vivre sur le même serveur que le site principal, sinon elle disparaît en même temps. C’est le genre de détail qu’on ne pense jamais à vérifier avant la première vraie coupure. Préparez-la à l’avance, avec un modèle de texte prêt à publier, et le nom de la personne qui a le droit de la mettre à jour. Sur ce point, voir aussi notre article sur site developpeur panne.
Il y a aussi ce qu’il ne faut pas faire : promettre un délai de rétablissement que vous ne pouvez pas tenir. Une entreprise qui annonce « retour à la normale dans trente minutes » et qui met six heures à revenir perd davantage de confiance qu’une entreprise qui reste vague mais honnête. La panne Avast qui a bloqué l’accès au site caf.fr a montré à quel point un incident peut toucher des services que personne n’imaginait concernés.
Ce que les équipes oublient dans leur scénario de secours
Les plans de reprise tournent souvent autour du serveur, comme si tout se jouait là. En pratique, d’autres points lâchent bien plus fréquemment, et personne ne les a écrits nulle part. Ces angles morts coûtent pourtant les heures les plus précieuses d’un incident.
- Le numéro de téléphone de l’hébergeur, rangé dans une boîte mail à laquelle plus personne n’a accès.
- Qui a le droit de parler publiquement au nom de la marque en cas de crise ?
- La sauvegarde existe, mais personne n’a jamais testé une restauration complète.
- Le budget publicitaire continue de tourner pendant la panne et envoie du trafic vers une page d’erreur.
- Un second domaine prêt à prendre le relais, mais dont la configuration n’a jamais été vérifiée.
Chacun de ces points se règle en moins d’une heure quand tout va bien, et coûte des jours entiers quand tout va mal. C’est typiquement le genre de tâche repoussée parce qu’elle n’a jamais d’échéance visible, jusqu’au jour où elle en a une. Le 12 avril 2023, un article de BFMTV citait TotalBug à propos d’un bug de Météo France, preuve qu’une panne touche parfois un service que des millions de gens consultent chaque matin sans imaginer qu’il puisse s’arrêter.
Reprendre le contrôle en moins d’une heure
La phase de résolution repose sur une règle : savoir revenir en arrière. Avant chaque mise à jour importante, notez la version en place et la procédure de retour arrière, pour pouvoir annuler un changement en quelques minutes plutôt que de chercher la cause pendant des heures. Beaucoup d’incidents viennent d’une modification récente.
Gardez aussi une version statique du site, même sommaire, avec les informations de contact et un message d’excuse. Un serveur de secours qui affiche trois pages coûte une fraction du prix d’un site complet, et il garde la marque joignable quand l’infrastructure principale ne répond plus. C’est laid, mais c’est infiniment mieux qu’un écran blanc.
Après le retour à la normale, prenez trente minutes pour écrire ce qui s’est passé, à froid. La chronologie, la cause, ce qui a bien fonctionné, ce qui a manqué. Ce document vaut plus que n’importe quel audit théorique, parce qu’il décrit votre système réel, celui qui a réellement tenu ou lâché sous pression.
Un plan B se prépare le jour où tout va bien
Personne n’aime consacrer du temps à un scénario qui n’arrivera peut-être jamais, et c’est exactement pour cette raison que la plupart des sites se font surprendre. Les pannes de CrowdStrike, d’Avast ou de Météo France racontent toutes la même histoire : celles et ceux qui avaient un plan ont limité les dégâts, les autres ont improvisé en direct devant leurs clients.
La différence ne tient pas au budget ni à la taille de l’équipe, mais au fait d’avoir écrit les choses à l’avance et de les avoir testées une fois pour de vrai. Votre entreprise saurait-elle quoi faire, précisément, si le site disparaissait demain matin pendant votre plus grosse campagne de l’année ?