PRA et PCA d’une application web : définir RTO, RPO, sauvegardes et scénarios de crise

Une sauvegarde ne garantit pas la continuité. Elle peut être incomplète, inaccessible lors d’une attaque, trop longue à restaurer ou dépendre d’un service lui-même indisponible. Le plan de reprise d’activité transforme les objectifs métier en procédures, moyens techniques et exercices mesurables.

Le PCA, plan de continuité d’activité, cherche à maintenir un niveau de service pendant la perturbation. Le PRA, plan de reprise d’activité, organise le rétablissement après une interruption. Pour une application web, les deux couvrent le code, les données, l’infrastructure, les services tiers, les équipes et la validation métier.

Partir de l’impact métier

La question initiale n’est pas « combien de sauvegardes voulons-nous ? », mais « que se passe-t-il si ce parcours est indisponible ou si ses dernières données disparaissent ? ». Les impacts peuvent être financiers, opérationnels, contractuels, réglementaires ou réputationnels.

Chaque capacité est classée : consultation, saisie, paiement, calcul, import, notification, administration. Certaines peuvent fonctionner en mode dégradé ; d’autres nécessitent un arrêt pour protéger l’intégrité.

Cette analyse définit les priorités de reprise. Restaurer l’ensemble du site avant la fonction qui reçoit les commandes peut être techniquement confortable mais métierment incorrect.

Comprendre RTO, RPO, MTPD et WRT

Le RTO est le temps cible entre l’interruption et le rétablissement du service technique acceptable. Le RPO représente la quantité maximale de données que l’organisation accepte de perdre, exprimée en temps.

Le MTPD désigne la durée maximale tolérable de perturbation avant que les conséquences ne deviennent inacceptables. Le WRT, ou temps de reprise du travail, couvre ce que les équipes métier doivent faire après le retour technique : contrôles, rapprochements, rattrapage et communication.

Une cohérence simple s’impose : le RTO plus le WRT doit rester inférieur au délai maximal tolérable. Le RPO doit être compatible avec la fréquence de sauvegarde ou de réplication réellement obtenue.

Une stratégie de sauvegarde complète

Une stratégie précise :

• les données couvertes ;
• la fréquence ;
• la rétention ;
• les copies hors ligne ou immuables ;
• la séparation des comptes et droits ;
• le chiffrement ;
• la surveillance des échecs ;
• la procédure de restauration ;
• les preuves de test.

La règle dite 3-2-1 — plusieurs copies, sur des supports distincts, dont une séparée — constitue un point de départ, pas une garantie universelle. Les sauvegardes doivent inclure bases, fichiers, configurations, clés nécessaires et versions de code compatibles.

Restaurer l’ensemble cohérent

Une base restaurée sans les fichiers associés, ou un code récent avec un schéma ancien, peut rendre l’application incohérente. Le PRA définit un point de cohérence et l’ordre : infrastructure, secrets, base, stockage, index, workers, caches et services.

Les migrations et scripts doivent être versionnés. Les clés de chiffrement et certificats nécessaires à la lecture des données sont protégés séparément mais disponibles pendant la crise.

Choisir le niveau de secours

Sauvegarde et reconstruction

Adaptée lorsque le RTO se compte en heures ou jours. L’infrastructure est recréée puis les données restaurées. Cette approche est économique mais dépend de l’automatisation et de la disponibilité des composants.

Environnement de secours froid ou tiède

Des ressources sont préparées, avec une partie de l’infrastructure ou des données déjà disponible. Le coût augmente, le temps de reprise diminue.

Secours chaud et réplication

Une infrastructure prête reçoit les données en continu ou presque. Le basculement peut être rapide, mais il faut maîtriser la réplication des erreurs, les conflits et les tests de retour.

Continuité active

Plusieurs zones ou sites servent le trafic. Cette architecture vise une forte disponibilité, sans supprimer le besoin de sauvegardes : une suppression logique ou une compromission peut se propager partout.

