Qu'est-ce qu'un plan de reprise après sinistre ? Composants, RTO/RPO, tests et checklist

Un plan de reprise après sinistre (PRA, ou DR pour disaster recovery) est une procédure écrite et testée pour restaurer les systèmes IT et les données après une panne majeure, une cyberattaque ou la perte d'un site. Il précise qui déclare le sinistre, quels systèmes reviennent en premier, avec quelle rapidité (RTO), quelle perte de données est acceptable (RPO), ainsi que les étapes de bascule et de retour.

Points clés

• Un PRA restaure la technologie ; un plan de continuité d'activité (PCA) maintient l'ensemble de l'entreprise en fonctionnement. Il vous faut les deux, et le PRA doit être un sous-ensemble du PCA.
• Toute décision de reprise commence par deux chiffres par système : l'objectif de temps de reprise (RTO) et l'objectif de point de reprise (RPO).
• Le DR cloud suit quatre stratégies standard : sauvegarde et restauration, pilot light, warm standby et multi-sites actif/actif. Le coût et la rapidité de reprise augmentent ensemble.
• Un plan non testé n'est qu'une supposition. Testez au moins une fois par an, et plus souvent pour les systèmes critiques, des exercices sur table jusqu'à la bascule complète.
• Dans l'UE, l'article 21 de NIS2 range la « gestion des sauvegardes et la reprise après sinistre » parmi les mesures de sécurité minimales. En Suède, elle s'applique par la loi sur la cybersécurité (Cybersäkerhetslagen) depuis le 15 janvier 2026.

Qu'est-ce qu'un plan de reprise après sinistre ?

C'est le guide technique pour remettre les systèmes en service après un événement que la résilience normale ne peut absorber. Les déclencheurs typiques sont un ransomware, la panne d'un centre de données ou d'une région cloud, une base de données corrompue, un changement raté, un incendie ou une inondation.

Le NIST SP 800-34 définit un PRA comme « un plan écrit de reprise d'un ou plusieurs systèmes d'information sur un site de secours en réponse à une défaillance matérielle ou logicielle majeure ou à la destruction des installations » (NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems). Le même guide souligne qu'un PRA se concentre sur les systèmes d'information, tandis qu'un plan de continuité d'activité couvre les processus métier tels que la paie ou le service client.

Vous rencontrerez aussi les termes « plan de reprise informatique », « DRP » ou « disaster recovery plan ». Ils désignent la même chose. Un bon plan est assez court pour être utilisable sous pression : droits de décision, priorités, runbooks, contacts et preuves de test. Un long document de politique que personne n'a ouvert depuis le dernier audit ne compte pas.

Reprise après sinistre et continuité d'activité

La reprise après sinistre restaure l'IT. La continuité d'activité permet à l'organisation de continuer à fournir ses produits et services alors que l'IT, les personnes, les locaux ou les fournisseurs sont perturbés. Le livre blanc d'AWS sur le DR l'exprime clairement : le PRA « devrait être un sous-ensemble du plan de continuité d'activité (PCA) de votre organisation, et non un document autonome ».

Pour une comparaison plus détaillée, y compris le BCDR sur AWS, Azure et Google Cloud, lisez notre guide sur la reprise après sinistre et la continuité d'activité dans le cloud.

Sauvegarde et reprise après sinistre

La sauvegarde est une copie des données. La reprise après sinistre est la capacité de remettre le service en marche. Vous pouvez disposer de sauvegardes parfaites et rester à l'arrêt pendant des jours si personne n'a scripté la reconstruction des serveurs, des réseaux, des identités et du DNS autour d'elles. Les sauvegardes sont une entrée du PRA ; la règle 3-2-1 (trois copies, deux types de supports, une hors site) est une base raisonnable.

À quoi sert un PRA ?

Son but est de rendre la reprise prévisible. Lorsqu'un sinistre survient, le plan remplace l'improvisation par des décisions prises calmement à l'avance.

