Plan de continuité d'activité (PCA) : guide 2026 en 8 étapes

Un plan de continuité d'activité (PCA) est l'ensemble documenté des stratégies, des moyens et des procédures qui permettent à une organisation de continuer à délivrer ses activités essentielles, à un niveau défini à l'avance, pendant et après une perturbation majeure : incendie, cyberattaque, défaillance d'un fournisseur, absence massive de personnel. Il répond à une question simple : si demain matin nous perdons X, que faisons-nous, qui le fait, et en combien de temps ?

La plupart des PCA échouent pour une raison qui n'a rien à voir avec leur qualité rédactionnelle : ils sont déconnectés de la réalité qu'ils sont censés protéger. Un annuaire d'astreinte vieux de dix-huit mois, un RTO de 4 heures jamais testé, un fournisseur cloud oublié dans la cartographie… Ce guide présente la méthode en 8 étapes alignée sur ISO 22301, ce que NIS2 et DORA exigent en 2026, et surtout comment faire du PCA un système vivant plutôt qu'un classeur.

L'essentiel en 30 secondes

• Le PCA maintient l'activité ; le PRA redémarre le système d'information. Le PRA est une composante du PCA, pas un substitut.
• Tout part de la BIA : sans RTO et RPO justifiés par les impacts métier, les stratégies de continuité sont des paris.
• Raisonnez par indisponibilité (données, SI, tiers, personnel, locaux) plutôt que par menace : la cause change, les effets restent.
• NIS2 (article 21) et DORA (article 11) font de la continuité une obligation, et DORA impose de tester les plans au moins une fois par an.
• Un PCA qui n'a jamais été exercé n'est qu'une hypothèse.

Qu'est-ce qu'un plan de continuité d'activité ?

La norme ISO 22301 définit le plan de continuité comme l'information documentée qui guide une organisation pour répondre à une perturbation, puis reprendre, rétablir et restaurer la fourniture de ses produits et services conformément à ses objectifs de continuité. Concrètement, un PCA poursuit trois objectifs, dans cet ordre :

1. Protéger les personnes : salariés, clients, visiteurs.
2. Maintenir les activités prioritaires à un niveau minimal acceptable pendant la perturbation (le MBCO, niveau minimal de continuité).
3. Revenir à la normale de manière maîtrisée, sans créer une seconde crise au moment de la reprise.

Un PCA n'est ni une police d'assurance (elle indemnise, elle ne fait pas tourner l'activité), ni un PRA informatique (il ne couvre qu'une partie du problème), ni un document de 300 pages rangé dans un tiroir. C'est un dispositif : des décisions prises à froid, des moyens prépositionnés et des personnes entraînées.

En France, la référence publique reste le Guide pour réaliser un plan de continuité d'activité du SGDSN (2013). L'AMRAE en a publié en 2026 une version actualisée de son propre cahier technique, qui intègre notamment les dimensions cyber et climat. À l'international, la référence est ISO 22301:2019, certifiable, dont la clause 8.4 porte précisément sur les plans et procédures de continuité.

PCA, PRA, PCI, PGC : quelle différence ?

C'est la confusion la plus fréquente, et elle coûte cher : beaucoup d'organisations pensent avoir un PCA alors qu'elles n'ont qu'un PRA informatique.

Le PCA est le chapeau : il s'appuie sur le PRA et le PCI pour le système d'information, sur le PGC pour la décision et sur le PCC pour la communication. Si vous n'avez que le PRA, vous savez restaurer vos serveurs, mais personne ne sait comment facturer, livrer ou répondre aux clients pendant les 48 heures que dure la restauration. Pour le volet technique, voir notre guide du plan de reprise d'activité (PRA).

Le PCA est-il obligatoire en 2026 ?

Pour un nombre croissant d'organisations, oui. Les principales sources d'obligation :

