L’année 2025 pour le projet PrestaShop

Posté par  (site web personnel, Mastodon) . Édité par Ysabeau 🧶. Modéré par Ysabeau 🧶. Licence CC By‑SA.
14
17
déc.
2025
PHP

Les nouvelles les plus récentes sur LinuxFR concernant PrestaShop remontent à bientôt trois ans, une éternité dans le monde de l’édition de solutions web.

Pour rappel, PrestaShop est un système de gestion de contenu (CMS) libre français de commerce en ligne, développé en PHP et placé sous licence OSL v3.

En cette fin d’année 2025, regardons quelles sont les nouveautés des douze mois écoulés.

(Déclaration d’intérêts : je suis salarié PrestaShop SA)

10 juin : sortie de PrestaShop 9

Après plus de deux ans de développement et de collaboration avec la communauté, cette version majeure apporte son lot de nouveautés, principalement sous le capot. Avec, entre autres, le passage à Symfony 6.4 (version LTS), la compatibilité avec PHP 8.4 ou encore une toute nouvelle API d’administration.

La liste complète des nouveautés est disponible dans les notes de publication (en anglais)

Juillet et août : appel aux contributions externes

Le projet PrestaShop, depuis sa genèse, est open source et ouvert à toute forme de contribution : développement, rapport de bugs, traductions, écriture de documentation, etc.

Au quotidien, ce projet est également soutenu par l’entreprise PrestaShop SA.

Durant cette année, cette dernière a souhaité améliorer le suivi des contributions externes. C’est pourquoi il a été décidé de proposer à la communauté deux thématiques ciblées : les hooks (billet en anglais) et l’API Admin (billet en anglais) .

Il y a quelques semaines, un point d’étape concernant les contributions sur l’API Admin a été publié sur le blog du projet (en anglais).

4 septembre : sortie de PrestaShop 8.2.3

Depuis la publication de PrestaShop 9, la branche 8.2 est en support étendu, ce qui veut dire que seuls des correctifs de sécurité sont traités.

C’est pourquoi début septembre, la version 8.2.3 a vu le jour, suite la découverte d’une faille sur la page de réinitialisation du mot de passe.

Le billet de blog est disponible en anglais.

8 décembre : ménage de printemps d’hiver

L’écosystème PrestaShop, ce sont des dizaines de dépôts, des centaines de contributeurices et des milliers de tickets ouverts.

Il a été proposé de revoir la manière dont sont gérés les tickets, afin d’aider la communauté à mieux s’y retrouver.

C’est pourquoi il est maintenant possible d’ouvrir un ticket (pour déclarer un bug ou demander une nouvelle fonctionnalité) sur certains dépôts directement. Auparavant, tout était centralisé sur le projet PrestaShop directement et il était devenu très compliqué, pour les personnes en charge de traiter les plus de 2 300 tickets d’être efficaces.

Toute la nouvelle organisation et les différentes étapes sont disponibles en anglais.

15 décembre : PrestaShop 9.1, levez les stylos !

Et voila, on ne touche plus à cette version, en cours de développement depuis plusieurs mois, et on entre dans une phase de « feature freeze » : plus aucune nouveauté ne sera ajoutée. C’est une période pour tester cette version importante qui apportera notamment un nouveau thème par défaut (Hummingbird), un système de création de promotions revu et amélioré et aussi la possibilité d’assigner plusieurs transporteurs sur une seule commande.

Vous souhaitez tester cette future version et aider la communauté à stabiliser tout cela, n’hésitez pas à lire cette page publiée récemment.

Et en 2026, quel programme ?

La procédure de livraison de PrestaShop 9.1 continuera son cours, avec la sortie de versions Release Candidate et bien sûr, une version finale. Pas de date à donner, c’est toujours plus sage d’être prudent.

Entamé depuis plusieurs années, le chantier de réécriture du backoffice poursuivra son cours, avec la migration vers Symfony.

En tout cas, l’année 2026 sera importante pour le projet et sa communauté, mais nous aurons le temps d’en reparler dans quelques semaines !

