Périmètre réel d’une migration de domaine PrestaShop (et ce que le cœur ne gère pas)
Une migration de domaine PrestaShop (ex. ancienne-boutique.tld → nouvelle-boutique.tld) n’est pas une “simple” modification d’URL dans le back-office. Vous touchez simultanément à des couches qui ne se parlent pas bien : DNS/TTL, certificats TLS, redirections HTTP, configuration PrestaShop (multi-boutique incluse), endpoints d’intégrations (webhooks, retours paiement), délivrabilité e-mail, et parfois des flux externes (Google Merchant Center, marketplaces, ERP). Le cœur PrestaShop stocke le domaine à plusieurs endroits (table ps_shop_url, clés de config, caches Symfony et legacy), et ne “recalcule” pas automatiquement ce qui vit hors de la base.
Dans la vraie vie, le changement de domaine arrive rarement “seul” : rebranding, passage de .fr à .com, fusion de boutiques, ou refonte infra (nouveau reverse-proxy / nouveau CDN). Ce contexte compte, parce que vos intégrations et vos e-mails sont souvent verrouillés sur un nom d’hôte (validation TLS, whitelists, URL callbacks enregistrées dans des consoles tierces, etc.).
Pour cadrer le périmètre sans lister 40 tickets au dernier moment, une façon simple consiste à distinguer :
| Zone impactée | Ce que PrestaShop gère | Ce qu’il ne gère pas (à prévoir) |
|---|---|---|
| Domaine/SSL | ps_shop_url, génération .htaccess |
Certificat, chaîne TLS, HSTS, WAF/CDN, vhosts |
| SEO | URLs internes, (re)génération sitemap via modules | Google Search Console, stratégie de redirection globale, canonicals surchargés thème/modules |
| Paiement | Parcours checkout côté site | URL retour/notification chez le PSP, whitelists, webhooks, sandbox/prod |
| Moteur templates, config SMTP | SPF/DKIM/DMARC, réputation domaine, liens absolus dans templates surchargés | |
| Flux/ERP | Exports/imports et modules | Planifications CRON externes, endpoints consommés par des tiers, quotas/429 |
Contexte versions (à adapter, mais ne faites pas semblant) : les points ci-dessous concernent PrestaShop 8.1/8.2/9.x. Choisissez la version de PHP selon la matrice de compatibilité de la version exacte de PrestaShop et de vos modules : ne déduisez pas un minimum commun à ces différentes branches. Si vous migrez aussi de 1.7 vers 9, commencez par cadrer la trajectoire de prod (staging, gel des changements, fenêtres de bascule) : voir “Migration PrestaShop 1.7 vers PrestaShop 9 : méthodologie en production” : https://www.expertise-prestashop.fr/2026/10/14/migration-prestashop-1-7-vers-prestashop-9-methodologie-en-production/
Avant de toucher PrestaShop : baissez le TTL DNS (ex. 300s) 24–48h avant, et préparez l’infra HTTPS sur le nouveau domaine. Concrètement, vérifiez aussi que vous avez prévu toutes les variantes réellement utilisées : www/non-www, éventuels sous-domaines (ex. static. / api. / m.), et IPv4/IPv6 (A/AAAA). Si vous êtes sur Lightsail/VM classique, ne réinventez pas la roue côté DNS + Let’s Encrypt : DNS, nom de domaine et HTTPS Let’s Encrypt sur PrestaShop Lightsail. Enfin, gardez un plan de rollback : au minimum snapshot VM + dump DB + artefacts (thème/modules) + export de la configuration (variables d’env, secrets, jobs cron).
Basculer le domaine côté PrestaShop : ps_shop_url, configuration, cache, multi-boutique
Le chemin “propre” passe par le back-office : Paramètres de la boutique → Trafic & SEO → SEO & URLs (selon versions/menus), en modifiant domaine et domaine SSL, puis en régénérant le .htaccess. En pratique, sur des boutiques chargées en modules, ce flow est fragile : des modules injectent des URL absolues (assets, endpoints, webservices), et vous devrez nettoyer les caches au niveau Symfony (var/cache/) et legacy. Après changement, contrôlez que le front ne sert pas encore d’URL absolues sur l’ancien domaine (HTML, CSS, JS, e-mails, PDF).
Point important (souvent sous-estimé) : le couple domaine + “base URI” doit rester cohérent. Typiquement :
physical_urivaut/si la boutique est à la racine du vhost.physical_urivaut/boutique/si PrestaShop est installé dans un sous-répertoire.virtual_urisert surtout dans certains montages multiboutique et peut impacter la résolution d’URL.
Pour diagnostiquer “où est stocké le domaine”, le point central est ps_shop_url (préfixe à adapter). Vous y trouverez notamment domain, domain_ssl, physical_uri, virtual_uri. En multi-boutique, plusieurs lignes coexistent ; une mise à jour brutale sans filtrage par id_shop peut casser un shop secondaire.
-- Exemple : vérifier les URL par boutique
SELECT id_shop_url, id_shop, domain, domain_ssl, physical_uri, virtual_uri, main
FROM ps_shop_url
ORDER BY id_shop, main DESC;
Si vous devez corriger en SQL (cas d’urgence, ou BO inaccessible), faites-le de manière scopée, et idéalement pendant une fenêtre de maintenance. Exemple (à adapter) : ne mettez pas à jour “tout” sans comprendre quel id_shop_url est le main=1.
START TRANSACTION;
-- Exemple : ne corriger que le shop principal
UPDATE ps_shop_url
SET domain = 'nouvelle-boutique.tld',
domain_ssl = 'nouvelle-boutique.tld'
WHERE id_shop = 1 AND main = 1;
COMMIT;
En complément, faites une recherche ciblée dans la configuration : certains modules stockent des URLs complètes en base (webhooks sortants, URL d’API, URL d’assets). Une requête simple permet souvent d’attraper 80% des “restes” :
-- Détecter des valeurs qui contiennent l'ancien domaine dans la configuration
SELECT name, value
FROM ps_configuration
WHERE value LIKE '%ancienne-boutique.tld%';
Sur le terrain, une migration de domaine échoue souvent pour une raison bête : le cache. PrestaShop 8/9 mélange du cache Symfony et du cache “historique” (templates compilés selon setup). Procédure minimale (après bascule du domaine) :
- Purge
var/cache/(Symfony) :
# depuis la racine PrestaShop
php bin/console cache:clear --no-warmup
- Purge cache PrestaShop (BO) + cache Smarty si activé.
Deux points de vigilance “invisibles” :
- Reverse-proxy/CDN : changer le domaine dans PrestaShop ne purge ni le CDN ni Varnish. Si vous avez un cache frontal, vérifiez la clé de cache (Host header) et la politique de redirection
http→https. - Contenu dupliqué : pendant la transition, vous pouvez vous retrouver avec les deux domaines accessibles, donc deux versions indexables. En SEO, la migration de domaine implique une stratégie de canonical/hreflang/sitemap et surtout des 301 propres.
Pour la partie SEO (sitemaps, redirections, images), vous pouvez recroiser avec : modules SEO PrestaShop : sitemaps, redirections, images et performance et en multi-boutique : paramétrage SEO PrestaShop multiboutique pour éviter le contenu dupliqué
Référence HTTP utile : la RFC 9110 définit la redirection permanente 301 : “The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.” (RFC 9110, section 15.4.2) RFC 9110
Webhooks après migration de domaine : endpoints, signatures, retries, et pourquoi un 301 ne suffit pas
Définition opérationnelle : un webhook est un appel HTTP initié par un système tiers (PSP, ERP, marketplace) vers votre boutique (ou votre middleware) pour notifier un événement (paiement confirmé, commande expédiée, stock modifié). Après une migration de domaine PrestaShop, 3 cas typiques : (1) endpoints webhooks configurés chez le provider doivent être mis à jour, (2) endpoints gérés par un module PrestaShop pointent sur l’ancien domaine, (3) vous aviez un bus d’événements/middleware (ex. API interne) avec des secrets basés sur le domaine.
Un piège classique : “je mets un 301 depuis l’ancien domaine vers le nouveau, donc ça passe”. Non. Beaucoup de providers n’acceptent pas les redirections sur des requêtes POST (ou arrêtent au premier hop), et d’autres implémentent des politiques strictes (timeouts faibles, pas de suivi de redirection, ou validation de l’hôte attendu). Résultat : webhooks en échec silencieux, puis retries exponentiels ou désactivation du endpoint.
Une façon pragmatique d’éviter la casse consiste à faire un inventaire avant la bascule (un tableau suffit) :
| Intégration | Où se règle l’URL côté tiers | Type d’appel | Criticité | Test minimal post-bascule |
|---|---|---|---|---|
| Paiement (PSP) | Console PSP / module | POST webhook + redirect client | Très élevée | 1 paiement sandbox + 1 remboursement (si possible) |
| ERP/PIM | Portail connecteur / middleware | POST/PUT | Élevée | 1 commande “test” + 1 synchro stock |
| Transport | Module / API | GET/POST | Moyenne | 1 calcul transport + 1 tracking |
| Avis/CRM | Console du service | POST | Variable | Vérifier réception événement “commande créée” |
L’approche robuste est :
- maintenir l’ancien domaine en ligne temporairement (TLS valide) ;
- configurer explicitement le nouveau endpoint chez chaque provider ;
- prévoir une période où les deux endpoints acceptent les événements (idempotence obligatoire).
Idempotence (pratique) : si un provider renvoie le même événement 3 fois, vous devez être capable de ne pas créer 3 fois un paiement, une expédition ou une mise à jour de stock. La technique la plus simple est de stocker un identifiant d’événement (ou une empreinte) et de refuser les doublons sur une fenêtre de temps donnée.
Sur la partie observabilité, vous ne voulez pas “découvrir” la casse 48h après via une compta en retard. Mettez de la télémétrie (taux d’erreur HTTP, latence P95, retries, ratio événements reçus/attendus) et une healthcheck par intégration : observabilité, télémétrie et gestion de santé des connexions. Et si vous consommez ces webhooks de façon asynchrone (fort volume, appels externes, traitements lourds), externalisez le traitement via queue ; l’article sur la mise en place de Symfony Messenger en production (RabbitMQ/Redis/SQS) donne les patterns de base : configuration de Symfony Messenger avec RabbitMQ, Redis ou SQS en production
Enfin, pour le cas Stripe (fréquent sur PrestaShop), la documentation officielle “webhooks” est un bon point de départ pour cadrer tests, retries et sécurité : documentation Stripe sur les webhooks
Paiements : reconfigurer callbacks, IPN/webhooks, 3DS et vérifier la chaîne TLS
Quand vous changez de domaine, la partie paiement casse rarement “au moment du checkout” (l’iframe/redirect PSP continue), mais plutôt après : retour client (success/cancel), notification serveur-à-serveur (webhook), et pages de confirmation/commande.
Le point qui piège le plus : vous pouvez “voir” le paiement côté PSP (autorisé), mais la commande ne passe pas au bon statut parce que la notification serveur-à-serveur n’arrive plus. D’où l’intérêt de tester les 2 chemins : retour navigateur et webhook.
La checklist côté PSP est concrète :
- URL de retour (success/failure/cancel) si votre module les enregistre chez le PSP ;
- endpoint webhook / notification (Stripe, PayPal, Adyen, etc.) ;
- whitelists IP / firewall rules (si vous filtrez par IP côté WAF) ;
- certificats TLS et chaîne complète (fullchain) sur le nouveau domaine.
Sur PrestaShop, vérifiez aussi les effets de bord “web” : cookies et sessions sur un nouveau domaine, SameSite, redirections http→https, et HSTS. Un checkout qui boucle entre http et https ou entre ancien/nouveau domaine se diagnostique vite en regardant les headers Location, Set-Cookie, et les logs module. Quand ça arrive, ce n’est pas “un bug PrestaShop” : c’est un mauvais alignement domain_ssl, reverse proxy, et détection HTTPS (proxy headers).
Un mini-scénario réaliste : vous migrez sur une infra derrière un load balancer. Le LB termine TLS, et le backend parle en HTTP. Si le header X-Forwarded-Proto n’est pas correctement transmis/consommé, PrestaShop “croit” être en HTTP, génère des liens non-SSL, et vous obtenez une boucle de redirection pendant le paiement (ou un mixed-content qui casse un widget 3DS).
Ne basculez pas en prod sans valider un parcours complet (et pas uniquement avec un compte admin déjà logué) :
- ajout panier
- login (ou création compte)
- adresse
- transport
- paiement
- retour
- confirmation + e-mail de commande
La validation ne doit pas être “visuelle” ; elle doit être métrique. Suivez au minimum : taux d’abandon checkout, ratio payment authorization vs payment capture, et codes d’erreurs PSP. Pour instrumenter correctement (et éviter de confondre un pic d’erreurs 503 avec une casse paiement), appuyez-vous sur : monitoring PrestaShop : KPI e-commerce, paiements et prévention des erreurs 503. Et si vous êtes sur PayPal, surveillez explicitement les webhooks et le messaging (qui contient parfois des URL absolues ou des assets) : activer et personnaliser le messaging PayPal Pay Later
Enfin, ne négligez pas la sécurité applicative pendant la migration : certains modules exposent des endpoints (webhooks, retours) qui ressemblent à des “API”. Si vous avez aussi des intégrations via Webservice natif, vérifiez clés/permissions et rotation des secrets au passage : sécuriser les clés API et permissions du Webservice PrestaShop.
E-mails transactionnels : SMTP, SPF/DKIM/DMARC, templates et liens absolus
La migration de domaine a un impact direct sur la délivrabilité : le “From:” peut changer (ou pas), mais surtout les enregistrements DNS d’authentification doivent être cohérents avec le nouveau domaine. Dans les faits :
- SPF : autorisez vos serveurs d’envoi (ou votre ESP) sur le domaine utilisé pour l’enveloppe d’envoi ; si celui-ci change, mettez à jour son enregistrement SPF ;
- DKIM : publiez la clé publique (sélecteur) correspondant à l’ESP / MTA ;
- DMARC : définissez une policy, a minima
p=noneau démarrage, et surveillez les rapports.
Deux rappels utiles (car ils évitent des semaines de “pourquoi Gmail spam ?”) :
- Pour qu’un message passe DMARC, SPF ou DKIM doit être authentifié et aligné avec le domaine visible dans le
From:. L’alignement SPF porte sur le domaine de l’enveloppe d’envoi ; celui de DKIM porte sur le domained=de la signature. Si vous passez à un nouveau domaine “marketing”, mais que l’enveloppe d’envoi reste sur l’ancien, vous pouvez créer des échecs d’alignement SPF. - La migration de domaine peut affecter la réputation d’envoi auprès de certains filtres : l’approche la plus sûre est de démarrer avec DMARC en observation (
p=none), analyser les rapports, puis durcir progressivement.
Sur PrestaShop, la config d’envoi (SMTP vs PHP mail) ne suffit pas. Les templates e-mail et certains modules injectent des URL absolues (logo, assets, liens de tracking). Après bascule, vous devez tester : e-mail de commande, e-mail “mot de passe oublié”, e-mail “contact”, e-mails de relance si module dédié, et pièces jointes PDF (facture/BL) si elles embarquent des liens. Le cœur PrestaShop ne refait pas votre “branding e-mail” : si votre thème ou un module surcharge les templates, une migration de domaine PrestaShop peut laisser des URLs de l’ancien domaine en dur.
Pour éviter de “deviner”, faites un test reproductible : déclencher un e-mail en environnement de préprod, intercepter le SMTP (MailHog/Mailpit) et rechercher l’ancien domaine dans le source. Exemple simple en CLI :
# après avoir capturé un .eml ou le HTML
grep -R "ancienne-boutique.tld" -n var/ mails/ themes/ modules/Ajoutez aussi un contrôle côté base, car certains modules stockent des templates ou des paramètres HTML en DB :
-- Détecter l'ancien domaine dans des contenus multilingues fréquents
SELECT id_lang, value
FROM ps_configuration_lang
WHERE value LIKE '%ancienne-boutique.tld%';Côté DNS, n’oubliez pas le monde réel : un record SPF trop long, une clé DKIM mal copiée, ou un DMARC strict trop tôt peut vous faire “disparaître” chez Gmail/Outlook au moment où vous changez de marque/domaine. Utilisez des outils de validation (MXToolbox, dmarcian) et les consoles (Google Postmaster Tools) pour monitorer. Et opérationnellement, prévoyez une règle de contrôle simple post-bascule : sur les 24–72h suivant le changement, surveillez le taux d’échec SMTP et les ouvertures/clics (si vous suivez ces métriques) — c’est souvent là que se révèlent un DKIM manquant ou un mauvais “From”.
Flux (catalogues, marketplaces, ERP) et jobs : URLs publiques, CRON, et stabilité des intégrations
Dans “flux”, mettez tout ce qui consomme une URL publique : feed XML/CSV, endpoints de sync, webhooks sortants, exports planifiés. Après migration de domaine, la casse la plus fréquente vient des systèmes qui ont “bookmarké” l’URL : Google Merchant Center, Meta Catalog, comparateurs, affiliates, connecteurs ERP/PIM, scripts d’agence, etc. Même si vous avez des 301, certains crawlers/ingestors suivent mal les redirections sur des flux volumineux, ou appliquent des caches agressifs.
Vérifiez explicitement :
- URL des feeds produits/catégories (ex.
/modules/xxx/flux.xml) ; - endpoints de synchronisation (ex.
/api/...custom) ; - fichiers robots/sitemap si utilisés comme point d’entrée par un flux.
Bon réflexe : faites une liste “flux & jobs” avant migration, en incluant la fréquence et le propriétaire (qui reçoit l’alerte). Exemple de checklist rapide :
- CRON système (crontab) : quelles lignes appellent un domaine en URL ?
- Planificateur externe (Panel d’hébergement, GitOps, outil type Rundeck) : quels jobs pointent sur l’ancien domaine ?
- Tâches “cachées” dans des consoles tierces : fetch de flux programmé côté marketplace/comparateur.
Pour l’import/export interne, beaucoup de shops utilisent des CRON qui appellent des URLs du type https://domaine.tld/modules/monmodule/cron.php?token=.... Après migration, deux options solides : (1) mettre à jour les URLs dans le scheduler, (2) basculer vers des commandes CLI Symfony quand le module le permet (moins fragile, pas de dépendance DNS/TLS). Si vous automatisez des imports catalogue, recroisez avec les patterns d’industrialisation et les points de contrôle (idempotence, reprise sur erreur) : automatiser les imports de catalogues produits PrestaShop via flux XML, CSV et API
Dernier point : si vos flux et webhooks se croisent (ex. marketplace qui pousse des commandes et consomme des stocks), vous devez gérer les pics et les erreurs 429/quotas. Des redirections ou une latence accrue post-migration peuvent vous faire dépasser les quotas. Pour cadrer ce sujet proprement (headers, backoff, erreurs), vous avez une base ici : comprendre les quotas API, les headers de limite et les erreurs 429
Validation post-bascule : tests, instrumentation, et rollback sans mythologie
Une migration de domaine PrestaShop se valide en trois axes : fonctionnel, intégrations, infra. Fonctionnel : parcours d’achat complet, création compte, reset password, contact, génération PDF, recherche, pages CMS, et compatibilité mobile (les URLs absolues dans le thème sont une cause récurrente). Intégrations : réception de webhooks (paiements, ERP), émission de flux, et jobs planifiés. Infra : certificat TLS valide avec une chaîne complète, redirections 301 correctes, et absence de mixed-content.
Pour éviter les oublis, vous pouvez formaliser une “Definition of Done” simple, par exemple :
- Ancien domaine : renvoie 301 sur les pages principales (home, catégories, fiches produits, CMS), et ne sert plus de contenu indexable.
- Nouveau domaine : canonical cohérents, sitemap accessible, robots.txt cohérent.
- Paiement : au moins 1 paiement testé de bout en bout + confirmation commande + e-mail reçu.
- Webhooks : endpoints mis à jour côté providers + taux d’erreur stable (pas de 4xx/5xx anormaux).
- E-mail : SPF/DKIM/DMARC publiés et contrôlés, pas de liens sur l’ancien domaine dans les templates.
Évitez les validations “à l’œil” : automatisez un minimum. Exemple : un script qui vérifie les statuts HTTP clés, les redirections, et la présence d’anciens domaines dans le HTML.
set -e
OLD="ancienne-boutique.tld"
NEW="nouvelle-boutique.tld"
curl -sS -I "https://$OLD/" | egrep -i "^HTTP/|^location:" || true
curl -sS -I "https://$NEW/" | egrep -i "^HTTP/|^strict-transport-security:" || true
curl -sS "https://$NEW/" | grep -F "$OLD" && echo "Ancien domaine détecté dans le HTML" && exit 1 || trueComplétez avec 2 contrôles très rentables :
- vérifier que les assets (CSS/JS/images) ne chargent pas en
http://(mixed-content) ; - vérifier que les pages clés renvoient bien sur le nouveau domaine sans chaîne de redirections (ex. 301 → 302 → 200), car certains navigateurs/robots et certains PSP n’aiment pas les cascades.
Enfin, prévoyez le pire : si la perf s’effondre après la bascule (cache froid, OPcache reset, CDN mal réglé), vous devez savoir diagnostiquer vite. D’un côté, les symptômes (TTFB, 503, saturation PHP-FPM) : diagnostiquer un PrestaShop lent : TTFB, bots et optimisation serveur et diagnostiquer une erreur HTTP 503 avec PHP et les logs Apache/LiteSpeed. De l’autre, gardez un rollback simple : réactiver l’ancien vhost, remettre l’ancien domaine en primaire, et rétablir les enregistrements DNS si la fenêtre le permet.
Un repère utile côté e-commerce : la performance perçue n’est pas “cosmétique”. Google (SOASTA/Think with Google, 2017) a popularisé le fait que les délais de chargement sur mobile corrèlent fortement avec l’abandon ; une bascule de domaine qui dégrade TTFB/ressources (caches froids, mauvais CDN) peut donc se voir directement dans le taux de conversion. D’où l’intérêt d’alerter sur les erreurs (4xx/5xx) et sur les métriques de latence dès la bascule.
La migration de domaine n’est “réussie” que quand vous avez prouvé que vous savez revenir en arrière sans corruption de commandes ni perte de paiements, et que vos intégrations (webhooks, flux, e-mails) continuent de fonctionner sans dépendre d’une redirection “chanceuse”.
