Test A/B :
comment tester
une hypothèse

Qu’est-ce qu’un test A/B ?

Un test A/B est une expérience qui attribue aléatoirement différentes versions d’un produit aux participants et compare un résultat défini à l’avance. A est généralement la version actuelle du site, et B une variante modifiée. Les deux groupes participent en même temps : ils connaissent la même promotion, les mêmes week-ends et le même contexte extérieur.

Par exemple, une boutique souhaite afficher le délai de livraison à côté du prix, plutôt que seulement dans le panier. Certains visiteurs voient l’ancienne fiche produit, d’autres la fiche avec le nouveau bloc. L’équipe vérifie si la proportion d’acheteurs change. Un nombre d’achats supérieur dans le second groupe ne suffit pas à prouver un effet : les groupes peuvent avoir des tailles différentes, des données peuvent manquer et une petite variation peut être aléatoire.

Un test peut comparer un seul élément ou deux versions complètes. Si seul le texte du bouton change, la conclusion porte sur ce texte. Si l’offre, l’illustration et le formulaire changent ensemble, le résultat concerne l’ensemble. On ne peut pas l’attribuer à un seul titre réussi. L’illustration d’ouverture montre le principe de comparaison de deux versions, et non l’interface d’un outil précis.

Choisir un problème et rédiger la fiche d’expérience

Partez d’observations : questions des clients, erreurs de formulaire, enregistrements de sessions et différences entre les étapes du parcours. « Faire plus moderne » n’explique pas la difficulté résolue par la nouvelle version. Pour une page de service, il est plus pertinent de vérifier si un périmètre de prestation clair aide les visiteurs à envoyer une demande adaptée.

Écrivez : « Nous observons [difficulté]. Si nous modifions [zone précise], [métrique] évoluera parce que [mécanisme supposé]. » Le mécanisme reste une hypothèse : le test mesure une évolution du résultat, sans lire les pensées du visiteur. Des entretiens et l’observation de la réalisation d’une tâche peuvent éclairer le comportement.

Priorisez les hypothèses selon l’ampleur du problème, le nombre de clients concernés, le coût de mise en œuvre et la possibilité de mesurer l’effet. Un formulaire de demande défectueux doit être réparé. L’utilité d’un champ supplémentaire ou d’une nouvelle explication du prix peut être testée. Ne consacrez pas un mois d’observation à un changement qui, même réussi, apporterait très peu à l’entreprise.

Définir la métrique principale et les indicateurs de protection

Pour un premier test, choisissez une métrique principale qui répond à la question métier. Classez les autres en métriques de diagnostic et indicateurs de protection. Les premières montrent à quelle étape le comportement a changé. Les seconds signalent les dommages inacceptables, même si la métrique principale progresse.

Fixez le dénominateur avant le lancement. Si l’expérience modifie l’accès au formulaire, vous ne pouvez pas comparer uniquement les personnes qui l’ont atteint : le changement influence cette sélection. L’analyse principale doit suivre la règle d’inclusion définie à l’avance. Pour une conversion binaire, un participant compte une seule fois comme converti, même s’il envoie trois demandes.

Vérifiez que l’événement correspond à une opération réussie, et non au simple clic sur un bouton. Rapprochez un envoi de test de son enregistrement CRM et assurez-vous qu’un rechargement de page n’ajoute pas de conversion. La variante doit être correctement liée au résultat. Pour les unités de calcul, consultez le guide sur la conversion du site ; la transmission des statuts de vente peut nécessiter une intégration CRM.

Calculer le nombre de participants nécessaire

Il n’existe pas de règle universelle selon laquelle « 100 conversions suffisent ». La planification nécessite le niveau actuel de la métrique, l’effet minimal détectable (MDE), le taux de faux positifs toléré et la puissance statistique. Plus la différence à distinguer du bruit est petite, plus il faut d’observations.

Le MDE est l’effet que l’expérience est conçue pour détecter avec la puissance choisie. Ce n’est ni une promesse de croissance ni une borne inférieure du résultat réel. Une puissance de 80 % est la probabilité de détecter cet effet précis, s’il existe, selon les hypothèses retenues. Le seuil α = 5 % concerne la procédure de test en l’absence d’effet, et non la probabilité qu’une conclusion donnée soit fausse.

Exemple avec le calculateur d’Evan Miller