• Limiter l'indisponibilité. Les systèmes critiques reviennent dans un délai convenu, dans un ordre convenu.
• Limiter la perte de données. Les sauvegardes et la réplication s'exécutent à la fréquence validée par l'entreprise.
• Lever les ambiguïtés. Chacun sait qui peut déclarer un sinistre, qui pilote, et qui s'adresse aux clients et aux autorités.
• Maîtriser les coûts. Tous les systèmes n'ont pas besoin d'un site de secours à chaud. Le plan consigne lesquels en ont besoin et pourquoi.
• Démontrer la conformité. Les autorités de contrôle, auditeurs, assureurs et grands clients demandent de plus en plus une capacité de reprise testée, et pas seulement une politique.

Ce sont aussi les bénéfices que recherchent les acheteurs. Un plan qui a été exercé raccourcit les pannes réelles, car les équipes ont déjà répété les étapes.

RTO et RPO : les deux chiffres qui structurent le plan

L'objectif de temps de reprise (RTO) est la durée pendant laquelle un système peut être indisponible. L'objectif de point de reprise (RPO) est la quantité de données, mesurée en temps, que vous pouvez vous permettre de perdre. AWS définit le RTO comme « le délai maximal acceptable entre l'interruption du service et son rétablissement » et le RPO comme « la durée maximale acceptable depuis le dernier point de récupération des données ».

Exemple chiffré. Une boutique en ligne convient d'un RTO de 4 heures et d'un RPO de 15 minutes pour son système de commandes. Si la base de données tombe à 10 h 00, les commandes doivent être de nouveau acceptées au plus tard à 14 h 00, et seules les commandes passées entre 9 h 45 et 10 h 00 peuvent devoir être ressaisies ou récupérées par d'autres moyens. Une sauvegarde nocturne ne peut pas tenir ce RPO ; la boutique a besoin d'un envoi de journaux ou d'une réplication au moins toutes les 15 minutes. Son wiki interne, à l'inverse, peut accepter un RTO de 3 jours et un RPO de 24 heures, ce qu'une sauvegarde quotidienne couvre.

Deux règles pratiques aident :

• Fixez les objectifs par système, au moyen d'une analyse d'impact sur l'activité (BIA), et non un chiffre unique pour « l'IT ». L'impact peut aussi varier dans le temps : AWS note qu'une panne de la paie juste avant le jour de paie fait bien plus mal qu'une panne juste après.
• Gardez le RTO inférieur à l'interruption maximale tolérable du processus métier. Le NIST SP 800-34 explique que le RTO « doit normalement être plus court » que cette limite, car les données doivent encore être retraitées une fois les systèmes revenus.

Pour plus d'exemples et une méthode pas à pas de définition des deux objectifs, consultez RPO et RTO en reprise après sinistre expliqués.

Stratégies de DR : de la sauvegarde et restauration à l'actif/actif

Le livre blanc d'AWS Disaster Recovery of Workloads on AWS regroupe le DR cloud en quatre stratégies. Les mêmes schémas s'appliquent sur Azure (où Azure Site Recovery réplique les machines virtuelles vers une région secondaire) et sur Google Cloud.

La distinction entre pilot light et warm standby déroute de nombreuses équipes. AWS la formule ainsi : un environnement pilot light « ne peut pas traiter de requêtes sans action supplémentaire préalable », alors qu'un warm standby « peut prendre en charge du trafic (à capacité réduite) immédiatement ». Notre article sur la reprise après sinistre en pilot light détaille ce schéma.

Deux points du livre blanc sont souvent négligés. D'abord, une architecture multi-AZ au sein d'une région « peut déjà répondre à une grande partie de vos besoins de réduction des risques » pour les défaillances au niveau d'un centre de données ; une seconde région sert aux événements touchant toute une région ou aux exigences réglementaires. Ensuite, la sauvegarde et restauration n'est rapide que si l'infrastructure est définie en code, car il faut redéployer les réseaux, les serveurs et la configuration en plus des données.

DRaaS et reprise après sinistre dans le cloud

Le disaster recovery as a service (DRaaS) signifie qu'un prestataire réplique vos serveurs dans son cloud et exploite les outils de bascule. AWS Elastic Disaster Recovery et Azure Site Recovery en sont les options natives ; les prestataires de services managés construisent autour d'elles les runbooks, la supervision et les tests. Le DRaaS transforme un projet d'investissement (un second centre de données) en coût d'exploitation, mais il ne vous décharge pas de définir le RTO/RPO, d'approuver le plan et de participer aux tests.

