Des données produit structurées, c'est une information produit rangée dans un attribut typé, ave…
PrestaShop 8 vers 9 sans replatforming : découplez d'abord le front
Vous retirez l'essentiel du risque de la mise à jour PrestaShop 8 vers 9 en sortant la storefront du thème PrestaShop avant de toucher au cœur. Dès que le front dialogue avec PrestaShop via une API plutôt que via des templates et des hooks d'affichage, la refonte du thème et les modules front office cassés ne font plus partie de la mise à jour. Il reste une mise à jour du back-end que vous pouvez tester, planifier et annuler de façon indépendante.
Ce qui change vraiment entre PrestaShop 8 et 9
PrestaShop 9.0 est sorti le 10 juin 2025, et il s'agit d'une vraie version majeure. Le cœur est passé de Symfony 4.4 à Symfony 6.4, la branche à support long terme qui reçoit des mises à jour de sécurité jusqu'en novembre 2027. Les exigences PHP évoluent aussi : PrestaShop 8.0 à 8.2 fonctionne avec PHP 7.2 à 8.1, alors que PrestaShop 9 exige au minimum PHP 8.1 et prend en charge PHP 8.4. PrestaShop 9.1 étend la compatibilité jusqu'à PHP 8.5.
Les notes pour les développeurs sont longues : les contrôleurs du back office doivent être définis comme services, et des bibliothèques embarquées comme Guzzle et Swift Mailer ont été remplacées par des composants Symfony. PrestaShop indique lui-même que certains modules et thèmes peuvent nécessiter des mises à jour pour fonctionner correctement.
La storefront change elle aussi. Avec PrestaShop 9.1, sorti le 23 mars 2026, Hummingbird 2.0 est devenu le thème front office par défaut. Il repose sur Bootstrap 5, et la documentation développeur indique que Classic est déprécié pour les nouveaux développements. Les boutiques existantes peuvent conserver Classic pour le moment.
En parallèle, PrestaShop 8.2 est en support étendu depuis juillet 2025. Il ne reçoit plus que des correctifs critiques et de sécurité, et la maintenance s'arrêtera à la sortie de PrestaShop 10.0.0. La mise à jour n'est pas une urgence, mais elle a sa place dans votre feuille de route.
Pourquoi la storefront porte l'essentiel du risque
Dans une installation PrestaShop classique, des années de personnalisation se trouvent dans le front office : un thème acheté ou fortement modifié, et des modules qui injectent du code via les hooks d'affichage, comme les sliders, les avis clients, les badges ou les blocs de ventes croisées.
La mise à jour crée alors une chaîne de dépendances :
- Le thème doit être vérifié, corrigé ou reconstruit pour PrestaShop 9, et le passage vers Hummingbird implique une migration de Bootstrap 4 vers 5.
- Chaque module affiché en front office a besoin d'une version compatible PrestaShop 9, et ses templates doivent s'accorder avec le thème.
- Les overrides et les modifications du thème enfant doivent être réappliqués et testés à nouveau.
- Le balisage SEO, le tracking et les Core Web Vitals doivent être validés de nouveau après la bascule.
Rien de tout cela ne fait vendre un produit de plus. Et comme thème et back-end sont couplés, le nouveau cœur et la storefront adaptée doivent être mis en ligne ensemble.
Trois options que les marchands PrestaShop comparent
La plupart des équipes confrontées à la mise à jour finissent par comparer trois voies :
- Mettre à jour l'existant. Cœur, thème et modules sont mis à jour ensemble, avec l'effort de coordination le plus élevé dans une seule fenêtre de release.
- Replatformer. Passer à un autre système e-commerce. Pertinent si PrestaShop ne correspond plus à votre modèle économique, mais cela remplace catalogue, processus de commande et intégrations en même temps.
- Découpler d'abord. PrestaShop reste le back-end e-commerce, la storefront passe sur un front découplé, puis le cœur est mis à jour en arrière-plan.
Si ce qui vous freine réellement est la storefront et non le back-end, l'option trois est un projet nettement plus petit. Nous en avons décrit la mécanique dans renouveler le front PrestaShop sans toucher au back-end.
Comment un front découplé change la mise à jour
Avec un front headless composable, la storefront ne rend plus de templates PrestaShop. Elle lit les produits, les prix, le panier et les données clients via des API et les affiche dans sa propre couche de composants. PrestaShop reste le système de référence pour le catalogue et les commandes.
Pour la mise à jour de 8 vers 9, le périmètre change :
- Le risque lié au thème sort du parcours client. Plus de thème Classic ou Hummingbird à reconstruire devant vos clients, et les versions de Bootstrap du thème front office n'influencent plus ce qu'ils voient.
- Le risque lié aux modules d'affichage diminue. Blocs de contenu, sliders et badges issus autrefois des modules front office deviennent des composants du front. Vous les maintenez une seule fois, indépendamment de la version du cœur.
- La mise à jour devient testable. Votre front dépend d'un contrat d'API. Vous mettez à jour PrestaShop en préproduction, envoyez les mêmes appels d'API aux versions 8 et 9 et comparez les résultats avant de basculer.
- Le marketing continue de publier. Les campagnes se construisent dans la couche front, par exemple dans l'éditeur visuel de Laioutr Studio, et un gel du back-end ne gèle pas la storefront.
Il y a des limites. Les modules porteurs de logique métier, comme le paiement, la livraison, les taxes ou les connecteurs ERP, tournent toujours dans PrestaShop et ont toujours besoin de versions compatibles PrestaShop 9. PrestaShop 9 introduit aussi une nouvelle Admin API basée sur API Platform, que le projet qualifie de chantier en cours et qui doit à terme remplacer les Web Services existants. Vérifiez quelle API votre front utilise et intégrez-la à vos tests de mise à jour.
Laioutr est conçu pour cette couche. En tant que Frontend Management Platform, Laioutr se place au-dessus des systèmes e-commerce existants, fonctionne avec plus de 50 back-ends et traite la performance comme une propriété de la plateforme : les storefronts Laioutr en production atteignent un LCP médian de 1,2 s, avec des objectifs d'INP inférieur à 80 ms et de CLS inférieur à 0,02. La page front headless pour PrestaShop montre à quoi cela ressemble pour PrestaShop. Connecteur prêt à l'emploi ou configuration spécifique au projet via Orchestr : nous clarifions ce qui convient à votre boutique lors de la démo.
Un plan de séquencement pour la mise à jour
Le découplage fonctionne mieux comme une séquence que comme une bascule unique. Pour une activité saisonnière, l'ordre décide aussi du risque que vous portez en haute saison, un point détaillé dans big bang ou migration front progressive.
- Auditer vos modules. Séparez les modules d'affichage front office, qui passent dans le front, des modules de logique métier, qui restent dans PrestaShop et doivent être vérifiés pour la version 9.
- Planifier le front découplé face à PrestaShop 8.2. Construisez et testez la nouvelle storefront avec votre back-end actuel, qui continue de recevoir les correctifs de sécurité. Les Core Web Vitals de l'ancien thème vous servent de référence.
- Figer le contrat d'API. Documentez les endpoints et les données dont votre front dépend et transformez-les en contrôles automatisés.
- Préparer la plateforme. PHP 8.1 est pris en charge par PrestaShop 8.2 et 9, vous pouvez donc passer le serveur en PHP 8.1 avant la mise à jour du cœur et isoler ce changement.
- Mettre à jour le back-end en préproduction, puis basculer hors saison. Passez à PrestaShop 9 avec l'Update Assistant, mettez à jour les modules métier restants et lancez les contrôles d'API. Vos clients gardent la même storefront, et en cas de problème, vous revenez en arrière sur le back-end sans toucher au front.
Une release risquée devient plusieurs releases plus petites, chacune avec un point de retour.
FAQ
Faut-il passer à PrestaShop 9 tout de suite ?
Non. PrestaShop 8.2 reçoit des correctifs critiques et de sécurité jusqu'à la sortie de PrestaShop 10.0.0. Profitez de cette période pour découpler d'abord le front.
Un front découplé supprime-t-il tout le risque lié aux modules ?
Non. Il supprime le risque lié au thème front office et aux modules qui s'y affichent. Les modules de paiement, de livraison, de taxes et d'ERP tournent toujours dans PrestaShop et nécessitent des versions compatibles PrestaShop 9.
Que devient le SEO quand la storefront change ?
URL, redirections, données structurées et métadonnées demandent un plan de migration, comme pour tout changement de thème. La différence : vous le faites une fois, dans le front, et non à chaque mise à jour du thème.
Est-ce pertinent seulement pour les grandes boutiques ?
Non. L'approche apporte le plus aux boutiques avec un thème personnalisé et de nombreux modules front office, quelle que soit leur taille.
Prochaines étapes
Si PrestaShop 9 figure dans votre feuille de route, commencez par la storefront : cartographiez vos modules, définissez le contrat d'API et planifiez le lancement du front avant la mise à jour du cœur. Réservez une démo avec notre équipe et nous passerons en revue la séquence adaptée à votre configuration.