Plan de reprise après sinistre : préparer le pire, sereinement

Un plan de reprise après sinistre décrit comment votre site et vos données reviennent en ligne après un incident grave : panne majeure, incendie, ransomware, erreur humaine. Le rédiger avant d'en avoir besoin transforme une crise en procédure à suivre. Voici comment le construire sans s'y perdre.

Sinistre : de quoi parle-t-on ?

Un sinistre, ce n'est pas seulement un serveur qui tombe. C'est tout événement qui rend vos données ou votre service indisponibles durablement : une panne matérielle étendue, une corruption généralisée, un incendie ou une inondation dans le datacenter, une attaque par ransomware qui chiffre vos fichiers, ou une erreur humaine qui supprime l'essentiel.

Ce qui distingue le sinistre de l'incident courant, c'est l'ampleur : on ne redémarre pas une machine, on reconstruit le service à partir des sauvegardes. C'est pour cela qu'un plan s'impose.

RPO et RTO : deux chiffres à définir

Tout plan de reprise repose sur deux objectifs chiffrés.

Le RPO (objectif de point de reprise) est la perte de données maximale acceptable : la durée entre deux sauvegardes que vous acceptez de perdre. Un RPO d'une heure signifie qu'au pire, vous perdez une heure de données. Un RPO de zéro exige une réplication continue.

Le RTO (objectif de durée de reprise) est le temps maximal acceptable pour remettre le service en ligne. Un RTO de quatre heures signifie que vous devez être capable de restaurer en quatre heures.

Ces deux chiffres se décident en fonction de votre activité : une boutique en ligne vise un RPO et un RTO courts, un site vitrine peut se permettre davantage. Ils déterminent ensuite les moyens à mettre en œuvre.

Par exemple, une boutique qui encaisse en continu peut viser un RPO de quelques minutes et un RTO d'une heure, là où un site vitrine se contentera d'un RPO quotidien et d'un RTO d'une journée. Le coût croît avec l'exigence : plus les objectifs sont serrés, plus les moyens sont importants.

Sauvegardes hors site et redondance

Le plan repose d'abord sur les sauvegardes, mais pas n'importe lesquelles. Une sauvegarde stockée sur le même serveur que le sinistre ne sert à rien.

Appliquez la règle 3-2-1 : trois copies, sur deux supports, dont une hors site. La copie hors site est votre dernier recours quand tout le reste est touché. Notre article sur la stratégie de sauvegarde 3-2-1 détaille le principe.

La redondance complète les sauvegardes : un réplica de base de données ou un second serveur réduit le RTO, car il évite de tout reconstruire. Mais la redondance ne remplace pas la sauvegarde : elle ne protège pas contre une corruption logique ou une suppression accidentelle, qui se propagent aux réplicas.

Documenter la restauration

Un plan de reprise écrit vaut mieux qu'une compétence dans la tête d'une seule personne. Documentez précisément :

• où se trouvent les sauvegardes et comment y accéder ;
• l'ordre de restauration : infrastructure, données, configuration, certificats ;
• qui est habilité à déclencher le plan ;
• les points de contact : hébergeur, développeur, responsable.

Si la personne qui sait tout est en congé le jour du sinistre, le plan doit permettre à quelqu'un d'autre de s'en sortir. Notre aide sur la copie de sauvegarde est un bon point de départ, et l'ouverture d'une demande au support vous montre comment solliciter l'hébergeur en urgence.

Une liste de contacts à jour est aussi précieuse que la procédure elle-même : pendant une crise, on n'a pas le temps de chercher qui joindre. Notez aussi la durée de chaque exercice de restauration : elle doit se rapprocher du RTO visé, sinon le plan doit être ajusté.

Tester le plan de reprise régulièrement

Un plan non testé est une théorie. Programmez des exercices réguliers : restaurez une sauvegarde sur un environnement séparé, chronométrez le retour en ligne, et comparez au RTO que vous vous êtes fixé.

Le test révèle ce qui manque : une dépendance non sauvegardée, une procédure périmée, un accès révoqué. Chaque exercice rend le plan plus fiable, et l'équipe plus sereine.

Qui fait quoi pendant la crise

Un plan de reprise est aussi un plan humain. Définissez les rôles à l'avance :

• qui déclare le sinistre et déclenche le plan ;
• qui contacte l'hébergeur et suit la restauration ;
• qui communique aux clients et aux équipes ;
• qui vérifie que le service est réellement rétabli.

Pendant la crise, chacun sait quoi faire au lieu d'improviser. C'est ce qui sépare une reprise maîtrisée d'une pagaille coûteuse.

Savoir réagir quand le site tombe est le premier réflexe : notre article sur les sites en panne couvre la marche à suivre immédiate. Pour les données sensibles, la question de l'hébergement local mérite aussi réflexion : voir notre article sur l'hébergement des données au Maroc.

Pour un hébergement qui place la sauvegarde vérifiée et la restauration documentée au cœur de son offre, découvrez l'offre haute disponibilité d'Atlas Hoster.

Les pièges à éviter

• Confondre redondance et sauvegarde : un réplica ne protège pas contre une suppression accidentelle ni une corruption, qui se propagent automatiquement.
• Garder le plan dans la tête d'une seule personne : si elle est absente le jour du sinistre, la procédure reste inaccessible.
• Ne jamais tester la restauration : un plan non testé est une théorie. Seul un exercice réel prouve qu'il fonctionne.
• Négliger la copie hors site : une sauvegarde dans le même bâtiment disparaît avec le sinistre.

Questions fréquentes

Quelle différence entre RPO et RTO ?

Le RPO mesure la perte de données acceptable (jusqu'où on remonte dans le temps), le RTO mesure la durée d'indisponibilité acceptable (combien de temps pour revenir en ligne). L'un concerne les données, l'autre le service.

La redondance remplace-t-elle les sauvegardes ?

Non. La redondance protège contre la panne matérielle, pas contre la corruption logique ni l'erreur humaine, qui se propagent aux réplicas. Les deux sont nécessaires.

À quelle fréquence tester un plan de reprise ?

Au moins une fois par an, et après chaque changement important d'infrastructure ou d'équipe. Un test régulier est la seule preuve que le plan fonctionne.