Aller plus loin

  • # Retour pro

    Posté par  . Évalué à 10 (+9/-0). Dernière modification le 17 décembre 2025 à 22:37.

    Avant tout, un énorme merci pour tout le travail accompli. Je me permets un retour sur l'utilisation que nous avons de PrestaShop dans un cadre pro.

    Nous déployons des stacks assez diverses (PHP/Symfony, Quarkus, SvelteKit…). Pour uniformiser tout ça, toutes nos applications sont containerisées, et tournent sur un cluster K8s.

    Nous avons fait le choix de tester PrestaShop pour une migration de site de vente en ligne. Expérience plutôt positive dans l'ensemble, mais avec deux principaux soucis :

    Tout d'abord, il peut y avoir dans l'arborescence d'un site PrestaShop un manque de clarté entre ce qui relève du code, et ce qui relève de la data. Un container applicatif peut (et va) être détruit / recréé au sein du cluster. La data doit donc être externalisée, soit dans une base de donnée, soit dans des volumes persistants. Cette data inclus par exemple les images produit, mais également la configuration de thèmes ou de modules, etc.

    Le problème est que les fichiers « data » ne sont pas centralisés dans un répertoire dédié, mais peuvent se retrouver à différent endroits de l'arborescence du site. Les modules tiers n'ont (je crois ?) pas à respecter de norme particulière à ce sujet. Cela nous conduit à devoir traiter la persistance de chaque module au cas par cas. On s'en sort en générant des liens symboliques (un peu comme Stow), mais ce n'est pas aussi pratique qu'une solution native.

    Les exemples de PrestaShop containerisé que nous avons pu trouver externalisent généralement l'intégralité du répertoire www, mais ce n'est pas ce que nous souhaitons… cf. second point.

    Second point, donc, il n'existe pas (à ma connaissance) de système permettant de travailler avec PrestaShop en mode « framework », un peu à la manière de ce que propose Bedrock pour Wordpress. L'idée étant de gérer un site PrestaShop comme un projet Composer. PrestaShop est une dépendance du projet, ainsi que tous les thèmes / modules que l'on souhaite installer. Les montées en version de PrestaShop comme des modules se feraient via Composer plutôt que depuis le backoffice.

    Idem ici, nous sommes en train de bricoler une solution maison.

    Attention, il ne s'agit en rien d'un cahier de doléances, et j'ai bien conscience que souci vient plus de ce que nous nous écartons de l'usage habituel de l'outil.

    Je pense en revanche que nous ne sommes pas les seuls à préférer ce type de workflow, qui a beaucoup d'avantages, comme la reproductibilité, la facilité de déploiement, etc. Y a-t-il du côté de l'équipe PrestaShop des évolutions prévues à ce sujet ?

    Voilà, my 2 cents, et merci encore.

    • [^] # Re: Retour pro

      Posté par  (site web personnel, Mastodon) . Évalué à 7 (+5/-0).

      Bonjour Letho. Merci pour ton commentaire très pertinent.

      Le problème est que les fichiers « data » ne sont pas centralisés dans un répertoire dédié, mais peuvent se retrouver à différent endroits de l'arborescence du site.

      Oui, nous avons évidemment conscience de ce problème. C'est dans les têtes de pas mal de personnes. Je sais que ce sujet a déjà été évoqué pour des projets entreprise, mais pour le moment, concernant le projet open source, je ne peux pas te dire si ce souci sera corrigé à court ou moyen terme.

      PrestaShop est une dépendance du projet, ainsi que tous les thèmes / modules que l'on souhaite installer. Les montées en version de PrestaShop comme des modules se feraient via Composer plutôt que depuis le backoffice.

      Mais oui 😍 on adorerait tout ça. On paie encore un héritage technique très lourd, nous sommes en pleine migration (depuis des années) mais à l'avenir, il serait bon de tendre vers cette architecture pour les dépendances.

      Idem ici, nous sommes en train de bricoler une solution maison.

      Alors, peut-être qu'il serait possible de contribuer au projet et d'apporter votre vision à tout ça ? On pourrait prolonger la discussion sur GitHub par exemple.

      Bonne journée et à très bientôt !

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.