Checklist de migration et mise à niveau vers PrestaShop 9

Ce que nous ferions

Pour une boutique PrestaShop 1.7 ou 8 adaptée, avec des modules maintenus et peu de modifications, nous commencerions par tester la mise à jour d’une copie de préproduction. Pour une boutique 1.6, un thème non pris en charge ou de nombreuses modifications sur mesure, nous évaluerions généralement d’abord une installation PrestaShop 9 neuve avec une migration des données selon des correspondances définies. Une reconstruction est un parcours à évaluer, pas une obligation automatique pour toute boutique personnalisée : une intégration défaillante peut souvent être adaptée ou remplacée isolément, comme le montre l’exemple ci-dessous.

Le PrestaShop Upgrade Service commence par une vérification gratuite de votre version, de PHP, de l’hébergement, du thème et des modules, fournit un devis écrit à prix fixe avant les travaux et intervient en préproduction pendant que la boutique en ligne continue à prendre des commandes ; le passage depuis la version 1.6 est une migration dont le devis est plus élevé.

Avant de valider l’un ou l’autre parcours, demandez les constats de compatibilité, le périmètre des données, les contrôles d’acceptation et le plan de retour arrière.

Choisir une cible prise en charge et un parcours adapté à votre boutique

Une migration majeure de PrestaShop peut modifier PHP, les composants du framework, les pages d’administration, les thèmes et les points d’extension. Inventoriez précisément la boutique avant de choisir une mise à jour ou une reconstruction. Gardez une checklist d’acceptation écrite et un point de décision pour le retour arrière.

Au 26 octobre 2026, PrestaShop 9.2 est disponible. Choisissez une cible corrigée prise en charge par vos fournisseurs de paiement, livraison, thème et intégrations. Une boutique qui se charge encore peut néanmoins ne plus bénéficier de maintenance logicielle.

La maintenance officielle de PrestaShop 1.6 a pris fin le 30 juin 2019 ; les travaux bénévoles ultérieurs constituent une initiative distincte. Consultez l’avis de fin de maintenance et l’explication de la maintenance bénévole. La maintenance régulière de 1.7 a pris fin à la sortie de 9.0.

L’outil de première étape pour 1.6 n’est plus maintenu. Testez le parcours dans un environnement isolé et conservez un instantané à chaque étape. Une reconstruction propre est une option distincte, pas la preuve qu’une mise à jour par étapes est techniquement impossible. Vérifiez les parcours officiels d’Update Assistant.

Quel que soit le parcours évalué, ce sont le tunnel de commande, le traitement des commandes et la restauration en préproduction qui décident s’il est exploitable. Une copie qui démarre et affiche le catalogue n’a pas encore réussi l’évaluation.

La préparation réduit les risques, mais ne peut exclure ni les défauts ni les pannes d’infrastructure. Ne promettez pas une durée de mise à niveau, une indisponibilité ou une récupération du référencement fixes à partir d’un nombre de modules ou de la taille du catalogue, et ne choisissez pas un parcours sur la promesse d’une compatibilité universelle.

Exemple : conserver la boutique, remplacer l’obstacle

Supposons qu’une boutique PrestaShop 8 utilise un thème maintenu et des outils de catalogue fonctionnels, mais que sa connexion transporteur sur mesure échoue sur la cible envisagée. Demandez au développeur d’isoler cette connexion, d’établir ses besoins en données et en étiquettes, puis de tester une adaptation ou un remplacement en préproduction. Ce constat seul ne justifie pas de reconstruire tout le catalogue. À l’inverse, une boutique 1.6 avec un thème non pris en charge, des modifications directes du cœur et une connexion de stock non documentée nécessite une comparaison chiffrée des deux parcours avant le début des travaux.

Exigez le parcours choisi par écrit. Pour une mise à jour, il s’agit de la séquence par étapes indiquant la source, l’outil de mise à jour, la cible et l’environnement PHP de chaque étape, ainsi que le point de contrôle à partir duquel chaque étape peut être restaurée (voir la section sur la compatibilité PHP ci-dessous). Pour une installation neuve, il s’agit de la correspondance des données et de la procédure de transfert final (voir la section sur la boutique propre ci-dessous).

Identifier la version exécutée et les prérequis serveur

Lisez la version de la boutique exécutée dans le pied de page du back-office ou sous Paramètres avancés > Informations. Confirmez qu’il s’agit de la production et non d’une ancienne copie de préproduction. La version d’un module n’est pas celle de la boutique.

