E-commerce Headless
La vitrine séparée de la boutique qui la nourrit
Le back-office reste celui que vos équipes connaissent ; les pages, elles, sont générées à l’avance et servies en statique. On gagne un temps d’affichage que les boutiques classiques n’atteignent pas.
- Pages générées en statique : affichage très rapide
- Votre back-office de gestion reste inchangé
- Astro ou Gatsby selon le projet
- Surface d’attaque réduite : rien à exécuter à la demande
Le principe
Découpler l’affichage de la gestion
Ce que « headless » veut dire
Une boutique classique fait deux métiers dans le même logiciel : elle gère le catalogue, les stocks et les commandes, et elle fabrique la page au moment où le visiteur la demande. Cette seconde partie coûte cher à chaque visite — requêtes en base, calcul du rendu, exécution de modules.
Une architecture headless sépare les deux. Le back-office continue de gérer le commerce ; la vitrine est un site distinct, dont les pages sont générées à l’avance et servies telles quelles. Il n’y a plus rien à calculer à la demande, et cela se voit.
Pourquoi c’est rapide, vraiment
Parce qu’il n’y a plus de travail au moment de la visite. Nous employons Astro — ce site en est fait — ou Gatsby, un framework fondé sur React dont nous nous servons pour des blogs et des sites e-commerce. Tous deux génèrent des pages statiques, d’où une consultation très rapide.
Astro prend par ailleurs en charge les optimisations les plus poussées, celles qui permettent d’atteindre les meilleurs scores Lighthouse, et il combine plusieurs frameworks JavaScript — React, Svelte, Vue.js ou Alpine.js — pour les parties qui doivent rester interactives : panier, filtres, recherche.
Ce n’est pas une application front
La confusion est fréquente et coûteuse. Une application front de type SPA construit ses pages dans le navigateur : son référencement est très complexe, souvent impossible, et elle convient à ce qui n’a pas besoin d’être indexé.
Un site headless génère les pages avant la visite. Elles existent, elles sont complètes, elles s’indexent normalement. C’est la différence qui rend l’approche compatible avec une boutique, dont chaque fiche produit doit être trouvée.
Ce que cela coûte en contrepartie
Deux systèmes au lieu d’un, et il faut le savoir avant de s’engager :
- Plus de pièces mobiles : le back-office, la génération, l’hébergement de la vitrine, et le lien entre les deux.
- Un délai de publication : une modification de prix ou de stock doit se propager jusqu’aux pages. Cela se traite — régénération ciblée, mise à jour du stock côté navigateur — mais c’est un point à décider, pas à découvrir.
- Un intérêt qui dépend du volume : sur une petite boutique bien hébergée, le gain est réel mais rarement décisif. Le headless prend son sens quand l’audience est là, ou quand la vitesse est un argument commercial.
Nous vous dirons franchement dans quel cas vous êtes.
La mise en place
Ce que nous construisons
-
Astro ou Gatsby
Astro pour la plupart des projets — c’est l’outil de ce site. Gatsby, fondé sur React, quand l’écosystème ou l’équipe le justifient. Les deux génèrent des pages statiques.
-
Votre back-office conservé
WooCommerce, Prestashop ou une autre source : vos équipes continuent de gérer le catalogue et les commandes là où elles ont l’habitude de le faire.
-
Pages générées à l’avance
Fiches produits, catégories, contenus éditoriaux. Rien n’est calculé au moment de la visite, ce qui supprime la principale source de lenteur.
-
Les parties interactives
Panier, filtres, recherche : React, Svelte, Vue.js ou Alpine.js selon le composant. Seul ce qui doit bouger embarque du code.
-
Surface d’attaque réduite
Une page statique n’exécute rien à la demande. Il n’y a ni base à interroger ni module à exploiter sur la vitrine — l’essentiel du risque reste derrière, sur le back-office.
-
Indexable, contrairement à une SPA
Les pages existent avant la visite et s’indexent normalement. C’est ce qui distingue le headless d’une application front, dont le référencement est souvent impossible.
Questions fréquentes
Headless : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Mes équipes doivent-elles changer d’outil de gestion ?
Non, c’est même l’intérêt de l’approche : le back-office reste celui qu’elles connaissent. Ce qui change est la façon dont les pages publiques sont fabriquées — et cela ne se voit pas depuis l’administration.
Un changement de prix est-il visible immédiatement ?
C’est le point à décider en amont. Les pages étant générées à l’avance, une modification doit se propager : régénération ciblée des fiches concernées, ou lecture du prix et du stock côté navigateur pour ce qui doit être temps réel. Les deux se font ; le choix dépend de la fréquence de vos changements.
Est-ce que cela nuit au référencement ?
Au contraire, et c’est là que la confusion se fait avec les applications front. Une SPA construit ses pages dans le navigateur : son référencement est très complexe, souvent impossible. Un site headless génère les pages avant la visite — elles s’indexent normalement, et leur vitesse joue en leur faveur.
Est-ce pour toutes les boutiques ?
Non, et nous le dirons. Sur une petite boutique déjà bien hébergée, le gain est réel mais rarement décisif au regard de la complexité ajoutée. Le headless prend son sens quand l’audience est là, quand la vitesse est un argument commercial, ou quand la vitrine doit vivre indépendamment du back-office.
Peut-on garder WordPress derrière ?
Oui, c’est un cas fréquent : Gatsby se branche facilement sur WordPress, dont il récupère alors la gestion de contenu et l’interface d’administration. Avec WooCommerce derrière, on obtient une vitrine statique très rapide sur une gestion que vous connaissez déjà.
La vitesse est-elle vraiment votre problème ?
Avant de découpler quoi que ce soit, nous mesurons. Il arrive que la réponse soit un cache bien posé plutôt qu’une nouvelle architecture.