Reprise après sinistre pour un site autonome : définitions RTO/RPO, procédure de reprise et exercice annuel

Niveaux RTO/RPO et exercice annuel : la procédure de reprise en quatre étapes

Reprise après sinistre pour un site autonome : définitions RTO/RPO, procédure de reprise et exercice annuel

Conclusion d’abord : Les deux indicateurs clés de la reprise après sinistre sont le RTO (objectif de temps de reprise) et le RPO (objectif de point de reprise). Pour la plupart des sites B2B autonomes, un RTO de 4 heures et un RPO de 4 heures sont raisonnables : inutile de viser 99,99 % de disponibilité, un niveau réservé à l’e-commerce et au paiement, dont le coût grimpe de façon exponentielle. La procédure de reprise se fait en quatre étapes : basculer le trafic vers le serveur de secours, restaurer la base de données et les fichiers depuis la sauvegarde, vérifier le formulaire de contact et l’acheminement des e-mails, puis rebasculer vers le site principal. Faites l’exercice au moins une fois par an, en chronométrant chaque étape : si le RTO/RPO réel dépasse l’objectif, il faut revoir le plan.

1. RTO et RPO : commencez par déterminer combien de données vous pouvez perdre et combien de temps vous pouvez rester hors ligne

Le RTO (Recovery Time Objective, objectif de temps de reprise) est le délai maximal acceptable entre la panne et le rétablissement du service. Le RPO (Recovery Point Objective, objectif de point de reprise) est l’ancienneté maximale des données que vous acceptez de perdre après la reprise. Une fois ces deux chiffres fixés, la fréquence de sauvegarde et le budget de secours le sont aussi : c’est un arbitrage entre coût et disponibilité.

Un constat contre-intuitif : pour un site B2B autonome, viser 99,99 % de disponibilité est un surinvestissement. Un site B2B reçoit peu de visiteurs et ses demandes passent surtout par e-mail et formulaire ; une coupure de 4 heures ou de 1 heure change peu de chose pour l’activité, alors que le coût du plan de secours, lui, explose : atteindre un RTO de 15 minutes exige deux salles serveurs actives et une synchronisation de base de données en temps réel, soit un coût mensuel 5 à 10 fois supérieur à une solution mono-site.

Type de site	Objectif RTO	Objectif RPO	Disponibilité	Plan de secours
Site de demandes critiques	≤ 1 heure	≤ 15 minutes	99,9 %	Serveur de secours distant + synchronisation binlog en temps réel
Site B2B standard	≤ 4 heures	≤ 4 heures	99,5 %	Mono-site + sauvegarde quotidienne + restauration à distance
Blog / site de contenu	≤ 24 heures	≤ 24 heures	99 %	Sauvegarde hebdomadaire + restauration manuelle
Site e-commerce / paiement	≤ 15 minutes	≤ 1 minute	99,99 %	Multi-actif + synchronisation en temps réel (coût très élevé)

Exemple concret : un site d’équipement industriel à l’export, environ 30 demandes par mois, panier moyen de 500 000 yuans. Une coupure de 4 heures représente, au rythme des demandes, 1 à 2 demandes perdues : la perte reste limitée. Pour ce type de site, un mono-site avec sauvegarde quotidienne, un RTO de 4 heures et un RPO de 4 heures suffisent, pour un coût de secours inférieur à 200 yuans par mois. En imposant une architecture multi-actif, les 2 000 yuans mensuels supplémentaires achètent une disponibilité sans retour mesurable pour l’activité.

Pour savoir dans quelle catégorie classer votre site, regardez d’abord le nombre de demandes par mois et le panier moyen : au-delà de 100 demandes par mois avec un panier inférieur à 10 000 yuans, le site tire vers l’e-commerce et le RTO doit descendre à 1 heure ; en dessous de 30 demandes par mois avec un panier supérieur à 100 000 yuans, il tire vers le projet et un RTO de 4 heures est tout à fait acceptable.

2. Procédure de reprise : quatre étapes à écrire sur papier à l’avance

Un plan de reprise après sinistre ne peut pas rester dans la tête. Quand l’incident survient, la personne concernée peut être réveillée à 3 h du matin, en déplacement, ou ne pas être la plus familière avec le système. Le plan doit être un document écrit, avec des étapes précises au niveau de la ligne de commande : qui fait quoi et à quel moment, sans ambiguïté.

Procédure de reprise standard en quatre étapes : première étape, basculer le trafic en changeant le DNS ou le CDN vers l’IP du serveur de secours ; deuxième étape, restaurer les données en récupérant la sauvegarde la plus récente depuis le stockage objet hors site, puis restaurer les fichiers et la base de données ; troisième étape, vérifier en parcourant la page d’accueil, la liste des produits, la soumission du formulaire de demande et la réception des e-mails ; quatrième étape, informer les parties prenantes : ventes, support et direction sont synchronisés sur l’heure de rétablissement du site. Pour la procédure spéciale après un piratage, voir Après un piratage de site.

