Les tests A/B natifs de Shopify : ce que Rollouts remplace et ce qu'il ne remplace pas

Les tests A/B natifs sont arrivés sur Shopify en juin 2026, sous Rollouts dans la section Markets. Ils couvrent les thèmes et les configurations de checkout, avec planification et publication progressive intégrées. Pour un grand nombre de marchands, c'est la première fois que le test fractionné est accessible sans rien installer.

C'est réellement significatif, et c'est aussi là que se situe le risque. La barrière à l'entrée pour lancer un test vient de tomber à presque zéro. La barrière pour lancer un test qui veut dire quelque chose n'a pas bougé.

Ce que Rollouts apporte concrètement

Trois capacités, à distinguer avec précision.

Test fractionné de thèmes. Servir deux versions de thème à un partage du trafic. C'est la fonction phare et celle qui retire un outil tiers aux boutiques qui ne testaient que la mise en page.

Test de configurations de checkout. Tester des configurations de checkout en split, ce qui compte beaucoup maintenant que Checkout Components est généralement disponible sur Plus. Comparer un checkout composé à l'existant était auparavant laborieux. C'est désormais natif.

Publication progressive. Diffuser un changement à une part croissante du trafic plutôt qu'à tout le monde d'un coup. Techniquement, il s'agit d'une sécurité de déploiement plus que d'une expérimentation, mais c'est sans doute la plus utile des trois, car elle transforme une mise en production risquée en manœuvre réversible.

Là où un outil dédié reste nécessaire

Rollouts ne remplace pas une plateforme d'expérimentation. Les manques qui comptent :

• Test de prix et d'offres. Rollouts partage des thèmes et des configurations de checkout, pas des tarifs, des structures de remise ou des seuils de livraison offerte. Les outils conçus pour cela restent nécessaires.
• Expériences côté serveur et headless. Si votre storefront est en Hydrogen ou Next.js, le partage de thème n'a rien à partager. Les expériences relèvent de votre propre couche edge ou serveur.
• Segmentation fine. Tester un changement uniquement sur les nouveaux visiteurs, sur une seule zone géographique ou sur les clients au-dessus d'un seuil de valeur vie demande généralement plus de contrôle de ciblage qu'un split natif.
• Rigueur statistique. C'est le point majeur et il mérite sa propre section.

Le problème statistique est désormais le vôtre

Un outil natif qui rend les tests faciles à lancer ne les rend pas faciles à interpréter. Deux modes d'échec vont être extrêmement répandus l'année prochaine.

Arrêter quand le chiffre est bon. Les écarts de taux de conversion oscillent énormément dans les premiers jours d'un test. Si vous regardez tous les jours et arrêtez dès que la variante B passe devant, vous déclarerez des gagnants qui ne sont que du bruit. La règle d'arrêt doit être fixée avant le lancement, en taille d'échantillon et en durée, puis respectée.

Tester des changements trop petits pour être détectés. La plupart des boutiques n'ont pas le trafic nécessaire pour détecter un gain relatif de un pour cent dans un délai raisonnable. Avant tout lancement, calculez le plus petit effet réellement détectable compte tenu de votre trafic et de votre taux de conversion de base. Si ce chiffre est de quinze pour cent en relatif, tester une couleur de bouton revient à gaspiller quatre semaines.

Un calcul de dimensionnement approximatif, à faire avant chaque test :

// Taille d'échantillon approximative par variante, test bilatéral, confiance 95%, puissance 80%.
// baseline : taux de conversion actuel, par exemple 0.024
// mde : effet minimal détectable en gain relatif, par exemple 0.10 pour 10%
function samplePerVariant(baseline, mde) {
  const p1 = baseline;
  const p2 = baseline * (1 + mde);
  const pBar = (p1 + p2) / 2;
  const zAlpha = 1.96;
  const zBeta = 0.84;

  const numerator =
    Math.pow(zAlpha * Math.sqrt(2 * pBar * (1 - pBar)) +
             zBeta * Math.sqrt(p1 * (1 - p1) + p2 * (1 - p2)), 2);

  return Math.ceil(numerator / Math.pow(p2 - p1, 2));
}