1. Ouvrez Sample Size Calculator.
2. Dans Baseline conversion rate (taux de conversion initial), saisissez 4 — soit le taux de conversion actuel de 4 %.
3. Dans Minimum Detectable Effect (effet minimal détectable), indiquez 1 et sélectionnez Absolute : un écart d’un point de pourcentage. Une hausse à 5 % correspond à une variation relative de 25 %.
4. Vérifiez Statistical power (puissance statistique) — 80 %, Significance level — 5 %.
5. Conservez les paramètres avec le résultat. Lors de la vérification de cette combinaison, le calculateur indiquait 6 238 participants par variante, et non pour toute l’expérience.

Il s’agit du calcul d’un outil précis pour une métrique de conversion. D’autres méthodes peuvent donner un volume légèrement différent ; le chiffre d’affaires, les événements répétés, les regroupements par entreprise et les groupes inégaux nécessitent leur propre calcul. Alignez la planification sur la méthode d’analyse future. Saisir un nombre de commandes dans un outil prévu pour des utilisateurs indépendants ne résout pas le problème.

Déduire la durée de la taille de l’échantillon

Pour cet exemple, arrondissons à 6 500 personnes par groupe, soit 13 000 au total. Si 1 000 participants éligibles entrent pour la première fois dans l’expérience chaque jour, le recrutement prend environ 13 jours. Avec seulement 200 par jour, il faut environ 65 jours. Le trafic total du site ne convient pas à ce calcul si seule une partie des visiteurs voit le test.

Prévoyez des cycles complets représentatifs de l’activité et le délai nécessaire à l’action cible. Si les achats sont comptés pendant les sept jours suivant l’entrée dans le test, le dernier participant doit lui aussi disposer de sept jours. « Deux semaines se sont écoulées » ne prouve pas que les données suffisent. Ne modifiez pas la taille requise après avoir vu un résultat qui vous plaît.

Préparer une expérience dans Varioqub

Un site équipé de Yandex Metrica peut utiliser Varioqub. Avant la connexion, vérifiez les fonctions de votre offre et les limites du mode d’intégration choisi. L’éditeur visuel convient aux modifications simples ; les changements côté serveur nécessitent un développeur. Un rapport d’analyse seul ne crée pas de test A/B sans mécanisme d’affectation des visiteurs.

1. Le Metrica sélectionnez le compteur du site concerné, puis ouvrez dans l’interface anglaise Varioqub → Experiments (expériences).
2. Utilisez Code for site (code pour le site) pour obtenir le code ou la méthode de connexion. Un développeur doit l’installer pour le bon compteur et vérifier son chargement. Les procédures pour JavaScript, le gestionnaire de balises et l’API figurent dans les instructions de connexion.
3. Cliquez sur Create experiment (créer une expérience). Donnez un nom explicite, par exemple « Délai de livraison sur la fiche produit — septembre », et décrivez l’hypothèse.
4. Pour le test parallèle classique décrit ici, choisissez une répartition égale. Définissez les conditions de participation, les pages, la période, les variantes témoin et modifiée, puis les métriques.
5. Vérifiez les deux variantes et enregistrez les paramètres. Comparez la configuration à votre fiche en suivant la procédure officielle de création.

La répartition dynamique du trafic est un mode distinct : la taille des groupes évolue au fil des résultats. Elle ne peut pas être analysée sans adaptation comme le test à ratio fixe décrit ici. Pour une première hypothèse, ne complexifiez pas le protocole sans raison claire.

Vérifier l’affectation des variantes avant le lancement

Un même participant doit retrouver la variante qui lui a été attribuée lors des visites suivantes. Un produit avec connexion peut utiliser l’identifiant utilisateur ; un système B2B peut nécessiter une affectation par entreprise pour éviter des interfaces incohérentes entre collègues. Tirer une nouvelle variante à chaque rechargement ne répond pas à ce besoin.

Documentez la gestion des appareils multiples, de la suppression des cookies et de la connexion au compte. Vérifiez l’affectation, l’affichage réel et l’enregistrement du résultat : ces événements peuvent se produire à des moments différents. Tenez un journal court : participant de test, groupe attribué, version vue, action réalisée et enregistrement retrouvé.

Vérifier le test A/A, les groupes et le fonctionnement du site

