Beaucoup d’entreprises disposent d’un plan… Mais peu d’entre elles savent dire quand il a été testé, ni ce que ce test a prouvé ! Un audit PCA / PRA répond précisément à cette question : le dispositif tiendrait-il en conditions réelles ? Et sur quelles preuves ? Ce guide donne la méthode en sept étapes, les points de contrôle et le livrable attendu.
Qu’est-ce qu’un audit PCA / PRA ?
Un audit PCA / PRA vérifie qu’un plan de continuité d’activité (PCA) et un plan de reprise d’activité (PRA) en place restent applicables, correctement dimensionnés et démontrés par un test. Le contrôle porte sur trois objets : le document, les mécanismes techniques et la capacité effective à basculer.
Ce que l’audit vérifie : le document, le dispositif, la bascule
Le document, le dispositif et la bascule se contrôlent séparément, avec des preuves différentes. Un plan à jour ne garantit pas que la réplication fonctionne. Une réplication active ne garantit pas que les équipes savent l’activer un dimanche à 3 heures du matin.
| Objet audité | Question posée | Preuve attendue |
| Le document (plan, procédures) | Le plan est-il à jour et accessible hors du système d’information protégé ? | Version datée, validée, stockée hors ligne |
| Le dispositif technique | Les mécanismes de sauvegarde et de réplication de données existent-ils ? | Journaux de sauvegarde, configuration de réplication, inventaire du secours |
| La capacité à basculer | La bascule a-t-elle été exécutée, sur quel périmètre, dans quel délai ? | Compte rendu de test de bascule daté, RTO et RPO mesurés |
Audit PCA et audit PRA : deux périmètres distincts
L’audit PCA porte sur les activités métier : processus prioritaires, effectifs, locaux, fournisseurs, mode dégradé. L’audit PRA porte sur la remise en service du système d’information : données, serveurs, réseaux, délais de redémarrage. Les deux se recoupent sur la cartographie des activités critiques, rarement ailleurs. Voir la page dédiée à la différence entre PRA et PCA.
Audit interne, audit externe, audit de certification
L’audit interne est commandé par la direction des systèmes d’information (DSI) ou le responsable de la sécurité des systèmes d’information (RSSI). Sa valeur dépend de l’indépendance laissée à l’auditeur.
L’audit externe est commandé par la direction générale, un client ou un assureur. Le regard extérieur repère les dépendances devenues invisibles en interne.
L’audit de certification relève d’un organisme accrédité, dans le cadre de l’ISO 22301. Il évalue la conformité du système de management, pas la robustesse technique d’une bascule. Une certification n’atteste pas qu’une reprise a réussi.
Pourquoi auditer un plan déjà en place ?
Un plan documenté n’est pas un plan opérationnel
Un plan de reprise d’activité (PRA) vieillit plus vite que l’infrastructure qu’il décrit. Trois ans après sa rédaction, une partie des applications a changé de version, d’hébergement ou de propriétaire. Les numéros d’astreinte pointent vers des personnes parties. Cas classique : la procédure est stockée sur le serveur qu’elle doit restaurer.
Les déclencheurs les plus fréquents d’un audit
Auditer son PRA relève rarement de l’anticipation. Six motifs reviennent :
- un incident réel, même sans perte de données ;
- une migration ou un changement d’infrastructure ;
- l’exigence d’un client ou d’un donneur d’ordre ;
- le renouvellement d’un contrat d’assurance cyber ;
- l’entrée dans un périmètre réglementaire ;
- l’arrivée d’un nouveau DSI ou d’un nouveau RSSI.
Ce qu’imposent NIS 2, DORA et ISO 22301 en matière de test
Aucun de ces trois référentiels ne prescrit un format d’audit. Deux portent des obligations de fond, le troisième structure une méthode.
La directive (UE) 2022/2555, dite NIS 2, cite à son article 21, paragraphe 2, point c, la continuité des activités, la gestion des sauvegardes et la gestion des crises parmi les mesures minimales attendues des entités essentielles et importantes. Le point f ajoute l’évaluation de leur efficacité. Ni fréquence, ni méthode ne sont fixées.
Le règlement (UE) 2022/2554, dit DORA, applicable depuis le 17 janvier 2025, va plus loin : son article 24, paragraphe 6, impose de tester au moins une fois par an tous les systèmes soutenant des fonctions critiques ou importantes. Périmètre strictement sectoriel, les entités financières.
L’ISO 22301 version 2019 consacre son article 8.5 au programme d’exercices et son article 8.6 à l’évaluation du plan de reprise d’activité. Adhésion volontaire. L’ISO 19011 version 2018 fournit le référentiel d’audit applicable. Ces éléments n’ont pas valeur de conseil juridique.
Les étapes d’un audit PCA / PRA
La méthodologie d’audit PCA PRA se déroule en sept étapes : cadrage du périmètre et des scénarios, revue du bilan d’impact sur l’activité, confrontation des objectifs de reprise aux valeurs réelles, audit technique des sauvegardes, audit organisationnel des rôles et suppléances, test de bascule et de restauration, restitution avec cotation des écarts et plan de remédiation.
1. Cadrage du périmètre et des scénarios de sinistre
Le cadrage fixe ce qui est audité, et contre quoi. Parmi les scénarios habituels : perte d’un site, chiffrement du système d’information par rançongiciel, défaillance d’un prestataire, panne matérielle… Un périmètre implicite rend le rapport contestable.
2. Revue du bilan d’impact sur l’activité (BIA)
Le bilan d’impact sur l’activité (BIA) classe les activités par criticité et fixe les délais tolérables. La cartographie des activités critiques doit être validée par les métiers, pas seulement par la DSI. Une criticité arbitrée en interne informatique reflète l’architecture, mais pas l’activité.
3. Confrontation des RTO / RPO cibles aux RTO / RPO réels
Il s’agit de l’étape la plus structurante. L’auditeur compare la durée maximale d’interruption admissible (RTO) et la perte de données maximale admissible (RPO) inscrites au plan avec les valeurs mesurées en restauration réelle. L’écart se chiffre souvent en heures. La page RTO et RPO détaille ces notions.
4. Audit technique des dispositifs de sauvegarde et de réplication
Quatre contrôles : sauvegarde immuable, isolation par rapport au domaine de production, répartition géographique des copies, vérification d’intégrité. Une sauvegarde accessible avec les identifiants de production ne survit pas à un rançongiciel. Voir la page stratégie de sauvegarde.
5. Audit organisationnel : rôles, suppléances et chaîne de décision
Qui déclenche, qui décide, qui communique. L’audit vérifie l’existence de suppléants nommés et joignables au sein de la cellule de crise, puis la chaîne de décision quand les titulaires sont absents. Une bascule qui dépend d’une seule personne est un point de rupture.
6. Test de bascule et de restauration
Trois niveaux coexistent : le test granulaire sur un fichier, le test partiel sur une application, le test de PRA complet sur tout le périmètre. Seul le dernier démontre la bascule. Les pages sur le déclenchement d’un PRA et sur la restauration informatique décrivent le déroulé réel.
7. Restitution, cotation des écarts et plan de remédiation
Le rapport évalue chaque écart selon sa gravité et l’effort de correction, puis le traduit en plan de remédiation daté, avec un responsable par ligne. Sans cotation, la restitution produit des constats que personne ne priorise.
Checklist des points de contrôle d’un audit PCA / PRA
Cette checklist d’audit PRA couvre cinq blocs : gouvernance, périmètre, technique, organisation et tests. Elle permet un pré-diagnostic sans prestataire, à condition de réunir les preuves avant de cocher une ligne.
| Point de contrôle | Preuve attendue | Écart typique |
| Gouvernance | ||
| Politique de continuité validée | Document signé et daté | Politique jamais formalisée |
| Propriétaire du plan désigné | Nom, fonction, lettre de mission | Responsabilité diluée DSI / métiers |
| Revue périodique du plan | Compte rendu de revue daté | Revue antérieure à la migration |
| Périmètre | ||
| Cartographie des activités critiques | BIA validé par les métiers | Cartographie produite par la DSI seule |
| Inventaire applications et dépendances | Liste à jour des interconnexions | Applications SaaS métier absentes |
| RTO et RPO définis par application | Tableau validé par application | Un RTO unique pour tout le SI |
| Dépendances externes recensées | Prestataires, lien opérateur, téléphonie | Opérateur et téléphonie oubliés |
| Technique | ||
| Sauvegardes immuables | Rétention non modifiable | Rétention modifiable par un administrateur |
| Isolation des sauvegardes | Authentification hors domaine | Sauvegardes jointes au domaine |
| Répartition géographique des copies | Copie sur un second site | Copies sur un site unique |
| Vérification d’intégrité automatisée | Rapports de vérification datés | Contrôle déclaratif, sans preuve |
| Ressources de secours dimensionnées | Capacité du site de reprise | Secours sous-dimensionné |
| Réplication supervisée | Alertes et journaux conservés | Rupture non détectée |
| Restauration en environnement sain | Procédure de reconstruction | Restauration sur infrastructure compromise |
| Organisation | ||
| Rôles et suppléants nommés | Organigramme de crise à jour | Aucun suppléant désigné |
| Coordonnées d’astreinte vérifiées | Test d’appel daté | Numéros obsolètes |
| Procédures accessibles hors du SI | Copie papier ou hors ligne | Procédure sur le serveur à restaurer |
| Modes dégradés définis | Fiches de mode dégradé | Aucun fonctionnement prévu sans SI |
| Plan de communication de crise | Messages types, canaux de repli | Communication improvisée |
| Tests | ||
| Calendrier de tests formalisé | Planning validé | Tests décidés au coup par coup |
| Exercice de crise réalisé | Compte rendu daté et périmètre | Uniquement des tests granulaires |
| Écarts du test précédent traités | Plan d’action clos | Constats reportés |
| RTO et RPO mesurés pendant le test | Relevés horodatés | Délais estimés, jamais chronométrés |
Les écarts les plus fréquemment constatés
Six écarts reviennent d’un audit à l’autre, quelle que soit la taille de l’entreprise.
- La sauvegarde est supervisée, mais la restauration ne l’est pas. Un rapport de sauvegarde réussie ne dit rien de la capacité à relire les données.
- Le RTO reste théorique. Redémarrer quarante machines virtuelles sur une plateforme prévue pour quinze allonge le délai, quelle que soit la cible.
- Les dépendances externes ne sont pas cartographiées. Restaurer les serveurs sans prévoir le lien opérateur laisse l’activité à l’arrêt malgré une reprise réussie.
- La documentation devient inaccessible au moment où elle sert : procédure sur un intranet chiffré, mots de passe sur le domaine compromis.
- Personne n’a été désigné comme suppléant. Le plan nomme un décideur unique, sans hypothèse d’indisponibilité.
- Le périmètre reste figé sur un système d’information qui a évolué. Il s’agit de l’écart le plus banal, mais aussi du plus long à corriger.
Combien de temps et quel budget prévoir ?
La durée dépend de trois variables : le nombre d’applications critiques, la présence de plusieurs sites et l’existence d’une documentation exploitable. Un dispositif documenté et déjà testé se contrôle en quelques jours. Un plan jamais éprouvé demande de reconstituer la matière.
Le test de bascule pèse le plus lourd : il mobilise l’exploitation et les référents métier sur une même fenêtre planifiée. Le cadrage et la restitution restent les phases les plus courtes.
Réaliser l’audit en interne ou le confier à un prestataire
Les deux options se défendent, et le choix dépend de l’usage prévu du rapport. Un pré-diagnostic interne suffit pour prioriser des corrections. Une exigence contractuelle, assurantielle ou réglementaire appelle un tiers.
| Audit interne | Audit externe |
| Connaissance fine du système d’information | Regard neuf sur les dépendances invisibles |
| Coût limité aux jours-homme mobilisés | Coût de prestation, à peser contre la valeur probante |
| Déclenchement rapide, sans procédure d’achat | Délai de contractualisation |
| Valeur probante faible auprès d’un client ou assureur | Rapport opposable à un tiers |
| Risque de juger son propre travail | Cotation issue d’un référentiel d’audit formalisé |
Un accompagnement PRA couvre l’audit du dispositif et sa remise à niveau, quand les écarts dépassent ce que les équipes internes peuvent absorber.