L’ancienne version 1.6 définit généralement _PS_VERSION_ dans config/settings.inc.php. PrestaShop 1.7/8 expose la version applicative dans app/AppKernel.php. Dans PrestaShop 9.1, cette classe délègue VERSION à src/Core/Version.php. Traitez un fichier copié comme un indice, pas comme une preuve de déploiement complet.

Dans du code où la boutique est déjà initialisée, utilisez _PS_VERSION_ et version_compare() pour les contrôles de compatibilité. Consignez la version PHP web et CLI, les extensions, limites, version de la base, thème actif et versions des modules.

php -v
php -m
php -i | rg 'memory_limit|max_execution_time'
# Run through the actual database connection:
# SELECT VERSION();

mysql --version indique le binaire client et pas nécessairement le serveur connecté. SELECT VERSION() identifie le serveur atteint par cette connexion. Le PHP CLI peut aussi différer du pool PHP-FPM qui sert la boutique.

PrestaShop 9 documente une recommandation mémoire de 512M par script. Prévoyez une marge supplémentaire mesurée pour les grosses mises à jour et les tâches PDF/import. Vérifiez CURL, DOM, Fileinfo, GD, Iconv, Intl, JSON, Mbstring, OpenSSL, PDO/MySQL, SimpleXML et Zip, ainsi que les paramètres d’exécution requis. Consultez les prérequis système.

Les versions de production distribuées en paquets contiennent les dépendances. Composer et les outils de compilation frontend sont nécessaires pour construire depuis les sources, pas pour chaque mise à jour par paquet.

Vérifiez séparément la compatibilité de la base et la maintenance du fournisseur. MySQL 8.0 est entré en Sustaining Support en avril 2026 ; n’en faites pas la cible automatique d’un nouveau déploiement. Choisissez une version maintenue compatible avec la boutique et la pile d’hébergement exactes, et testez son comportement SQL. Consultez les avis de cycle de vie MySQL.

Planifier la compatibilité PHP à chaque étape

Voici un tableau de compatibilité, pas une recommandation d’exposer publiquement d’anciennes versions PHP :

Utilisez l’ancienne matrice, la matrice PrestaShop 8 et les prérequis de 9.2 pour les versions source et cible exactes.

PHP 7.4 a atteint sa fin de vie le 28 novembre 2022 ; le support de sécurité de PHP 8.1 a pris fin le 31 décembre 2025. Vérifiez les branches PHP maintenues et la liste des fins de vie. La compatibilité ne rend pas un ancien environnement adapté à un nouveau déploiement public.

1. Consignez les prérequis PHP de la boutique source, de l’outil de mise à jour, des phases de mise à jour et de la cible, y compris l’environnement qui exécute les imports et les autres tâches planifiées.
2. Choisissez un parcours direct de 1.7 vers 9 uniquement si les versions exactes de l’Assistant et de la cible passent les contrôles préalables et si vous avez répété chaque phase avec un PHP compatible. La source et la cible n’ont pas de version PHP généralement prise en charge en commun ; ne contournez pas les prérequis et ne supposez pas un changement automatique d’environnement.
3. Si ce parcours ne permet pas une transition fiable, choisissez un parcours intermédiaire testé ou une migration propre.
4. Une étape facultative de 1.7.8 vers 8.2 peut s’exécuter sous PHP 7.4 ; 8.2 peut ensuite tourner sous PHP 8.1 pour une transition testée vers 9. Gardez ces environnements intermédiaires en fin de vie isolés et temporaires.
5. Une fois la cible atteinte, passez à la version PHP maintenue choisie, prise en charge par toute la pile, puis retestez.

Ne basculez pas une installation 1.7 en production vers n’importe quelle version de PHP 8 simplement parce que l’hébergeur la propose, ni pour découvrir si l’ancienne installation démarrera : vérifiez-le en préproduction. Gardez le web, le CLI et les tâches planifiées alignés. Ne revenez à l’ancienne version de PHP seule que si les fichiers applicatifs et la base restaurés sont eux aussi compatibles.

Auditer les modules, le code personnalisé et les intégrations

Établissez un inventaire depuis le Gestionnaire de modules et le système de fichiers déployé. Consignez nom du module, version, fournisseur, fonction, associations aux boutiques, configuration, propriété des données, tâches planifiées et points d’entrée externes. Pour chaque élément, choisissez une mise à jour compatible, un remplacement, une suppression ou un travail de migration explicite.

Priorisez paiement, tunnel de commande, transporteurs, taxes, facturation, ERP/PIM, stock, flux et email. Un catalogue qui se charge ne prouve pas que vous pouvez accepter et traiter des commandes.

