PrestaShop vers WooCommerce : Pourquoi j’ai migré l’intégralité de mon parc

Le point de non-retour

Si vous avez lu mon analyse sur la modernisation ratée de PrestaShop 8, vous savez que le moteur tousse. Aujourd’hui, je vous explique pourquoi j’ai décidé de changer de voiture.

Le déclic n’est pas venu d’un bug catastrophique ni d’une incompatibilité module qui aurait planté une boutique en plein Black Friday. Non. Le point de rupture a été beaucoup plus insidieux : la perte de confiance dans la trajectoire du projet. Quand une plateforme e-commerce ne sait plus si elle est un logiciel libre ou un produit SaaS déguisé, quand ses propres contributeurs ne savent plus quelle version numéroter ni comment documenter les breaking changes, il est temps de regarder ailleurs.

Parce que mon métier n’est pas de debugger des abstractions Symfony mal digérées à 23h un dimanche soir. Mon métier, c’est de construire des outils de vente qui fonctionnent, qui évoluent, et qui ne plombent pas la trésorerie de mes clients avec des frais de maintenance absurdes.

La thèse est simple : on ne peut plus construire l’avenir de ses clients sur une plateforme qui ne sait plus où elle va. Et après quatre ans de patience face à la promesse d’un « PrestaShop moderne », j’ai migré l’intégralité de mon parc client vers WooCommerce. Pas par idéologie. Par pragmatisme.

Voici pourquoi.

1. Le flou artistique : « Project » vs « Edition »

Je ne vais pas revenir sur les détails techniques de la version 8. C’est déjà fait dans l’article précédent. Parlons plutôt de ce qui tue vraiment une plateforme open source : le flou de gouvernance.

PrestaShop a décidé de scinder son écosystème en deux entités distinctes :

• PrestaShop Project : la version « communautaire », open source, gratuite.
• PrestaShop Edition : la version « professionnelle », avec support, modules premium, et roadmap prioritaire.

Sur le papier, c’est cohérent. Dans la pratique, c’est un cauchemar de positionnement pour tout prestataire qui engage sa responsabilité professionnelle.

Le risque pour les agences

Quand un client vous demande quelle version installer, vous lui répondez quoi ? La version « Project » qui sert ouvertement de laboratoire bêta pour les features qui finiront peut-être dans « Edition » ? Ou la version « Edition », stable certes, mais qui vous rend dépendant d’un éditeur qui peut changer ses conditions tarifaires du jour au lendemain ?

Le problème n’est pas l’existence d’une version payante. Le problème, c’est que personne ne sait vraiment quelle est la version de référence pour un projet e-commerce sérieux en 2026. Deux numérotations. Deux cycles de release. Deux philosophies.

L’écosystème des modules qui se fragmente

Et les développeurs de modules dans tout ça ? Vous croyez vraiment qu’ils vont maintenir deux versions distinctes de chaque module pour couvrir les deux branches ? Non. Ils vont choisir. Et devinez laquelle ? Celle qui rapporte de l’argent : Edition.

Résultat : si vous restez sur « Project », vous vous retrouvez avec un écosystème de modules qui s’étiole progressivement. Et si vous basculez sur « Edition », vous acceptez de devenir captif d’un modèle économique que vous ne maîtrisez pas.

C’est précisément ce genre d’incertitude stratégique qui m’a poussé vers la sortie.

Et PrestaShop 9.1 dans tout ça ? La version 9.1 est sortie il y a quelques semaines (mars 2026) avec Hummingbird 2.0, PHP 8.5, et des promesses d’amélioration de la stabilité. Bien. Mais le fond du problème reste inchangé : la dette technique accumulée, le flou de gouvernance entre Project et Edition, et la cohabitation Smarty/Twig. Une nouvelle version ne résout pas 10 ans de décisions architecturales discutables. Elle ne fait que repousser le problème d’un an.

2. La fatigue de la maintenance (Le coût caché)

Parlons argent. Parlons temps. Parlons de ce qui compte vraiment pour un client : le coût d’opportunité.

L’exemple des Hooks : le symbole de l’absurdité

Vous voulez savoir pourquoi j’ai craqué ? Parce que sur PrestaShop, afficher plusieurs fois le même hook sur une page relève du parcours du combattant. Un concept de base en développement web moderne, réutiliser un composant, devient un combat technique inutile à cause d’un système de hooks mal pensé qui date de PHP 5.

