L’essentiel sur le PCA informatique en entreprise
Un PCA informatique, ou plan de continuité d’activité appliqué au système d’information, décrit comment une entreprise continue de fonctionner pendant une panne, une cyberattaque ou la perte d’un site. Le PRA, plan de reprise d’activité, organise le retour à la normale une fois l’incident maîtrisé. Un exemple de PCA informatique exploitable en PME tient en cinq à dix pages et contient cinq éléments :
- les activités qui ne peuvent pas s’arrêter, souvent trois ;
- pour chacune, un délai d’interruption toléré (RTO) et une perte de données admissible (RPO) ;
- des modes dégradés utilisables sans informatique ;
- un scénario de bascule vers une infrastructure de secours ;
- deux responsables nommés et joignables.
PCA, PRA, résilience : ce que recouvrent les termes
Le plan de continuité d’activité couvre la phase pendant laquelle le système d’information est indisponible : il organise le mode dégradé pour que l’activité ne s’arrête pas. Le plan de reprise d’activité informatique intervient ensuite, pour restaurer les données et redémarrer les environnements à partir de sauvegardes vérifiées. Le couple PCA PRA informatique répond à deux moments distincts du même incident, et les confondre revient à surdimensionner l’un en négligeant l’autre.
Deux indicateurs définis par la norme ISO 22301 chiffrent un plan de continuité : le RTO fixe la durée d’interruption maximale admissible d’un service, le RPO l’ancienneté des données que l’entreprise accepte de perdre — quinze minutes, une heure, vingt-quatre heures. Ces deux chiffres, et non le budget, déterminent l’architecture de résilience à construire : réplication, sauvegarde externalisée, site de secours actif ou dormant. Les hébergeurs et opérateurs cloud français, Naitways parmi eux, interviennent sur ce volet auprès des PME et ETI sans second datacenter.
Un PCA informatique reste un document d’exploitation : s’il n’est pas lisible en dix minutes sous pression, il ne sert à rien. Le guide du SGDSN ajoute un avertissement utile : un plan limité au périmètre informatique protège des serveurs sans protéger l’activité.
Exemple de PCA informatique : une PME industrielle de 80 salariés
L’exemple qui suit est celui d’un fabricant de pièces mécaniques de 80 salariés : deux serveurs sur site pour l’ERP et les fichiers, une messagerie en SaaS, un logiciel de supervision relié aux machines.
Les activités critiques d’un fabricant industriel
Le PCA de cette PME n’en retient que trois : la supervision de l’atelier, la prise de commande et l’expédition. La comptabilité, la paie et le marketing peuvent s’arrêter deux jours. Cette hiérarchisation est l’exercice le plus utile du plan, et le plus souvent bâclé.
Le temps d’arrêt d’activité limité
Dans cette entreprise, la supervision ne tolère que quatre heures d’arrêt, au-delà desquelles les machines stoppent. La prise de commande tolère une journée, l’expédition une demi-journée.
Les modes dégradés
Des bons de commande et de livraison papier sont imprimés chaque semaine et rangés à l’accueil de l’usine. L’atelier conserve une copie locale des gammes des dix références les plus produites, exportée chaque nuit sur un poste isolé.
La bascule
L’ERP de cette PME est répliqué sur une infrastructure cloud externe, avec un point de reprise à quinze minutes. Elle est déclenchée par le responsable informatique ou, à défaut, par le directeur de production, tous deux nommés dans le plan.
La communication
Une liste SMS prévient les 80 salariés, une autre les principaux clients, avec des messages pré-rédigés.
Trois scénarios à écrire noir sur blanc
Le premier scénario à documenter dans un PCA informatique est le rançongiciel. L’ANSSI rappelle que les sauvegardes accessibles depuis le réseau restent exposées : le plan précise quelle copie est isolée, qui la restaure et sur quelle infrastructure — pas celle qui vient d’être chiffrée.
Le deuxième scénario est la perte du site : incendie, dégât des eaux, coupure électrique longue. La question devient organisationnelle — où travaillent les équipes, avec quels équipements ? Dix portables préconfigurés et un accès distant testé suffisent.
Le troisième scénario est la panne d’un service tiers, messagerie ou plateforme fournisseur : l’entreprise ne peut que contourner, via un canal de secours connu à l’avance.
Un PCA qui n’est pas testé n’existe pas
Un plan de continuité se teste deux fois par an, par un exercice sur table d’une heure réunissant les personnes qu’il nomme : la mise en situation révèle plus de failles qu’un audit. Une bascule réelle annuelle confirme le reste du dispositif.
La partie technique d’un PCA — réplication, points de reprise, secours à froid ou à chaud — se traite avec l’hébergeur, une fois les délais fixés côté métier.
Questions fréquentes sur le PCA informatique
Quelle est la différence entre un PCA et un PRA informatique ?
Le PCA maintient l’activité pendant l’incident, grâce aux modes dégradés et à une bascule sur une infrastructure de secours. Le PRA organise le retour à la normale : restauration des sauvegardes, redémarrage des environnements, contrôle des données. Les deux plans se rédigent ensemble et partagent les mêmes indicateurs, RTO et RPO.
Combien de pages doit faire un PCA informatique ?
Un PCA informatique de cinq à dix pages suffit à une PME. Au-delà, le document devient illisible en situation de crise, précisément le moment où il sert. Mieux vaut un plan court, à jour et connu des personnes concernées qu’un document exhaustif que personne n’a ouvert depuis deux ans.
À quelle fréquence tester son plan de continuité ?
Un plan de continuité se teste par deux exercices sur table par an, d’une heure chacun, et une bascule réelle annuelle. Chaque test remonte des écarts : contacts obsolètes, accès manquants, procédure jamais essayée. Un plan jamais testé décrit une organisation théorique, rarement celle qui existe.
Quelles erreurs reviennent le plus souvent ?
Trois erreurs reviennent dans les PCA informatiques : classer toutes les applications comme critiques, ce qui revient à ne rien prioriser ; stocker le plan sur le seul serveur de fichiers, donc le rendre inaccessible le jour utile ; le confier au seul service informatique, qui oubliera les décisions métier.
Sources
- SGDSN, Guide pour réaliser un plan de continuité d’activité — sgdsn.gouv.fr
- SGDSN, Guide de la continuité d’activité (plateforme de formation) — guide-continuite-activite.sgdsn.gouv.fr
- ANSSI et ministère de la Justice, Attaques par rançongiciels, tous concernés — messervices.cyber.gouv.fr
- ISO 22301:2019, Sécurité et résilience — Systèmes de management de la continuité d’activité — iso.org
0 commentaires