• Lisez les plages PrestaShop et PHP déclarées par chaque module ainsi que ses contraintes de dépendances. Demandez aux fournisseurs du thème et des modules de confirmer la prise en charge de la cible et de la version PHP exactes, puis testez cette affirmation avec votre configuration.
• Examinez les overrides personnalisés, les modèles copiés, les contrôleurs sur mesure, les points d’entrée cron, les clients API, les URL de callback et les chemins d’administration codés en dur. Incluez les modifications faites directement dans les fichiers du cœur ou des modules.
• Vérifiez les API supprimées et les traductions sur la cible exacte, puis reproduisez chaque échec.
• Utilisez les liens/routes générés du back-office plutôt que de concaténer noms de répertoires et jetons.
• Testez les clés Webservice et les nouveaux clients/périmètres Admin API comme des intégrations distinctes.
• Désignez pour chaque intégration le responsable capable de fournir des identifiants de sandbox, des cas de test et un accompagnement au lancement.

PrestaShop 8 utilise Symfony 4.4 ; 9 utilise Symfony 6.4. Les pages d’administration modernes utilisent Twig et Symfony, tandis que les anciens contrôleurs conservent des voies de compatibilité. Ne supposez pas que le cycle de rendu ou l’override de modèle d’un ancien contrôleur contrôle une page migrée.

Tools::displayPrice() est supprimé dans 9. Utilisez la méthode formatPrice($amount, $currencyIsoCode) de la locale courante dans le contexte approprié. Examinez individuellement les anciens appels de traduction d’administration et méthodes de cycle de vie plutôt que d’imposer une recette universelle d’affectation dans le constructeur ou les propriétés.

Préférez les hooks, abonnés aux événements et décorations de services Symfony pris en charge lorsque cela convient. Les overrides de classes historiques existent encore pour les classes concernées, mais peuvent entrer en conflit et exigent une vérification des signatures. Auditez les paramètres des hooks, leur exécution et le balisage front-office sous le thème choisi. Consultez le guide de structure du code.

Mettez à jour les modules en préproduction dans un ordre maîtrisé. Sauvegardez les données avant toute désinstallation ou réinitialisation. Désactivez via le Gestionnaire de modules ou l’action prise en charge prestashop:module disable avec le contexte de boutique voulu. Mettre à jour uniquement module.active ne gère pas correctement les associations aux boutiques.

Questions à poser à votre développeur ou à votre agence

• Quels modules essentiels disposent d’une version compatible testée, et lesquels dépendent d’un développement non chiffré ou d’une nouvelle licence ?
• Quelles modifications n’existent que dans les fichiers déployés, sans figurer dans le paquet du fournisseur ou le dépôt source ?
• Qui testera les paiements, les transferts de stock, les étiquettes et les exports comptables avec les prestataires concernés ?
• Quel environnement d’exécution traite les requêtes des navigateurs, et lequel exécute les imports et les autres tâches planifiées ?
• Quelles preuves démontreront que le travail est terminé, et qui décide si un contrôle échoué bloque la mise en ligne ?

Conservez les réponses avec l’inventaire. Signalez tout fournisseur inconnu ou toute intégration non documentée comme une dépendance non résolue, avec une personne désignée pour l’examiner.

Si vous utilisez nos modules, Module Updates & Remote Assist affiche les versions installées et les mises à jour disponibles pour votre licence, et vous permet de choisir les installations et les mises à jour depuis le back-office. Il ne remplace pas la sauvegarde concordante de toute la boutique ni la répétition de restauration décrites ci-dessous.

Créer des sauvegardes concordantes et répéter en préproduction

Avant de changer de version, de schéma, de modules ou de thème, sauvegardez toute la boutique et la base de données correspondante, et notez comment revenir à l’installation d’origine. Incluez les fichiers cachés, les médias téléversés, les modules, leurs données, les personnalisations du thème et la configuration. Enregistrez la configuration du serveur web et de PHP-FPM, les paramètres SMTP, les identifiants de paiement, les URL de webhook, les tâches planifiées et les règles CDN dans un registre d’exploitation protégé.

L’exemple suivant suppose un login path MySQL protégé nommé shop-backup et un répertoire de sauvegarde restreint existant. Choisissez le vrai nom de base et les chemins avant utilisation.

mysqldump --login-path=shop-backup --single-transaction --quick prestashop > /srv/backups/prestashop-before-update.sql
tar -C /var/www -czf /srv/backups/prestashop-before-update-files.tar.gz html

Vérifiez le code de sortie des commandes, l’espace disponible et l’intégrité des archives. Un dump transactionnel repose sur des tables transactionnelles et l’absence de changements de schéma concurrents. Coordonnez un instantané fichiers/base et gelez les écritures si nécessaire. Ne mettez pas de mots de passe dans les arguments des commandes ou des archives publiques.

