Migration vers PrestaShop 9 : Guide complet de mise à jour

Pourquoi passer à PrestaShop 9

PrestaShop 9 représente le plus grand changement architectural depuis le passage de la version 1.6 à la 1.7. Ce n’est pas un simple changement de numéro de version — c’est une modernisation fondamentale de la plateforme. Si vous utilisez PrestaShop 1.7 ou 8.x, la question n’est pas de savoir si vous devez migrer, mais quand et comment le faire correctement.

Voici ce que PrestaShop 9 apporte :

Symfony 6.4 LTS sous le capot

PrestaShop 9 passe de Symfony 4.4 (PS 8.x) à Symfony 6.4 LTS. Il s’agit d’une version avec support à long terme, ce qui signifie que vous bénéficiez de correctifs de sécurité et de corrections de bugs jusqu’en novembre 2027. La mise à jour Symfony apporte une injection de dépendances moderne, un routage amélioré, une meilleure gestion des erreurs et un cycle de requêtes nettement plus rapide.

Pour les propriétaires de boutiques, cela signifie une base plus stable et plus sécurisée. Pour les développeurs, cela signifie l’accès à des composants et des patterns Symfony modernes autour desquels l’écosystème PHP s’est standardisé.

PHP 8.2+ requis

PrestaShop 9 nécessite PHP 8.2 au minimum, avec un support complet de PHP 8.3. Ce n’est pas arbitraire — PHP 8.2+ apporte les classes readonly, les fibers, un système de types amélioré et des gains de performance significatifs. Les benchmarks montrent une exécution 5 à 15 % plus rapide par rapport à PHP 7.4, avec une consommation mémoire réduite sur toute la ligne.

Si vous êtes encore sous PHP 7.4 ou 8.0, la seule mise à jour vers PHP 8.2+ rendra votre boutique sensiblement plus rapide — même avant de toucher à PrestaShop.

Twig partout dans l’administration

Le back office a terminé sa migration de Smarty vers Twig. Chaque page d’administration fonctionne désormais avec des templates Twig, ce qui signifie un rendu plus rapide, une meilleure sécurité (avec l’échappement automatique des sorties) et un moteur de templates réellement maintenu et bien documenté. Les anciens contrôleurs d’administration fonctionnent toujours grâce à une couche de compatibilité, mais la direction est claire : Twig est le présent et l’avenir.

Hummingbird comme thème par défaut

Le thème Classic est remplacé par Hummingbird comme thème par défaut du front office. Hummingbird est construit sur Bootstrap 5.3, utilise des propriétés CSS personnalisées modernes et est nettement plus léger que Classic. Il est conçu pour la performance avant tout — des fichiers CSS plus petits, moins de JavaScript et de meilleurs scores Core Web Vitals dès l’installation.

Améliorations de la sécurité

Symfony 6.4 apporte un composant de sécurité entièrement revu. Le hachage des mots de passe utilise des algorithmes modernes (bcrypt/argon2), la protection CSRF est plus robuste et le système d’authentification repose sur le bundle de sécurité Symfony plutôt que sur l’approche legacy basée sur les cookies de PrestaShop. Les vulnérabilités d’injection SQL et de XSS dans les chemins de code legacy ont été systématiquement éliminées.

PrestaShop 9 n’est pas une mise à jour cosmétique. Il change le fonctionnement de la plateforme en profondeur. C’est exactement pourquoi vous devez aborder la migration de manière méthodique — la récompense est une boutique plus rapide, plus sécurisée et plus facile à maintenir, mais uniquement si vous effectuez la migration correctement.

Avant de commencer : liste de vérification des prérequis

Ne touchez pas à votre boutique en production tant que vous n’avez pas vérifié chaque élément de cette liste. Négliger les prérequis est la cause numéro un des mises à jour échouées.

Configuration serveur requise

• PHP 8.2 ou 8.3 — vérifiez avec php -v sur votre serveur. PHP 8.1 ne fonctionnera PAS.
• MySQL 8.0+ ou MariaDB 10.4+ — vérifiez avec mysql --version. MySQL 5.7 n’est plus supporté.
• Extensions PHP requises : intl, gd, curl, zip, mbstring, openssl, pdo_mysql, fileinfo, dom, json
• Composer 2.x — nécessaire pour la gestion des dépendances lors de la mise à jour
• Au moins 256 Mo pour memory_limit en PHP — le processus de mise à jour est gourmand en mémoire
• max_execution_time d’au moins 600 secondes — les grandes boutiques ont besoin de temps pour les migrations de base de données

Pour vérifier rapidement votre configuration PHP :

# Check PHP version
php -v

# Check loaded extensions
php -m | grep -E "(intl|gd|curl|zip|mbstring|openssl|pdo_mysql)"

# Check memory limit and execution time
php -i | grep -E "(memory_limit|max_execution_time)"

# Check MySQL version
mysql --version

Prérequis de version PrestaShop

