Un plan de reprise d’activité cloud doit permettre de redémarrer vos services dans une région indépendante si un data center entier devient indisponible. Il fixe deux objectifs métier, le délai maximal d’interruption et la perte de données acceptable, puis organise sauvegardes, infrastructure, accès et bascule. Sans tests réguliers, une réplication active ou une sauvegarde terminée ne prouve pas que l’activité pourra réellement reprendre.
Pourquoi préparer la perte complète d’un data center cloud ?
La perte d’un data center cloud peut interrompre une application même lorsque ses serveurs sont virtualisés. En octobre 2026, trois centres de données de Yandex ont été physiquement touchés par des attaques de drones. Des services de taxi, de banque, de messagerie et de livraison ont alors subi des perturbations, selon Yandex et Associated Press.
Le cloud abstrait les machines, pas leur existence physique. Les serveurs, équipements réseau, alimentations et fibres restent installés quelque part. Le Monde indiquait le 13 octobre 2026 que les trois sites concernés figuraient parmi les six grands centres de données Yandex publiquement connus.
Un plan de reprise d’activité cloud, ou PRA cloud, est un dispositif technique et organisationnel qui restaure un service informatique après un sinistre. Il se distingue du plan de continuité d’activité, qui cherche à maintenir les fonctions essentielles pendant la crise. Pour replacer ces notions dans une démarche globale, consultez ce guide sur le PRA, le PCA et les cyberattaques en PME.
La nuance entre data center, zone de disponibilité et région change directement le niveau de risque. Une zone de disponibilité regroupe des infrastructures séparées au sein d’une même région cloud. Une panne régionale exige, selon les recommandations AWS publiées entre 2024 et 2026, des données, des ressources et des configurations déjà disponibles dans une autre région.
Comment définir le RTO et le RPO d’un plan de reprise d’activité cloud ?
Le RTO est la durée maximale acceptable avant le rétablissement d’un service, tandis que le RPO représente la période maximale de données que l’entreprise accepte de perdre. Microsoft Azure recommande en 2026 de fixer ces deux objectifs par une analyse d’impact métier avant de choisir l’architecture du plan de reprise d’activité cloud.
Un RTO de quatre heures signifie que l’application doit être rétablie au plus tard quatre heures après l’incident. Un RPO de quinze minutes signifie qu’une perte des quinze dernières minutes de données reste tolérable. Ces valeurs ne doivent pas être copiées depuis un modèle technique : elles découlent des conséquences commerciales, réglementaires et opérationnelles d’un arrêt.
Commencez par chiffrer ce que provoquent une heure sans commandes, une journée sans extranet ou la perte des écritures récentes. La direction, les métiers et le responsable informatique doivent trancher ensemble. Plus le RTO et le RPO sont courts, plus l’infrastructure de secours doit être disponible et synchronisée, donc coûteuse.
Attention aux chiffres commerciaux présentés sans contexte. En 2026, AWS Prescriptive Guidance associe à titre indicatif la restauration depuis sauvegarde à un délai de plusieurs heures et inférieur à 24 heures, le pilot light à quelques dizaines de minutes, le warm standby à quelques minutes et l’architecture active-active à des objectifs proches de zéro. Ce ne sont pas des garanties universelles.
Quelle architecture de reprise choisir selon les délais métier ?
Quatre architectures couvrent l’essentiel des plans de reprise d’activité cloud : sauvegarde et restauration, environnement minimal dit pilot light, infrastructure de secours active à capacité réduite et multi-région active-active. Le bon choix dépend du RTO, du RPO et du coût d’un arrêt, pas du niveau de sophistication recherché.
| Architecture | Principe | Rétablissement indicatif | Arbitrage principal |
|---|---|---|---|
| Sauvegarde et restauration | Reconstruction après le sinistre | Plusieurs heures, généralement moins de 24 heures selon AWS en 2026 | Coût réduit, reprise lente |
| Pilot light | Socle critique maintenu dans une autre région | Quelques dizaines de minutes selon AWS en 2026 | Déploiement et montée en capacité nécessaires |
| Warm standby | Copie active à capacité réduite | Quelques minutes selon AWS en 2026 | Coût permanent plus élevé |
| Active-active | Production répartie entre plusieurs régions | RTO et RPO proches de zéro dans l’exemple AWS de 2026 | Complexité et coût élevés |
Pour une PME dont l’activité peut attendre une demi-journée, une restauration automatisée et testée peut être plus rationnelle qu’un système actif-active. Honnêtement, l’active-active ne se justifie que si quelques minutes d’arrêt coûtent plus cher que sa conception, son exploitation permanente et ses tests.
Google Cloud documentait en 2024 une architecture illustrative de niveau 2 avec un RTO de 24 heures et un RPO de 4 heures pour une panne régionale. Cet exemple montre qu’une architecture cloud sérieuse peut assumer une reprise différée. La disponibilité la plus élevée n’est pas systématiquement le meilleur achat.
Côté agence, le réflexe est de relier chaque composant au parcours métier : authentification, paiement, génération de documents, envoi d’e-mails et outils internes. Une application redémarrée mais incapable d’accepter un paiement n’a pas réellement repris son activité.
Pourquoi la réplication ne remplace-t-elle pas les sauvegardes ?
La réplication interrégionale réduit la quantité de données perdues, mais elle peut aussi copier une suppression, une corruption ou des données chiffrées par un rançongiciel. Un plan de reprise d’activité cloud doit donc conserver des sauvegardes datées, chiffrées et isolées de l’environnement de production, conformément aux recommandations AWS et CISA de 2024 à 2026.
Une copie isolée utilise une frontière de sécurité différente : compte cloud séparé, coffre logiquement isolé ou support hors ligne. Si le même administrateur compromis peut supprimer la production et toutes ses sauvegardes, la redondance géographique apporte peu de protection contre une attaque.
Le piège moins visible concerne la durée de réplication. Microsoft indique en 2026 que les sauvegardes géoredondantes Azure peuvent exposer jusqu’à 36 heures de perte de données dans le cas régional général documenté : un RPO primaire de 24 heures auquel peuvent s’ajouter jusqu’à 12 heures de réplication. Le mot « géoredondant » ne suffit donc pas à établir votre RPO réel.
La reprise doit aussi intégrer les droits d’accès, journaux et procédures de réponse à incident. Ces mesures prolongent les fondamentaux de la cybersécurité, notamment la limitation des privilèges et la séparation des environnements.
Comment tester un PRA cloud sans perturber la production ?
Un test de PRA cloud doit restaurer réellement les données, déployer l’application dans une région indépendante et mesurer le délai obtenu. AWS recommande en 2026 des restaurations régulières, des exercices de bascule et des contrôles de capacité. Le statut « sauvegarde réussie » confirme une copie, pas la possibilité de redémarrer l’activité.
Un exercice encadré peut utiliser des données neutralisées et un domaine de test avant une bascule complète. L’objectif est d’observer les actions humaines, les autorisations manquantes et les dépendances oubliées. Sur les projets que nous menons, nous voyons souvent le DNS, les certificats ou les quotas cloud retarder davantage la reprise que le redéploiement des serveurs.
Le scénario PME suivant synthétise en 2026 les procédures recommandées par Amazon Web Services, Microsoft Azure et Google Cloud :
- déclarer la région principale indisponible et déclencher la procédure avec les personnes habilitées ;
- restaurer ou promouvoir la base de données dans une région indépendante ;
- déployer l’application depuis l’infrastructure as code, c’est-à -dire une description versionnée de l’infrastructure ;
- rétablir les secrets, certificats, comptes d’identité, routes réseau et chaînes de connexion ;
- rediriger le DNS, le service qui associe un nom de domaine à l’application, puis contrôler sa propagation ;
- vérifier les paiements, e-mails, API tierces et outils de surveillance, puis traiter des commandes de test ;
- mesurer la perte de données et le temps total avant de tester le retour contrôlé vers la région principale.
Le basculement DNS mérite un chronomètre propre. La détection de panne, les contrôles de santé des serveurs et la propagation des changements peuvent allonger le RTO réellement constaté. Un répartiteur de charge mondial accélère certains scénarios, mais il doit lui aussi être configuré, surveillé et testé.
L’infrastructure as code réduit les manipulations manuelles et les écarts de configuration. Les modèles Terraform, AWS CloudFormation ou Azure Bicep, ainsi que les versions de l’application, doivent être conservés hors de la seule région sinistrée. La même discipline s’applique aux mises à jour, comme l’explique ce guide sur le patch management sans interruption de production.
Quels éléments un plan de reprise d’activité cloud doit-il documenter ?
Un plan de reprise d’activité cloud complet documente les responsables, critères de déclenchement, dépendances, accès d’urgence, étapes de bascule et conditions de retour à la normale. Microsoft Azure rappelle en 2026 que le calcul, la base de données et le stockage ne suffisent pas : identité, DNS, certificats, secrets, réseau, quotas et API tierces doivent être couverts.
Le document doit préciser qui peut déclarer le sinistre, qui communique avec les clients et qui autorise le retour en production. Il doit rester accessible quand le système d’information principal ne l’est plus. Une procédure stockée uniquement dans l’intranet indisponible devient inutilisable au moment critique.
Ajoutez les coordonnées des prestataires, les comptes cloud d’urgence, les limites contractuelles et les conditions de support. Pour chaque dépendance externe, vérifiez si le fournisseur accepte les connexions depuis la région de secours : listes d’adresses IP autorisées, certificats, restrictions géographiques et plafonds d’API peuvent bloquer la reprise.
La conformité ne se délègue pas entièrement à l’hébergeur. Les entreprises concernées par des obligations renforcées peuvent également examiner l’effet de NIS2 sur les sous-traitants et les TPE. Le PRA doit rester cohérent avec les contrats, la protection des données et les engagements pris auprès des clients.
Cadrer le plan de reprise d’activité cloud avant de choisir l’architecture évite de payer une redondance mal adaptée ou de découvrir trop tard une dépendance bloquante. Un regard extérieur peut surtout aider à confronter les objectifs métier aux délais réellement mesurables.
FAQ sur la reprise après sinistre dans le cloud
Une sauvegarde cloud suffit-elle pour reprendre l’activité ?
Une sauvegarde cloud ne suffit que si sa restauration, les accès, l’infrastructure et les dépendances ont été testés. Une copie terminée peut être corrompue, inaccessible ou trop lente à restaurer pour respecter le RTO.
Quelle différence entre haute disponibilité et reprise après sinistre ?
La haute disponibilité absorbe des pannes courantes avec peu ou pas d’interruption. La reprise après sinistre traite un événement majeur, comme la perte d’une région cloud, et accepte souvent une procédure de restauration plus longue.
À quelle fréquence faut-il tester une restauration cloud ?
La fréquence d’un test de restauration cloud dépend du rythme des changements et de l’impact métier. Chaque modification majeure d’architecture, d’identité, de réseau ou de base de données doit conduire à vérifier la procédure, en complément des exercices planifiés.
Peut-on construire un PRA chez le même fournisseur cloud ?
Un PRA peut utiliser deux régions indépendantes du même fournisseur cloud si les risques résiduels sont acceptés et testés. Un second fournisseur réduit certaines dépendances communes, mais augmente la complexité des compétences, des données, du réseau et de l’exploitation.