3 min de lecture
L’essentiel
- Le RTO (objectif de temps de reprise) et le RPO (objectif de point de reprise) déterminent la conception de la reprise après sinistre (DR).
- L’architecture multi-région active-active permet d’atteindre un RTO inférieur à une minute, mais coûte deux à trois fois plus cher.
- Les approches « Pilot Light » et « Warm Standby » offrent une reprise après sinistre économique, avec un RTO compris entre 10 et 60 minutes.
- L’Infrastructure as Code rend les environnements de reprise après sinistre reproductibles et testables.
- Les tests réguliers de la reprise après sinistre sont obligatoires : 40 % des entreprises qui ne les effectuent pas échouent lors d’un incident réel.
La question n’est pas de savoir si une région cloud tombera en panne, mais quand. Les régions AWS us-east-1, Azure South Central et GCP europe-west1 ont toutes connu des pannes majeures ces dernières années. Pour les entreprises sans plan de reprise après sinistre validé par des tests, la question devient existentielle : dans combien de temps pouvons-nous revenir en ligne – et combien de données avons-nous perdues ?
RTO et RPO : les deux indicateurs qui décident de tout
L’objectif de temps de reprise (RTO) répond à cette question : quelle est la durée maximale acceptable d’une interruption ? Un RTO de 4 heures signifie que le service doit être pleinement rétabli dans les 4 heures suivant la panne.
L’objectif de point de reprise (RPO) répond à cette autre question : quelle quantité de perte de données est acceptable ? Un RPO d’une heure signifie qu’au maximum une heure de données peut être perdue.
Ces deux indicateurs déterminent à la fois la conception de la reprise après sinistre et son coût. Un RTO et un RPO nuls exigent une architecture multi-région active-active – l’option la plus onéreuse. En revanche, un RTO et un RPO de 24 heures peuvent suffire avec des sauvegardes quotidiennes – l’option la plus économique. L’art consiste à trouver l’équilibre juste entre les exigences métier et le budget alloué.
Les quatre stratégies de reprise après sinistre dans le cloud
Sauvegarde et restauration : Des sauvegardes régulières sont stockées dans une autre région. En cas de sinistre, l’infrastructure est recréée et les données restaurées. RTO : 4 à 24 heures. RPO : dépend de la fréquence des sauvegardes. Coût : minimal (uniquement le stockage des sauvegardes). Adapté aux charges de travail non critiques.
Pilot Light : Une infrastructure minimale (réplique de base de données, DNS) fonctionne en permanence dans la région de secours. En cas de sinistre, les ressources de calcul sont démarrées et le trafic redirigé. RTO : 30 à 60 minutes. RPO : quelques minutes (grâce à la réplication). Coût : 10 à 20 % des coûts de production.
Warm Standby : Une version mise à l’échelle de la production fonctionne dans la région de secours, avec une capacité réduite. En cas de sinistre, la capacité est augmentée et le trafic redirigé. RTO : 10 à 30 minutes. RPO : quelques secondes. Coût : 30 à 50 % des coûts de production.
Multi-région active-active : Capacité totale dans les deux régions, avec répartition du trafic. La panne d’une région est automatiquement compensée. RTO : moins d’une minute. RPO : zéro. Coût : 200 à 300 % (en plus de la complexité accrue). Adapté aux services métiers critiques et proches des clients.
L’Infrastructure as Code comme levier de la reprise après sinistre
Les plans de reprise après sinistre basés sur des procédures manuelles échouent souvent en situation réelle, sous la pression du stress, du manque de temps ou de l’absence d’identifiants. L’Infrastructure as Code (Terraform, CloudFormation, Pulumi) rend les environnements de reprise après sinistre déclaratifs et reproductibles.
Le principe est simple : l’infrastructure de production est entièrement décrite dans du code. En cas de sinistre, ce même code est exécuté dans la région cible – avec des variables spécifiques à la région. Ce qui prendrait des heures manuellement s’accomplit en quelques minutes avec l’IaC. Et surtout, cela se teste : des exercices de reprise après sinistre sont réalisés régulièrement pour vérifier que le code fonctionne effectivement.
Réplication des données : synchrone vs asynchrone
La réplication synchrone écrit les données simultanément dans les deux régions. RPO : zéro (aucune perte de données). Inconvénient : la latence augmente, car chaque écriture doit attendre la confirmation provenant de la région de secours. Cette méthode n’est pertinente que lorsque la latence entre les régions est inférieure à 50 ms.
La réplication asynchrone écrit d’abord localement, puis réplique avec un léger décalage. RPO : quelques secondes à plusieurs minutes (selon le délai de réplication). Avantage : aucune incidence sur la latence de la production. C’est la solution standard pour la reprise après sinistre inter-régions.
Des services gérés tels qu’Aurora Global Database, Cosmos DB ou Cloud Spanner proposent une réplication multi-régions avec un niveau de cohérence configurable – supprimant ainsi la charge opérationnelle liée à la mise en place de systèmes de réplication personnalisés.
Tester la reprise après sinistre : un facteur de réussite trop souvent sous-estimé
Un plan de reprise après sinistre non testé n’est pas un plan – c’est une simple espérance. Des études montrent que 40 % des entreprises n’ayant jamais testé leur plan échouent face à un incident réel, confrontées à des problèmes imprévus : identifiants expirés, points de terminaison API modifiés, formats de données incompatibles – autant de défauts que seuls les tests permettent de révéler.
Bonne pratique : réaliser des exercices de reprise après sinistre tous les trimestres, en transférant effectivement le trafic vers la région de secours. Netflix a montré la voie avec son « Chaos Engineering » (Chaos Monkey, simulation d’incidents régionaux), démontrant comment tester continuellement la résilience. AWS Fault Injection Service et Azure Chaos Studio proposent aujourd’hui des solutions gérées de Chaos Engineering accessibles à tous.
Questions fréquentes
Quel est le coût de la reprise après sinistre dans le cloud ?
Selon la stratégie choisie : la sauvegarde et la restauration ne coûtent que le stockage (quelques euros par mois et par téraoctet). Le « Pilot Light » représente 10 à 20 % des coûts de production. Le « Warm Standby », 30 à 50 %. L’architecture active-active, 200 à 300 %. Pour la plupart des PME, le « Pilot Light » constitue le bon compromis entre coût et disponibilité.
Avec quelle fréquence faut-il tester la reprise après sinistre ?
Au minimum tous les trimestres. Pour les systèmes critiques, tous les mois. Chaque test doit faire l’objet d’un compte rendu détaillé : qu’est-ce qui a fonctionné, qu’est-ce qui n’a pas fonctionné, quelles actions correctives sont nécessaires. Des tests automatisés (via Terraform et CI/CD) permettent d’augmenter leur fréquence sans effort manuel supplémentaire.
Une simple sauvegarde suffit-elle comme stratégie de reprise après sinistre ?
Oui, pour les systèmes non critiques. Mais pour tout système nécessitant un RTO inférieur à 4 heures, les sauvegardes ne conviennent pas – le processus de restauration prend trop de temps. La restauration de bases de données volumineuses (plusieurs téraoctets) peut prendre des heures. Dans ce cas, « Pilot Light » ou « Warm Standby » constituent de meilleures options.
Que se passe-t-il en cas de panne multi-régions ?
Les pannes multi-régions affectant un seul fournisseur sont extrêmement rares, mais possibles (panne DNS globale, bogue critique dans IAM). Pour une résilience maximale, certaines entreprises adoptent une stratégie de reprise après sinistre multi-cloud – production chez AWS, secours chez Azure, ou inversement. La complexité augmente fortement, mais elle est justifiée pour les infrastructures critiques.
Comment concevoir la reprise après sinistre pour des charges de travail Kubernetes ?
Velero est la solution de référence pour la reprise après sinistre Kubernetes : il sauvegarde l’état du cluster et les volumes persistants, et permet de les restaurer dans une autre région ou un autre cluster. Pour les charges de travail sans état, GitOps (ArgoCD) suffit : l’état du cluster est défini dans un dépôt Git et peut être déployé à tout moment dans un nouveau cluster.
Source de l’image : Pexels / Jakub Zerdzicki
