Un PRA informatique — plan de reprise d’activité — n’est pas un document, c’est un dispositif technique doublé d’une procédure. La question qu’il tranche est simple : quand vos serveurs ne répondent plus, sur quoi redémarrez-vous, et qui appuie sur le bouton ? Ce guide couvre les trois niveaux de secours possibles, les six étapes de mise en place, et ce qui fait réellement grimper la facture.
En bref — Trois niveaux de secours existent : froid, tiède et chaud. Ils ne se distinguent pas par la qualité mais par le délai de redémarrage, et ce délai se paie. La mise en place suit six étapes, dont une seule est vraiment difficile : l’analyse d’impact, qui oblige à hiérarchiser les applications. Et le PRA ne disparaît pas quand l’infrastructure part dans le cloud — il change de forme.
Qu'est-ce qu'un PRA informatique, précisément
Un PRA informatique est l’ensemble des moyens techniques et de la procédure qui permettent de remettre le système d’information en service après un arrêt. Il se définit par deux engagements chiffrés : la quantité de travail qu’on accepte de perdre, et le délai au bout duquel l’activité reprend.
Ce n’est ni un document, ni un logiciel. C’est une infrastructure de secours — du matériel ou des ressources cloud prêtes à prendre le relais — doublée d’une procédure écrite qui dit qui décide, dans quel ordre on redémarre, et comment on travaille pendant la reprise. L’une sans l’autre ne sert à rien : une infrastructure que personne ne sait activer vaut autant qu’une procédure sans infrastructure.
On le confond souvent avec la sauvegarde, qui n’en est qu’un ingrédient, et avec le PCA, qui l’englobe et le dépasse. Ces deux distinctions sont traitées plus bas.
Les cinq sinistres qu'un PRA doit couvrir
Un plan ne se dimensionne pas contre « une panne » en général, mais contre des scénarios nommés, qui n’ont ni la même probabilité ni les mêmes conséquences.
- La panne matérielle. Un disque, une alimentation, un serveur entier. C’est le cas le plus fréquent et le plus simple à couvrir.
- Le rançongiciel. Le plus redouté, parce qu’il touche les données et les sauvegardes connectées en même temps. Il impose une copie déconnectée — voir que faire en cas d’attaque et notre guide de la sauvegarde informatique.
- L’erreur humaine. Une suppression de masse, une mise à jour ratée, une migration qui tourne mal. Elle ne détruit pas le matériel mais rend les données inutilisables.
- Le sinistre des locaux. Incendie, dégât des eaux, coupure électrique prolongée. C’est le scénario qui justifie à lui seul que le secours soit hors site.
- La perte d’un service externe. Panne prolongée de l’hébergeur, de l’opérateur ou d’un éditeur en ligne. Elle échappe à votre contrôle, et c’est précisément ce qui rend nécessaire de savoir à l’avance comment travailler sans.
Un plan qui ne nomme pas ces scénarios se dimensionne au jugé.
Les trois niveaux de secours : froid, tiède, chaud
C’est le choix structurant, et il se fait avant tout le reste, parce qu’il détermine à la fois le délai de reprise et le budget.
Le secours froid. Vous disposez de sauvegardes exploitables et d’un endroit où redémarrer, mais rien n’est prêt : il faut installer, restaurer, reconfigurer. C’est le moins coûteux, et le plus lent — on compte en jours, pas en heures, surtout si le matériel doit être commandé.
Le secours tiède. Une infrastructure de remplacement existe et reste à jour par des restaurations régulières, mais elle n’est pas allumée en permanence. Le redémarrage demande une intervention, pas une reconstruction. C’est le compromis le plus fréquent en PME.
Le secours chaud. Une seconde infrastructure fonctionne en parallèle et reçoit les données en continu. La bascule se fait en minutes. C’est le plus coûteux, parce que vous payez deux fois l’infrastructure et le lien qui les relie.
Le choix ne se fait pas globalement mais application par application : la base de production peut mériter du chaud pendant que le serveur de fichiers se contente de tiède. C’est ce découpage qui évite de payer du chaud pour tout le parc.
RPO et RTO : les deux chiffres qui commandent tout
Toute la suite en découle, et ce sont les seuls chiffres qui comptent vraiment.
Le RPO — Recovery Point Objective — est la quantité de travail que vous acceptez de perdre. Un RPO de quatre heures signifie que la dernière copie exploitable peut dater de quatre heures : au pire, une demi-journée de saisie à refaire.
Le RTO — Recovery Time Objective — est le délai au bout duquel l’activité redémarre. Il dépend de la sauvegarde, mais aussi du matériel disponible : restaurer deux téraoctets sur un serveur qu’il faut d’abord commander se compte en jours, quelle que soit la qualité des copies.
Ces deux valeurs se fixent par application, jamais globalement — une base de production et un partage de fichiers ne méritent pas le même effort. Nos trois niveaux de service engagent au contrat un RPO de 24 heures, 4 heures ou 1 heure, et un RTO de 72 heures, 24 heures ou 4 heures. La méthode pour les arbitrer application par application est détaillée dans notre exemple de plan de reprise rempli.
Réplication ou sauvegarde : ce qui les distingue vraiment
La confusion est constante, et elle fait acheter le mauvais dispositif.
La sauvegarde conserve des états successifs. Elle permet de revenir à hier, à la semaine dernière, au mois dernier. C’est ce qui sauve d’une suppression, d’une erreur de manipulation ou d’un chiffrement par rançongiciel.
La réplication maintient une copie synchronisée en temps réel ou presque. Elle permet de redémarrer vite, mais elle réplique aussi le problème : un fichier chiffré sur le site principal est chiffré sur le site de secours dans la minute.
Un PRA sérieux a les deux. La réplication tient le délai de reprise, la sauvegarde tient la capacité à revenir en arrière. Un dispositif qui n’a que la réplication ne protège pas d’un rançongiciel — voir aussi notre guide de la sauvegarde informatique.
Les six étapes de mise en place d'un PRA
Aucune ne peut être sautée, et l’ordre compte.
1. L’inventaire. Lister les serveurs, les applications, les dépendances et les flux. Ce qui n’est pas inventorié ne sera pas repris.
2. L’analyse d’impact. C’est l’étape difficile, et la seule qui n’est pas technique : pour chaque application, combien de temps l’activité tient-elle sans elle, et quelle perte de données est tolérable. Elle se mène avec les métiers, pas avec l’informatique seule, et elle produit les deux chiffres qui commandent tout le reste.
3. Le choix du niveau de secours, application par application, à partir des réponses de l’étape 2.
4. La construction du dispositif. Infrastructure de secours, réplication, sauvegardes, accès réseau, annuaire. C’est la partie longue.
5. La rédaction de la procédure. Qui déclare le sinistre, dans quel ordre on redémarre, où sont les accès de secours, comment on travaille en mode dégradé. Notre exemple de plan de reprise rempli détaille les huit rubriques attendues.
6. Le test. Sans lui, les cinq étapes précédentes sont une hypothèse.
Le PRA quand tout est déjà dans le cloud
C’est le malentendu le plus répandu du moment : « nous sommes dans le cloud, donc nous avons un PRA ». Non.
Un hébergeur garantit la disponibilité de son infrastructure. Si l’un de ses équipements tombe, il bascule et vous ne voyez rien. En revanche, il ne vous protège ni d’une suppression de votre côté, ni d’un compte administrateur compromis, ni d’une erreur de configuration qui casse votre application.
Le PRA en environnement cloud existe donc toujours, mais il change de nature : au lieu d’acheter du matériel de secours, on configure une région secondaire et on répète la bascule. Pour les environnements Microsoft, Azure Site Recovery permet de préparer cette bascule. Encore faut-il l’avoir essayé au moins une fois : une bascule jamais testée n’a aucune valeur, sur site comme dans le cloud.
Ce qui fait réellement le coût d'un PRA
Quatre postes, et ils ne pèsent pas également :
Le niveau de secours choisi. C’est de loin le premier facteur : passer du tiède au chaud, c’est doubler l’infrastructure et payer le lien entre les deux.
Le périmètre. Couvrir trois applications critiques ou l’ensemble du parc ne se compare pas. C’est là que l’analyse d’impact fait économiser.
La fréquence de réplication. Répliquer toutes les heures ou en continu ne consomme pas la même bande passante ni le même stockage.
Les tests. Ils coûtent du temps d’ingénieur, et c’est le poste qu’on supprime en premier — c’est aussi celui qui fait la différence le jour du sinistre.
Qui décide, qui exécute
Un PRA échoue souvent sur l’organisation plutôt que sur la technique.
La déclaration du sinistre est une décision de direction, pas une décision technique. Basculer sur le site de secours a des conséquences : on repart d’un état antérieur, on perd ce qui n’a pas été répliqué, et revenir en arrière est complexe. Le plan doit nommer qui a ce pouvoir, et son suppléant.
L’exécution est technique, et elle suppose des accès qui fonctionnent quand l’annuaire est tombé. C’est le point que les plans oublient : les mots de passe d’administration sont dans un coffre, et le coffre est parfois sur le serveur en panne.
La communication est un troisième rôle : prévenir les équipes, les clients, parfois l’assureur. Elle se prépare à froid, avec des modèles déjà écrits.
Les signes qu'un PRA n'en est pas un
Cinq indices, constatés en intervention :
Le document n’a pas de date de dernier test, ou elle remonte à plus d’un an.
Les objectifs sont globaux — « reprise en 24 heures » — au lieu d’être fixés par application. Cela signifie que l’analyse d’impact n’a pas eu lieu.
Le site de secours n’a jamais reçu de charge réelle. Une infrastructure de secours dimensionnée sur le papier tient rarement la production.
Personne ne sait qui déclare le sinistre.
Les sauvegardes et la réplication sont sur le même réseau que la production, donc accessibles avec les mêmes identifiants. Un attaquant qui entre les atteint toutes.
Ce que nous mettons en place
Nous partons de l’analyse d’impact, parce que c’est elle qui évite de payer du secours chaud pour des applications qui n’en ont pas besoin.
Nos trois niveaux de service engagent au contrat un RPO de 24 heures, 4 heures ou 1 heure, et un RTO de 72 heures, 24 heures ou 4 heures, fixés par application et non globalement. Les copies hors site sont conservées en France.
Et nous réalisons au minimum deux tests de restauration par an, avec un compte rendu écrit mentionnant le délai réellement atteint. C’est ce document qui prouve que le dispositif fonctionne. La sauvegarde externalisée en est le socle, et l’ensemble s’inscrit dans notre offre de cybersécurité.
PRA, PCA : la distinction qui change le budget
Les deux sigles circulent ensemble et ne recouvrent pas le même engagement.
Le PRA organise le redémarrage après un arrêt. Il accepte une interruption et vise à la raccourcir.
Le PCA vise à ce qu’il n’y ait pas d’interruption du tout, y compris hors informatique : locaux de repli, organisation du travail, fournisseurs de secours. Il englobe le PRA et le dépasse largement.
Pour une PME, viser un PCA complet est rarement réaliste. Un PRA bien dimensionné, testé, avec un mode dégradé écrit pour les 24 premières heures, couvre l’essentiel du risque pour une fraction de l’effort.
Questions fréquentes sur le PRA informatique
Qu'est-ce qu'un PRA informatique ?
C’est l’ensemble des moyens techniques et des procédures qui permettent de redémarrer le système d’information après un arrêt : panne, sinistre, erreur ou cyberattaque. Il se définit par un délai de reprise visé et une perte de données acceptée.
Quelle différence entre secours froid, tiède et chaud ?
Le secours froid suppose de tout reconstruire à partir des sauvegardes : on compte en jours. Le tiède maintient une infrastructure à jour mais éteinte : quelques heures. Le chaud fait fonctionner une seconde infrastructure en parallèle : quelques minutes, pour un coût sensiblement plus élevé.
La réplication remplace-t-elle la sauvegarde ?
Non. La sauvegarde conserve des états antérieurs et permet de revenir en arrière ; la réplication maintient une copie synchronisée et permet de redémarrer vite, mais elle recopie aussi les fichiers chiffrés ou supprimés. Un PRA sérieux combine les deux.
Quelle est l'étape la plus difficile d'un PRA ?
L’analyse d’impact. Elle n’est pas technique : elle demande aux métiers combien de temps ils tiennent sans chaque application et quelle perte de données ils tolèrent. Sans elle, les objectifs sont fixés au jugé et le dispositif est mal dimensionné.
Être dans le cloud dispense-t-il d'un PRA ?
Non. L’hébergeur garantit la disponibilité de son infrastructure, pas la récupération après une suppression, une compromission de compte ou une erreur de configuration. Le PRA en environnement cloud consiste à préparer et tester une bascule vers une région secondaire.
Qu'est-ce qui coûte le plus cher dans un PRA ?
Le niveau de secours retenu pèse le plus, loin devant le reste : le secours chaud suppose de doubler l’infrastructure. Viennent ensuite le périmètre couvert, la fréquence de réplication et le temps consacré aux tests.
Qui décide de déclencher le plan ?
La déclaration du sinistre relève de la direction, pas de la technique : basculer fait perdre ce qui n’a pas été répliqué et revenir en arrière est complexe. Le plan doit nommer la personne qui décide et son suppléant.
Quelle différence entre PRA et PCA ?
Le PRA organise le redémarrage en acceptant une interruption. Le PCA vise l’absence d’interruption et dépasse l’informatique : locaux de repli, organisation, fournisseurs de secours. Pour une PME, un PRA testé couvre l’essentiel du risque.
À quelle fréquence tester son PRA ?
Au moins une fois par an, et à chaque changement significatif : nouveau serveur, nouvelle application métier, migration. Un plan dont la date de dernier test remonte à plus d’un an ne vaut plus grand-chose.
Par où commencer ?
Le périmètre et les dépendances se relèvent d’abord, puis l’analyse d’impact fixe les objectifs par application. Le dispositif se dimensionne ensuite — pas l’inverse.
Faire dimensionner votre PRA
Nous relevons le périmètre, nous menons l’analyse d’impact avec vos métiers, et nous proposons un niveau de secours par application plutôt qu’un dispositif uniforme.
Les niveaux de secours décrits ici sont ceux couramment rencontrés ; les objectifs de perte et de délai se fixent sur le parc réel, application par application.
