Sauvegarde PrestaShop : tout ce qu’il faut conserver pour restaurer sa boutique

Une sauvegarde PrestaShop réellement restaurable ne se limite pas à un export de base de données ni à une copie partielle en FTP. La boutique dépend à la fois de ses données SQL, de ses fichiers applicatifs, de ses médias produits et de sa configuration serveur. Pour pouvoir revenir en ligne après une mise à jour ratée, une suppression de fichiers, une panne d’hébergement ou une compromission, il faut sauvegarder ces éléments ensemble, les conserver hors du serveur et tester leur restauration.

Les deux composants indispensables : base de données et fichiers

PrestaShop stocke les informations métier dans une base de données MySQL ou MariaDB : catalogue, clients, commandes, paniers, comptes employés, règles de prix, modules et paramètres. Les fichiers présents sur l’hébergement contiennent quant à eux le cœur de PrestaShop, le thème, les modules, les images, les documents et certains réglages propres à l’environnement.

Une restauration n’est cohérente que si la base et les fichiers correspondent au même instant ou à des instants très proches. Restaurer les fichiers d’un lundi avec une base du vendredi peut par exemple faire disparaître des images récemment envoyées ou laisser en base des références à des fichiers qui n’existent plus.

Sauvegarder la base de données complète

Exportez l’intégralité de la base utilisée par la boutique, et non uniquement quelques tables telles que ps_product ou ps_orders. Le préfixe ps_ est courant, mais il peut avoir été modifié lors de l’installation. Il faut donc sélectionner la base dont les identifiants figurent dans la configuration de PrestaShop.

Sur PrestaShop 1.7 et 8, ces identifiants sont généralement définis dans app/config/parameters.php. Sur des installations plus anciennes, ils peuvent être présents dans config/settings.inc.php. Ce fichier indique notamment le nom de la base, son serveur et le préfixe des tables.

Ce que doit contenir l’export SQL

• La structure des tables : commandes CREATE TABLE, index et clés.
• Les données : commandes INSERT ou export équivalent.
• Les procédures, déclencheurs ou vues s’ils existent et si l’hébergement les autorise.
• Un encodage adapté, généralement UTF-8 ou UTF-8MB4 selon la base en place.

phpMyAdmin permet un export SQL depuis la base concernée. Pour une base volumineuse, un export en ligne de commande est souvent plus fiable : mysqldump --single-transaction --routines --triggers -u utilisateur -p nom_base > prestashop.sql. L’option --single-transaction limite les incohérences sur les tables transactionnelles sans bloquer durablement l’activité. Vérifiez toutefois que le fichier généré n’est pas vide et qu’il peut être ouvert ou contrôlé avec un outil SQL.

La fonction de sauvegarde accessible dans le back-office peut dépanner pour obtenir un export de base. Elle ne remplace pas une stratégie complète : elle ne récupère pas les fichiers de la boutique et dépend de l’espace disque ainsi que des limites d’exécution du serveur.

Copier tous les fichiers de la boutique

La sauvegarde des fichiers doit porter sur le répertoire d’installation complet. Une synchronisation SFTP, SSH/rsync ou une archive créée côté serveur convient, à condition de ne pas exclure les dossiers importants par erreur. Une simple sauvegarde du thème ne permet pas de reconstruire une boutique.

Dossiers à contrôler en priorité

• img/ : images produits, catégories, fabricants et contenus importés. C’est l’un des dossiers les plus critiques.
• modules/ : modules installés, y compris les développements spécifiques et les versions payantes.
• themes/ : thème actif, thème enfant éventuel et personnalisations.
• override/ : surcharges de classes ou contrôleurs, si le projet en utilise.
• mails/ : modèles d’e-mails personnalisés, notamment dans les sous-dossiers de thème ou de module.
• download/ : fichiers téléchargeables vendus, lorsque cette fonctionnalité est utilisée.
• upload/ : pièces jointes et fichiers transmis selon les fonctionnalités activées.
• translations/ : traductions personnalisées si elles ne sont pas gérées autrement.

