Headless
Next.js + Shopify Storefront
Marque DTC sur Shopify Plus, ambition front élevée.
Voir la fiche techno→
Par besoin · Headless
Reprendre la main
sur le front sans casser le back.
Découpler le front de la plateforme commerce, c’est se redonner liberté éditoriale et perf au prix d’une stack plus exigeante. On le fait quand l’enjeu de marque le justifie, pas par mode.
SYMPTÔMES
Six signaux qu’un projet headless devient pertinent.
Le headless n’est pas une cible par défaut. C’est un investissement qu’on défend dans des contextes précis éditorial fort, perf saturée, multi-canal. Voici les situations où il devient le bon choix.
01
Ambition éditoriale forte que la plateforme plombe
Vous voulez raconter votre marque comme un magazine, mais le theme commerce vous limite à des grilles produits. Le contenu coûte trop cher à produire.
02
Performance front qui plafonne malgré les optims
Le theme natif a été optimisé à fond, vous avez gratté tous les quick wins, mais le LCP reste à 3 secondes. La plateforme rend du HTML qu’on ne peut pas alléger plus.
03
Marque multi-canal
Web, app native, kiosques en boutique, partenaires API vous avez besoin de rendre votre catalogue partout, avec des UI adaptées à chaque support.
04
Équipe produit interne qui veut produire vite
Designers + dev front + content en boucle hebdomadaire la plateforme commerce n’est pas leur outil, ils ont besoin d’un repo Git + d’un CMS éditorial dédié.
05
Tunnel custom impossible sur la plateforme
Configurateur produit, abonnement avec règles fines, panier multi-vendeur le tunnel natif ne plie pas, on le contourne avec des hacks fragiles.
06
SEO qui souffre du rendu serveur
Le HTML rendu par la plateforme commerce contient trop de JS critique, des balises meta qu’on ne contrôle pas, un Core Web Vitals plafonné.
APPROCHE
Quatre étapes pour ne pas se prendre les pieds dans le tapis.
Un projet headless mal cadré coûte deux fois plus cher qu’une refonte classique. La méthode commence par décider, sobrement, ce qu’on découple et ce qu’on garde sur la plateforme.
01
Périmètre
On cartographie ce que vous voulez héritier de la plateforme commerce (catalogue, panier, paiement, comptes) et ce qu’on prend en main côté front (rendering, navigation, contenu, perf). Tout n’est pas à découpler souvent, juste les pages les plus stratégiques.
Livrables
Diagramme front / back
Périmètre signé
Risques cartographiés
02
Choix techno
Couche front (Next.js, Astro, Remix), couche commerce (Shopify Storefront API, Adobe Commerce GraphQL, BigCommerce, Salesforce), CMS éditorial (Sanity, Contentful, Hygraph). On défend chaque choix avec un critère : pas de framework du moment, des outils éprouvés en prod.
Livrables
Stack signée + ADR
Coût d’hébergement estimé
Plan d’ops
03
Build itératif
On commence par 1 ou 2 templates clés (home, fiche produit) pas big bang. Mise en prod incrémentale via réécriture URL ou CDN. Chaque page ajoutée passe les budgets perf + SEO avant d’être basculée.
Livrables
Templates clés en prod
Switch progressif sur le trafic
Budgets perf + SEO en CI
04
Run + observabilité
Un front custom n’est pas un theme il faut quelqu’un pour l’opérer. On définit qui fait quoi (vous, nous, mixte), on met en place le monitoring (RUM, erreurs, alertes), et on documente l’ensemble pour réduire la charge mentale d’une équipe interne.
Livrables
Runbook complet
Monitoring + alertes en prod
Onboarding équipe interne
CE QUE ÇA CHANGE
Le delta réel entre headless et plateforme native.
Un projet headless ne change pas tout. Il change ce qu’on en attend front et marque. Voici les écarts qu’on observe sur les axes critiques.
Plateforme native
Headless
Time-to-page
Limité au theme
Architecte choisit
Liberté éditoriale
Bornée par le theme
CMS dédié, multi-format
Perf mobile
Plafond élevé
Cible Core Web Vitals atteignable
Coût de dev front
Theme + customs
1,5–2× theme natif
Complexité ops
Une plateforme
Plateforme + front + CMS
Autonomie marketing
Admin commerce
CMS éditorial dédié
STACK POSSIBLE
Quatre directions techniques selon la couche commerce.
Le headless n’est qu’à moitié un sujet techno : la couche commerce derrière dicte 80% des choix. Voici les variantes qu’on défend selon la plateforme conservée.
Headless
Next.js + Adobe Commerce GraphQL
Catalogue complexe Adobe Commerce, besoin d’un front léger.
Voir la fiche techno→
Headless
Astro + Shopify
Site éditorial fort, peu de logique côté client, SEO max.
Voir la fiche techno→
Hybride
Remix + plateforme
Tunnels custom complexes, rendering serveur natif privilégié.
Voir la fiche techno→
USE CASE TYPE
À quoi ressemble un projet headless qu’on a mené.
Une trajectoire-type, anonymisée, d’une marque DTC mid-market passée d’un theme Shopify Plus à un front Next.js sur l’API Storefront.
01 · Point de départ
Theme Shopify Plus saturé, ambition éditoriale forte (rich content, magazine produit), perf mobile à 65, équipe interne avec un dev React.
02 · Décision
Migration headless sur Next.js + Shopify Storefront API + Sanity pour l’éditorial. Périmètre : home, catégories, fiches produits, contenu marque. Le checkout reste Shopify natif.
03 · Trajectoire
Périmètre 4 sem, build par template avec mise en prod progressive sur 5 mois, bascule complète au sixième mois sur un dimanche soir hors saison.
04 · Ce que ça débloque
Perf mobile à 92, conversion +15% sur la home, et une équipe produit qui livre une nouvelle landing par semaine sans toucher au catalogue Shopify.
FAQ
Les questions qu’on entend sur le headless.
Le SEO ne va-t-il pas en pâtir ?
Non si on rend correctement côté serveur (SSR/SSG/ISR). Au contraire on contrôle bien mieux les balises, le HTML rendu, les Core Web Vitals. La condition : un dev qui maîtrise vraiment l’hydratation et le rendering.
Quels coûts cachés ?
Le hosting du front (Vercel, Netlify, votre infra), le CMS éditorial (souvent payant à la doc/utilisateur), et surtout le run un front custom demande qu’on le maintienne, contrairement à un theme géré par la plateforme.
Quelle équipe pour maintenir ça ?
Au minimum un dev front senior à demi-temps en interne, ou une agence d’ops dédiée. Si vous n’avez ni l’un ni l’autre, le headless n’est pas pour vous restez sur le theme.
Peut-on revenir en arrière ?
Tant qu’on n’a pas migré le checkout, oui on peut redéployer le theme natif en quelques jours. Une fois le checkout custom, le retour devient un projet à part entière.
Votre marque mérite-t-elle un front sur-mesure ?
Un atelier de cadrage de deux jours pour décider headless oui, headless partiel, ou refresh sur la plateforme. Document écrit, pas d’engagement après.