Votre boutique en ligne est en panne : un plan de continuité pour savoir quoi faire

Toutes les boutiques tombent un jour en panne. Le serveur manque d'espace disque, une mise à jour automatique de l'hébergeur change la version de PHP, un module plante après une modification, le domaine expire ou une attaque rend le site inutilisable. Ce qui distingue une panne d'une heure d'une panne d'une journée n'est généralement pas la gravité de l'incident, mais le degré de préparation de l'équipe : si elle savait comment être prévenue, qui appeler et quoi faire.

Un plan de continuité n'a pas besoin d'être un document de cent pages. Pour une boutique en ligne, une ou deux pages qui répondent à quelques questions avant qu'on en ait besoin suffisent.

1. Comment vous êtes prévenu

La pire façon de l'apprendre, c'est par un client, et la deuxième pire, le lendemain. Il vous faut au minimum :

• Une surveillance externe qui interroge la page d'accueil et quelques pages clés toutes les quelques minutes depuis l'extérieur de votre serveur, et qui vous alerte si elle ne répond pas ou répond par une erreur. Elle doit être externe : si le serveur tombe, une surveillance installée dessus tombe avec lui.
• Des alertes d'erreurs depuis l'intérieur de la boutique, pour les pannes qui ne font pas tomber la page d'accueil mais cassent quelque chose : le checkout, le retour d'une passerelle de paiement, une page précise.
• Des alertes d'expiration du domaine et du certificat SSL. Ce sont des pannes totalement évitables.

Et décidez qui reçoit les alertes. Une alerte qui arrive dans une boîte que personne ne lit la nuit ne sert à rien.

2. De quel type de panne s'agit-il

Les premières minutes servent à classer, car chaque type a son responsable :

• Rien ne répond (ni la boutique ni les autres sites du même serveur) : serveur, réseau ou DNS. C'est l'affaire de l'hébergeur ou du fournisseur du domaine.
• Erreur 500 ou page blanche : presque toujours une erreur PHP dans la boutique. Une modification récente, un module, la version de PHP, le disque plein ou la base de données.
• Erreur de base de données : le serveur de base de données est en panne ou saturé, ou les identifiants ont changé.
• Elle fonctionne, mais quelque chose ne va pas : impossible de payer, les produits ne s'ajoutent pas au panier, la boutique affiche un contenu étrange. Cela peut être la panne d'un module ou, dans le pire des cas, une intrusion.
• Elle fonctionne, mais très lentement : pics de trafic, robots, tâche lourde ou manque de ressources.

3. Qui vous appelez

Rédigez une liste avec le nom, le moyen de contact et les horaires pour :

• L'hébergeur : numéro client, comment ouvrir un ticket urgent et ce que couvre son support.
• Le fournisseur du domaine et du DNS, s'il est différent de l'hébergeur.
• La personne qui maintient la boutique : votre développeur ou l'entreprise qui assure votre support.
• Les passerelles de paiement, au cas où le problème viendrait d'elles ou si vous devez vérifier des encaissements.
• La personne qui décide au sein de votre équipe : si l'on restaure une sauvegarde, si l'on passe la boutique en maintenance, ce que l'on communique.

Conservez cette liste en dehors de la boutique et de la messagerie du domaine. Si le serveur tombe et que votre messagerie y est hébergée, vous ne pourrez pas la consulter.

4. Accès et sauvegardes, vérifiés à l'avance

En pleine panne, ce n'est pas le moment de découvrir que personne n'a le mot de passe du panneau d'hébergement ou que la dernière sauvegarde date d'un mois. Vérifiez à l'avance :

• Que les personnes qui doivent intervenir ont accès au panneau d'hébergement, au FTP ou au SSH, à la base de données et au back-office.
• Qu'il existe des sauvegardes récentes des fichiers et de la base de données, stockées en dehors du serveur de la boutique.
• Que quelqu'un a déjà restauré une sauvegarde et sait combien de temps cela prend. Une sauvegarde jamais testée est un espoir, pas un plan.
• Ce qu'il advient des commandes passées entre la dernière sauvegarde et la panne s'il faut restaurer : où les consulter (passerelle, e-mails de confirmation, ERP) et comment les récupérer.

5. Ce que vous faites pendant la réparation

Maintenance avec message

Si la boutique répond mais présente des pannes, il vaut souvent mieux la passer en maintenance avec un message clair que de laisser les clients tomber sur des erreurs ou, pire, payer sans que la commande soit créée.

Paiements

Vérifiez dans la passerelle les encaissements de la période concernée et comparez-les avec les commandes. Les encaissements sans commande doivent être traités un par un : créer la commande ou rembourser.

Communication

• Aux clients : un message bref sur les réseaux sociaux ou dans l'avis de maintenance lui-même, sans promettre des délais que vous ne pouvez pas tenir.
• Aux clients ayant une commande en cours, si la panne affecte les expéditions ou les délais.
• Au service client, avec ce qu'il doit répondre en cas d'appel.

S'il y a des signes d'intrusion dans la boutique et que des données personnelles ont pu être touchées, la situation change : il faut évaluer les obligations de notification du RGPD avec la personne qui vous conseille en protection des données, et ne pas restaurer de sauvegarde sans avoir d'abord fermé la porte d'entrée.

6. Après : quoi consigner

Quand la boutique est rétablie, le travail n'est pas terminé. Notez :

• Quand la panne a commencé, quand vous l'avez apprise et quand elle a été résolue. L'écart entre les deux premières heures mesure l'efficacité de votre surveillance.
• Ce qui l'a causée et ce qui a été fait.
• Ce qui a manqué : un accès, une sauvegarde, un numéro de téléphone.
• Ce que vous changez pour qu'elle ne se reproduise pas : une mise à jour en attente, plus d'espace disque, un module à retirer, une surveillance à ajouter.

Beaucoup de pannes se répètent parce que personne n'en note la cause. Et beaucoup s'évitent avec les bonnes pratiques habituelles : boutique, PHP et modules à jour, testés sur une copie avant de les modifier en production.

Comment le résoudre dans PrestaShop

RKR Sentinel surveille la boutique de l'intérieur et vous alerte sur Telegram en cas d'erreurs PHP, d'exceptions, d'erreurs fatales, de mémoire épuisée, de délais dépassés et de réponses 500, avec le message, le fichier et la ligne, l'URL et les versions ; il capture aussi les erreurs JavaScript du checkout et surveille les paiements qui n'aboutissent pas à une commande ou dont le montant ne correspond pas. Il regroupe les répétitions pour ne pas inonder votre téléphone et masque cartes, IBAN, jetons et mots de passe avant tout envoi. N'oubliez pas qu'il a besoin que la boutique réponde : pour les pannes complètes du serveur, combinez-le avec une surveillance externe. Et si vous cherchez un hébergement pensé pour PrestaShop, le Hosting plan profesional de Rekire est notre proposition pour les boutiques qui veulent ne plus se soucier du serveur.