La plupart des plans de continuité ont été écrits pour un incendie, une inondation ou une panne électrique. Puis un groupe de rançongiciel chiffre les serveurs de fichiers, les sauvegardes, et le document même qui explique quoi faire. Le plan qui semblait solide dans le classeur d'audit meurt dans la première heure d'une cyberattaque.
C'est tout l'écart entre un PCA vu comme un livrable de conformité et une vraie capacité de continuité. Voici comment le combler.
À quoi sert vraiment un PCA
Un plan de continuité des activités (PCA, ou BCP en anglais) est le dispositif documenté qui permet à votre organisation de maintenir ses activités essentielles, même en mode dégradé, pendant et après une perturbation majeure. Il répond à une question avant que la crise ne la pose : qui fait quoi, dans quel ordre, avec quelles ressources?
L'erreur classique consiste à réduire le PCA à un plan de relève informatique. La continuité dépend de bien plus que des serveurs :
- Les personnes : qui agit si le responsable de la cellule de crise est dans un avion, et qui couvre les rôles critiques portés par une seule personne?
- Les sites et équipements : où travaillent les équipes si un bureau, une usine ou un centre d'appels devient inaccessible?
- Les fournisseurs : quels tiers sont si critiques que leur panne devient la vôtre, et quel est le contournement?
- Les communications : comment parler aux employés, aux clients, aux régulateurs et aux médias quand vos canaux habituels sont hors service ou compromis?
Le plan de reprise informatique (PRI) qui restaure les systèmes en est une composante. Le PCA est la couche d'affaires au-dessus.
Pourquoi une cyberattaque casse les hypothèses classiques du PCA
Une attaque par rançongiciel n'est pas une inondation. La continuité traditionnelle suppose une perturbation externe, locale et neutre : le bâtiment est perdu mais le réseau est sain, donc on bascule vers le site secondaire et on continue. Le rançongiciel viole chacune de ces hypothèses.
- Le réseau lui-même est hostile. L'attaquant est peut-être encore à l'intérieur. Basculer vers votre site secondaire peut simplement lui offrir un deuxième environnement. La reprise commence par le confinement et l'éviction, pas par la restauration.
- Les sauvegardes sont une cible, pas un acquis. Les groupes modernes cherchent d'abord les consoles de sauvegarde. Vos copies peuvent être chiffrées, supprimées, ou empoisonnées des semaines plus tôt, si bien que restaurer réinstalle l'accès de l'attaquant.
- L'ordre de reprise compte. L'identité, le DNS et les services réseau doivent revenir avant les applications d'affaires, sur une infrastructure reconstruite ou vérifiée saine. Restaurer l'ERP sur un domaine compromis fait perdre des jours.
- Le chronomètre est juridique, pas seulement opérationnel. Les régulateurs imposent des délais de notification serrés, les assureurs exigent des preuves, et la préservation de la preuve limite la vitesse à laquelle vous pouvez tout effacer et reconstruire.
Si votre PCA traite la cyberattaque avec la même logique de reprise qu'un incendie, il ne survivra pas au contact d'un incident réel.
Commencer par un bilan d'impact honnête
Le bilan d'impact sur les activités (BIA) est le fondement de tout PCA crédible. Il identifie vos processus d'affaires critiques, leurs dépendances (systèmes, personnes, sites, fournisseurs) et le seuil au-delà duquel leur interruption devient inacceptable.
Du BIA découlent vos objectifs de reprise : RTO et RPO par processus. Le RTO est la durée d'interruption maximale tolérable; le RPO, la perte de données maximale tolérable. Deux disciplines s'imposent :
- Différencier. Tout n'est pas critique. Un RTO de quatre heures pour la paie un 2 du mois relève du théâtre; un RTO de quatre heures pour la prise de commandes peut être vital. Les cibles courtes coûtent cher : réservez-les aux processus qui les justifient vraiment.
- Être honnête. Un RTO de quatre heures ne veut rien dire si une restauration complète prend trois jours. Fixez des cibles que votre architecture peut réellement tenir, ou investissez jusqu'à ce qu'elle le puisse. C'est dans l'écart entre le RTO affiché et le temps réel qu'un incident devient un désastre.
Les annexes cyber dont votre PCA a besoin
Pour survivre à une cyberattaque, un PCA classique doit s'enrichir d'une couche spécifiquement cyber. Au minimum :
- Des procédures hors ligne. Imprimées ou stockées hors de l'environnement corporatif : procédures de reprise, schémas réseau, inventaires d'actifs, clés de licence, et le plan lui-même. S'il n'existe que sur le serveur de fichiers chiffré, il n'existe pas.
- Des communications hors bande. Un canal qui ne dépend ni du courriel, ni de la messagerie, ni de la téléphonie de l'entreprise, avec des points de contact convenus d'avance. Partez du principe que l'attaquant lit votre boîte de réception.
- Un arbre de décision payer ou ne pas payer. Décidez d'avance qui siège autour de la table, quelles vérifications juridiques et de sanctions s'appliquent, ce que votre assureur exige, et quelles preuves il vous faut avant toute décision sur une rançon. Trancher cela à 3 h du matin sous pression, c'est ainsi que se prennent les mauvaises décisions.
- Les obligations légales et de notification. Cartographiez-les avant d'en avoir besoin : la Loi 25 au Québec pour les incidents de confidentialité, NIS2 pour les entités essentielles et importantes en Europe, DORA pour les entités financières et leurs prestataires TIC. Chacune impose son délai et son format, et « nous étions occupés à restaurer » n'est pas une défense.
Testez la restauration, pas la sauvegarde
Un PCA non testé est une hypothèse. Les tests s'échelonnent sur un continuum, à gravir méthodiquement :
- Exercices sur table : la cellule de crise déroule un scénario, décisions et communications comprises. Peu coûteux, révélateur, et le bon point de départ.
- Tests fonctionnels : restaurer des systèmes précis, activer le site de repli, basculer sur les communications hors bande pendant une journée.
- Bascule complète : faire tourner les processus critiques sur l'infrastructure de relève, le site principal volontairement arrêté.
Une règle au-dessus des autres : testez la restauration, pas la sauvegarde. Le crochet vert sur la copie de la veille ne prouve rien. Restaurer un système critique de bout en bout, sur une infrastructure saine, dans le RTO annoncé, prouve tout. Chronométrez, documentez, corrigez ce que le test casse.
La continuité est devenue un sujet de conseil et d'assureur
Le PCA n'est plus un document de back-office. C'est un pilier de la résilience opérationnelle : la capacité démontrée à encaisser une perturbation, à s'y adapter et à s'en remettre. Les conseils d'administration demandent la preuve que les services critiques survivraient à des scénarios sévères. Les assureurs cyber conditionnent de plus en plus la couverture et la prime à des sauvegardes testées et des rapports d'exercice. Les régulateurs, de DORA à NIS2, veulent des preuves, pas des déclarations d'intention.
Le fil conducteur : avoir un plan ne suffit plus. Il faut pouvoir démontrer qu'il fonctionne.
Là où les PCA échouent vraiment
Les mêmes causes reviennent dans presque toutes les revues post-incident :
- Le plan a été écrit pour les auditeurs. Formellement complet, opérationnellement inutilisable, inconnu de ceux censés l'exécuter.
- Les listes de contacts étaient périmées. La moitié des noms avaient quitté l'entreprise; le numéro d'urgence de l'assureur datait de la police précédente.
- Une seule personne portait tout. Le seul administrateur qui connaissait le système de sauvegarde était injoignable, et rien n'était documenté.
- Il n'a jamais été testé contre un scénario cyber. La bascule a fonctionné à merveille, droit vers un réseau compromis.
Chacun de ces défauts coûte peu à corriger avant l'incident, et très cher à découvrir pendant.
Où FortaRisks intervient
La continuité ne vit pas dans un classeur; elle vit dans des contrôles : sauvegardes testées, procédures de reprise documentées, rôles de crise exercés, préparation aux notifications. FortaRisks cartographie ces contrôles à travers plus de 30 référentiels, dont DORA, NIS2 et la Loi 25, et transforme les écarts en feuille de route priorisée et chiffrée dans le module Conformité. Vous voyez où en est votre posture de continuité, quoi corriger en premier, et quelles preuves présenter à un conseil, un assureur ou un régulateur.