Fichiers
Thème, médias, PDF, scripts et arborescence utile.
Avant une refonte, la sauvegarde fichiers refonte site doit couvrir séparément les fichiers, la base de données, les médias, les accès techniques et un point de retour vérifiable. Une archive ZIP posée sur le même serveur ne suffit pas.
Le risque est concret, mais il se prépare. Ancien site encore en ligne, nouveau site en préparation, contenus à reprendre, accès parfois détenus par un ancien prestataire. La bonne méthode n’est pas de tout copier au hasard, mais de savoir ce qui permet réellement de restaurer, migrer ou revenir en arrière. La question n’est pas seulement de faire une sauvegarde de site internet, mais de comprendre pourquoi vous la faites et comment la réaliser sans oubli dans la reprise de données.
En bref
- ✓Sauvegardes distinctes: Séparez fichiers, base de données et médias; une archive ZIP sur le même serveur n'est pas suffisante.
- ✓Accès validés: Testez SFTP, base, CMS, registrar et CDN avant la refonte pour éviter les blocages opérationnels.
- ✓Point de retour testé: Restaurez au moins une fois en préproduction ou téléchargez et ouvrez l'archive pour confirmer qu'elle est utilisable.
- ✓Stockage hors serveur: Conservez au moins une copie hors hébergement principal (Drive, Nextcloud ou cloud privé) et nommez-la avec date et domaine.
- ✓Fenêtre de gel: Pour les sites transactionnels, prévoyez une période de gel ou synchronisation finale, car 1 sauvegarde ancienne peut écraser des commandes récentes.
Avant la refonte, que faut-il sauvegarder en priorité ?
Synthèse
Les éléments à sécuriser en premier
La refonte doit distinguer ce qui permet de reconstruire, restaurer et remettre en ligne.
Base
Pages, réglages, comptes, formulaires et données dynamiques.
Accès
CMS, hébergeur, SFTP, DNS, registrar et stockage externe.
Retour arrière
Version datée, contrôlée et accessible hors serveur principal.
Une sauvegarde utile commence par les fichiers du site : thème, templates, scripts, feuilles CSS, dossiers médias, documents PDF et fichiers déposés par les utilisateurs. Sur WordPress, cela inclut souvent wp-content/uploads, le thème actif, un thème enfant et certaines extensions spécifiques.
La base de données doit être traitée comme un élément distinct. Elle contient fréquemment les pages, articles, menus, réglages CMS, comptes utilisateurs, formulaires et données dynamiques. Sans export MySQL ou sauvegarde équivalente, une copie de fichiers peut garder les images tout en laissant le site inutilisable.
La configuration compte aussi. Certains fichiers, comme wp-config.php sur WordPress, peuvent contenir des réglages sensibles et doivent être manipulés avec prudence. L’objectif n’est pas de les exposer partout, mais de savoir qu’ils existent et qu’ils participent à la restauration.
Enfin, les exports de contenus sont utiles pour une reprise de données éditoriale, mais ils ne remplacent pas une sauvegarde complète. Exporter des pages peut aider à reconstruire un nouveau site ; cela ne garantit pas de pouvoir remettre l’ancien en ligne.
Les accès à récupérer avant de toucher au site
Une sauvegarde sans accès exploitables peut bloquer une refonte autant qu’une absence de sauvegarde. Le cas classique : le nouveau site est prêt en préproduction, mais la mise en ligne attend parce que le DNS ou le registrar dépend encore d’un ancien prestataire.
| Élément à sécuriser | Pourquoi c’est important | Où le trouver | Format ou accès attendu | À vérifier avant refonte |
|---|---|---|---|---|
| Hébergement | Accès aux fichiers, sauvegardes et réglages serveur | Compte hébergeur | Identifiant administrateur | Propriétaire du compte et droits réels |
| SFTP/FTP | Copie de l’arborescence du site | Panneau hébergeur ou prestataire | Hôte, utilisateur, port, mot de passe ou clé | Connexion testée avant intervention |
| Base de données | Export des contenus et réglages dynamiques | Outil hébergeur, phpMyAdmin ou équivalent | Accès base ou export SQL | Export présent, ouvrable et daté |
| CMS admin | Exports, médias, réglages, comptes | Interface WordPress, PrestaShop, Shopify ou autre | Compte administrateur | Double accès si possible |
| Registrar et DNS | Contrôle du nom de domaine et mise en ligne | Bureau d’enregistrement | Compte propriétaire ou délégation claire | Accès non dépendant d’un ancien prestataire |
| Sauvegardes automatiques | Points de restauration existants | Hébergeur, plugin, outil tiers | Liste des versions disponibles | Date, rétention et possibilité de téléchargement |
| CDN éventuel | Cache, DNS ou certificats selon configuration | Compte CDN | Accès administrateur | Rôle exact dans la mise en ligne |
Testez avant de promettre une date de mise en ligne. Cela évite de découvrir un accès manquant trop tard.
Le bon réflexe consiste à tester les accès avant de planifier la bascule. Un identifiant “normalement disponible” ne vaut pas une connexion réussie.
Fichiers, base de données et reprise de contenus ne couvrent pas le même risque
À ne pas confondre
Trois copies pour trois usages
Chaque copie répond à un risque différent pendant la refonte.
Fichiers
Structure et médias
Utile pour récupérer thème, uploads, documents et code.
Base
Contenus dynamiques
Indispensable pour pages, réglages, comptes et formulaires.
Préproduction
Test de retour
Permet de vérifier sans toucher à la production.
Copier les fichiers préserve souvent le code, les images, les PDF et certains uploads. Mais beaucoup de CMS stockent les pages, menus, formulaires ou réglages dans la base. Une refonte peut donc perdre des contenus même si le dossier du site a bien été copié.
Sur un e-commerce, la prudence doit être plus forte. Une base ancienne peut écraser des commandes, comptes clients ou paiements créés entre la sauvegarde et la mise en ligne. Le point de retour doit donc tenir compte de la période où l’ancien site continue de vivre.
- Sauvegarde : copie de sécurité permettant de conserver un état du site.
- Restauration : remise en ligne d’un état antérieur à partir d’une sauvegarde.
- Migration : déplacement ou transformation vers une nouvelle structure technique.
- Reprise de contenus : tri, adaptation et réintégration des textes, médias et pages utiles.
Une copie partielle peut donner une fausse impression de sécurité. Elle rassure, puis bloque dès qu’il faut restaurer.
Pour approfondir ce point, consultez Quel support ne sauvegarde pas vraiment vos, qui traite plus précisément de quel support ne sauvegarde pas vraiment vos données ?.
Cette distinction évite une erreur fréquente : croire qu’un export de pages suffit à protéger le projet. Il aide la refonte, mais il ne garantit ni les réglages, ni les médias, ni la capacité à revenir en arrière. Pour réussir la reprise de données lors d’une refonte, il faut traiter séparément la sauvegarde technique (fichiers + base) et les exports éditoriaux.
Quelle méthode de sauvegarde choisir avant une refonte ?
La meilleure méthode dépend du CMS, du niveau de risque et des accès disponibles. Pour un site simple, une sauvegarde hébergeur téléchargée hors serveur peut suffire. Pour un projet plus sensible, il faut souvent combiner fichiers, base, préproduction et export éditorial. Concrètement, la sauvegarde de site internet, pourquoi et comment la faire se résume à une question : quel scénario de panne ou d’échec de refonte devez-vous pouvoir rattraper rapidement ?
| Méthode | Convient pour | Ce que cela sauvegarde | Limite principale | Précaution avant refonte |
|---|---|---|---|---|
| Sauvegarde hébergeur | Sites simples, point de retour rapide | Selon offre : fichiers, base ou environnement | Peut rester inaccessible ou stockée au même endroit | Télécharger une copie hors hébergement principal |
| Plugin CMS | WordPress ou CMS compatible | Fichiers, base, parfois réglages | Limites de taille ou de serveur | Vérifier l’archive produite |
| Export manuel fichiers plus base | Projet sensible, besoin de contrôle | Arborescence et export SQL | Demande une compétence technique minimale | Documenter date, source et responsable |
| Préproduction | Refonte testable sans toucher à la production | Copie de travail du site | Peut être désynchronisée | Identifier ce qui a changé depuis la copie |
| Export de contenus | Migration éditoriale | Pages, articles, parfois médias | Ne couvre pas tout le site | Le traiter comme complément, pas comme sauvegarde unique |
Certains hébergeurs ou prestataires conservent plusieurs points de restauration sur 7 à 30 jours. C’est utile, mais ce n’est pas une règle universelle. Il faut vérifier la rétention réelle, le mode de téléchargement et ce qui est inclus dans chaque point. Une archive peut couvrir les fichiers sans la base, ou l’inverse ; la seule façon de le savoir consiste à regarder le contenu de la sauvegarde et à documenter ce qu’elle permet réellement de restaurer.
Grille de décision
Choisir la bonne méthode de sauvegarde
Le choix dépend surtout du risque de perte et de la capacité à restaurer rapidement.
Simple
Site vitrine stable
Le site évolue peu et ne reçoit pas de données critiques ?
Impact décision : Une sauvegarde hébergeur téléchargée hors serveur peut suffire si elle contient fichiers et base.
Projet
Refonte active
Des contenus, médias ou réglages changent pendant la préparation ?
Impact décision : Combinez sauvegarde complète, export éditorial et note de synchronisation finale.
Sensible
E-commerce
Des commandes ou comptes clients peuvent apparaître entre deux copies ?
Impact décision : Prévoyez une base récente, une fenêtre de gel ou une reprise finale avant mise en ligne.
Avant mise en ligne
Le point de retour doit exister avant la bascule
La copie finale doit distinguer l’ancien site, les données récentes et les accès qui permettent de revenir en arrière.
Organiser la bascule sans écraser les dernières données
La sauvegarde initiale ne suffit pas toujours si l’ancien site continue de recevoir des formulaires, des commandes ou des inscriptions pendant que le nouveau se prépare. Dans ce cas, le chef de projet doit définir une période de gel, une synchronisation finale ou une règle claire sur les données à reprendre au dernier moment.
Sur un site vitrine, cela peut simplement consister à exporter les derniers messages de formulaire et à vérifier les médias ajoutés après la première copie. Sur un e-commerce, c’est plus sensible : commandes récentes, comptes clients, stocks, paiements et factures ne doivent pas être écrasés par une base plus ancienne.
Le jour de la mise en ligne, il faut savoir quelle sauvegarde sert de point de retour, qui peut modifier le DNS, qui valide le nouveau site et qui décide d’un retour arrière. Une refonte bien préparée n’empêche pas les imprévus, mais elle évite les discussions improvisées quand chaque minute compte.
Cette organisation peut tenir dans un document très simple : date de la dernière sauvegarde complète, emplacement de l’archive, accès validés, responsable technique, responsable métier et fenêtre de bascule prévue. L’essentiel est que chaque personne sache où trouver la version de référence.
Quand plusieurs prestataires interviennent, ce document évite aussi les responsabilités floues. L’agence qui refond le site, l’hébergeur, l’ancien webmaster et le responsable interne ne regardent pas toujours le même périmètre. Nommer les accès, les fichiers et les validations attendues limite les angles morts avant la mise en ligne.
Il faut enfin décider ce qui sera archivé après la refonte. Garder une copie de l’ancien site pendant quelques semaines aide à retrouver un visuel, un texte légal, une ancienne URL ou un document oublié. Cette archive ne doit pas rester publique sans contrôle, mais elle peut servir de filet de sécurité pendant la phase de vérification finale et les derniers ajustements métier prioritaires.
Où stocker la sauvegarde pour éviter une perte totale ?
La mauvaise pratique la plus dangereuse reste l’archive ZIP gardée dans un dossier du même serveur, par exemple dans /backup/. Si le serveur est supprimé, compromis, nettoyé ou inaccessible, la sauvegarde disparaît avec le site. C’est précisément ce scénario que vise la recommandation classique : « stocker une sauvegarde sur le même serveur d’hébergement : à éviter ».
Une copie doit exister hors de l’hébergement principal : Drive, Nextcloud, espace cloud contrôlé, coffre documentaire projet ou dépôt privé pour les fichiers de code. Le choix importe moins que deux règles : accès maîtrisé et nommage compréhensible.
- Conserver au moins une copie hors serveur principal.
- Nommer le fichier avec la date, le domaine et le type de sauvegarde.
- Identifier un propriétaire responsable de l’archive.
- Tester l’accès au dossier de stockage avant l’intervention.
- Marquer clairement la version qui sert de point de retour.
Évitez aussi l’excès inverse : cinq archives anonymes dans cinq espaces différents. Une sauvegarde introuvable ou impossible à dater ralentit la refonte au lieu de la sécuriser.
Contrôles pré-refonte
Checklist rapide avant toute intervention
Vérifiez ces éléments et testez les accès avant de toucher à la production.
- ✓Télécharger une copie complète hors du serveur principal (nommé + daté)
- ✓Exporter la base de données (SQL) et vérifier l'ouverture du fichier
- ✓Vérifier la présence de wp-config / fichiers de configuration sensibles
- ✓Tester SFTP, accès hébergeur, CMS admin et DNS (connexion réussie)
- ✓Identifier le propriétaire du compte registrar et la possibilité de modifier le DNS
- ✓Lister et récupérer accès CDN et certificats si utilisés
- ✓Documenter la version de référence: emplacement, date, responsable
- ✓Planifier synchronisation finale ou fenêtre de gel pour formulaires/commandes
Les contrôles qui prouvent qu’une sauvegarde est restaurable
Synthèse
Les preuves à garder avant bascule
Ces traces évitent de dépendre d’un souvenir ou d’un accès supposé disponible.
Archive datée
Nom de fichier clair, date et emplacement connu.
Export base
Fichier SQL ou sauvegarde de base identifié et ouvrable.
Accès testés
CMS, hébergement, SFTP et DNS validés avant intervention.
Point de retour
Version à restaurer désignée avant la mise en ligne.
Posséder un fichier ne prouve pas qu’il permettra de restaurer le site. Avant une refonte, le contrôle doit être simple, documenté et réalisé avant de toucher à la production.
- Télécharger l’archive ou l’export depuis sa source réelle.
- Vérifier la date, le poids et le nom du fichier.
- Ouvrir l’arborescence pour confirmer la présence des dossiers attendus.
- Contrôler l’export SQL ou la sauvegarde de base de données.
- Tester les accès CMS, hébergeur, SFTP et DNS.
- Restaurer en préproduction si le risque du projet le justifie.
La prudence se joue avant le clic de mise en ligne. Après, chaque correction devient plus visible.
Le test sur production doit rester exceptionnel. Quand le site a du trafic, des commandes ou des formulaires actifs, une préproduction limite fortement le risque de casser l’existant pendant la vérification.
Comment restaurer votre site web à partir d’une sauvegarde ?
En cas de problème lors de la refonte, la restauration doit suivre un chemin clair. Pour restaurer une sauvegarde de son site, la séquence courante est :
- Créer ou vérifier un environnement de test (préproduction) si possible.
- Remettre en place les fichiers : supprimer ou renommer les fichiers actuels, puis téléverser l’archive décompressée.
- Restaurer la base de données : vider la base actuelle ou en créer une nouvelle, puis importer le fichier SQL sauvegardé.
- Mettre à jour les accès de configuration (par exemple wp-config.php) pour pointer vers la bonne base.
- Tester le site restauré (pages, formulaires, back-office) avant toute remise en ligne publique.
- Basculer le DNS ou le vhost vers l’environnement restauré si les tests sont concluants.
Cela illustre pourquoi il est crucial de disposer à la fois d’une sauvegarde de fichiers, d’un export de base et d’accès réels au serveur avant de lancer une refonte.
Les pièges qui font perdre des contenus pendant la refonte
Les pertes viennent souvent d’une confusion de dates. Une base sauvegardée lundi peut écraser des commandes créées mardi. Une refonte peut aussi oublier des médias, supprimer un ancien thème encore utile, perdre une extension spécifique ou confondre export de pages et sauvegarde complète.
La Wayback Machine peut aider à retrouver une page publique, un texte, une URL ou parfois une image. Elle ne restaure pas la base de données, les formulaires, les comptes, les commandes, les réglages ou l’administration. C’est un recours partiel, pas un plan de retour. Elle peut sauver un contenu oublié, mais elle ne remplace jamais une sauvegarde datée, maîtrisée et testée.
Quand un doute apparaît, il vaut mieux ralentir la bascule que supprimer l’ancien environnement trop vite. Conserver temporairement une copie lisible, même hors ligne, donne le temps de vérifier une image oubliée, une page légale, une ancienne redirection ou un document téléchargeable encore demandé par les visiteurs.
FAQ : sauvegarde d’un site internet avant refonte
Pourquoi sauvegarder un site internet avant sa refonte ?
Une refonte touche au code, à la base de données et parfois à l’hébergement. Sans sauvegarde, un incident (erreur de manipulation, plugin incompatible, problème de migration) peut rendre le site inutilisable sans possibilité de retour. La sauvegarde protège vos contenus, vos données métiers (commandes, formulaires, comptes) et votre référencement en permettant de revenir à un état antérieur stable.
Comment sauvegarder son blog avant refonte ?
Pour un blog (WordPress ou équivalent), combinez :
- une sauvegarde complète via l’hébergeur ou un plugin (fichiers + base) téléchargée hors du serveur ;
- un export éditorial (articles, pages, catégories, commentaires) pour faciliter la reprise de contenus ;
- un test de restauration en préproduction si le blog génère du revenu ou du trafic important.
C’est la meilleure façon de comment sauvegarder son blog avant refonte sans perdre ni textes, ni images, ni réglages.
Où stocker la sauvegarde de son site internet ?
Stockez au minimum une copie hors du serveur de production : espace cloud d’entreprise, Drive, Nextcloud, dépôt privé Git pour le code, coffre documentaire projet, voire support chiffré interne. Évitez d’être dépendant d’un seul prestataire (hébergeur ou agence) et nommez clairement l’archive (date, domaine, type de sauvegarde) pour retrouver rapidement la bonne version en cas de besoin.
Combien de temps conserver l’ancienne version du site ?
La plupart des équipes gardent une copie exploitable de l’ancien site au moins le temps de la recette et des premiers retours utilisateurs (quelques semaines à quelques mois). Au-delà, une archive froide (compressée, hors ligne) suffit souvent pour retrouver un texte, une preuve légale ou un ancien média. L’important est de documenter où elle se trouve et qui peut y accéder.
La refonte peut commencer quand le retour arrière existe
Une refonte devient beaucoup moins risquée quand les fichiers et la base sont sauvegardés séparément, que les accès techniques sont récupérés, qu’une copie existe hors serveur principal et qu’une restauration a été contrôlée. Ce socle n’empêche pas tous les problèmes, mais il évite de découvrir trop tard qu’il n’y a aucun retour arrière.
La priorité avant de lancer le chantier : désigner la version à conserver, vérifier qui possède les accès et tester au moins le chemin de restauration le plus probable.
Pour approfondir ce point, consultez Zoho CRM, le bon choix pour structurer, qui traite plus précisément de zoho crm, le bon choix pour structurer votre relation client ?.
