Résiliation hébergement PrestaShop : résilier sans perdre vos données

Une résiliation d’hébergement peut effacer une boutique en quelques minutes.

Pour résilier proprement votre serveur PrestaShop sans perte, l’objectif est simple : geler ce qui doit l’être, sauvegarder fichiers + base + éléments “oubliés”, puis restaurer et tester sur le nouvel environnement avant de confirmer la clôture. Vous gardez ainsi vos données, vos médias, vos modules, vos factures et votre continuité e-commerce.

Si vous préparez une migration encadrée et performante, cette offre d’hébergement PrestaShop éprouvée vous aidera à poser un cadre “zéro surprise” dès le départ.

Préparer les sauvegardes et les accès indispensables

Accès FTP/SSH et base de données : ce qu’il faut récupérer avant toute action

• Accès FTP (ou SFTP) : hôte, port, identifiant, mot de passe, racine web.
• Accès SSH (si disponible) : utilisateur, clé, port, commande de connexion.
• Accès base MySQL/MariaDB : hôte, nom de base, utilisateur, mot de passe, port.
• Accès back-office : URL admin, identifiants, et idéalement un compte “tech”.
• Accès DNS du domaine : registrar, zone DNS, TTL si modifiable, accès aux enregistrements (A/AAAA, CNAME, MX).

Sans ces accès, vous dépendez du support de l’hébergeur au pire moment (juste avant la résiliation). À minima, sécurisez un export de la base et une copie complète des fichiers, comme le recommande la documentation PrestaShop sur la sauvegarde des fichiers et de la base. PrestaShop Help Center

Temps estimé, difficulté et fenêtre de maintenance

Planifiez une fenêtre de maintenance site internet : vous voulez éviter qu’une commande ou qu’un paiement arrive entre votre dump de base et votre copie de fichiers. En pratique, la difficulté vient rarement du “copier/coller”, mais des détails (versions PHP, droits, cache, tâches cron, e-mails transactionnels, passerelles de paiement).

Checklist technique avant de toucher à quoi que ce soit (SSL, PHP, disque)

• SSL/TLS : certificat en place, date d’expiration, chaîne, redirections HTTP→HTTPS.
• Version PHP : version exacte, extensions activées, limites (memory_limit, upload_max_filesize).
• Espace disque : place disponible pour générer/exporter les archives (fichiers + dump).
• Mode debug / logs : emplacement des logs, niveau de verbosité, accès.
• Cache : PrestaShop + éventuels caches serveur (proxy/cache HTTP) à purger au bon moment.

Notez tout dans un mémo “migration” : l’objectif est de pouvoir reconstruire le même environnement sur le nouveau serveur, sans improvisation.

Sauvegarder les fichiers de la boutique et les médias

Exporter les fichiers via FTP, SSH ou gestionnaire

Copiez l’intégralité des fichiers de la boutique (pas seulement le thème). La méthode la plus fiable est :

• SSH : archive (tar/zip) côté serveur puis téléchargement (plus rapide, moins d’erreurs).
• FTP/SFTP : téléchargement récursif complet (plus long, mais accessible partout).
• Panneau d’hébergement : “File manager” + export (pratique, dépendant du fournisseur).

La documentation PrestaShop rappelle explicitement que les fichiers contiennent le cœur, le thème, les images et les modules : il faut donc sauvegarder le répertoire complet. PrestaShop Help Center

Snippet : arborescence à copier intégralement

/ (racine du site PrestaShop)
├─ adminXXXX/                  # votre dossier admin (nom personnalisé)
├─ app/                        # (selon versions) config, ressources, etc.
├─ config/                     # paramètres (selon versions)
├─ classes/
├─ controllers/
├─ img/                        # images produits, catégories, etc. (critique)
├─ mails/                      # templates e-mails
├─ modules/                    # modules (critique)
├─ override/                   # surcharges éventuelles
├─ themes/                     # thème(s)
├─ translations/
├─ upload/                     # fichiers uploadés
├─ var/                        # cache/logs (peut être régénéré mais utile en diag)
└─ .htaccess + fichiers racine (robots.txt, index.php, etc.)

