La sauvegarde est au vert. Mais si l’application devenait indisponible, le client retrouverait-il le service déjà payé ?
Une page d’accueil restaurée ne démontre ni la connexion du client ni la récupération de son billet. La base peut référencer un fichier absent. Une tâche récupérée peut aussi envoyer une confirmation ou tenter un paiement depuis le système de test.
Cela arrive aussi à des équipes bien organisées. Le 31 janvier 2017, les sauvegardes quotidiennes de la base de GitLab.com échouaient sans que personne ne s’en aperçoive : la tâche lançait pg_dump 9.2 sur une base PostgreSQL 9.6, et les e-mails d’échec étaient rejetés par le serveur de messagerie destinataire. Quand des données de production ont été supprimées ce jour-là, le bucket de sauvegarde était vide. Le postmortem de GitLab décrit une restauration à partir d’un snapshot manuel pris environ six heures plus tôt, et la perte des modifications faites depuis : environ 5 000 projets, 5 000 commentaires et 700 nouveaux comptes utilisateurs, selon sa propre estimation.
La réponse courte : un test de restauration part d’une action client. Récupérez ses dépendances en environnement isolé et vérifiez les droits attendus. Bloquez les vrais messages, paiements et modifications de services tiers avant le démarrage. Distinguez durées observées, point de reprise et dépendances non testées de vos objectifs.
1. Choisir l’action qui donne un sens à la reprise
Prenons un site fictif de formations professionnelles. Le client paie, reçoit une confirmation puis télécharge son billet depuis son compte. L’exigence de reprise est précise : retrouver la réservation et son billet sans repayer.
La fin de l’import de la base est une étape intermédiaire.
Lors d’un appel avec un CTO, nous l’avons formulé ainsi : « Un rapport de sauvegarde vous dit qu’une copie a été faite. Un test de restauration vous dit combien de temps l’activité est à l’arrêt et ce qu’elle perd. Seul le second a sa place dans un engagement envers un client. »
La CNIL recommande un plan de continuité et de reprise, même sommaire, incluant la liste des intervenants, et des tests réguliers de la restauration des sauvegardes et de l’application de ce plan. Le responsable du site et l’opérateur technique doivent convenir du parcours attendu, ainsi que d’un éventuel fonctionnement réduit acceptable, avant l’exercice.
Les outils cloud ne choisissent pas vos critères métier. AWS Backup décrit une validation distincte après restauration : la ressource demande encore les vérifications propres au service.
L’exercice proposé ne rapporte ni restauration réalisée ni cas client.
2. Suivre la réservation au-delà de sa ligne en base
Sur ce site, le parcours dépend de plusieurs éléments :
| Dépendance | Ce que l’exercice doit établir |
|---|---|
| Accès de l’opérateur et du client | L’opérateur récupère les éléments nécessaires ; l’identité de test prévue utilise le compte restauré. |
| Application et configuration | Une version compatible, ses réglages, droits et moyens de déchiffrement sont récupérables par la procédure convenue. |
| Réservation et droit acquis | Le compte retrouve la réservation payée et le droit de télécharger correspondant. |
| Billet | Le contenu du fichier est disponible, au-delà de sa référence en base. |
| Services tiers et tâches en attente | L’état du paiement, les messages et les tâches différées ont un traitement et des limites explicites. |
La documentation peut révéler des omissions. Supabase précise, par exemple, que ses sauvegardes de base n’incluent pas les objets Storage et que les sauvegardes quotidiennes ne conservent pas les mots de passe des rôles personnalisés. La base restaurée ne démontre donc pas, à elle seule, la récupération d’un billet téléchargeable ni de tous les accès nécessaires.
Cybermalveillance rappelle l’importance des logiciels indispensables à l’exploitation des données. Les Essentiels de l’ANSSI sur la sauvegarde recommandent d’inclure les médias d’installation et les configurations des applications métier dans les sauvegardes. Pour chaque dépendance, demandez d’où elle provient et qui peut la récupérer si l’environnement d’origine n’est plus accessible.
Recopier un réglage non documenté depuis la production laisse la dépendance à cet accès non résolue.
3. Confiner la copie avant de démarrer l’application
Un nom de domaine séparé ne suffit pas si la copie conserve des secrets de production ou peut joindre les services réels. L’opérateur doit établir le confinement avant d’activer l’application, les tâches planifiées ou les traitements en arrière-plan.
Prévoyez une destination distincte, à accès restreint, dont les connexions sortantes se limitent aux dépendances de test autorisées. Ne modifiez pas le routage de production. Remplacez ou désactivez les identifiants des intégrations réelles, examinez les tâches au démarrage et vérifiez que la copie ne peut pas écrire dans les bases ou stockages de production.
Dirigez les e-mails applicatifs vers un outil de capture de test. Utilisez des destinataires fictifs et examinez aussi les autres canaux, dont les notifications émises directement par les prestataires. Les envois planifiés et appels sortants restent désactivés tant que leur traitement n’est pas établi. Un réglage dans l’interface ne remplace pas la vérification de la configuration déployée et du destinataire effectif.
Pour simuler un achat, utilisez un environnement de paiement séparé et ses clés de test. Stripe décrit des transactions simulées sans mouvement de fonds. Cela n’isole pas les e-mails de votre application ni toutes les notifications du prestataire : contrôlez-les séparément. Ne chargez jamais les clés de paiement réelles dans cet exercice.
Privilégiez une réservation fictive déjà présente dans la sauvegarde sélectionnée. La créer après restauration testerait une nouvelle opération sans démontrer la récupération d’un état antérieur. Si des données réelles sont nécessaires, faites définir les accès, la protection, l’usage et la suppression par le responsable habilité ; la CNIL précise les précautions relatives aux données de test.
Si ce confinement ne peut pas être établi, arrêtez-vous avant toute exécution de l’application et consignez le blocage. L’étiquette « préproduction » ne détermine ni les droits ni les connexions effectives.
4. Rejouer le parcours déjà payé
Convenez du scénario : l’environnement applicatif d’origine est indisponible ; la reprise utilise le jeu de sauvegardes nommé et les dépendances documentées. Précisez quelles pannes sont simulées et quels services restent accessibles.
L’opérateur récupère sauvegardes et accès, restaure en environnement confiné, applique la configuration compatible et récupère les billets. Conservez identifiants des sauvegardes, versions, horodatages et interventions manuelles.
Avant d’activer le parcours, examinez les tâches en attente. Une ancienne confirmation ne doit pas repartir vers une adresse réelle. Une tentative de paiement au résultat incertain ne doit pas être relancée au seul motif que son enregistrement précède la sauvegarde.
Avec l’identité de test autorisée, ouvrez ensuite la réservation existante et téléchargez le billet. Vérifiez son rattachement au compte, le droit acquis et le contenu du fichier. Tentez le même accès avec une autre identité de test, non autorisée. Le téléchargement réussi et le refus correct répondent à deux parties différentes de l’exigence.
Supposons que la réservation apparaisse mais que le billet manque. Consignez cet échec avant de récupérer le fichier par la voie secondaire documentée puis de refaire l’essai. Gardez les deux observations. Si le billet a été recréé manuellement, précisez-le : cela peut être un moyen de reprise accepté, mais ne démontre pas que la sauvegarde initiale des fichiers était complète.
Appliquez la même règle à un rôle ou à un réglage absent. Le dossier doit montrer l’échec initial, la correction et le résultat suivant.
Le minimum que nous accepterions, c’est qu’un parcours client payé fonctionne sur la copie restaurée : se connecter, voir la bonne réservation, télécharger le fichier. Une page d’accueil qui se charge montre que le serveur web a démarré, pas que l’activité est revenue.
5. Séparer la réservation récupérée du nouvel achat simulé
La réservation antérieure vérifie l’état récupéré ; le nouvel achat simulé, le traitement d’une nouvelle opération. Les essais se complètent.
Utilisez une nouvelle identité fictive et l’environnement de paiement de test. Vérifiez le retour du prestataire, la création de la réservation et la confirmation capturée. Séparez les identifiants de paiement de test des références réelles restaurées : l’environnement de test ne confirme pas l’état d’un ancien débit.
Définissez les critères avant de lire les résultats :
| Vérification | Éléments à conserver | Ce qu’elle ne couvre pas |
|---|---|---|
| Réservation et billet antérieurs | Références liées et éléments de parcours expurgés, protégés | Réservations hors du point récupéré ou de l’échantillon |
| Demande de billet non autorisée | Identité de test, action tentée et refus | Autres rôles et chemins non examinés |
| Nouvel achat simulé | Évènement de test, changement d’état applicatif et confirmation capturée | Règlement réel et configuration du compte de production |
| Confinement des actions sortantes | Réglages effectifs, restrictions de connexion et destinations observées | Intégrations et tâches non testées |
Un client peut avoir payé après le point de reprise. Désignez qui rapprocherait les états du prestataire de paiement et de l’application, et comment les droits seraient traités avant réouverture. Relancer les débits ou créer des réservations pour masquer l’écart ne le résout pas.
6. Distinguer les observations des promesses de reprise
Le guide du NIST définit le RTO comme la durée maximale pendant laquelle un système peut rester indisponible avant un impact inacceptable, et le RPO comme le point dans le temps auquel les données doivent être récupérées après une panne. Il traite aussi des tests de reprise et de la validation des données et fonctionnalités restaurées. Ces recommandations américaines ne constituent pas une obligation française.
Fixez le début de la mesure : consignez l’accès opérateur, la restauration, le chargement, le démarrage et l’acceptation. Incluez attentes et corrections. Indiquez les points de reprise sélectionnés et obtenus pour la base et les fichiers, avec leurs incohérences.
Un exercice préparé ne garantit pas le délai d’un incident futur. Précisez les conditions non testées : indisponibilité du fournisseur d’identité, perte d’accès aux sauvegardes, changement du DNS de production, rapprochement réel des paiements, charge ou perte d’une autre région, par exemple.
Là où nous posons la limite : nous ne promettons aucun délai de reprise avant qu’un exercice en ait mesuré un. Ensuite, nous indiquons le temps qu’il a pris dans ces conditions, pas une garantie pour chaque incident.
L’exercice ne démontre pas non plus l’élimination d’une compromission. L’ANSSI rappelle qu’après un incident, les sauvegardes peuvent contenir les vecteurs de compromission, et recommande de restaurer à partir de sources de confiance. Une copie fonctionnelle ne prouve pas qu’un attaquant a été évincé ; cela relève d’une réponse de sécurité distincte et adaptée.
7. Accepter le résultat dans ses limites et attribuer les écarts
Demandez un dossier court : action client, composants, observations, étapes, échecs, corrections et inconnues. Attribuez chaque blocage et sa contre-vérification. Fermez l’environnement temporaire et traitez ses données et identifiants selon la conservation convenue.
Vous pouvez accepter ce parcours dans les conditions examinées, financer une dépendance manquante ou différer l’acceptation tant qu’un blocage subsiste. Le statut au vert devient utile lorsque son périmètre est visible.
Si la décision porte plus largement sur une stabilisation ou une reconstruction, consultez le guide IZZY sur les sites lents ou instables. Le support longue durée fournit le cadre d’exploitation ; l’exercice de reprise demande un périmètre convenu.
Préparons l’exercice ensemble
Pour le cadrer avec IZZY, apportez parcours payant, sauvegardes et intégrations au service Cloud, DevOps & Plateforme. Convenez de l’exercice, des preuves et des corrections avant d’en faire un engagement de reprise.
Sources et limites
Sources consultées le 10 novembre 2026. Le site de formation et l’exercice sont fictifs. Hormis le postmortem publié par GitLab, aucun résultat de restauration, durée mesurée, test de paiement ou résultat client d’IZZY n’est rapporté. Les limites des plateformes citées leur sont propres. Un opérateur technique doit adapter l’exercice au système réel ; cet article ne constitue pas une procédure de réponse à un incident en cours.