Résiliation hébergement PrestaShop : sauvegarde complète et plan de migration

Table des matières :

Ce que couvre réellement une « résiliation hébergement PrestaShop »

Résilier un hébergement PrestaShop ne consiste pas uniquement à « déplacer des fichiers » : vous perdez un environnement d’exécution complet (versions PHP, extensions, configuration FPM/Apache, règles WAF éventuelles, tâches cron, certificats TLS, SMTP, accès objets/stockage, etc.). La première erreur classique est de ne sauvegarder que /public_html + un export SQL, puis de découvrir après coup que des composants périphériques (webhooks, jobs, index de recherche, secrets) sont restés sur l’ancien serveur.

Côté PrestaShop, le cœur ne documente pas vraiment une procédure de sortie d’hébergeur « zéro surprise ». Le CMS stocke une partie critique de l’état dans la base (config, hooks, modules, translations, CMS pages), mais le runtime (cache, sessions, logs, overrides, thème, médias, modules custom, fichiers téléchargeables) dépend fortement du filesystem et de la configuration serveur. La résiliation doit donc être abordée comme une migration d’infrastructure applicative, pas comme une opération d’admin de boutique.

Enfin, la résiliation a une dimension contractuelle et RGPD : durée de rétention des sauvegardes chez l’hébergeur, suppression des volumes, accès résiduel aux snapshots, traitement des logs contenant des données personnelles. Si votre hébergeur fournit des snapshots automatiques, ne présumez pas qu’ils seront exploitables après fermeture du compte : exportez-les avant d’entamer la procédure de clôture.

Point souvent sous-estimé : « résilier » peut aussi vouloir dire changer de périmètre de responsabilité. Exemple très concret : vous aviez une pile “managée” (mises à jour OS/PHP, sauvegardes, pare-feu), vous basculez sur une VM/IaaS où tout est à votre charge. Dans ce cas, la migration n’est pas seulement technique, elle est aussi organisationnelle : qui patch ? qui surveille ? qui valide les restore tests ? Une bonne pratique est d’écrire noir sur blanc, avant le cutover, ce qui était fourni par l’ancien hébergeur (backup quotidien, rétention, monitoring, anti-DDoS, etc.) et ce qui doit être reconstitué chez le nouveau.

Inventaire technique avant sauvegarde : ce que vous devez extraire du serveur

Avant toute sauvegarde, fixez un périmètre. Pour une boutique PrestaShop 8.1/9.x (PHP 8.1 à 8.3 typiquement ; voir les contraintes exactes selon votre version), l’inventaire minimal comprend : base MySQL/MariaDB, code (thème + modules + overrides), médias (/img), fichiers sensibles (config, clés, certificats), et données hors-webroot (ex. /download pour produits virtuels). Ajoutez systématiquement les éléments « non visibles » : crons (ex. cronjobs du module, tâches système), files d’attente, index externes, stockage S3/MinIO, et configuration SMTP.

Concrètement, listez et exportez :

Accès : utilisateurs SSH/SFTP, clés, règles sudo, IP whitelist (paiement, ERP), règles firewall.
Dépendances runtime : version PHP, extensions (intl, gd/imagick, curl, soap, zip), config OPcache, limites memory_limit, max_execution_time.
Services : Redis/Memcached (si sessions/cache), Varnish/HAProxy, cron, supervisor (workers), ELK/SIEM.
Intégrations : webhooks (PS, ERP, paiement), endpoints API, clés API (nShift, Dolibarr, etc.), DNS (A/AAAA/CNAME, TXT SPF/DKIM/DMARC), CDN.

Ce travail est plus rapide si vous avez déjà des runbooks de prod. Si ce n’est pas le cas, partez d’une base et normalisez : l’article sur les runbooks et le monitoring peut servir de squelette pour cadrer les points de contrôle et les seuils d’alerte : https://www.expertise-prestashop.fr/2026/06/18/prestashop-performance-monitoring-tests-de-charge-et-runbooks-soldes/

Pour éviter les angles morts, une méthode simple consiste à se poser la question : « qu’est-ce qui écrit encore des données si je coupe le front web ? » Les réponses typiques sont : cron (relances paniers, sync stock), webhooks (paiement), import ERP, workers de queue, et parfois des scripts maison déclenchés par des intégrations.

Tableau de repérage rapide (utile en atelier avec l’équipe technique/marketing/ERP) :

