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.
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.
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 le permet — voir notre page infogérance Azure. 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.
