A/B Testing pour le Commerce Headless — Comment ça Marche sur Hydrogen, commercetools, Saleor & Stacks Personnalisés

Le commerce headless est désormais la norme pour les marques D2C mid-market et enterprise sérieuses. Le frontend (React, Vue, Astro, custom) vit séparément du backend commerce (Shopify, commercetools, Saleor, BigCommerce). Tu obtiens de la performance, de la flexibilité de design, et une expérience développeur propre. Tu obtiens aussi une relation différente avec les outils d'A/B testing, parce que la plupart d'entre eux ont été conçus en supposant que tu as un thème.

Cette page explique la différence architecturale entre tester sur un store basé sur des thèmes et tester sur un storefront headless, présente comment l'intégration fonctionne sur chaque stack majeur, et montre ce qui change quand tu décides entre l'expérimentation côté client et côté serveur. C'est un explainer, pas un classement d'outils.

Ce qui change quand tu passes en headless

Si vous avez déjà installé un outil de test A/B sur un thème Shopify Liquid ou un site WooCommerce, le processus était simple. Coller un snippet dans l'en-tête du thème, sauvegarder, terminé. Ce processus part du principe de trois choses qui disparaissent toutes avec le commerce headless.

Il n'y a pas d'éditeur de thème. Les plateformes monolithiques sont livrées avec un point d'intégration connu : l'en-tête du thème. En headless, votre frontend est une application personnalisée construite en React, Vue, Next.js, Hydrogen, ou un autre framework de votre choix. Le snippet de test doit s'intégrer dans le code de votre application ou se charger depuis un CDN. C'est une décision ponctuelle que prend votre développeur, mais c'est une décision, pas une étape copier-coller.

Le pipeline de build vous appartient. Hydrogen se construit avec Vite. Un storefront commercetools utilise souvent Next.js. Les frontends Saleor sont typiquement Next.js ou Nuxt. Chaque projet a son propre bundler, graphe de dépendances, et cible de déploiement. Un outil de test qui livre un seul script drop-in fonctionne partout. Un outil qui nécessite l'installation de SDK et la configuration du bundler fonctionne sur certaines stacks et pas d'autres.

Le rendu se passe différemment. Sur un store Shopify monolithique, le HTML est rendu par les serveurs de Shopify. JavaScript s'exécute dans le navigateur, et le test côté client est le choix évident. En headless, vous pourriez utiliser le rendu côté serveur (Next.js SSR), la génération de sites statiques (Hydrogen, Astro), la régénération incrémentale, ou le rendu purement côté client. Chacun change où l'assignation de variante devrait avoir lieu. Ceci devient la décision centrale pour le test A/B headless, et nous le couvrons ci-dessous.

Comment fonctionne le test A/B sur chaque stack headless majeur

Shopify Hydrogen

Hydrogen est le framework React de Shopify pour les storefronts headless, déployé sur Oxygen. Il utilise Remix sous le capot et rend côté serveur. Pour le test A/B, vous avez deux voies :

• Côté client : Charger le snippet de test dans le layout racine (root.tsx). L'assignation de variante s'exécute dans le navigateur après l'hydratation. Fonctionne pour tout test au niveau UI (héro, layout PDP, placement CTA, badges de confiance). C'est ce que la plupart des équipes choisissent.
• Côté serveur : Utiliser les fonctions loader d'Hydrogen pour récupérer les assignations de variantes depuis l'API de votre outil de test, puis les passer comme props aux composants rendus. Zéro scintillement, effort d'implémentation plus élevé.

Notez que l'app de test A/B native de Shopify ne fonctionne pas sur Hydrogen. Elle est construite pour les thèmes Liquid uniquement.

