Reprise après sinistre : définir des RTO et RPO adaptés

La plupart des plans de reprise après sinistre échouent le jour même où ils sont rédigés, pas le jour de la panne. Quelqu'un choisit des chiffres ronds qui semblent rassurants, personne n'en évalue le coût, et l'écart n'apparaît que lorsqu'une base de données est déjà en feu. La solution consiste à traiter le RTO et le RPO comme des décisions d'entreprise assorties d'un coût, et non comme des trophées techniques.

Ce que signifient réellement RTO et RPO

Deux acronymes portent l'essentiel du poids de toute conversation sur la reprise après sinistre, il vaut donc la peine d'être précis à leur sujet.

Le RTO (Recovery Time Objective) correspond à la durée pendant laquelle un système peut rester hors service avant que cette indisponibilité ne cause un préjudice inacceptable. Si votre service de paiement a un RTO d'une heure, vous vous engagez à ce qu'il serve de nouveau les clients dans les soixante minutes suivant le début d'un incident.

Le RPO (Recovery Point Objective) correspond à la quantité de données que vous pouvez vous permettre de perdre, mesurée en temps. Un RPO de cinq minutes signifie qu'après la reprise, vous acceptez de perdre au maximum les cinq dernières minutes d'écritures. Le RPO est en réalité une affirmation sur la fréquence à laquelle vous capturez un état récupérable.

Le piège consiste à traiter les deux comme « le plus bas possible ». Un niveau proche de zéro pour les deux est techniquement réalisable, mais la courbe de coût est impitoyable. Diviser par deux votre RTO ou votre RPO ne double que rarement le coût. Il le multiplie souvent par cinq ou dix dès que vous ajoutez la réplication synchrone, l'infrastructure de secours et le temps d'ingénierie nécessaire pour maintenir le tout en état.

Le RTO et le RPO ne sont pas la même chose qu'un SLA

Un SLA décrit le fonctionnement normal, par exemple une disponibilité mensuelle de 99,9 pour cent. Le RTO et le RPO décrivent les situations anormales : une défaillance de région, un événement de rançongiciel, une mauvaise migration qui corrompt une table. Un service peut respecter son SLA chaque mois pendant des années et être malgré tout anéanti par un seul sinistre qu'il n'a jamais été conçu pour surmonter. Conservez ces chiffres dans des documents distincts afin que personne ne confonde « généralement fiable » et « récupérable ».

Partez de l'impact métier, pas de l'infrastructure

L'erreur numéro un que nous constatons, ce sont des ingénieurs qui fixent le RTO et le RPO du côté technique. L'ordre correct est inversé. Vous partez d'une analyse d'impact sur l'activité et vous la laissez dicter les niveaux.

Passez en revue chaque système critique et posez trois questions simples à son responsable :

1. Si ce système est hors service pendant une heure, qu'est-ce qui se casse dans l'entreprise ? Et au bout de quatre heures, ou d'une journée entière ?
2. Si nous perdons ici les quinze dernières minutes de données, est-ce une gêne ou un problème juridique et financier ?
3. Que font les gens manuellement pendant que le système est hors service, et combien de temps peuvent-ils tenir ainsi ?

Les réponses se regroupent naturellement. Un grand livre de facturation et un blog marketing ne méritent pas la même protection, et payer pour les protéger de façon identique est la meilleure façon de gaspiller un budget de reprise après sinistre. D'après notre expérience, la plupart des organisations aboutissent à trois ou quatre niveaux plutôt qu'à un objectif unique à l'échelle de l'entreprise.

Un modèle de niveaux concret

Voici une structure de niveaux que nous utilisons comme point de départ dans nos missions clients. Ajustez les chiffres selon votre propre appétence au risque.

• Niveau 0, mission critique : RTO de quelques minutes, RPO proche de zéro. Paiements, authentification, la base de données transactionnelle centrale. Ces éléments justifient un secours à chaud et une réplication synchrone ou quasi synchrone.
• Niveau 1, critique pour l'activité : RTO d'une à quatre heures, RPO de quinze minutes. Les services applicatifs principaux et leurs magasins de support. Un secours à tiède avec réplication asynchrone fréquente convient généralement.
• Niveau 2, important : RTO d'un jour ouvré, RPO de quelques heures. Outils internes, reporting, systèmes de back-office. Une restauration à partir de sauvegarde suffit souvent.
• Niveau 3, différable : RTO de plusieurs jours, RPO de vingt-quatre heures. Archives, journaux, tout ce que vous pouvez reconstruire. Un stockage à froid bon marché est la bonne réponse.

