Plan de continuité d’activité et NIS2 : articuler PCA, analyse des risques et exercices de crise

Un plan de continuité d’activité conçu dans le contexte de NIS2 ne peut pas rester une procédure isolée, administrée par la seule direction informatique. Il doit découler de l’analyse d’impact sur l’activité et de l’analyse des risques, fixer les priorités de reprise des processus et être régulièrement mis à l’épreuve. Son efficacité ne se démontre pas par des déclarations, mais par la capacité réelle de l’organisation à décider, à activer un mode dégradé, à atteindre un niveau minimal de fonctionnement puis à revenir en toute sécurité à une activité normale.

La continuité d’activité relève d’une décision de gouvernance

Un plan de continuité d’activité ne commence ni par un modèle de procédure ni par un inventaire des systèmes informatiques. Le point de départ réside dans les services, produits et processus dont l’interruption pourrait compromettre les engagements de l’entreprise, la sécurité, le respect des exigences applicables ou sa stabilité financière. Le périmètre du plan doit être établi à partir d’une analyse d’impact sur l’activité. Il convient de déterminer comment les conséquences s’aggravent dans le temps, à quel moment elles dépassent le seuil accepté par la direction et dans quel ordre les capacités opérationnelles doivent être rétablies.

La durée maximale d’interruption admissible et le niveau de perte acceptable ne doivent pas être définis unilatéralement par la direction informatique. Ces paramètres sont approuvés par la direction à partir des informations fournies par les pilotes de processus et par les fonctions finance, conformité, sécurité et technologie. Le pilote de processus définit les exigences de continuité, tandis que le responsable du plan coordonne la préparation et le maintien du dispositif. Sans mécanisme de décision commun, l’informatique protège l’infrastructure, les opérations assurent la fourniture des prestations et la direction ne dispose pas d’une vision consolidée des priorités de reprise ni des interruptions acceptables.

Dans un site industriel, le simple rétablissement du système de planification ou de conduite ne signifie pas que les expéditions peuvent reprendre. La production peut rester à l’arrêt en raison de l’indisponibilité des données techniques, de l’absence d’opérateurs habilités, d’une coupure d’alimentation, d’une liaison fournie par un prestataire ou de l’absence d’une procédure approuvée pour travailler en mode dégradé. La résilience opérationnelle n’existe que si le plan couvre l’ensemble de la chaîne de dépendances du processus, et non les seules ressources placées sous le contrôle de l’informatique.

Il convient également de distinguer la continuité d’activité, la reprise des ressources informatiques, la réponse aux incidents et la gestion de crise. La première vise à maintenir ou à reprendre les processus ; la deuxième, à restaurer les technologies et les données ; la troisième, à contenir et à traiter l’événement ; la quatrième, à prendre des décisions dans un contexte de perturbation majeure. Ces dispositifs doivent partager des scénarios, des seuils d’escalade et des règles de responsabilité cohérents, sans pour autant être interchangeables.

Ce n’est qu’après avoir défini ce modèle opérationnel qu’il devient pertinent de le rapprocher des obligations issues de NIS2 et des dispositions nationales applicables en matière de gestion des risques, de continuité d’activité, de traitement des incidents et de responsabilité des organes de direction, en tenant compte du statut et du périmètre de l’organisation. Pour une vue plus large, consulter NIS2 pour les entreprises industrielles : organisations concernées, obligations introduites et préparation sans réduire le sujet à l’informatique.

Le risque doit déboucher sur un scénario opérationnel

Le registre des risques ne pilote réellement le plan de continuité que s’il met en évidence les liens entre menace, vulnérabilité, actif, processus et conséquence métier. Une simple liste de cybermenaces n’explique pas comment maintenir l’activité. Les scénarios doivent donc être construits autour des effets de la perturbation : indisponibilité d’un système de conduite, perte de données, interruption des communications, absence de personnel ou indisponibilité d’un fournisseur. Des causes différentes peuvent conduire au même état opérationnel et exiger une stratégie de continuité identique.

L’analyse d’impact sur l’activité et l’analyse des risques remplissent des fonctions distinctes mais complémentaires. La première détermine la gravité d’une interruption, la vitesse à laquelle les pertes augmentent et le moment où le niveau accepté par la direction est dépassé. La seconde permet d’identifier les sources possibles de l’événement, les vulnérabilités et l’efficacité des mesures de maîtrise existantes. La méthode et l’échelle d’évaluation retenues doivent permettre de comparer les scénarios et d’accepter consciemment le risque résiduel, conformément à l’appétence au risque de l’organisation.

