Conversion Rate Optimization
Optimisation du Taux de Conversion de vos SItes

Critères de validité statistique d'un test A/B

Ce qui rend un résultat de test exploitable, ou trompeur

Trois règles minimales avant de tirer une conclusion

Un test A/B ne devient exploitable qu'à condition de respecter trois critères simultanément. Le premier fixe un seuil minimal de 100 visiteurs uniques par variante. Le second impose une durée minimale d'une semaine, la préférence allant à deux semaines pour couvrir à la fois les jours de semaine et le week-end, dont les comportements diffèrent souvent sensiblement. Le troisième interdit d'arrêter un test avant d'avoir atteint au moins 95 % de signification statistique, ce seuil représentant la probabilité que le résultat observé ne soit pas dû au hasard seul.

Un repère complémentaire, plus prudent dans sa formulation, recommande d'ignorer purement et simplement tout résultat de test tant que 350 conversions par variante n'ont pas été atteintes, ou davantage selon la taille d'échantillon réellement nécessaire au cas précis. Ce chiffre de 350 n'est cependant jamais présenté comme une valeur magique universelle : la taille d'échantillon nécessaire doit être calculée à l'avance pour chaque test, à l'aide d'un calculateur dédié, plutôt que déduite d'un chiffre générique. Analyser les résultats d'un test par segment (bureau, tablette, mobile) exige, de la même façon, un nombre de conversions plus élevé que l'analyse du résultat global.

Signification statistique et validité ne se confondent jamais

Une distinction reste décisive et fréquemment ignorée en pratique : atteindre 95 % de signification statistique dans un tableau de bord de test ne garantit rien si la taille d'échantillon nécessaire n'a pas encore été atteinte. Lancer un test sans réfléchir à la confiance statistique reviendrait, selon une formule reprise dans ce contexte, à donner une fausse confiance d'avoir compris ce qui fonctionne sur un site, alors que rien n'a réellement été appris. La signification statistique ne constitue donc jamais, à elle seule, une règle d'arrêt légitime d'un test : elle doit toujours se combiner à la taille d'échantillon minimale requise.

Une durée qui couvre un cycle métier complet, pas seulement un volume de trafic

La taille d'échantillon nécessaire peut être atteinte en quelques jours seulement sur un site à fort trafic, sans que cet échantillon soit pour autant représentatif : il omettrait alors un cycle métier complet, avec ses variations de jours de semaine, de week-end, de phase commerciale, de sources de trafic, et de calendrier de publication ou de newsletter. Un test valide combine donc toujours une taille d'échantillon suffisante et une durée suffisante pour couvrir ce cycle complet, idéalement deux cycles. Pour la plupart des entreprises, cette durée se situe entre deux et quatre semaines.

Le coût réel d'une méthodologie de test négligée

Une recherche attribuée à l'outil de test Qubit chiffre à 13 milliards de dollars par an le revenu perdu par les détaillants en ligne du fait de méthodologies de test A/B défaillantes. Ce chiffre illustre l'enjeu concret d'une rigueur trop souvent traitée comme secondaire face à l'attrait d'un résultat rapide : un gain apparent obtenu en quelques jours, sur un échantillon insuffisant ou une durée trop courte, peut se révéler un artefact statistique plutôt qu'un effet réel, avec un coût cumulé qui dépasse largement celui d'avoir simplement attendu que le test atteigne sa validité.

Les conseils de Ronny Kohavi (Microsoft) pour des expérimentations contrôlées fiables

Ronny Kohavi, qui dirige la plateforme d'expérimentation de Microsoft, formule six recommandations issues de nombreuses expérimentations web contrôlées, complémentaires aux seuils de taille d'échantillon et de durée déjà exposés plus haut. Mener des tests à facteur unique pour étudier des changements de conception découplés les uns des autres. Oser des paris de conception nettement différenciés plutôt que des variations mineures, puis itérer à partir du gagnant. Utiliser un plan factoriel lorsqu'on soupçonne que plusieurs facteurs interagissent entre eux. Se méfier des effets de primauté des nouvelles fonctionnalités, un biais que l'on peut limiter en exposant la nouveauté à de nouveaux utilisateurs plutôt qu'à des utilisateurs déjà habitués à l'ancienne version. Intégrer les expérimentations contrôlées directement dans le système de production pour éviter les erreurs de code et permettre un échec rapide et peu coûteux. Enfin, réduire le coût de chaque expérimentation pour augmenter mécaniquement le nombre d'expérimentations qu'une équipe peut mener.

