PrestaShop headless : Nuxt 3, pas Next.js — le choix souverain

Un article récent explique comment connecter PrestaShop à Next.js via l'API Webservice pour obtenir un front headless. L'approche est techniquement correcte. Mais elle omet trois réalités que seul un praticien qui a livré des boutiques headless en production peut voir : la souveraineté de l'hébergement, la fraîcheur des données en SSR, et le tunnel de conversion complet. Après 193 projets PrestaShop et 12 mois de production headless avec Nuxt 3, voici pourquoi je ne recommande pas Next.js pour un e-commerce souverain — et ce que ça change concrètement pour le commerçant.

Le vrai problème du headless e-commerce : qui contrôle le front ?

Cet article fait partie de notre dossier PrestaShop Headless › architecture.

Quand une agence propose Next.js pour un PrestaShop headless, elle propose en réalité deux dépendances : le framework (Next.js, maintenu par Vercel) et la plateforme de déploiement (Vercel, hébergeur américain). Ce n'est pas un détail technique — c'est une décision stratégique. Vos données de navigation, vos logs d'accès, vos analytics côté serveur transitent par des serveurs américains soumis au Cloud Act. Pour un commerçant français qui vend à d'autres professionnels français, c'est un non-sens réglementaire.

Nuxt 3 s'auto-héberge sur n'importe quel VPS. Le nôtre tourne sur un serveur OVH à Gravelines, à 200 km de nos clients. Pas de CDN tiers, pas de vendor lock-in, pas de facture Vercel qui grimpe avec le trafic. Le commerçant possède son front comme il possède son back-office — c'est la même philosophie que PrestaShop lui-même.

ISR vs SSR : le stock affiché est-il le stock réel ?

L'ISR (Incremental Static Regeneration) est l'argument massue de Next.js : on génère les pages en avance, on les cache, et on les régénère périodiquement. Pour un blog, c'est parfait. Pour un catalogue e-commerce avec des stocks qui bougent, c'est un piège. Un client voit « 3 en stock », ajoute au panier, et découvre au checkout que le produit est épuisé. La page ISR affichait un cache de 60 secondes — et en 60 secondes, les 3 dernières unités sont parties.

Avec Nuxt 3 en SSR, chaque page produit est rendue côté serveur à la volée. Le stock affiché est le stock réel à la milliseconde. Le prix TTC affiché intègre la dernière règle de remise. L'état de la promotion est à jour. Pour un B2B où les quantités commandées sont élevées et les ruptures coûteuses, la différence entre un cache de 60 secondes et le temps réel n'est pas un détail — c'est de l'argent perdu ou un client frustré.

L'argument classique contre le SSR est la performance. Nos mesures de production le démentent : 0.15 seconde pour la homepage, 0.32 seconde pour une catégorie de 1 105 produits. Avec un Redis local et un Nginx bien configuré, le SSR Nuxt 3 bat l'ISR Next.js sur les métriques Core Web Vitals — sans jamais montrer un prix périmé.

Le demi-headless : le piège le plus répandu

La plupart des implémentations headless PrestaShop s'arrêtent à la page produit. Le catalogue est en Next.js ou Nuxt, mais dès que le client clique sur « Ajouter au panier », il bascule sur le thème PrestaShop classique pour le checkout. Deux designs, deux vitesses, deux expériences — et un taux de conversion qui s'effondre à la transition.

Notre approche avec Nuxt 3 headless couvre le tunnel complet : homepage, listing catégorie, fiche produit, panier, checkout, confirmation. Le thème PrestaShop est désactivé. Le front Nuxt parle directement à l'API PrestaShop pour chaque action (ajout panier, calcul livraison, paiement). Le client ne quitte jamais l'interface rapide. C'est ce que nous appelons un tunnel complet headless, par opposition au « demi-headless » qui ne fait que le catalogue.

L'API Webservice legacy vs les modules ac_ sur mesure

