PRA : ce qu'un plan de reprise d'activité contient vraiment

Posez la question autour de vous : « si votre serveur principal brûlait ce soir, dans combien de temps l'entreprise refonctionnerait-elle ? ». Vous obtiendrez des silences, ou des estimations au doigt mouillé qui vont de « quelques heures » à « aucune idée ». C'est exactement l'écart que comble un PRA (plan de reprise d'activité) : transformer « on a des sauvegardes » en « on redémarre en N heures, en perdant au pire M minutes de données, et on l'a déjà fait ».

RTO et RPO : les deux seuls sigles qui comptent #

Un PRA tient sur deux chiffres, et ce sont des décisions business, pas techniques. Le RTO (Recovery Time Objective) : combien de temps l'activité peut-elle tenir sans le service ? Le RPO (Recovery Point Objective) : combien de données peut-on accepter de perdre : les dernières minutes, la dernière heure, la dernière journée ? Un cabinet comptable peut vivre une demi-journée sans son outil mais pas perdre une écriture ; un site marchand, c'est l'inverse. Tant que ces deux chiffres n'ont pas été posés par la direction, toute la technique en dessous est du réglage à l'aveugle.

Sans RTO décidé, vous en avez quand même un : celui que vous découvrirez le jour de la panne. Il est généralement plus long que ce que l'entreprise peut supporter.

Le contenu réel d'un PRA de PME #

Oubliez le classeur de 80 pages qui dort dans une armoire. Un PRA utile est court, à jour, et surtout exécutable par quelqu'un de fatigué à 3 h du matin :

• L'inventaire par criticité : quels services, quelles machines, quelles dépendances. Sans lui, on restaure dans le désordre : l'application avant sa base, la base avant le DNS.
• RTO/RPO par service : tout ne se vaut pas. La messagerie, la facturation et l'intranet n'ont ni la même urgence ni le même besoin de fraîcheur.
• Les procédures de restauration écrites : pas « restaurer le serveur », mais les commandes, les accès, les points de contrôle. Si la procédure n'existe que dans la tête d'une personne, votre PRA a un SPOF humain.
• L'ordre de redémarrage : réseau, DNS, bases, applications, puis les clients. Les dépendances imposent une séquence, autant l'écrire à froid.
• Les rôles et contacts : qui décide de déclencher, qui restaure, qui prévient les clients. Avec les numéros, pas « voir l'annuaire », qui est peut-être dans le serveur en panne.
• Les critères de déclenchement : à partir de quand bascule-t-on du dépannage à la reprise ? Les pires pertes viennent des heures passées à réparer un mort.

Les moyens techniques, par étages #

Le PRA est le document ; encore faut-il des moyens qui le rendent tenable. Ils s'empilent par étages, du moins cher au plus exigeant, et chaque étage réduit RTO ou RPO :

1. Sauvegardes testées, immuables, hors site : le socle absolu, sans lequel le reste est décoratif. Nous avons détaillé cette architecture dans notre article 3-2-1. RPO typique : la journée ou l'heure ; RTO : le temps de restaurer.
2. Réplication : les données copiées en continu ou toutes les X minutes vers un second hôte. Le RPO tombe à quelques minutes ; le RTO reste celui d'une bascule.
3. Haute disponibilité : plusieurs nœuds, bascule automatique en cas de panne d'un hôte. Le RTO tombe à quelques minutes : pour les pannes matérielles, pas pour le ransomware ni l'erreur humaine, qui se répliquent aussi vite que les données.
4. Supervision indépendante : qui vous prévient si la panne survient à 2 h du matin ? Et si c'est la supervision elle-même qui meurt ? Un contrôle « dead-man » externe (une sonde qui s'inquiète du silence du système de surveillance) ferme la boucle.

C'est l'empilement que nous opérons pour nos clients : cluster à plusieurs nœuds avec bascule automatique, réplication entre hôtes, sauvegardes quotidiennes immuables avec copie hors site, et supervision doublée d'un watchdog indépendant. Aucune de ces briques n'est exotique ; ce qui est rare, c'est qu'elles soient toutes en place et vérifiées.

Un PRA non exercé est une fiction #

Le jour de la panne n'est pas le bon jour pour découvrir qu'un mot de passe a changé, qu'une procédure a deux ans de retard ou qu'une restauration prend six heures et non deux. Un exercice par an, a minima : restaurer réellement un service critique sur un hôte vierge, chronométrer, corriger la procédure. Notre premier exercice complet nous a appris des détails qu'aucune revue documentaire n'aurait attrapés : c'est précisément à ça qu'il sert. Le chronomètre de l'exercice, c'est votre vrai RTO ; comparez-le à celui que la direction a décidé, et vous savez où investir.

Notre infogérance inclut ce socle (sauvegardes testées, supervision 24/7, astreinte) et nous construisons le PRA avec vous : inventaire, RTO/RPO posés avec la direction, procédures écrites, exercice annuel. Si vous ne savez pas répondre à la question du premier paragraphe, c'est le bon moment d'en parler.