• Vous devez d’abord être sur PrestaShop 8.1 ou 8.2. Les mises à jour directes depuis 1.7.x ou 1.6.x vers 9.x ne sont pas supportées.
• Si vous êtes sur PS 1.7.x, passez d’abord à la version 8.2, stabilisez, puis passez à la 9.x.
• Si vous êtes sur PS 1.6.x — arrêtez-vous. Vous avez besoin d’une reconstruction complète, pas d’une mise à jour. Consultez la section « Installation propre » ci-dessous.

Audit de compatibilité des modules

C’est là que la plupart des mises à jour échouent. Avant de procéder à la mise à jour, vous devez savoir quels modules sont compatibles PS9 et lesquels ne le sont pas.

1. Faites une liste complète de chaque module installé (Back Office ? Modules ? Gestionnaire de modules)
2. Pour chaque module tiers, contactez le fournisseur et demandez : « La version X.Y est-elle compatible avec PrestaShop 9 ? »
3. Pour tout module dont la compatibilité n’est pas confirmée, vous avez besoin d’un plan : le mettre à jour, le remplacer ou le supprimer
4. Portez une attention particulière aux modules de paiement — une passerelle de paiement incompatible signifie zéro revenu

Ne supposez pas qu’un module est compatible parce qu’il « fonctionnait sur PS 8 ». PrestaShop 9 supprime des API et modifie des comportements fondamentaux. Un module qui fonctionnait parfaitement sur 8.2 peut planter sur 9.0 parce qu’il appelle une fonction qui n’existe plus.

Compatibilité du thème

• Si vous utilisez le thème Classic par défaut, vous devrez passer à Hummingbird ou à un thème tiers compatible PS9
• Si vous utilisez un thème acheté, vérifiez la compatibilité PS9 auprès du développeur du thème
• Les thèmes personnalisés basés sur Classic nécessiteront un travail de refonte important — la structure des templates a changé
• Les thèmes enfants Hummingbird sont la voie recommandée

Timing commercial

• Ne faites jamais de mise à jour pendant les périodes de forte vente (Black Friday, Noël, promotions majeures)
• Planifiez la mise à jour pendant votre période de trafic la plus faible — généralement en milieu de semaine, tôt le matin
• Prévoyez au moins 48 heures de surveillance après la mise à jour avant votre prochain pic de trafic
• Ayez un plan de restauration prêt (détaillé ci-dessous)

Sauvegardez tout en premier

Ce n’est pas optionnel. Ce n’est pas « recommandé ». C’est l’étape la plus importante de toutes. Si votre mise à jour échoue et que vous n’avez pas de sauvegarde, vous perdez votre boutique. Point final.

Sauvegarde de la base de données

La base de données contient tout ce qui compte — produits, clients, commandes, configurations, paramètres des modules. Sauvegardez-la avec mysqldump :

# Standard mysqldump � works on any server
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

# If your database is large (>1GB), add compression
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop | gzip > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql.gz

Si votre PrestaShop fonctionne sous Docker :

# Replace 'my-shop-db' with your actual database container name
docker exec my-shop-db mysqldump -u root -p'YOUR_PASSWORD' --single-transaction --quick prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

Explication des options :

• --single-transaction — prend un instantané cohérent sans verrouiller les tables (essentiel pour InnoDB)
• --quick — récupère les lignes une par une au lieu de les mettre en mémoire tampon (indispensable pour les grandes tables)
• --lock-tables=false — évite de verrouiller les tables pendant le dump afin que votre boutique reste en ligne

Vérifiez que votre sauvegarde fonctionne en l’important dans une base de données de test :

# Create a test database and import the backup
mysql -u root -p -e "CREATE DATABASE prestashop_backup_test;"
mysql -u root -p prestashop_backup_test < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# Check that it imported correctly
mysql -u root -p prestashop_backup_test -e "SELECT COUNT(*) FROM ps_product; SELECT COUNT(*) FROM ps_orders;"

# Clean up
mysql -u root -p -e "DROP DATABASE prestashop_backup_test;"

Sauvegarde des fichiers

Sauvegardez l’intégralité du répertoire PrestaShop — tous les fichiers PHP, thèmes, modules, images téléchargées, absolument tout :

# Full file backup with tar
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /var/www/html/

# If you want to exclude cache and logs (they're regenerated anyway)
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz \
  --exclude='var/cache' \
  --exclude='var/logs' \
  /var/www/html/

Pour les boutiques basées sur Docker, sauvegardez le volume monté :

tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /path/to/docker/html/

Stockez vos sauvegardes dans au moins deux emplacements — le serveur lui-même ET un emplacement externe (votre machine locale, un stockage cloud ou un serveur différent). Une sauvegarde qui n’existe que sur le même disque que votre boutique n’est pas une vraie sauvegarde.

Notes de configuration

Avant de commencer, documentez ces paramètres (vous en aurez besoin si vous devez tout reconfigurer) :