Élément à migrer	Où il se trouve	Risque si oublié	Vérification simple
Cron système + cron modules	crontab, panel, module	commandes non envoyées, stock non synchronisé	lister `crontab -l`, vérifier les modules “Cron”
SMTP et identité mail	config app + DNS	mails transactionnels en spam/non envoyés	test email BO + contrôle SPF/DKIM
Clés API / webhooks	BO + dashboards tiers	paiement “OK” côté client mais commande non confirmée	test paiement + réception callback
Stockage objet (S3/MinIO) / CDN	config module/thème	images cassées ou lenteurs	pages produits + console réseau
TLS/redirect/HSTS	vhost/proxy/CDN	boucles 301, mixed content	`curl -I`, test checkout

Astuce “zéro perte” : à ce stade, définissez aussi un “fichier de preuves” : une liste de 10 à 20 URL/pages/commandes/références (ID commande, ID client, SKU) qui serviront de points de contrôle avant/après, et que vous pourrez rejouer rapidement le jour J.

Sauvegarde complète de la base : cohérence, volumétrie et restauration testée

Pour la base, l’objectif n’est pas de « produire un .sql » mais d’obtenir une sauvegarde cohérente (sans lignes orphelines ni états transactionnels intermédiaires) et restaurable. En environnement InnoDB, mysqldump est l’outil standard de sauvegarde logique. En pratique, cela implique de capturer schéma + données + triggers + routines + events, et de gérer correctement la concurrence.

Pour une boutique active, passez la boutique en maintenance (Back Office) et neutralisez les writes cachés : webhooks, cron module, imports automatisés, ERP. L’option --single-transaction permet un dump cohérent sans verrouiller toutes les tables InnoDB, mais elle ne protège pas les tables non transactionnelles. Exemple (MySQL/MariaDB) :

# Pré-requis : accès réseau DB, user dédié en lecture + SHOW VIEW + TRIGGER
mysqldump \
  --host=127.0.0.1 --user=backup --password \
  --default-character-set=utf8mb4 \
  --single-transaction --quick --routines --triggers --events \
  --set-gtid-purged=OFF \
  --databases prestashop \
  | gzip -9 > prestashop_$(date +%F_%H%M).sql.gz

Deux points qui évitent des restaurations “surprises” :

Encodage et collation : assurez-vous d’être en utf8mb4 bout en bout (dump + restore) pour éviter des caractères cassés (emojis, accents, symboles).
DEFINER / droits : certains dumps incluent des DEFINER= (vues, triggers). Selon les politiques de votre nouveau serveur, cela peut bloquer l’import. Si vous avez des vues/routines, testez l’import très tôt en préprod.

