Il existe des acronymes simples : VPN, Wi-Fi, SMS, USB : on les utilise tous les jours, sans se poser de questions.
Et puis il y a ceux-là : PRA, PCA, PRI, PCI.
Ils apparaissent souvent quand on parle de cybersécurité, de continuité d’activité ou d’incident informatique. On les confond, on les mélange, et parfois on les utilise comme s’ils voulaient dire la même chose.
En réalité, ils ne parlent ni du même moment, ni du même objectif !
Certains concernent ce qui se passe pendant un incident. D’autres ce qui se passe après. Certains sont métier, d’autres purement informatiques…
Mais pas facile de s’y retrouver (et encore moins de garder le cap) quand il s’agit de structurer un plan de reprise informatique (PRA / PCA).
Faisons la route ensemble.
Étape 1 : Comprendre PRA, PCA, PRI et PCI (le minimum vital)
La différence entre continuité et reprise
La continuité concerne ce qui se passe pendant l’incident. Elle vise à maintenir un niveau d’activité minimal, même dégradé.
- Le PCA (Plan de Continuité d’Activité) organise la continuité des processus métier
- Le PCI (Plan de Continuité Informatique) permet de maintenir les usages informatiques essentiels
La reprise, elle, intervient après la stabilisation de l’incident. Elle vise à revenir à un fonctionnement normal.
- Le PRA (Plan de Reprise d’Activité) pilote la reprise globale de l’activité
- Le PRI (Plan de Reprise Informatique) détaille la restauration technique du système d’information
Quand activer le PCA ou le PRA
Le PCA s’active dès qu’un incident perturbe le fonctionnement normal mais que l’activité peut encore être maintenue, même partiellement : panne d’un outil, indisponibilité d’un service, incident localisé.
Le PRA s’active lorsque l’incident empêche durablement le fonctionnement normal du système d’information.
Cette distinction est essentielle. Sans critères clairs d’activation, les décisions sont prises dans l’urgence, au cas par cas, avec un risque élevé d’erreur ou de retard dans la reprise.
Pour structurer cette gouvernance, beaucoup d’entreprises s’appuient sur un RSSI externalisé qui pilote l’ensemble de la démarche de continuité et de reprise.
Étape 2 : Identifier ce qui ne peut pas s’arrêter (PCA)
Le PCA informatique vise à garantir la continuité des processus métier essentiels lorsque le système d’information est partiellement ou totalement indisponible.
Il ne cherche pas à maintenir l’ensemble des activités, mais à éviter l’arrêt complet de l’entreprise pendant l’incident.
Processus métier critiques
Un processus métier correspond à ce qui fait tourner l’entreprise au quotidien : produire, livrer, facturer, servir les clients.
Exemples concrets en PME / ETI :
- Facturation : impossibilité d’émettre des factures si l’ERP ou l’outil comptable est indisponible
- Production / exploitation : arrêt des opérations si l’application métier centrale ou la base de données associée n’est plus accessible
- Relation client : impossibilité de traiter des demandes ou incidents si le CRM est indisponible
- Obligations réglementaires : incapacité à produire des données exigées par un régulateur ou un client
Fonctionnement en mode dégradé
Le mode dégradé décrit la manière dont un processus critique continue à fonctionner lorsque tout ou partie du SI est indisponible.
Il s’agit de scénarios préparés à l’avance, et non de solutions improvisées en situation de crise.
Tableau – Exemples de processus critiques et modes dégradés associés
| Processus métier | Impact en cas d’arrêt | Dépendances SI principales | Exemple de mode dégradé |
|---|---|---|---|
| Facturation | Perte de chiffre d’affaires | ERP, base comptable | Saisie manuelle et facturation différée |
| Production / exploitation | Arrêt de l’activité | Application métier, base de données | Réduction du périmètre opérationnel |
| Relation client | Dégradation du service | CRM, messagerie | Support via canal alternatif |
| Obligations réglementaires | Risque juridique | Données réglementées | Extraction manuelle des données clés |
Étape 3 : Fixer des limites claires d’arrêt et de perte de données (RTO / RPO)
Une fois les processus critiques identifiés, l’enjeu du plan de reprise informatique est de déterminer jusqu’où l’entreprise peut se permettre une interruption.
C’est précisément le rôle des RTO (délai de reprise acceptable) et RPO (perte de données tolérable).
Ce que mesurent réellement le RTO et le RPO
Le RTO (Recovery Time Objective) correspond au délai maximal d’indisponibilité acceptable pour un service ou un processus.
Le RPO (Recovery Point Objective) définit la quantité maximale de données que l’entreprise peut se permettre de perdre.
Tableau – Exemples de RTO et RPO par type de processus
| Processus métier | RTO cible | RPO cible | Impact principal en cas de dépassement |
|---|---|---|---|
| Facturation | 24 h | 24 h | Retard de trésorerie |
| Production / exploitation | 4 à 8 h | 1 h | Arrêt d’activité |
| Relation client | 8 à 24 h | 24 h | Dégradation du service |
| Outils internes secondaires | 48 à 72 h | 48 h | Impact limité |
Étape 4 : Préparer la reprise technique du système d’information (PRI)
Le plan de reprise ne peut pas rester théorique.
Il doit se traduire par des actions concrètes et applicables sur le plan technique.
C’est précisément le rôle du PRI (Plan de Reprise Informatique), qui décrit comment les systèmes, les applications et les données sont effectivement remis en service.
Aligner les sauvegardes sur les objectifs de reprise (RPO)
Les sauvegardes sont la base de toute reprise après sinistre, mais leur existence ne suffit pas.
Dans la pratique, cela implique de vérifier :
- à quelle fréquence les données sont réellement sauvegardées
- quelles données sont incluses (bases métiers, fichiers, configurations)
- si la restauration a déjà été testée dans des conditions proches du réel
- si les sauvegardes sont isolées du système de production
Choisir une architecture de reprise compatible avec les délais attendus (RTO)
L’architecture de reprise conditionne directement le RTO.
Selon la situation, la reprise peut s’appuyer sur :
- une infrastructure interne redondée
- un environnement de secours hébergé dans le cloud
- une approche hybride combinant les deux
Définir clairement l’ordre de redémarrage des services
Lors d’un incident majeur, tous les systèmes ne peuvent pas être restaurés en même temps. Le PRI doit donc préciser :
- quels services sont redémarrés en premier
- lesquels peuvent attendre
- quels prérequis techniques sont nécessaires
- quels contrôles doivent être réalisés avant remise en production
Étape 5 : Intégrer les scénarios cyber dans le plan de reprise informatique
Une attaque cyber ne se gère pas comme une panne classique. Le système n’est pas seulement indisponible : il peut être compromis.
Le plan de reprise informatique doit donc prévoir des règles spécifiques pour éviter d’aggraver la situation au moment de redémarrer.
Pour détecter ces compromissions avant qu’elles n’impactent la reprise, des tests d’intrusion réguliers permettent d’identifier les vulnérabilités exploitables.
Ce qui change en cas d’attaque cyber (ransomware, compromission)
En cas d’incident cyber, certaines actions habituelles deviennent risquées.
| Situation | Risque principal |
|---|---|
| Restauration trop rapide | Réintroduire l’attaque |
| Sauvegardes compromises | Impossible de repartir |
| Redémarrage sans contrôle | Propagation de l’incident |
| Décisions prises dans l’urgence | Mauvais arbitrages |
Sécuriser les sauvegardes et les environnements de reprise
| Point clé | Attente minimale |
|---|---|
| Accès aux sauvegardes | Comptes séparés |
| Protection | Sauvegardes isolées ou immuables |
| Restauration | Testée hors production |
| Environnement de reprise | Séparé du SI compromis |
Sans ces garanties, la reprise peut échouer même avec des sauvegardes existantes.
Un SOC managé peut surveiller en continu les tentatives d’accès aux sauvegardes et détecter les comportements anormaux.
Coordonner reprise informatique et gestion de crise
La reprise technique ne peut pas avancer seule. Elle doit être alignée avec les décisions de gestion de crise.
Étape 6 : Tester, maintenir et gouverner le plan de reprise informatique avec Cykrony
Un plan de reprise informatique (PRA / PCA) n’échoue pas par absence de procédures, mais par décalage progressif entre le plan, le système d’information réel et les décisions prises en situation de crise.
Cykrony accompagne les PME et ETI sur ces sujets avec une approche pragmatique, centrée sur l’activabilité du plan.
Concrètement, l’accompagnement permet de :
- clarifier le périmètre réel du PRA et du PCA, sans chercher à tout couvrir
- définir des RTO et RPO tenables, en lien direct avec les contraintes métiers
- structurer un PRI cohérent avec les capacités techniques existantes
- tester le plan à travers des exercices de gestion de crise et des simulations de décision
- maintenir le plan dans le temps, à mesure que le SI et les usages évoluent
L’objectif n’est pas de produire un plan exhaustif, mais un plan compréhensible, testé et activable.
Pour une gouvernance complète, ces plans s’articulent avec les démarches de conformité et certifications de votre organisation.