PRA cloud : plan de reprise d’activité

Un PRA cloud, ce n'est pas une option d'assurance qu'on coche puis qu'on oublie : c'est la capacité, mesurée et testée, de remettre votre activité en marche après un sinistre, panne majeure, erreur humaine, ransomware, perte d'une région. La vraie question n'est pas « avons-nous un PRA ? » mais « en combien de temps redémarrons-nous, avec quelles données, et l'avons-nous prouvé ? ». Cette page démonte le sujet de bout en bout : du cadrage métier au choix d'architecture, du chiffrage à la conformité 2026, des tests à l'exploitation, avec le regard d'un intermédiaire indépendant, à l'aise sur Azure comme sur AWS.

Qu'est-ce qu'un PRA cloud et comment fonctionne-t-il ?

Un PRA (plan de reprise d'activité), ou Disaster Recovery Plan, est l'ensemble des moyens techniques et organisationnels qui permettent de restaurer un système d'information après un sinistre, dans un délai et avec une perte de données maîtrisés. Le terme « cloud » désigne ici le fait que le site de secours n'est plus un second datacenter physique que vous achetez, climatisez et entretenez, mais une infrastructure à la demande sur Azure ou AWS, que vous ne payez vraiment qu'au moment où vous en avez besoin.

Un PRA cloud repose sur trois mécanismes fondamentaux qui travaillent ensemble.

• La réplication : vos données (et souvent vos machines entières) sont copiées en continu ou à intervalles réguliers vers une région secondaire ou un second cloud. La réplication asynchrone est la plus répandue : les écritures sont confirmées localement puis propagées vers le site de secours avec un léger décalage, ce qui borne la perte de données potentielle (le RPO).
• La sauvegarde : des copies datées et conservées (snapshots, sauvegardes applicatives) qui permettent de revenir à un point antérieur. C'est le filet contre la corruption logique, la suppression et le chiffrement malveillant, là où la simple réplication échoue, car elle réplique fidèlement le désastre.
• La bascule (failover) : l'action de basculer la production sur le site de secours. Elle peut être manuelle (un humain déclenche un plan de récupération), semi-automatique (déclenchement humain, exécution orchestrée) ou automatique (sur détection de panne). La bascule retour (failback) ramène ensuite l'activité sur le site nominal une fois l'incident résolu.

En une phrase : un PRA cloud, c'est de la réplication pour ne pas tout perdre, de la sauvegarde pour pouvoir revenir en arrière, et une bascule orchestrée et testée pour redémarrer vite. Les trois sont nécessaires ; aucun ne suffit seul.

Le fonctionnement concret suit un cycle de vie. En régime normal, le site de secours est en veille, minimal ou inexistant en compute selon la stratégie choisie, pendant que la réplication maintient les données à jour. Lors d'un sinistre, le plan de récupération s'exécute : provisionnement de la capacité de calcul, restauration ou attachement des données répliquées, reconfiguration réseau et DNS, redémarrage des applications dans le bon ordre de dépendance. Une fois l'activité rétablie et le site nominal réparé, on planifie le failback.

Ce sujet s'inscrit dans une problématique plus large de fiabilité. Si votre environnement souffre de fragilités structurelles au-delà du seul scénario catastrophe, notre page pilier infrastructure cloud instable : solutions traite la fiabilité de bout en bout, et la résilience nominale relève souvent du PCA cloud (plan de continuité d'activité), complémentaire du PRA.

PRA, PCA, sauvegarde et haute disponibilité : ne pas confondre

Quatre notions sont systématiquement mélangées dans les appels d'offres et les conversations de direction. Les distinguer est la base de tout arbitrage budgétaire sain.

| Notion | Ce qu'elle couvre | Quand elle agit | Ce qu'elle ne fait pas | |---|---|---|---| | Sauvegarde | Copies datées des données, conservées et restaurables | Après coup, sur restauration | Ne redémarre pas l'application ; restauration souvent lente | | Haute disponibilité (HA) | Redondance locale (plusieurs instances/zones) pour absorber une panne de composant | En continu, automatiquement | Ne protège pas d'un sinistre régional ni d'une corruption logique répliquée | | PRA | Reprise après sinistre majeur sur un site de secours, avec RTO/RPO cibles | Après un sinistre, sur bascule | Tolère une interruption (le RTO) ; ce n'est pas du « zéro coupure » | | PCA | Continuité de l'activité dans son ensemble (SI + locaux + personnes + processus) | Avant, pendant et après | Le PRA n'en est que le volet informatique |

Trois clarifications s'imposent.

