Plan de reprise d'activité site web : RTO, RPO et runbooks pour agences

Plan de reprise d'activité site web : RTO, RPO et runbooks pour agences

Un site client hors ligne génère des appels, des annulations de commandes et du stress — pour votre client et pour votre équipe. Un plan de reprise d'activité (PRA) définit à l'avance les décisions à prendre et les commandes à exécuter pour que cette interruption dure le moins longtemps possible. Sans PRA documenté, chaque incident se règle à l'improviste, sous pression, avec un risque d'erreur proportionnel au chaos ambiant.

Ce guide vous donne les définitions opérationnelles (RTO, RPO, PRA vs PCA), une architecture de sauvegarde compatible avec une reprise rapide, et deux runbooks complets : un pour un piratage, un pour une panne hébergeur. Contrairement aux guides théoriques existants, chaque étape indique les actions concrètes et les délais cibles.

1. RTO et RPO : les deux métriques de votre PRA
2. Quatre scénarios à couvrir
3. Architecture de sauvegarde compatible PRA rapide
4. Runbook 1 — Reprise après piratage
5. Runbook 2 — Reprise après panne hébergeur
6. Documentation et exercices en agence

RTO et RPO : les deux métriques de votre PRA

Tout PRA repose sur deux chiffres que vous fixez avant l'incident, pas pendant.

RTO (Recovery Time Objective)

Le RTO est la durée maximale acceptable entre la détection de l'incident et la reprise du service. Il se fixe selon l'impact métier du site :

• Site vitrine : RTO de 4 à 8 heures — une demi-journée d'inaccessibilité est rarement fatale pour l'activité.
• Boutique e-commerce : RTO de 1 à 2 heures — chaque heure hors ligne se traduit directement en commandes non prises.
• Application sur mesure (SaaS, portail client) : RTO de 15 à 30 minutes — les utilisateurs métier sont bloqués dans leurs tâches.

RPO (Recovery Point Objective)

Le RPO est la perte de données maximale acceptable : l'écart entre le dernier point de sauvegarde valide et le moment de l'incident. Il dépend directement de la fréquence des sauvegardes :

• Sauvegarde quotidienne → RPO de 24 heures : une journée entière de données peut disparaître.
• Sauvegarde toutes les heures → RPO de 1 heure.
• Sauvegarde toutes les 15 minutes → RPO quasi nul.

Pour un blog ou une vitrine dont le contenu est rarement modifié, un RPO de 24 heures est acceptable. Pour une boutique enregistrant des commandes en continu, un RPO de 1 heure est le minimum raisonnable.

PRA et PCA : deux documents distincts

Le PRA (plan de reprise d'activité) cible la restauration technique des systèmes après une défaillance : bases de données, fichiers, configuration serveur. Le PCA (plan de continuité d'activité) est plus large : il englobe le PRA mais ajoute les processus métier, la communication externe, les ressources humaines et les enjeux légaux.

Pour une agence web gérant un parc de sites clients, le PRA suffit dans la grande majorité des incidents. Le PCA s'impose surtout aux entreprises dont le site est le cœur même de l'activité — un SaaS en production, un e-commerce à fort volume, une plateforme métier critique.

Quatre scénarios à couvrir

Un PRA web doit anticiper au minimum ces quatre types d'incident :

1. Piratage complet : prise de contrôle du site, défacement, injection de code malveillant. Ce scénario exige une investigation avant restauration — remettre en ligne sans identifier le vecteur d'entrée reviendrait à livrer le même site avec la même faille ouverte.
2. Panne hébergeur : serveur hors ligne, datacenter inaccessible, panne réseau chez le prestataire. Ce scénario est indépendant de toute faute de votre part, mais c'est votre agence qui reçoit les appels de vos clients.
3. Suppression accidentelle de données : base de données écrasée lors d'une migration, répertoire effacé par erreur. Scénario fréquent, généralement résolu par un rollback depuis la dernière sauvegarde.
4. Erreur lors d'une mise à jour : extension ou thème qui rend le site inaccessible après application. Un retour à la version précédente suffit dans la plupart des cas.

Les runbooks ci-dessous couvrent les deux scénarios les plus impactants et les plus longs à résoudre : le piratage et la panne hébergeur. Pour les deux autres, un rollback depuis votre dernière sauvegarde résout l'incident dans la grande majorité des situations.

Architecture de sauvegarde compatible PRA rapide

Un PRA n'est solide que si les sauvegardes sont fiables, récentes et testées. L'architecture conditionne directement le RPO atteignable et la durée de restauration lors d'un incident réel.

La règle 3-2-1

La règle 3-2-1 est le standard de toute stratégie de sauvegarde sérieuse :

• 3 copies de vos données (la production + deux sauvegardes indépendantes)
• sur 2 supports différents (disque local du serveur + stockage objet distant, par exemple)
• dont 1 copie hors site (stockage cloud dans un datacenter distinct de votre hébergeur principal)

