PCA (plan de continuité d’activité)

Un plan de continuité d’activité organise le maintien des fonctions essentielles pendant une perturbation. Il identifie les activités prioritaires, les ressources nécessaires et les responsabilités. Il dépasse l’informatique : personnes, locaux, fournisseurs et communications peuvent aussi être concernés.

Le PCA part des conséquences d’un incident sur l’activité. Il ne consiste pas à garantir que rien ne tombera en panne. Il décrit ce que l’organisation doit pouvoir continuer à faire, dans quelles conditions et avec quels moyens. Le fonctionnement dégradé doit rester adapté aux contraintes du métier.

Identifiez les activités dont l’arrêt crée les conséquences les plus importantes. Examinez leurs dépendances : logiciels, connexion, équipements, personnes et prestataires. Une activité qui paraît autonome peut dépendre d’un service partagé ou d’un compte unique.

Les priorités doivent être validées par le métier. Le service informatique peut proposer des moyens, mais il ne décide pas seul du niveau acceptable de perturbation. Les objectifs doivent être réalistes et reliés aux ressources disponibles. Une liste de services critiques sans ordre ni responsable reste difficile à utiliser.

Le PCA traite le maintien de l’activité pendant l’incident. Le PRA organise la remise en service des systèmes après une interruption. La sauvegarde fournit des copies pour la récupération. Ces dispositifs se complètent, mais leurs objectifs ne sont pas identiques.

Un processus manuel peut permettre de continuer une activité pendant la restauration d’une application. Une connexion de secours peut maintenir certains accès sans reprendre tout le site. Le plan doit préciser les limites et les conditions de retour à un fonctionnement normal.

Imaginons un établissement dont la connexion principale devient indisponible. Le PCA identifie les opérations à maintenir et les services qui peuvent attendre. Un accès de secours est prévu pour les usages prioritaires, selon sa couverture et sa capacité testées.

L’équipe connaît la personne qui déclenche le mode dégradé et celle qui contacte les fournisseurs. Les applications sont vérifiées une par une. Certaines sessions peuvent être interrompues ; le plan ne doit pas promettre une bascule transparente sans preuve.

Ce scénario est illustratif. Le test doit inclure la communication aux utilisateurs et le retour à l’accès principal. Une solution technique installée mais jamais utilisée par l’équipe ne démontre pas la continuité de l’activité.

Le plan doit identifier les décideurs, les intervenants et leurs remplaçants. Les coordonnées doivent rester accessibles lorsque le système habituel est indisponible. Prévoyez les messages et les canaux utilisables pour informer les équipes et les personnes concernées.

Les procédures doivent être courtes et compréhensibles. Une personne doit pouvoir savoir quoi faire sans rechercher un document dans une application en panne. Les décisions prises pendant l’incident doivent être enregistrées avec les moyens disponibles pour préparer le retour à la normale.

Un exercice permet de vérifier les dépendances, les rôles et les moyens prévus. Il peut être limité à un scénario pour éviter d’exposer la production. Documentez les difficultés et les corrections nécessaires. Le succès d’un composant ne signifie pas que tout le processus fonctionne.

Revoyez le plan lorsque les activités, les logiciels ou les personnes changent. Une procédure qui mentionne un ancien fournisseur ou un compte disparu peut devenir inutilisable. La continuité dépend de l’entretien du dispositif autant que de sa rédaction initiale.

Le fonctionnement dégradé peut créer des informations hors du système habituel : notes, listes ou opérations différées. Définissez où les conserver et qui les reprend ensuite. Le retour à la normale doit éviter les pertes et les doublons. Un exercice doit donc aller jusqu’à cette reprise, même si la première partie montre que l’équipe peut continuer à travailler pendant la perturbation.

Commencez par une activité essentielle et un scénario crédible. Décrivez les conséquences, les ressources et les responsabilités. Identifiez les moyens de fonctionnement dégradé qui peuvent être utilisés avec les contraintes réelles de l’équipe.

Préparez un exercice adapté, avec des conditions de sécurité et un responsable. Vérifiez les accès, la communication et les opérations nécessaires. Le compte rendu doit annoncer ce qui a été testé et ce qui reste à valider.

Conservez le plan dans un emplacement accessible en cas d’incident. Désignez son propriétaire et les situations qui demandent une révision. Reliez-le au PRA et aux sauvegardes sans confondre leurs objectifs. Le livrable doit guider une action concrète, avec des moyens et des limites connus.

Pour les principes de préparation et de reprise, voir le guide de sécurité des données personnelles de la CNIL.

Référence consultée le 10 octobre 2026.