PRA vs PCA. Le PCA (plan de continuité d'activité) est le périmètre large : il vise à maintenir l'activité de l'entreprise face à toute crise, pas seulement informatique. Il englobe les locaux de repli, la gestion des personnes, la communication de crise, les processus métier dégradés. Le PRA est le sous-ensemble technique du PCA : il traite la reprise du système d'information. On peut avoir un PRA solide sans PCA formalisé (fréquent en PME), mais un PCA crédible suppose un PRA qui fonctionne. Pour le volet continuité, voyez PCA cloud.

PRA vs sauvegarde. Une sauvegarde est nécessaire mais pas suffisante. Avoir ses données sauvegardées ne dit rien du temps qu'il faudra pour reconstruire les serveurs, réinstaller les applications, reconfigurer le réseau et redémarrer le tout dans l'ordre. Beaucoup d'entreprises croient avoir un PRA parce qu'elles ont des sauvegardes : elles découvrent, le jour du sinistre, que restaurer 4 To depuis un stockage froid et réinstaller une stack complète prend trois jours, pas trois heures.

PRA vs haute disponibilité. La HA absorbe les petites pannes locales (un serveur tombe, un autre prend le relais) sans interruption perceptible, dans la même région. Le PRA répond aux sinistres majeurs : perte d'une région entière, désastre logique, attaque. Une architecture multi-zones très disponible peut être anéantie par une corruption de données qui se réplique instantanément sur toutes les zones, d'où la nécessité d'un PRA distinct, avec ses points de restauration immuables.

RTO et RPO : les cibles qui pilotent la stratégie de reprise

Tout PRA se construit autour de deux chiffres. Le RTO (Recovery Time Objective) borne la durée maximale d'interruption acceptable ; le RPO (Recovery Point Objective) borne le volume de données qu'on accepte de perdre, exprimé en temps. Côté reprise, ils ne relèvent pas d'un débat théorique : ce sont les deux cadrans qui sélectionnent l'architecture. Un RTO de quelques minutes impose un site de secours déjà actif ; un RPO proche de zéro impose une réplication synchrone, coûteuse et contraignante. Plus on les pousse vers zéro, plus le coût récurrent monte.

La définition métier canonique de ces deux indicateurs, la méthode pour les fixer application par application et les ordres de grandeur à viser par criticité relèvent de la stratégie de continuité. Nous les détaillons dans la section RTO et RPO : définition et objectifs à viser du plan de continuité d'activité (PCA cloud). Sur cette page, nous partons de ces cibles comme d'une donnée d'entrée et nous concentrons sur la façon de les atteindre techniquement, application par application.

Une seule règle opérationnelle à retenir ici : un RTO ou un RPO annoncé mais jamais validé en test de bascule ne vaut rien. Nous présentons toujours nos cibles comme des objectifs visés et mesurés en test, jamais comme des garanties, c'est précisément ce que prouve la campagne de tests décrite plus bas.

L'analyse d'impact métier (BIA) : le point d'entrée du PRA

Avant toute décision d'architecture, le PRA a besoin d'une classification des applications par criticité (vitale / critique / importante / secondaire). C'est elle qui dit où investir dans la résilience et où un simple Backup & Restore suffit. Cette classification est produite par l'analyse d'impact métier (BIA, Business Impact Analysis) et sa matrice criticité-budget.

La BIA, son déroulé question par question et la matrice de décision relèvent de la stratégie de continuité : nous la détaillons dans le BIA (Business Impact Analysis) et la matrice criticité-budget. Côté reprise, nous partons de son livrable, la criticité par application, pour deux décisions strictement opérationnelles : affecter une stratégie DR à chaque application (section suivante) et fixer les cibles RTO/RPO à valider en test.

Un seul rappel de terrain, car il décide du succès d'un PRA bien plus que la technologie : le sinistre ne révèle presque jamais un manque d'outil, mais une dépendance oubliée, un annuaire (Active Directory / Microsoft Entra ID), un DNS, une application classée « secondaire » qui bloque en réalité toute la chaîne de production.

Le PRA doit reprendre la chaîne complète, pas le maillon visible. C'est ce qui sépare un PRA d'apparence d'un PRA de combat.

La cartographie de ces dépendances réelles, souvent différentes de celles que l'on croit, est précisément ce qu'un audit d'infrastructure cloud préalable met à jour, et ce que le plan de reprise doit impérativement intégrer.

Les stratégies d'architecture de reprise dans le cloud

Le cloud a standardisé quatre grandes stratégies de Disaster Recovery, du moins coûteux au plus résilient. Le choix se fait par application, selon sa criticité issue de la BIA, pas pour l'ensemble du SI d'un bloc.

Backup & Restore (sauvegarde et restauration)

Le site de secours n'existe pas en régime normal. On conserve des sauvegardes et, en cas de sinistre, on reconstruit l'infrastructure (idéalement via du code) puis on restaure les données.

• RTO : élevé (heures à jours). RPO : selon la fréquence de sauvegarde.
• Coût : le plus bas, on ne paie que le stockage des sauvegardes.
• Pour qui : applications importantes ou secondaires, environnements de test, contraintes budgétaires fortes.

Pilot Light (veilleuse)

Le cœur critique du système (généralement les bases de données, répliquées en continu) reste actif et à jour sur le site de secours, mais la couche applicative est éteinte ou réduite au minimum. En cas de sinistre, on « rallume » et on dimensionne la couche compute autour d'un socle de données déjà chaud.

• RTO : moyen (dizaines de minutes à quelques heures). RPO : faible (réplication continue des données).
• Coût : modéré, on paie le stockage et la réplication des données, peu de compute.
• Pour qui : applications critiques avec un bon rapport résilience/coût.

Warm Standby (secours tiède)

Une version réduite mais fonctionnelle de l'environnement complet tourne en permanence sur le site de secours, prête à monter en charge. La bascule consiste à rediriger le trafic et à mettre à l'échelle.

• RTO : faible (minutes à dizaines de minutes). RPO : très faible.
• Coût : significatif, on paie un environnement secondaire permanent, même dimensionné a minima.
• Pour qui : applications vitales ou critiques exigeant un redémarrage rapide.

Actif/Actif (Multi-Site)

L'application tourne simultanément sur plusieurs régions (voire plusieurs clouds), le trafic étant réparti entre elles. La perte d'un site est absorbée quasi sans interruption : il n'y a pas de « bascule » à proprement parler, seulement un report de charge.

• RTO : proche de zéro. RPO : proche de zéro (selon la stratégie de données).
• Coût : le plus élevé, double infrastructure active, complexité de cohérence des données.
• Pour qui : services à tolérance d'interruption quasi nulle (paiement, plateformes critiques en continu).

| Stratégie | RTO | RPO | Coût relatif | Complexité | |---|---|---|---|---| | Backup & Restore | Heures à jours | Heures | € | Faible | | Pilot Light | Dizaines de min à h | Minutes | €€ | Moyenne | | Warm Standby | Minutes à dizaines de min | Quasi nul | €€€ | Élevée | | Actif/Actif | ~ 0 | ~ 0 | €€€€ | Très élevée |

Le bon PRA n'applique pas une stratégie unique : il mixe. Backup & Restore pour 60 % du parc, Pilot Light pour les applications critiques, Warm Standby pour les deux ou trois systèmes vitaux. C'est ce dosage, guidé par la BIA, qui rend le PRA à la fois résilient là où il faut et abordable globalement.

DRaaS, PRA « fait maison » ou Cloud-to-Cloud : quel modèle ?

Trois grands modèles de mise en œuvre coexistent. Le choix engage votre autonomie autant que votre budget.

• DRaaS (Disaster Recovery as a Service) : un prestataire vous fournit le PRA « clé en main » comme un service managé (réplication, orchestration, tests, parfois la bascule elle-même). Avantage : rapidité de mise en œuvre, expertise externalisée. Limite : dépendance au prestataire et à sa plateforme, réversibilité parfois difficile, coûts récurrents qui peuvent grimper.
• PRA « fait maison » : vous construisez et exploitez votre PRA avec les outils natifs (Azure Site Recovery, AWS Elastic Disaster Recovery) ou des solutions tierces (Veeam, Zerto). Avantage : maîtrise totale, pas d'enfermement. Limite : exige des compétences internes et une discipline de tests réelle, sinon le PRA dérive.
• Cloud-to-Cloud : le site de secours est dans un autre cloud que la production (Azure ↔ AWS, ou vers un acteur souverain comme OVHcloud). Avantage : protection contre la défaillance globale d'un fournisseur et indépendance accrue. Limite : complexité, coûts de transfert de données, double expertise nécessaire.

Notre positionnement d'indépendant consiste précisément à ne pas vous vendre notre DRaaS, nous n'en avons pas. Les prestataires de notre réseau construisent un PRA qui vous appartient : le code d'infrastructure (Terraform / Bicep) reste dans vos dépôts, les comptes cloud sont à votre nom, la documentation vous est remise. Vous gardez la liberté de changer d'opérateur ou de l'exploiter vous-même. C'est l'inverse du lock-in fréquent chez les hébergeurs qui louent leur PRA propriétaire. Cette logique d'autonomie traverse toute notre démarche, du conseil en architecture à l'infogérance cloud entreprise.

Azure Site Recovery vs AWS Elastic Disaster Recovery : comparatif neutre

C'est le comparatif que presque aucun acteur du SERP ne porte, parce que la plupart vendent un seul cloud ou une seule plateforme. Voici une lecture indépendante des deux solutions natives de DR des hyperscalers. Les valeurs ci-dessous sont des ordres de grandeur observés, à valider sur votre périmètre réel, elles dépendent du débit de réplication, du volume et du paramétrage.

| Critère | Azure Site Recovery (ASR) | AWS Elastic Disaster Recovery (AWS DRS, ex-CloudEndure) | |---|---|---| | Cloud cible | Microsoft Azure (région secondaire) | AWS (région secondaire) | | Réplication | Asynchrone, en continu (niveau bloc) | Asynchrone, en continu (niveau bloc) | | RPO atteignable | De l'ordre de quelques minutes (souvent < 5 min) | De l'ordre de quelques secondes à minutes | | RTO atteignable | Quelques minutes à dizaines de minutes (plan de récupération orchestré) | Quelques minutes à dizaines de minutes | | Sources | VM Azure, VMware, machines physiques, autres clouds | VM AWS, VMware, physiques, autres clouds | | Orchestration | Recovery Plans (groupes, ordre de démarrage, scripts/runbooks) | Lancement de drills et de recovery, automatisation via API | | Tests non disruptifs | Oui (test failover isolé) | Oui (recovery/drill instances isolées) | | Coût en veille | Stockage répliqué + licence ASR par instance protégée | Faible compute de réplication (instances légères) + stockage | | Régions | Large couverture mondiale, dont régions France | Large couverture mondiale, dont régions Paris/UE | | Bon usage | Parcs Windows/Azure, écosystème Microsoft, hybride VMware | Charges AWS, hétérogène, migration + DR conjointes |

La lecture honnête : les deux solutions atteignent des objectifs comparables pour la majorité des charges (RPO de quelques minutes, RTO de l'ordre de la dizaine de minutes avec une orchestration soignée). Le choix se fait moins sur la performance brute que sur votre écosystème existant, vos compétences internes, votre stratégie de souveraineté et le reste de votre architecture. Un parc fortement Microsoft avec Entra ID gravite naturellement vers Azure et ASR ; un SI déjà sur AWS capitalise sur AWS DRS. Pour des besoins de réplication multi-plateformes ou indépendants du cloud cible, des solutions comme Veeam ou Zerto offrent une couche d'abstraction utile.

C'est exactement là que l'indépendance compte : nous évaluons votre contexte plutôt que de défendre une plateforme. Approfondir côté Microsoft : architecte Azure.

Combien coûte un PRA cloud ? Chiffrage, ROI et coût d'une heure d'arrêt

Le réflexe « combien ça coûte ? » est légitime, mais il se renverse : la vraie question est « combien me coûte une heure d'arrêt ? ». Tant que ce chiffre n'est pas posé, aucun budget PRA ne peut être arbitré rationnellement.

Calculer le coût d'une heure d'indisponibilité

Une formule simple, utilisable en comité de direction, pour objectiver la dépense auprès de la DAF :

Coût d'une heure d'arrêt ≈ (Chiffre d'affaires horaire impacté) + (Coût horaire de la masse salariale immobilisée) + (Pénalités contractuelles & SLA) + (Coût de remédiation) + (Impact réputationnel estimé)

Exemple illustratif pour une PME e-commerce réalisant 6 M€ de CA en ligne sur 3 000 heures d'ouverture annuelle : le CA horaire moyen avoisine 2 000 €. Ajoutez 40 collaborateurs partiellement bloqués (disons 1 500 €/h de masse salariale immobilisée), des pénalités fournisseurs et un coût de remédiation. On dépasse vite 4 000 à 6 000 € par heure, soit, sur une panne d'une journée, plusieurs dizaines de milliers d'euros. À ce tarif, un PRA se rentabilise dès le premier incident évité. C'est cet exercice, et non un argumentaire commercial, qui justifie le budget.

Les facteurs qui font le prix d'un PRA cloud

Le coût d'un PRA cloud dépend de variables précises :

• Le nombre de VM / d'applications à protéger et leur volumétrie de données.
• Les RTO/RPO visés : plus ils sont bas, plus l'architecture (Warm Standby, Actif/Actif) et donc le coût récurrent montent.
• La stratégie retenue par application (Backup & Restore est marginal, Actif/Actif est lourd).
• Le niveau de service : PRA simplement construit et documenté, ou exploité et testé régulièrement en infogérance.
• Les coûts récurrents cloud : stockage de réplication, instances en veille, transferts de données inter-régions, licences (ASR, Veeam, Zerto).
• La conformité : un PRA soumis à DORA ou HDS impose des tests, une traçabilité et une documentation plus exigeants.

Durée, livrables et budget indicatif

La mise en place d'un PRA cloud avec les prestataires de notre réseau s'étale généralement sur 3 à 10 jours de cadrage et de construction, selon le périmètre et le nombre d'applications. Le budget indicatif se situe dans une fourchette de 8 000 à 20 000 € pour la conception, la construction et la première campagne de tests, toujours sur devis selon le périmètre réel, jamais un prix ferme. À cela s'ajoutent les coûts récurrents d'exploitation cloud (stockage, réplication) et, optionnellement, un forfait d'infogérance pour les tests et le maintien en conditions opérationnelles.

Les livrables d'un projet PRA type :

• Le dossier de BIA et la classification des applications par criticité.
• Le document d'architecture DR (stratégie par application, RTO/RPO cibles, schémas).
• Le code d'infrastructure (Terraform / Bicep) du site de secours, versionné dans vos dépôts.
• Les runbooks de bascule et de retour (plans de récupération orchestrés).
• Le rapport de la campagne de tests initiale (scénarios joués, RTO/RPO constatés, écarts).
• Le plan de gouvernance de crise (rôles, déclencheurs, communication).

Trois niveaux de service, présentés en fourchette indicative et adaptés au périmètre :

| Niveau | Périmètre | Esprit | |---|---|---| | Essentiel | Backup & Restore industrialisé + sauvegardes immuables, runbook documenté | Socle de protection, budget contenu | | Avancé | Pilot Light / Warm Standby sur applications critiques, IaC, tests semestriels | Équilibre résilience / coût pour PME-ETI | | Critique | Warm Standby / Actif-Actif, tests fréquents, conformité DORA/HDS, exploitation 24/7 | Secteurs réglementés et activités vitales |

Pour optimiser les coûts récurrents du site de secours sans dégrader la résilience, notre approche FinOps et notre page optimisation des coûts cloud sont directement mobilisables : extinction des environnements non sollicités, paliers de stockage, dimensionnement juste de la veille.

PRA et conformité : ce que les régulateurs exigent côté tests

Le cadre réglementaire de la continuité (DORA, NIS2, HDS, ISO 22301) et son périmètre détaillé (qui est assujetti, à quels seuils, sous quelles sanctions) relèvent de la stratégie de continuité : nous le traitons dans conformité et obligations de continuité (DORA, NIS2, HDS, ISO 22301). Ce qui nous occupe ici, c'est sa traduction opérationnelle sur le PRA, et elle tient en un mot : la preuve.

Quel que soit le texte applicable, la même exigence revient : un PRA n'est conforme que s'il est testé, documenté et auditable. La conformité ne se décrète pas dans un classeur ; elle se démontre dans la campagne de tests.

• DORA (secteur financier et assurance) impose des tests de résilience réguliers, y compris des tests avancés, la maîtrise des prestataires tiers et une réversibilité démontrable. Concrètement : des campagnes de tests planifiées, des rapports d'écarts archivés, et un PRA dont vous gardez le contrôle (code et comptes à votre nom). Voir notre approche du secteur finance.
• NIS2 (transposition française attendue via la loi de résilience en 2026) fait de la continuité d'activité et de la gestion de crise une mesure attendue : un PRA testé et journalisé devient un élément de preuve de conformité, pas un confort.
• HDS (santé) : le site de secours doit rester chez un partenaire certifié HDS, chiffrement et traçabilité préservés jusqu'au bout de la chaîne de réplication, y compris pendant un test de bascule. Voir le secteur santé.

La conséquence pratique est simple : ces exigences se conçoivent dans la démarche de test (fréquence, scénarios, journal de preuves), détaillée plus bas, et non comme un volet documentaire ajouté après coup. Pour le détail du cadre réglementaire et des obligations par secteur, reportez-vous au plan de continuité d'activité (PCA cloud) ; les enjeux de sécurisation de l'infrastructure cloud et de gouvernance cloud y sont directement liés. Le secteur public est également exposé.

PRA et ransomware : sauvegardes immuables, air-gap et restauration propre

C'est le scénario qui a changé la donne, et celui que la plupart des contenus traitent superficiellement. Un PRA conçu pour la panne ne protège pas du ransomware, il peut même l'aggraver.

Le piège : la réplication réplique le désastre. Si un rançongiciel chiffre vos données en production, une réplication asynchrone propage fidèlement les fichiers chiffrés vers le site de secours. Vous obtenez deux copies inutilisables. La haute disponibilité multi-zones ne sauve pas davantage. Seules des sauvegardes saines et antérieures à l'infection permettent une restauration propre.

Les bonnes pratiques anti-ransomware d'un PRA moderne :

• Sauvegardes immuables : des copies qui ne peuvent être ni modifiées ni supprimées pendant une durée définie (verrouillage WORM, immutable storage / Object Lock côté Azure et AWS). Même un attaquant ayant compromis les comptes ne peut les détruire.
• Air-gap (isolement logique) : des sauvegardes déconnectées ou logiquement isolées du réseau de production, hors de portée d'une propagation latérale.
• Règle 3-2-1(-1-0) : 3 copies, sur 2 supports, dont 1 hors site, étendue à 1 copie immuable/air-gap et 0 erreur vérifiée par restauration testée.
• Isolement du site de reprise : la bascule s'effectue dans un environnement propre et cloisonné, pour éviter de réintroduire la menace.
• Restauration propre (clean room) : on restaure dans une zone isolée, on analyse, on désinfecte, puis on remet en production, on ne rebascule pas à l'aveugle.

L'articulation avec l'assurance cyber est devenue déterminante : les assureurs conditionnent de plus en plus la couverture (et son tarif) à l'existence de sauvegardes immuables, de tests de restauration et d'un PRA documenté. Un PRA solide n'est plus seulement une protection technique, c'est un argument d'assurabilité. Ce sujet relève pleinement de notre offre de cybersécurité cloud et de la sécurisation de l'infrastructure cloud.

PRA versionné en Infrastructure as Code : réversibilité et anti-lock-in

C'est notre différenciateur structurant, et la réponse directe à la peur du « fait maison vs prestataire ». Un site de secours décrit en Infrastructure as Code (Terraform, Bicep, ARM, CloudFormation) change la nature du PRA.

Au lieu d'un environnement secondaire figé qu'il faut maintenir manuellement et qui dérive, le site de reprise devient un artefact reproductible : du code qui reconstruit l'infrastructure de secours à la demande, à l'identique, dans la région ou le cloud de votre choix. Les bénéfices sont concrets.

• Reconstruction à la demande : en stratégie Pilot Light ou Backup & Restore, on ne paie pas un environnement permanent ; le code reconstruit la cible au moment du sinistre (ou du test), réduisant le coût en veille.
• Lutte contre le drift : le code est la source de vérité. La dérive entre la production et le site de secours, l'une des causes majeures d'échec des PRA, se détecte (plan) et se corrige.
• Réversibilité native : parce que le PRA est du code dans vos dépôts, avec des comptes à votre nom, vous n'êtes enfermé chez personne. Vous pouvez le reproduire ailleurs, le confier à une autre équipe, l'auditer. C'est l'exigence même de DORA traduite en pratique.
• Tests reproductibles : un test de PRA devient l'exécution d'un apply dans un environnement isolé, puis sa destruction, répétable, traçable, peu coûteux.

Un PRA décrit en code n'est pas un site de secours qu'on espère à jour : c'est une recette de reconstruction, versionnée, testée, qui vous appartient. C'est la différence entre louer une assurance opaque et posséder un plan que vous pouvez lire, exécuter et améliorer.

Cette approche s'intègre dans une démarche infrastructure & DevOps plus large. Idéalement, la résilience se conçoit dès la construction de la landing zone (Cloud Adoption Framework côté Azure, Landing Zone Accelerator côté AWS), pas après coup.

Étapes de mise en place d'un PRA cloud (méthodologie projet)

La construction d'un PRA cloud suit une méthodologie en sept étapes.

1. Cadrage et BIA : identification des applications, de leurs dépendances, de leur criticité ; définition des RTO/RPO cibles par classe.
2. Choix de stratégie : affectation d'une stratégie (Backup & Restore / Pilot Light / Warm Standby / Actif-Actif) à chaque application selon la matrice criticité × budget × secteur.
3. Conception de l'architecture DR : région(s) de secours, mécanismes de réplication, gestion des identités (Entra ID / Active Directory), DNS, réseau, sécurité du site de reprise.
4. Construction en IaC : codification (Terraform / Bicep) du site de secours, mise en place de la réplication (ASR, AWS DRS, Veeam ou Zerto selon le cas) et des sauvegardes immuables.
5. Orchestration de la bascule : rédaction des runbooks et plans de récupération (ordre de démarrage, scripts, bascule manuelle ou automatique).
6. Tests : campagne de tests non disruptifs validant les RTO/RPO réels et corrigeant les écarts.
7. Exploitation et gouvernance, intégration au cycle de vie : tests périodiques, détection de drift, mise à jour des runbooks, indicateurs de santé.

Détaillons les étapes les plus déterminantes : la conception et les tests.

Soigner les dépendances : DNS, Active Directory, Entra ID

L'anti-pattern le plus coûteux est l'oubli des dépendances transverses. Un PRA qui redémarre l'application mais pas son annuaire (Active Directory / Microsoft Entra ID), son DNS ou sa résolution de noms ne redémarre rien du tout : les utilisateurs ne peuvent s'authentifier, les services ne se trouvent plus. La conception doit traiter ces services socles en priorité et vérifier qu'ils sont, eux aussi, répliqués et joignables depuis le site de secours.

Tester un PRA cloud : fréquence, scénarios, validation

Un PRA jamais testé n'est pas un PRA : c'est une hypothèse. C'est la vérité la plus dure du sujet, et la plus ignorée. La majorité des PRA qui échouent le jour J n'ont jamais été éprouvés en conditions réalistes.

À quelle fréquence tester ? Au minimum une à deux fois par an, et après tout changement majeur d'architecture. Les secteurs réglementés (DORA) imposent une cadence et des scénarios plus exigeants, incluant des tests avancés.

Quels scénarios ?

• Test non disruptif (drill) : on bascule dans un environnement isolé, sans toucher à la production. C'est le test de routine, qui valide les RTO/RPO sans risque pour l'activité. Azure Site Recovery (test failover) et AWS DRS (drill instances) le permettent nativement.
• Test de bascule complète : on bascule réellement, puis on revient (failback). Plus engageant, réservé à des fenêtres planifiées.
• Test de restauration : on restaure des sauvegardes (notamment immuables) pour vérifier qu'elles sont exploitables, la sauvegarde qui ne se restaure pas est le piège classique.
• Scénario ransomware : on simule une restauration propre depuis des sauvegardes antérieures à une infection fictive.

Que valide-t-on ? Le RTO réellement constaté (et non l'objectif théorique), le RPO effectif, l'exhaustivité de la reprise (toutes les dépendances), la justesse des runbooks et la capacité de rollback (revenir en arrière proprement si la bascule échoue). Chaque test produit un rapport d'écarts qui alimente l'amélioration continue.

Le test transforme des chiffres affichés en chiffres prouvés. Tant qu'un RTO n'a pas été mesuré en test, il reste une intention. Nous présentons donc nos résultats comme constatés en test, jamais comme des garanties contractuelles.

Indicateurs de santé d'un PRA et anti-patterns à éviter

Un PRA se pilote dans la durée avec quelques indicateurs simples.

• Taux de couverture applicative : quelle part des applications critiques est réellement protégée par le PRA ?
• Fréquence et taux de succès des tests : combien de tests menés, combien réussis sans écart majeur ?
• Dérive (drift) entre production et site de reprise : l'écart de configuration se mesure et doit tendre vers zéro.
• RTO/RPO constatés vs objectifs : l'écart entre le visé et le mesuré.
• Fraîcheur des runbooks : un runbook obsolète vaut un runbook absent.

Les anti-patterns les plus fréquents, observés sur le terrain :

• Le PRA jamais testé, le plus répandu et le plus dangereux.
• Des RTO/RPO théoriques irréalistes, affichés mais jamais validés.
• Les dépendances oubliées : DNS, Active Directory / Entra ID, passerelles, résolution de noms.
• Le single-region : un PRA dans la même région que la production ne protège pas d'un sinistre régional.
• Le drift non surveillé : le site de secours diverge silencieusement de la production.
• L'absence de gouvernance de crise : personne ne sait qui déclenche la bascule.

Multicloud / cross-cloud DR : quand est-ce justifié ?

Faut-il répliquer son PRA sur un second cloud (Azure ↔ AWS) ? En architecte indépendant, la réponse honnête est : rarement nécessaire, parfois indispensable.

Le cross-cloud DR a du sens quand : vous êtes soumis à une exigence forte de réversibilité ou de souveraineté (DORA, secteurs stratégiques), vous voulez vous prémunir contre la défaillance globale d'un fournisseur, ou votre tolérance au risque l'impose réellement. Il est en revanche un sur-investissement dans la plupart des cas PME/ETI : la complexité, le coût de transfert de données, la double expertise et la difficulté de cohérence des données dépassent souvent le risque réel. Une stratégie multi-région chez un même fournisseur offre déjà une résilience très élevée à un coût bien moindre. Notre rôle d'indépendant est précisément de vous dire quand vous n'en avez pas besoin.

Gouvernance de crise : qui décide, qui déclenche, qui communique

La technique ne suffit pas. Le jour du sinistre, l'absence de gouvernance de crise paralyse autant qu'une panne. Un PRA mature définit, avant l'incident :

• Une matrice de rôles (type RASCI) : qui est Responsable de la bascule, qui Approuve son déclenchement, qui est Soutien, qui est Consulté, qui est Informé.
• Le déclencheur : à partir de quels critères objectifs déclenche-t-on la bascule, et qui a l'autorité de le faire (un seuil d'indisponibilité, une décision du responsable d'astreinte).
• Le plan de communication : informer les utilisateurs, les clients, la direction, et le cas échéant les autorités (les obligations de notification d'incident relèvent de NIS2/DORA).
• La documentation post-incident : retour d'expérience structuré qui alimente l'amélioration du PRA.

Cette dimension organisationnelle est le pont vers le PCA cloud, qui formalise la continuité au-delà du SI. Un PRA technique sans gouvernance de crise reste un demi-PRA.

Pourquoi le cloud surpasse le site physique secondaire traditionnel

Le PRA n'est pas né avec le cloud : il reposait historiquement sur un second datacenter physique, loué ou possédé. Le cloud change l'équation sur plusieurs plans.

• Coût en veille : un datacenter de secours physique se paie en permanence (locaux, matériel, énergie, maintenance), qu'on l'utilise ou non. Dans le cloud, les stratégies Pilot Light ou Backup & Restore ne facturent quasiment que le stockage tant qu'il n'y a pas de sinistre, on paie la capacité de calcul au moment de la bascule.
• Élasticité : impossible de surdimensionner ou sous-dimensionner, la capacité se provisionne à la bascule, à la taille voulue.
• Couverture géographique : les régions et zones des hyperscalers offrent une distance et une diversité géographiques difficiles à reproduire avec deux salles serveurs.
• Automatisation : la réplication, l'orchestration et les tests sont natifs et pilotables par code (IaC), là où un site physique repose sur des procédures manuelles.
• Tests réalistes et bon marché : tester un PRA cloud (drill isolé) coûte peu et n'immobilise rien ; tester une bascule sur site physique est lourd et rare, donc rarement fait.

Cela ne signifie pas que le cloud résout tout automatiquement : un PRA cloud mal conçu (single-region, jamais testé, dépendances oubliées) échoue tout autant. Le cloud offre les bons outils ; encore faut-il une architecture et une discipline justes. C'est précisément l'objet de notre accompagnement. Pour situer le PRA dans une démarche cloud d'ensemble, voir le guide du cloud et notre offre de services. Si votre infrastructure montre des signes d'instabilité plus larges, mieux vaut d'abord fiabiliser une infrastructure cloud instable en amont du PRA ; les enjeux de performance applicative y sont souvent liés.

Pourquoi confier votre PRA cloud à Architecte Cloud

Construire un PRA, c'est faire des choix d'architecture qui engagent votre résilience et votre budget pour des années. Notre valeur tient à quatre points.

• Indépendance Azure & AWS : nous n'avons pas de DRaaS propriétaire à vous vendre. Les prestataires de notre réseau conçoivent le PRA adapté à votre contexte, sur la plateforme qui vous convient, ou en cross-cloud quand c'est justifié, pas par principe.
• Autonomie et réversibilité : le code IaC reste dans vos dépôts, les comptes sont à votre nom, la documentation vous est remise. Vous n'êtes enfermé nulle part, exigence centrale de DORA et de toute stratégie cloud saine.
• Expérience éprouvée : les prestataires de notre réseau totalisent une expérience solide sur des projets de reprise après sinistre et disposent des certifications requises (Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, Azure Security Engineer, FinOps Certified Practitioner) ainsi que des statuts Microsoft Azure Partner et AWS Partner. Démarche ISO 27001, en lien avec la FinOps Foundation.
• Du cadrage à l'exploitation : nous cadrons le besoin et vous mettons en relation avec des prestataires qui mènent la BIA, conçoivent l'architecture, construisent en IaC, testent et, si vous le souhaitez, exploitent le PRA en infogérance 24/7 avec tests réguliers.

Nos études de cas sont représentatives et anonymisées : un groupe industriel (ETI) dont le RTO de l'ERP a été réduit de plus de 24 h à moins de 2 h constatées en test via une stratégie Pilot Light ; un éditeur SaaS sécurisé par une architecture Warm Standby multi-région ; une structure de santé dont le PRA a été reconstruit chez un partenaire certifié HDS avec sauvegardes immuables. Voir nos secteurs, dont l'industrie, la distribution et le SaaS.

Combien ça coûte, en résumé

Pour fixer les idées sans engagement : un projet de mise en place de PRA cloud représente 3 à 10 jours de travail de cadrage et de construction, pour un budget indicatif de 8 000 à 20 000 €, fourchette de conception/construction/tests, sur devis selon le périmètre réel, à laquelle s'ajoutent les coûts récurrents cloud et l'éventuelle exploitation. Ce chiffre se met en regard du coût d'une seule journée d'arrêt, qui le dépasse fréquemment. Le diagnostic initial permet de cibler précisément votre besoin avant tout chiffrage ferme.

Pour démarrer, le plus efficace est un diagnostic : nous évaluons votre exposition, vos RTO/RPO réalistes et la stratégie adaptée. Lancez votre audit en ligne, ou prenez contact via /contact, réponse sous 48 h ouvrées.

FAQ : PRA cloud

Qu'est-ce qu'un PRA cloud et comment fonctionne-t-il ?

Un PRA cloud (plan de reprise d'activité) est l'ensemble des moyens permettant de restaurer votre système d'information après un sinistre, en utilisant une infrastructure de secours sur Azure ou AWS plutôt qu'un second datacenter physique. Il fonctionne sur trois mécanismes : la réplication (vos données et machines sont copiées en continu vers une région de secours), la sauvegarde (copies datées pour revenir en arrière) et la bascule (failover) orchestrée, qui redémarre l'activité sur le site de secours selon un plan de récupération testé.

Quelle différence entre une sauvegarde et un PRA ?

Une sauvegarde est une copie datée de vos données, restaurable. Elle est nécessaire mais insuffisante : elle ne dit rien du temps qu'il faudra pour reconstruire les serveurs, réinstaller les applications, reconfigurer le réseau et redémarrer le tout dans l'ordre. Un PRA organise cette reprise complète, avec des objectifs de délai (RTO) et de perte de données (RPO). Beaucoup d'entreprises croient avoir un PRA parce qu'elles ont des sauvegardes, et découvrent le jour J que la restauration prend des jours.

Combien coûte un PRA cloud ?

Le coût dépend du nombre de VM et d'applications, des RTO/RPO visés, de la stratégie retenue et du niveau de service. À titre indicatif, la conception, la construction et la première campagne de tests d'un PRA cloud représentent une fourchette de 8 000 à 20 000 €, sur devis selon le périmètre réel, à laquelle s'ajoutent les coûts récurrents cloud (stockage, réplication) et l'éventuelle exploitation. La bonne mesure est de comparer ce budget au coût d'une heure d'arrêt, qui le rentabilise souvent dès le premier incident évité.

Comment mettre en place un plan de reprise d'activité dans le cloud ?

En sept étapes : (1) cadrage et analyse d'impact métier (BIA), (2) choix d'une stratégie par application, (3) conception de l'architecture DR, (4) construction en Infrastructure as Code, (5) orchestration de la bascule via des runbooks, (6) tests non disruptifs validant les RTO/RPO réels, (7) exploitation et gouvernance dans la durée (tests périodiques, surveillance du drift). La BIA et les tests sont les étapes qui font la différence entre un PRA réel et un PRA d'apparence.

Le PRA est-il obligatoire (NIS2, DORA) ?

Pour un nombre croissant d'entreprises, oui. DORA impose au secteur financier et de l'assurance une résilience opérationnelle testée et documentée. NIS2, dont la transposition française est attendue via la loi de résilience en 2026, élargirait les obligations à de l'ordre de 15 000 entités, avec des sanctions pouvant atteindre 10 M€ ou 2 % du chiffre d'affaires mondial pour les entités essentielles, la continuité d'activité y figure parmi les mesures attendues. En santé, l'hébergement doit se faire chez un partenaire certifié HDS. Les seuils définitifs dépendent des textes de transposition.

Qu'est-ce que le DRaaS (Disaster Recovery as a Service) ?

Le DRaaS est un modèle où un prestataire fournit le PRA comme un service managé clé en main : réplication, orchestration, tests, parfois la bascule elle-même. Avantage : rapidité et expertise externalisée. Limite : une dépendance au prestataire et à sa plateforme, et une réversibilité parfois difficile. L'alternative est un PRA construit avec les outils natifs (Azure Site Recovery, AWS Elastic Disaster Recovery) ou tiers (Veeam, Zerto) qui vous appartient, c'est notre approche, pour préserver votre autonomie.

Faut-il choisir Azure ou AWS pour son PRA cloud ?

Les deux solutions natives, Azure Site Recovery et AWS Elastic Disaster Recovery, atteignent des objectifs comparables (RPO de quelques minutes, RTO de l'ordre de la dizaine de minutes avec une orchestration soignée). Le choix dépend surtout de votre écosystème existant, de vos compétences internes et de votre stratégie de souveraineté, pas de la performance brute. Un SI fortement Microsoft gravite vers Azure ; un SI déjà AWS capitalise sur AWS DRS. Notre indépendance nous permet d'évaluer votre contexte sans parti pris.

Comment tester un PRA cloud et à quelle fréquence ?

Au minimum une à deux fois par an, et après tout changement majeur d'architecture (plus souvent en secteur réglementé). Le test de routine est le test non disruptif (drill) : on bascule dans un environnement isolé sans toucher à la production, pour mesurer les RTO/RPO réels. On complète par des tests de restauration (notamment des sauvegardes immuables) et des scénarios ransomware. Un PRA jamais testé n'est pas un PRA : c'est une hypothèse.

Un PRA protège-t-il contre les ransomwares ?

Pas automatiquement. La réplication réplique fidèlement le désastre : si vos données sont chiffrées, la copie de secours l'est aussi. La protection passe par des sauvegardes immuables (impossibles à modifier ou supprimer), un air-gap (isolement logique), une restauration propre dans un environnement cloisonné et antérieure à l'infection. Ces dispositifs sont aussi de plus en plus exigés par les assureurs cyber pour accorder une couverture.

Le cloud remplace-t-il un PRA ?

Non. Héberger ses applications dans le cloud n'équivaut pas à disposer d'un PRA. Le cloud fournit d'excellents outils de résilience, mais un environnement cloud mal conçu (single-region, sauvegardes jamais testées, dépendances oubliées) échoue tout autant lors d'un sinistre. Le PRA reste une démarche d'architecture et de discipline à construire et à tester, le cloud la rend simplement plus accessible et moins coûteuse qu'un second datacenter physique.

Quelles sont les différentes stratégies de reprise (Backup & Restore, Pilot Light, Warm Standby) ?

Quatre stratégies, du moins au plus résilient et coûteux : Backup & Restore (pas de site de secours actif, reconstruction après sinistre, RTO élevé, coût minimal) ; Pilot Light (cœur de données répliqué à chaud, couche applicative éteinte, bon équilibre) ; Warm Standby (environnement réduit mais fonctionnel en permanence, RTO faible) ; Actif/Actif (production simultanée sur plusieurs régions, RTO quasi nul, coût maximal). Le bon PRA mixe ces stratégies par application selon la criticité.

Quelle est la différence entre PRA et haute disponibilité ?

La haute disponibilité (HA) assure une redondance locale (plusieurs instances ou zones dans la même région) pour absorber la panne d'un composant sans interruption perceptible. Le PRA répond aux sinistres majeurs : perte d'une région entière, corruption logique, attaque. Une architecture très disponible peut être anéantie par une corruption de données qui se réplique sur toutes les zones, d'où la nécessité d'un PRA distinct, avec des points de restauration immuables et un site de secours géographiquement séparé.