Plan de continuité d’activité : les objectifs et le périmètre
Un Plan de continuité d’activité (PCA) décrit comment une organisation maintient ses services essentiels lorsqu’un événement perturbe son fonctionnement. Il ne se limite pas au redémarrage informatique : il traite aussi des personnes, des locaux, des fournisseurs et des décisions à prendre en situation de crise.
Ses Objectifs sont concrets : préserver les activités prioritaires, limiter les conséquences d’une interruption et organiser un retour maîtrisé au fonctionnement habituel. Le Périmètre précise les entités, les sites, les processus et les dépendances couverts. Sans ces limites clairement définies, le document risque d’être trop général pour guider une équipe.
Clarifier le rôle du PCA et du PRA
Le PCA organise la continuité des activités dans leur ensemble ; le Plan de reprise d’activité (PRA) décrit plus précisément la remise en service des systèmes ou des infrastructures. Le PRA constitue donc généralement un volet technique du dispositif, même si les termes varient selon les organisations.
Selon ISO 22301, les procédures doivent permettre de répondre aux perturbations et de reprendre les activités selon des objectifs définis. Pour une PME fictive qui reçoit des commandes par son ERP, le PCA peut prévoir une saisie temporaire hors ligne, tandis que le PRA décrit la restauration de l’application.
Pour cadrer le document, consignez les éléments suivants :
- Activités essentielles et services concernés
- Sites, équipes et entités inclus dans le périmètre
- Fournisseurs et ressources dont dépend la continuité
- Responsable du document et modalités d’approbation
Analyse d’impact et BIA : établir les priorités du PCA
Une fois le périmètre choisi, l’Analyse d’impact aide à déterminer quelles interruptions menaceraient le plus l’organisation. Le BIA, ou bilan d’impact sur l’activité, recueille les conséquences possibles dans le temps : retards de livraison, obligations non respectées, pertes financières ou atteinte à la sécurité des personnes.
Définir des objectifs de reprise validés par les métiers
Le BIA sert à fixer les priorités et à expliciter les besoins de reprise. Le RTO désigne le délai visé pour rétablir une activité ou un service ; le RPO correspond à la perte de données jugée acceptable. Ces objectifs doivent être validés par les responsables métiers, car l’équipe informatique ne peut pas décider seule du niveau de service nécessaire.
Selon ISO 22301, l’analyse des conséquences et des dépendances alimente les stratégies de continuité. Un commerce peut, par exemple, accepter de suspendre temporairement l’analyse détaillée des stocks, mais pas de perdre les coordonnées des commandes déjà reçues. Les objectifs retenus doivent refléter ces arbitrages et leurs hypothèses.
Les résultats du BIA peuvent être présentés simplement :
| Élément étudié | Question à documenter | Utilisation dans le PCA |
|---|---|---|
| Processus métier | Quelle activité doit continuer en priorité ? | Ordre de priorisation |
| Impact d’une interruption | Quelles conséquences apparaissent avec le temps ? | Évaluation de criticité |
| RTO | Quel délai de reprise est acceptable ? | Choix des moyens de secours |
| RPO | Quelle perte de données est tolérable ? | Exigences de sauvegarde |
| Dépendances | Quels outils, personnes ou prestataires sont nécessaires ? | Repérage des points de défaillance |
Scénarios de crise, gouvernance et responsabilités
Après avoir identifié les activités prioritaires, l’organisation peut examiner les événements susceptibles de les interrompre. L’Analyse des risques aide à sélectionner des Scénarios de crise réalistes, sans chercher à prévoir toutes les situations possibles.
Organiser les décisions et les communications
La Gouvernance décrit qui peut activer le PCA, qui arbitre les priorités et qui communique avec les équipes ou les partenaires. Les Rôles et responsabilités doivent inclure des suppléants : une procédure qui dépend d’une seule personne peut devenir inutilisable si celle-ci est indisponible.
Selon ISO/IEC 27001:2022, les contrôles A.5.29 et A.5.30 portent respectivement sur la continuité de la sécurité de l’information et la préparation des technologies de l’information à la continuité. Le PCA doit donc examiner les risques cyber en plus des sinistres physiques, des pannes et de l’indisponibilité du personnel.
Pour chaque scénario, indiquez les responsables, les critères de déclenchement et les premiers gestes. Une panne ERP, par exemple, appelle des consignes différentes d’un rançongiciel qui touche aussi les outils de communication.
Les scénarios à examiner peuvent comprendre :
- Cyberattaque ou indisponibilité majeure du système d’information
- Panne d’un site, d’un réseau ou d’une infrastructure essentielle
- Absence importante de personnel ou accès impossible aux locaux
- Défaillance d’un fournisseur ou d’un service externalisé critique
Un annuaire de crise et une copie du PCA doivent rester accessibles si le réseau interne est indisponible. Cette précaution évite qu’une panne informatique empêche l’équipe de consulter les consignes censées l’aider.
Procédures de continuité et plan de reprise opérationnel
Les scénarios prennent leur valeur lorsqu’ils débouchent sur des actions exécutables. Les Procédures de continuité expliquent comment poursuivre les activités en mode dégradé ; le Plan de reprise précise comment rétablir progressivement les moyens habituels.
Documenter les gestes utiles en situation réelle
Chaque fiche devrait indiquer le déclencheur, les décisions à prendre, les personnes à contacter, les ressources nécessaires et les critères de retour à la normale. Une consigne comme « prévenir les équipes » reste trop vague si elle ne précise pas qui appelle, avec quel moyen et selon quelle priorité.
Pour une panne d’ERP, une PME pourrait recevoir les commandes sur un support de secours, leur attribuer une référence et différer leur validation jusqu’au contrôle des stocks. La procédure doit préciser qui autorise ce mode, comment éviter les doublons et qui rapproche les enregistrements après le redémarrage.
Le tableau ci-dessous distingue les mesures de continuité des étapes de reprise. Les moyens retenus dépendent des résultats du BIA, des risques et des ressources réellement disponibles.
| Situation | Continuité immédiate | Reprise organisée |
|---|---|---|
| ERP indisponible | Enregistrement temporaire des commandes | Contrôle puis saisie dans le système rétabli |
| Locaux inaccessibles | Activation du lieu ou mode de travail de secours prévu | Retour après vérification de la sécurité des locaux |
| Réseau indisponible | Utilisation des moyens de communication alternatifs autorisés | Rétablissement et contrôle des accès |
| Fournisseur critique défaillant | Application des solutions de contournement prévues | Reprise après validation du service et des échanges |
La continuité ne doit pas affaiblir la sécurité : les outils alternatifs, les accès de secours et les échanges de fichiers doivent rester encadrés. Les procédures doivent également être disponibles hors ligne et compréhensibles par les personnes qui les appliqueront.
Tests et mise à jour : garder un PCA réellement utilisable
Un document approuvé ne prouve pas que les équipes sauront agir quand une interruption survient. Les Tests et mise à jour vérifient les hypothèses, révèlent les consignes imprécises et permettent de corriger les dépendances oubliées.
Tester, corriger, puis réviser le document
Un exercice sur table permet à la cellule de crise de dérouler un scénario sans interrompre les opérations. L’équipe peut vérifier qui prend la décision, si l’annuaire fonctionne et si les procédures restent accessibles en cas de panne du système d’information.
La directive NIS 2 prévoit des mesures de gestion des risques pour les entités relevant de son champ, dont la continuité des activités et la gestion des incidents. L’applicabilité dépend toutefois du statut de l’organisation et du cadre national en vigueur ; il faut donc vérifier le périmètre réglementaire avant d’affirmer qu’une obligation s’applique.
Après chaque exercice, consignez les constats, les actions correctives, leur responsable et leur échéance. Une révision est aussi nécessaire après un changement important : nouvel outil critique, déménagement, réorganisation ou remplacement d’un prestataire essentiel.
Un cycle de maintenance réaliste comprend :
- Relecture périodique du BIA et des priorités métiers
- Vérification des contacts et des moyens de secours hors ligne
- Exercice adapté aux scénarios les plus importants
- Suivi des corrections et approbation des versions révisées
Selon les principes d’ISO 22301, les exercices doivent contribuer à vérifier l’efficacité des dispositions de continuité. La fréquence doit être définie en fonction des risques, des changements et des obligations applicables, plutôt que présentée comme un chiffre universel.
Sources : ISO 22301:2019, « Sécurité et résilience — Systèmes de management de la continuité d’activité » ; ISO/IEC 27001:2022, « Sécurité de l’information, cybersécurité et protection de la vie privée — Systèmes de management de la sécurité de l’information » ; directive (UE) 2022/2555, dite NIS 2.
Mieux mesurer le risque, pour décider plus sereinement
Qu'il s'agisse de CVA, de régulation bancaire, de dérivés ou de stratégie d'investissement, chaque repère compris est un pas de plus vers une gestion du risque plus rigoureuse et plus lisible. Aucun modèle ne remplace le jugement professionnel, mais il permet d'aborder chaque décision avec plus de clarté.
Pour aller plus loin
- Croiser plusieurs sources et méthodologies avant de conclure sur un niveau de risque
- Documenter les hypothèses de chaque modèle, jamais les considérer comme acquises
- Suivre les évolutions réglementaires qui peuvent changer le cadre du jour au lendemain
- Revoir régulièrement ses estimations plutôt que de les figer une fois pour toutes