commercetools (avec n'importe quel frontend)

commercetools est un backend de commerce headless. Le frontend est typiquement Next.js, Nuxt, ou personnalisé. L'approche de test dépend du frontend, pas de commercetools lui-même. La plupart des équipes déposent un snippet dans l'en-tête HTML du frontend et exécutent côté client. Côté serveur est possible en appelant l'API de l'outil de test depuis les fonctions serveur de votre frontend.

Saleor

Saleor est une plateforme de commerce headless open-source avec une implémentation de référence de storefront Next.js ou React. Le backend Saleor ne dicte pas l'approche de test. Côté client via snippet dans _app.tsx ou layout racine est le pattern standard.

BigCommerce headless

BigCommerce supporte le headless via son storefront de référence Catalyst Next.js ou tout frontend personnalisé. Même pattern que les autres : snippet côté client dans la racine Next.js, optionnellement côté serveur via API pour les variantes SSR.

Next.js personnalisé, Remix, Astro, SvelteKit

Tout frontend de commerce personnalisé fonctionne de la même manière. Déposer le snippet de test dans le composant ou layout racine. Si vous avez besoin de variantes côté serveur (typiquement pour les pages de checkout où le scintillement est inacceptable), appeler l'API de test dans vos fonctions serveur et passer les résultats comme props.

Côté serveur vs côté client en headless : quand choisir quoi

Le headless vous donne un vrai choix architectural entre le test côté serveur et côté client. Sur un store Shopify Liquid la question s'applique à peine. En headless si.

Le test côté client fonctionne sur toutes les stacks headless. La configuration prend quelques minutes (coller un snippet dans le layout racine), l'éditeur visuel reste disponible, et les marketers peuvent exécuter des tests sans implication de l'ingénierie. Les outils dans cette catégorie incluent Varify.io, VWO, AB Tasty, et Convert. Le petit risque est le scintillement sur les réseaux lents, qu'une bonne implémentation anti-scintillement réduit à moins de 30 millisecondes.

Le test côté serveur fonctionne mieux sur les stacks SSR ou SSG comme Hydrogen, Next.js SSR, et Astro. La décision de variante se passe avant que le HTML atteigne le navigateur, donc le scintillement est zéro. Le coût est l'effort d'implémentation : chaque test nécessite l'intégration SDK, des changements de pipeline de déploiement, et de la logique backend pour router les variantes. Les outils dans cette catégorie incluent GrowthBook, Optimizely Full Stack, et LaunchDarkly Experimentation. C'est la bonne voie quand vous avez de la capacité d'ingénierie et un test critique checkout ou logique backend où le scintillement est inacceptable.

Pour environ 80% des tests A/B de commerce headless, côté client est le bon choix. Les exceptions sont les tests critiques checkout où le scintillement compte et les tests de logique backend comme les moteurs de prix ou algorithmes de recommandation. Pour ceux-là, les configurations côté serveur ou hybrides ont du sens. Notre comparaison côté client vs côté serveur a la répartition complète.

Comment Varify.io s'intègre avec un storefront headless

Trois raisons pour lesquelles Varify.io convient bien au commerce headless.

• Un seul snippet, n'importe quel frontend. Un snippet JavaScript de 11,5 Ko ajouté une fois dans votre layout racine. Fonctionne avec React, Vue, Astro, SvelteKit, Hydrogen, Next.js, et tout ce qui charge du JavaScript dans un navigateur. Pas d'installation de SDK, pas de config bundler, pas de package spécifique au framework à maintenir à jour.
• Compatible SPA. Les stores headless sont généralement des applications single-page. Varify détecte les changements de route dans React Router, le routing Next.js, et la navigation Hydrogen, et réapplique automatiquement les variantes sur la nouvelle page. Aucune configuration SPA manuelle requise.
• Sans cookies, sans gate de consentement. L'assignation des variantes utilise localStorage, qui fonctionne indépendamment de l'état de la bannière de consentement et de Safari ITP. C'est important pour les stores headless avec un trafic mobile élevé et une base de clients UE. Voir tests A/B sans cookies pour les détails de l'architecture.

L'intégration typique sur un storefront Next.js ou Hydrogen ressemble à ceci :

// app/layout.tsx or root.tsx
<script
  async
  src="https://cdn.varify.io/snippet/YOUR_ID.js"
/>

C'est toute l'intégration pour la plupart des storefronts headless. Une fois le snippet en ligne, les expériences sont gérées dans le dashboard Varify, et aucun changement de code supplémentaire n'est nécessaire pour de nouveaux tests.

Pour les pages critiques en performance où le scintillement est inacceptable, Varify prend aussi en charge l'appel de l'API d'assignation depuis le code côté serveur et l'injection des données de variante dans le rendu HTML initial. La plupart des équipes n'en ont pas besoin, et le défaut côté client suffit pour la majorité des tests.