PrestaShop 8 en fin de support : faut-il migrer vers la 9 ?

Ce que « support étendu » veut dire concrètement

Depuis juillet 2025, PrestaShop 8 est passé en support étendu. Ce n'est pas la fin du support, mais ce n'est plus un maintien complet : la branche 8.x ne reçoit plus que les correctifs de bugs critiques, les correctifs de sécurité et les évolutions de hooks indispensables. Les nouvelles fonctionnalités vont exclusivement en version 9. La fin réelle du support interviendra à la sortie de PrestaShop 10.

Autrement dit, la question « PrestaShop 8 fin de support, faut-il migrer ? » ne se pose pas en termes de panne imminente. Elle se pose en termes de dette technique qui s'accumule.

Les trois faits techniques qui pèsent vraiment

PHP. PrestaShop 8 plafonne à PHP 8.1, dont le support de sécurité officiel est terminé. PrestaShop 9 accepte PHP 8.1 à 8.4. À terme, votre hébergeur retirera PHP 8.1 de son parc, et vous n'aurez plus le choix.

Symfony. PrestaShop 8 repose sur Symfony 4.4, en fin de vie, sans backport de sécurité. PrestaShop 9 est passé à Symfony 6.4 LTS, maintenu en correctifs jusqu'à fin 2026 et en sécurité jusqu'à fin 2027. L'équipe PrestaShop a indiqué explicitement qu'aucun backport n'est prévu pour la branche 8.x.

Node.js. La compilation des thèmes en version 9 exige Node 20 ou supérieur. Ce détail piège les agences qui travaillent encore avec un environnement de build ancien.

Ce qui casse réellement en passant en 9

La migration 8 vers 9 n'est pas une simple montée de version. Voici les ruptures qui génèrent la charge de travail :

• Bibliothèques retirées du cœur : Swift Mailer remplacé par Symfony Mailer, Guzzle par Symfony HTTP Client, League Tactician par Symfony Messenger. Tout module qui déclare use GuzzleHttp\... produit une erreur fatale.
• Contrôleurs d'administration : FrameworkBundleAdminController est déprécié au profit de PrestaShopAdminController. Les contrôleurs doivent être déclarés comme services avec injection de dépendances.
• Bundles supprimés : sensio/framework-extra-bundle disparaît, donc les annotations de route et de template ne fonctionnent plus.
• Authentification back-office entièrement portée sur Symfony : les modules SSO ou de double authentification maison qui s'appuyaient sur le cookie historique cessent de fonctionner.
• Thème : Hummingbird devient le thème par défaut. Il abandonne Bootstrap et casse les surcharges écrites pour Classic. Classic reste livré, ce qui permet de temporiser.

La grille de décision

Restez en 8 pour l'instant si votre boutique est stable, votre hébergeur maintient PHP 8.1, vous dépendez de modules tiers dont l'éditeur n'a pas publié de version compatible 9, et vous êtes en pleine saison commerciale. Dans ce cas, appliquez rigoureusement chaque correctif de sécurité 8.2.x.

Planifiez la migration dans les 6 à 12 mois si votre boutique est un actif principal, vous développez régulièrement des fonctionnalités, ou votre thème est très surchargé. Plus vous attendez, plus l'écart entre votre code et le cœur se creuse.

Envisagez une refonte plutôt qu'une migration si votre thème date d'avant 2020, vous accumulez plus de dix overrides, ou plus de la moitié de vos modules tiers ne sont plus maintenus. Dans ce cas de figure, migrer coûte souvent plus cher que reconstruire proprement, pour un résultat moins bon.

Comment chiffrer honnêtement

L'audit préalable est l'étape la plus rentable de tout le projet. Il consiste à répondre à quatre questions :

1. Combien de modules tiers, et combien ont une version compatible 9 publiée ?
2. Combien d'overrides dans override/, et sont-ils encore utiles ?
3. Combien de templates surchargés dans le thème, et quel écart avec le thème parent ?
4. Quel volume de code spécifique développé sur mesure ?

Un audit sérieux prend une à deux journées et transforme un devis approximatif en un plan de charge fiable. Il permet aussi de découvrir que certains overrides datent d'un besoin abandonné depuis longtemps, et que la migration sera plus légère que prévu.

Ne migrez jamais sans plan de retour arrière

Trois précautions non négociables :

• une préproduction identique à la production, sur laquelle tourne la migration complète avant toute intervention en réel ;
• une recette écrite couvrant le tunnel de commande, les paiements, les transporteurs, les emails transactionnels et les exports comptables ;
• une fenêtre de bascule avec sauvegarde restaurable, et un critère d'échec décidé à l'avance.

Si votre mise à jour est déjà lancée et bloquée, notre article sur l'Update Assistant traite les erreurs les plus courantes. Et si vous partez d'une version antérieure, le chemin est différent : voyez la migration depuis PrestaShop 1.6.

Faire auditer votre boutique

Nous réalisons l'audit de compatibilité, chiffrons la migration et l'exécutons avec un plan de retour arrière. Découvrez notre approche sur la page migration PrestaShop.