Sites chauds, tièdes et froids

Avant les régions cloud, les stratégies de DR se décrivaient par le niveau de préparation du site de secours. Le NIST SP 800-34 décrit les sites froids comme des locaux dotés d'électricité, de refroidissement et de connectivité mais sans équipement, les sites tièdes comme partiellement équipés en matériel et télécoms, et les sites chauds comme entièrement configurés avec matériel, infrastructure et personnel. Un site froid est le moins cher mais peut demander des jours ou des semaines pour être opérationnel. Les équivalents cloud correspondent à peu près à la sauvegarde et restauration (froid), au pilot light ou warm standby (tiède) et à l'actif/actif (chaud). Pour en savoir plus, lisez ce qu'est un site chaud en reprise après sinistre.

Que doit contenir un PRA ? Checklist

Utilisez cette checklist pour construire un nouveau plan ou auditer un plan existant. Chaque ligne doit exister sous forme d'artefact nommé et daté, pas d'une promesse.

Comment élaborer un PRA en sept étapes

1. Réalisez une analyse d'impact sur l'activité et une analyse de risques. C'est la première étape de tout effort de DR. Listez les processus métier, le coût d'une panne par heure et les systèmes nécessaires à chacun.
2. Fixez le RTO et le RPO par système. Regroupez les systèmes en trois ou quatre niveaux pour concevoir par niveau plutôt que pour des centaines de serveurs individuels.
3. Choisissez une stratégie par niveau. Associez chaque niveau à la sauvegarde et restauration, au pilot light, au warm standby ou à l'actif/actif. Comparez le coût à l'impact mesuré à l'étape 1.
4. Construisez la capacité technique. Sauvegardes, copies inter-régions ou inter-comptes, réplication, infrastructure as code, supervision et alertes aussi dans l'environnement de reprise.
5. Rédigez les runbooks. Des étapes courtes et numérotées qu'un ingénieur d'astreinte peut suivre à 3 h du matin, retour en production compris.
6. Testez et corrigez. Commencez par un exercice sur table, puis des tests de restauration, puis une bascule. Consignez les RTO et RPO mesurés.
7. Maintenez-le. Revoyez-le au moins une fois par an et après chaque changement important des systèmes, des fournisseurs ou de l'organisation.

Reprise après sinistre face aux cyberincidents et aux ransomwares

Pour beaucoup d'entreprises, le sinistre pour lequel il faut vraiment se préparer est un ransomware ou un compte administrateur compromis, plutôt qu'une inondation. Cela change le plan de trois façons.

• La réplication ne suffit pas. AWS avertit que la réplication continue « peut ne pas protéger contre des événements de sinistre tels que la corruption de données ou une attaque malveillante (comme une suppression non autorisée de données) aussi bien que des sauvegardes à un instant donné ». Conservez des sauvegardes à un instant donné que les attaquants ne peuvent pas supprimer, idéalement dans un compte distinct avec d'autres identifiants.
• La reprise commence après le confinement. Le plan de réponse à incident détermine quand l'environnement est assez sain pour y restaurer. Restaurer sur une infrastructure compromise la réinfecte.
• L'identité est une dépendance. Si votre fournisseur d'identité ou votre gestionnaire de mots de passe est indisponible ou compromis, les runbooks doivent indiquer comment les intervenants obtiennent un accès.

Quand un PRA est-il déclenché ?

Le plan est déclenché lorsqu'une panne dépasse, ou va clairement dépasser, ce que la gestion normale des incidents peut corriger dans le RTO. Consignez les critères par écrit, par exemple « région principale indisponible plus de 30 minutes » ou « données de production chiffrées par un ransomware », et nommez qui décide. Consultez quand activer un plan de reprise après sinistre pour les déclencheurs typiques.

À quelle fréquence tester un PRA ?

Testez au moins une fois par an, et après chaque changement important. Les systèmes critiques méritent des exercices plus fréquents. La politique de contingence type du NIST indique que les capacités de reprise « doivent être testées annuellement », et le guide recommande de revoir le plan « au moins annuellement » et après les changements importants.