La règle 3-2-1 garantit qu'un incident chez l'hébergeur n'emporte pas simultanément votre production et vos sauvegardes.

La copie hors site est la plus souvent négligée, et c'est pourtant elle qui vous sauve lors d'une compromission totale du serveur ou d'une panne d'infrastructure. Pour aller plus loin sur la fréquence et la rétention, consultez le guide sur la stratégie GFS pour les sauvegardes de sites web.

Fréquence de sauvegarde selon la criticité

Type de site	Base de données	Fichiers	RPO résultant
Site vitrine	Quotidienne	Quotidienne	24 heures
Boutique e-commerce	Toutes les heures	Quotidienne	1 heure (BDD)
Application sur mesure	Toutes les 15 min	Quotidienne	15 minutes (BDD)

Test de restauration mensuel

Une sauvegarde non testée est une sauvegarde dont on ignore si elle fonctionne réellement. Planifiez un test de restauration chaque mois sur un environnement isolé : restaurez la base, vérifiez l'intégrité des données, mesurez le temps effectif. Ce temps est votre RTO réel — si la restauration prend 3 heures, vous ne pouvez pas garantir un RTO de 2 heures à votre client.

Sentinelo vérifie chaque archive sauvegardée par empreinte SHA-256 et vérification post-stockage. Le test de restauration applicative — vérifier que le site fonctionne correctement après restauration — reste votre responsabilité en tant qu'agence.

Runbook 1 — Reprise après piratage (objectif < 4 heures)

Ce runbook s'applique dès que vous suspectez une intrusion : pages modifiées, redirections inattendues, alerte de votre scanner de sécurité, signalement d'un client. Le guide d'audit et de durcissement WordPress pour agences détaille comment qualifier le type d'intrusion avant de lancer la restauration.

Étape 1 — Isolation immédiate (objectif : moins de 15 minutes après détection)

1. Passer le site en mode maintenance : servir une page statique sans exécution PHP. Cela protège les visiteurs et interrompt l'exécution de code malveillant potentiellement actif.
2. Exporter les logs avant toute intervention : logs d'accès serveur, logs d'erreurs, logs applicatifs, logs de base de données. Les supprimer lors du nettoyage est l'erreur la plus courante. Copiez-les sur un support hors du serveur compromis.
3. Révoquer les accès suspects : désactiver les comptes administrateur créés récemment, changer le mot de passe de la base de données pour bloquer toute connexion active.
4. Informer l'hébergeur : certains peuvent isoler le serveur au niveau réseau si l'intrusion est critique.

Étape 2 — Qualification de l'incident (15 minutes à 1 heure)

1. Identifier le vecteur d'entrée dans les logs : extension vulnérable exploitée, upload de fichier malveillant, identifiant administrateur compromis, exploit sur le core CMS.
2. Dater l'intrusion : cherchez dans les logs la première requête anormale ou le premier fichier modifié. Cette date délimite la sauvegarde saine à utiliser pour la restauration.
3. Évaluer le périmètre : d'autres sites hébergés sur le même serveur ou le même compte mutualisé peuvent être touchés.
4. Déterminer si des données personnelles ont été exfiltrées. En cas de doute, la déclaration à la CNIL est obligatoire dans les 72 heures suivant la détection, conformément à l'article 33 du RGPD.

Étape 3 — Restauration depuis une sauvegarde saine (1 heure à 3 heures)

1. Sélectionner la sauvegarde immédiatement antérieure à la date d'intrusion identifiée à l'étape précédente. Utiliser une sauvegarde postérieure à l'intrusion restaurerait le même code compromis.
2. Restaurer sur un environnement de staging isolé si le délai le permet. Vérifier que le site fonctionne correctement avant de remettre en production.
3. Scanner le site restauré avant remise en ligne : un piratage laisse parfois des backdoors dans des fichiers présents avant l'intrusion et que la restauration réintroduit.
4. Remettre en production et désactiver le mode maintenance.

Étape 4 — Durcissement post-incident (3 heures à 4 heures)

1. Rotation complète des mots de passe : compte administrateur CMS, base de données, accès FTP/SSH, interface hébergeur, registrar DNS.
2. Rotation de toutes les clés API actives sur le site.
3. Mise à jour immédiate du CMS, de toutes les extensions et du thème.
4. Fermer le vecteur d'entrée identifié : supprimer l'extension vulnérable, corriger les permissions de fichiers, activer un pare-feu applicatif si votre hébergeur en propose un.
5. Rédiger un rapport d'incident : date, vecteur, durée d'exposition, mesures prises, données potentiellement touchées. Ce document est utile pour la CNIL si une notification est requise et pour améliorer votre PRA.

Le CERT-FR publie une fiche de bons réflexes en cas d'intrusion sur un système d'information qui complète ce runbook pour les incidents plus complexes impliquant une infrastructure étendue.

Runbook 2 — Reprise après panne hébergeur (objectif < 2 heures)

