PrestaShop vs WooCommerce en headless : le moteur commerce natif contre le plugin greffé sur WordPress

Depuis des années, je construis des architectures e-commerce pour des dirigeants de PME. Quand un prospect me demande « pourquoi pas WordPress avec WooCommerce ? », la question est sincère et légitime. PrestaShop vs WooCommerce : les deux sont open source, auto-hébergés, capables de tourner en headless. Mais quand on retire la façade 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 disparaît, 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 (interface utilisateur). Le front est reconstruit avec un framework moderne comme Nuxt, Next.js ou SvelteKit. Le back-office ne sert plus qu'à 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, médias, taxonomies. Le commerce y est délégué à WooCommerce, un plugin qui ajoute ses propres API et ses tables sur un socle conçu pour publier.

La question n'est donc pas « quel est le meilleur CMS ? ». C'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 détermine tout : la performance, la maintenabilité, la capacité à grandir.

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 pensés pour elle :

Chaque requête cible exactement la table dont elle a besoin. Un SELECT quantity FROM ps_stock_available WHERE id_product = 42 lit le stock sur une table indexée, sans détour. Les jointures sont propres et la base reste lisible quand le catalogue grossit.

WooCommerce : le piège EAV

WordPress repose sur un modèle de type EAV (Entity-Attribute-Value) : les contenus passent par wp_posts et leurs attributs par wp_postmeta. Un produit WooCommerce est un post de type product. Son prix, son stock, son poids, sa référence sont des lignes clé-valeur dans wp_postmeta.

Pour être juste : WooCommerce a bougé. Les commandes peuvent désormais vivre dans des tables dédiées (le stockage dit HPOS), et une table de correspondance accélère certaines recherches produit. Mais le produit lui-même, ses déclinaisons et ses attributs restent dans le couple wp_posts / wp_postmeta. Le plugin corrige les symptômes un par un ; il ne change pas le socle.

Sur un petit catalogue, les deux systèmes se comportent de manière comparable. Quand le catalogue grossit, wp_postmeta accumule les lignes et chaque requête commerce multiplie les JOIN sur cette table. C'est l'anti-pattern EAV, documenté de longue date en ingénierie logicielle comme un piège de performance.

Architecture des modules : MVC vs hooks

La façon dont chaque plateforme s'étend révèle deux philosophies.

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, ses vues Smarty ou Twig. L'ObjectModel fournit un ORM léger pour manipuler les données. Le module est un composant encapsulé dans l'écosystème.

Mon architecture repose sur une série de modules maison préfixés ac_*, chacun avec ses tables, ses contrôleurs et son cycle de vie :

• ac_autoblogarticle — file de génération IA pour le blog, avec sa table ps_ac_autoblog_queue
• ac_smartlead / ac_smartproject — CRM, kanban, tâches, automatisations
• ac_smartproducts — catalogue enrichi par l'IA
• ac_autosocialpost — publication sur les réseaux sociaux
• ac_extracmsfields — métadonnées SEO supplémentaires (dates, couvertures, FAQ)
• ac_blogcomments — commentaires natifs avec modération IA

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

WordPress : hooks, actions et wp_options

WordPress étend ses fonctionnalités par un système de hooks (actions et filtres). Les plugins s'accrochent à des événements du cœur et modifient le comportement à la volée. La configuration vit dans wp_options, une table clé-valeur où les valeurs sont souvent sérialisées en PHP.

Ce modèle est souple pour un site de contenu. Il devient fragile pour le commerce : les conflits entre plugins sont fréquents, les données sérialisées sont pénibles à migrer et à auditer, et chaque plugin ajoute des hooks qui alourdissent le traitement de chaque 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, le blog de PrestaShop est faible, celui de WordPress excellent.

Mais cette comparaison ignore une asymétrie fondamentale :

Ajouter du simple à du complexe est naturel. Un blog, ce sont des articles avec un titre, un contenu, des métadonnées. Quelques tables, un éditeur, un flux RSS. PrestaShop l'héberge sans effort.

Ajouter du complexe à du simple crée de la dette technique. Le e-commerce, ce sont des stocks en temps réel, des règles de prix, des paniers avec des réductions croisées, 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 crée une complexité accidentelle qui ne fait que croître.

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 décider quel contenu produire.

1. Analyse Search Console — repérer les requêtes à fort potentiel où le site sous-performe
2. Génération IA — le module ac_autoblogarticle rédige avec le ton du fondateur
3. Couverture automatique — l'image de couverture est générée
4. Maillage interne — les liens internes sont posés dans les articles du cocon sémantique
5. Publication sociale — ac_autosocialpost diffuse sur les réseaux
6. Notification — signal d'indexation envoyé aux moteurs

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

Souveraineté : un argument qui pèse

PrestaShop est français : fondé à Paris, avec une communauté 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.

WooCommerce appartient à Automattic, société basée à San Francisco. Les extensions critiques (paiement, livraison, analytics) sont souvent développées par des sociétés américaines soumises au Cloud Act.

Dans mon architecture PaaS souverain, chaque client dispose de son propre serveur en France, de sa propre base de données, de son propre certificat. Le client possède son code, ses données, son infrastructure — zéro lock-in.

PrestaShop vs WooCommerce : comparaison synthétique en headless

Quand WooCommerce 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 avec WooCommerce est un bon choix quand :

• le besoin principal est le contenu éditorial (média, magazine, blog professionnel) ;
• le e-commerce est secondaire, avec un petit catalogue de produits simples ;
• l'équipe interne maîtrise déjà PHP et l'écosystème WordPress ;
• le budget ne permet pas une architecture headless sur mesure.

Mais dès que le e-commerce devient le cœur de l'activité — catalogue étendu, déclinaisons, multi-transporteur, règles de prix — construire sur un moteur de blog devient un pari risqué. Et si vous partez de Shopify plutôt que de WordPress, le raisonnement est le même : je le détaille dans le comparatif PrestaShop ou Shopify.

Le vrai choix : moteur natif ou plugin greffé

La décision se résume à une question de fondations. Un bâtiment peut être 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, conformité fiscale, multi-devises. Il a besoin de fondations pensées 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 headless, cette distinction n'est pas un détail — c'est tout.

Vous dirigez une PME et vous cherchez une architecture e-commerce headless solide, souveraine, avec un blog IA-natif ?

Écrivez-moi : contact@alexandrecarette.fr — on parle de votre projet, sans engagement.

Sources et références

• PrestaShop DevDocs — documentation du webservice PrestaShop 8
• WordPress Developer Resources — REST API Handbook
• WooCommerce — documentation de la REST API
• Entity-Attribute-Value model — article de référence (anti-pattern EAV)

Approfondir dans l'Academy

Module : Architecture Headless de A à Z →

Articles dans le même univers

• PrestaShop ou Shopify en 2026 : les inconvénients de chacun, chiffres en main
• Les 3 Gatekeepers qui contrôlent votre e-commerce — s'en libérer
• Boutiques IA en 2026 : le monde code le commerce, l'Europe choisit
• E-commerce 2026 : votre boutique doit devenir un média (Flywheel)