Point SXO/UX : img/ et modules/ sont les deux répertoires les plus “chers” à oublier. Les médias impactent la présentation, et les modules impactent paiements, livraison, SEO et parfois le tunnel de commande.

Exporter la base de données et les paramètres

Dump MySQL via phpMyAdmin ou SSH

Deux voies propres existent :

• SSH : dump via mysqldump (robuste, automatisable).
• phpMyAdmin : export SQL depuis l’interface (accessible, attention aux limites).

Côté SSH, mysqldump est l’outil standard pour produire un backup logique réimportable sur un autre serveur. MySQL Reference Manual

Commandes types (à adapter à votre serveur)

# Dump complet (structure + données)
mysqldump -h DB_HOST -u DB_USER -p DB_NAME > prestashop.sql

# Option utile si vous avez beaucoup de trafic (InnoDB) :
# --single-transaction limite les verrous (cas fréquent en e-commerce)
mysqldump -h DB_HOST -u DB_USER -p --single-transaction DB_NAME > prestashop.sql

Si vous passez par phpMyAdmin, utilisez l’onglet Export/Import : la doc officielle détaille les modes d’import/export (y compris fichiers compressés) et les contournements en cas de fichiers lourds. Documentation phpMyAdmin

Points de vigilance (préfixe, encodage, tailles)

• Préfixe de tables : souvent ps_, mais pas toujours (utile pour diagnostiquer une restauration partielle).
• Encodage/collation : visez l’équivalent à l’arrivée (souvent utf8mb4) pour éviter des caractères “cassés”.
• Taille du dump : si l’export web échoue, basculez en SSH ou utilisez un dump compressé.
• Tables volumineuses : logs, stats, paniers, connexions… à traiter selon votre besoin métier.
• Secrets : certaines clés (API, SMTP, paiements) sont stockées en base et/ou en fichiers : gardez-les, mais manipulez-les comme des données sensibles.

Sur PrestaShop 1.7, la documentation “Database Backup” précise aussi l’emplacement des sauvegardes générées par PrestaShop (dossier /backup sous le dossier admin) et des options comme “ignorer les tables de statistiques”. PrestaShop 1.7 Documentation

Diagramme : ce que vous devez avoir en main avant de résilier

Flux : [Sauvegarde fichiers (core + themes + modules + img)] → [Export base MySQL (structure + données)] → [Sauvegarde paramètres (DNS, SMTP, cron, SSL)] → [Restauration sur nouveau serveur] → [Tests front-office/back-office] → [Bascule domaine] → [Résiliation confirmée]

Objectif : au moment où vous confirmez la résiliation hébergement prestashop, vous devez déjà être capable de redéployer votre boutique ailleurs à l’identique (ou d’expliquer précisément ce qui change).

Confirmer la résiliation hébergement PrestaShop

Vérifier engagement, préavis, frais et renouvellement automatique

Avant tout e-mail de clôture, relisez les conditions : engagement initial, préavis, date de renouvellement automatique, frais éventuels, et surtout date effective de suppression des données côté hébergeur. Le point critique : certains prestataires coupent l’accès (FTP/SSH/DB) avant la suppression, ce qui vous empêche de corriger un oubli de dernière minute.

Demander la suppression, mais garder l’accès le temps de la migration

Exigez une clôture “propre” : résiliation planifiée, accès maintenus jusqu’à la bascule validée, puis suppression à date convenue. Si vous avez un interlocuteur assistance/support (chez l’hébergeur sortant ou entrant), nommez un responsable de change pour verrouiller la séquence de bascule et éviter les coupures.

Snippet : message support pour une clôture propre

Objet : Résiliation hébergement PrestaShop – demande de clôture planifiée

Bonjour,