Étape	Action	Direction	Durée estimée	Critères de validation
1 Confirmation de l’incident	Alerte de surveillance déclenchée, confirmation de l’indisponibilité du site principal	Ingénieur d’astreinte	5 minutes	3 échecs de détection consécutifs
2 Bascule du trafic	TTL DNS abaissé à 60 secondes, bascule vers l’IP du serveur de secours	Maintenance	10 minutes	Propagation DNS mondiale
3 Restauration des données	Récupération de la sauvegarde depuis S3, restauration des fichiers et de la base de données	Maintenance	1 à 2 heures	Site accessible
4 Vérification fonctionnelle	Parcours complet : accueil, pages produits, formulaire de demande	Ingénieur + ventes	30 minutes	E-mail de soumission du formulaire reçu
5 Notification	Les ventes et le support savent que le site est rétabli	Responsable marketing	10 minutes	Notification envoyée dans le groupe
6 Bilan	Rédiger le rapport d’incident sous 24 heures	Responsable technique	1 jour ouvré	Cause racine et axes d’amélioration

Exemple concret : un site d’export reçoit une alerte à 3 h du matin, le site principal renvoie une erreur 502. L’ingénieur d’astreinte suit le plan : première étape, il confirme un crash de MySQL, le redémarrage ne fonctionne pas ; deuxième étape, il bascule le DNS vers le serveur de secours, le TTL ayant été réglé à 60 secondes à l’avance, la propagation mondiale prend 10 minutes ; troisième étape, il récupère la sauvegarde de la veille au soir depuis S3 et restaure la base de données en 40 minutes ; quatrième étape, il soumet une demande de test depuis son téléphone et reçoit l’e-mail 30 secondes plus tard ; cinquième étape, il prévient les ventes dans le groupe, et à 8 h le site est déjà opérationnel. L’ensemble du processus a un RTO d’environ 1 heure et un RPO d’environ 6 heures, conformes aux objectifs du plan.

Pour les détails de la bascule DNS et de la coordination avec le CDN, voir Accélération mondiale par CDN la section sur le basculement en cas de panne de nœud. Le changement de domaine et la transition 301 suivent une logique similaire, voir Refonte du site et changement de domaine.

3. Serveur de secours et secours à froid : pas besoin de double actif à chaque fois

Les solutions de secours se divisent en trois niveaux : secours à froid, secours à chaud et double actif. Le secours à froid ne dispose que de fichiers de sauvegarde, on monte une machine temporaire pour restaurer en cas d’incident ; le secours à chaud garde un serveur de secours allumé à vide, avec une synchronisation asynchrone des données ; le double actif fait tourner deux salles informatiques en parallèle avec une synchronisation en temps réel. Le coût va du plus bas au plus élevé, le RTO du plus long au plus court.

La plupart des sites B2B indépendants se contentent d’un mélange secours à froid et secours à chaud : le serveur de secours reste allumé mais ne reçoit pas de trafic, les données sont synchronisées une fois par jour, et en cas d’incident il suffit de changer le DNS pour basculer, avec un RTO ramené à 1 ou 2 heures. Le double actif est un investissement excessif pour une personne seule ou une petite équipe, la complexité opérationnelle devenant ingérable.

Approche	État du serveur de secours	RTO	Surcoût mensuel	Cas d’usage
Secours à froid	Aucun serveur de secours, uniquement des sauvegardes	4 à 8 heures	0 €	Blogs, sites de contenu
Secours à chaud	Serveur de secours allumé en permanence, synchronisation quotidienne	1 à 2 heures	Environ 300 à 500 yuans	Sites B2B à demandes entrantes courants
Secours à chaud	Serveur de secours toujours actif, synchronisation en temps réel	15 à 30 minutes	Environ 1 500 à 3 000 yuans	Site métier critique
Actif-actif	Deux sites en service simultanément	Quelques secondes	Environ 5 000 yuans et plus	E-commerce, paiement

Rappel contre-intuitif : la bascule DNS n’est pas instantanée. Même avec un TTL à 60 secondes, la propagation mondiale du DNS prend 5 à 15 minutes, et le cache DNS local de certains utilisateurs conservera l’ancienne adresse pendant plusieurs heures. Avant de basculer le trafic, préparez-vous donc à ceci : après la bascule, tout le monde n’accède pas immédiatement au serveur de secours, il faut une période de transition. Le plan doit préciser noir sur blanc : « après la bascule DNS, attendre 15 minutes avant de vérifier l’accès mondial ».