Attribuer chaque système à un niveau est l'heure la plus précieuse que vous passerez, car elle convertit une anxiété diffuse en un petit ensemble d'objectifs concrets et chiffrables.

Adaptez la stratégie de reprise aux chiffres

Une fois que chaque système a un niveau, la stratégie se choisit presque d'elle-même. Le schéma classique ici, popularisé par les architectures de référence du cloud, s'articule autour de quatre grandes approches, ordonnées de la moins chère à la plus coûteuse.

• Sauvegarde et restauration : Sauvegardes périodiques vers un stockage durable, reconstruction à la demande. Coût le plus faible, RTO mesuré en heures voire en jours, RPO lié à la fréquence des sauvegardes. Adapté aux niveaux 2 et 3.
• Pilot light : Données centrales répliquées en continu, infrastructure minimale maintenue en fonctionnement, le reste étant provisionné lorsque le sinistre survient. Bon compromis pour de nombreux systèmes de niveau 1.
• Secours à tiède (warm standby) : Une copie de l'environnement réduite mais toujours active, que vous montez en puissance lors du basculement. RTO de quelques minutes à un petit nombre d'heures.
• Secours à chaud ou multi-site actif-actif : Une capacité entièrement dupliquée fonctionnant en direct, le trafic basculant avec peu ou pas d'interruption. La seule façon d'atteindre les objectifs de niveau 0, et facturée en conséquence.

Le compromis oppose l'argent et la complexité à la vitesse de reprise. L'actif-actif vous offre le meilleur RTO et le meilleur RPO, mais il vous oblige à résoudre la cohérence des données entre les sites, double une grande partie de votre coût de fonctionnement et ajoute ses propres modes de défaillance. N'achetez pas une protection de niveau 0 pour un système de niveau 2 parce que la diapositive d'un fournisseur l'a fait paraître facile.

Si vous mettez cela en balance avec vos dépenses cloud plus larges, notre guide d'optimisation des coûts cloud explique comment éviter que la capacité de secours ne devienne discrètement votre poste de dépense le plus important.

Concevez pour les défaillances qui se produisent réellement

Les pannes cloud à l'échelle d'une région font les gros titres, mais ce ne sont pas les sinistres les plus fréquents auxquels nous répondons. Les menaces du quotidien sont plus banales et plus dangereuses parce que les équipes s'y préparent insuffisamment.

• Suppression accidentelle et mauvais déploiements : Une migration supprime une colonne, un script tronque une table. La réplication ne vous sauve pas ici, car elle copie fidèlement l'erreur vers votre secours en quelques secondes.
• Rançongiciels et personnes malveillantes internes : Vos sauvegardes sont elles aussi une cible. Si elles peuvent être atteintes et chiffrées à partir des mêmes identifiants que la production, ce ne sont pas vraiment des sauvegardes.
• Corruption de données qui se propage silencieusement : La pire des situations, car elle peut se propager à chaque réplique et même aux sauvegardes récentes avant que quiconque ne s'en aperçoive.

C'est pourquoi le RPO ne peut pas être satisfait par la seule réplication en direct. Vous avez besoin de sauvegardes immuables, versionnées et idéalement hors ligne ou logiquement isolées (air-gapped), avec une rétention suffisante pour revenir en arrière au-delà d'une corruption que vous n'avez pas détectée immédiatement. La résilience face aux rançongiciels recoupe fortement votre posture de sécurité plus large, il vaut donc la peine de le lire en parallèle de notre guide sur l'architecture zero trust. Le même principe de limitation du rayon d'impact s'applique directement à la protection de vos données de reprise.

Le plan ne vaut rien tant que vous ne l'avez pas testé

