Voir le mot succès dans le log d’une sauvegarde est rassurant. Ça confirme qu’un processus a copié des données quelque part. Ça ne prouve pas qu’on est capable de remettre tout le service en marche dans le délai dont l’entreprise a besoin.

Le nuage fournit plusieurs mécanismes utiles : réplication entre zones, instantanés, stockage d’objets versionné, sauvegardes gérées et infrastructure décrite par code. Ces mécanismes ne répondent pourtant pas tous au même problème. Une réplique conserve la disponibilité quand un nœud tombe, mais elle peut répliquer immédiatement une suppression accidentelle. Un instantané permet de revenir à un état antérieur, mais il ne garantit pas que plusieurs bases liées ont été figées au même moment. Une copie hors du compte principal protège mieux contre une erreur d’administration, mais elle prend plus de temps à restaurer.

Avant de choisir un produit, il faut donc fixer deux objectifs. Le RPO, ou objectif de point de reprise, représente la quantité de données qu’on accepte de perdre. Le RTO, ou objectif de temps de reprise, représente la durée maximale de l’interruption. Si une commande est enregistrée toutes les minutes et qu’on accepte au plus cinq minutes de perte, une sauvegarde nocturne ne suffit pas, même si elle est parfaitement valide. Si le service doit revenir en trente minutes, télécharger trois téraoctets depuis une archive froide ne convient pas davantage.

Ces chiffres ont un coût. Répliquer chaque transaction vers une deuxième région demande plus d’infrastructure et une gestion rigoureuse de la cohérence. Accepter un RPO de quatre heures permet une solution plus simple. La bonne architecture n’est pas celle qui promet le plus petit chiffre partout; c’est celle dont les objectifs correspondent réellement aux conséquences d’affaires.

Tester la reprise pour vrai

Prenons une application assez ordinaire : un site web, une API, une base SQL, un stockage de fichiers et un fournisseur d’identité. Sauvegarder seulement la base laisse de côté les documents auxquels ses lignes font référence. Recréer les serveurs sans les secrets empêche l’API de démarrer. Restaurer les données avant les schémas ou dans la mauvaise version produit des erreurs plus discrètes encore.

Un exercice de reprise réaliste suit une séquence observable :

1. créer un environnement vide dans un autre compte ou une autre région à partir du code d’infrastructure;
2. restaurer les secrets, certificats et paramètres depuis leur coffre, sans les copier d’un portable;
3. restaurer la base et le stockage au même point logique, puis vérifier les sommes de contrôle et les migrations;
4. démarrer l’API et le site dans l’ordre de leurs dépendances, sans encore changer le DNS public;
5. exécuter un vrai parcours — connexion, lecture d’une commande, ajout d’un document et écriture d’une nouvelle transaction — avant la bascule.

Le chronomètre doit commencer au moment où l’incident est déclaré, pas une fois les fichiers téléchargés. Il faut aussi noter le dernier enregistrement récupéré pour mesurer le RPO réellement obtenu. Si la procédure exige le mot de passe d’une personne en vacances ou un appel improvisé au fournisseur, ce sont des dépendances du système et non des détails administratifs.

Les pannes les plus instructives sont rarement spectaculaires. Un certificat expiré bloque les communications internes. Une clé de chiffrement sauvegardée dans le même compte que les données disparaît avec lui. Une file de messages redémarre et rejoue des opérations, créant des doublons parce que les consommateurs ne sont pas idempotents. Un service externe répond encore, mais refuse les nouvelles adresses IP. La reprise doit tester ces chemins, puis préciser le retour à l’état normal pour éviter deux systèmes actifs qui acceptent des écritures concurrentes.

Je ne cherche pas une promesse de zéro panne. Je veux un objectif explicite, une procédure courte, un propriétaire et une preuve datée que le parcours essentiel a été restauré. Dans le nuage comme ailleurs, une sauvegarde devient une capacité de reprise seulement le jour où on l’a utilisée avec succès.