Aller au contenu principal

Guide de la politique de conservation des sauvegardes de sites web

· 6 minutes de lecture
Customer Care Engineer

Publié le 6 novembre 2026

Guide de la politique de conservation des sauvegardes de sites web

Une sauvegarde qui existe, mais qui ne permet pas de restaurer la bonne version de votre site web, est peu rassurante à 2 heures du matin. Un guide pratique sur la politique de conservation des sauvegardes commence par une question simple : jusqu’où faut-il pouvoir remonter lorsqu’un problème survient, qu’un élément est supprimé ou qu’un système est compromis ?

Pour le site d’une petite entreprise, la réponse peut être de quelques semaines. Pour une agence qui gère les boutiques, les bases de données et les e-mails de ses clients, cela peut être plusieurs mois, voire plus. La bonne politique ne consiste pas à conserver toutes les sauvegardes indéfiniment. Il s’agit de conserver suffisamment de copies propres et restaurables pour résoudre les problèmes réels, sans faire des coûts de stockage et de gestion un problème supplémentaire.

À quoi sert réellement une politique de conservation des sauvegardes​

Un calendrier de sauvegarde indique quand les copies sont créées. Une politique de conservation indique combien de temps chaque copie reste disponible avant d’être supprimée. Vous avez besoin des deux.

Sans règles de conservation, le stockage se remplit discrètement, jusqu’à ce que les sauvegardes échouent ou que les factures augmentent sans raison valable. Avec des règles trop strictes, la sauvegarde dont vous avez besoin risque d’avoir déjà disparu. Cela arrive plus souvent qu’on ne le pense : une mise à jour corrompue d’un plugin peut passer inaperçue pendant plusieurs jours, une suppression accidentelle peut être découverte en fin de mois, ou un problème de base de données peut avoir été répercuté sur toutes les sauvegardes récentes.

Une bonne politique distingue la restauration à court terme de la protection à long terme. Les sauvegardes récentes permettent de gérer les incidents courants, comme un déploiement qui échoue ou une mise à jour WordPress défectueuse. Les points de restauration plus anciens aident à résoudre les problèmes qui évoluent lentement, à effectuer des audits et des rapports saisonniers, ou à gérer une violation détectée tardivement.

Commencez par les besoins de restauration, pas par l’espace de stockage​

Il peut être tentant de choisir les périodes de conservation en fonction de l’espace de stockage disponible. Commencez plutôt par évaluer les risques. Le stockage représente un coût à maîtriser, mais la perte de données du site web, les commandes manquées et une longue interruption de service coûtent généralement plus cher.

Deux objectifs de restauration facilitent la prise de décision. Votre objectif de point de reprise, ou RPO, correspond à la quantité maximale de données que vous pouvez vous permettre de perdre. Si une boutique en ligne ne peut perdre qu’une heure de commandes, elle doit disposer de sauvegardes ou d’une protection de base de données au moins aussi fréquentes. Un site vitrine mis à jour une fois par semaine peut tolérer un intervalle beaucoup plus long.

Votre objectif de délai de restauration, ou RTO, correspond au délai dans lequel le service doit être rétabli. Une sauvegarde n’est utile que si vous pouvez la restaurer dans ce délai. Des sauvegardes quotidiennes peuvent répondre à votre RPO, mais la restauration d’un grand serveur depuis un stockage distant peut tout de même dépasser votre RTO. La durée de conservation et la vitesse de restauration doivent être planifiées ensemble.

Pour la plupart des sites web, classez les systèmes en fonction de leur impact. Un portfolio personnel, un site marketing d’entreprise, une boutique WooCommerce très fréquentée, un compte d’hébergement client et un serveur de messagerie ne devraient pas forcément suivre les mêmes règles. Plus les données changent souvent et plus les revenus ou la confiance en dépendent, plus les sauvegardes doivent être fréquentes et conservées avec soin.

Guide pratique sur la politique de conservation des sauvegardes​

Un calendrier à plusieurs niveaux fonctionne bien, car il fournit des points de restauration fréquents sans conserver indéfiniment chaque sauvegarde complète. Pour un site web d’entreprise classique, un bon point de départ consiste à conserver les sauvegardes quotidiennes pendant 14 à 30 jours, les sauvegardes hebdomadaires pendant 8 à 12 semaines et les sauvegardes mensuelles pendant 6 à 12 mois.

C’est un point de départ, pas une règle absolue. Un site dont le contenu est mis à jour quotidiennement peut nécessiter 30 versions quotidiennes. Une entreprise de commerce électronique peut avoir besoin de sauvegardes de base de données plus fréquentes, surtout pendant les périodes de soldes. Un développeur qui travaille sur une refonte majeure peut temporairement prolonger la conservation jusqu’à ce que la nouvelle version soit stable. Un petit site statique peut être bien protégé par des copies hebdomadaires et mensuelles.

Pour les systèmes contenant des documents financiers, contractuels ou soumis à une réglementation, une conservation plus longue peut être nécessaire. Ne confondez toutefois pas la conservation opérationnelle des sauvegardes avec la conservation officielle des documents. Une sauvegarde est conçue pour la restauration. Elle ne constitue pas toujours le format, le mode d’accès ou le système de contrôle adapté aux archives juridiques. Si votre entreprise est soumise à des exigences de conformité, définissez-les séparément en vous appuyant sur les conseils juridiques ou opérationnels appropriés.

Conservez davantage de versions autour des changements​