Il est utile de limiter le nombre de scénarios aux conséquences distinctes qui nécessitent des décisions, des ressources ou des séquences de reprise différentes. Analyser séparément chaque variante technique améliore rarement l’utilité du plan ; cela complique en revanche sa maintenance et son application sous contrainte de temps.

Pour chaque scénario, il faut définir la durée maximale d’interruption admissible, le niveau minimal de fonctionnement, les ressources requises, l’ordre de reprise et la personne habilitée à activer le plan. Ces paramètres doivent s’appuyer sur les durées réelles d’arrêt et de rétablissement observées lors d’incidents, de pannes et d’exercices, ainsi que sur les exigences contractuelles relatives à la disponibilité, aux délais d’exécution et à la notification des perturbations. Ils permettent ensuite de mesurer le délai de décision, le temps nécessaire pour atteindre le niveau minimal et la durée de reprise complète.

L’analyse doit prendre en compte les dépendances réelles du processus : applications, données, infrastructures, sites, utilités, compétences clés, prestataires informatiques, intégrateurs et sous-traitants. Lorsqu’une stratégie repose sur l’appui d’un tiers, il faut vérifier sa disponibilité, ses délais de réaction, ses voies d’escalade et ses solutions de secours, plutôt que de s’en remettre aux seules clauses du contrat. Le sujet est approfondi dans NIS2 et sécurité de la chaîne d’approvisionnement : évaluer les prestataires informatiques, les intégrateurs et les sous-traitants.

Le plan doit guider l’organisation pendant la perturbation

Un plan de continuité utile ne cherche pas à décrire tous les événements possibles. Il guide les responsables à travers une succession de décisions. Il doit préciser qui qualifie la situation, qui déclare l’activation du dispositif de continuité, quels processus doivent être maintenus à un niveau minimal, dans quel ordre les capacités doivent être rétablies, comment conduire la communication de crise et sur quels critères mettre fin au mode exceptionnel.

Le niveau de détail est suffisant lorsque le plan réduit le besoin d’interprétation sous pression sans se substituer aux instructions techniques et opérationnelles. Dans une organisation de taille importante, une architecture efficace consiste à disposer d’un plan directeur définissant le commandement, l’escalade et les règles de coordination, complété par des plans propres à chaque processus.

La procédure d’activation doit reposer sur des critères mesurables. Une formulation telle que « en cas de panne grave » reporte le débat sur le sens du mot « grave » au pire moment possible. Le critère peut être le dépassement de la durée maximale d’interruption admissible, la perte de fiabilité des données, l’impossibilité de travailler en sécurité, l’indisponibilité de personnes clés ou la baisse prévisible sous le niveau minimal de fonctionnement approuvé par le pilote du processus. Chaque écart doit être relié à une action, à une autorité de décision, à un délai d’escalade et à un enregistrement attendu. Une logique comparable, appliquée à un autre niveau opérationnel, est présentée dans Plan de réaction dans le plan de contrôle : définir les actions lorsque le processus sort de ses limites.

Les rôles doivent être attribués à des fonctions, et non uniquement à des personnes nommément désignées. La matrice des responsabilités doit prévoir les suppléances, le périmètre des pouvoirs, la disponibilité ainsi que les canaux de contact principal et de secours. Une liste nominative peut être gérée comme une annexe maîtrisée, afin qu’un changement de personnel n’impose pas de refondre l’ensemble du plan.

La direction doit statuer sur les décisions qui dépassent le cadre opérationnel approuvé, notamment l’acceptation d’un risque significatif pour l’activité, l’engagement de moyens exceptionnels ou une communication à portée stratégique. En revanche, la décision de passer à un mode dégradé préalablement approuvé doit rester aussi proche que possible du processus concerné.

Après la perte du système de gestion des commandes, la personne d’astreinte peut confirmer l’indisponibilité et sa durée prévisionnelle, le pilote du processus peut activer l’enregistrement de secours, puis le coordinateur de la continuité peut procéder à l’escalade lorsque le seuil convenu est atteint. Le plan doit fixer les limites de ce contournement : capacité de traitement, durée maximale d’utilisation, règles de protection et d’intégrité des données, rapprochements manuels obligatoires et modalités de réintégration ultérieure des enregistrements dans le système.

Le retour au fonctionnement normal ne peut intervenir qu’après confirmation de la stabilité de la solution, de l’exhaustivité des données et du rapprochement des opérations réalisées manuellement. Les enregistrements produits doivent permettre d’évaluer le délai de décision, le temps d’atteinte du niveau minimal et la durée de reprise complète.

Le coût le plus élevé apparaît souvent à l’interface entre les plans