Ce runbook s'applique quand votre monitoring détecte un site hors ligne et que l'hébergeur confirme une panne de son infrastructure — ou quand la durée de résolution annoncée dépasse votre RTO. Pour être alerté avant vos clients, consultez notre guide sur la supervision de l'uptime sur un parc de sites clients.

Étape 1 — Diagnostic rapide (objectif : moins de 15 minutes)

1. Consulter la page de statut de l'hébergeur pour confirmer la panne et obtenir une estimation de résolution.
2. Vérifier depuis plusieurs points géographiques que le problème est bien côté serveur et non DNS (entrée expirée, propagation en cours) ou SSL (certificat expiré).
3. Décider entre attendre ou activer la procédure de migration d'urgence. Si le délai annoncé par l'hébergeur est inférieur à votre RTO, attendre est souvent la meilleure décision. Dans le cas contraire, activez le runbook sans délai.

Étape 2 — Déploiement sur hébergeur de secours (15 minutes à 1 heure)

1. Provisionner un serveur de secours chez un hébergeur différent. Bonne pratique : préparer ce serveur en avance avec les mêmes versions de PHP, MySQL et serveur web que votre environnement de production. Cela réduit le délai de déploiement de 1 heure à 15 minutes.
2. Déployer les fichiers depuis la dernière sauvegarde disponible.
3. Restaurer la base de données depuis la dernière sauvegarde disponible.
4. Configurer les variables d'environnement et les fichiers de configuration : chaîne de connexion BDD, clés API, chemins d'accès aux fichiers.
5. Tester le site directement sur l'adresse IP du serveur de secours avant toute modification DNS. Vérifier les pages critiques : accueil, checkout si boutique, formulaires de contact.

Étape 3 — Bascule DNS (5 minutes de manipulation, propagation variable)

1. Modifier les enregistrements A (et AAAA pour IPv6) pour pointer vers la nouvelle adresse IP.
2. Réduire le TTL à 300 secondes le temps de la bascule, pour permettre un retour en arrière rapide si nécessaire.
3. La durée de propagation dépend du TTL en vigueur au moment de la modification : environ 30 minutes si le TTL était déjà court (300 s), jusqu'à 48 heures si le TTL était à sa valeur par défaut (3 600 s ou plus).
4. Surveiller la propagation avec la commande dig @8.8.8.8 votre-domaine.fr A depuis un terminal ou via un service de monitoring DNS en ligne.

Bonne pratique préventive : réduire le TTL de votre zone DNS à 300 secondes au moins 24 heures avant toute opération de maintenance planifiée. En dehors des maintenances, un TTL de 3 600 secondes est un bon compromis entre réactivité et charge sur les résolveurs.

Étape 4 — Communication client (objectif : moins de 30 minutes après détection)

Envoyez un premier message dès que la panne est confirmée, même sans estimation précise de résolution. Les clients tolèrent mieux une interruption avec communication qu'une interruption silencieuse.

Modèle de message initial :

Objet : [Nom du site] — Incident en cours, suivi en temps réel

Votre site [nom] est inaccessible depuis [heure]. Nous avons identifié une panne côté hébergeur et avons activé notre procédure de migration d'urgence. Prochain point d'information dans 30 minutes.

Documentation et exercices en agence

Le runbook : court et opérationnel

Un runbook n'est pas un manuel de 40 pages. C'est un document court — deux à cinq pages maximum — que n'importe quel membre de l'équipe peut suivre à 23 heures sous pression, sans chercher d'informations annexes. Chaque étape doit comporter : l'action à exécuter, l'outil ou la commande, le délai cible, et le critère de passage à l'étape suivante.

Matrice d'escalade

Le runbook doit indiquer qui contacter à chaque niveau :

• Niveau 1 (0 à 15 min) : la personne d'astreinte, qui exécute le runbook.
• Niveau 2 (15 à 60 min) : le responsable technique de l'agence, si le niveau 1 est bloqué ou débordé.
• Niveau 3 (au-delà de 1 heure ou données compromises) : hébergeur, éditeur du CMS, CERT-FR, DPO.

Ces contacts doivent figurer dans le runbook avec leurs coordonnées directes — pas seulement dans un annuaire interne accessible uniquement depuis un poste connecté au réseau de l'agence.

Exercice trimestriel

Un PRA non testé est un PRA dont vous découvrirez les lacunes lors d'un incident réel. Organisez un exercice trimestriel : simulez une panne sur un site de test, exécutez le runbook de bout en bout, mesurez le temps réel de chaque étape. Chaque exercice révèle des lacunes concrètes — une version PHP incompatible sur le serveur de secours, un mot de passe introuvable, un accès FTP révoqué depuis la dernière révision. Corrigez-les avant l'incident.

Votre PRA est un document vivant : révisez-le après chaque exercice, après chaque incident réel, et à chaque changement de technologie ou d'hébergeur sur votre parc. Pour centraliser les sauvegardes, le chiffrement et la vérification d'intégrité sur l'ensemble de vos sites clients, la plateforme Sentinelo fournit les archives sur lesquelles s'appuie votre PRA à chaque restauration.