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 ?
# Retour pro
Posté par Letho . En réponse à la dépêche L’année 2025 pour le projet PrestaShop. Évalué à 10. 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.