Plan de reprise d’activité (PRA) et continuité (PCA) pour applications critiques
Obtenez un résumé intelligent et des insights personnalisés
Un plan de reprise d’activité application (PRA) organise le redémarrage d’une app après un sinistre majeur. Cela peut notamment être entre autres : une panne serveur, une cyberattaque ou un incendie de datacenter.
Un plan de continuité d’activité (PCA) va plus loin. En effet, il maintient tout ou partie du service pendant l’incident, sans interruption totale. Ces deux dispositifs reposent sur deux indicateurs clés, le RTO et le RPO, détaillés plus bas.
En effet, une heure d’indisponibilité coûte en moyenne plus de 300 000 dollars aux moyennes et grandes entreprises, selon l’étude ITIC 2024 sur le coût horaire des interruptions de service. Pour une PME française, l’ordre de grandeur se compte plutôt en milliers d’euros par heure. Néanmoins, l’impact reste réel. À savoir : la perte de chiffre d’affaires, les clients mécontents ou l’image dégradée. Alors, comment faire ? AquilApp vous dit tout.
Qu’est-ce que le PRA vs le PCA ? Quelles sont les différences ?
Un PRA est un plan de reprise d’activité application. Il organise notamment la restauration d’une application après un sinistre. Donc, il définit qui fait quoi, dans quel ordre, et avec quel délai maximal.
Un PCA est un plan qui maintient l’activité pendant l’incident. Il s’appuie sur un mode dégradé, un site de secours actif, ou des procédures manuelles temporaires.
La différence est simple :
- Le PRA répare après coup.
- Le PCA absorbe le choc en temps réel.
Une application critique a besoin des deux.
| Critère | PRA | PCA |
|---|---|---|
| Objectif | Redémarrer après sinistre | Maintenir le service pendant l’incident |
| Déclencheur | Panne totale, sinistre majeur | Dégradation ou incident partiel |
| Horizon temporel | Après l’arrêt | Pendant l’arrêt |
| Exemple concret | Restaurer une base de données depuis un site de secours | Basculer le trafic vers un serveur actif en parallèle |
Définitions construites à partir du référentiel ISO 22301 et des guides méthodologiques de l’ANSSI sur la continuité d’activité.
Évidemment, ces deux plans s’articulent avec votre sécurité applicative au sens large. Notre guide sur la sécurité applicative OWASP détaille les vulnérabilités à corriger en amont d’un PRA.
Comment définir vos RTO et RPO dans un plan de reprise d’activité application ?
Le RTO (Recovery Time Objective) est le délai maximal acceptable pour redémarrer une application après un incident. D’un autre côté, le RPO (Recovery Point Objective) est la quantité de données que vous acceptez de perdre. Elle est notamment mesurée en temps depuis la dernière sauvegarde.
Ces deux seuils ne se fixent pas au hasard. Ils découlent d’une analyse d’impact métier :
- Coût réel d’une heure d’arrêt
- Criticité des données
- Et, dépendance des processus à l’application.
| Criticité de l’application | RTO cible | RPO cible | Architecture associée |
|---|---|---|---|
| Transactionnelle (paiement) | < 15 minutes | < 5 minutes | Actif-actif, réplication continue |
| Métier critique (ERP, CRM) | 1 à 4 heures | 1 heure | Actif-passif avec bascule automatisée |
| Reporting interne | 24 heures | 24 heures | Sauvegarde quotidienne, restauration manuelle |
Ordres de grandeur usuels en architecture IT, à ajuster selon votre analyse de risques.
Quelle architectures de résilience choisir pour votre PRA : active-passive, active-active, multi-région
Trois architectures dominent le marché.
- Active-passive : un site principal traite le trafic, un site de secours reste en attente. Le RTO se compte en minutes. Le coût reste maîtrisé.
- Active-active : deux sites traitent le trafic simultanément. Le RTO devient quasi nul, mais le coût double car l’infrastructure tourne en permanence.
- Multi-région : les sites sont répartis sur plusieurs zones géographiques. Cette architecture protège contre un sinistre régional, mais soulève des questions de souveraineté des données.
Le choix dépend de votre RTO cible et de votre budget. Un plan de reprise d’activité application actif-passif suffit pour la majorité des applications métier.
Comment gérer les sauvegardes et la réplication des données pendant un plan de reprise d’activités application ?
La sauvegarde capture un état de vos données à un instant donné. D’un autre côté, la réplication copie vos données en continu vers un second emplacement.
Notre conseil : la règle 3-2-1 reste la référence. Donc, vous aurez besoin de :
- Trois copies de vos données
- Sur deux supports différents
- Dont une copie hors site.
À noter : une sauvegarde non testée n’a aucune valeur. Donc, elle doit être restaurée régulièrement pour vérifier son intégrité réelle.
Comment tester votre PRA : scénarios et fréquence
Un plan de reprise d’activité application jamais testé reste une hypothèse, pas un plan opérationnel. Donc, faites les démarches qu’il faut :
- Test documentaire : relecture de la procédure en réunion.
- Test partiel : bascule réelle d’un composant, sans impact utilisateur.
- Test grandeur nature : simulation complète d’un sinistre, avec bascule effective.
Le saviez-vous ? Une application critique doit être testée au moins une fois par an. Les organisations soumises à NIS2 ou DORA devront documenter ces tests avec une fréquence plus soutenue.
Quelles sont les obligations réglementaires d’un plan de reprise d’activités application : NIS2 et DORA
Deux textes européens encadrent désormais la résilience numérique.
DORA (Digital Operational Resilience Act) s’applique au secteur financier. Ce règlement européen est directement applicable, sans loi de transposition, depuis le 17 janvier 2025. Banques, assurances et leurs prestataires informatiques critiques doivent démontrer un PRA testé.
NIS2 vise un périmètre plus large. Tel est le cas de l’énergie, la santé, l’industrie, le numérique, ou les administrations. En France, la transposition n’est toujours pas achevée mi-2026. Le projet de loi Résilience reste bloqué à l’Assemblée nationale, et la Commission européenne a saisi la Cour de justice de l’Union européenne contre la France en juillet 2026 pour ce retard. L’ANSSI estime que 15 000 à 18 000 entités françaises seront concernées une fois la loi adoptée, contre environ 500 sous l’ancienne directive NIS1.
Anticiper reste la meilleure stratégie. En effet, de nombreux donneurs d’ordre exigent déjà un PRA dans leurs contrats, avant même l’entrée en vigueur de la loi française. Notre article dédié à NIS2 détaille le périmètre complet de la directive.
Quels sont les coûts et le dimensionnement d’un plan de reprise d’activité application ?
Le budget d’un PRA varie fortement selon le niveau de résilience visé.
| Niveau | Description | RTO indicatif | Budget indicatif |
|---|---|---|---|
| Basique | Stratégie de backup et restauration cloud + procédure documentée | 24 à 48 heures | Quelques centaines à quelques milliers d’€/mois |
| Intermédiaire | Site de secours actif-passif | 1 à 4 heures | Quelques milliers à dizaines de milliers d’€/mois |
| Avancé | Architecture actif-actif multi-région | Quasi nul | Dizaines à centaines de milliers d’€/mois |
Fourchettes indicatives, établies à partir de nos retours d’expérience projets. Elles varient selon votre architecture existante et vos exigences réglementaires.
Cette dépense se compare toujours au coût d’une panne. Un PRA à 3 000 euros par mois devient rentable dès la première interruption majeure évitée.
FAQ sur le plan de reprise d'activité (PRA) d'une application
* **PCA (Plan de Continuité d’Activité) :** Vise à maintenir le fonctionnement des applications critiques sans interruption totale, même en cas de panne ou de sinistre majeur (ex. architecture hautement disponible avec basculement automatique *failover*).
* **PRA (Plan de Reprise d’Activité) :** Intervient après un arrêt avéré du système d’information. Il définit les procédures techniques et organisationnelles permettant de reconstruire l’infrastructure, de restaurer les données et de redémarrer les applications dans des délais maîtrisés.
Une application métier hautement critique combine généralement un PCA pour la haute disponibilité et un PRA en secours ultime.
* **Secteur financier et bancaire :** Le règlement européen **DORA** (*Digital Operational Resilience Act*), entré en application en janvier 2025, impose des exigences strictes en matière de résilience opérationnelle numérique et de tests de PRA.
* **Organisations d’importance essentielle ou importante :** La directive **NIS 2** élargit ces obligations de continuité d’activité à 15 000 – 18 000 entités supplémentaires en France (énergie, santé, transports, administrations publiques, fournisseurs de services numériques).
Pour les autres PME, bien que non strictement obligatoire par la loi, le PRA reste exigé par la plupart des cyber-assureurs et des grand comptes dans le cadre de leur gestion des risques tiers.
* **Applications transactionnelles critiques :** Visent un RTO quasi-nul ou inférieur à 15 minutes (ex. e-commerce, systèmes de paiement, core banking).
* **Applications métiers internes ou de reporting :** Peuvent tolérer un RTO de 4 h à 24 h sans mettre en péril l’entreprise.
Le RTO se fixe en mettant en balance le coût financier et opérationnel d’une heure d’arrêt d’activité face au coût des infrastructures requises pour réduire ce temps de reprise.
* **PRA basique (sauvegarde Cloud & restauration) :** Pour des applications peu critiques avec un RTO étendu, une solution de sauvegarde externalisée sécurisée et documentée démarre à quelques centaines d’euros par mois.
* **PRA avancé (Actif-Passif / Cloud Disaster Recovery) :** Pour une application critique nécessitant une réplication continue des données et un site de secours immédiatement mobilisable dans le Cloud, les coûts s’élèvent de plusieurs milliers à plusieurs dizaines de milliers d’euros par mois, incluant la conduite de tests d’amorce périodiques obligatoires.
Conclusion
Le PRA ou plan de reprise d’activité application restaure votre app après un sinistre. Le PCA maintient l’activité pendant l’incident. Ensemble, ils protègent votre entreprise contre le coût réel d’une panne prolongée.
La démarche commence par une analyse d’impact métier. Ensuite, elle se poursuit par le choix d’une architecture adaptée à votre RTO. Enfin, elle se valide par des tests réguliers.
Vous souhaitez sécuriser l’ensemble de votre infrastructure ? Complétez cette démarche par un audit de votre stratégie multi-cloud. De quoi réduire votre dépendance à un seul fournisseur.
Besoin d’évaluer la résilience de votre application critique ? Nos experts auditent votre architecture et dimensionnent votre PRA sur mesure.
