Disposer d’un plan de continuité ne garantit pas que l’entreprise pourra réellement poursuivre ses activités en cas de panne majeure, de cyberattaque ou d’indisponibilité d’un prestataire. Seuls des tests du plan de continuité IT permettent de vérifier que les procédures prévues sont applicables, que les équipes savent les exécuter et que les solutions techniques fonctionnent dans les délais attendus.
Pourtant, de nombreuses organisations concentrent leurs efforts sur la rédaction du PCA informatique, puis repoussent les exercices, jugés complexes ou susceptibles de perturber la production. Le document existe, les responsabilités semblent définies et les infrastructures de secours sont disponibles. Mais le jour où survient un incident, des dépendances non identifiées, des accès impossibles à utiliser ou des sauvegardes inexploitables peuvent compromettre toute la reprise informatique.
Tester régulièrement le dispositif permet de transformer un plan théorique en véritable capacité opérationnelle de résilience IT.
Le plan de continuité IT rassemble les mesures organisationnelles et techniques permettant de maintenir ou de rétablir les services numériques nécessaires aux activités prioritaires de l’entreprise.
Il s’inscrit dans une démarche plus large de continuité d’activité. Celle-ci commence généralement par l’identification des processus critiques, de leurs dépendances et des conséquences d’une interruption. L’organisation peut ensuite définir les ressources minimales à maintenir, les délais de reprise attendus, les responsabilités et les solutions de secours.
Le PCA informatique est souvent complété par un plan de reprise d’activité, ou PRA. Dans la pratique, les deux notions sont étroitement liées :
• le PCA vise à poursuivre les activités essentielles, éventuellement en mode dégradé ;
• le PRA organise le rétablissement des infrastructures, des applications et des données après une interruption ;
• le plan de gestion de crise coordonne les décisions, les communications et les actions transversales.
Le NIST présente la planification de continuité comme un processus comprenant notamment l’analyse d’impact, l’identification des contrôles préventifs, la définition des stratégies de reprise, la rédaction du plan, les tests et sa maintenance. L’ANSSI rappelle également que les PCA et PRA participent à la préparation des opérations de continuité et de remédiation après un incident cyber.
La première raison est organisationnelle. La rédaction d’un plan possède un début et une fin clairement identifiables, alors que son maintien nécessite une démarche continue. Une fois le document validé, les priorités opérationnelles reprennent souvent le dessus.
Un test peut également mobiliser de nombreuses équipes : infrastructure, réseau, sécurité, métiers, communication, direction, support et prestataires. Les responsables craignent qu’une bascule, même préparée, entraîne une interruption ou révèle des problèmes difficiles à corriger rapidement.
D’autres freins sont fréquents :
• l’absence de responsable clairement désigné pour piloter les exercices ;
• la difficulté à réserver du temps aux équipes techniques et métiers ;
• une connaissance insuffisante des dépendances entre applications ;
• des environnements de secours rarement mis à jour ;
• la peur de constater que les objectifs de reprise ne sont pas tenables ;
• la confusion entre la supervision quotidienne et un véritable test de continuité.
Or, vérifier qu’un serveur de secours est allumé ou qu’une tâche de sauvegarde s’est terminée correctement ne prouve pas que l’entreprise peut restaurer son activité.
Une sauvegarde ne doit pas seulement être créée : elle doit pouvoir être restaurée dans un environnement utilisable.
Le test doit vérifier l’intégrité des fichiers, la disponibilité des clés de chiffrement, les droits d’accès, la cohérence des bases de données et le temps nécessaire à la restauration. La CNIL recommande de tester régulièrement l’intégrité des sauvegardes ainsi que la capacité à les restaurer. Elle recommande également de tester l’application des plans de continuité et de reprise.
Exemple : une entreprise sauvegarde quotidiennement son progiciel de gestion. Lors d’un exercice, elle découvre que la base peut être restaurée, mais que les pièces jointes sont stockées dans un espace distinct non inclus dans la procédure. La sauvegarde était techniquement réussie, mais le service restauré aurait été incomplet.
Isolation, automatisation, protection contre les ransomwares et tests de restauration : découvrez les bonnes pratiques permettant de construire une stratégie de sauvegarde réellement résiliente.
Le test de bascule vérifie que les infrastructures secondaires peuvent réellement accueillir les services prioritaires. Il doit couvrir les capacités de calcul et de stockage, mais aussi les règles réseau, les flux entre applications, le DNS, les certificats et les mécanismes de supervision.
Un environnement de secours peut être disponible sans être correctement synchronisé avec la production. Une modification récente du pare-feu, une nouvelle adresse IP ou un certificat expiré suffit parfois à bloquer la reprise.
Lorsque le risque d’interruption est élevé, la bascule peut d’abord être testée sur une application limitée ou dans un environnement isolé, avant d’organiser un exercice plus complet.
En cas d’indisponibilité d’un site, de panne électrique ou d’impossibilité d’accéder aux locaux, les équipes doivent parfois travailler à distance. Il faut alors vérifier :
• la capacité des accès VPN ou des passerelles sécurisées ;
• la disponibilité des équipements confiés aux collaborateurs ;
• le fonctionnement de l’authentification multifacteur ;
• l’accès aux outils d’administration ;
• la possibilité de joindre le support en dehors des canaux habituels.
Un accès distant testé par quelques administrateurs ne garantit pas qu’il supportera simultanément les utilisateurs nécessaires au maintien de l’activité.
Les tests ne doivent pas s’arrêter à l’infrastructure. Une machine virtuelle peut démarrer correctement tandis que l’application reste inutilisable en raison d’une licence inaccessible, d’un connecteur manquant ou d’une dépendance externe.
Pour chaque application critique, l’exercice doit vérifier un parcours métier représentatif. Il peut s’agir, par exemple, de créer une commande, consulter un dossier client, produire un document, enregistrer un paiement ou traiter une demande d’assistance.
Cette validation fonctionnelle doit associer les métiers : les équipes IT ne peuvent pas toujours déterminer seules si un service restauré répond réellement aux besoins opérationnels.
Les annuaires, services d’identité et mécanismes d’authentification constituent des dépendances particulièrement sensibles. Sans eux, les utilisateurs et les administrateurs peuvent être incapables d’accéder aux applications, y compris lorsque celles-ci sont disponibles.
Il convient de vérifier la restauration de l’annuaire, l’existence de comptes d’urgence, la disponibilité des systèmes d’authentification multifacteur et les procédures applicables lorsqu’un domaine est compromis. L’ANSSI souligne le rôle central des annuaires dans l’identification et l’authentification des utilisateurs et accorde une attention particulière à leur sécurisation et à leur reconstruction après compromission.
Une crise IT ne se limite jamais à un problème technique. Les équipes doivent pouvoir informer les collaborateurs, la direction, les clients, les partenaires et, selon la situation, les autorités compétentes.
Un exercice doit tester les listes de contacts, les chaînes d’alerte, les modèles de messages et les canaux alternatifs. La messagerie ou l’outil collaboratif habituel pourrait précisément être indisponible.
L’ANSSI recommande d’organiser des exercices pour entraîner les équipes à la gestion opérationnelle et stratégique d’une crise cyber. L’ENISA souligne également l’intérêt des exercices pour développer les compétences techniques, opérationnelles et décisionnelles sans subir les conséquences d’un incident réel.
Exercices de gestion de crise, chaîne d’alerte, coordination des équipes et plans de remédiation : découvrez comment tester votre organisation dans des conditions réalistes.
Les services cloud, opérateurs télécoms, infogérants, éditeurs et prestataires de cybersécurité font partie du dispositif de continuité. Leur présence dans un contrat ne garantit toutefois ni leur disponibilité immédiate ni leur capacité à intervenir dans les conditions prévues.
Le test peut vérifier les numéros d’escalade, les délais de réponse, les accès du prestataire, la disponibilité des sauvegardes exportables et les possibilités de fonctionnement dégradé. Il doit aussi examiner les dépendances en chaîne : un fournisseur critique peut lui-même dépendre d’un autre acteur.
Tous les exercices ne nécessitent pas une interruption de production. Une démarche progressive permet d’augmenter le niveau de réalisme tout en maîtrisant les risques.
Il consiste à relire les plans, vérifier les coordonnées, les rôles, les procédures et la cohérence avec l’architecture actuelle. Ce niveau est utile après une réorganisation, un changement de prestataire ou une évolution importante du système d’information.
Il reste néanmoins insuffisant pour démontrer que les solutions techniques fonctionnent.
Les participants analysent collectivement un scénario simulé : rançongiciel, indisponibilité d’un datacenter, panne réseau ou défaillance d’un fournisseur. Ils décrivent les décisions et les actions qu’ils réaliseraient.
Le NIST présente l’exercice sur table comme une méthode permettant de valider le contenu et l’applicabilité des plans, sans effectuer toutes les opérations techniques réelles.
Une composante précise est testée en conditions contrôlées : restauration d’une base, activation d’un lien de secours, démarrage d’une application ou utilisation des comptes d’urgence.
Ce format limite les risques tout en produisant des résultats mesurables.
L’organisation simule une interruption importante et mobilise l’ensemble des acteurs. Elle exécute réellement tout ou partie des procédures de bascule, de reprise, de communication et de retour à la normale.
Le NIST distingue les exercices fonctionnels ciblés des exercices complets couvrant l’ensemble des éléments du plan. Le niveau choisi doit dépendre de la criticité du système et des objectifs de l’exercice.
Un PCA obsolète peut donner une fausse impression de sécurité. En situation de crise, l’entreprise peut découvrir que :
• les procédures ne correspondent plus à l’architecture ;
• les collaborateurs désignés ont changé de poste ;
• les mots de passe ou clés nécessaires ne sont pas accessibles ;
• les sauvegardes sont incomplètes ou trop longues à restaurer ;
• le site de secours ne dispose pas des capacités attendues ;
• les applications redémarrent dans le mauvais ordre ;
• les fournisseurs ne peuvent pas intervenir ;
• les délais de reprise sont incompatibles avec les besoins métiers.
Les conséquences peuvent être une interruption prolongée, une perte de données, une désorganisation de la gestion de crise ou une reprise précipitée dans un environnement insuffisamment sécurisé.
Il n’existe pas de fréquence universelle adaptée à toutes les organisations. La périodicité doit être définie selon la criticité, le rythme des changements, les risques et les engagements propres à l’entreprise.
Une organisation peut retenir, à titre de démarche interne :
• une revue documentaire après chaque changement majeur et au moins annuellement ;
• des restaurations régulières sur un échantillon de sauvegardes ;
• des tests techniques partiels plusieurs fois par an pour les services critiques ;
• un exercice global annuel ou selon le niveau de risque ;
• un nouveau test après une modification significative ou un échec.
Ces fréquences constituent une approche de gestion, et non une règle générale applicable à toutes les entreprises. La CNIL demande des tests réguliers sans imposer une périodicité unique. Le NIST propose, dans ses modèles destinés aux systèmes fédéraux américains, des niveaux d’exercice différents selon l’impact des systèmes. Ces recommandations doivent donc être adaptées au contexte de chaque organisation.
Les indicateurs doivent mesurer à la fois la performance technique et la capacité organisationnelle. Les plus utiles comprennent :
• le temps réel de reprise comparé à l’objectif prévu ;
• le point de restauration effectivement atteint ;
• le pourcentage de services restaurés dans les délais ;
• le taux de réussite des restaurations ;
• le nombre de dépendances non documentées découvertes ;
• le délai de mobilisation des intervenants ;
• le délai d’envoi des premières communications ;
• le nombre d’écarts critiques et leur délai de correction ;
• le taux de réalisation du programme annuel de tests.
L’objectif n’est pas de produire un score artificiellement rassurant, mais d’identifier les écarts qui pourraient empêcher la continuité d’activité.
Chaque exercice doit disposer d’un périmètre, d’objectifs mesurables et de critères d’arrêt. Les équipes doivent distinguer clairement les actions simulées des opérations réellement exécutées.
Pour réduire les risques, il est recommandé de :
• commencer par un périmètre limité ;
• tester les opérations sensibles dans un environnement isolé ;
• prévoir une procédure de retour arrière ;
• informer uniquement les acteurs nécessaires selon le scénario ;
• désigner un responsable de l’exercice et des observateurs ;
• protéger les données utilisées pendant le test ;
• planifier les opérations techniques sur une période adaptée ;
• documenter précisément les résultats.
Les observateurs doivent relever les décisions, les délais, les incompréhensions et les contournements. Ces éléments sont souvent plus instructifs qu’un simple résultat « réussi » ou « échoué ».
Un test n’apporte de valeur que s’il débouche sur des corrections. Un retour d’expérience doit être organisé rapidement avec les équipes techniques, les métiers, la sécurité et les prestataires concernés.
Le compte rendu doit identifier :
• ce qui a fonctionné ;
• les écarts par rapport au plan ;
• les causes techniques ou organisationnelles ;
• les risques associés ;
• les actions correctives ;
• un responsable et une échéance pour chaque action ;
• les tests nécessaires pour valider les corrections.
Le PCA, le PRA, les schémas d’architecture, les listes de contacts et les procédures doivent ensuite être mis à jour. Les écarts critiques doivent faire l’objet d’un nouveau test, sans attendre l’exercice annuel suivant.
Les tests du plan de continuité IT ne constituent pas une formalité documentaire. Ils vérifient que l’entreprise peut maintenir ses activités essentielles, restaurer ses données, mobiliser ses équipes et communiquer efficacement lorsque ses outils habituels ne sont plus disponibles.
Une approche progressive, allant de la revue documentaire au test grandeur nature, permet d’améliorer la résilience IT sans exposer inutilement la production. Restaurations, accès distants, applications, annuaires, fournisseurs et communication de crise doivent tous être inclus dans le programme.
Pour les décideurs IT et les dirigeants, la bonne question n’est donc pas seulement : « Avons-nous un PCA informatique ? », mais plutôt : « Quelle partie de ce plan avons-nous réellement testée, quand et avec quel résultat ? »
Une évaluation structurée du dispositif existant constitue un premier pas pour identifier les tests prioritaires et renforcer durablement la disponibilité du système d’information.
Supervision, maintien en condition opérationnelle, sauvegarde et reprise après sinistre : découvrez comment les services managés Tenexa contribuent à maintenir la disponibilité de vos infrastructures et applications critiques.
Sources utilisées
• ANSSI, Organiser un exercice de gestion de crise cyber : consulter le guide.
• ANSSI, Crise cyber : les clés d’une gestion opérationnelle et stratégique : consulter le guide.
• ANSSI, Cyberattaques et remédiation : consulter la publication.
• CNIL, Sécurité : prévoir la continuité et la reprise d’activité, 14 mars 2024 : consulter la fiche.
• CNIL, Sécurité : sauvegarder, 14 mars 2024 : consulter la fiche.
• NIST, SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems : consulter la publication.
• NIST, SP 800-84 — Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities : consulter la publication.
• ENISA, Cyber Europe : consulter la présentation des exercices.
• ISO, ISO 22301 — Systèmes de management de la continuité d’activité : consulter la présentation.