Sur WordPress/WooCommerce, vous utilisez do_action() autant de fois que vous voulez. C’est évident. C’est prévisible. Sur PrestaShop, vous vous retrouvez à patcher le core ou à ruser avec des modules tiers pour contourner une limitation architecturale qui n’a aucune raison d’exister.

Les moteurs de templates : Smarty ET Twig (oui, les deux)

Et pendant qu’on parle d’incohérences architecturales, parlons des moteurs de templates.

PrestaShop a décidé de migrer de Smarty vers Twig. Jusque-là, c’est compréhensible : Smarty est dépassé, Twig est plus moderne et mieux intégré à Symfony. Sauf que PrestaShop a fait le choix hallucinant de garder les deux moteurs en parallèle. Pourquoi ? Parce que :

Le thème « Classic » (toujours livré par défaut) : Il utilise Smarty. PrestaShop ne peut pas le supprimer sans casser des milliers de boutiques existantes qui en dépendent. Donc Smarty reste.

Le thème « Hummingbird » (le nouveau thème « moderne ») : Il utilise Twig. C’est la nouvelle référence, celle qu’on est censé utiliser pour les projets sérieux.

Vous comprenez l’absurdité ?

Pour un développeur de parc, c’est un cauchemar :

• Vous devez maintenir deux compétences de templating différentes selon le thème utilisé par le client.
• Vous ne pouvez pas mutualiser vos composants custom entre boutiques si l’une tourne sur Classic et l’autre sur Hummingbird.
• La documentation PrestaShop mélange allègrement les exemples Smarty et Twig sans toujours préciser lequel s’applique à quelle version/thème.
• Les modules tiers doivent souvent fournir deux jeux de templates (.tpl pour Smarty, .html.twig pour Twig) pour être compatibles avec les deux écosystèmes.

Comparaison avec WooCommerce : Un seul moteur de templates (PHP natif dans les fichiers .php du thème, ou builders comme Elementor/Gutenberg pour les pages). Pas de cohabitation schizophrène. Une seule syntaxe à maîtriser.

Cette double stack ne sert qu’à masquer un problème de fond : PrestaShop n’ose pas assumer une vraie rupture de compatibilité qui ferait mal pendant 6 mois mais assainirait l’écosystème pour les 10 prochaines années. Résultat : on traîne le boulet Smarty ad vitam æternam.

Métaphore : C’est comme essayer de construire une maison où le rez-de-chaussée est en briques (Smarty) et l’étage en impression 3D (Twig). Ça tient debout. Mais personne ne sait quel ciment utiliser entre les deux. Et quand il faut rénover, vous devez faire venir deux entrepreneurs différents qui ne se parlent pas.

Le coût réel pour le client

Comparons factuellement deux scénarios :

Scénario A (PrestaShop) : Un client veut modifier l’affichage de la page produit.

• 1h pour comprendre quel template Twig est appelé (cascade de surcharges Symfony opaque)
• 2h pour debugger pourquoi le hook ne s’affiche pas (module tiers a surchargé le contrôleur)
• 1h pour tester la compatibilité mobile (conflits CSS entre back-office legacy et moderne)

Total : 4 heures, dont 3h de maintenance technique pure, 1h de valeur réelle.

Scénario B (WooCommerce) : Même demande.

• Identifier le bon hook (woocommerce_before_add_to_cart_form)
• Injecter le code dans le thème enfant
• Tester

Total : 1h30, temps utile concentré sur la feature.

La différence ? Le client PrestaShop paie pour maintenir l’existant. Le client WooCommerce paie pour générer du business.

L’argument de la « puissance native » qui s’effondre

Les défenseurs de PrestaShop vont objecter : « Oui mais PrestaShop est plus puissant nativement pour le multi-langues, le multi-devises, le B2B… »

Peut-être. Mais à quel prix ? Si cette « puissance native » se paie en lourdeur de back-office, en bugs récurrents sur les mises à jour, et en dette technique chronique, elle ne vaut rien.

WooCommerce avec les bons plugins (WPML, Multi-Currency, WooCommerce Wholesale) fait exactement la même chose, en plus stable, en plus documenté, et en 3 fois moins de temps de configuration.

3. Le choix du nouvel écosystème : Pourquoi WooCommerce ?

Casser le mythe : Non, WooCommerce n’est pas « juste pour les petits sites »

Première objection des puristes PrestaShop : « WooCommerce, c’est pour les boutiques à 50 produits. Pour du sérieux, il faut du vrai e-commerce. »

Faux. Archi-faux. J’ai des clients qui font 200k€/an de CA avec des catalogues de 2000+ références sur WooCommerce. Le problème n’est pas la stack. Le problème, c’est l’architecture.