4. Exercice annuel : dérouler le plan pour révéler les problèmes sur le papier

Le plus grand risque d’un plan de reprise après sinistre, c’est de croire que « rédiger, c’est faire ». Le document peut être parfaitement étoffé : le jour où l’incident survient, on découvre qu’on ne connaît pas le mot de passe du serveur de secours, qu’on n’arrive pas à récupérer les fichiers de sauvegarde, que la configuration SMTP est codée en dur sur l’ancien serveur. Seul un exercice réel permet de révéler ces problèmes.

L’exercice annuel se tient un dimanche à l’aube, pendant un creux d’activité, chronomètre en main. Il ne s’agit pas de basculer réellement le site principal, mais de dérouler intégralement la procédure de restauration dans un environnement de test, de la récupération de la sauvegarde à la vérification du formulaire, en notant le temps réel de chaque étape. Comparez le RTO réel à l’objectif du plan : s’il le dépasse, faites évoluer la solution. À la fin de l’exercice, rédigez un retour d’expérience et mettez le plan à jour.

Point de l’exercice	Objet du contrôle	Questions fréquentes	Axe d’amélioration
Disponibilité des sauvegardes	La dernière sauvegarde récupérée depuis S3 peut-elle être décompressée ?	Archive gzip corrompue, clé expirée	Ajouter un contrôle d’intégrité des sauvegardes
Démarrage du serveur de secours	Le serveur de secours démarre-t-il en 5 minutes ?	Serveur de secours resté éteint longtemps, logiciels obsolètes	Démarrer le serveur de secours une fois par mois
Bascule DNS	Le TTL est-il vraiment à 60 secondes ?	TTL non abaissé à l’avance	Fixer le TTL à 60 secondes en permanence
Restauration de la base de données	Le chinois s’affiche-t-il correctement après l’import ?	Erreur de jeu de caractères, texte illisible	Jeu de caractères fixé dans le script de restauration
E-mails du formulaire	Une demande de test envoyée est-elle bien reçue ?	Mot de passe SMTP codé en dur dans l’ancienne configuration	Utiliser des variables d’environnement pour le SMTP
Personnel prêt	Peut-on joindre la personne d’astreinte ?	Passation de poste non effectuée après un départ	Mettre à jour les contacts chaque trimestre

Exemple concret : une équipe réalise son premier exercice annuel. Elle suit le plan, récupère la sauvegarde, restaure la base de données, accède au site : les 40 premières minutes se passent sans accroc. Vient l’étape de vérification du formulaire de demande : le formulaire est envoyé, mais aucun e-mail n’arrive. En cause : le mot de passe SMTP était écrit dans wp-config.php, et le service de messagerie de l’ancien serveur était arrêté depuis longtemps. Si ce problème était apparu lors d’un vrai incident, il aurait fallu une heure de plus pour le diagnostiquer. Tout l’intérêt de l’exercice est de révéler ce genre de problème sur le papier.

Pour la configuration détaillée de la stratégie de sauvegarde, voir Sauvegarde et restauration : s’entraîner à réagir ; pour les seuils d’alerte de supervision, voir Surveillance et alertes du site ; pour la liste des tâches de maintenance courante, voir Les six tâches mensuelles de la maintenance d’un site.

FAQ — Questions fréquentes

Que sont réellement le RTO et le RPO, et comment les définir ?

Le RTO (objectif de temps de reprise) désigne le délai maximal acceptable entre la panne et le rétablissement du service ; le RPO (objectif de point de reprise) désigne la perte de données maximale tolérable, exprimée en durée avant l’incident. Pour un site B2B indépendant, on recommande un RTO de 4 heures et un RPO de 4 heures : cette configuration suffit pour une activité de projets avec environ 30 demandes par mois et un panier moyen élevé. Au-delà de 100 demandes par mois, l’activité se rapproche de l’e-commerce : on descend le RTO à 1 heure. Plus le RTO est court, plus le coût augmente de façon exponentielle : ne visez pas 99,99 % de disponibilité à tout prix.

Faut-il passer en actif-actif pour un site B2B indépendant ?

Dans la grande majorité des cas, non. L’actif-actif, c’est deux salles serveurs qui traitent le trafic en même temps avec synchronisation de la base de données en temps réel : plus de 5 000 yuans par mois, et une complexité d’exploitation ingérable pour une personne seule ou une petite équipe. Le site de secours tiède est plus rentable : la machine de secours reste allumée sans recevoir de trafic, les données sont synchronisées une fois par jour, et en cas d’incident on bascule en changeant le DNS. Le RTO descend alors à 1 ou 2 heures pour un surcoût de 300 à 500 yuans par mois. Seuls les sites e-commerce, de paiement ou générant plusieurs centaines de demandes par mois justifient un site de secours à chaud ou de l’actif-actif.

