CompTIA SY0-701: Continuité des activités et reprise après sinistre — Guide d'étude

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fait partie du CompTIA Security+ SY0-701 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens CompTIA, ou passez des tests chronométrés sur ExamRoll.io.

La continuité d’activité (BC) et la reprise après sinistre (DR) constituent la colonne vertébrale opérationnelle de la résilience organisationnelle. Là où les contrôles de sécurité tentent de prévenir les incidents, la planification BC/DR reconnaît que certaines perturbations — explosions de ransomware, ouragans, coupures de fibre optique, pannes de réseau électrique ou pannes cloud en cascade — se produiront indépendamment des mesures préventives. Cette discipline se concentre sur la quantification des interruptions tolérables, la conception de chemins de reprise et la validation de ces chemins avant qu’ils ne soient nécessaires.

Objectifs de reprise : RTO, RPO, MTTR et MTBF

Deux métriques sont au cœur de toute discussion sur la reprise, et les confondre est l’une des erreurs les plus persistantes dans les documents de planification. L’objectif de temps de reprise (RTO) exprime la durée maximale acceptable pendant laquelle un système peut rester indisponible après une perturbation. Il est mesuré en temps écoulé, depuis le moment de la défaillance jusqu’au moment où les services sont restaurés à un état utilisable.

L’objectif de point de reprise (RPO), en revanche, mesure la tolérance à la perte de données — jusqu’à quel point dans le passé l’organisation est prête à perdre des transactions. Le RPO est mesuré à rebours depuis le moment de la défaillance jusqu’au dernier point de reprise connu et valide. Un RPO de quinze minutes signifie que l’entreprise peut tolérer la perte de jusqu’à quinze minutes d’écritures ; par conséquent, les sauvegardes, la réplication ou l’envoi des journaux de transactions doivent avoir lieu au moins à cette fréquence.

La meilleure façon d’assimiler cette distinction est d’utiliser une chronologie : le RPO se situe à gauche de la panne (données), et le RTO se situe à droite (temps d’arrêt). Une réplique de base de données synchrone sur deux zones de disponibilité peut offrir un RPO proche de zéro et un RTO de quelques secondes via un basculement automatisé. Une sauvegarde nocturne sur bande expédiée hors site offre, au mieux, un RPO de 24 heures et un RTO mesuré en jours.

Deux métriques complémentaires complètent le vocabulaire. Le temps moyen de réparation (MTTR) est le temps moyen observé pour restaurer un composant défaillant, tandis que le temps moyen entre les pannes (MTBF) décrit la fiabilité. Un MTBF élevé et un MTTR faible sont les objectifs d’ingénierie qui rendent les RTO agressifs réalisables.

Analyse d’impact sur l’activité (BIA)

Les valeurs de RTO et de RPO ne sont pas choisies par le département informatique — elles découlent d’une analyse d’impact sur l’activité (BIA). La BIA identifie systématiquement les processus métier, les associe aux actifs technologiques qui les soutiennent, et quantifie les dommages opérationnels, financiers, réglementaires et de réputation qui s’accumulent à mesure qu’une panne se prolonge. Un système de paie peut avoir un RTO modeste de 48 heures car les salaires sont versés toutes les deux semaines, tandis que le dossier d’administration électronique des médicaments d’un hôpital peut exiger un RTO de quelques minutes car la sécurité des patients se dégrade immédiatement.

La BIA produit plusieurs artefacts en aval : un niveau de criticité pour chaque système, la durée d’indisponibilité maximale tolérable (MTD) qui est le plafond absolu au-delà duquel la reprise n’a plus de sens, et les paires RTO/RPO qui guident les choix d’architecture. Elle met également en évidence les dépendances — la reprise d’un système de gestion des commandes sans la reprise simultanée de son fournisseur d’authentification, de sa base de données et de sa passerelle de paiement ne produit rien d’utilisable.

Stratégies de site de reprise

Lorsqu’un site principal est perdu, les charges de travail doivent être déplacées quelque part. Les trois types canoniques de sites alternatifs arbitrent entre le coût et la vitesse de reprise.

Un site chaud (hot site) est une réplique entièrement opérationnelle de la production. Le matériel est installé en rack, les logiciels sont sous licence et patchés, et les données sont répliquées en continu. Le basculement peut se mesurer en minutes, voire en secondes, lorsqu’il est combiné à une répartition de charge globale. Les sites chauds offrent les RTO et RPO les plus bas, mais impliquent le coût le plus élevé, doublant de fait les dépenses d’infrastructure.

Un site tiède (warm site) occupe une position intermédiaire. Le matériel et la connectivité sont en place, et certains logiciels de base sont installés, mais les données ne sont pas répliquées en continu — elles doivent être restaurées à partir d’une sauvegarde, et la configuration finale est achevée lors de l’activation. Les sites tièdes permettent généralement une reprise en quelques heures à une journée.

Un site froid (cold site) fournit l’espace physique, l’alimentation, le refroidissement et la connectivité Internet, mais guère plus. Les serveurs doivent être expédiés ou achetés, les systèmes d’exploitation installés, les applications déployées et les données restaurées à partir de sauvegardes. Un site froid est peu coûteux à maintenir mais peut nécessiter des jours ou des semaines pour être mis en service. Considérer un site froid comme une destination de basculement rapide est une erreur de planification récurrente ; il ne convient qu’aux systèmes dont le RTO se mesure en jours.

Les architectures modernes s’appuient de plus en plus sur la reprise basée sur le cloud — veilleuse (pilot light), secours tiède (warm standby) ou multi-région actif/actif — ce qui estompe ces catégories. Une conception en veilleuse (pilot-light) maintient en fonctionnement un minimum de services essentiels (une base de données répliquée, par exemple), tandis que le reste de la pile est démarré à la demande à partir de modèles d’infrastructure en tant que code.

