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 :
- 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.
- 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.
- 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.
- 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.