Un plan de reprise après sinistre qui n'a jamais été exécuté est une hypothèse, pas une capacité. L'écart entre le RTO que vous avez noté et celui que vous pouvez réellement atteindre est généralement important, et vous ne le découvrez qu'en menant l'exercice.

Intégrez les tests à un calendrier et augmentez le réalisme au fil du temps :

1. Revue sur table (trimestrielle) : L'équipe parcourt un scénario étape par étape. Peu coûteux, et cela révèle rapidement les runbooks manquants et les responsabilités floues.
2. Restauration de composant (mensuelle) : Restaurez une seule base de données ou un seul service à partir d'une sauvegarde dans un environnement isolé et vérifiez que les données sont intactes et utilisables, pas seulement que le fichier s'est téléchargé.
3. Exercice de basculement complet (deux fois par an) : Basculez tout un niveau vers sa cible de reprise et mesurez le RTO réel au chronomètre. Comparez-le à votre objectif.
4. Game day avec éléments surprises : Une fois les bases solides, introduisez un imprévu, par exemple un identifiant manquant ou un runbook obsolète, pour tester la capacité de l'équipe à improviser.

Deux choses rendent ces exercices rentables. Premièrement, chronométrez-les toujours et enregistrez les chiffres réels, car « ça a semblé rapide » n'est pas une métrique. Deuxièmement, vérifiez les données récupérées avec de vrais contrôles : décomptes de lignes, sommes de contrôle, un test de fumée de l'application. Une restauration qui se termine mais renvoie une base de données corrompue a respecté votre RTO et a complètement trahi votre entreprise.

Modes de défaillance courants à éviter

Au fil des audits, les mêmes erreurs reviennent, et il vaut la peine de les nommer afin que vous puissiez comparer votre propre plan à celles-ci.

• Sauvegardes non testées. La tâche de sauvegarde s'affiche en vert pendant des années et personne ne restaure jamais à partir d'elle. La première vraie restauration révèle qu'il lui manquait depuis toujours un schéma critique.
• Ignorer les dépendances. Vous basculez l'application mais oubliez qu'elle a besoin de DNS, d'un coffre de secrets, d'une file de messages et d'une API tierce qui connaît sa propre panne. L'ordre de reprise compte, alors documentez-le.
• Un point de défaillance unique dans le chemin de reprise. Le runbook n'existe que sur l'ordinateur portable du seul ingénieur injoignable pendant l'incident. Stockez-le là où il survit au sinistre.
• Un RPO qui ignore les données en transit. Vous répliquez la base de données mais pas la file d'événements non traités, si bien que la reprise perd les transactions qui étaient en cours.

Maintenez le plan à jour

Les systèmes changent chaque semaine, et un plan de reprise après sinistre rédigé pour l'architecture de l'an dernier ne récupérera pas celle de cette année. Rattachez une revue légère à votre processus de changement afin que tout nouveau service de niveau 0 ou de niveau 1 se voie attribuer un RTO et un RPO avant sa mise en production. Réexaminez le plan complet au moins deux fois par an, et toujours après un incident réel, car la revue post-incident est votre source la plus honnête de ce que le plan a mal anticipé.

Comment Innovation T peut vous aider

Chez Innovation T, nos services cloud et DevOps commencent la reprise après sinistre là où c'est sa place : par une analyse d'impact sur l'activité qui transforme des craintes floues en un ensemble clair de niveaux, chacun assorti d'un RTO et d'un RPO que vous pouvez défendre devant la direction financière. À partir de là, nous concevons l'architecture de reprise correspondante, qu'il s'agisse de sauvegarde et restauration pour les systèmes de back-office ou d'un secours à tiède pour votre chaîne de revenus, et nous construisons l'automatisation qui rend le basculement rapide et reproductible plutôt qu'héroïque. Nous menons également les exercices avec vous, mesurons les chiffres de reprise réels et comblons l'écart entre le plan sur le papier et le plan qui fonctionne à trois heures du matin.

Si votre plan actuel n'a jamais survécu à un vrai test, ou si vous n'êtes pas certain de ce que serait votre véritable RTO aujourd'hui, contactez-nous. Nous vous aiderons à définir des objectifs adaptés à votre entreprise et à bâtir la résilience nécessaire pour réellement les atteindre.