Sur le repère de taille d'échantillon spécifique aux tests de landing page, un ordre de grandeur alternatif recommande d'attendre environ 40 conversions par variante avant de porter un jugement statistique fiable, sauf si les pages testées produisent des résultats très nettement différenciés dès les premières conversions. Ce repère reste, comme le seuil de 350 conversions déjà cité, une indication générale à ajuster au cas par cas plutôt qu'une règle universelle.

FAQ

Quelle taille d'échantillon minimale un test A/B doit-il atteindre avant d'être exploité ? Un repère courant fixe le seuil à au moins 100 visiteurs uniques par variante, un autre repère plus prudent recommande d'ignorer tout résultat avant 350 conversions par variante. Dans les deux cas, ces chiffres restent des repères généraux : la taille d'échantillon réellement nécessaire doit être calculée au cas par cas à l'aide d'un calculateur dédié, en fonction du taux de conversion de base et de l'effet minimal qu'on cherche à détecter.

Pourquoi 95 % de signification statistique ne suffit-il pas à arrêter un test ? Parce que la signification statistique répond à une question différente de la validité globale du test : elle indique la probabilité que le résultat observé ne soit pas dû au hasard, mais ne garantit rien si la taille d'échantillon nécessaire n'a pas encore été atteinte. Un test arrêté dès l'apparition de 95 % de confiance, avant d'avoir atteint sa taille d'échantillon requise, reste vulnérable à un résultat qui s'inverse si le test se poursuivait.

Combien de temps doit durer un test A/B ? Au minimum une semaine, idéalement deux, pour couvrir à la fois les jours de semaine et le week-end. Pour la plupart des entreprises, une durée de deux à quatre semaines permet en outre de couvrir un cycle métier complet (variations de sources de trafic, calendrier promotionnel, comportement saisonnier), une condition aussi importante que le seul volume de conversions atteint.

Un test qui atteint rapidement son seuil de conversions peut-il être arrêté immédiatement ? Pas nécessairement : un volume de trafic élevé peut permettre d'atteindre la taille d'échantillon requise en quelques jours seulement, sans que cet échantillon couvre un cycle métier complet. Arrêter le test à ce stade risque de fonder une décision sur une période non représentative, même si la taille d'échantillon nominale est techniquement atteinte.

Que coûte réellement une méthodologie de test A/B mal maîtrisée ? Une recherche attribuée à l'outil de test Qubit chiffre ce coût à 13 milliards de dollars par an de revenu perdu pour l'ensemble des détaillants en ligne, un ordre de grandeur qui illustre l'enjeu concret d'un manque de rigueur statistique, au-delà du seul risque de tirer une conclusion erronée sur un test isolé.

Faut-il traiter différemment un test dont on veut analyser les résultats par segment (mobile, tablette, bureau) ? Oui : analyser un test par segment exige un nombre de conversions plus élevé que l'analyse du seul résultat global, chaque segment devant lui-même atteindre une taille d'échantillon suffisante pour que sa conclusion propre soit fiable. Prévoir cette segmentation avant le lancement du test, plutôt qu'après coup, permet d'anticiper le volume de trafic ou la durée nécessaires.

Quels conseils Ronny Kohavi (Microsoft) donne-t-il pour mener des expérimentations contrôlées fiables ? Six recommandations principales : mener des tests à facteur unique pour des changements découplés, oser des paris de conception nettement différenciés puis itérer à partir du gagnant, utiliser un plan factoriel quand plusieurs facteurs peuvent interagir, se méfier des effets de primauté des nouvelles fonctionnalités, intégrer les expérimentations au système de production pour éviter les erreurs de code, et réduire le coût de chaque expérimentation pour pouvoir en mener davantage.