Au-delà de quelques dizaines de Go, une sauvegarde logique peut devenir lente et consommatrice (CPU + I/O) et votre fenêtre de maintenance s’allonge. Dans ce cas, privilégiez un backup physique type Percona XtraBackup (InnoDB) avec test de restauration sur une instance isolée (https://docs.percona.com/percona-xtrabackup/8.0/). Dans tous les cas, testez la restauration : importer sur une DB vierge, lancer CHECK TABLE (ou, mieux, checks applicatifs), et comparer des métriques simples (nombre de commandes, clients, produits) avant/après. Sans restauration testée, votre « sauvegarde » n’est qu’un fichier.

Pour rendre le contrôle plus “opérationnel”, vous pouvez ajouter une mini-checklist de cohérence post-restore :

nombre de lignes sur tables critiques (ex. commandes, clients, produits) identique à ±0 (ou compréhensible si vous avez gelé les écritures) ;
possibilité de se connecter au Back Office ;
recherche BO/FO fonctionnelle (si vous utilisez un moteur externe, prévoir la reconstruction d’index) ;
paiement en mode test (si disponible) et génération de facture PDF.

Et pour sécuriser le transfert du dump entre serveurs, calculez un checksum (utile quand vous passez par des stockages intermédiaires) :

sha256sum prestashop_2026-06-22_2300.sql.gz > prestashop_2026-06-22_2300.sql.gz.sha256

Sauvegarde complète des fichiers : éviter les oublis (médias, modules, overrides, virtual products)

Le filesystem PrestaShop contient des données métier (images, factures PDF selon modules, exports, logs), pas seulement du code. Ne limitez pas la copie à la racine HTTP : vérifiez où votre hébergeur stocke les éléments hors webroot (ex. /home/.../download, répertoires de jobs, clés privées). Côté PrestaShop, incluez systématiquement :

/img/ (volumétrie majeure), /mails/, /themes/, /modules/, /override/ (si présent), /translations/.
/download/ (produits virtuels), /upload/ (pièces jointes, imports), /config/ et fichiers .env si vous en avez.
Éventuels répertoires custom (/var/ hors cache, exports, feeds, intégrations).

Pour une copie robuste et relançable, rsync est généralement plus fiable qu’un zip fait depuis un panel. Le manpage résume l’outil : « rsync is a fast, versatile, remote (and local) file-copying tool » (https://rsync.samba.org/). Exemple (depuis un bastion ou votre poste d’admin) :

rsync -aHAX --numeric-ids --info=progress2 \
  --exclude='/var/cache/' --exclude='/cache/' \
  --exclude='/.git/' \
  user@old-server:/var/www/prestashop/ \
  ./backup_fs/

Attention aux permissions et propriétaires : une migration qui « marche » en dev mais casse en prod est souvent un problème de droits sur /var/, /img/ ou /config/. Capturez aussi la configuration serveur utile au diagnostic : vhost Nginx/Apache, pool PHP-FPM, versions, et paramètres php.ini. Ces fichiers ne sont pas importés par PrestaShop, mais ils expliquent 80% des différences de comportement après migration (upload max, timeouts, headers cache, compression, etc.).

Ajouts utiles (souvent oubliés car “hors PrestaShop”) :

Jobs/exports : si vous déposez des flux pour comparateurs/marketplaces (CSV, XML) dans un répertoire spécifique, migrez-le aussi (sinon rupture de diffusion).
Fichiers de validation de domaine : certains services (DSP2, passerelles, outils marketing) demandent un fichier à déposer (ex. dans /.well-known/ ou à la racine). Vérifiez si votre boutique en contient.
Logs pertinents : pas pour tout migrer, mais pour garder des preuves techniques durant la période de rollback (erreurs PHP, logs reverse-proxy, logs applicatifs). Dans une logique RGPD, limitez la conservation au strict nécessaire et appliquez une rétention.

Mini-scénario courant : la boutique “semble OK”, mais les clients ne reçoivent plus les fichiers virtuels. La cause : /download/ ou ses permissions n’ont pas été migrés, ou le module qui sert les fichiers pointe vers un chemin absolu différent. D’où l’intérêt de tester au moins un produit virtuel en préprod, pas seulement un parcours panier standard.

Plan de migration : préparer le nouvel hébergement et organiser un cutover propre

La partie la plus coûteuse d’une migration est la divergence environnementale. Alignez d’abord les versions : PrestaShop 9 introduit Symfony 6.4 et des exigences modernes côté PHP/CLI (voir la compatibilité PHP et nouveautés développeurs : https://www.expertise-prestashop.fr/2026/03/24/prestashop-9-1-compatibilite-php-8-1-8-5-cli-et-nouveautes-developpeurs/). Si vous migrez à iso-version PrestaShop, gardez au minimum le même couple PHP + extensions, la même version majeure de MariaDB/MySQL, et la même stratégie de cache.

Provisionnez ensuite une préprod sur le nouvel hébergement et restaurez-y vos sauvegardes. C’est là que vous mesurez :

la compatibilité des modules (extensions PHP manquantes, fonctions dépréciées),
la performance baseline (TTFB, cache, opcache),
les contraintes réseau (sortie SMTP, API paiement, webservices ERP).

Pour cadrer la perf, partez sur des métriques concrètes (TTFB, LCP, erreurs 5xx, saturation DB). Les articles suivants donnent une base exploitable : optimisation TTFB https://www.expertise-prestashop.fr/2026/06/03/ttfb-prestashop-reduire-le-time-to-first-byte-sous-200-ms/ et configuration Varnish/ESI si vous utilisez du cache HTTP avancé https://www.expertise-prestashop.fr/2026/05/22/varnish-cache-configuration-esi-pour-optimiser-le-cache-par-fragments/. Si votre archi passe par un reverse-proxy, documentez vos frontends/backends et ACL (utile au cutover) : https://www.expertise-prestashop.fr/2026/06/22/haproxy-3-2-deploiement-systemd-configuration-frontend-backend-acl/

Le cutover DNS doit être traité comme un changement de prod : baissez le TTL (ex. 300s) au moins 24h avant, pré-provisionnez TLS, puis basculez. Pour TLS, n’inventez rien : Let’s Encrypt est la norme (et sa définition officielle est claire : « a free, automated, and open certificate authority » https://letsencrypt.org/about/). En parallèle, préparez un plan d’arrêt/relance : désactiver les crons sur l’ancien serveur, passer en maintenance, réaliser un dernier delta DB + filesystem (rsync incrémental), puis ouvrir la boutique côté nouveau serveur.

Deux détails “terrain” qui font gagner du temps le jour J :

Propagation DNS et caches : même avec un TTL bas, certains résolveurs et navigateurs gardent des valeurs en cache de façon imprévisible. Préparez un plan de vérification depuis plusieurs réseaux (4G, fibre bureau, VPN) et, si vous utilisez un CDN/proxy, identifiez ce qui doit être purgé côté edge.
Paiement/anti-fraude : de nombreux PSP contrôlent l’IP serveur ou l’empreinte TLS. Anticipez : vérifiez les whitelists IP, les URLs de notification, et les environnements de test. Cela évite le cas classique “checkout OK mais aucun statut de commande ne remonte”.

Validation post-migration : contrôles fonctionnels, SEO, performance et sécurité

Après restauration, ne vous fiez pas au simple chargement de la home. Faites une validation orientée flux métier : panier, tunnel de commande, paiement (redirection et retour IPN/webhook), création compte, email transactionnel, génération facture, back-office (grille produit, recherche, export). Sur PrestaShop, des régressions se cachent souvent dans des hooks/overrides : vérifiez les logs PHP et le var/log selon votre version.

Côté SEO technique, une migration d’hébergement ne devrait pas changer d’URL, mais elle change souvent des détails : headers (HSTS, compression), canonical, redirections, robots, sitemap, statut HTTP des pages. Contrôlez les codes 200/301/404, et la cohérence des contenus rendus (pas de page « vide » suite à un cache/JS cassé). Si vous avez besoin d’une checklist d’audit de rendu, cette ressource est directement applicable : https://www.expertise-prestashop.fr/2026/05/04/contenu-de-page-vide-checklist-daudit-et-plan-de-remediation/

Ajoutez un contrôle “SEO/ops” simple mais très efficace : comparez un petit échantillon d’URL avant/après (catégories, produits, CMS, panier, recherche) et vérifiez :

même status HTTP (idéalement 200 sur les pages indexables, 301 maîtrisées) ;
même canonicals et mêmes meta robots ;
pas de changement non voulu sur www/non-www ou HTTP→HTTPS (les chaînes de redirection coûtent des ms et peuvent créer des erreurs).

Côté performance, comparez avant/après sur un scénario reproductible : TTFB sur endpoints clés, temps de réponse DB sur requêtes critiques, et Core Web Vitals en conditions réalistes (mobile). L’objectif n’est pas « plus rapide » mais « pas pire ». Mesurez l’impact des caches (OPcache, Varnish), et vérifiez les indexes si vous observez des slow queries ; pour une approche rigoureuse côté SQL, appuyez-vous sur EXPLAIN et l’optimisation d’index : https://www.expertise-prestashop.fr/2026/05/25/index-mysql-optimiser-where-join-et-order-by-avec-explain/

Sur la sécurité, partez du principe que des secrets ont été exposés à l’ancien environnement : régénérez/rotater les mots de passe DB, clés API, tokens webhook, SMTP, et si possible les cookies keys (avec prudence car cela invalide des sessions). Pour durcir l’expo API/back-office (WAF, journalisation, SIEM), vous avez un cadre concret ici : https://www.expertise-prestashop.fr/2026/05/29/securite-prestashop-proteger-api-backoffice-waf-et-journalisation-siem/ et une vue 2026 des menaces : https://www.expertise-prestashop.fr/2026/04/20/securite-prestashop-2026-risques-majeurs-et-protections-professionnelles/

Enfin, contrôlez un point souvent “hors radar” mais très visible business : la délivrabilité email. Après migration, un changement d’IP sortante peut impacter le taux de réception (mails en spam, blocage). Sans surcharger l’article, retenez au minimum :

test d’envoi (BO) + réception sur plusieurs boîtes (Gmail, Outlook, domaine pro),
cohérence des enregistrements SPF/DKIM/DMARC (si vous les gérez sur votre DNS),
journal d’erreurs SMTP côté serveur (auth, TLS, quotas).

Rollback, purge et RGPD : ne pas fermer l’ancien hébergement trop tôt

Un rollback n’est pas une option théorique : c’est une exigence opérationnelle. Concrètement, vous devez savoir comment revenir en arrière si le paiement ou la DB part en vrille après la bascule. Gardez l’ancien hébergement (ou au minimum un snapshot complet) le temps d’un cycle complet de vente + retours + exports comptables (souvent 7 à 14 jours).

Le runbook de rollback doit être écrit avant le cutover : quelles conditions déclenchent le retour (taux d’erreur, pertes de commandes, latence DB), qui décide, et comment vous resynchronisez la donnée (si des commandes ont été prises sur le nouveau). Si vous voulez aller plus loin, mettez en place une courte fenêtre « write freeze » et une bascule avec dernier dump + diff incrémental, plutôt qu’une bascule « au fil de l’eau ». Sans ce cadre, vous risquez une divergence irréconciliable des commandes.

Deux approches réalistes (à choisir selon votre volumétrie et vos contraintes) :

Rollback “DNS” : vous rebasculez le DNS vers l’ancien serveur et vous acceptez de perdre les écritures réalisées sur le nouveau pendant une courte fenêtre (acceptable uniquement si vous avez gelé les writes ou si vous êtes en maintenance).
Rollback “applicatif” : vous restez sur le nouveau serveur mais vous corrigez un incident (module incompatible, extension PHP manquante, paramètre proxy, etc.). C’est souvent le meilleur compromis si les commandes ont déjà repris.

Enfin, la résiliation implique une purge contrôlée : suppression des comptes/accès chez l’hébergeur, suppression des volumes et snapshots, et demande de confirmation écrite sur l’effacement des données si vous êtes soumis à des exigences strictes (DPA). Côté RGPD, vos logs d’accès, exports, et sauvegardes contiennent des données personnelles : intégrez-les dans votre registre et votre plan de rétention (principe de “limitation de la conservation”, RGPD, art. 5). Pour un cadre d’audit exploitable en e-commerce, référez-vous à la grille de contrôle : https://www.expertise-prestashop.fr/2026/06/02/audit-rgpd-prestashop-88-points-de-controle-pour-boutiques/

Un dernier point pratique : si vous externalisez des sauvegardes chiffrées (S3, NAS, coffre-fort), documentez où elles sont stockées, qui possède les clés, et combien de temps vous les gardez. La purge RGPD n’est pas compatible avec des “backups orphelins” impossibles à inventorier.

Checklist opérationnelle (J-7 → J+1) pour une résiliation sans perte

À J-7, vous cherchez à réduire l’incertitude : abaissez le TTL DNS, identifiez toutes les intégrations et IP whitelists, et provisionnez une préprod restaurée sur le nouvel hébergement. C’est aussi le moment de nettoyer la base (tables de logs énormes, caches applicatifs) pour réduire la durée des transferts ; une routine de maintenance DB bien cadrée évite de migrer du bruit : https://www.expertise-prestashop.fr/2026/04/30/base-de-donnees-prestashop-routine-de-maintenance-et-nettoyage-automatise/

À J-1 / J0, exécutez la bascule : maintenance + arrêt des crons, backup DB final, rsync incrémental final, restauration/upgrade des permissions, purge cache, warmup (pages clés), puis ouverture. Documentez chaque étape avec horodatage (utile si paiement/ERP contestent une incohérence). Si vous utilisez ElasticSearch ou un moteur externe, planifiez la reconstruction d’index après migration (la reconstruction est souvent plus rapide et plus saine que la copie brute d’un data directory).

À J+1, vous validez en prod : monitoring (erreurs 4xx/5xx, latence, saturation), contrôle des emails transactionnels, et vérification de la complétude fonctionnelle (commande → paiement → facture → expédition). Ne résiliez l’ancien hébergement qu’après avoir consolidé : logs, preuves de commandes, exports, et un dernier snapshot « légal/ops » chiffré. Si vous n’avez pas de tests de charge, exécutez a minima un scénario synthétique (crawl + checkout) pour détecter une régression grossière ; le plan de monitoring et tests décrit ici est un bon point de départ : https://www.expertise-prestashop.fr/2026/06/18/prestashop-performance-monitoring-tests-de-charge-et-runbooks-soldes/

Pour rendre la checklist immédiatement actionnable, voici une version “contrôle/feu vert” en fin de bascule :

Feu vert fonctionnel : 1 commande test payée (ou mode sandbox), 1 email transactionnel reçu, 1 facture générée, 1 création de compte OK.
Feu vert technique : logs sans erreurs fatales répétées, pas de pic anormal de 5xx, cache applicatif opérationnel, cron relancés uniquement côté nouveau serveur.
Feu vert SEO : robots.txt conforme, sitemap accessible, absence de noindex accidentel, redirections propres (pas de chaînes).
Feu vert sécurité : rotation des secrets planifiée/exécutée (au moins paiements + SMTP + accès admin), accès anciens révoqués, sauvegarde post-migration chiffrée vérifiée.