Dans Docker, incluez les vrais montages/volumes persistants et les données de base ou le dump logique. Consignez les versions d’image/environnement et la propriété numérique. Copier seulement l’image du conteneur ne préserve ni commandes réelles ni fichiers téléversés.

1. Gardez une sauvegarde hors serveur avec des identifiants distincts.
2. Préparez la destination isolée avant le démarrage de l’application copiée ou de toute tâche planifiée : sa propre base de données, son propre domaine et un accès restreint. Désactivez les vrais paiements, les emails sortants vers les clients, les webhooks de production et les écritures externes planifiées, ou dirigez-les vers des connexions sandbox et une boîte de réception de test.
3. Restaurez-y les fichiers et la base. Vérifiez que la copie utilise réellement la base et les destinations de préproduction, et pas seulement un autre domaine.
4. Vérifiez catalogue, nombre de commandes, images, connexions clients et factures représentatives.
5. Exécutez la mise à jour ou la migration prévue, y compris chaque transition PHP. Conservez les erreurs et consignez les correctifs.
6. Recommencez à partir d’un nouvel instantané concordant, afin que la procédure écrite contienne chaque étape nécessaire.
7. Répétez aussi la restauration : revenez à l’installation d’origine à partir des fichiers applicatifs, de la base, des médias, de la configuration et d’un PHP compatible concordants.

Si la répétition modifie la configuration à la main, consignez ces changements dans la procédure, pour que la restauration suivante ne se reconnecte pas discrètement à la production.

Des fichiers de sauvegarde sur le disque ne prouvent pas que la restauration fonctionne, et les nombres de lignes sont utiles mais ne constituent pas un test de restauration complet. Testez les processus réels et les accès. Protégez les données clients sensibles en préproduction. Le guide des sauvegardes couvre le processus de restauration dans son ensemble, et le guide de la préproduction privée aide à organiser la copie.

Exécuter le processus Update Assistant testé en préproduction

Utilisez une version actuelle en paquet d’Update Assistant compatible avec la boutique source, puis suivez ses contrôles préalables et le processus de la cible choisie. Les canaux et options actuels diffèrent des anciennes captures « 1-Click Upgrade ». Le choix de cible en ligne dépend aussi de l’environnement PHP.

Examinez les prérequis et les actions sur les modules avant de commencer. Distinguez la désactivation temporaire d’une désinstallation ou réinitialisation proposée, qui peut supprimer paramètres ou données métier. Préservez et migrez ces données avant d’accepter une action destructive. Consultez le processus de l’Assistant et l’aide propre à la version.

Pour voir comment une telle mise à jour de PrestaShop 8 vers 9 se déroule en pratique, et où elle coince sur une boutique en ligne, lisez l’étude de cas de 4eck Media (en allemand).

Répétez d’abord exactement ce processus en préproduction. En production, suivez la procédure écrite plutôt que d’improviser :

1. Planifiez la bascule répétée et désignez un opérateur, la checklist d’acceptation, une heure de décision de retour arrière et les échecs qui déclenchent ce retour arrière.
2. Sous Paramètres de la boutique > Paramètres généraux > Maintenance, réglez Activer la boutique sur Non. N’ajoutez que les IP de maintenance prévues et testez depuis une adresse extérieure.
3. Maîtrisez aussi les autres sources d’écriture : tâches cron, imports ERP, files d’attente et callbacks. Le mode maintenance seul ne gèle pas toutes les écritures externes.
4. Réalisez la sauvegarde concordante finale et consignez le dernier point de rapprochement des commandes et paiements, les callbacks de prestataires en attente et les imports en file d’attente (voir la section sur la bascule ci-dessous).
5. Exécutez le parcours Assistant testé et les transitions PHP. Surveillez la progression et les bons journaux PHP/applicatifs.
6. En cas d’échec, préservez les journaux et diagnostiquez l’étape exacte. Ne rafraîchissez pas la page, ne relancez pas l’opération et n’arrêtez pas un processus à l’aveugle.
7. Après réussite, reconstruisez les caches avec l’utilisateur d’exécution prévu et vérifiez la propriété des fichiers générés.
8. Réactivez les modules validés dans un ordre maîtrisé et exécutez les tests d’acceptation, y compris tunnel de commande, emails, callbacks, redirections et restrictions d’indexation, avant la réouverture.

Les commandes CLI de cache pour une cible compatible comprennent :

php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