• NIS2 : l'article 21 impose aux entités essentielles et importantes des mesures de gestion des risques qui incluent explicitement « la continuité des activités, par exemple la gestion des sauvegardes et la reprise des activités, et la gestion des crises ». Les sanctions peuvent atteindre 10 M€ ou 2 % du chiffre d'affaires mondial pour une entité essentielle. En France, le projet de loi « Résilience » qui transpose la directive n'était toujours pas définitivement adopté à la mi-octobre 2026, et la Commission européenne poursuit les États en retard. Ce délai ne protège pas grand monde : vos clients donneurs d'ordre exigent déjà ces preuves dans leurs questionnaires fournisseurs. Voir NIS2 : entités essentielles vs importantes.
• DORA (secteur financier, applicable depuis le 17 janvier 2025) : l'article 11 exige une politique de continuité des activités de TIC, des plans de réponse et de rétablissement, et des tests au moins annuels de ces plans. L'article 12 encadre les sauvegardes, l'article 14 la communication de crise. Voir notre guide DORA 2026 et, pour les prestataires TIC, le registre d'informations DORA.
• Banque et assurance : en France, l'arrêté du 3 novembre 2014 relatif au contrôle interne impose aux établissements bancaires des plans d'urgence et de poursuite de l'activité (PUPA) ; Solvabilité II (article 41) demande aux assureurs des plans d'urgence.
• RGPD : l'article 32 exige la capacité à rétablir la disponibilité et l'accès aux données personnelles dans des délais appropriés en cas d'incident.
• ISO 22301 : volontaire, mais de plus en plus demandée dans les appels d'offres et par les assureurs cyber.

Même sans obligation réglementaire, un PCA est devenu une question commerciale : le jour où un grand client vous demande « quel est votre RTO sur la prestation que vous nous fournissez ? », il faut une réponse prouvable.

Les 8 étapes pour construire un PCA

La méthode ci-dessous suit la logique d'ISO 22301 (clauses 4 à 10) et du guide SGDSN. Elle s'applique à une PME comme à un groupe : seule la profondeur change.

Étape 1 — Cadrer : sponsor, périmètre et politique

Un PCA sans sponsor à la direction générale meurt au premier arbitrage budgétaire. ISO 22301 en fait une exigence explicite (clause 5, leadership).

• Désignez un sponsor au comité de direction et un responsable du PCA (RPCA), avec des correspondants dans chaque métier.
• Définissez le périmètre : quels produits et services, quelles entités, quels sites. Pour une première version, commencez par deux ou trois services critiques plutôt que par l'organisation entière.
• Rédigez une politique de continuité d'une à deux pages : objectifs, périmètre, rôles, fréquence de revue et de test.
• Fixez les seuils d'inacceptable : à partir de quel montant de perte, de quel retard client, de quel manquement réglementaire un impact devient-il intolérable ?

Livrable : note de cadrage validée par la direction et politique de continuité.

Étape 2 — Cartographier les activités et leurs dépendances

Pour chaque activité du périmètre, identifiez tout ce dont elle a besoin pour fonctionner :