• Votre fichier app/config/parameters.php (identifiants de base de données, configuration du mailer, clé de cookie)
• Votre fichier .htaccess (surtout si vous avez ajouté des règles de réécriture personnalisées)
• La configuration SMTP/email depuis le back office
• Les clés API et paramètres des passerelles de paiement
• Les configurations des tâches cron
• Toute configuration serveur personnalisée (règles Nginx, paramètres du pool PHP-FPM)

Prenez des captures d’écran des pages de paramètres critiques du back office. Quand quelque chose tourne mal pendant la mise à jour, avoir une référence visuelle de « ce à quoi cela ressemblait avant » est inestimable.

Processus de mise à jour étape par étape

Il existe deux chemins légitimes vers PrestaShop 9 : la mise à jour sur place à l’aide du module officiel, ou une installation propre avec migration des données. Chacun a sa place.

Approche 1 : Module de mise à jour automatique (1-Click Upgrade)

Le chemin de mise à jour officiel utilise le module autoupgrade (également appelé « 1-Click Upgrade »). Ce module gère le remplacement des fichiers, la migration de la base de données et le nettoyage post-mise à jour de manière automatique.

Préparation

1. Installez ou mettez à jour le module 1-Click Upgrade dans sa dernière version depuis le PrestaShop Marketplace
2. Allez dans Back Office ? Modules ? 1-Click Upgrade
3. Le module affichera votre version actuelle et les cibles de mise à jour disponibles
4. Lancez la liste de vérification pré-mise à jour — le module vérifiera la compatibilité de votre serveur et signalera les problèmes potentiels

Activez le mode maintenance

# Or do it from the back office: Shop Parameters ? General ? Maintenance ? Enable
# Make sure to whitelist your own IP address

C’est indispensable. Vous ne voulez pas que des clients passent des commandes pendant la migration de la base de données.

Lancez la mise à jour

1. Dans le module 1-Click Upgrade, sélectionnez votre version cible (PrestaShop 9.x)
2. Choisissez « Mise à jour majeure » comme canal de mise à jour
3. Vérifiez les options de mise à jour :
   • Sauvegarder les fichiers et la base de données — activez cette option (ceinture et bretelles, même si vous avez déjà sauvegardé manuellement)
   • Désactiver les modules non natifs — activez cette option pour éviter les conflits de modules pendant la mise à jour
   • Régénérer les modèles d’email — activez si vous ne les avez pas personnalisés
4. Cliquez sur « Mettre à jour PrestaShop maintenant »
5. Ne fermez PAS l’onglet du navigateur, ne naviguez PAS ailleurs — attendez que le processus se termine

La mise à jour peut prendre de 5 minutes (petite boutique) à 30 minutes ou plus (grand catalogue, nombreux modules). Vous verrez un journal de progression montrant chaque étape.

Après la mise à jour

# Clear all caches � this is not optional
rm -rf var/cache/*

# If using CLI (recommended):
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

# Fix file permissions
chown -R www-data:www-data /var/www/html/var/
chown -R www-data:www-data /var/www/html/themes/
chmod -R 755 /var/www/html/var/

Réactivez les modules un par un

Si vous avez choisi de désactiver les modules non natifs pendant la mise à jour, ne les activez pas tous en même temps. Activez-les un par un :

1. Activez le module
2. Vérifiez le front office et le back office à la recherche d’erreurs
3. Si tout fonctionne, passez au module suivant
4. Si cela casse quelque chose, désactivez-le et contactez le fournisseur du module

Cette approche méthodique vous indique exactement quel module a causé un problème, plutôt que de contempler une boutique cassée avec 30 modules activés sans savoir lequel est le coupable.

Approche 2 : Installation propre + migration des données

Parfois, le chemin le plus propre est de repartir de zéro. Installez PrestaShop 9 depuis le début et migrez vos données dedans. Cette approche demande plus de travail mais vous donne une installation vierge sans aucun héritage technique.

Quand choisir l’installation propre

• Vous passez de PS 1.6.x (la mise à jour sur place n’est pas supportée pour des sauts aussi importants)
• Votre boutique actuelle accumule des années de surcharges, de correctifs et de tables de modules abandonnés
• Vous souhaitez de toute façon changer de thème
• Votre base de données est devenue enflée par les paniers abandonnés, les anciens journaux et les données orphelines
• Des tentatives de mise à jour précédentes ont échoué

Le processus

1. Installez PrestaShop 9 de zéro dans un nouveau répertoire ou sur un nouveau serveur
2. Configurez votre thème (Hummingbird ou un thème compatible PS9)
3. Installez vos modules (uniquement les versions compatibles PS9)
4. Migrez vos données en utilisant :
   • L’import CSV de PrestaShop pour les produits, catégories et clients
   • Une migration directe de la base de données via des scripts SQL personnalisés
   • Des outils de migration tiers
5. Reconfigurez les passerelles de paiement, la livraison, les taxes et les emails
6. Testez tout sur la nouvelle installation
7. Changez le DNS ou basculez la racine du document quand vous êtes prêt

Migration des données via import CSV

L’outil d’import intégré de PrestaShop (Back Office ? Paramètres avancés ? Import) gère :

• Les catégories
• Les produits (avec déclinaisons, images, caractéristiques et stock)
• Les clients
• Les adresses
• Les fabricants et fournisseurs

Exportez depuis votre ancienne boutique, nettoyez les fichiers CSV et importez dans la nouvelle. C’est fastidieux pour les grands catalogues mais donne le résultat le plus propre.

Migration des données via SQL

Pour les développeurs expérimentés, la migration SQL directe est plus rapide pour les grands volumes de données :

# Export specific tables from old database
mysqldump -u root -p old_prestashop \
  ps_product ps_product_lang ps_product_shop \
  ps_category ps_category_lang ps_category_shop \
  ps_customer ps_address \
  ps_image ps_image_lang ps_image_shop \
  ps_stock_available \
  > ~/migration_data.sql

# You'll need to review and adjust the SQL for schema changes between versions
# Column names, table structures, and foreign keys may differ

La migration SQL nécessite une connaissance approfondie du schéma de base de données de PrestaShop. Si vous n’êtes pas à l’aise avec l’écriture et le débogage de requêtes SQL complexes, utilisez la méthode d’import CSV ou engagez un développeur. Une migration SQL bâclée peut corrompre vos données de manière extrêmement difficile à réparer.

Quelle approche est la meilleure ?

Pour la plupart des propriétaires de boutiques sous PS 8.x avec un nombre raisonnable de modules bien maintenus, la mise à jour automatique est le bon choix. L’installation propre a du sens lorsque vous venez d’une très ancienne version ou que vous souhaitez profiter de l’occasion pour faire le ménage.

Compatibilité des modules : ce qui casse dans PrestaShop 9

Cette section s’adresse aux développeurs et aux propriétaires de boutiques techniquement curieux. Comprendre ce qui a changé vous aide à évaluer si vos modules survivront à la mise à jour.

Templates Smarty supprimés de l’administration

C’est le changement le plus important. Dans PS 8.x, les anciens contrôleurs d’administration pouvaient encore utiliser des templates Smarty (fichiers .tpl) pour leurs pages de back office. Dans PS 9, l’administration est entièrement basée sur Twig. Les anciens contrôleurs sont encapsulés par un LegacyController Symfony qui rend leur sortie via Twig.

Ce que cela signifie en pratique :

• Les modules avec des pages d’administration personnalisées utilisant AdminController + Smarty fonctionnent toujours, mais ils sont rendus à l’intérieur du nouveau layout Twig via une couche de compatibilité
• Les surcharges de templates d’administration (fichiers dans override/controllers/admin/templates/) peuvent ne pas fonctionner comme prévu
• Les variables Smarty assignées dans initContent() peuvent être perdues car LegacyController encapsule le rendu différemment — la variable Smarty content doit être explicitement réassignée
• La méthode display() de AdminController n’est plus appelée par PS 9 — LegacyController la contourne entièrement

Changements du système de surcharges

PrestaShop décourage les surcharges depuis PS 1.7, et PS 9 renforce encore les restrictions :

• Les surcharges de classes du cœur fonctionnent encore techniquement mais sont de plus en plus fragiles à mesure que le code principal migre vers des services Symfony
• Les surcharges de contrôleurs ne sont pas fiables — la couche de routage Symfony peut ne pas les charger comme prévu
• Les surcharges de templates dans les répertoires override/ sont dépréciées pour les pages d’administration
• L’approche recommandée est désormais les hooks, les décorateurs Symfony et les event subscribers

Si vous avez des modules qui dépendent fortement des surcharges, ce sont les plus susceptibles de casser lors de la mise à jour. Vérifiez le répertoire override/ dans le dossier de chaque module.

Changements des hooks

PrestaShop 9 ajoute de nouveaux hooks et modifie certains existants :

• Plusieurs hooks legacy dans la zone d’administration sont supprimés ou renommés
• De nouveaux hooks sont disponibles pour les pages d’administration basées sur Symfony
• Les hooks du front office restent largement compatibles (Hummingbird utilise les mêmes points de hook que Classic)
• L’ordre d’exécution des hooks peut changer dans certains cas — si votre module dépend d’être appelé avant ou après un autre hook, testez-le

Dépréciations des contrôleurs legacy

Plusieurs patterns de contrôleurs d’administration qui fonctionnaient dans PS 8.x se comportent différemment dans PS 9 :

• $this->l() (la fonction de traduction) est supprimée des contrôleurs d’administration — utilisez $this->module->l('string', 'ControllerClassName') à la place
• Tools::displayPrice() est supprimée — utilisez Context::getContext()->getCurrentLocale()->formatPrice($amount, $currencyIsoCode)
• Les propriétés $this->meta_title, $this->fields_list et $this->bulk_actions du contrôleur d’administration doivent être assignées APRÈS l’appel à parent::__construct() car la référence au module n’est pas disponible avant
• Le répertoire d’administration est désormais backoffice/ par défaut (et non admin-dev ou une chaîne aléatoire) — les chemins d’administration codés en dur ne fonctionneront plus

Comment vérifier si vos modules sont prêts pour PS9

Pour chaque module installé :

1. Vérifiez le site du fournisseur — cherchez des déclarations explicites de compatibilité PS 9
2. Vérifiez les surcharges — regardez dans modules/yourmodule/override/. Tout fichier présent est un signal d’alerte.
3. Vérifiez les appels à des fonctions dépréciées — recherchez dans les fichiers PHP du module :
   • Tools::displayPrice(
   • $this->l( dans les fichiers de contrôleurs d’administration
   • Des classes AdminController avec des méthodes display() complexes
   • Des chemins de répertoire d’administration codés en dur
4. Vérifiez le fichier config.xml ou le fichier PHP principal du module pour le paramètre ps_versions_compliancy — inclut-il la version 9.x ?

# Quick command to find potential PS9 issues in a module
# Run this from inside the module directory

# Check for overrides
find override/ -type f 2>/dev/null && echo "WARNING: Module uses overrides"

# Check for removed functions
grep -rn "Tools::displayPrice" *.php controllers/ classes/ 2>/dev/null
grep -rn '$this->l(' controllers/admin/ 2>/dev/null

# Check version compatibility declaration
grep -A2 "ps_versions_compliancy" *.php

Migration du thème : Hummingbird est désormais le thème par défaut

PrestaShop 9 est livré avec Hummingbird comme thème par défaut, remplaçant Classic. Si vous utilisez Classic ou un thème basé sur Classic, vous avez besoin d’un plan de migration.

Ce qui a changé dans Hummingbird

• Bootstrap 5.3 remplace Bootstrap 4 — les noms de classes, le système de grille et les classes utilitaires ont changé
• Les propriétés CSS personnalisées sont largement utilisées pour la thématisation — les couleurs, espacements et typographies sont configurés via des variables CSS plutôt que des variables SCSS
• Moins de JavaScript — Hummingbird s’appuie davantage sur les fonctionnalités natives du navigateur et moins sur les plugins jQuery
• Système de build moderne — compilation des assets basée sur Webpack avec un tree shaking efficace
• Conception responsive-first — la mise en page mobile est la base, le bureau est l’amélioration (contrairement à Classic qui était desktop-first)

Si vous utilisez le thème Classic

Le thème Classic n’est pas inclus dans PS 9. Vos options sont :

1. Passer à Hummingbird — le chemin le plus simple. Créez un thème enfant pour vos personnalisations.
2. Acheter un thème compatible PS9 — de nombreux fournisseurs de thèmes ont publié des versions PS9.
3. Porter vos personnalisations Classic vers un thème enfant Hummingbird — cela nécessite un travail de développement frontend mais donne le meilleur résultat à long terme.

Créer un thème enfant Hummingbird

Un thème enfant vous permet de personnaliser Hummingbird sans modifier les fichiers du thème principal (afin que vos modifications survivent aux mises à jour du thème) :

# Create child theme directory structure
mkdir -p themes/my-child-theme/assets/css
mkdir -p themes/my-child-theme/templates

Créez le fichier themes/my-child-theme/config/theme.yml :

parent: hummingbird
name: my-child-theme
display_name: My Custom Theme
version: 1.0.0
author:
  name: Your Name

Ajoutez vos styles personnalisés dans themes/my-child-theme/assets/css/custom.css. Hummingbird charge automatiquement le fichier custom.css des thèmes enfants avec la priorité la plus basse (chargé en dernier), de sorte que vos styles remplaceront ceux du thème parent.

Pour surcharger un template spécifique, copiez-le depuis themes/hummingbird/templates/ vers le même chemin relatif dans votre thème enfant. Ne copiez que les fichiers que vous devez modifier — tout le reste est automatiquement hérité du thème parent.

Si vous utilisez un thème acheté

Contactez le fournisseur de votre thème et posez ces questions précises :

• Existe-t-il une version compatible PS9 ?
• Est-elle basée sur Hummingbird ou est-ce un thème indépendant ?
• Ma licence actuelle couvre-t-elle la version PS9 ?
• Quel est le chemin de migration depuis la version actuelle ?

Si le fournisseur n’a pas de version PS9 et ne peut pas vous donner de calendrier, commencez dès maintenant à planifier votre passage à Hummingbird.

Liste de vérification post-mise à jour

Vous avez terminé la mise à jour et votre back office se charge. Ne célébrez pas encore. Vérifiez systématiquement chaque fonction critique de votre boutique.

Tests du front office

Tests du back office

Vérification des passerelles de paiement

Ce point mérite sa propre section car il impacte directement le chiffre d’affaires. Pour CHAQUE mode de paiement :

1. Passez une vraie commande de test (ou utilisez le mode sandbox si disponible)
2. Vérifiez que le paiement est enregistré dans le tableau de bord du prestataire de paiement
3. Vérifiez que le statut de la commande se met à jour correctement dans PrestaShop
4. Testez les remboursements si votre processus le nécessite
5. Vérifiez les URL de webhook/IPN — la mise à jour peut avoir modifié la structure des URL

Vérification de la livraison

• Vérifiez que tous les transporteurs affichent les tarifs corrects pour les différentes zones
• Testez les seuils de livraison gratuite
• Si vous utilisez le calcul des tarifs transporteur en temps réel (via API), vérifiez que la connexion fonctionne toujours
• Vérifiez que la saisie des numéros de suivi et les emails de notification fonctionnent

Tâches cron

Vérifiez chaque tâche automatisée exécutée selon un planning :

• Emails de relance de panier abandonné
• Synchronisation des stocks
• Génération des flux (Google Shopping, Facebook, etc.)
• Génération du sitemap
• Mise à jour des taux de change
• Tout script cron personnalisé

Les URL des tâches cron changent souvent entre les versions majeures. Mettez à jour vos entrées crontab :

# Check your current cron jobs
crontab -l

# PS 9 cron URLs may have changed � verify each one loads correctly
curl -s -o /dev/null -w "%{http_code}" "https://yourshop.com/modules/yourmodule/cron.php?token=XXXXX"

Vérification du SEO

• Vérifiez que les URL simplifiées fonctionnent toujours (pages de catégorie, pages produit)
• Vérifiez que votre sitemap se génère correctement
• Vérifiez que le fichier robots.txt est correct
• Testez les pages d’atterrissage clés qui sont bien positionnées — assurez-vous qu’elles existent toujours aux mêmes URL
• Si des URL ont changé, mettez en place des redirections 301 immédiatement

Problèmes courants de mise à jour et solutions

Écran blanc de la mort

Le problème le plus fréquent après une mise à jour. Vous voyez une page blanche vide sans aucun message d’erreur.

Solution :

1. Activez le mode débogage en modifiant config/defines.inc.php :

   define('_PS_MODE_DEV_', true);

2. Rechargez la page — vous devriez maintenant voir l’erreur PHP réelle
3. Si vous voyez toujours un écran blanc, vérifiez les journaux d’erreurs PHP :

   # Apache
   tail -50 /var/log/apache2/error.log
   
   # Nginx + PHP-FPM
   tail -50 /var/log/php-fpm/error.log
   
   # PrestaShop's own log
   tail -50 /var/www/html/var/logs/prod.log

4. Causes courantes :
   • Mémoire PHP épuisée — augmentez memory_limit dans php.ini à 512M
   • Extension PHP manquante — installez l’extension requise et redémarrez PHP
   • Problème de permissions de fichiers — exécutez chown -R www-data:www-data /var/www/html/var/

Erreur 500 Internal Server Error

Généralement causée par des problèmes de .htaccess ou de configuration PHP après la mise à jour.

Solution :

# Check if .htaccess is the problem � temporarily rename it
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# If the site loads without .htaccess, regenerate it from back office:
# Shop Parameters ? Traffic & SEO ? Generate .htaccess file

# Or manually restore the default PS 9 .htaccess

Vérifiez également :

• Que le mod_rewrite d’Apache est activé : a2enmod rewrite && systemctl restart apache2
• Que votre virtual host Apache autorise les surcharges .htaccess : AllowOverride All
• Que la version PHP est bien 8.2+ pour le processus web (pas seulement en CLI)

Conflits de modules après la mise à jour

Symptômes : le back office se charge partiellement, erreurs dans des sections spécifiques, erreurs JavaScript dans la console.

Solution — la méthode d’isolation :

1. Désactivez TOUS les modules non natifs :

   # Via database if back office is broken
   mysql -u root -p prestashop -e "UPDATE ps_module SET active = 0 WHERE name NOT IN ('ps_banner','ps_contactinfo','ps_emailsubscription','ps_featuredproducts','ps_imageslider','ps_linklist','ps_mainmenu','ps_searchbar','ps_sharebuttons','ps_socialfollow','ps_wirepayment','ps_checkpayment');"

2. Videz le cache : rm -rf var/cache/*
3. Vérifiez que la boutique fonctionne avec uniquement les modules natifs
4. Activez les modules un par un, en vidant le cache entre chaque activation
5. Quand vous trouvez le module problématique, mettez-le à jour, remplacez-le ou contactez le fournisseur

Traductions manquantes ou cassées

Après la mise à jour, certaines chaînes de traduction peuvent être manquantes ou s’afficher sous forme de clés brutes (comme Modules.YourModule.SomeString).

Solution :

• Allez dans International ? Traductions et exportez/importez votre pack de langue
• Pour les traductions de modules, réinitialisez les traductions du module : désinstallez puis réinstallez le module (attention : cela peut réinitialiser la configuration — sauvegardez-la d’abord)
• PrestaShop 9 utilise plus intensivement le système de traduction Symfony — les anciens fichiers de traduction (dans modules/yourmodule/translations/) peuvent nécessiter une conversion

Problèmes de cache

Un cache obsolète est à l’origine d’un nombre surprenant de problèmes post-mise à jour. En cas de doute, videz tout :

# Nuclear cache clear
rm -rf var/cache/*

# Symfony cache rebuild
php bin/console cache:clear --env=prod --no-warmup
php bin/console cache:warmup --env=prod --no-optional-warmers

# Fix ownership after cache rebuild
chown -R www-data:www-data var/

# Also clear your browser cache � old cached JS/CSS can cause phantom issues

Images qui ne s’affichent pas

Les chemins des images ou le système de récupération des images peuvent changer entre les versions.

Solution :

• Régénérez les miniatures : Apparence ? Paramètres des images ? Régénérer les miniatures
• Vérifiez que les permissions du répertoire img/ sont correctes
• Si vous utilisez un CDN, purgez le cache du CDN
• Vérifiez que le nouveau format d’URL des images correspond à ce que votre thème attend

Connexion admin impossible

Les algorithmes de hachage des mots de passe ont changé dans PS 9 (MigratingPasswordHasher de Symfony avec bcrypt/argon2). Dans la plupart des cas, les mots de passe existants fonctionneront car le hasher effectue une migration automatique lors de la première connexion. Mais si vous êtes bloqué :

# Reset admin password � PS 9 requires Symfony's password hasher
# Do NOT use raw MD5 or direct SQL UPDATE on the password field

# Instead, use PrestaShop's CLI (if available):
php bin/console prestashop:user:change-password --email=admin@yourshop.com

# Or create a temporary PHP script to reset the password properly
# (delete this file immediately after use!)

Ne laissez jamais de scripts de réinitialisation de mot de passe sur votre serveur. Créez-les, utilisez-les, supprimez-les — tout en une seule session. Un script de réinitialisation oublié est une vulnérabilité de sécurité.

Quand engager un développeur ou faire soi-même

Soyez honnête quant à vos compétences techniques. Une mise à jour ratée peut vous coûter des jours de chiffre d’affaires et la confiance de vos clients. Voici un guide réaliste :

Vous pouvez probablement le faire vous-même si :

• Vous passez de PS 8.2 à 9.x (un seul saut de version)
• Vous avez moins de 10 modules tiers, tous confirmés compatibles PS9
• Vous utilisez un thème standard (Classic ? Hummingbird, ou un thème acheté avec support PS9)
• Vous êtes à l’aise avec SSH, la ligne de commande et les opérations de base de données
• Vous disposez d’un environnement de préproduction fonctionnel pour tester au préalable
• Votre boutique n’a pas de surcharges personnalisées ni de modifications du cœur

Vous devriez engager un développeur si :

• Vous passez de PS 1.6.x ou d’une version 1.7.x ancienne (écart de version majeur)
• Vous avez 20 modules ou plus, surtout si certains utilisent des surcharges
• Vous avez un thème personnalisé qui doit être porté vers Hummingbird
• Votre boutique contient des modifications personnalisées du cœur ou des fichiers de surcharge
• Vous n’êtes pas à l’aise avec la ligne de commande ou les opérations de base de données
• Votre boutique génère un chiffre d’affaires quotidien important et le temps d’arrêt coûte cher
• Vous avez tenté la mise à jour en préproduction et rencontré des problèmes que vous ne parvenez pas à résoudre

Ce qu’il faut rechercher chez un développeur

• Une expérience spécifique avec PrestaShop — pas seulement « développeur PHP » ou « développeur e-commerce ». L’architecture de PrestaShop est unique, et les développeurs généralistes passeront des heures facturables à apprendre des choses qu’un spécialiste PS connaît déjà.
• Une expérience spécifique avec PS 9 — demandez s’ils ont déjà réalisé des mises à jour vers PS 9. La migration vers Symfony 6.4 comporte des pièges spécifiques.
• Un plan de projet clair — ils devraient proposer : audit ? mise à jour en préproduction ? tests ? mise à jour en production ? surveillance.
• Un support post-mise à jour — les problèmes font souvent surface 1 à 2 semaines après la mise à jour, lorsque des cas particuliers sont déclenchés. Assurez-vous que le support est inclus.

Fourchettes de prix indicatives

Voici des estimations approximatives basées sur les tarifs du marché en 2025-2026 :

• Mise à jour simple (PS 8.x ? 9.x, peu de modules, thème standard) : 500 à 1500 EUR
• Mise à jour moyenne (PS 1.7.x ? 9.x, portage de thème personnalisé, modules modérés) : 2000 à 5000 EUR
• Mise à jour complexe (PS 1.6.x ? 9.x, reconstruction complète, nombreux modules personnalisés) : 5000 à 15000+ EUR

Ces prix reflètent la réalité : une mise à jour de version majeure n’est pas une opération en un clic. Si quelqu’un vous propose 200 EUR pour une migration PS 1.6 ? PS 9, soit il ne comprend pas l’étendue du travail, soit il va couper des coins, ce qui vous coûtera plus cher par la suite.

Plan de restauration : si les choses tournent mal

Vous avez fait vos sauvegardes (n’est-ce pas ?). Voici comment les utiliser si la mise à jour échoue de manière catastrophique.

Restauration depuis la mise à jour automatique

Si vous avez utilisé le module 1-Click Upgrade et qu’il a créé sa propre sauvegarde :

1. Allez dans Back Office ? Modules ? 1-Click Upgrade
2. Cliquez sur « Restauration » et sélectionnez la sauvegarde pré-mise à jour
3. Le module restaurera à la fois les fichiers et la base de données

Si le back office est totalement inaccessible, vous devrez restaurer manuellement :

Restauration manuelle — base de données

# Drop the current (broken) database and recreate it
mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"

# Import your backup
mysql -u root -p prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# For Docker:
docker exec -i my-shop-db mysql -u root -p'PASSWORD' -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
docker exec -i my-shop-db mysql -u root -p'PASSWORD' prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

Restauration manuelle — fichiers

# Remove the upgraded files
rm -rf /var/www/html/*

# Restore from your backup
tar -xzf ~/prestashop_files_pre_ps9_XXXXXXXX_XXXXXX.tar.gz -C /

# Fix permissions
chown -R www-data:www-data /var/www/html/

# Clear cache
rm -rf /var/www/html/var/cache/*

Vérifiez que la restauration a fonctionné

1. Accédez au front office — votre boutique se charge-t-elle ?
2. Accédez au back office — pouvez-vous vous connecter ?
3. Vérifiez quelques commandes — les données sont-elles intactes ?
4. Passez une commande de test — le processus de commande fonctionne-t-il ?
5. Désactivez le mode maintenance une fois que tout est confirmé fonctionnel

Après une restauration, ne tentez PAS immédiatement la mise à jour à nouveau. Analysez d’abord ce qui a mal tourné. Vérifiez les journaux de mise à jour, identifiez l’étape défaillante, recherchez l’erreur spécifique et corrigez la cause première dans votre environnement de préproduction avant de toucher à nouveau à la production.

L’urgence « sans sauvegarde »

Si vous n’avez pas fait de sauvegardes (cela arrive — ne faisons pas semblant du contraire), vos options sont limitées mais pas inexistantes :

• Sauvegardes de l’hébergeur : De nombreux hébergeurs conservent des sauvegardes quotidiennes pendant 7 à 30 jours. Vérifiez votre panneau d’hébergement ou contactez le support immédiatement.
• Journaux binaires de la base de données : Si la journalisation binaire MySQL est activée, une récupération à un instant précis peut être possible. Cela nécessite une expertise technique.
• La sauvegarde du module autoupgrade : Si vous avez coché « créer une sauvegarde » pendant la mise à jour, cherchez dans /admin/autoupgrade/backup/ les fichiers de sauvegarde du module.
• Acceptez et avancez : Si la récupération n’est pas possible, concentrez-vous sur la réparation de la boutique mise à jour plutôt que d’essayer de revenir en arrière. Parfois, aller de l’avant est la seule option.

Résumé : le parcours de mise à jour en un coup d’œil

1. Audit — vérifiez la configuration serveur requise, la compatibilité des modules, la compatibilité du thème
2. Sauvegarde — base de données (mysqldump), fichiers (tar), notes de configuration
3. Préproduction — testez l’intégralité de la mise à jour sur un environnement de préproduction d’abord
4. Planification — choisissez une période de faible trafic avec une marge de temps pour les problèmes
5. Mise à jour — activez le mode maintenance, lancez la mise à jour, videz les caches
6. Test — front office, back office, commande, paiements, livraison, emails
7. Surveillance — surveillez les journaux d’erreurs pendant 48 heures après la mise en production
8. Nettoyage — désactivez le mode débogage, supprimez les fichiers temporaires, mettez à jour la documentation

PrestaShop 9 est une amélioration significative par rapport à ses prédécesseurs. La base Symfony 6.4, l’exigence PHP 8.2+ et l’administration basée sur Twig créent une plateforme plus stable, plus rapide et plus facile à maintenir. La mise à jour nécessite une planification minutieuse, mais le résultat en vaut la peine — un moteur e-commerce moderne qui vous servira bien pour les années à venir.

Prenez votre temps, testez minutieusement et ne faites pas l’impasse sur les sauvegardes. Votre futur vous vous en remerciera.