L’ampleur d’une perte ne dépend pas uniquement de la cause de la panne. L’attente d’une autorisation, une qualification ambiguë de l’événement, des priorités de reprise contradictoires ou une connaissance insuffisante des dépendances entre processus, systèmes et fournisseurs prolongent également l’interruption. Le plan de réponse aux incidents sert d’abord à détecter, évaluer, contenir et traiter l’événement. Le plan de continuité vise, quant à lui, à maintenir l’activité au niveau accepté. Les deux dispositifs doivent définir les mêmes points de transmission des informations et des décisions : qui constate que la continuité est menacée, qui active le mode dégradé et qui approuve le retour au fonctionnement normal.

La priorité de reprise technique doit découler de la priorité du processus, sans en être une simple copie. Un système soutenant le processus le plus critique peut nécessiter le rétablissement préalable de services d’identité, de réseau, de base de données ou d’intégration. Il faut parallèlement préserver l’intégrité des données, respecter la séquence de redémarrage et maintenir les mécanismes de sécurité. La cohérence entre priorités métier et techniques se vérifie en comparant la disponibilité requise du processus avec les résultats réels des tests de restauration des sauvegardes, la perte de données admissible et les dépendances d’infrastructure.

Les opérations peuvent souhaiter reprendre la saisie des commandes avant la facturation, alors que l’équipe informatique prévoit de restaurer d’abord la facturation parce qu’elle contient le référentiel central des clients. Si cette dépendance n’a pas été arbitrée en amont, la décision sera prise sous pression et le contournement manuel pourra créer des données impossibles à rapprocher en toute sécurité par la suite. Ce type de situation doit être évalué à partir des délais réels de détection, d’escalade, de décision et de reprise, ainsi que des résultats des essais confirmant l’exhaustivité et l’intégrité des données.

Une lacune comparable apparaît à la frontière de responsabilité du prestataire. Un engagement contractuel de disponibilité ne remplace ni une voie d’escalade attribuée à des personnes ou à des fonctions, ni des paramètres de reprise convenus, ni l’accès aux informations sur le déroulement de la perturbation, ni une obligation de coopération pendant les exercices. Les besoins des processus critiques doivent être comparés aux clauses contractuelles et aux capacités réelles du fournisseur. Ce n’est qu’à cette condition qu’il devient possible de décider en connaissance de cause s’il faut maintenir une solution de secours, accepter l’arrêt, mobiliser des ressources internes ou recourir à un service externe.

Le budget doit traiter les écarts de capacité, et non financer une accumulation de documents. Les dépenses peuvent porter sur une redondance supplémentaire, le raccourcissement de la chaîne de décision, des tests de restauration plus fréquents, une révision des conditions contractuelles ou la mise en place d’un mode alternatif d’exécution du processus. L’analyse Quel budget prévoir pour NIS2 et l’uKSC : structurer les coûts d’audit, de documentation, de formation et de sécurisation sans erreurs coûteuses présente une méthode de structuration de ces coûts.

Un exercice doit éprouver les décisions

Un exercice de continuité d’activité ne doit pas se limiter à lire une procédure ou à confirmer la présence des participants. Il doit tester une hypothèse clairement formulée, par exemple : l’organisation est-elle capable d’activer un processus de secours sans son système principal, de garder la maîtrise des données saisies et de les rapprocher en toute sécurité après le rétablissement du service ?

Le programme d’exercices peut être développé progressivement : revue des rôles et exercice sur table, test d’une procédure ciblée ou d’une restauration, puis exercice technico-opérationnel associant les métiers, l’informatique, la direction et les fournisseurs. Le périmètre doit évoluer en fonction du risque, de la criticité du processus et du niveau de préparation de l’organisation.

Le scénario doit imposer des décisions dans des conditions proches d’une perturbation réelle. Il peut intégrer des informations incomplètes, une contrainte de temps, des priorités contradictoires ou l’indisponibilité d’une dépendance importante, telle qu’un approbateur, un service fourni par un prestataire ou une liste de contacts à jour. L’exercice ne doit toutefois pas constituer un piège pour les participants. L’objet de l’évaluation est le système — répartition des responsabilités, qualité des informations, faisabilité des procédures et capacité d’escalade — et non la mise en cause individuelle des collaborateurs.

La participation de la direction est indispensable lorsque le scénario exige l’acceptation d’un risque, la modification des priorités ou l’activation d’une solution de secours coûteuse. Le fournisseur doit être associé dès lors que sa réaction conditionne la continuité du processus.