Comment rédiger un plan de reprise après sinistre, et à quel niveau de détail ?

Rédigez-le au niveau de la ligne de commande. Il doit contenir : les critères de détection de panne (3 échecs de test consécutifs déclenchent l’incident), les étapes précises de bascule DNS avec les temps d’attente, le bucket S3 et la sauvegarde à récupérer, les commandes complètes de restauration de la base de données, la liste de vérification (page d’accueil, pages produit, formulaire de demande, réception des e-mails), la liste des contacts avec leurs numéros de téléphone, et un modèle de rapport de retour d’expérience. N’écrivez pas « contacter l’équipe technique » : indiquez des noms précis et un contact de secours. Conservez le plan à deux endroits, dans un gestionnaire de mots de passe et sur un cloud, jamais uniquement sur le serveur qui tombe en panne.

Comment organiser l’exercice annuel, faut-il couper le site ?

Faites-le en environnement de test, sans couper le site principal. La procédure : récupérer une sauvegarde récente dans l’environnement de test, dérouler tout le processus de restauration, de la décompression des fichiers à l’import de la base de données, la configuration de nginx, l’accès au site, l’envoi d’une demande de test et la réception de l’e-mail, en chronométrant chaque étape. Comparez le temps réel au RTO cible du plan : s’il est dépassé, faites évoluer la solution. Programmez l’exercice un dimanche à l’aube, en période creuse, au moins une fois par an ; tout nouvel employé doit y participer dans les six mois suivant son arrivée.

Combien de temps prend la bascule DNS, et pourquoi des utilisateurs accèdent-ils encore à l’ancien site ?

Même avec un TTL à 60 secondes, la propagation mondiale du DNS prend 5 à 15 minutes, et le cache DNS local de certains utilisateurs conserve l’ancienne adresse pendant plusieurs heures. C’est normal, ce n’est pas un échec de configuration. Avant de basculer le trafic, réduisez le TTL à 60 secondes à l’avance (mieux vaut le maintenir à 60 secondes en permanence plutôt que d’attendre l’incident). Après la bascule, attendez 15 minutes avant de vérifier l’accès mondial, et prévenez les équipes commerciales et le support : certains utilisateurs peuvent encore voir l’ancien site, c’est la période de transition.

Les procédures de reprise après un piratage et après une panne matérielle sont-elles identiques ?

Ce n’est pas la même chose. En cas de panne matérielle, il suffit de restaurer la sauvegarde directement sur la machine de secours. Après un piratage, la restauration demande deux étapes de plus : premièrement, on ne peut pas restaurer directement l’ancienne sauvegarde, car elle peut déjà contenir une porte dérobée ; deuxièmement, après la restauration, il faut changer tous les mots de passe et toutes les clés, vérifier les tâches cron et les webshells dans la base de données, et ne remettre le site en ligne qu’après avoir confirmé que tout est propre. La procédure détaillée est décrite dans Après un piratage de site cet article. Confondre ces deux types de restauration est une erreur fréquente : après un piratage, on restaure directement l’ancienne sauvegarde, et la porte dérobée revient avec.

Pour conclure

En matière de reprise après sinistre, l’état d’esprit le plus dangereux est de se dire « nous avons des sauvegardes, cela suffit ». La sauvegarde évite de perdre des données ; la reprise après sinistre détermine à quelle vitesse le service peut être rétabli après un incident, qui s’en charge et comment. Entre les deux, il y a tout un plan de reprise et des exercices. Des sauvegardes sans plan, et vous paniquez le jour où ça arrive ; un plan sans exercice, et vous restez bloqué le jour où il faut l’appliquer.

Trois étapes concrètes : premièrement, définir le RTO et le RPO en fonction du volume mensuel de demandes et du panier moyen ; pour la plupart des sites B2B, 4 heures suffisent, inutile de viser trop haut sans raison ; deuxièmement, rédiger un plan de reprise au niveau ligne de commande, à conserver à la fois dans le gestionnaire de mots de passe et sur le cloud ; troisièmement, réaliser chaque année un exercice complet en environnement de test, noter le RTO et le RPO réels, et revoir le plan à la hausse si les objectifs sont dépassés. Une fois ces trois étapes faites, vous saurez enfin combien de temps votre site mettra à revenir après un incident.

Une phrase à retenir : un RTO n’est pas meilleur parce qu’il est plus court ; entre 4 heures et 15 minutes, le coût d’une reprise après sinistre est multiplié par 10. Calculez d’abord ce que 4 heures d’arrêt vous coûtent réellement, puis décidez jusqu’où vous voulez aller en matière de reprise après sinistre.