WooCommerce mal configuré, avec 40 plugins qui se marchent dessus et un thème surchargé de jQuery legacy, c’est lent. Mais PrestaShop avec 60 modules qui écrasent les mêmes hooks et un template non optimisé, c’est tout aussi catastrophique.

La différence ? La prévisibilité de l’écosystème.

La prévisibilité : un socle stable

WordPress a 20 ans. WooCommerce en a 15. L’API est documentée. Les hooks sont stables. Les breaking changes sont annoncés plusieurs versions à l’avance avec des guides de migration clairs.

Quand vous développez un plugin WooCommerce en 2026, vous pouvez raisonnablement parier qu’il fonctionnera encore dans 3 ans sans refonte majeure. Essayez d’en dire autant avec PrestaShop post-1.7.

Cette prévisibilité a une valeur économique concrète pour mes clients :

• Moins de bugs silencieux après les mises à jour
• Moins de temps passé en maintenance corrective
• Moins de modules payants « essentiels » pour corriger des lacunes du core

L’agilité : la prise en main client

Un client PrestaShop qui veut modifier un texte sur sa page d’accueil doit :

1. Se connecter au back-office (déjà, expliquer qu’il y a deux interfaces selon les pages…)
2. Naviguer dans des menus labyrinthiques
3. Comprendre la logique « blocs » du page builder intégré (qui change selon les thèmes)
4. Espérer ne pas casser la mise en page responsive

Un client WooCommerce/WordPress :

1. Se connecte
2. Modifie la page d’accueil comme un document Word avec Gutenberg ou Elementor
3. Prévisualise
4. Publie

C’est cette simplicité qui fait que mes clients ne m’appellent plus à 18h pour « juste changer une phrase ».

4. Le « 1-Click » de l’angoisse

Le risque permanent de la mise à jour

Tous les prestataires PrestaShop connaissent cette scène. Vous êtes dans le back-office. Une notification vous informe qu’une mise à jour mineure est disponible (genre 8.1.3 → 8.1.4). Vous savez qu’elle corrige des failles de sécurité critiques. Vous devez l’installer.

Mais vous savez aussi, par expérience, qu’il y a statistiquement 50% de chances que cette mise à jour « mineure » casse :

• Un module tiers qui n’a pas suivi la roadmap PrestaShop
• Un template custom qui utilisait une fonction dépréciée sans warning
• Le système de cache qui va nécessiter une purge manuelle via CLI
• Ou pire : un conflit SQL silencieux qui ne se manifestera que 3 jours plus tard quand un client appellera pour signaler que ses factures PDF sont vides

Vous cliquez. Vous priez. Et dans 1 cas sur 2, vous finissez votre nuit à restaurer un backup SQL de 4 Go en SSH pendant que votre client reçoit des emails de clients furieux qui ne peuvent pas finaliser leur commande.

Sur WooCommerce ? Vous cliquez. Ça roule. Vous testez 2-3 pages. C’est bon. Temps total : 5 minutes.

Pourquoi c’est toujours « l’enfer » en 2026 ?

Le problème ne vient plus seulement du code mal écrit ou des bugs Symfony (j’ai déjà traité ça dans mon article sur PrestaShop 8). Non, le problème vient de la structure même du processus de mise à jour.

Le saut PHP : Passer de PrestaShop 1.7 ou 8 à PrestaShop 9 demande souvent un saut de version PHP (de 8.1 vers 8.4 par exemple). L’outil de mise à jour « 1-Click Upgrade » gère très mal le moment où le code de l’ancienne version essaie de s’exécuter sur une version PHP trop récente. Résultat : la fameuse Erreur 500 ou la page blanche au milieu du processus. Vous êtes coincé avec une boutique à moitié migrée, ni fonctionnelle sur l’ancienne version, ni sur la nouvelle.

Le nettoyage post-migration : Même quand la mise à jour « réussit », vous vous retrouvez souvent avec :

• Des tables SQL fantômes de l’ancien système de cache ou de modules désinstallés qui traînent dans la base
• Des fichiers résiduels Smarty qui viennent polluer le nouveau moteur Symfony/Twig et créer des conflits de templates
• Des hooks orphelins qui pointent vers des modules qui n’existent plus, provoquant des lenteurs inexplicables en front-office

Ces scories nécessitent un nettoyage manuel en base et en fichiers. Temps estimé : 1 à 2 heures de plus.