Un exercice type peut débuter par l’indisponibilité du système de traitement des commandes. L’animateur indique ensuite que la copie des données est incomplète et que la réponse du prestataire est retardée. L’équipe doit décider s’il convient d’activer le traitement manuel, quelles commandes accepter et comment identifier les enregistrements afin d’éviter, après la reprise du service, les doublons et les pertes d’intégrité.

Pendant l’exercice, il faut mesurer les délais de détection de la perturbation, d’escalade, d’activation du dispositif de continuité, d’atteinte du niveau minimal et de reprise. Il convient parallèlement d’évaluer la qualité des échanges et des enregistrements, l’utilisation éventuelle de coordonnées obsolètes, les escalades inefficaces et les étapes du plan impossibles à exécuter. Les délais obtenus doivent être comparés aux objectifs de continuité approuvés.

La fréquence et la forme des exercices doivent être déterminées par le niveau de risque, les changements apportés aux processus, les résultats des essais précédents et l’importance des dépendances, et non par le seul calendrier annuel. Un exercice annoncé facilite l’apprentissage et l’alignement des rôles. Un exercice inopiné permet d’évaluer la préparation réelle, mais exige une maîtrise du risque opérationnel. L’utilisation du système de production n’est justifiée que si le périmètre, les mesures de protection et la possibilité d’interrompre l’essai ont été explicitement approuvés ; dans les autres cas, un environnement de test est préférable.

Chaque exercice doit déboucher sur des actions assorties d’un responsable, d’une échéance, d’un critère d’efficacité et d’une décision concernant leur nouveau test. Le taux d’actions clôturées dans les délais constitue un indicateur utile, mais le statut « réalisé » ne prouve pas à lui seul l’amélioration. Le résultat du nouvel essai reste déterminant. L’approche présentée dans Construire une bibliothèque de modèles qualité : FMEA, Control Plan, 8D, audit, CAPA et KPI peut aider à structurer les scénarios, comptes rendus, actions correctives et indicateurs.

Boucler le cycle par des preuves et une revue de direction

Un ensemble complet de procédures ne démontre pas la capacité à maintenir l’activité. Une chaîne de preuves crédible doit relier les hypothèses approuvées de l’analyse des risques et de la continuité, les décisions des pilotes de processus, les enregistrements des tests, les résultats des exercices, les non-conformités constatées, les actions correctives et l’évaluation de leur efficacité. Le registre des versions du plan de continuité doit indiquer non seulement la date et l’auteur de la modification, mais aussi l’événement, la décision ou le résultat d’analyse qui la justifie.

La fréquence de révision du plan doit être adaptée à la criticité des processus et à l’évolution des risques. Une échéance périodique ne suffit pas. Une revue doit également être déclenchée après un incident, un exercice ou une modification significative d’un processus, d’une technologie, d’un site, d’un fournisseur, de la structure organisationnelle ou du profil de risque. Les critères d’acceptation de l’exercice doivent être définis avant son lancement, afin d’éviter une conclusion subjective selon laquelle l’organisation « s’en est sortie ».

Le suivi mensuel peut montrer que le programme d’exercices a été réalisé comme prévu, tout en révélant qu’un processus n’a pas atteint le délai de reprise requis et qu’aucune solution de secours n’existe encore pour un service critique fourni par un tiers. Ce résultat ne doit pas être relégué dans un compte rendu technique. La direction doit recevoir une information claire sur les processus qui n’atteignent pas la capacité attendue, les écarts non acceptés, les risques assumés en connaissance de cause et les investissements ou arbitrages organisationnels nécessaires. La revue de direction doit se conclure par des décisions documentées, et non par une simple prise d’acte.

L’audit interne doit vérifier la cohérence entre les déclarations et les pratiques : le processus qualifié de critique participe-t-il réellement aux exercices ? Les objectifs techniques de reprise répondent-ils aux besoins opérationnels ? Les actions issues des essais ont-elles été clôturées et leur efficacité confirmée ? Il convient de présenter à l’auditeur ou à l’autorité de contrôle une chaîne d’enregistrements retraçant le cheminement depuis le risque identifié jusqu’à l’amélioration vérifiée, en passant par la décision et l’essai. Parmi les indicateurs utiles figurent le taux d’exécution du programme d’exercices approuvé, le respect des délais des actions correctives et le nombre d’écarts non acceptés entre la capacité de continuité requise et celle effectivement démontrée.

La liste finale des actions peut être intégrée au calendrier plus large présenté dans Mise en œuvre de NIS2 après l’inscription au registre KSC : plan d’action jusqu’au 3 avril 2027. Les échéances, le périmètre des obligations et les mesures appropriées doivent toutefois être vérifiés au regard du droit en vigueur, du statut de l’organisation dans le système national de cybersécurité et de son profil de risque réel.