Les risques ne sont pas répartis uniformément sur l’année. Les mises à jour majeures de plugins, les migrations, les changements de serveur, les nouvelles intégrations et les importations massives sont autant de moments où un site web risque le plus de se comporter de façon imprévisible.

Créez une sauvegarde vérifiée avant le changement. Conservez-la plus longtemps que d’habitude, jusqu’à ce que la nouvelle version ait fonctionné correctement pendant une période raisonnable. Par exemple, si vous migrez le site d’un client, conservez la sauvegarde antérieure à la migration jusqu’à ce que le client confirme que les formulaires, l’envoi des e-mails, les paiements et les pages clés fonctionnent comme prévu.

Cette petite habitude évite une erreur fréquente : supprimer la dernière copie connue comme fonctionnelle juste avant de découvrir que le problème a commencé plusieurs semaines plus tôt.

Appliquez le principe 3-2-1 sans vous compliquer la vie​

L’approche 3-2-1 reste utile, car elle protège contre différents types de défaillances. Conservez au moins trois copies des données importantes, sur deux types de supports différents, dont une copie hors site.

Pour un site web, cela peut désigner les données en ligne sur le serveur, une sauvegarde locale ou gérée par le fournisseur, ainsi qu’une copie chiffrée dans un espace de stockage de sauvegardes distinct. L’essentiel est de séparer les copies. Les sauvegardes stockées uniquement sur le même serveur risquent de disparaître avec lui. Les sauvegardes du même compte peuvent être exposées si les identifiants sont compromis.

Le stockage hors site n’a pas besoin d’être compliqué. Cela signifie que la copie est protégée contre la défaillance dont vous cherchez à vous remettre. Choisissez un emplacement de stockage et un modèle d’accès que votre équipe peut réellement gérer.

Protégez les sauvegardes contre la suppression et les rançongiciels​

Une politique de sauvegarde doit préciser qui peut supprimer des sauvegardes, modifier les paramètres de conservation et accéder aux données de restauration. Ces autorisations sont importantes, car un attaquant qui obtient un accès administrateur peut tenter de supprimer les points de restauration avant de chiffrer ou d’effacer les données de production.

Lorsque cette option est disponible, utilisez des sauvegardes immuables ou protégées en écriture pendant une période définie. Cela empêche les sauvegardes d’être modifiées ou supprimées trop tôt, même par un compte disposant de droits étendus. C’est particulièrement utile pour les sites critiques, les fournisseurs d’hébergement et les agences responsables de plusieurs environnements clients.

Le chiffrement est également important. Les sauvegardes contiennent souvent des bases de données, des fichiers de configuration, des données clients et parfois des identifiants. Chiffrez les données en transit et au repos, limitez l’accès aux personnes qui en ont besoin et stockez les clés de restauration en lieu sûr. Même une sauvegarde parfaitement conservée ne permet pas de restaurer les données si personne ne peut la déchiffrer.

Testez les restaurations avant d’en avoir besoin​

Les messages indiquant que les sauvegardes ont réussi ne remplacent pas les tests de restauration. Une tâche peut se terminer correctement alors que l’archive est incomplète, que l’export de la base de données est endommagé ou que le processus de restauration est trop lent pour vos besoins.

Testez les restaurations selon un calendrier adapté à l’importance du système. Un test trimestriel peut suffire pour un site simple. Les boutiques à fort trafic et les environnements d’hébergement devraient effectuer des tests plus souvent, en particulier après une modification des outils de sauvegarde, de la configuration des serveurs ou des destinations de stockage.

Dans la mesure du possible, effectuez la restauration dans un environnement de préproduction sécurisé. Ne vérifiez pas uniquement si la page d’accueil se charge. Vérifiez que la base de données se connecte, que le contenu récent est présent, que les utilisateurs peuvent se connecter, que les fichiers multimédias s’affichent, que les tâches planifiées s’exécutent et que les intégrations de paiement ou de formulaires de contact fonctionnent normalement. Notez la durée de la restauration et les étapes qui ont posé problème. Ce compte rendu devient le guide d’intervention que vous serez heureux d’avoir en cas d’incident.

Rédigez une politique que quelqu’un d’autre pourra suivre​

Une politique de conservation devrait tenir sur une ou deux pages, sans devenir un document que tout le monde évite d’ouvrir. Précisez ce qui est sauvegardé, la fréquence des sauvegardes, la durée de conservation de chaque type de sauvegarde, l’emplacement des copies, les personnes responsables du processus et la manière dont les restaurations sont testées.

Définissez également les exceptions. Par exemple, un compte client associé à une base de données volumineuse peut nécessiter des sauvegardes plus fréquentes, tandis que les projets archivés peuvent être conservés uniquement selon une périodicité mensuelle. La documentation des exceptions évite que les paramètres ne deviennent un ensemble de décisions ponctuelles énigmatiques.

Les utilisateurs de FASTPANEL peuvent mieux suivre ces opérations en gérant les sites web, les bases de données et les opérations serveur depuis un panneau de contrôle unique et clair, plutôt que de chercher les paramètres dans plusieurs outils. La visibilité ne remplace pas une politique, mais elle en facilite grandement l’application.

Votre politique de conservation devrait sembler ennuyeuse quand tout va bien. C’est un compliment. Lorsqu’une mise à jour défectueuse, une migration échouée ou une suppression accidentelle survient, le fait que tout soit ennuyeux signifie que la bonne copie est toujours disponible, que la procédure de restauration est connue et que votre équipe dispose d’un point de départ fiable.