PrestaShop Headless vs WordPress : le vrai choix e-commerce

Depuis onze ans, je construis des architectures e-commerce pour des dirigeants de PME. Quand un prospect me demande "pourquoi pas WordPress ?", la question est sincère et légitime. Les deux sont open source, auto-hébergés, capables de fonctionner en headless. Mais quand on retire la façade frontale et qu'il ne reste que l'API, la différence entre un moteur de commerce natif et un moteur de blog avec un plugin commerce devient impossible à ignorer.

Headless : quand la façade disparait, seul le moteur compte

Cet article fait partie de notre dossier Stratégie › positionnement.

Le headless, c'est la séparation stricte entre le back-office (données, logique métier, API) et le front-end (interface utilisateur). Le front-end est reconstruit à partir de zéro avec un framework moderne comme Nuxt 3, Next.js ou SvelteKit. Le back-office ne sert plus qu'a exposer une API.

Cette séparation révèle la nature profonde de chaque outil. PrestaShop expose une API qui parle commerce : produits, déclinaisons, stocks, paniers, commandes, clients, transporteurs. WordPress expose une API qui parle contenu : articles, pages, medias, taxonomies. Le e-commerce est délégué a WooCommerce — un plugin qui greffé des tables supplémentaires sur un schema conçu pour le blog.

La question n'est pas "lequel est le meilleur CMS ?". La question est : "quand il ne reste que l'API, laquelle parle nativement votre métier ?"

Modèle de données : la fracture invisible

C'est ici que la différence est la plus profonde — et la plus invisible pour un décideur non technique. Le modèle de données determine tout : la performance, la maintenabilité, la scalabilité.

PrestaShop : des tables métier dédiées

PrestaShop stocke chaque entité commerce dans sa propre table SQL, avec des colonnes typées et des index optimisés :

Table	Fonction	Colonnes clés
ps_product	Catalogue produit	reference, prix, poids, EAN13, UPC
ps_order	Commandes	total_paid, id_carrier, id_cart, statut
ps_cart	Paniers	id_customer, id_currency, date_add
ps_stock_available	Stocks en temps réel	quantity, id_product_attribute, id_shop
ps_product_attribute	Déclinaisons	taille, couleur, reference spécifique
ps_shop	Multi-boutique natif	id_shop_group, nom, domaine

Chaque requête SQL cible exactement la table dont elle a besoin. Un SELECT * FROM ps_stock_available WHERE id_product = 42 renvoie le stock en une milliseconde. Les jointures sont propres, les index performants, la base reste rapide a 50 000 produits.

WordPress + WooCommerce : le piège EAV

WordPress utilisé un modèle EAV (Entity-Attribute-Value) : toutes les données passent par deux tables — wp_posts et wp_postmeta. Un produit WooCommerce est un post de type product. Son prix, son stock, son poids, sa reference sont stockes comme des lignes dans wp_postmeta.

Critère	PrestaShop	WordPress + WooCommerce
Architecture	Tables dédiées par entité	EAV (wp_posts + wp_postmeta)
Prix d'un produit	Colonne price dans ps_product	Ligne meta_key='_price' dans wp_postmeta
Stock	Table ps_stock_available	Ligne meta_key='_stock' dans wp_postmeta
Performance 5000+ produits	Requetes rapides (index natifs)	Dégradation progressive (JOINs wp_postmeta)
Multi-boutique	Natif (ps_shop)	Multisite = reseau de blogs
Déclinaisons produit	Table ps_product_attribute	Posts enfants (type product_variation)

À 500 produits, les deux systèmes se comportent de manière comparable. À 5 000 produits, wp_postmeta contient des centaines de milliers de lignes et chaque requête commerce nécessite plusieurs JOIN sur cette table. C'est l'anti-pattern EAV — documenté depuis des décennies en ingénierie logicielle comme un piège de performance.

Architecture des modules : MVC vs hooks

La façon dont chaque plateforme permet d'étendre ses fonctionnalités révèle une philosophie radicalement différente.

PrestaShop : des modules MVC structurés

Un module PrestaShop suit le pattern MVC (Modèle-Vue-Contrôleur). Il possède ses propres tables SQL, ses contrôleurs AJAX, ses vues Smarty ou Symfony. L'ObjectModel fournit un ORM léger pour manipuler les données. Le module est un micro-service encapsule dans l'écosystème PS.

Mon architecture repose sur 26 modules propriétaires préfixés ac_*. Chaque module a ses propres tables, ses propres contrôleurs, son propre cycle de vie :

• ac_autoblogarticle — File de génération IA pour le blog, avec table ps_ac_autoblog_queue
• ac_smartlead / ac_smartproject — CRM complet, kanban, taches, automations
• ac_smartproducts — Gestion catalogue enrichie par l'IA
• ac_autosocialpost — Publication automatique sur LinkedIn, X, Facebook, Instagram
• ac_extracmsfields — Métadonnées SEO supplémentaires (dates, covers, FAQ)
• ac_blogcomments — Système de commentaires natif avec modération IA

Le moteur est open source. Les pieces sont propriétaires. C'est le modèle Red Hat appliqué au e-commerce : le client possède son code, ses données, son serveur — mais la valeur est dans l'expertise d'intégration et les modules métier.

WordPress : hooks, actions et wp_options

WordPress etend ses fonctionnalités via un système de hooks (actions et filtres). Les plugins s'accrochent a des événements du core et modifient le comportement à la volée. Les données de configuration sont stockees dans wp_options — une table cle-valeur ou les valeurs sont souvent sérialisées en PHP.