L'API Webservice de PrestaShop existe depuis la version 1.5. Elle fonctionne — mais elle a été conçue pour de la synchronisation ERP, pas pour un front e-commerce moderne. Pas de filtrage avancé, pas de tri multi-critères, pas d'agrégation. Pour afficher un méga-menu avec les sous-catégories et le nombre de produits par catégorie, il faut 12 appels API. Pour un filtre par attribut combiné avec un tri par prix, il faut bricoler côté client.

Notre stack utilise des modules PrestaShop sur mesure (préfixe ac_) qui exposent exactement les données dont le front a besoin, dans le bon format, en un seul appel. Un module ac_smartproducts renvoie le catalogue filtré, trié, paginé, avec les images optimisées et les variantes — en 80 ms. Un module ac_base gère l'authentification et les sessions. Le front ne bricole pas avec une API des années 2010 — il consomme une API conçue pour le headless.

La souveraineté n'est pas un argument marketing

Quand votre front tourne sur Vercel, vos logs d'accès, vos données de session et vos analytics côté serveur sont stockés aux États-Unis. Le RGPD l'interdit sauf transfert encadré — et depuis l'arrêt Schrems II, les clauses contractuelles standard ne suffisent plus pour la CNIL. Ce n'est pas de la théorie juridique : c'est le quotidien des PME qui vendent à des collectivités ou à des grands comptes avec des clauses de localisation des données.

Avec Nuxt 3 sur un VPS OVH, les données restent en France. Le commerçant peut montrer à son client B2B que toute la chaîne — base de données, back-office, front-end, analytics — tourne sur un serveur français. C'est un argument commercial concret, pas un label vide. Nos clients B2B l'utilisent dans leurs réponses à appels d'offres.

Ce que les articles « Next.js headless » ne montrent jamais

1. Le coût réel de Vercel à l'échelle. Le plan gratuit plafonne à 100 GB de bande passante. Un catalogue de 5 000 fiches produit avec des images optimisées dépasse ce seuil en deux semaines. Le plan Pro démarre à 20 $/mois/membre d'équipe — et les fonctions serverless sont facturées à l'exécution.
2. Le middleware propriétaire. Les Edge Functions de Vercel ne tournent que sur Vercel. Si vous migrez vers AWS, Cloudflare ou un VPS, votre middleware est à réécrire. Nuxt 3, via Nitro, se déploie partout : Node.js, Deno, Cloudflare Workers, ou un simple PM2 sur VPS.
3. L'absence de tunnel complet. Montrer un listing produit en Next.js est facile. Gérer le checkout complet (adresses, transporteurs, paiement, confirmation) sans revenir au thème PS demande des mois de développement spécifique. La plupart des démos s'arrêtent à la page produit.
4. La maintenance du Webservice API. L'API Webservice n'est plus activement développée par PrestaShop. Les modules sur mesure permettent de contourner les limitations sans attendre une mise à jour officielle qui ne viendra peut-être jamais.

Conclusion : le headless souverain existe, il tourne en production

Le débat Next.js vs Nuxt 3 pour PrestaShop n'est pas un débat de préférence de framework. C'est un choix d'architecture qui détermine qui contrôle les données de vos clients, combien coûte votre hébergement front, et si votre tunnel de conversion est complet ou tronqué. Next.js est un excellent framework — mais l'écosystème Vercel qui l'accompagne est incompatible avec un e-commerce souverain français.

Nuxt 3 auto-hébergé, couplé à des modules PrestaShop sur mesure et un SSR temps réel, offre ce que les architectures ISR/Vercel ne peuvent pas : la propriété totale du commerçant sur son front, ses données et ses coûts. C'est ce que nous livrons en production depuis 12 mois, avec des résultats mesurables.

Vous envisagez un headless pour votre PrestaShop ? Discutons de votre projet en 30 minutes — je vous montre une boutique en production, pas une démo.
Réserver un créneau →