Le NIST adapte aussi la profondeur des tests au niveau d'impact du système. Pour les systèmes à faible impact, un exercice sur table suffit ; les systèmes à impact modéré exigent un exercice fonctionnel incluant la restauration depuis une sauvegarde ; les systèmes à fort impact exigent un exercice fonctionnel à grande échelle incluant « une bascule du système vers le site de secours ».

La colonne de fréquence est notre recommandation pour une entreprise moyenne type ; votre autorité de contrôle ou vos clients peuvent exiger davantage. AWS résume pourquoi les tests comptent : « la seule reprise sur erreur qui fonctionne est le chemin que vous testez fréquemment ». Après chaque test, consignez le temps de reprise et la perte de données mesurés, comparez-les à vos objectifs et attribuez un responsable à chaque écart.

NIS2 et la loi suédoise sur la cybersécurité

Pour les organisations relevant de NIS2, la reprise après sinistre n'est plus une bonne pratique facultative. L'article 21, paragraphe 2, point c), de la directive (UE) 2022/2555 (NIS2) impose que les mesures de gestion des risques incluent au minimum « la continuité des activités, par exemple la gestion des sauvegardes et la reprise après sinistre, et la gestion des crises ». L'article 23 ajoute des délais de notification pour les incidents importants : une alerte précoce dans les 24 heures suivant la prise de connaissance et une notification d'incident dans les 72 heures. Votre PRA et votre processus de notification d'incident doivent donc fonctionner ensemble.

En Suède, NIS2 est transposée par la loi sur la cybersécurité (Cybersäkerhetslag, SFS 2025:1506), entrée en vigueur le 15 janvier 2026. Le chapitre 2, section 3, cite « kontinuitetshantering och krishantering » (gestion de la continuité et gestion de crise) parmi les mesures de sécurité minimales. Attendez-vous à ce que les autorités de supervision demandent des preuves : un plan à jour, des rapports de tests et des constats clos.

Comment Opsio vous accompagne

Opsio conçoit, exploite et teste le DR pour les workloads sur AWS et Azure dans le cadre de son service de reprise après sinistre cloud.

Questions fréquentes

Quels sont les composants clés d'un plan de reprise après sinistre ?

Les composants essentiels sont une analyse d'impact sur l'activité et une analyse de risques, le RTO et le RPO par système, une stratégie de reprise par niveau, la sauvegarde et la réplication, les critères d'activation, les rôles et contacts, des runbooks pas à pas incluant le retour en production, un plan de communication, ainsi qu'un calendrier de tests et de maintenance.

Quelle est la première étape d'un effort de reprise après sinistre ?

La première étape est une analyse d'impact sur l'activité associée à une analyse de risques. Elle indique quels processus et systèmes comptent le plus et combien de temps ils peuvent être indisponibles, ce qui fixe le RTO et le RPO dont dépend chaque décision ultérieure.

À quelle fréquence tester un plan de reprise après sinistre ?

Au moins une fois par an et après chaque changement majeur des systèmes ou des fournisseurs. Réalisez des exercices sur table pour tous les plans et des tests de restauration ou de bascule pour les systèmes critiques, comme le recommande le NIST SP 800-34 pour les systèmes à impact plus élevé.

Quelle différence entre reprise après sinistre et continuité d'activité ?

La reprise après sinistre restaure les systèmes IT et les données. La continuité d'activité maintient l'entreprise en fonctionnement pendant une perturbation et couvre aussi les personnes, les locaux, les fournisseurs et la communication. Le PRA doit faire partie du plan de continuité d'activité.

Quelles sont les quatre stratégies de reprise après sinistre dans le cloud ?

Sauvegarde et restauration, pilot light, warm standby et multi-sites actif/actif. Elles vont de plusieurs heures de reprise au coût le plus bas à une reprise quasi instantanée au coût le plus élevé, selon le livre blanc DR d'AWS.

NIS2 impose-t-elle une planification de la reprise après sinistre ?

L'article 21, paragraphe 2, point c), de NIS2 impose aux entités essentielles et importantes de couvrir la continuité des activités, « par exemple la gestion des sauvegardes et la reprise après sinistre, et la gestion des crises ». En pratique, cela signifie une capacité de DR documentée et testée que vous pouvez présenter à l'autorité de supervision.