Utilisez le bon binaire PHP et la bonne identité. Réparez l’accès aux chemins inscriptibles sélectionnés plutôt que d’attribuer récursivement tout le code de production à l’utilisateur web. Maintenez le gel des écritures jusqu’à la fin des contrôles.

Construire une boutique propre et établir la correspondance des données

Une cible neuve est utile pour remplacer un thème 1.6, refondre la boutique ou supprimer des personnalisations accumulées. Elle est construite et testée en préproduction pendant que l’ancienne boutique continue à vendre, si bien que seul le transfert final exige un gel des écritures. Elle crée aussi un projet de migration des données : les tables, mots de passe, documents et intégrations ne peuvent pas tous être copiés tels quels.

1. Installez la cible prise en charge dans une destination propre et protégée.
2. Choisissez un thème compatible et installez les modules compatibles requis.
3. Configurez langues, devises, taxes, transporteurs, paiements, messagerie et pages juridiques.
4. Établissez la correspondance des catégories, produits, déclinaisons, caractéristiques, attributs, images, stocks, prix et métadonnées SEO.
5. Établissez la correspondance des clients, adresses et groupes de clients, en testant la continuité des mots de passe ou le processus de réinitialisation nécessaire.
6. Établissez la correspondance des commandes historiques, factures, avoirs, paiements, numérotations de documents et relations nécessaires au service client et à la comptabilité.
7. Incluez les données métier propres aux modules, les associations aux boutiques et les références d’intégration, et pas seulement les tables principales du catalogue.
8. Vérifiez totaux, identifiants, associations, références d’images et accès côté client.

L’import CSV natif prend en charge certaines entités catalogue/client ; ce n’est pas une migration complète des commandes, paiements et documents historiques. Un service ou script de migration dédié nécessite une correspondance explicite des champs/relations et une transformation testée.

Exemple de correspondance pour la migration

Demandez comment une nouvelle exécution de la migration évite de dupliquer des enregistrements, et comment les enregistrements source modifiés ou supprimés sont traités lors du transfert final. La répétition n’a d’intérêt que si la même procédure peut être relancée sur les données finales.

Ne restaurez pas un choix de tables 1.6 sur un schéma 9 neuf. Les définitions de tables, lignes boutique/langue et identifiants diffèrent. Préservez références, relations et numérotation des documents légaux avec un processus tenant compte du schéma.

Les empreintes de mots de passe sont irréversibles. La conservation des connexions dépend de l’outil de migration, des anciennes clés et des algorithmes de hachage pris en charge par la cible ; copier les lignes clients ne garantit pas à lui seul la continuité des mots de passe. Testez de vrais comptes migrés sur la cible isolée. Si des réinitialisations sont nécessaires, utilisez le processus de réinitialisation de mot de passe pris en charge et convenez d’une communication claire avec les clients avant le lancement.

Le transfert final des changements intervenus depuis l’instantané de répétition a lieu lors de la bascule (voir ci-dessous) ; exigez sa procédure écrite en même temps que la correspondance des données.

Garder un thème compatible ou créer un thème enfant

Une mise à niveau du cœur n’impose pas systématiquement un passage à Hummingbird. Classic reste disponible dans les versions 9 concernées. Vous pouvez conserver un thème fondé sur Classic compatible et testé, ou prévoir une migration de thème séparée. Un thème 1.6 nécessite un remplacement ou un portage substantiel pour PrestaShop moderne.

Conservez un thème compatible lorsqu’il réussit les parcours nécessaires ; une mise à niveau du cœur ne justifie pas à elle seule une refonte. Traitez une refonte comme un chantier distinct, avec son propre périmètre et ses propres contrôles d’acceptation. Lorsque le thème actuel ne peut pas suivre vers la cible, le front-office est reconstruit quel que soit le parcours, ce qui plaide pour l’évaluation d’une boutique propre.

Hummingbird est devenu le thème par défaut des nouvelles installations 9.1. Il utilise Bootstrap 5.3 et des propriétés CSS personnalisées avec une compilation SCSS. Modifier les variables à l’exécution et effectuer des changements nécessitant une chaîne Sass/compilation sont des tâches différentes. Testez hooks, sélecteurs, mises en page responsive et balisage tiers.

Pour un thème acheté, demandez la compatibilité exacte avec la cible et PHP, le chemin de mise à jour, la couverture de la licence et la prise en charge des modules du tunnel de commande. Ne supposez pas qu’un thème fonctionne simplement parce que ses modèles affichent une page d’accueil. Pour un remplacement de thème, testez le catalogue, les positions des modules, les commandes sur mobile et le tunnel de commande avec vos vrais produits.