Cartographier les dépendances

L’application dépend souvent de DNS, identité, e-mail, paiement, stockage, API métier et fournisseurs. Le PRA doit préciser le comportement de chacun : attente, mise en file, mode dégradé, autre fournisseur ou suspension contrôlée.

Une architecture redondante perd son intérêt si le compte DNS, le fournisseur d’identité ou une clé unique reste un point de défaillance. Les dépendances organisationnelles comptent aussi : qui peut accéder aux comptes, prendre une décision et communiquer ?

Définir les scénarios de crise

Un plan générique ne suffit pas. Testez des scénarios :

• suppression ou corruption de données ;
• indisponibilité d’une région cloud ;
• compromission de comptes administrateurs ;
• ransomware ;
• certificat ou domaine expiré ;
• déploiement défectueux ;
• panne d’un service tiers ;
• indisponibilité d’une personne clé.

Chaque scénario précise déclencheur, périmètre, décision, isolement, restauration, validation et sortie de crise.

Écrire un runbook utilisable sous pression

Le runbook doit être court, versionné et accessible même si le système principal est indisponible. Il indique les contacts, les prérequis, les commandes, les résultats attendus et les points d’arrêt. Les secrets ne sont pas écrits en clair ; leur coffre et leur procédure d’accès sont testés.

Les rôles sont séparés : direction de crise, intervention technique, validation métier, communication et liaison avec les fournisseurs. Une même personne peut cumuler des rôles dans une petite structure, mais la responsabilité reste explicite.

Tester la restauration

Un test de sauvegarde vérifie qu’un fichier existe. Un test de restauration prouve qu’il peut être utilisé. L’exercice doit mesurer :

• temps de récupération des accès ;
• temps de reconstruction ;
• temps de transfert et de restauration ;
• contrôles d’intégrité ;
• validation des parcours ;
• écarts au RTO/RPO ;
• opérations manuelles et erreurs.

Les exercices peuvent commencer par une table, puis un environnement isolé, puis une répétition complète. Ils doivent produire des actions avec échéance.

Préparer la communication

La continuité inclut les utilisateurs, partenaires et équipes. Des modèles de messages expliquent ce qui est connu, l’impact, les mesures et la prochaine mise à jour. Il faut éviter les promesses de délai non confirmées et protéger les informations de sécurité.

Un journal de crise horodaté conserve décisions, actions et preuves. Il facilite le retour d’expérience et les obligations éventuelles de notification.

Maintenir le plan vivant

Le PRA est revu lorsque l’architecture, les volumes, les fournisseurs ou l’organisation changent. Les contacts expirent, les commandes évoluent et les objectifs métier se durcissent. Une revue annuelle est un minimum pour une plateforme importante ; les tests peuvent être plus fréquents selon la criticité.

Les indicateurs suivent le taux de succès des sauvegardes, l’âge du dernier test, le temps mesuré de reprise, les écarts et les actions non clôturées.

Une capacité, pas un document

Le niveau de continuité doit être proportionné. Un RTO de quelques minutes implique une architecture et une organisation coûteuses. Un objectif de plusieurs heures peut être parfaitement acceptable s’il est assumé et testé.

Partitech assure l’hébergement, l’infogérance, la supervision et la maintenance de plateformes digitales. Nous pouvons cartographier les dépendances, définir les objectifs, automatiser la restauration et conduire des exercices afin que le PRA corresponde à une capacité réelle.

Pour approfondir la démarche, cadrez les niveaux de service et la maintenance applicative, commencez par un audit technique de l’application et préparez les stratégies de bascule d’une application. Découvrez également l’offre Maintenance, évolutions, hébergement et infogérance de Partitech.

Références officielles

Références consultées le 17 août 2026 :

• ANSSI — Sauvegarde des systèmes d’information ;
• ANSSI — Directive NIS 2 et continuité.