• les personnes et compétences clés (y compris celles que personne d'autre ne sait remplacer) ;
• les applications et services informatiques, et les données qu'ils manipulent ;
• les fournisseurs et sous-traitants, y compris les éditeurs SaaS et les prestataires de rang 2 ;
• les sites, équipements et stocks ;
• les processus amont et aval dont elle dépend ou qu'elle alimente.

C'est l'étape la plus sous-estimée, et celle où les tableurs atteignent leurs limites : une même application soutient dix processus, un même fournisseur héberge trois applications. Une dépendance oubliée ici devient un angle mort le jour J. Le 19 juillet 2024, une mise à jour défectueuse de l'éditeur de sécurité CrowdStrike a mis hors service environ 8,5 millions de postes Windows, selon Microsoft : compagnies aériennes, hôpitaux et banques ont découvert en quelques heures qu'un composant que personne n'avait cartographié comme critique pouvait tout arrêter.

Étape 3 — Réaliser l'analyse d'impact sur l'activité (BIA)

La BIA mesure ce que coûte l'interruption de chaque activité dans le temps : au bout de 4 heures, de 24 heures, de 72 heures, d'une semaine, d'un mois. Évaluez l'impact sur plusieurs dimensions (financière, clients, réglementaire, image, sécurité des personnes), puis déduisez-en les indicateurs qui piloteront tout le reste du PCA :

Deux règles évitent la plupart des erreurs. D'abord, interrogez les métiers, pas l'informatique : c'est le responsable de la facturation qui sait ce que coûtent trois jours sans facturer. Ensuite, confrontez les RTO métier aux RTO techniques : une application dont la restauration prend 72 heures ne peut pas soutenir un processus dont le RTO est de 4 heures. Cet écart est la découverte la plus précieuse d'une BIA. Il faut le traiter, pas le masquer.

Pour aller plus loin : notre guide BIA en 7 étapes, RTO vs RPO, le modèle de BIA gratuit et le calculateur RTO/RPO.

Étape 4 — Analyser les risques et retenir des scénarios

Deux approches complémentaires, à mener ensemble.

Par indisponibilité. Quelle que soit la cause, une organisation ne perd jamais que cinq choses. Raisonner sur ces effets, et non sur la liste infinie des menaces, garantit qu'aucune réponse ne manque :

Par scénario. Retenez ensuite, grâce à votre analyse de risques (ISO 31000, ISO 27005, EBIOS RM), quelques scénarios à haut risque graves mais plausibles, qui combinent souvent plusieurs indisponibilités : un rançongiciel touche à la fois le SI et les données ; une inondation touche les locaux, le personnel et les fournisseurs locaux.

Le contrôle à faire est simple : chaque activité critique doit avoir une réponse pour chaque indisponibilité, et chaque scénario retenu doit être couvert par le plan.

Étape 5 — Choisir les stratégies de continuité

Pour chaque indisponibilité, listez les options, chiffrez-les, et retenez celles qui permettent de tenir les RTO au coût le plus raisonnable (ISO 22301, clause 8.3) :

• Locaux : site de repli, télétravail, accord de réciprocité, transfert d'activité vers un autre site.
• Personnel : polyvalence, suppléants nommés, documentation des savoir-faire critiques, prestataires d'appoint.
• Système d'information : redondance, PRA, bascule cloud, procédures manuelles en mode dégradé.
• Données : règle 3-2-1 avec une copie immuable ou hors ligne, et tests de restauration réguliers (une sauvegarde jamais restaurée n'est pas une sauvegarde).
• Tiers : double sourcing, stocks tampons, clauses contractuelles (engagements de service, réversibilité, plan de continuité du fournisseur), stratégie de sortie pour les prestataires critiques, que DORA impose pour les services TIC.

Règle d'or : plus le RTO est court, plus la stratégie coûte cher. Chaque choix doit pouvoir être justifié par la BIA, pas par une préférence technique. Le simulateur de coût de reprise aide à objectiver l'arbitrage.

Étape 6 — Rédiger des plans actionnables

Un PCA efficace tient en peu de pages et se lit sous stress. Structure recommandée :

1. Objet, périmètre, propriétaire, version et date de dernière revue.
2. Critères de déclenchement et niveaux d'alerte : qui peut activer le plan, et sur quels signaux ?
3. Organisation de crise : rôles, titulaires et suppléants.
4. Annuaire : équipes internes, fournisseurs critiques, autorités, assureur, avec des numéros joignables hors du SI de l'entreprise.
5. Procédures par indisponibilité et par activité : actions dans l'ordre, ressources nécessaires, objectif de délai.
6. Modes dégradés et contournements.
7. Retour à la normale : conditions, séquence, contrôles.
8. Annexes : inventaires, fiches réflexes d'une page par rôle.

Deux tests de bon sens. Le plan doit pouvoir être exécuté par un suppléant réveillé à 3 heures du matin : verbes d'action, listes à cocher, pas de paragraphes. Et il doit rester accessible quand le SI est tombé : un PCA stocké uniquement sur l'intranet qui vient de s'arrêter est inutile. Prévoyez des copies hors ligne et imprimées chez les personnes clés.

Modèles gratuits : plan de continuité d'activité, plan de reprise après sinistre, plan de communication de crise.

Étape 7 — Organiser l'alerte et la gestion de crise

Le PCA décrit quoi faire ; la gestion de crise décide quand et dans quel ordre.

• Une cellule de crise à deux niveaux : décisionnel (direction, arbitrages, communication externe) et opérationnel (pilotage des actions). Rôles indispensables : pilote, secrétaire chargé de la main courante, communication, juridique, RH, informatique, représentants métier.
• Une chaîne d'alerte testée : astreinte, arbre d'appel, notification multicanale, et un canal de secours si la messagerie de l'entreprise est elle-même compromise.
• Une main courante horodatée : chaque décision, chaque action, chaque information reçue. Elle sert à piloter, à rédiger le retour d'expérience et à répondre au régulateur.
• Des obligations de notification anticipées : NIS2 impose une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final sous un mois ; DORA fixe des délais comparables, voire plus courts, pour les incidents TIC majeurs. Préparez les trames à l'avance. Voir NIS2 : notification d'incident en 24 h, 72 h et 1 mois.
• Des messages préparés pour les salariés, les clients, les partenaires et les médias.

Pour structurer la prise de décision, voir notre article sur le plan de gestion de crise et le framework RAPID.

Étape 8 — Tester, exercer, améliorer

C'est l'étape qui transforme un document en capacité. ISO 22301 (clause 8.5) exige un programme d'exercices à intervalles planifiés et lors de changements significatifs ; DORA impose un test au moins annuel des plans de continuité TIC. Montez en puissance progressivement :

Chaque exercice doit produire un retour d'expérience : écarts constatés, actions correctives avec un responsable et une échéance, mise à jour du plan, puis passage en revue de direction (clause 9.3). L'indicateur le plus parlant pour un comité de direction est l'écart entre le RTO cible et le temps de reprise réellement mesuré.

Besoin d'idées ? Voir nos 10 scénarios d'exercice de crise.

Pourquoi tant de PCA échouent le jour J

Les retours d'expérience se ressemblent tous. Six causes reviennent sans cesse :

1. Le plan dort. Personne n'en est propriétaire, il n'a pas été revu depuis la dernière réorganisation. Remède : un propriétaire par plan, et une revue déclenchée par les changements (nouvelle application, nouveau fournisseur, déménagement), pas seulement par le calendrier.
2. Les dépendances sont invisibles. Le fournisseur SaaS, le prestataire de rang 2, l'expert unique. Remède : cartographier une fois les liens processus ↔ applications ↔ fournisseurs, et les réutiliser partout.
3. Les RTO sont déclaratifs. Annoncés, jamais mesurés. Remède : tester, et suivre l'écart entre la cible et la capacité réelle.
4. Le plan est inaccessible. Stocké sur le système qui vient de tomber. Remède : copies hors ligne, versions imprimées, annuaire hors SI.
5. Le plan est illisible. Deux cents pages que personne n'ouvre en crise. Remède : des fiches réflexes d'une page par rôle.
6. Aucune preuve pour l'auditeur. Les exercices ont eu lieu, mais rien ne le démontre. Remède : historiser les versions, les validations, les exercices et les actions correctives.

Le point commun de ces six échecs : le PCA est traité comme un document, alors que c'est un système d'information à part entière, un graphe de dépendances qui change chaque semaine. Un PCA qui tient, c'est un PCA dont chaque élément (activité, application, fournisseur, risque, procédure, exercice) est relié aux autres et mis à jour en même temps qu'eux.

Excel, Word ou logiciel de PCA ?

Un tableur et un traitement de texte suffisent pour une première version dans une petite structure mono-site, avec peu de dépendances informatiques. Au-delà, le coût de maintenance dépasse rapidement celui d'un outil dédié :

Pour approfondir : tableur ou ResiPlan ? et notre guide de choix d'un BCM SaaS pour PME.

Ce que fait ResiPlan, concrètement

ResiPlan a été conçu autour de l'idée défendue dans ce guide : un seul modèle de données, de la BIA au plan testé et aux preuves prêtes pour l'audit.

• BIA connectée : processus pré-remplis selon le secteur, calcul du RTO et de la DMIA, campagnes auprès des responsables de processus avec circuit de validation et historique des versions.
• Plans pré-remplis depuis la BIA : 8 types de plans (continuité, reprise métier, reprise informatique, réponse à incident, urgence, gestion de crise, communication de crise, résilience fournisseurs). Pour cinq d'entre eux, un premier jet est généré par IA, puis relu et validé par vos équipes.
• Dépendances reliées : processus ↔ services informatiques ↔ fournisseurs ↔ risques, avec la couverture des 5 indisponibilités et des scénarios à haut risque confrontée à vos stratégies.
• Exercices et retours d'expérience : exercices sur table, constats transformés en actions correctives suivies jusqu'à leur clôture.
• Preuves : clauses 4 à 10 d'ISO 22301, article 21 de NIS2 et DORA cartographiés, dossier de preuves téléchargeable, export Word et PDF.
• Pour les consultants : un espace par client pour piloter plusieurs missions de continuité depuis une seule interface.

Les données métier sont hébergées dans l'Union européenne. Une précision honnête : un logiciel ne rend personne « conforme » et ne certifie personne. ResiPlan structure, relie et prouve le travail que vos équipes réalisent. Essai gratuit de 7 jours, sans carte bancaire.

Checklist : votre PCA est-il prêt ?

• Un sponsor au comité de direction et un responsable du PCA sont nommés.
• La politique de continuité est écrite, validée et datée.
• Les activités critiques sont identifiées et leurs dépendances cartographiées (personnes, applications, données, fournisseurs, sites).
• Une BIA a fixé la DMIA, le RTO, le RPO et le MBCO de chaque activité critique.
• Les écarts entre RTO métier et capacités techniques sont identifiés et traités.
• Chaque activité critique a une réponse pour chacune des 5 indisponibilités.
• Les scénarios à haut risque retenus par l'analyse de risques sont couverts.
• Les stratégies retenues sont chiffrées et justifiées par la BIA.
• Les fournisseurs critiques ont des engagements contractuels de continuité et une solution de repli.
• Le plan nomme des titulaires et des suppléants pour chaque rôle.
• L'annuaire de crise est à jour et accessible hors du SI.
• Les trames de notification (NIS2, DORA, CNIL) et les messages de crise sont prêts.
• Les sauvegardes critiques ont été restaurées avec succès dans les 12 derniers mois.
• Un exercice a eu lieu dans les 12 derniers mois et ses actions correctives sont suivies.
• La direction a passé en revue le dispositif dans l'année.

Pour une évaluation plus complète : checklist ISO 22301, autodiagnostic NIS2, checklist de préparation DORA.

FAQ

Quelle est la différence entre un PCA et un PRA ?

Le PCA vise à maintenir les activités essentielles pendant une perturbation, sur tout le périmètre de l'organisation (métiers, personnes, locaux, fournisseurs, SI). Le PRA vise à redémarrer après un arrêt, essentiellement le système d'information. Le PRA est une composante du PCA.

Combien de temps faut-il pour réaliser un PCA ?

Pour une PME de 50 à 250 personnes qui démarre sur deux ou trois services critiques, comptez en pratique 6 à 12 semaines pour une première version exercée. Pour un groupe multi-sites, plusieurs mois. Le facteur limitant est rarement la rédaction : c'est la disponibilité des métiers pour la BIA.

Qui doit rédiger le PCA ?

Le responsable du PCA coordonne, mais les métiers rédigent leurs procédures : eux seuls savent comment travailler en mode dégradé. L'informatique rédige le PRA, la direction valide la politique et les arbitrages. Un PCA écrit par un consultant seul, sans les équipes, ne sera pas appliqué. Côté conseil, voir comment industrialiser une mission PCA.

À quelle fréquence faut-il tester un PCA ?

Au moins une fois par an pour un exercice significatif (c'est une obligation pour les plans de continuité TIC sous DORA), et après chaque changement majeur : nouvelle application critique, nouveau fournisseur, déménagement, réorganisation.

Le PCA est-il obligatoire pour une PME ?

Il l'est pour les PME qui entrent dans le champ de NIS2 (entités essentielles ou importantes) ou de DORA, ainsi que pour certaines activités régulées. Pour les autres, il devient une exigence de fait de la part des clients, des assureurs et des appels d'offres.

Faut-il être certifié ISO 22301 ?

Non, la certification est volontaire. Mais suivre la structure de la norme garantit que votre PCA couvre ce que les auditeurs, les régulateurs et les grands clients attendent. C'est ce qui permet de passer une certification plus tard, si elle devient un atout commercial : voir certification ISO 22301 : étapes, durée et coût.

Que doit contenir un PCA au minimum ?

Un périmètre et un propriétaire, des critères de déclenchement, une organisation de crise avec des suppléants, un annuaire accessible hors SI, des procédures par activité critique et par indisponibilité, des modes dégradés, une procédure de retour à la normale, et la trace du dernier exercice.

Pour aller plus loin

• Plan de reprise d'activité (PRA) : guide complet
• Cellule de crise : composition, rôles et activation
• ISO 22301 en 10 étapes : implémenter un BCMS conforme
• BIA en 7 étapes, avec modèle gratuit
• ISO 22301 vs ISO 27001 : différences et recouvrement
• DORA vs NIS2 : quelle réglementation s'applique à vous ?
• Générateur de plan de continuité

Un PCA n'a de valeur que le jour où il sert. Entre-temps, sa qualité se mesure à une seule chose : sa capacité à rester vrai pendant que l'organisation change autour de lui.