Une base complète de thème enfant

Cet exemple suppose Hummingbird installé et les commandes lancées depuis la racine de la boutique. Il crée le répertoire config, hérite des ressources parentes et enregistre explicitement une feuille de style enfant distincte.

mkdir -p themes/shop-child/config themes/shop-child/assets/css themes/shop-child/templates
cp themes/hummingbird/preview.png themes/shop-child/preview.png

Créez themes/shop-child/config/theme.yml :

parent: hummingbird
name: shop-child
display_name: Shop Child
version: 1.0.0
author:
  name: Shop Team
assets:
  use_parent_assets: true
  css:
    all:
      - id: shop-child-overrides
        path: assets/css/shop-overrides.css
        media: all
        priority: 1100

Créez themes/shop-child/assets/css/shop-overrides.css :

body { --shop-child-ready: 1; }

Activez le thème enfant via Apparence > Thème et logo. Reconstruisez les caches, ouvrez l’onglet Réseau du navigateur et confirmez que les ressources parentes et shop-overrides.css renvoient 200. Vérifiez la propriété personnalisée calculée --shop-child-ready sur le body. Cela vérifie le chargement de la feuille de style avant d’ajouter de vrais changements graphiques.

Ne copiez que les modèles à modifier en préservant leur chemin sous templates/. Comparez-les ensuite aux mises à jour du parent. Consultez la structure des thèmes enfants et le guide des thèmes enfants.

Préserver les URL, les paramètres d’indexation et les callbacks externes

Constituez l’inventaire des anciennes URL à partir du catalogue, des explorations, des sitemaps, des journaux et des données de la Search Console. Les exemples d’indexation de la Search Console ne sont pas un export complet de toutes les URL indexées. Incluez les modèles d’URL gérés par des modules, afin qu’un changement de route ne casse pas discrètement des adresses déjà utilisées par des clients ou des systèmes externes.

Préservez les URL fonctionnelles si possible. Pour les équivalents modifiés, utilisez des redirections permanentes testées comme 301 ou 308. Vérifiez le contenu final, les balises canoniques, liens internes, variantes linguistiques et flux. Ne redirigez pas des pages supprimées sans rapport vers l’accueil et ne promettez pas un délai fixe de récupération du référencement.

Utilisez un module sitemap comme gsitemap ou un autre générateur implémenté ; une mise à niveau du cœur ne crée pas à elle seule un processus complet de sitemap XML. Vérifiez que les URL canoniques aboutissent et sont indexables avant soumission. Retirez les restrictions noindex/authentification de préproduction uniquement sur la destination de production voulue.

Par exemple, ouvrez une ancienne adresse de produit dans chaque langue concernée et suivez sa redirection vers le produit équivalent en production. Examinez l’adresse canonique finale, les liens de langue et l’entrée du sitemap. Vérifiez que la destination de production n’a plus les restrictions d’accès ni le réglage noindex de la préproduction, tandis que la copie de préproduction reste protégée.

Mettez à jour les webhooks/IPN de paiement, les points d’accès ERP, les URL de flux, les emails, le suivi et les tâches planifiées si le domaine ou le chemin change. Testez des opérations authentifiées plutôt que de considérer un simple HTTP 200 comme la preuve qu’une tâche cron a accompli sa tâche métier.

Le guide des URL et redirections contient le plan de correspondance, les exemples serveur et les contrôles de lancement.

SEO Revolution prend en charge les processus de redirection et de sitemap ; consultez son aide du module pour la configuration.

Smart SEO Friendly URL Manager prend en charge les routes personnalisées et l’historique des URL ; consultez son aide du module pour conserver ou modifier ces modèles.

Tester la boutique avant réouverture

Exécutez ces contrôles à chaque répétition en préproduction, puis à nouveau sur la destination de lancement avant la réouverture. Pour chaque domaine, recueillez des preuves, pas une impression.

Vérifiez la capture du paiement dans le tableau de bord du prestataire, et pas seulement le statut de la commande. Confirmez les factures, emails et mouvements de stock attendus et évitez tout double débit involontaire. Utilisez les sandbox des prestataires lorsqu’elles existent ; convenez de toute transaction réelle contrôlée de faible montant et rapprochez-la, afin que les tests ne provoquent ni débits, ni expéditions, ni messages clients involontaires.

Transformer la checklist en paniers réalistes

