Un plan de sauvegarde utile explique ce qui peut être récupéré, jusqu'où l'on peut remonter et qui effectuera la restauration. Avant d'accepter la mention « sauvegardes incluses », demandez la liste des systèmes couverts, des points de restauration conservés et une démonstration sûre que le site convenu peut être restauré. Une simple notification de sauvegarde réussie ne répond pas à ces questions.
Cette checklist de sauvegarde et de restauration aide une entreprise à définir ses exigences de reprise avec son prestataire web ou son hébergeur. L'organisation adaptée dépend de ce que le site stocke et de la façon dont l'entreprise l'utilise. Un site de services de cinq pages, un site éditorial et une boutique en ligne peuvent avoir des besoins de reprise très différents.
1. Lister les dépendances du site
Commencez par les éléments nécessaires au fonctionnement du site plutôt que par le nom d'un produit de sauvegarde. Incluez les contenus des pages, les images, le code, la configuration et toute base de données. Listez ensuite les services connectés séparément : la destination d'un formulaire, un système de réservation, un prestataire de paiement ou un logiciel de gestion de la relation client peut conserver des informations en dehors du compte d'hébergement du site.
Une copie des pages visibles ne comprend pas nécessairement ces autres données. Par exemple, WordPress explique qu'une sauvegarde complète classique nécessite à la fois les fichiers du site et la base de données. Télécharger uniquement les fichiers ne sauvegarde pas la base de données. Les fichiers et la base doivent aussi correspondre à un état cohérent de l'historique du site, notamment lors des mises à jour.
Pour un site construit à partir d'un dépôt de code, demandez ce qui est nécessaire en plus pour le reconstruire et le publier. Le guide de sauvegarde de GitHub distingue les données incluses dans les différentes méthodes de sauvegarde. Une copie du dépôt est utile, mais il ne faut pas supposer qu'elle contient tous les fichiers importés, les données externes, les paramètres de compte ou les éléments nécessaires au déploiement.
Utilisez un petit tableau de couverture pour rendre ces limites visibles. C'est un outil de préparation, pas une affirmation que chaque site a besoin de toutes les lignes. Remplacez les exemples par les systèmes réellement utilisés dans votre entreprise et indiquez le responsable de chacun.
| Élément | Question à résoudre | Éléments de preuve à conserver |
|---|---|---|
| Pages, code et ressources graphiques | La version convenue peut-elle être reconstruite ou restaurée ? | Version, emplacement et instructions de restauration |
| Base de données et médias importés | Les deux sont-ils inclus dans un ensemble de restauration cohérent ? | Dates des sauvegardes, couverture et résultat de restauration |
| Configuration et accès | Qui peut restaurer les paramètres et obtenir un accès autorisé ? | Responsable et procédure d'accès sécurisé |
| Demandes, réservations ou commandes | Quel système conserve réellement ces données ? | Prestataire distinct et modalités de restauration |
| Domaine et services connectés | Quelles dépendances doivent fonctionner avant que le site puisse être utilisé ? | Responsables des comptes et checklist des dépendances |
2. Convenir de la perte de données et de l'indisponibilité acceptables
Deux questions simples rendent le plan plus utile : quelle quantité d'informations récentes l'entreprise pourrait-elle se permettre de perdre, et combien de temps le service concerné pourrait-il rester indisponible ? Répondez pour le processus métier, pas seulement pour la page d'accueil. Une page vitrine statique et un système qui accepte des commandes payantes peuvent justifier des réponses différentes.
Ces questions correspondent à l'objectif de point de reprise, ou RPO, et à l'objectif de temps de reprise, ou RTO. AWS définit ces objectifs de reprise en fonction de la période acceptable de perte de données et de la durée maximale acceptable d’interruption du service. Considérez-les comme des objectifs de préparation convenus. Ils ne prouvent pas qu'un prestataire donné pourra les respecter pour chaque incident.
Par exemple, un point de restauration quotidien peut laisser une période non couverte comprenant les modifications effectuées après la dernière sauvegarde réussie. Son existence ne dit rien, à elle seule, du temps nécessaire pour le trouver, obtenir l'accès, le restaurer et vérifier le résultat. Demandez au prestataire de relier le calendrier et le processus de reprise proposés aux objectifs que vous avez définis.
Évitez de choisir « aucune perte de données » ou « reprise instantanée » simplement parce que ces expressions sont rassurantes. Expliquez quelles informations ne peuvent pas être recréées et quelles activités peuvent temporairement emprunter une autre voie. Convenez ensuite d'une organisation réalisable, de son coût et de ses limites. Consignez les horaires de disponibilité de l'assistance à la reprise, ainsi que la prise en charge d'un incident en dehors de ces horaires.
3. Conserver assez longtemps des points de restauration utilisables
La fréquence des sauvegardes et leur durée de conservation répondent à des questions différentes. La fréquence indique à quel rythme un nouveau point de restauration est créé. La durée de conservation indique combien de temps les anciens points restent disponibles. Une sauvegarde fréquente qui remplace sans cesse l'unique copie peut être peu utile lorsqu'une modification indésirable est découverte plusieurs jours plus tard.
Demandez combien de versions sont conservées, comment leurs dates sont identifiées et ce qui se passe lorsque les limites de stockage sont atteintes ou que l'abonnement change. Tenez compte du temps dont votre équipe peut avoir besoin pour détecter un problème. Si personne ne vérifie le contenu pendant plusieurs semaines, une durée de conservation très courte peut expirer avant la découverte d'une suppression accidentelle.
Clarifiez la séparation entre les copies de restauration et l'environnement de production, ainsi que les personnes qui peuvent les modifier ou les supprimer. Une copie touchée par la même erreur de manipulation du compte ou le même incident de sécurité n'offre pas forcément l'indépendance attendue. Discutez des contrôles d'accès et de la protection avec le prestataire responsable, sans supposer qu'un deuxième dossier ou une synchronisation automatique suffit.
Gardez un plan pratique : identifiez l'emplacement de restauration et le responsable du compte sans inscrire de mots de passe, de clés secrètes ou de données clients dans un cahier des charges partagé. Notez où les instructions d'accès autorisé sont tenues à jour. Convenez aussi de qui reçoit les notifications d'échec et des actions à mener lorsqu'une sauvegarde programmée n'aboutit pas.
4. Distinguer retour arrière, restauration ciblée et complète
Des problèmes différents demandent des méthodes de reprise différentes. Un retour à un déploiement précédent remet le site publié dans une version antérieure. Une restauration ciblée récupère un fichier, une page ou un enregistrement précis. Une restauration complète reconstruit l'environnement couvert à partir d'un ensemble de restauration. Demandez quelles méthodes sont prises en charge par votre accord et ce que chacune modifie.
Par exemple, Cloudflare Pages documente le retour à un déploiement de production antérieur réussi. C'est utile pour un problème introduit par un déploiement. Cela ne prouve pas qu'une plateforme de réservation distincte ou une base de données clients externe reviendra également à ce moment précis. Confirmez le comportement de chaque dépendance au lieu de traiter le retour arrière comme un bouton d'annulation universel.
Avant de restaurer des données anciennes, identifiez les modifications effectuées depuis ce point de restauration. Une restauration complète de la base de données peut remplacer des informations récentes valides en même temps que la modification indésirable. Déterminez si ces enregistrements ultérieurs peuvent être conservés, rapprochés ou récupérés séparément. La personne qui autorise la restauration doit comprendre cet arbitrage avant le début d'une opération destructive.
Consignez le processus de décision dans un langage courant : qui évalue le problème, qui approuve le point de restauration choisi et qui réalise les travaux. Prévoyez, si nécessaire, un moyen de conserver l'état actuel pour l'analyse. Le plan de reprise doit expliquer comment l'équipe choisit une méthode, sans encourager le responsable de l'entreprise à expérimenter sur le site en production.
5. Démontrer une restauration dans un environnement sûr
Demandez un test de restauration coordonné avant de vous fier au plan. AWS recommande des tests de reprise périodiques pour vérifier que les données sauvegardées peuvent être restaurées et utilisées. La question pratique est de savoir si l'ensemble de restauration convenu permet d'obtenir un site utilisable, pas si un fichier d'archive existe.
Utilisez une destination de test isolée, convenue avec le responsable technique. Contrôlez l'accès aux informations clients restaurées et empêchez les copies de test d'envoyer de véritables notifications, d'accepter des paiements ou d'écraser les intégrations en production. L'équipe responsable doit décider quelles données conviennent au test et comment elles seront supprimées ensuite.
Examinez les pages restaurées, les images, la navigation et la configuration nécessaire. Vérifiez un parcours métier représentatif dans des conditions de test coordonnées. L'affichage correct d'une page ne prouve pas que son service connecté est bien configuré. Lorsqu'une dépendance ne peut pas être testée en toute sécurité, consignez cette limite au lieu de déclarer que tout le parcours a été démontré.
Conservez un bref compte rendu de test : point de restauration utilisé, systèmes couverts, destination, heures de début et de fin, vérifications effectuées et problèmes non résolus. Mesurez les étapes qui comptent pour l'objectif de reprise convenu, y compris l'accès et la vérification. Répétez les contrôles pertinents après des modifications importantes du site, de l'hébergement ou des modalités de reprise, selon une fréquence de révision adaptée à votre situation et convenue ensemble.
6. Examiner une décision de reprise réaliste
Prenons l'exemple fictif d'un cabinet de conseil doté d'un petit site de services. Ses pages sont publiées depuis un dépôt, et les demandes sont conservées dans un système distinct. Le mardi après-midi, l'équipe découvre qu'un déploiement effectué le lundi a supprimé une page de service. Une nouvelle demande est arrivée le mardi matin.
La première question est de savoir si le problème touche uniquement les pages publiées ou également le système de demandes. Si un déploiement précédent contient la page manquante, l'équipe peut envisager d'y revenir sans supposer qu'elle doit restaurer les demandes stockées séparément. Elle vérifie quelles autres modifications du site seraient également annulées et si récupérer uniquement la page serait préférable.
Dans un aperçu isolé, le prestataire responsable démontre la version proposée et vérifie les liens convenus ainsi que la configuration du formulaire. Le responsable de l'entreprise examine les modifications concernées et autorise la reprise en production selon le processus établi. L'enregistrement plus récent du système de demandes est examiné séparément, puisque ses modalités de stockage et de restauration sont distinctes.
Cet exemple décrit une méthode de décision, pas un résultat client rapporté ni une promesse de délai de reprise. Pour une boutique en ligne dont les commandes sont stockées dans la base de données du site, la même décision devrait tenir compte des commandes créées après le point de restauration proposé. La leçon utile consiste à identifier où les informations sont conservées avant de choisir ce qu'il faut restaurer.
7. Inscrire les responsabilités de reprise dans l'accord
Terminez par une courte checklist à laquelle les deux parties peuvent répondre. Conservez-la avec les documents de passation du site et réexaminez-la lorsque le site change. Elle doit rester compréhensible pour la personne qui devrait signaler un incident, même si cette personne n'a pas commandé le projet initial.
- Nous savons quels composants du site et quels systèmes externes sont couverts.
- Nous avons convenu des objectifs de reprise, de la fréquence des sauvegardes et de leur durée de conservation.
- Nous savons qui vérifie les échecs et qui peut obtenir un accès autorisé pour la restauration.
- Nous comprenons les méthodes de reprise prises en charge et le risque pour les données récentes.
- Nous disposons d'un compte rendu daté du test de restauration, avec ses limites et les prochaines actions.
- Nous avons convenu des responsabilités, de la disponibilité et des éventuels frais de reprise distincts.
Ajoutez les exigences non résolues au cahier des charges du projet web. Si la préparation de la reprise accompagne le remplacement du site, utilisez la checklist de refonte pour la transition dans son ensemble. Un accord de reprise clair réduit l'incertitude lorsqu'un incident survient ; il doit décrire ce qui a été convenu et démontré.
Chez Digital Studio, la création de site web commence à 2 190 EUR pour une réalisation ponctuelle de cinq pages maximum à partir des contenus fournis, avec un design responsive, les bases du SEO, un formulaire de demande et la mise en ligne sur votre domaine. Les modalités de sauvegarde, les tests de restauration et l'assistance continue à la reprise doivent être discutés et leur périmètre explicitement défini pour votre projet. Décrivez votre site et vos exigences de reprise afin de convenir des responsabilités et des éventuels travaux supplémentaires avant le début de la réalisation.
