Le plan de continuité d’activité (PCA) organise le maintien des services prioritaires lors d’une interruption. Il relie les besoins métiers, les dépendances, les moyens de secours et les décisions de crise. Le guide du SGDSN pour réaliser un PCA constitue une référence méthodologique ; les guides ANSSI complètent cette démarche pour les crises d’origine cyber.
La continuité doit être dimensionnée selon les activités, les risques et les exigences applicables. Ce guide propose une démarche opérationnelle et un exemple fictif, sans supposer que toutes les organisations ont les mêmes délais, budgets ou obligations sectorielles.
Pour approfondir : PSSI ANSSI, SecNumCloud, cartographie SI.
Points clés
- Le PCA répond aux sinistres majeurs ; le PRA (Plan de Reprise d’Activité) couvre le redémarrage technique.
- La démarche proposée ici structure le PCA en cinq étapes : cadrage, BIA, scénarios, stratégies, mise en œuvre/tests.
- NIS 2 (art. 21) et DORA (art. 11) imposent la continuité d’activité aux entités régulées.
- Les exercices vérifient les hypothèses du plan ; leur programme dépend du risque et des exigences applicables.
- Les délais cibles (RTO, RPO, MTPD) doivent être validés par les métiers, pas imposés par l’IT.
1. Périmètre : PCA, PRA, PCI — clarifier les termes
Trois plans souvent confondus :
| Plan | Objet | Périmètre |
|---|---|---|
| PCA (Plan de Continuité d’Activité) | Maintien des activités essentielles | Organisation entière (métier + IT) |
| PRA (Plan de Reprise d’Activité) | Redémarrage technique post-sinistre | Systèmes d’information |
| PCI (Plan de Continuité Informatique) | Continuité des services IT | Infrastructure et applications |
Le PCA est le parent ; le PRA en est la composante technique.
2. Étape 1 — Cadrage du projet PCA
Désignez un sponsor de direction capable d’arbitrer les priorités, les ressources et les désaccords entre métiers. Nommez aussi un responsable de maintenance du plan.
Livrables du cadrage :
- Note de cadrage validée en COMEX
- Périmètre (sites, filiales, activités incluses/exclues)
- Comité de pilotage PCA (RSSI, DSI, métiers, RH, juridique, communication)
- Budget justifié par les activités prioritaires, les ressources nécessaires et les solutions retenues
3. Étape 2 — Bilan d’Impact sur l’Activité (BIA)
Le BIA (bilan d’impact sur l’activité) examine les conséquences d’une interruption dans le temps : sécurité des personnes, engagements, finances, obligations et capacité de reprise. Le responsable métier décrit le service minimal acceptable, les périodes sensibles et la durée maximale d’interruption admissible.
Les objectifs de reprise (RTO) et de perte de données admissible (RPO) doivent être cohérents avec cette analyse. Il n’existe pas une grille universelle classant toute activité à quatre, vingt-quatre ou soixante-douze heures. Documentez les hypothèses, les dépendances et la validation du métier avant de comparer les moyens techniques du PRA.
4. Étape 3 — Scénarios de sinistre
Pour ouvrir l’analyse, examinez quatre familles de scénarios :
- Indisponibilité d’un site (incendie, inondation, attentat)
- Indisponibilité du SI (cyberattaque, ransomware) — durée variable
- Indisponibilité des personnes (pandémie, grève, accident collectif)
- Indisponibilité d’un prestataire critique (cloud, télécom, sous-traitant)
Dans un scénario cyber, envisagez aussi l’indisponibilité des outils habituels de communication et de l’annuaire. Le plan ne doit pas supposer que les moyens de coordination restent tous accessibles.
5. Étape 4 — Stratégies de continuité
Pour chaque scénario, définir les moyens de contournement :
- Site de repli (hot site, warm site, cold site)
- Télétravail massif (testé pendant le COVID-19)
- Sous-traitance d’urgence (contrats de réversibilité)
- Procédures dégradées manuelles (formulaires papier, téléphone)
Comparez les coûts de mise en place, de fonctionnement, d’exercice et de retour au service normal. Une solution moins coûteuse peut impliquer un mode dégradé plus long ; faites valider cette conséquence par le métier.
6. Étape 5 — Mise en œuvre et tests
Construisez un programme d’exercices progressif : lecture croisée des consignes, exercice sur table, vérification d’une procédure et exercice impliquant les dépendances critiques. Pour chaque séance, indiquez le scénario, le périmètre, les objectifs et les conditions d’arrêt. Une fréquence interne choisie doit être distinguée d’une exigence réglementaire ou contractuelle.
Conservez les observations, les écarts, leur responsable et la vérification corrective. Un exercice exécuté sans traitement des anomalies ne suffit pas à montrer que l’organisation peut fonctionner dans le scénario prévu.
Exemple fictif : assurer la prise de commandes pendant une panne de l’ERP
Une PME prépare un exercice sur table : l’ERP devient inaccessible au début de la journée. La responsable commerciale identifie le service à maintenir — recevoir les commandes et informer les clients — tandis que le responsable logistique précise les opérations suspendues. La validation des stocks et l’expédition dépendent de l’ERP ; la simple disponibilité de la messagerie ne suffit donc pas à poursuivre toute l’activité.
L’équipe parcourt cinq décisions avant de jouer le scénario :
- Décrire l’interruption. L’ERP est indisponible ; le portail et la téléphonie restent accessibles dans cette hypothèse. Une seconde variante pourra retirer aussi ces moyens pour éviter de bâtir le plan sur une dépendance oubliée.
- Vérifier les dépendances. L’exploitation confirme quels accès, annuaires, interfaces et prestataires sont nécessaires au mode de secours. Les équipes confrontent cette liste à leur carte du SI et vérifient que les consignes restent accessibles hors de l’ERP.
- Définir le mode dégradé. Le commercial reçoit les demandes dans le support de secours prévu, leur attribue une référence et annonce qu’une confirmation suivra après vérification des stocks. Le responsable métier fixe les opérations autorisées pendant ce fonctionnement ; l’exercice utilise uniquement des commandes fictives.
- Nommer les décideurs. Le directeur de crise décide de l’activation et du retour au fonctionnement normal. L’exploitation suit la reprise technique ; le commercial tient la liste des demandes en attente ; la logistique organise leur rapprochement avant exécution.
- Mesurer le résultat. Le compte rendu relève le délai de contact des responsables, les demandes effectivement reçues, les consignes introuvables et les doublons détectés à la reprise. Chaque écart devient une action attribuée, avec une échéance et une vérification prévue.
Supposons que l’exercice révèle un annuaire de secours stocké uniquement dans l’ERP. L’action est alors précise : rendre la copie de secours accessible aux personnes prévues, en vérifier l’actualité et rejouer l’appel. Pour reconstituer l’ordre des événements sans confondre déclarations et observations, l’équipe rapproche le compte rendu des journaux de sécurité disponibles.
Le résultat attendu du PCA est la capacité du métier à poursuivre le service défini et à résorber les demandes en attente. Le PRA apporte la preuve du redémarrage technique. L’exercice relie ces deux résultats : une application redémarrée ne clôt pas le scénario tant que les commandes n’ont pas été rapprochées et que le métier n’a pas validé la reprise.
7. Relier les obligations applicables au plan
L’article 21 §2 c) de la directive NIS 2 vise notamment la continuité, les sauvegardes, la reprise et la gestion de crise. L’assujettissement et les dispositions nationales doivent être examinés selon la situation de l’entité ; consultez le suivi de la transposition française de NIS 2 avant de retenir une obligation précise.
Le règlement DORA comporte des exigences de continuité et de tests pour les entités financières relevant de son champ. Les tests avancés fondés sur la menace concernent les entités identifiées selon les conditions de l’article 26 ; ils ne s’appliquent pas automatiquement à toute « grande entreprise ». Le guide DORA aide à préparer l’analyse du périmètre.
8. Fiche de correspondance des exigences
Pour chaque exigence identifiée, indiquez le texte et l’article, l’entité concernée, le livrable, le responsable et la preuve. Reliez par exemple une exigence de restauration à une procédure et au résultat observé d’un exercice. Le travail de cartographie des preuves ReCyF permet d’organiser cette correspondance sans confondre une recommandation, une obligation et une preuve d’exécution.
9. Gouvernance et cellule de crise
Le PCA s’appuie sur une cellule de crise dont les conditions d’activation et la disponibilité sont définies selon le besoin, articulée avec le playbook de gestion de crise cyber. Fonctions à attribuer selon le scénario :
- Directeur de crise (souvent DG ou COO)
- RSSI / responsable PCA
- Communication (interne + externe)
- Juridique (notifications CNIL, ANSSI)
- Métiers concernés
- DSI / production IT
L’ANSSI publie un guide « Crise d’origine cyber, les clés d’une gestion opérationnelle et stratégique » (2021) qui complète utilement le PCA.
10. Documentation minimale
Un PCA défendable contient :
- Politique de continuité (signée DG)
- BIA daté, validé et réexaminé lors des changements pertinents
- Scénarios de sinistre documentés
- Procédures de bascule (PRA, télétravail, site de repli)
- Annuaires de crise accessibles en secours, limités aux coordonnées nécessaires
- Comptes rendus des exercices et suivi des actions correctives
- Plan de communication de crise
11. Erreurs fréquentes
- PCA copié d’un modèle sans analyse des impacts métiers
- RTO/RPO fixés par l’IT sans validation métier — irréalistes
- Programme d’exercices non exécuté — hypothèses de continuité non vérifiées
- Annuaires de crise obsolètes — découvert au pire moment
- Pas de plan de communication — gestion de crise chaotique
12. Outils et certifications
Référentiels utiles :
- ISO 22301 (Système de management de la continuité d’activité)
- ISO 27031 (Continuité IT)
- Guide SGDSN pour réaliser un PCA
- Guide ANSSI crise cyber (2021)
Vérifiez la version du référentiel et le périmètre d’une éventuelle certification. Une certification ne remplace pas la vérification des procédures nécessaires à votre scénario.
FAQ
Quelle est la différence entre PCA et PRA ?
Le PCA couvre la continuité des activités métier dans son ensemble (humains, locaux, procédures, SI). Le PRA est la composante technique : redémarrage des systèmes d’information après sinistre. Le PRA est un sous-ensemble du PCA.
Le PCA est-il obligatoire pour mon entreprise ?
Analysez les textes sectoriels, le statut de l’entité et les engagements contractuels. Le seul effectif ne suffit pas à trancher tous les cas. Conservez les références et les conditions qui fondent votre conclusion, puis traduisez les obligations applicables en actions et preuves identifiables.
Quel budget prévoir pour un PCA ?
Chiffrez les ressources humaines, les moyens de secours, les prestataires, les exercices et la maintenance. Comparez plusieurs scénarios avec leurs délais et capacités, puis faites arbitrer le niveau de service acceptable. Aucun pourcentage unique du budget informatique ne décrit toutes les situations.
À quelle fréquence tester son PCA ?
Fixez un programme selon les risques, les changements et les exigences applicables. Une modification majeure d’application, de site ou de prestataire peut justifier de rejouer un scénario avant la prochaine échéance planifiée. Vérifiez ensuite les corrections issues de l’exercice.