Les modules « bloquants » : Il suffit d’un seul module natif mal mis à jour pour paralyser tout le back-office après l’upgrade. Exemple typique : psxdesign (le module de personnalisation graphique de PrestaShop) qui, après une mise à jour majeure, peut bloquer l’accès à l’ensemble du back-office avec une erreur PHP fatale. Vous devez alors :

1. Vous connecter en SSH
2. Désactiver manuellement le module en base de données (UPDATE ps_module SET active = 0 WHERE name = 'psxdesign')
3. Relancer le back-office
4. Attendre qu’une mise à jour du module soit publiée par PrestaShop (délai : de 2 jours à 2 semaines selon la gravité)

Le contraste avec WooCommerce :

Sur WordPress/WooCommerce, la mise à jour est un non-événement. Pourquoi ?

Rétrocompatibilité obsessionnelle : WordPress gère la compatibilité ascendante de manière quasi-religieuse. Les fonctions dépréciées restent fonctionnelles pendant des années avec des warnings clairs pour les développeurs. Vous avez le temps d’adapter votre code. Pas de rupture brutale.

Mode « récupération » natif : Si un plugin WooCommerce (ou n’importe quel plugin WordPress) plante après une mise à jour, WordPress détecte automatiquement le problème et bascule en mode récupération. Ce mode :

• Isole le plugin fautif
• Vous permet d’accéder au back-office pour désactiver le plugin en un clic
• Ne fait pas tomber toute la boutique

Vous corrigez le problème en 2 minutes depuis l’interface admin. Pas besoin de SSH, pas besoin de manipuler la base en SQL brut, pas besoin de paniquer à 2h du matin.

Gestion des versions PHP : WordPress annonce les prérequis PHP des mois à l’avance, et les plugins majeurs (dont WooCommerce) suivent cette roadmap de manière synchronisée. Quand vous mettez à jour WordPress 6.8 → 6.9, vous savez qu’il fonctionne sur PHP 8.1, 8.2, ET 8.3. Pas de saut brutal qui casse tout.

Mieux encore : WooCommerce publie des versions bêta publiques qui testent la compatibilité avec les futures versions PHP avant même leur sortie stable. Vous pouvez donc anticiper, tester en staging, et déployer sereinement. PrestaShop, lui, semble courir après la compatibilité une fois que la version stable de PHP est déjà sortie. Résultat : bugs de dernière minute, patchs d’urgence, et prestataires en stress.

La dette de la mise à jour

Comparons factuellement le processus de mise à jour pour une version mineure :

PrestaShop (version mineure 8.1.3 → 8.1.4) :

1. Backup complet : base de données + fichiers (30 min avec une base de 2 Go et 15 000 fichiers)
2. Déploiement en staging : dupliquer l’environnement de prod pour tester (20 min)
3. Mise à jour en staging : lancer le module « 1-Click Upgrade » (10 min si tout va bien, 1h si ça plante)
4. Tests manuels : vérifier que checkout, back-office, modules critiques fonctionnent (30 min minimum)
5. Corrections de bugs post-migration : parce qu’il y en a toujours (de 0 à 2h selon la gravité)
6. Mise à jour en prod : répéter les étapes 1-3 sur le serveur live (40 min)
7. Monitoring post-déploiement : surveiller les logs d’erreur pendant 24-48h

Temps total : entre 2h30 et 5h, selon si vous avez de la chance ou non.

WooCommerce (version mineure 9.1.2 → 9.1.3) :

1. Backup automatique via plugin (UpdraftPlus ou similaire) : 5 min
2. Clic sur « Mettre à jour » dans le back-office WordPress : 2 min
3. Test rapide : checkout + back-office : 5 min
4. Déploiement terminé

Temps total : 12 minutes. Et encore, je suis large.

La différence ? La prévisibilité de l’écosystème. Quand WordPress annonce une mise à jour mineure, elle ne casse pas les plugins. Parce que l’API est stable. Parce que les breaking changes sont documentés à l’avance. Parce qu’il y a une vraie gouvernance de la compatibilité ascendante.

L’obsolescence programmée des thèmes

Et puis il y a le coup de grâce : la dette graphique.

Rappelez-vous la section sur Smarty/Twig. Imaginez maintenant que vous ayez un client avec une boutique PrestaShop 1.7.8 qui tourne sur un thème custom développé en 2019 (donc Smarty). Il veut migrer vers PrestaShop 8.x pour profiter des nouvelles features et de la sécurité renforcée.

Problème : son thème custom est en Smarty. Le nouveau back-office et les nouveaux modules sont en Twig. Que se passe-t-il ?

Vous devez refaire le thème de zéro. Ou presque.