const perVariant = samplePerVariant(0.024, 0.10);
const weeklySessions = 40000;
const weeks = (perVariant * 2) / weeklySessions;

console.log({ perVariant, weeks: Math.ceil(weeks * 10) / 10 });

Exécutez-le avec vos vrais chiffres. Pour une boutique à deux virgule quatre pour cent de conversion et quarante mille sessions hebdomadaires, détecter un gain relatif de dix pour cent prend plusieurs semaines. Ce n'est pas une raison de renoncer aux tests. C'est une raison de tester des choses assez grandes pour compter et d'arrêter de programmer quatre expériences par mois.

Ce qui mérite d'être testé cette année

Compte tenu des tailles d'effet réellement détectables, les candidats qui passent la barre sont structurels plutôt que cosmétiques.

L'autre sujet qui mérite d'être testé, et que presque personne ne teste, c'est la performance. Une page plus rapide n'est pas un changement de mise en page, elle n'apparaîtra donc pas dans un backlog de tests classique, mais la relation entre temps de chargement et conversion est l'un des effets les plus fiables du e-commerce. Nous avons rassemblé les données dans notre analyse Core Web Vitals et conversion, et la démarche de diagnostic dans notre checklist d'audit Core Web Vitals Shopify.

Hygiène de mesure

Une mise en garde propre aux tests natifs. Rollouts rapporte la mesure faite par Shopify du split. Si votre stack analytique affiche des chiffres différents, et ce sera le cas, résistez à la tentation de retenir la source qui confirme le résultat souhaité.

Décidez avant le test quelle source fait foi, et assurez-vous qu'elle ne soit pas purement côté client. Bloqueurs de publicités, choix de consentement et restrictions navigateur suppriment une part significative et non aléatoire des événements client, ce qui suffit à inverser un résultat serré. Notre guide du tracking côté serveur couvre la mise en place, et si vous voulez que les résultats d'expérience côtoient le reste de vos données commerciales plutôt qu'un tableau de bord isolé, notre guide Looker Studio et BigQuery traite le volet entrepôt.

En résumé

Rollouts est une vraie amélioration, surtout parce que la publication progressive sécurise le déploiement de thèmes et parce que le test de configuration de checkout arrive exactement au moment où les boutiques Plus en ont besoin. Il ne remplace pas une plateforme d'expérimentation pour le test de prix, les storefronts headless ou les expériences segmentées.

Le changement le plus important est culturel. Quand les tests étaient coûteux à mettre en place, la barre pour en lancer un était haute. Maintenant qu'ils sont gratuits, la discipline doit venir d'ailleurs : une hypothèse écrite, un calcul de dimensionnement et une règle d'arrêt avant toute mise en ligne.

Questions fréquentes

Rollouts fonctionne-t-il sur un storefront headless ?

Le partage de thème non, puisqu'il n'y a pas de thème rendu par Shopify à partager. Le test de configuration de checkout reste applicable. Les expériences storefront doivent tourner dans votre propre couche de rendu.

Puis-je tester les prix avec Rollouts ?

Non. Il partage des thèmes et des configurations de checkout. Le test de prix et d'offres exige toujours un outil dédié.

Combien de temps doit durer un test ?

Assez longtemps pour atteindre la taille d'échantillon qu'impose votre taux de conversion de base, et jamais moins d'une semaine complète. Deux semaines est un défaut plus sûr, car les comportements de semaine et de week-end y sont couverts deux fois.

Dois-je arrêter de payer mon outil de test actuel ?

Uniquement si vous l'utilisiez exclusivement pour des tests de mise en page de thème. Si vous faites de la segmentation, du test de prix ou des expériences côté serveur, la fonction native ne vous couvre pas.

Quelle est l'erreur la plus fréquente avec les tests natifs ?

L'arrêt prématuré. La facilité de consultation quotidienne rend très tentant de déclarer un gagnant dès qu'il apparaît, et c'est ainsi que du bruit se retrouve mis en production comme une découverte.