Le headless est présenté tantôt comme un passage obligé, tantôt comme un effet de mode. La réalité est plus ennuyeuse et plus utile : c'est une architecture qui résout des problèmes précis, au prix d'une complexité qui ne se justifie pas pour la majorité des marques.
Ce que le headless change concrètement
Une boutique classique livre ensemble le moteur de commerce et l'affichage. Le headless sépare les deux : le back-end gère le catalogue, les commandes et le paiement, le front-end est développé à part et dialogue avec lui par API. Les deux évoluent alors indépendamment.
Cette séparation ouvre trois possibilités réelles. Composer une expérience de navigation qui ne ressemble à aucun thème existant. Servir plusieurs points de contact — site, application mobile, borne en magasin — depuis un même catalogue. Et brancher un gestionnaire de contenu tiers quand le contenu éditorial pèse autant que le catalogue.
Ce qu'elle coûte, et qui le paie
Le front-end n'est plus fourni : il est construit et maintenu par votre équipe ou votre agence. Chaque mise à jour de la plateforme peut demander une adaptation. Les fonctionnalités livrées d'origine dans un thème — recherche, filtres, tunnel d'achat, blocs de personnalisation — sont à redévelopper ou à reconstruire à partir de briques.
Les applications de l'écosystème posent la même question. Beaucoup interviennent en modifiant le thème ; sans thème, leur intégration devient un développement. Une marque qui s'appuie sur une dizaine d'applications découvre souvent ce point après la décision, pas avant.
Trois situations où le choix se justifie
Le premier cas est celui d'une expérience de navigation qui constitue elle-même l'argument de vente : configurateur, personnalisation produit poussée, parcours éditorial fortement scénarisé.
Le deuxième est l'omnicanal réel, quand le même catalogue alimente plusieurs surfaces qui ne partagent pas le même affichage.
Le troisième est la contrainte d'intégration lourde : un système d'information existant qui impose sa logique, un référentiel produit qui fait autorité ailleurs que dans la boutique. Nous traitons ce sujet dans notre article sur les connexions entre un ERP et Shopify.
Et les cas où il ne se justifie pas
Si le besoin est une identité visuelle forte, un thème sur mesure y répond, avec la maintenance et l'écosystème d'applications en prime. Si le besoin est la performance, elle se gagne d'abord sur les images, les scripts tiers et le nombre d'applications actives — un front-end découplé mal construit est plus lent qu'un thème bien tenu.
Si le besoin est l'international, les fonctionnalités multi-marchés natives couvrent aujourd'hui la plupart des cas sans changer d'architecture.
Ce que fait une agence headless
Choisir une agence headless suppose de vérifier trois choses : qu'elle sait dire non quand l'architecture n'est pas justifiée, qu'elle maintient elle-même ce qu'elle livre, et qu'elle documente les points de rupture avec l'écosystème d'applications. Une équipe qui présente le découplage comme un progrès sans contrepartie n'a pas encore maintenu de projet de ce type sur plusieurs années.
Notre position est simple : nous proposons cette architecture quand un des trois cas ci-dessus est avéré, et un thème sur mesure dans tous les autres. La question à trancher n'est pas « est-ce moderne » mais « qu'est-ce que cela nous permet de faire que nous ne pouvons pas faire autrement ».
Pour arbitrer sur votre projet, prenez rendez-vous avec un expert de notre agence.
Revu par Thomas, expert en connecteurs et développement Shopify chez LobsTTer.
