PrestaShop 9 marque la transition la plus importante de l’histoire récente de la plateforme. Après une longue phase de cohabitation entre code legacy (Smarty, ObjectModel) et code moderne (Symfony, Twig), la branche 9 fait le ménage : modernisation Symfony complète, abandon progressif de Smarty, exigences PHP relevées, et back-office repensé. Ce guide fait le point sur les changements connus, ce qu’ils impliquent pour vos modules, et comment préparer votre migration depuis PrestaShop 8.
Le contexte de PrestaShop 9
PrestaShop 8 avait pour mandat de stabiliser l’écosystème après les soubresauts de 1.7. Mission accomplie : la branche 8.x est mature, performante et bien supportée par les modules tiers majeurs. PrestaShop 9 prend le relais avec un mandat différent : moderniser en profondeur la stack technique pour préparer les dix prochaines années.
Cette modernisation a un coût : certains modules développés pour PrestaShop 1.7 ou 8 ne fonctionneront pas tels quels sur 9. C’est le compromis assumé par l’équipe core.
Symfony et le passage au tout-Twig
PrestaShop 8 fonctionne sur Symfony 4.4. PrestaShop 9 monte significativement de version, alignée sur les standards Symfony actuels — ce qui veut dire des composants plus modernes, des performances meilleures, et de nouvelles capacités côté DAL et services.
Côté templates, la transition Smarty → Twig progresse. Sur PrestaShop 8, le back-office est presque entièrement en Twig mais le front-office reste majoritairement en Smarty. Sur PrestaShop 9, l’orientation est claire : Twig devient le standard sur l’ensemble du code core, avec Smarty maintenu à plus longue échéance pour la compatibilité des thèmes existants. À terme, les nouveaux thèmes seront développés en Twig.
Pour les développeurs : si vous démarrez un nouveau projet de thème ou de module en 2026, il est temps de monter en compétence sur Twig si ce n’est pas déjà fait.
Exigences techniques relevées
PrestaShop 9 demande au minimum :
- PHP 8.1+ (idéalement 8.2 ou 8.3 pour les performances)
- MySQL 5.7.8+ ou MariaDB équivalent
- Composer obligatoire pour certains workflows
Si votre boutique tourne encore sur PHP 7.4 (comme beaucoup d’installations PrestaShop 1.7 jamais modernisées), la migration vers PrestaShop 9 implique aussi une migration PHP. Sur un hébergement mutualisé moderne (o2switch, OVH Cloud Web, Cloudways), cette bascule se fait via le panneau de gestion en quelques clics. Sur des serveurs custom, ça peut demander plus de travail.
Impact sur les modules existants
L’impact dépend de la qualité technique de vos modules. Trois cas typiques :
Cas A : modules modernes, Symfony-friendly
Modules développés en respectant les standards modernes (services Symfony, Twig pour le back-office, DAL pour les requêtes, hooks documentés). Migration vers PrestaShop 9 généralement sans douleur, parfois avec une simple recompilation Composer.
Cas B : modules hybrides PrestaShop 8
Modules qui mélangent code legacy (ObjectModel, Smarty pour le front-office, requêtes Db direct) et code moderne. Compatibles dans la plupart des cas, mais quelques ajustements peuvent être nécessaires sur les hooks deprecated ou les composants tiers utilisés.
Cas C : modules legacy PrestaShop 1.7
Modules conçus avant Symfony, en pur Smarty + ObjectModel + ancien système de hooks. Compatibilité incertaine. Beaucoup de ces modules ne sont plus maintenus de toute façon. Ce sera l’occasion de faire le ménage.
Pour vos modules tiers : vérifiez la compatibilité PrestaShop 9 sur la fiche de chaque module avant migration. Les éditeurs sérieux annoncent leur compatibilité sous 3 à 6 mois après une release majeure. Les modules silencieux sont à considérer comme abandonnés.
Le back-office repensé
PrestaShop 9 modernise plusieurs sections du back-office, notamment :
- L’éditeur de modules avec une UX revue
- Les sections catalogue et commandes plus rapides grâce aux datatables modernes
- Une intégration plus poussée des composants Symfony Flex pour les développeurs
- Une amélioration des performances générales du back-office (rendu plus rapide, moins de roundtrips serveur)
L’expérience utilisateur des marchands reste cohérente avec PrestaShop 8 — pas de re-formation des équipes nécessaire.
Faut-il migrer immédiatement ?
Pour la plupart des boutiques en production sur PrestaShop 8 stable, la réponse est : pas dans la précipitation. Quelques règles pragmatiques :
- Boutique en production stable : attendre la version 9.0.x stabilisée (typiquement 6 à 12 mois après la première release) avant migration. Les .0 ont souvent des bugs résiduels.
- Nouveau projet en 2026 : démarrer directement en PrestaShop 9 si tous vos modules critiques sont compatibles. Sinon, démarrer en 8.x récent et migrer plus tard.
- Boutique sur PrestaShop 1.7 : ne pas attendre. Migrer vers 8.x récent immédiatement (la 1.7 n’est plus supportée), puis vers 9 une fois stabilisée.
Préparer la migration
Quelle que soit votre échéance, anticipez :
- Auditer vos modules — listez tous les modules installés, leur version, leur éditeur, leur statut PrestaShop 9. Identifier les modules abandonnés ou non compatibles.
- Vérifier votre stack PHP — passer à PHP 8.1+ avant la migration PrestaShop. Sur PrestaShop 8, PHP 8.1+ tourne très bien et améliore déjà les performances.
- Préparer un environnement de staging — la migration doit être testée sur un clone de la production avant déploiement. Compter 2 à 4 semaines de tests pour une boutique avec une trentaine de modules.
- Sauvegarder, tout, plusieurs fois — base de données, fichiers, configuration nginx/apache, certificats SSL. Sauvegarder avant chaque étape.
- Communiquer aux clients — programmer la migration sur un créneau de faible activité (nuit, dimanche matin selon votre activité). Prévenir vos newsletters d’une potentielle indisponibilité de quelques heures.
Combien de temps prévoir ?
Pour une boutique de taille moyenne (~1 000 produits, 30 modules, 1 thème custom), comptez :
- Audit et planning : 1 à 2 jours
- Mise à jour des modules vers leurs versions PS9-compatibles : 2 à 5 jours
- Migration thème custom : 5 à 15 jours selon la complexité (passages Smarty → Twig si nécessaire)
- Tests sur staging : 5 à 10 jours
- Migration en production + monitoring : 1 jour
Soit 3 à 6 semaines au total pour une boutique standard. Plus pour les boutiques complexes (multi-boutique, B2B, gros catalogue).
Les risques classiques d’une migration majeure
- Modules tiers cassés — toujours le risque numéro un. Tester un par un sur staging.
- Régressions SEO — vérifier que les URLs, sitemap, données structurées et canonicals sont préservées. Surveiller Search Console les 4 semaines suivant la migration.
- Régressions de performance — Lighthouse avant / après pour comparer.
- Données de configuration perdues — certains modules stockent leurs configurations dans des champs custom qui peuvent être effacés. Documenter avant migration.
- Cache résiduel — vider tous les caches (Smarty, Symfony, navigateur, CDN) après migration. Beaucoup de bugs post-migration sont en réalité des bugs de cache.
Ce que cela signifie pour DataFirefly
Tous nos nouveaux modules sont développés en respectant les standards modernes Symfony, ce qui garantit leur compatibilité PrestaShop 9. Pour notre catalogue existant, nous procédons à un audit module par module et publions les versions PrestaShop 9-compatibles au fur et à mesure des tests. Les mises à jour sont incluses dans les 12 mois de support post-achat.
Pour aller plus loin
Toutes nos actualités sur PrestaShop 9 et les évolutions du e-commerce sont à retrouver dans la catégorie Actualités e-commerce. Pour les tutoriels techniques liés à PrestaShop 8 et 9, voir Tutoriels PrestaShop. Et notre catalogue de modules PrestaShop indique pour chaque produit la liste des versions compatibles.