Un test A/A montre la même version à deux groupes. Il aide à vérifier l’infrastructure : répartition, journalisation des affichages, objectifs et lien avec les ventes. Une différence significative isolée peut apparaître même si le système fonctionne ; c’est un signal à examiner, pas une preuve automatique de panne. À l’inverse, un rapport sans anomalie ne garantit pas l’absence de toute erreur.

Un contrôle distinct porte sur Sample Ratio Mismatch, SRM : la répartition observée correspond-elle au plan ? Un léger écart par rapport à 50/50 est normal et doit être évalué selon la taille de l’échantillon. Dans l’analyse de Microsoft Research, SRM est considéré comme le signe possible d’un problème d’affectation, d’exécution, de collecte ou de traitement des données. Lorsqu’un déséquilibre est détecté, il faut en rechercher la cause avant d’interpréter les métriques métier.

• Les deux versions : vérifier l’achat, les formulaires, la validation, la navigation et la transmission des données.
• Appareils : parcourir le scénario sur mobile et ordinateur, y compris lors d’un retour.
• Chargement : vérifier les apparitions furtives de la version d’origine, les décalages de mise en page et les erreurs de script.
• Mesure : s’assurer qu’une même action est enregistrée selon les mêmes règles.
• Chevauchements : vérifier si une autre expérience modifie la même étape du parcours.

Ne « rééquilibrez » pas les groupes en supprimant les enregistrements gênants. Si des données de B disparaissent à cause d’un chargement défectueux, retirer une partie de A masque le symptôme sans récupérer les résultats inconnus. Corrigez la cause et déterminez quelles données restent utilisables. Un changement de logique nécessite généralement un nouveau lancement avec un protocole distinct conservé.

Interpréter la conversion, l’effet et l’incertitude

Dans l’interface anglaise de Varioqub, ouvrez la liste des expériences et choisissez View result (voir le résultat). Comparez la période, la métrique et l’audience au plan. Les définitions et particularités de calcul sont précisées dans l’aide du rapport. Les méthodes de la plateforme peuvent différer d’un simple calculateur de deux proportions ; un écart de chiffres impose de vérifier les définitions, pas de choisir l’estimation la plus agréable.

La différence absolue est de 0,8 point de pourcentage. La hausse relative est de 20 % : (4,8 − 4) / 4 × 100 %. Ce sont deux façons d’exprimer le même résultat. Dire « une hausse de 0,8 % » sans précision est ambigu.

Pour ces données pédagogiques, un test z bilatéral approché de deux proportions donne p ≈ 0,0058. L’intervalle usuel à 95 % de la différence, par approximation normale, va d’environ +0,23 à +1,37 point de pourcentage. Cela suppose des participants indépendants, un plan fixe et aucune correction pour comparaisons multiples. Les événements rares, observations dépendantes et analyses séquentielles nécessitent des méthodes adaptées.

Ce que signifie la valeur p

Une valeur p décrit le caractère inhabituel des données observées ou plus extrêmes sous l’hypothèse d’absence d’effet et les hypothèses du modèle. Une valeur de 0,03 ne signifie pas « 97 % de probabilité que B soit meilleur ». Elle ne mesure pas non plus l’ampleur du bénéfice. Ces limites sont explicitement rappelées par l’American Statistical Association.

Examinez l’ampleur de l’effet et l’intervalle d’incertitude. Si celui-ci permet à la fois un dommage et un bénéfice importants, les données ne suffisent pas pour décider avec confiance. Si presque tout l’intervalle est proche de zéro, une forte amélioration paraît moins plausible dans les conditions du test. L’absence de significativité ne prouve pas l’égalité : conclure à l’équivalence exige un plan spécifique.

Quand arrêter le test et prendre une décision

Avec un plan fixe, ne terminez pas l’expérience dès le premier jour où la valeur p passe sous le seuil. Chercher à répétition la « significativité » modifie le risque de faux positif. Vous pouvez et devez surveiller le bon fonctionnement technique ; jugez l’efficacité selon la règle choisie à l’avance. Ce problème d’arrêt anticipé est expliqué par Evan Miller.

Les méthodes séquentielles permettent des décisions intermédiaires selon leurs propres règles. Elles nécessitent un plan statistique spécifique, et non un test ordinaire dont on consulte le tableau chaque jour. Ne transposez pas les seuils ni les interprétations entre méthodes. Une probabilité bayésienne n’est pas non plus « 1 − valeur p ».