• Utilisez un panier invité et celui d’un client existant, avec le prix de groupe, le bon de réduction et la destination de livraison concernés. Comparez les taxes et les frais de livraison avec la source dans les mêmes conditions.
• Testez des paniers de part et d’autre d’un seuil configuré de livraison gratuite ou de remise. Incluez des taux de taxe mixtes ou des cas de clients professionnels si la boutique les utilise.
• Effectuez un paiement de test, quittez le parcours avant de revenir à la boutique et vérifiez que le callback du prestataire produit toujours l’état de commande attendu. Répétez un callback avec les outils de test pris en charge par le prestataire et recherchez d’éventuels doublons de commandes, de messages ou de mouvements de stock.
• Effectuez un remboursement selon le processus convenu et vérifiez l’enregistrement du prestataire, l’avoir et le traitement du stock. Un changement d’état de commande seul ne démontre pas que l’argent a été remboursé.

Pour chaque cas, consignez le panier initial, le résultat attendu, le résultat observé et les preuves. Demandez au personnel chargé du traitement des commandes de valider son propre processus.

Conservez les journaux pendant les premiers cycles d’exploitation complets : imports planifiés, règlements, retours et pointes de trafic peuvent révéler des cas manqués au lancement. Comparez réussite des commandes, encaissements, files de service client et pages d’entrée principales à la référence.

Basculer en une seule fenêtre planifiée

Continuez à vendre pendant la préparation et la répétition ; seule la bascule finale nécessite une pause maîtrisée des écritures. Menez-la comme une procédure répétée à part entière, avec un opérateur, la checklist d’acceptation et les conditions d’échec qui déclenchent le retour arrière, convenus à l’avance.

1. Arrêtez le tunnel de commande de l’ancienne boutique et gelez les autres sources d’écriture : mode maintenance ainsi que tâches cron, imports, files d’attente et callbacks, comme aux étapes 2 et 3 du processus Update Assistant ci-dessus. Cela s’applique aussi à l’ancienne boutique dans le parcours par installation neuve.
2. Consignez le point de rapprochement : la dernière commande et le dernier événement de paiement rapprochés, les callbacks de prestataires en attente, les imports en file d’attente et les mouvements de stock. Convenez avec chaque prestataire de l’endroit où les événements différés seront reçus ou rejoués, et de la personne qui les vérifie, plutôt que de bloquer les callbacks à l’aveugle.
3. Réalisez la sauvegarde concordante finale.
4. Parcours par mise à jour : appliquez la procédure répétée à cet état final de la production, ou utilisez une méthode de transfert répétée séparément qui préserve toutes les modifications intermédiaires. Ne promouvez pas telle quelle une ancienne base de préproduction : il lui manque toutes les commandes prises depuis l’instantané de répétition.
5. Parcours par installation neuve : transférez le delta final depuis l’instantané de répétition (commandes, clients, stock, paiements et données de modules modifiées) et rapprochez-le de la source.
6. Effectuez les contrôles de la cible possibles avant la bascule. Basculez la destination de production selon la procédure répétée, puis vérifiez tunnel de commande, emails, callbacks des prestataires, redirections et réglages d’indexation via les routes de production avant de rouvrir les commandes. Gardez la copie de préproduction distincte protégée.
7. Si une ancienne installation distincte subsiste après la migration, gardez-la isolée et en lecture seule pour consultation autorisée. Pour une mise à jour sur place, conservez l’instantané concordant d’avant mise à jour et la procédure de restauration testée. Ne laissez accessible en écriture que le tunnel de commande de production choisi ; rouvrir les deux pour éviter le rapprochement crée deux flux de commandes concurrents.
8. Surveillez pendant les cycles d’import, de traitement des commandes et de paiement concernés.

Diagnostiquer les problèmes courants après mise à jour

Commencez par le premier contrôle sans risque : conservez les preuves et reproduisez le problème en préproduction protégée, avec l’environnement et les extensions prévus, avant de modifier la boutique en production.

