Shopware

Shopware headless avec la Store API

juin 2, 2026 4 min de lecture Alexandre Navaeian

Le commerce headless sépare le back-office (gestion du catalogue, des commandes, des clients) du front-end (l’expérience d’achat). Shopware 6 est conçu pour cette architecture grâce à sa Store API. À la clé : des performances de premier ordre, une liberté de design totale et des expériences multi-canal pilotées depuis un seul back-office. Voici comment cela fonctionne concrètement et quand c’est le bon choix.

Qu’est-ce que la Store API ?

La Store API est l’interface qui expose tout le parcours d’achat — catalogue, recherche, panier, checkout, compte client — sous forme d’API REST. Un frontend développé en Vue, React, Next ou Nuxt consomme cette API et gère seul l’affichage. Shopware devient alors un moteur e-commerce piloté à distance : il garde la logique métier, les prix, les stocks et les règles, mais ne rend plus aucune page lui-même.

C’est la différence fondamentale avec le mode classique, où Shopware sert lui-même les pages via son Storefront en Twig. En headless, le Storefront est tout simplement remplacé par votre propre application front.

Store API vs Admin API : ne pas les confondre

Shopware expose deux API distinctes, et choisir la bonne est essentiel.

	Store API	Admin API
Public visé	L’acheteur, côté front	Le back-office et les intégrations
Authentification	Clé d’accès du sales channel	OAuth (client credentials)
Usage	Catalogue, panier, checkout, compte	CRUD complet, imports, ERP/PIM
Exemple	Frontend découplé	Synchronisation des stocks depuis un ERP

Un projet headless consomme la Store API pour l’expérience d’achat, et réserve l’Admin API aux flux d’administration et aux intégrations ERP/PIM.

Comment se déroule un parcours headless

Tout commence par une clé d’accès rattachée à un sales channel de type « API ». Le front l’envoie à chaque requête via l’en-tête sw-access-key. Shopware renvoie alors un jeton de contexte (sw-context-token) qui identifie la session du visiteur — panier, langue, devise, client connecté. Ce jeton accompagne ensuite chaque appel.

// 1. Ouvrir un contexte (session) côté client
fetch('https://boutique.example/store-api/context', {
  headers: {
    'sw-access-key': 'VOTRE_CLE_ACCES_SALES_CHANNEL',
    'Content-Type': 'application/json'
  }
});

Une fois le contexte établi, ajouter un produit au panier devient un simple appel POST :

// 2. Ajouter un produit au panier
fetch('https://boutique.example/store-api/checkout/cart/line-item', {
  method: 'POST',
  headers: {
    'sw-access-key': 'VOTRE_CLE_ACCES_SALES_CHANNEL',
    'sw-context-token': 'JETON_DE_SESSION',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    items: [ { type: 'product', referencedId: 'ID_DU_PRODUIT', quantity: 1 } ]
  })
});

Le reste du tunnel suit la même logique : récupération du catalogue, gestion du compte client, puis création de la commande. Le front orchestre l’interface, Shopware reste l’autorité sur les données.

Pourquoi passer headless ?

Trois bénéfices majeurs justifient l’architecture découplée :

Performance maximale : un front statique ou en rendu serveur (SSR) ultra-rapide, indépendant du temps de génération des pages côté Shopware.
Liberté créative totale : l’interface n’est plus contrainte par le Storefront ; vous bâtissez exactement l’expérience voulue, animations et interactions comprises.
Multi-canal : un site web, une app mobile, des bornes ou un marketplace peuvent tous consommer la même Store API, depuis un unique back-office.

Quels outils pour le front ?

Vous pouvez tout construire à la main, mais l’écosystème propose des accélérateurs. Shopware fournit ses propres composable frontends (briques Vue/Nuxt prêtes à consommer la Store API), et des solutions comme Vue Storefront/Alokai s’intègrent à Shopware. Le choix dépend de l’équipe front et du niveau de personnalisation visé : partir d’une base composable fait gagner des semaines, repartir de zéro offre un contrôle total.

Les points d’attention

Le headless ajoute une vraie complexité qu’il faut assumer :

SEO : sans rendu serveur, un front en JavaScript pur s’indexe mal. Le SSR ou la génération statique (SSG) sont quasi obligatoires, avec une gestion soignée des métadonnées, des URLs canoniques et des redirections.
Stack à maintenir : vous gérez désormais deux applications (Shopware + front) et leur déploiement.
Cache : il faut penser la stratégie de cache du front et l’invalidation lors des changements de prix ou de stock.
Coût : le ticket d’entrée est plus élevé qu’un Storefront classique bien optimisé.

Headless ou Storefront classique ?

Le headless est pertinent pour des projets ambitieux : fort trafic, exigence de performance et d’image, besoin multi-canal, équipe front en interne. Pour une boutique de taille modeste, un Storefront Twig bien optimisé offre 90 % des bénéfices pour une fraction de la complexité. Le bon réflexe est de partir du besoin réel, pas de la hype.

Pour les bases techniques côté serveur, lisez développer un plugin Shopware 6, et pour situer Shopware face à la concurrence, Shopware vs PrestaShop. Vous envisagez une architecture découplée ? Découvrez mon offre Shopware headless ou l’ensemble de mes prestations de développeur Shopware 6 freelance.