Après la décision, conservez l’hypothèse, les paramètres, les dates, les versions, l’échantillon, les calculs, les limites et le lien vers le résultat. Supprimez les mécanismes temporaires d’affichage et revérifiez le parcours. Une réussite sur les fiches d’un segment ne prouve pas un bénéfice pour tout le site ; l’extension du changement exige d’évaluer la similarité des conditions.

Tester sans créer de problèmes SEO inutiles

Google publie des recommandations pour les tests de sites web. Pour un test classique de variantes de page, vérifiez quatre points :

1. Ne créez pas de contenu spécial réservé aux robots de recherche. Une expérience ne justifie pas le cloaking.
2. Si les variantes ont des URL différentes, ajoutez sur les pages alternatives rel="canonical" en pointant vers la page d’origine.
3. Utilisez une redirection temporaire 302 vers la variante, plutôt qu’une redirection permanente 301.
4. Après le test, supprimez les variantes, mécanismes de sélection et redirections temporaires devenus inutiles.

Vérifiez le HTML réellement servi, la conservation du chemin et le chargement des ressources. Le guide de vérification des balises canonical et redirections vous aidera à formuler la tâche du développeur. Il s’agit de règles techniques, pas d’une garantie de positions inchangées.

Un test A/B utilisateur classique mesure le comportement des visiteurs. Évaluer des changements SEO à partir du trafic organique nécessite un autre protocole, souvent avec des groupes de pages et la prise en compte de l’évolution temporelle. Plus d’achats dans B ne prouvent pas un meilleur classement.

Ce qui rend le plus souvent une conclusion fragile

• Des canaux différents au lieu de groupes aléatoires. La recherche arrive sur A, la publicité sur B. Vous comparez des audiences différentes.
• Changer de métrique après le lancement. Les ventes n’ont pas augmenté, mais un joli indicateur de clics a été trouvé. Cette recherche peut produire une nouvelle hypothèse, sans remplacer le résultat initial.
• Multiplier variantes et segments sans correction. Avec des dizaines de comparaisons, il est plus facile d’obtenir par hasard un chiffre convaincant. Définissez à l’avance la gestion des tests multiples.
• Modifier B pendant la collecte. Des versions différentes sont regroupées sous un même nom. Conservez l’historique et séparez les expériences.
• Des fenêtres de conversion inégales. Les premiers participants ont été observés un mois, les derniers une heure. Comparez selon la règle convenue.
• Décider uniquement à partir de la moyenne. Une hausse globale peut masquer un dommage important, par exemple sur mobile. Vérifiez toujours les indicateurs de protection prédéfinis ; les effets par segment découverts après le lancement doivent être confirmés séparément.

Une promotion extérieure ne rend pas automatiquement un test simultané inutile si elle touche également les groupes constitués au hasard. La conclusion concerne toutefois l’audience et les conditions de cette promotion. Consignez l’événement et ne généralisez pas à une période normale sans justification supplémentaire.

Que faire si le trafic est insuffisant ?

Commencez par une estimation réaliste de la durée. Si un petit changement nécessite un an, l’appeler « test A/B » n’améliorera pas la décision. Étudiez le parcours client : faites réaliser une tâche à des utilisateurs cibles, analysez les demandes au support et vérifiez le formulaire et l’offre. Ces méthodes trouvent des difficultés, mais ne donnent pas d’estimation statistique de la hausse des ventes.

Vous pouvez tester une hypothèse plus substantielle si elle est justifiée. Un effet attendu plus grand peut être plus facile à détecter, mais ne modifiez pas le MDE pour obtenir une durée commode. Un test commun sur un même modèle de page exige une affectation correcte et la prise en compte des dépendances. Comparer arbitrairement vingt produits populaires à vingt produits rares n’est pas une expérience équitable.

Une métrique intermédiaire peut s’accumuler plus vite, mais la réponse ne concerne qu’elle. Plus d’accès au formulaire ne signifie pas plus de revenus. Avec peu de données, explicitez l’incertitude et le plan de suivi. Pour un travail structuré, les hypothèses, l’analyse et la mise en œuvre peuvent être réunies dans le marketing à la performance, et les changements d’interface dans l’évolution du site.

Liste de contrôle avant le lancement et le déploiement

Questions fréquentes sur les tests A/B