• Page blanche ou erreur 500 : examinez d’abord les journaux du serveur web, de PHP-FPM et de PrestaShop et conservez l’exception. En préproduction protégée, activez temporairement le mode debug pour identifier l’exception, puis désactivez-le. Vérifiez les extensions, la mémoire, le code incompatible et les chemins inscriptibles.
• Échecs de réécriture : préservez les règles personnalisées et inspectez les modules Apache/AllowOverride ou les locations Nginx. Testez les changements de règles dans le contexte prévu ; supprimer .htaccess publiquement peut aussi supprimer des protections de sécurité.
• Conflit de modules : utilisez les actions de désactivation de modules prises en charge et isolez les changements sur la copie. N’exécutez pas une mise à jour SQL globale du champ active avec une liste supposée de modules natifs autorisés, et ne réinitialisez ni ne désinstallez de modules lors d’une mise à niveau en production sans sauvegarde, reproduction en préproduction et plan de retour arrière.
• Traductions manquantes : vérifiez noms de domaines, fichiers/catalogues de traduction, contexte langue/boutique et caches. Réinstaller n’est pas un correctif général des traductions et peut supprimer les données du module.
• CSS ou JavaScript obsolètes : vérifiez d’abord les URL des ressources, puis reconstruisez les caches de l’application et du thème et videz le cache CDN/navigateur concerné.
• Images manquantes : examinez les adresses, chemins et permissions des ressources avant de régénérer quoi que ce soit, puis régénérez si nécessaire uniquement les miniatures concernées. Vérifiez le CDN séparément.
• Connexion à l’administration : vérifiez l’URL, les cookies, HTTPS, l’état de l’employé, les journaux d’authentification et la distribution des emails de réinitialisation. Utilisez le processus intégré de réinitialisation du mot de passe des employés.

Le cœur PrestaShop utilise son service Crypto Hashing, notamment bcrypt et la vérification de l’ancien MD5. N’attribuez pas toute la gestion des mots de passe de la boutique au MigratingPasswordHasher de Symfony. L’authentification moderne du back-office et les cookies du front-office utilisent des mécanismes différents.

Ce cœur ne propose pas de commande standard de récupération prestashop:user:change-password. Évitez le SQL brut sur les mots de passe et les scripts publics de réinitialisation. Si l’email de réinitialisation échoue, réparez sa livraison ou utilisez une procédure administrative de récupération expressément prise en charge.

Pour un diagnostic détaillé, utilisez le guide de dépannage.

Restaurer en sécurité et transmettre le résultat

Définissez avant de commencer quel échec déclenche le retour arrière. Préservez les journaux et l’état en échec pour le diagnostic. Une restauration doit associer les fichiers, la base, l’environnement PHP, la configuration et les médias persistants concordants.

1. Gardez la boutique en maintenance et maîtrisez les écritures externes.
2. Vérifiez si le processus de restauration testé de l’Assistant peut utiliser la sauvegarde prévue d’avant mise à jour.
3. Pour une restauration manuelle, utilisez une destination propre et une base vide distincte.
4. Restaurez l’instantané complet concordant, y compris les fichiers cachés. Ne superposez pas une archive au code mis à niveau et ne supposez pas que rm -rf /var/www/html/* a supprimé les fichiers cachés.
5. Pointez l’environnement restauré vers sa base et le bon domaine/environnement d’exécution, réparez les permissions requises et reconstruisez les caches générés.
6. Rapprochez toutes les commandes, paiements ou événements externes acceptés après l’instantané avant de rouvrir. Restaurer la sauvegarde de la veille après avoir pris de nouvelles commandes exige un plan de rapprochement explicite : une restauration n’efface ni la transaction d’un prestataire ni une opération d’entrepôt.
7. Testez connexion, catalogue, commande, email et intégrations selon la checklist de restauration.

Un retour arrière de la base seule face aux nouveaux fichiers laisse une installation mélangée. Si PHP a changé, restaurez aussi les versions compatibles web et CLI. Gardez l’environnement en échec isolé jusqu’à disposer des journaux et données nécessaires à l’enquête.

Sans sauvegarde adéquate, demandez immédiatement à l’hébergeur les instantanés et leur rétention, vérifiez l’inventaire des sauvegardes de l’Assistant et évaluez la restauration à un instant donné si des journaux binaires existent. Une mise à jour échouée ne peut pas être annulée de façon sûre en copiant quelques anciens fichiers. Une récupération spécialisée ou une correction de l’installation mise à jour peut être nécessaire.

Après restauration, reproduisez l’étape défaillante en préproduction et corrigez-la avant de réessayer en production.

Décider qui doit réaliser la migration

Basez le choix entre réalisation interne et spécialiste sur la complexité réelle de la boutique, votre capacité à la restaurer et le coût d’une interruption. Demandez au développeur un inventaire écrit, une correspondance données/URL, un parcours testé en préproduction, des tests d’acceptation, un plan de retour arrière et une transmission de la surveillance. Fondez devis et estimations d’indisponibilité sur ce périmètre plutôt que sur des fourchettes génériques du marché.

Lors de la transmission, documentez les nouvelles versions, l’environnement d’exécution, les thèmes, les réglages modifiés, la propriété des identifiants, les tâches, les URL d’intégration et leurs responsables, les limites connues, les étapes de restauration des sauvegardes et la responsabilité du support. Vérifiez que l’affichage debug est désactivé en production et que les outils et accès temporaires ont été supprimés.