Headless commerce : utile ou coûteux pour votre boutique ?

Le headless commerce consiste à séparer la vitrine que voit le client du moteur qui gère le catalogue, le panier et le paiement, les deux communiquant par API. Cette architecture apporte une vraie liberté de conception et de canaux de vente. Elle ajoute aussi une application entière à développer et à maintenir. Elle se justifie donc rarement pour une petite boutique et devient pertinente quand la vitrine classique vous freine de façon mesurable.

Je développe des boutiques avec Sylius et Symfony, y compris avec API : ce sujet peut donc me rapporter du travail. C'est une raison de plus pour commencer par les cas où il vaut mieux s'en passer.

Le headless commerce, expliqué sans jargon

Sur une boutique classique, la même application affiche les pages et traite les commandes. En headless, la « tête », c'est-à-dire le site visible, devient une application séparée. Elle interroge le moteur par une API, une interface qui permet à deux logiciels de s'échanger des données. La documentation de Shopify le dit simplement : vous construisez et hébergez le site visible, et les API de Shopify fournissent les données produit et les fonctions de commerce.

Deux termes reviennent souvent. Le composable commerce consiste à assembler plusieurs services spécialisés, pour la recherche, le contenu ou le paiement, par exemple. MACH est un sigle, pour microservices, API-first, cloud-native SaaS et headless, défendu par la MACH Alliance, un groupement d'acteurs de ce marché. Un vendeur qui l'emploie n'a pas tort, mais vous pouvez parfaitement faire du headless sans adopter toute cette approche.

Ce que le marché propose

Shopify décrit Hydrogen comme sa boîte à outils pour construire une vitrine complète en JavaScript, et son Storefront API comme le service qui fournit produits, recherche et panier avant de renvoyer le client vers le paiement. Medusa documente des API Store et Admin ainsi qu'un modèle de départ Next.js. Sylius se présente comme une plateforme headless et open source reposant sur PHP, Symfony et API Platform, et la version 2.3 accepte API Platform 4.3 ou 5. Quant à PrestaShop 9, sa nouvelle API est orientée administration et a été annoncée comme un travail en cours.

Quand le headless commerce rapporte vraiment

Trois situations le justifient selon moi. La première : vous vendez sur plusieurs points de contact, comme un site, une application mobile, une borne en magasin, et vous voulez un seul moteur de vente derrière. La deuxième : votre expérience d'achat constitue votre avantage, avec un configurateur ou un contenu éditorial très travaillé, et le thème de votre plateforme vous bloque. La troisième : vous avez déjà une équipe de développement front-end qui peut en assumer la maintenance.

Dans ces cas, la séparation permet aussi de faire évoluer la vitrine sans toucher au moteur, et inversement. Une refonte visuelle ne risque plus de casser les commandes, à condition que le contrat d'API soit stable.

Les coûts que l'on découvre après coup

Le premier est la double maintenance. Vous avez désormais deux applications à mettre à jour, à surveiller et à héberger, et souvent deux compétences à mobiliser. Le deuxième est la perte de ce qui marchait tout seul : sur une boutique classique, de nombreuses extensions ajoutent un bloc à la page sans effort, alors qu'en headless, ce bloc doit souvent être recodé dans la vitrine. Prévisualisation des contenus, avis, recommandations de produits, suivi publicitaire : chaque élément est à vérifier.

Le troisième est le référencement, si le projet est mal conçu. Google précise que le rendu JavaScript intervient quand ses ressources le permettent, qu'un rendu côté serveur ou un prérendu reste une très bonne idée, et que tous les robots ne savent pas exécuter JavaScript. Exigez donc un rendu serveur ou un prérendu pour les pages catégorie et produit, ainsi qu'un plan de redirections si les adresses changent. Pour le reste, ma page sur la refonte sans perte de référencement explique la méthode.

Le dernier concerne le budget : je n'ai pas trouvé de chiffre public fiable et comparable pour une boutique headless, et je préfère ne pas en inventer. La logique reste simple : vous payez une vitrine en plus du moteur. Faites donc chiffrer les deux options sur le même périmètre, maintenance comprise sur trois ans.

Quand il vaut mieux s'en passer

Si votre boutique est lente, cherchez d'abord la cause : images, extensions, hébergement, requêtes. Changer d'architecture pour ce motif revient souvent à traiter le mauvais problème. Si vous êtes une petite équipe sans développeur, un thème bien réglé sur une plateforme hébergée vous servira mieux. Si la seule justification du devis est que c'est « moderne », demandez quel chiffre de votre activité doit s'améliorer, et comment il sera mesuré.

Il existe aussi un intermédiaire souvent négligé : garder une boutique classique et traiter séparément le contenu, par exemple un site vitrine rapide, relié à la boutique par de simples liens. Cette solution couvre une bonne partie des besoins de marque, à un coût bien moindre.

Les questions à poser avant de signer

Demandez qui maintient la vitrine et le moteur, et à quel prix par an. Demandez comment se passe le rendu des pages pour les robots, quelles extensions actuelles devront être recodées, et ce qui est prévu si le moteur change de version majeure. Demandez enfin une référence comparable à votre projet, à tout prestataire, moi compris.

Si un devis headless est sur votre bureau, ou si vous vous demandez si cette voie vous concerne, décrivez-moi votre situation via ma page e-commerce. Je réponds sous 24 heures ouvrées, vous échangez directement avec la personne qui écrit le code, et si une boutique classique suffit, c'est ce que je vous recommanderai.