Front & intégration Avis
Headless ou thème classique : ce qu’une PME gagne vraiment à découpler sa boutique
Le commerce « headless », qui sépare la vitrine de la plateforme, est présenté comme l'avenir de l'e-commerce. Pour une PME, il double le nombre d'applications à maintenir et fait perdre une partie des extensions. Les cas où il se justifie existent, mais ils sont rares.
Le mot revient dans les appels d’offres et les présentations d’agences : headless. L’idée est de séparer la vitrine, une application JavaScript autonome construite avec Next.js ou un outil équivalent, de la plateforme de commerce, qui ne sert plus que de moteur accessible par API. Sur le papier, la promesse est séduisante : liberté totale de design, pages très rapides, possibilité de brancher plusieurs vitrines sur un même catalogue.
Pour une PME qui vend quelques centaines ou quelques milliers de produits, la question mérite d’être posée à l’envers : que coûte ce découplage, et qu’achète-t-il réellement ?
Le coût caché : les extensions
Une boutique WooCommerce ou PrestaShop tire une grande partie de sa valeur de ses extensions : paiement, sélection de point relais, avis clients, codes promo, bundles, champs personnalisés. La plupart agissent sur l’affichage de la boutique. Dans une architecture headless, cet affichage n’existe plus : chaque fonctionnalité visible doit être reconstruite dans la vitrine, à partir de ce que l’API de l’extension veut bien exposer. Une extension achetée quelques dizaines d’euros devient un développement sur mesure.
La performance ne justifie plus le découplage
Le premier argument du headless était la vitesse. Il a beaucoup perdu de sa force. Un thème classique bien construit, servi avec un cache de page, des images correctement dimensionnées et peu de scripts tiers, atteint des Core Web Vitals verts. À l’inverse, une vitrine headless mal conçue embarque des centaines de kilo-octets de JavaScript et dégrade la réactivité. La performance dépend de la qualité d’exécution bien plus que de l’architecture.
Les cas où le headless se défend
- Plusieurs points de vente sur un même catalogue : site, application mobile, bornes en magasin, qui consomment tous la même API.
- Une expérience très éloignée d’une boutique standard : configurateur de produit, parcours éditorial immersif, que le thème ne permettrait qu’au prix de contorsions.
- Une équipe technique interne capable de maintenir deux applications dans la durée.
Hors de ces cas, une solution intermédiaire couvre souvent le besoin : un thème classique, et une application JavaScript isolée pour le seul composant qui l’exige, un configurateur par exemple, branchée sur la plateforme sans la remplacer.
Ce qu’il faut retenir
- Le headless double les applications à maintenir et fait perdre l’affichage des extensions.
- Un thème classique bien exécuté atteint de bonnes performances.
- Le découplage se justifie pour le multicanal, les expériences très spécifiques ou une équipe technique interne.
Je construis des applications React et Next.js, dont un générateur de CV complet en production : je n’ai rien contre le découplage. Mais quand une PME me demande une boutique headless, je lui demande qui la maintiendra dans trois ans. Dans la grande majorité des cas, la réponse honnête est un thème bien fait, et un composant JavaScript isolé là où il apporte vraiment quelque chose. — Simon Janvier
On vous propose une refonte headless et vous doutez ? Parlons-en trente minutes, en visio, sans engagement. Demander l’audit e-commerce
