RPO, RTO et plan de reprise d'activité

RPO, RTO et plan de reprise d'activité

Quand la catastrophe frappe, combien de données peut-on se permettre de perdre et en combien de temps doit-on redémarrer ? Ces questions se formalisent par deux indicateurs essentiels : le RPO et le RTO.

RPO : Recovery Point Objective

Le RPO détermine jusqu'à quel moment on peut revenir en arrière en cas de catastrophe. Autrement dit : combien de données peut-on se permettre de perdre. Un RPO de 1 heure signifie qu'on accepte de perdre au maximum 1 heure de données. Un RPO de 0 signifie qu'aucune perte n'est acceptable.

RTO : Recovery Time Objective

Le RTO détermine le temps maximal acceptable pour rétablir le service. Un RTO de 2 heures signifie que le service doit être à nouveau disponible dans les 2 heures après l'incident. Un RTO de quelques minutes relève de la haute disponibilité automatique ; un RTO de plusieurs heures permet une restauration manuelle.

Les implications techniques

RPO faible (minutes) : réplication synchrone ou quasi-synchrone. RPO moyen (heures) : backups fréquents, transaction logs. RPO tolerant (jour) : backup quotidien. Chaque niveau implique des coûts et des complexités différentes. Le RPO réaliste dépend de la criticité métier et du budget.

Les niveaux de RTO

RTO de quelques secondes : load balancer + failover automatique. RTO de minutes : scripts de restauration automatique testés. RTO d'heures : intervention manuelle avec procédures documentées. RTO de jours : reconstruction complète. Le RTO cible détermine le dispositif à mettre en place.

Le PRA : Plan de Reprise d'Activité

Document qui formalise comment redémarrer après un sinistre majeur (perte de datacenter, attaque ransomware, catastrophe naturelle). Il précise les priorités, les ressources, les actions, les responsables. Sans PRA testé, on improvise dans la panique — les conséquences sont souvent catastrophiques.

Le PCA : Plan de Continuité d'Activité

Plus large que le PRA, le PCA vise à maintenir les activités critiques même dégradées pendant la crise. Il couvre l'IT mais aussi les RH, la logistique, la communication. C'est un document d'entreprise, pas seulement technique.

Les tests

Un PRA non testé n'a aucune valeur. Des tests réguliers — ne serait-ce qu'une fois par an — révèlent les lacunes : procédures obsolètes, compétences perdues, outils défaillants. Le test révèle aussi le RPO/RTO réellement atteignable vs théorique.

La communication en cas de crise

Savoir qui prévenir, comment, avec quel message. Status page publique (StatusPage, Instatus), mailing clients, réseaux sociaux : la communication pendant l'incident est aussi critique que la technique. Une bonne communication atténue l'impact réputationnel.

Documenter pour ne pas oublier

Un PRA est vivant : il évolue avec l'infrastructure, les applications, les équipes. Une révision semestrielle évite la dérive documentaire. Toutes les procédures doivent être exécutables par plusieurs personnes, pas dépendre d'un expert unique. Pour approfondir, consultez nos articles haute disponibilité et redondance et stratégies de backup 3-2-1.