Conservez également les fichiers de configuration, notamment app/config/parameters.php ou config/settings.inc.php, sans les diffuser : ils contiennent des identifiants de base de données et des clés. Les fichiers .htaccess, les certificats ou réglages spécifiques peuvent aussi être nécessaires, mais les secrets doivent être chiffrés et accessibles uniquement aux personnes autorisées.

Ne pas confondre fichiers critiques et cache régénérable

Certains répertoires peuvent être reconstruits après restauration, comme le cache de PrestaShop. Selon la version, il se trouve notamment dans var/cache/ ou dans d’anciens répertoires de cache. Le sauvegarder n’est pas dangereux, mais il peut alourdir considérablement les archives et transporter des fichiers devenus inutiles.

En revanche, ne supprimez pas d’une sauvegarde les images ou les fichiers de modules sous prétexte qu’ils pourraient être régénérés : ce n’est généralement pas le cas. Après une restauration, videz le cache depuis le back-office si possible, ou supprimez uniquement son contenu lorsque la procédure est maîtrisée, puis testez l’affichage de la boutique.

Inclure les éléments hors du répertoire PrestaShop

Une boutique peut dépendre de composants placés ailleurs que dans son dossier web. Recensez-les avant d’avoir besoin de restaurer en urgence :

• tâches cron configurées chez l’hébergeur, par exemple pour les flux, relances ou synchronisations ;
• scripts d’import/export stockés hors de la racine web ;
• configuration Nginx ou Apache, redirections et règles de sécurité ;
• configuration PHP utile au fonctionnement de la boutique ;
• variables d’environnement, clés API et paramètres de services externes ;
• configuration d’un CDN, d’un cache serveur ou d’un service de recherche externe.

Ces éléments ne doivent pas tous être archivés de la même manière. Les clés API, par exemple, doivent être documentées dans un gestionnaire de secrets plutôt que déposées en clair dans une archive accessible. L’objectif est de disposer des informations nécessaires pour reconstruire l’environnement, sans créer une nouvelle faille de sécurité.

Mettre en place une sauvegarde exploitable

Planifiez séparément la fréquence des données et celle des fichiers. Une boutique qui reçoit des commandes quotidiennement nécessite généralement des exports SQL fréquents, car les commandes, paiements et comptes clients évoluent en continu. Les fichiers changent moins souvent, sauf lors d’ajouts massifs de produits, d’imports d’images ou de modifications de thème.

1. Créez une archive de fichiers datée et un export SQL daté, avec un format de nom explicite, par exemple boutique-2026-10-31-files.tar.gz et boutique-2026-10-31.sql.gz.
2. Stockez-les sur un emplacement distinct de l’hébergement : stockage objet, serveur de sauvegarde ou espace chiffré dédié. Une archive laissée sur le même serveur ne protège pas d’une suppression de compte ou d’une compromission complète.
3. Contrôlez la taille des fichiers et les journaux de tâche. Une archive anormalement petite peut signaler un échec, un manque d’espace ou une exclusion incorrecte.
4. Définissez une durée de conservation incluant plusieurs versions. Une sauvegarde récente peut déjà contenir une erreur, un fichier compromis ou une suppression passée inaperçue.
5. Documentez la version de PrestaShop, la version PHP, le thème actif, les modules essentiels et les actions de restauration.

Tester la restauration avant l’incident

Le test doit être réalisé sur un sous-domaine de préproduction ou un environnement isolé, jamais en écrasant directement la boutique active. Installez une base vide, importez le fichier SQL, placez les fichiers sauvegardés et adaptez les accès à la nouvelle base dans le fichier de configuration. Si l’URL change, vérifiez le domaine configuré dans les paramètres de la boutique et les redirections éventuelles.

Après restauration, contrôlez au minimum la page d’accueil, une fiche produit avec images, le panier, la connexion client, le tunnel de commande sans effectuer de paiement réel, les e-mails et le back-office. Vérifiez aussi les journaux PHP et PrestaShop. Une erreur après import peut provenir d’une incompatibilité de version PHP, d’un module absent, de permissions de fichiers inadéquates ou d’une archive incomplète. Ce test transforme une sauvegarde théorique en procédure de reprise réellement utilisable.