Ce modèle est flexible pour un blog. Il devient fragile pour le commerce : les conflits entre plugins sont fréquents, les données sérialisées dans wp_options sont difficiles à migrer ou a auditer, et chaque plugin ajoute des hooks qui ralentissent le cycle de vie de la requête.

Le blog : la fausse faiblesse de PrestaShop

C'est l'argument le plus utilisé en faveur de WordPress : "PrestaShop n'a pas de blog". C'est vrai — nativement, les capacites blog de PrestaShop méritent un 3 sur 10. WordPress mérite un 10 sur 10.

Mais cette comparaison ignore une asymetrie fondamentale :

Direction	Difficulté	Résultat
Ajouter du blog a un moteur e-commerce	Simple a complexe = faisable	Modules blog sur un socle commerce solide
Ajouter du e-commerce a un moteur de blog	Complexe a simple = dette technique	Plugin commerce sur un socle blog fragile

Ajouter du simple a du complexe est naturel. Un blog, c'est des articles avec un titre, un contenu, des métadonnées. Quelques tables SQL, un editeur, un flux RSS. PrestaShop peut héberger cela sans effort.

Ajouter du complexe a du simple est une source de dette technique. Le e-commerce, c'est des stocks en temps réel, des règles de prix complexes, des paniers avec des réductions croisees, du multi-devises, du multi-transporteur, de la facturation réglementaire. Greffer tout cela sur un modèle de données conçu pour des articles de blog crée une complexité accidentelle qui ne fait que croitre.

Content Intelligence : le blog IA-natif

Le blog de mon architecture n'est pas un blog manuel. C'est un système de Content Intelligence qui croise les données de la Google Search Console, les analytics de navigation et l'analyse concurrentielle pour decider quel contenu l'IA doit produire.

Le pipeline fonctionne ainsi :

1. Analyse GSC — Identifier les requêtes à fort potentiel ou le site sous-performe
2. Génération IA — Le module ac_autoblogarticle génère le contenu via Claude, avec le ton du fondateur
3. Cover automatique — ac_covergen.py crée l'image de couverture (PIL, fond + masque + titre)
4. Maillage interne — ac_pipeline.py injecte les liens internes dans tous les articles du cocon semantique
5. Publication sociale — ac_autosocialpost distribue sur LinkedIn, X, Facebook, Instagram
6. Notification SEO — Google Indexing API + IndexNow pour une indexation rapide

WordPress a un blog 10/10 manuel. Mon architecture a un blog IA-natif qui s'alimente, se publie et se maile automatiquement. La comparaison pertinente n'est pas PrestaShop vs WordPress sur le blog — c'est un blog autonome vs un blog manuel.

Souveraineté : un argument qui pèse

PrestaShop est français. Fondé a Paris, développé en France, avec une communaute francophone massive. Pour une PME française qui manipule des données clients, des commandes et des informations de paiement, c'est un argument de souveraineté concret.

WordPress est americain. WooCommerce appartient a Automattic (San Francisco). Les extensions critiques (paiement, livraison, analytics) sont souvent developpees par des societes americaines soumises au Cloud Act.

Dans mon architecture PaaS souverain, chaque client dispose de son propre VPS français, de sa propre base de données, de son propre certificat SSL. Aucune donnée ne transite par un serveur americain. Le client possède son code, ses données, son infrastructure — zero lock-in.

Comparaison synthétique : PrestaShop Headless vs WordPress Headless

Critère	PrestaShop Headless	WordPress + WooCommerce Headless
API native	Commerce (produits, stocks, commandes)	Contenu (posts, pages, medias)
Modèle de données	Tables dédiées (ps_product, ps_order)	EAV (wp_posts + wp_postmeta)
Scalabilite catalogue	50 000+ produits sans dégradation	Ralentissement a 5 000+ produits
Modules	MVC + ObjectModel + SQL propre	Hooks + wp_options sérialisé
Multi-boutique	Natif (ps_shop)	Multisite (reseau de blogs)
Blog	3/10 natif, 9/10 avec modules IA	10/10 manuel, 0/10 autonome
Souveraineté	Français (Paris)	Americain (San Francisco)
Approche headless	Le front disparait, le moteur commerce reste	Le front disparait, le moteur blog reste

Quand WordPress reste le bon choix

Cet article n'est pas un réquisitoire contre WordPress. C'est une analyse du modèle, pas du produit. WordPress est excellent quand :

• Le besoin principal est le contenu éditorial (media, magazine, blog professionnel)
• Le e-commerce est secondaire (quelques dizaines de produits simples)
• L'equipe interne maîtrise PHP + l'écosystème WordPress
• Le budget ne permet pas une architecture headless sur-mesure

Mais dès que le e-commerce devient le coeur de l'activité — avec un catalogue de plus de 500 références, des déclinaisons, du multi-transporteur, des règles de prix complexes — construire sur un moteur de blog est un pari risqué.

Le vrai choix : moteur natif ou plugin greffé

La decision se resume a une question de fondations. Un bâtiment peut etre beau quel que soit le terrain — mais un gratte-ciel ne se construit pas sur du sable. Le e-commerce est un gratte-ciel : stocks, paniers, paiements, logistique, conformite fiscale, multi-devises. Il a besoin de fondations pensees pour lui.

PrestaShop est un moteur de commerce auquel on peut ajouter un blog. WordPress est un moteur de blog auquel on a greffé du commerce. En mode headless, cette distinction n'est pas un détail — c'est tout.

Les marques citees dans cet article appartiennent a leurs propriétaires respectifs. Cette analyse est independante et n'est affiliée, sponsorisée ou approuvée par aucune des entreprises mentionnees. Les opinions exprimees reflètent l'analyse de l'auteur au moment de la publication.