PrestaShop : de la 1.6 à la 8, une modernisation ratée ?

Cela fait plus de dix ans que je bidouille, que je configure et que je personnalise des boutiques en ligne avec PrestaShop. Une décennie de loyauté à cette solution open source française, un petit bijou qui m’a accompagné après mes premières armes sur OSCommerce. À l’époque, PrestaShop, c’était la liberté, la simplicité, et une efficacité redoutable pour monter une boutique sans se prendre la tête. La version 1.6, pour moi, reste le sommet de cette aventure : stable, intuitive, et parfaitement adaptée aux besoins d’un e-commerçant qui veut garder la main sur son outil. Mais depuis ? J’ai l’impression que PrestaShop s’est perdu en chemin, et je ne suis pas le seul à le penser.

Symfony : un choix qui plombe plus qu’il n’élève

Tout a basculé avec l’arrivée de Symfony dans la version 1.7. Sur le papier, ça sonnait bien : moderniser le code, le rendre plus robuste, attirer les développeurs pros avec un framework à la mode. Mais dans les faits ? Une usine à gaz. La légèreté qui faisait le charme de PrestaShop s’est évaporée, remplacée par une architecture lourde qui demande des serveurs costauds et des compétences pointues pour ne pas se noyer dans les fichiers. Les avantages ? Très théoriques. Oui, Symfony structure le code, mais à quel prix ? Pour l’utilisateur lambda ou le petit marchand qui veut juste vendre ses produits, c’est une complexité inutile. Et depuis la 1.8 – ou plutôt devrais-je dire la version 8, vu qu’ils ont sauté directement de 1.7 à 8 pour faire « moderne » – j’ai l’impression que PrestaShop passe son temps à corriger les errements de cette transition. On essuie les plâtres d’un choix mal assumé, et ça commence à lasser.

Un saut de 1.7 à 8 : la modernité en trompe-l’œil

Parlons-en, de ce passage direct de 1.7 à 8. Officiellement, c’était une décision stratégique : adopter un versioning sémantique (SemVer) avec du MAJOR.MINOR.PATCH, rendre la numérotation plus claire et signaler une « évolution majeure ». Fini le 1.x hérité des débuts, place à un grand 8 pour se caler sur Symfony 4.4 (puis 6.4 dans la 9) et montrer qu’on suit les pratiques modernes. Sauf que dans les faits, ça sent le paradoxe à plein nez. On nous vend une clarification, mais pour beaucoup, ça ajoute juste de la confusion : après des années en 1.x, ce bond donne l’illusion d’un renouveau alors qu’on traîne encore les casseroles de choix bancals. C’est comme repeindre une vieille bagnole en criant « voiture neuve » – le moteur tousse toujours. Le versioning, c’est bien joli, mais si c’est pour masquer une modernisation laborieuse, ça ne trompe personne.

Guzzle : un symbole des décisions bancales

Prenez l’exemple de Guzzle, cette bibliothèque HTTP qu’ils ont fini par virer par défaut dans la version 9. Pendant des années, elle a alourdi le cœur du système pour… pas grand-chose, vu que peu de modules natifs l’utilisaient vraiment. La retirer, c’est une bonne idée sur le tard, mais ça montre surtout l’improvisation des choix passés. On intègre une dépendance lourde, on laisse les développeurs s’appuyer dessus, et puis on la dégage en disant « adaptez-vous ». C’est typique de cette manie de PrestaShop à courir après les technos modernes sans plan clair, pour ensuite reculer face au bazar créé. Les petites boutiques et les devs indépendants trinquent, et nous, on reste là à regarder le spectacle.

Smarty vs Twig : le symbole d’une dérive

Et puis il y a cette bascule de Smarty à Twig. Smarty, c’était le moteur de templates qui collait parfaitement à l’esprit PrestaShop : simple, direct, flexible. On pouvait ajuster un thème en deux coups de cuillère à pot, sans doctorat en informatique. Twig, lui, arrive avec ses promesses de modernité et de séparation stricte entre logique et présentation. Sauf que dans la vraie vie, ça complique tout. La syntaxe est plus verbeuse, les ajustements demandent plus de gymnastique, et pour quoi ? Une performance à peine meilleure si t’as un cache bien réglé – et encore, sur un petit serveur, tu sens la différence dans le mauvais sens. Le pire ? PrestaShop 8 et 9 prétendent uniformiser l’usage de Twig, mais Smarty traîne encore dans certains coins du système. Sérieusement ? On change de moteur pour ne pas aller au bout du truc ? C’est presque comique.

WooCommerce, la réalité qui s’impose

En bon patriote, j’ai soutenu PrestaShop dès le début. Une solution française face aux géants américains, ça avait du sens, ça me parlait. Mais aujourd’hui, je me retrouve à bosser de plus en plus avec WooCommerce, presque à contrecœur. Pourquoi ? Parce que la réalité prend parfois le pas sur les idéaux. WooCommerce, avec WordPress, c’est moche à coder, c’est brouillon, mais au moins, ça reste accessible, rapide à déployer, et ça fait le job sans te demander de réécrire la moitié du système pour ajouter un bouton. PrestaShop, lui, s’est enfermé dans une tour d’ivoire technique, oubliant au passage ceux qui l’ont porté : les petits commerçants, les indépendants, les bidouilleurs comme moi.

Et maintenant ?

Je ne dis pas que PrestaShop est mort. Il a encore ses forces : une communauté fidèle, des modules sympas, une base solide. Mais il faut ouvrir les yeux : depuis la 1.6, les choix stratégiques ont plus freiné qu’ils n’ont propulsé cette belle aventure. Symfony, Twig, Guzzle, ce saut grotesque de 1.7 à 8… c’était peut-être une bonne idée pour les grosses agences ou les projets ultra-complexes, mais pour le cœur de cible historique de PrestaShop, c’est un virage raté. Alors oui, je continue de suivre, d’espérer un retour aux sources. Mais en attendant, WooCommerce gagne du terrain sur mon disque dur… et dans mon quotidien. PrestaShop, réveille-toi avant qu’il ne soit trop tard !