Un plan de reprise après sinistre (PRA) n’est pas une collection de sauvegardes. C’est la capacité démontrée à restaurer une application, ses données et ses dépendances dans un délai compatible avec l’activité. Pour une boutique PrestaShop ou un site WordPress, il faut notamment retrouver la base de données, les fichiers envoyés, la configuration, les secrets et les services externes nécessaires au parcours client.
Plutôt que de s’appuyer sur un incident spectaculaire ou un pourcentage non sourcé, partez de scénarios concrets : suppression accidentelle de données, compromission, panne d’un serveur, erreur de déploiement ou indisponibilité d’un fournisseur.
Définir RPO et RTO avec le métier
Le RPO (Recovery Point Objective) exprime la quantité maximale de données que vous acceptez de perdre. Le RTO (Recovery Time Objective) indique le temps maximal acceptable avant le retour du service. Ils ne sont pas des réglages techniques : ils doivent être décidés avec les personnes responsables des commandes, du support et de la comptabilité.
Exemple : si une boutique accepte de perdre au plus une heure de commandes et doit revenir en ligne en quatre heures, la fréquence des sauvegardes, le stockage distant, les étapes de restauration et les accès d’urgence doivent permettre de tenir ces objectifs. Si ce n’est pas mesuré lors d’un exercice, ce ne sont que des intentions.
Inventorier ce qui doit être restauré
Une restauration de fichiers seule ne suffit généralement pas. Votre registre PRA doit inclure :
- base de données et méthode de restauration vérifiée ;
- fichiers applicatifs, médias et fichiers de configuration ;
- variables d’environnement, clés, certificats et accès DNS ;
- version de PHP, extensions, serveur web, tâches planifiées et cache ;
- comptes d’administration et accès aux prestataires ;
- services de paiement, e-mail, CDN, stockage objet et API critiques ;
- personne responsable de chaque étape et canal de communication.
Évitez de conserver des secrets dans un script de sauvegarde ou dans un dépôt. Utilisez le mécanisme de secrets prévu par votre hébergeur ou votre outil d’automatisation, avec des droits minimaux.
Concevoir une sauvegarde réellement restaurable
La règle pratique est de conserver plusieurs copies, sur des supports ou emplacements distincts, avec au moins une copie isolée des comptes de production. Le choix du nombre de copies et de l’immuabilité dépend des risques et du budget ; l’essentiel est de pouvoir vérifier l’intégrité et de restaurer.
Pour MySQL ou MariaDB, un export cohérent est utile, mais le bon format dépend de la taille de la base, de l’objectif de restauration et de l’outil utilisé. Testez la restauration dans une base distincte avant de déclarer une sauvegarde valide. Faites de même avec les médias et la configuration applicative.
| Composant | Échec fréquent | Vérification utile |
|---|---|---|
| Base de données | Export incomplet ou non restaurable | Import dans un environnement isolé |
| Médias | Sauvegarde sans fichiers uploads | Contrôle du volume et de quelques fichiers |
| Configuration | Secret ou variable manquante | Démarrage de l’application restaurée |
| DNS et certificats | Bascule non documentée | Exercice avec responsable désigné |
| Paiement et e-mail | Webhooks ou clés absents | Parcours de test sans transaction réelle |
Exécuter un exercice de reprise
Un exercice doit produire une preuve : heure de départ, données utilisées, étapes suivies, durée réelle, erreurs, responsable et actions correctives. Commencez avec une restauration isolée, puis réalisez à intervalle défini un exercice plus proche d’une bascule réelle.
Une séquence simple :
- choisissez un scénario et annoncez le périmètre de l’exercice ;
- restaurez la base, les fichiers et la configuration dans un environnement non public ;
- vérifiez connexion, panier, administration, e-mails et tâches planifiées ;
- mesurez le délai et comparez-le au RTO fixé ;
- documentez chaque blocage et corrigez le plan ;
- mettez à jour la date de test, les accès d’urgence et les contacts.
La réplication et une infrastructure redondante peuvent réduire l’indisponibilité, mais elles ne remplacent pas une sauvegarde isolée : une suppression ou une compromission peut se répliquer elle aussi.
Associer le PRA à la sécurité quotidienne
Le PRA limite les conséquences d’un incident ; il ne remplace ni les mises à jour ni le contrôle des accès. Pour les diagnostics applicatifs, consultez aussi notre guide pour diagnostiquer une erreur 500 avec Nginx, les logs et une assistance IA. Pour une migration de serveur, le guide migrer un serveur e-commerce vers une nouvelle version Linux et PHP aide à préparer les dépendances à inclure dans le plan de retour.
L’ANSSI publie des recommandations de continuité et de reprise d’activité qui peuvent servir de cadre pour formaliser les responsabilités et les exercices.
Questions fréquentes
Un CDN suffit-il en cas de sinistre ?
Non. Il peut servir des contenus en cache, mais ne restaure ni la base de données, ni les commandes, ni l’administration de l’application.
À quelle fréquence faut-il tester ?
La fréquence dépend des changements et des objectifs métier. Testez après une évolution majeure de l’infrastructure ou de l’application, et planifiez des exercices réguliers suffisamment complets pour valider le RPO et le RTO.
Une réplication est-elle une sauvegarde ?
Non. La réplication améliore la disponibilité, mais elle peut propager une corruption ou une suppression. Conservez des sauvegardes séparées et testées.