Ce n’est pas une « migration ». C’est une refonte graphique complète. Avec tout ce que ça implique :

• Reprise des templates custom page par page
• Réécriture des hooks dans la nouvelle syntaxe Twig
• Tests responsive sur tous les devices
• Régression visuelle à chasser pendant des jours

Devis pour le client : entre 5 000€ et 15 000€, selon la complexité du thème initial.

Et là, le client vous regarde avec des yeux ronds : « Mais… je veux juste mettre à jour pour être à jour. Pourquoi je dois repayer un thème ? »

Réponse honnête : Parce que PrestaShop a changé de moteur de templates sans assurer une compatibilité descendante propre. Parce que la « modernisation » n’est réelle que si vous repartez d’une installation vierge.

Sur WooCommerce ? Les thèmes sont en PHP natif depuis 15 ans. Un thème développé en 2015 fonctionne encore aujourd’hui (moyennant quelques ajustements CSS mineurs pour les nouveaux blocs Gutenberg). Pas de refonte. Pas de devis surprise.

La cage dorée : pourquoi on reste quand même

Alors pourquoi tant de marchands restent-ils sur PrestaShop malgré tout ça ?

Parce qu’ils sont coincés.

Un commerçant qui a 10 ans d’historique de commandes, 50 000 clients en base, des dizaines de modules métier intégrés (comptabilité, ERP, marketplaces), il ne peut pas migrer sur un coup de tête. C’est une opération lourde qui nécessite :

• Une extraction complète des données (commandes, clients, produits, historique)
• Une migration API propre (comme celle que j’ai développée avec StockSync)
• Une reprise manuelle des règles métier custom (promotions, calculs de frais de port, workflows spécifiques)
• Une formation des équipes sur le nouvel outil

Sans l’aide d’un expert qui maîtrise les deux écosystèmes, c’est mission impossible.

C’est précisément pour cette raison que PrestaShop peut se permettre de laisser pourrir sa dette technique : ses utilisateurs historiques sont captifs. Ils savent que partir leur coûtera 20 000€ minimum en prestation. Alors ils restent. Et ils paient la maintenance corrective. Encore et encore.

Mon travail de migration a précisément consisté à casser cette cage dorée pour mes clients. En développant des outils API-first qui extraient proprement les données sans dépendre de la structure interne de PrestaShop, j’ai pu offrir une porte de sortie viable.

Mais combien de marchands sont encore coincés faute de prestataire qui maîtrise les deux stacks ?

Conclusion : Regarder devant

Bilan de la migration : retours clients

Depuis la migration complète de mon parc vers WooCommerce (achevée en Q1 2025), les retours clients sont unanimes :

• Performance : temps de chargement des pages divisé par 2 en moyenne (grâce à un hosting optimisé WordPress et à l’élimination des modules PrestaShop legacy).
• Simplicité : formation client réduite de 3h à 1h. Ils prennent en main Gutenberg/Elementor en 20 minutes.
• Coût de maintenance : factures mensuelles en baisse de 30-40% (moins de bugs, moins de correctifs, moins d’urgences).

Aucun client n’a demandé à revenir en arrière.

Conseil aux confrères : ne pas rester par habitude

Si vous lisez cet article, c’est peut-être parce que vous sentez aussi cette fatigue PrestaShop. Ce sentiment diffus qu’on passe plus de temps à éteindre des incendies qu’à développer de la valeur.

Mon conseil : testez WooCommerce sur un projet pilote. Pas sur votre plus gros client. Sur un petit projet, où l’enjeu est limité, où vous pouvez expérimenter sans risque.

Vous verrez par vous-même la différence entre :

• Passer 2h à comprendre pourquoi un module PrestaShop casse le checkout après une mise à jour mineure.
• Passer 2h à développer une vraie feature WooCommerce qui rapporte du CA à votre client.

Le temps, c’est de l’argent. Le vôtre. Celui de vos clients. Arrêtez de le gaspiller sur une plateforme qui ne vous respecte plus.

Phrase de fin

PrestaShop a peut-être gagné Symfony. Mais il a perdu ses ambassadeurs de terrain.

Ceux qui développaient des modules gratuits par passion. Ceux qui répondaient sur les forums à 22h pour aider un confrère. Ceux qui défendaient bec et ongles la « solution e-commerce française » face à WooCommerce ou Shopify.

Aujourd’hui, ces ambassadeurs sont partis. Ou en train de partir. Parce qu’on ne construit pas une communauté sur du flou stratégique et de la dette technique chronique.

Moi, j’ai fait mon choix. Et je ne le regrette pas.