Plan de reprise d'activité : le guide complet

15 juillet 2026 · 5 min de lecture · SOVALYX Technologies

Un plan de reprise d'activité (PRA) est l'ensemble documenté — et surtout testé — des moyens et procédures qui permettent de remettre le système informatique en service après un sinistre majeur : panne, cyberattaque, incendie, cyclone. Ce guide couvre ses composants, les étapes pour le construire, la façon de le tester, et les erreurs qui transforment un classeur rassurant en fiction.

Un PRA, c'est quoi exactement ?

Le PRA (en anglais disaster recovery plan) organise la reconstruction du système d'information après une interruption majeure : dans quel ordre redémarrer, depuis quelles copies, sur quelle infrastructure, par qui. Il se distingue du PCA — plan de continuité d'activité — qui vise, lui, à maintenir l'activité pendant l'incident, y compris par des moyens dégradés non informatiques. La sauvegarde, enfin, n'est ni l'un ni l'autre : c'est une matière première. Posséder des sauvegardes sans procédure de reconstruction, c'est posséder des briques sans plan de la maison.

Deux objectifs chiffrés gouvernent tout le reste : le RTO, durée maximale d'interruption acceptable, et le RPO, perte de données maximale admissible. Ils se définissent avec les métiers, application par application — notre guide RTO/RPO détaille la méthode. Tout le dimensionnement du PRA en découle : viser deux heures de reprise ou deux jours ne mobilise ni la même architecture ni le même budget.

Les composants d'un plan de reprise d'activité

• L'analyse d'impact métier (BIA) : quels processus sont vitaux, quelles applications les portent, quelles dépendances les relient, combien coûte leur arrêt.
• Les objectifs RTO et RPO par application, classés en niveaux de criticité et validés par la direction.
• La cartographie technique : inventaire des serveurs, réseaux, flux et dépendances entre systèmes — c'est d'elle que se déduit l'ordre de redémarrage.
• La stratégie de secours : site secondaire, réplication, sauvegardes externalisées dont une copie immuable, capable de résister à un ransomware qui chiffrerait aussi les sauvegardes en ligne.
• Les procédures de bascule et de retour, écrites pour être exécutées sous stress par quelqu'un d'autre que leur auteur.
• Les rôles et la communication de crise : qui décide de déclencher, qui exécute, qui informe clients et partenaires — et par quel canal si la messagerie est elle-même touchée.
• Les critères de retour à la normale : quand et comment revenir sur le site principal sans provoquer un second incident.

Construire son PRA étape par étape

1. Analyser l'impact métier. Recenser les processus critiques et chiffrer ce que coûte leur interruption : c'est le socle qui justifiera chaque dépense ultérieure.
2. Fixer les objectifs. Traduire cette analyse en RTO et RPO par niveau de criticité, arbitrés et signés en direction — pas décidés en salle serveur.
3. Choisir la stratégie technique. Restauration depuis sauvegarde (économique, RTO en jours), réplication vers un site de secours (RTO en heures), ou infrastructure doublée et active (RTO en minutes). La plupart des entreprises combinent : chaque application reçoit la stratégie de son niveau, pas davantage.
4. Écrire les procédures. Pas un document d'architecture : des listes d'exécution — ordre de redémarrage, commandes, points de contrôle, contacts, seuils de décision.
5. Mettre en place les moyens. Réplication, site de secours, sauvegardes hors site, et le plus d'automatisation possible : en crise, ce sont les gestes manuels qui échouent en premier.
6. Tester, corriger, retester. C'est l'objet de la section suivante — et c'est elle qui sépare un PRA d'un document.

Un PRA non testé n'existe pas

C'est la règle la plus importante de ce guide. Un plan jamais exécuté n'est pas un plan : c'est une hypothèse optimiste. Chaque test révèle quelque chose — une dépendance oubliée, un mot de passe périmé, une sauvegarde qui ne se restaure pas, une procédure devenue fausse depuis la dernière migration. Mieux vaut le découvrir un mardi matin planifié qu'une nuit de sinistre réel.

Trois niveaux de test se complètent :

• La revue sur table : dérouler le scénario en salle avec tous les acteurs. Peu coûteuse, répétable plusieurs fois par an, elle détecte les incohérences d'organisation et les rôles vacants.
• Le test partiel : restaurer réellement une application, basculer un service, chronométrer. Il valide la technique, périmètre par périmètre, sans arrêter la production.
• La bascule complète : faire tourner l'activité depuis le site de secours, au moins une fois par an — idéalement avant les périodes à risque, comme avant la saison cyclonique à Maurice.

Chaque test se conclut par un rapport : RTO et RPO mesurés face aux objectifs, écarts constatés, plan d'action daté. Chez SOVALYX, un PRA n'est considéré comme livré qu'après sa première bascule réussie et chronométrée : le test constitue le livrable, pas le document.

Erreurs classiques, entretien et checklist

Les erreurs qui reviennent le plus souvent :

• Le PRA-document : un beau classeur jamais testé, périmé six mois après sa rédaction, exhibé aux auditeurs et inutilisable en crise.
• Les sauvegardes au même endroit que la production — détruites par le même incendie, chiffrées par le même ransomware.
• Les dépendances externes oubliées : annuaire, DNS, liens opérateurs, applications SaaS, et le prestataire lui-même — que vaut votre PRA si le sien n'existe pas ?
• Le plan stocké dans le serveur en panne : les procédures doivent exister hors du système qu'elles servent à reconstruire, sous forme accessible sans lui.
• L'homme-clé : un plan que seule une personne sait exécuter tombe en panne avec elle.
• Le retour oublié : basculer se prépare ; revenir en production nominale aussi, et ce second trajet est souvent le plus délicat.

Un PRA s'entretient comme il se construit : révision à chaque changement d'architecture significatif, à chaque arrivée ou départ dans l'équipe, et au minimum une fois par an. Le test régulier reste le meilleur mécanisme d'entretien, parce qu'il force la mise à jour de ce qui a dérivé.

La checklist finale :

• Analyse d'impact métier réalisée et validée par la direction.
• RTO et RPO définis par application, avec les métiers, et signés.
• Stratégie de secours dimensionnée par niveau de criticité.
• Sauvegardes externalisées, dont une copie immuable hors ligne.
• Procédures exécutables par quelqu'un d'autre que leur auteur, stockées hors du SI.
• Rôles, suppléants et plan de communication de crise définis.
• Test partiel récent ; bascule complète datant de moins d'un an.
• Rapport de test avec RTO/RPO mesurés, plan d'action suivi — et un interlocuteur identifié pour la prochaine échéance.

🧰 L'outil qui va avec : Combien vous coûte une heure d'arrêt ? — gratuit · 2 minutes.

Relu et optimisé par IA.