Je souhaite résilier mon hébergement hébergeant une boutique PrestaShop.
Merci de :
1) Me confirmer la date de fin d’engagement, le préavis applicable et tout frais éventuel.
2) Planifier la résiliation à la date : [JJ/MM/AAAA], avec maintien des accès FTP/SSH/DB jusqu’à validation de migration.
3) Me confirmer la date exacte de suppression des données (fichiers + base) et la procédure de récupération si besoin.

Cordialement,
[Nom / Société]
[Nom de domaine concerné]
[Identifiant client]

Ce message réduit les ambiguïtés : vous obtenez des dates, un maintien d’accès, et un accord clair sur le timing.

Tester la restauration et basculer sans coupure

Restaurer sur le nouvel hébergeur et vérifier le front-office

Restaurez d’abord “hors production” (URL de préproduction, IP temporaire, hosts local) pour valider : page d’accueil, catégories, fiches produit, recherche, tunnel de commande, compte client, performance perçue (TTFB, chargement images). Puis seulement ensuite, basculez le domaine.

Contrôler paiements, e-mails, modules et tâches cron

• Paiements : mode test, webhooks/retours, logs, 3DS si applicable.
• E-mails : SMTP, expéditeur, délivrabilité, templates, mails de commande/factures.
• Modules : licences, clés API, dépendances serveur (extensions PHP), compatibilité version.
• Cron : tâches planifiées (exports, relances, flux, indexations, nettoyages).
• Cache : purge et cohérence (éviter de servir de vieux contenus après bascule).

Si votre boutique déclenche des erreurs, regardez aussi les contrôleurs : une régression sur un contrôleur (ex. modulefrontcontroller) peut venir d’un module non restauré, d’un override manquant, ou d’une version PHP différente.

Matrice : erreurs courantes → correctifs rapides

Cette matrice vous évite de “tirer au hasard” : on corrige d’abord l’environnement serveur, ensuite les fichiers, puis la configuration applicative.

FAQ : changer d’hébergeur PrestaShop sans perte de données

Quand lancer la migration pour éviter du downtime (délai réaliste) ?

Lancez la migration en deux temps : (1) restauration sur un serveur cible en parallèle, (2) bascule du domaine une fois les tests validés. Le seul moment où vous figez l’écriture (maintenance) doit être le plus court possible : juste avant un dernier export de données, puis import immédiat côté cible.

Quelles données ne pas oublier d’exporter (check anti-oubli) ?

Au-delà du dump MySQL : le répertoire /img, /modules, /themes, /mails, les overrides, vos fichiers racine (.htaccess), ainsi que vos paramètres SMTP, tâches cron et réglages DNS du domaine. Sans cela, vous perdez souvent la présentation, des fonctionnalités, ou l’envoi des factures et e-mails transactionnels.

Que faire si la base dépasse la limite d’upload (limite taille / timeout) ?

Évitez l’import via navigateur si vous êtes limité : préférez un export/import via SSH (mysqldump + client mysql) ou un import phpMyAdmin en utilisant ses mécanismes prévus (upload directory, compression, etc.). La documentation phpMyAdmin liste précisément les méthodes d’import et les contournements pour gros fichiers. Documentation phpMyAdmin

Comment gérer le nom de domaine rapidement (sans casse SEO) ?

Préparez la zone DNS en amont : baissez le TTL si possible, reproduisez les enregistrements nécessaires (A/AAAA/CNAME, MX si e-mails, SPF/DKIM), puis basculez lorsque la boutique cible est validée. Après bascule, contrôlez HTTPS, redirections, canonicals, sitemap, et faites un tour complet du parcours d’achat.

Dois-je supprimer l’ancien serveur tout de suite (risque et retour arrière) ?

Non : gardez l’ancien hébergement quelques jours (ou au minimum l’accès) après bascule, le temps de confirmer : commandes, paiements, e-mails, jobs cron, et modules. Cette période sert de filet de sécurité si un détail a été oublié.

Action immédiate : avant d’envoyer votre demande de résiliation, faites un test de restauration complet (fichiers + base) sur un serveur de préproduction et validez un achat de bout en bout.