PCA informatique : de quoi parle-t-on exactement ?
Un plan de continuité d’activité (PCA) rassemble les procédures qui permettent à une entreprise de continuer à travailler en cas de crise majeure : panne, cyberattaque, sinistre. Sa part technique, le plan de continuité informatique (PCI), précise ce qui doit rester disponible dans le système d’information : applications, serveur, messagerie, téléphonie, accès à distance. Le PCA ne répare rien. Il vise à assurer la continuité des activités, c’est-à-dire à décider de ce qui continue, comment, et pendant combien de temps. C’est aussi un moyen de renforcer la résilience de l’entreprise face aux cyberattaques et aux pannes.
| Plan | Question à laquelle il répond | Quand il agit | Périmètre |
|---|---|---|---|
| PCA | Comment continue-t-on à travailler ? | Pendant la crise | Toute l’activité : équipes, locaux, fournisseurs, système d’information |
| PCI (volet technique du plan) | Quels outils doivent rester disponibles, et avec quel mode dégradé ? | Pendant la crise | Applications, serveur, réseau, téléphonie |
| PRA | Comment remet-on les systèmes en état de marche ? | Après la crise | Restauration des données et des systèmes |
On croise aussi le sigle PRI, plan de reprise informatique, qui désigne la version technique du plan de reprise d’activité (PRA). Nous détaillons les plans de reprise dans notre article pour préparer un PRA informatique. Dans le duo PRA et PCA, le PCA évite que l’activité s’arrête net, le PRA ramène l’entreprise à son fonctionnement normal. Cet article s’arrête au premier.
Un plan de continuité est-il obligatoire pour une PME ?
Aucune loi n’impose un plan de continuité à toutes les entreprises. Quand l’obligation existe, elle vient d’un texte sectoriel ou d’un contrat :
- Le secteur financier : le règlement européen DORA, applicable depuis le 17 janvier 2025, exige une politique de continuité documentée et testée.
- La directive NIS2 : elle range la continuité d’activité, la gestion des sauvegardes et la gestion de crise parmi les mesures attendues des entités concernées. En octobre 2026, sa transposition en droit français n’est pas achevée, le texte étant en cours d’examen au Parlement. Notre article sur les obligations NIS2 pour les entreprises fait le point.
- Les contrats et l’assurance : un client, un donneur d’ordre ou un assureur cyber peut vous demander de démontrer que vous savez continuer à travailler après une crise.
- Les normes ISO : l’ISO 22301 encadre le management de la continuité d’activité, l’ISO 27001 rattache la continuité au management de la sécurité de l’information. Elles restent volontaires, sauf si un contrat ou un appel d’offres les exige.
Sans obligation, la CNIL recommande de rédiger un plan de continuité et de reprise d’activité, même sommaire, avec la liste des intervenants. Pour une PME, un plan court et testé vaut mieux qu’un dossier épais que personne n’a relu.
Les scénarios que le plan doit couvrir dans une PME
Le plan complète la cybersécurité : l’antivirus et le pare-feu réduisent la probabilité d’une attaque, il limite ses conséquences. Il se construit à partir de scénarios précis. Pour une PME, cinq suffisent généralement à démarrer :
- La panne du serveur ou d’une application critique, qu’elle soit matérielle ou logicielle.
- La cyberattaque, notamment un rançongiciel qui chiffre les données et rend le système inutilisable. Notre guide sur la protection contre les ransomwares détaille la prévention.
- La coupure de la connexion internet ou de la téléphonie, que l’on oublie souvent parce qu’elle dépend d’un opérateur.
- La défaillance d’un prestataire : hébergeur, éditeur du logiciel métier, opérateur télécom.
- Un sinistre sur les locaux, ou l’absence soudaine de la seule personne qui connaît les accès.
Chaque scénario se juge à ses conséquences sur l’activité plus qu’à sa probabilité. C’est la logique de la gestion des risques informatiques, à laquelle le plan de continuité donne une suite concrète.
Les 5 étapes pour mettre en place un PCA informatique
La démarche suit la logique du guide de la continuité d’activité du SGDSN, ramenée à la taille d’une PME.
1. Identifier les activités critiques
On part du métier, pas des serveurs. Avec chaque responsable, listez les activités sans lesquelles l’entreprise perd de l’argent, des clients ou une obligation légale, puis les applications et les ressources dont elles dépendent. Cette cartographie des activités, appelée analyse d’impact (BIA), peut tenir sur une page.
Voici le tableau type d’une PME de services de quarante salariés. Les délais varient d’une entreprise à l’autre : fixez les vôtres avec vos équipes.
| Activité | Outil dont elle dépend | Arrêt tolérable | Solution de contournement |
|---|---|---|---|
| Prise de commandes | ERP, téléphonie IP | 2 heures | Fiche de saisie papier, numéro de repli sur mobile |
| Relation client | Messagerie, téléphonie IP | 1 heure | Renvoi d’appels vers des mobiles, message d’attente |
| Facturation | ERP | 2 jours | Reportée, rattrapée au redémarrage |
| Comptabilité | Logiciel comptable | 5 jours | Aucune, l’activité peut attendre |
Ce tableau n’a de valeur que validé par les métiers. Rempli par la seule équipe technique, il décrit l’architecture du système plutôt que les besoins de l’entreprise.
2. Fixer les objectifs de reprise : RTO et RPO
Deux indicateurs traduisent ces choix en objectifs mesurables. Le RTO (Recovery Time Objective) est la durée maximale d’indisponibilité que l’activité peut supporter. Le RPO (Recovery Point Objective) est la perte de données maximale admissible, exprimée en temps. Avec une sauvegarde réalisée chaque nuit, le RPO est d’une journée : si la panne survient en fin d’après-midi, tout le travail saisi dans la journée est à refaire.
Le RTO et le RPO sont des décisions de direction avant d’être des choix techniques : plus ils sont serrés, plus les solutions coûtent cher, mais moins l’arrêt coûte en pertes financières.
3. Choisir des solutions de repli proportionnées
Chaque activité critique reçoit une réponse adaptée à son délai, pour continuer à fonctionner même en mode dégradé. Les solutions s’étagent du plus simple au plus exigeant :
- Un mode dégradé : procédures manuelles, outil de repli, renvoi d’appels. Il suffit quand l’arrêt toléré se compte en jours.
- Un système de secours : serveurs prêts à démarrer sur un site secondaire. Il convient quand l’arrêt toléré se compte en heures.
- Une infrastructure redondante : le site principal bascule automatiquement sur le site de secours. C’est la réponse aux activités qui ne supportent aucune interruption, avec un hébergement haute disponibilité adapté.
Ajoutez ce qui sort du cadre du serveur : un lien internet de secours, la téléphonie, l’accès à distance. Passer certaines applications en SaaS réduit la dépendance au serveur local, à condition de vérifier la continuité de l’éditeur. Les sauvegardes restent la base du dispositif : une sauvegarde externalisée, chiffrée, stockée hors des locaux.
4. Organiser la gestion de crise
Le jour de la panne, ce ne sont pas les outils qui coordonnent, ce sont les décisions. Quelques fiches réflexes, une par scénario, disent qui déclenche le plan, qui remplace qui, qui prévient les clients et par quel canal. Une cellule de crise de deux ou trois personnes suffit dans une PME. Pour une crise d’origine cyber, les guides de l’ANSSI donnent un cadre utile. Trois points méritent une attention particulière :
- Un annuaire de crise lisible sans le système touché : copie papier, copie hors ligne, numéros personnels.
- Un suppléant nommé pour chaque rôle, y compris pour l’administrateur qui détient les accès.
- Un plan de communication de crise : messages préparés pour les clients et les fournisseurs, communication interne vers les collaborateurs, canal de repli.
5. Tester, corriger, mettre à jour
Un plan non testé reste une hypothèse. L’exercice le plus accessible est l’exercice sur table : on réunit la direction, les responsables métiers et l’équipe technique, on déroule un scénario (« le serveur ne redémarre pas ce matin ») et on chronomètre chaque décision. Une seule réunion suffit à faire apparaître les dépendances oubliées.
Prévoyez un test chaque année et après tout changement majeur (logiciel métier, déménagement, nouvel opérateur) ou l’apparition de nouveaux risques. Chaque écart devient une action, avec un responsable et une date.
Les erreurs que l’on rencontre le plus souvent
- Croire que les sauvegardes suffisent. Elles conservent les données, mais ne disent ni qui travaille, ni avec quels outils, pendant la réparation.
- Ranger la procédure sur le serveur qui tombe. Un plan introuvable le jour J ne sert à personne.
- Oublier les dépendances externes. Une coupure d’opérateur arrête l’activité même si tous les serveurs fonctionnent : notre retour d’expérience sur une fibre coupée en entreprise l’illustre.
- Laisser un équipement en fin de vie porter l’activité. Le cas d’un serveur obsolète montre pourquoi cette panne-là se prépare avant qu’elle n’arrive.
- Fixer les délais sans les métiers, puis découvrir en pleine crise qu’ils ne tiennent pas.
Qui fait quoi dans le projet ?
Le plan est un projet de direction, pas un chantier technique. La direction arbitre, fixe les priorités, finance la stratégie de continuité. Les responsables métiers fixent les délais tolérables. L’équipe technique propose et met en œuvre les solutions. Les collaborateurs connaissent leur rôle et les consignes.
Beaucoup de PME n’ont pas de DSI. Un prestataire apporte alors la méthode et un regard extérieur sur les dépendances que l’équipe ne voit plus.
Checklist : votre PME est-elle prête ?
Chaque « non » ou « je ne sais pas » désigne un chantier.
- Je peux citer les activités qui ne doivent pas s’arrêter plus de quelques heures.
- Chacune a une durée d’arrêt tolérable validée par son responsable.
- Je sais quelles données je peux me permettre de perdre, et lesquelles non.
- Une solution de repli existe pour chaque activité critique : mode dégradé, système de secours ou bascule.
- Mon lien internet et ma téléphonie ont un plan B.
- Les consignes de crise sont lisibles sans le système touché.
- Au moins deux personnes connaissent les accès critiques.
- Le plan a été joué depuis le dernier changement majeur.
Questions fréquentes sur le PCA informatique
Quelle est la différence entre un PCA et un PRA ?
Le PCA maintient l’activité pendant la crise, souvent en mode dégradé. Le PRA remet les systèmes en état après la panne. Le premier limite l’impact, le second raccourcit la durée de la remise en état.
Qui est concerné par le PCA ?
Toute entreprise dont l’activité dépend de son système d’information, quelle que soit sa taille. L’obligation légale, elle, ne concerne que certains secteurs, comme on l’a vu plus haut.
Quand mettre en place un PCA ?
Avant la crise, sans quoi il ne sert à rien. Les déclencheurs les plus fréquents sont une demande d’un client ou d’un assureur, une migration, l’arrivée d’une application critique ou une cyberattaque survenue chez un confrère.
Faut-il faire auditer son plan de continuité ?
Un audit externe n’est pas obligatoire, mais il devient utile dès que le plan existe : il vérifie que le dispositif tiendrait en conditions réelles, là où un test sur table révèle surtout les oublis. Il se justifie après un changement majeur ou quand un client l’exige.
Combien coûte un plan de continuité ?
Le coût dépend surtout des délais que vous fixez. Un mode dégradé bien préparé coûte avant tout du temps de réflexion, tandis qu’une bascule automatique sur un site de secours demande une infrastructure redondante. D’où l’intérêt de commencer par les seules activités vraiment critiques.
Faire appel à FC MICRO pour votre plan de continuité
FC MICRO accompagne depuis plus de 20 ans les PME de l’Essonne et d’Île-de-France sur leur informatique. Nous partons de vos activités et de vos délais, pas d’un modèle générique, de l’analyse des risques jusqu’à la mise en œuvre opérationnelle du plan. Notre équipe, basée à Gometz-le-Châtel, intervient aussi pour reprendre l’activité après un incident. Pour savoir quelles activités de votre PME ne supporteraient pas deux heures d’arrêt, appelez-nous au 01 69 94 10 96.