Basculement (Failover), retour arrière (Failback) et haute disponibilité

Le basculement (Failover) est l’action de transférer le trafic d’un système principal défaillant vers un système de secours. Il peut être automatique, déclenché par des vérifications de santé et des changements DNS ou BGP, ou manuel, nécessitant une autorisation humaine. Le retour arrière (Failback) — le retour au site principal d’origine une fois celui-ci réparé — est souvent négligé dans la planification, pourtant, il comporte son propre risque : les données écrites sur le site de basculement pendant la panne doivent être réconciliées et répliquées en retour avant le changement, sous peine de perdre des écritures.

La redondance au niveau des composants soutient ces stratégies. Les répartiteurs de charge (load balancers) distribuent le trafic entre les nœuds actifs. Les bases de données en cluster se répliquent de manière synchrone au sein d’une région et de manière asynchrone entre les régions. Le RAID protège contre les pannes de disque mais ne constitue pas une sauvegarde. Des chemins réseau redondants, des alimentations doubles provenant de PDU distincts et des circuits de FAI (ISP) diversifiés éliminent les points de défaillance uniques au sein du centre de données.

Continuité de l’alimentation : ASI, groupes électrogènes et décisions de défaillance ouverte

La continuité de l’alimentation électrique est le fondement de tout. Une alimentation sans interruption (ASI), ou UPS, comble l’intervalle entre une panne de courant et le démarrage du groupe électrogène, offrant généralement 5 à 15 minutes d’autonomie sur batterie. Les groupes électrogènes fournissent une alimentation de secours durable, généralement au diesel ou au gaz naturel, et doivent être testés en charge régulièrement. Les contrats de carburant, le fonctionnement du commutateur de transfert et les séquences de démarrage du groupe électrogène sont autant d’éléments qui peuvent échouer silencieusement jusqu’à ce qu’ils soient sollicités. Un test trimestriel en charge réelle est bien plus révélateur qu’un simple démarrage à vide mensuel.

Les dispositifs de sécurité soulèvent une question distincte en cas de panne d’alimentation ou de logiciel : doivent-ils être en défaillance ouverte (fail-open) ou en défaillance fermée (fail-closed) ? Un pare-feu en défaillance ouverte laisse passer le trafic lorsque l’équipement tombe en panne, préservant la disponibilité au détriment de la sécurité. Un pare-feu en défaillance fermée bloque tout le trafic, préservant la sécurité au détriment de la disponibilité. Les contrôles d’accès physiques sont confrontés au même dilemme : une serrure de porte électronique en défaillance fermée peut piéger les occupants lors d’un incendie. Les normes de sécurité des personnes imposent donc généralement un comportement en défaillance ouverte (également appelé fail-safe ou à sécurité positive) pour les issues de secours.

Tests : exercice sur table, revue de plan, simulation et interruption complète

Un plan qui n’a jamais été testé n’est qu’une hypothèse. Les tests suivent un spectre de réalisme et de risque.

Un exercice sur table rassemble les parties prenantes autour d’une table pour discuter d’un scénario : « un ransomware a chiffré le cluster VMware principal dimanche à 2 heures du matin ; décrivez-moi les six prochaines heures. » Il met en lumière les lacunes dans la documentation, les listes de contacts, les autorités décisionnelles et les hypothèses. Il ne comporte aucun risque opérationnel et constitue le point de départ approprié.

Une revue de plan ou revue structurée examine le document du plan lui-même pour en vérifier l’exactitude. Une simulation introduit des jeux de rôle et des injects (événements imprévus). Un test en parallèle met en service le site de secours parallèlement à la production, sans basculement. La forme la plus rigoureuse, un test en interruption complète, consiste à basculer réellement la production vers le site de secours. C’est un test coûteux, perturbateur, et le seul qui prouve que le plan fonctionne vraiment.

Chaque test doit inclure le plan de retour en arrière (backout plan) : comment revenir à l’état initial si le basculement lui-même échoue ou corrompt des données. Les tests en charge des groupes électrogènes, les exercices de restauration de sauvegardes et les activations de l’arbre de communication doivent figurer sur le même calendrier récurrent que l’application des correctifs logiciels.

Scénario pratique : l’échec d’un plan de reprise non testé lors d’un incident réel

Le plan de reprise d’activité (PRA) d’une banque régionale spécifiait un site tiède avec un RTO de quatre heures pour son système bancaire central. Le plan avait été rédigé trois ans auparavant et revu annuellement sur papier, mais jamais testé par une activation réelle. Lorsqu’un déclenchement du système d’extinction d’incendie a détruit l’infrastructure de refroidissement du datacenter principal, la banque a tenté d’activer le site tiède. L’équipe a découvert que le système d’exploitation du serveur de sauvegarde avait deux versions majeures de retard sur la version de production actuelle et était incompatible avec la version applicative en cours. Les tâches de sauvegarde de la base de données échouaient silencieusement depuis six semaines en raison de l’expiration d’un certificat sur l’agent de sauvegarde. La reprise réelle a pris 31 heures, soit près de huit fois le RTO documenté, et la banque a fait l’objet d’un examen réglementaire pour l’écart entre ses capacités de reprise documentées et réelles. La leçon à retenir : le RTO et le RPO sont des engagements d’ingénierie, pas des objectifs ambitieux, et ils doivent être validés par des tests réalistes au moins une fois par an.

← Sécurité des données · Tous les domaines · Sécurité des terminaux →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →