Pourquoi migrer vers Prestashop 8 ?
Prestashop 8, sorti en octobre 2022 puis stabilisé avec la version 8.1 en 2023, constitue une évolution majeure de la plateforme e-commerce open source. Pour les développeurs, cette version représente bien plus qu’une simple mise à jour : c’est un changement d’écosystème technique qui apporte des gains tangibles.
Voici les raisons principales qui justifient cette migration :
- PHP 8.0 / 8.1 supporté nativement : gain de performance de 15 à 30 % sur le temps de traitement des requêtes par rapport à PHP 7.4.
- Symfony 4.4 pleinement intégré : meilleure structure du code, injection de dépendances systématique, découplage des composants.
- Sécurité renforcée : correctifs de vulnérabilités critiques, fin du support sécuritaire de la branche 1.7.
- Nouveau système de gestion des hooks et amélioration de la gestion des commandes CQRS.
- Back-office modernisé avec de nouvelles pages migrées sur Symfony/Twig.
Concrètement, une boutique Prestashop 1.7.8 qui reste sur PHP 7.4 se prive de mises à jour de sécurité depuis décembre 2022 (fin de vie de PHP 7.4). La migration n’est donc pas un luxe — c’est une nécessité.
Prérequis techniques avant de commencer
Vérifier la compatibilité serveur
Avant toute manipulation, assurez-vous que votre environnement serveur répond aux exigences de Prestashop 8 :
| Composant | Prestashop 1.7.8 | Prestashop 8.0/8.1 |
|---|---|---|
| PHP | 7.1 – 7.4 | 7.4 – 8.1 (8.1 recommandé) |
| MySQL | 5.6+ | 5.7+ (8.0 recommandé) |
| MariaDB | 10.0+ | 10.2+ (10.5 recommandé) |
| Symfony | 3.4 | 4.4 |
| Node.js (build thème) | 14.x | 16.x / 18.x |
| Composer | 1.x / 2.x | 2.x obligatoire |
Si vous êtes hébergé sur une infrastructure que vous maîtrisez (serveur dédié, VPS, AWS), la mise à jour PHP est simple. Sur un mutualisé, vérifiez auprès de votre hébergeur que PHP 8.1 est disponible. Chez Lueur Externe, nous déployons systématiquement nos boutiques Prestashop sur des instances AWS optimisées, ce qui nous permet de contrôler finement chaque composant de la stack.
Auditer les modules installés
C’est l’étape la plus critique. Chaque module tiers doit être vérifié :
- Module compatible PS 8 : consultez la page de l’éditeur sur Prestashop Addons ou le dépôt GitHub du module.
- Module abandonné : si le module n’a pas été mis à jour depuis plus de 18 mois, il y a de fortes chances qu’il ne soit pas compatible.
- Module custom : tout module développé sur mesure devra être relu et adapté.
Créez un tableau de synthèse de tous vos modules avec leur statut :
| Module | Version actuelle | Compatible PS8 | Action requise |
|---------------------|-----------------|----------------|---------------------|
| ps_facetedsearch | 3.12.0 | Oui | Mise à jour auto |
| modulecustom_xyz | 1.0.0 | Non testé | Audit code requis |
| mailchimp | 2.1.3 | Oui (v3.0+) | Mise à jour manuelle|
| module_abandonné | 0.9.1 | Non | Remplacement |
Auditer le thème
Si vous utilisez le thème Classic ou un thème enfant de Classic, la compatibilité est généralement assurée. En revanche, si vous utilisez un thème acheté (Warehouse, flavor, flavor…) ou un thème entièrement custom :
- Vérifiez que les templates Smarty sont compatibles avec les nouveaux hooks de PS 8.
- Testez le rendu du checkout, des pages produit et du listing catégorie.
- Attention aux fichiers
theme.yml: la structure a légèrement évolué.
Sauvegarder absolument tout
Cela semble évident, mais trop de migrations échouent à cause d’une sauvegarde incomplète :
# Sauvegarde complète de la base de données
mysqldump -u user -p --single-transaction --routines --triggers prestashop_db > backup_ps17_$(date +%Y%m%d).sql
# Sauvegarde des fichiers
tar -czf backup_ps17_files_$(date +%Y%m%d).tar.gz /var/www/prestashop/
Conservez ces sauvegardes en dehors du serveur de production (S3, stockage distant, etc.).
Mettre en place un environnement de staging
Ne tentez jamais une migration directement en production. Créez un environnement de staging identique :
- Clonez le serveur (snapshot AWS, copie du VPS, Docker).
- Restaurez la base de données et les fichiers.
- Modifiez le fichier
parameters.phppour pointer vers la base de staging. - Désactivez les emails transactionnels et les passerelles de paiement.
- Mettez un
.htaccessavec authentification pour bloquer les robots.
# Exemple rapide avec Docker pour un env de staging local
docker run -d --name ps17-staging \
-e DB_SERVER=db \
-e DB_NAME=prestashop_staging \
-e PS_DOMAIN=staging.monsite.local \
-p 8080:80 \
prestashop/prestashop:1.7.8
Cet environnement sera votre terrain de jeu pour tester la migration sans risque.
Processus de migration étape par étape
Étape 1 : Mettre à jour vers Prestashop 1.7.8.x
Si vous êtes sur une version 1.7 antérieure (1.7.5, 1.7.6, 1.7.7), commencez par monter en 1.7.8.11 (dernière version 1.7). Cela facilitera la transition vers la v8 car la version 1.7.8 partage déjà de nombreux composants avec Prestashop 8.
Utilisez le module 1-Click Upgrade (autoupgrade) en version 4.x :
cd /var/www/prestashop/modules/
git clone https://github.com/PrestaShop/autoupgrade.git
cd autoupgrade
composer install --no-dev
Puis configurez-le dans le back-office : Paramètres avancés > Mise à jour automatique.
Étape 2 : Nettoyer le code legacy
Avant de passer à PS 8, profitez-en pour nettoyer :
- Supprimez les overrides inutiles : chaque fichier dans
/override/est une source potentielle de conflit. Prestashop 8 déprécie de plus en plus les overrides au profit des hooks et des services Symfony. - Remplacez les appels dépréciés :
Tools::getValue()reste disponible mais les contrôleurs admin doivent migrer vers les formulaires Symfony. - Nettoyez le dossier
/cache/et videz les fichiers de classe compilés.
// Exemple : remplacement d'un override par un hook
// AVANT (override de AdminProductsController)
class AdminProductsController extends AdminProductsControllerCore
{
public function initContent()
{
// Code personnalisé
parent::initContent();
}
}
// APRÈS (utilisation d'un hook dans un module)
public function hookActionAdminProductsControllerInitAfter($params)
{
// Même logique, mais découplée et compatible PS8
}
Étape 3 : Lancer la migration vers Prestashop 8
Une fois en 1.7.8.x avec un code propre, lancez la migration vers PS 8.1 (ou la dernière version 8.x stable).
Méthode 1 : via le module Autoupgrade (recommandée)
php modules/autoupgrade/cli-upgrade.php \
--dir=admin-dev \
--channel=major \
--action=CompareReleases
Puis :
php modules/autoupgrade/cli-upgrade.php \
--dir=admin-dev \
--channel=major \
--action=update
Le CLI est préférable à l’interface web car il évite les timeouts sur les boutiques avec beaucoup de données.
Méthode 2 : migration manuelle (devs expérimentés)
Pour les développeurs qui veulent un contrôle total :
- Téléchargez l’archive Prestashop 8.1 depuis GitHub.
- Remplacez les fichiers core (tout sauf
/modules/,/themes/votretheme/,/img/,/upload/,/var/,/app/config/parameters.php). - Lancez Composer pour mettre à jour les dépendances :
composer install --no-dev --optimize-autoloader
- Exécutez les scripts de migration SQL. Ils se trouvent dans
/install-dev/upgrade/sql/. - Videz tous les caches :
php bin/console cache:clear --env=prod
php bin/console doctrine:schema:update --dump-sql # vérifiez avant d'exécuter
Attention : cette méthode est réservée aux développeurs qui maîtrisent parfaitement l’architecture Prestashop. Une erreur dans les fichiers remplacés peut rendre la boutique inaccessible.
Étape 4 : Adapter les modules
Après la migration du core, certains modules auront besoin d’ajustements :
- Vérifiez les fichiers
composer.jsonde chaque module : les contraintes de version PHP et Prestashop doivent être mises à jour. - Testez les hooks : certains hooks ont été renommés ou dépréciés entre PS 1.7.8 et PS 8.
- Migrez les contrôleurs admin : si un module ajoute des pages admin, elles doivent utiliser le pattern CQRS de Prestashop 8.
// composer.json d'un module compatible PS8
{
"name": "monmodule/monmodule",
"type": "prestashop-module",
"require": {
"php": ">=7.4",
"prestashop/prestashop": ">=8.0.0"
},
"autoload": {
"psr-4": {
"MonModule\\": "src/"
}
}
}
Étape 5 : Vérifier le thème
Testez minutieusement :
- La page d’accueil et les pages CMS.
- Le listing produit avec le module de filtres à facettes.
- La fiche produit (variantes, ajout au panier, zoom images).
- Le tunnel de commande complet (panier → paiement → confirmation).
- Le compte client (commandes, adresses, avoirs).
- La version mobile (responsive).
Un outil comme Cypress ou Playwright peut automatiser ces tests fonctionnels :
// Exemple de test Playwright pour le tunnel de commande
test('Le tunnel de commande fonctionne après migration', async ({ page }) => {
await page.goto('/fr/men/1-hummingbird-printed-t-shirt.html');
await page.click('[data-button-action="add-to-cart"]');
await page.waitForSelector('.cart-products-count');
await page.goto('/fr/commande');
await expect(page.locator('.cart-summary')).toBeVisible();
});
Les pièges classiques à éviter
Après avoir accompagné des dizaines de migrations Prestashop depuis 2003, l’équipe de Lueur Externe a identifié les erreurs les plus fréquentes :
1. Ignorer les overrides
Les fichiers dans /override/ sont la première cause d’échec de migration. Ils écrasent des classes core qui changent d’une version à l’autre. Auditez chaque override et transformez-le en hook ou service.
2. Ne pas tester les paiements
Un module de paiement qui plante après migration = des ventes perdues. Testez chaque moyen de paiement en mode sandbox (Stripe Test, PayPal Sandbox, etc.).
3. Oublier les tâches CRON
Si votre boutique utilise des crons (import catalogue, synchronisation ERP, envoi d’emails automatisés), vérifiez que les scripts appelés fonctionnent toujours avec la nouvelle structure.
4. Sous-estimer la migration des données
Les boutiques avec plus de 50 000 produits ou 500 000 commandes peuvent rencontrer des timeouts lors de la migration SQL. Augmentez les limites :
; php.ini
max_execution_time = 600
memory_limit = 512M
5. Migrer un vendredi
Cela paraît anecdotique, mais planifiez votre mise en production un mardi ou mercredi matin. Vous aurez le reste de la semaine pour corriger les éventuels problèmes sans pression du week-end commercial.
Checklist post-migration
Une fois la migration effectuée sur le staging et validée, voici la checklist avant de passer en production :
- Toutes les pages du site se chargent sans erreur 500.
- Le tunnel de commande fonctionne de bout en bout.
- Les modules de paiement sont opérationnels.
- Les emails transactionnels sont envoyés correctement.
- Le sitemap XML se régénère (
/1_index_sitemap.xml). - Les URL canoniques et les redirections 301 sont en place.
- Le fichier
robots.txtest correct. - Google Search Console ne remonte pas de nouvelles erreurs d’exploration.
- Les performances sont au moins équivalentes (testez avec GTmetrix / Lighthouse).
- Le SSL fonctionne sur toutes les pages.
- Les sauvegardes automatiques sont reconfigurées.
Performances attendues après migration
D’après nos benchmarks réalisés sur des boutiques clientes, le passage de Prestashop 1.7.8 (PHP 7.4) à Prestashop 8.1 (PHP 8.1) produit ces résultats moyens :
| Métrique | PS 1.7.8 / PHP 7.4 | PS 8.1 / PHP 8.1 | Gain |
|---|---|---|---|
| TTFB (Time To First Byte) | 380 ms | 260 ms | -31 % |
| Temps de chargement page produit | 2.1 s | 1.5 s | -28 % |
| Temps de génération back-office | 1.8 s | 1.1 s | -39 % |
| Consommation mémoire PHP | 128 Mo | 95 Mo | -26 % |
Ces chiffres varient selon la complexité de la boutique, le nombre de modules et la qualité de l’hébergement, mais la tendance est systématiquement positive.
Faut-il faire appel à un prestataire spécialisé ?
Si vous êtes développeur et que vous maîtrisez l’écosystème Prestashop, ce guide vous donne toutes les clés pour mener la migration vous-même. Cependant, certains contextes justifient de faire appel à un expert :
- Boutique avec un chiffre d’affaires supérieur à 100 000 € annuels (le risque d’indisponibilité est trop coûteux).
- Plus de 20 modules installés dont plusieurs modules custom.
- Intégrations tierces complexes (ERP, PIM, marketplace).
- Thème entièrement sur mesure avec des surcharges profondes.
Lueur Externe, agence certifiée Prestashop et AWS Solutions Architect basée dans les Alpes-Maritimes, accompagne des marchands dans ce type de migration depuis plus de 20 ans. Notre approche combine l’audit technique préalable, la migration sur environnement de staging, les tests automatisés et la mise en production assistée.
Conclusion
La migration de Prestashop 1.7 vers la version 8 est un passage obligé pour tout marchand qui souhaite bénéficier des dernières avancées en matière de performance, de sécurité et de maintenabilité du code. Pour les développeurs, c’est aussi l’occasion de nettoyer la dette technique accumulée : suppression des overrides, modernisation des modules et adoption des patterns Symfony.
Les étapes clés sont claires : auditer l’existant, préparer un staging, migrer progressivement, tester exhaustivement, puis déployer en production. Avec de la méthode et de la rigueur, la migration se déroule sans accroc.
Vous avez un projet de migration Prestashop 8 et souhaitez être accompagné par une équipe qui connaît la plateforme sur le bout des doigts ? Contactez Lueur Externe pour un audit gratuit de votre boutique et un devis personnalisé. Parlons de votre projet →