Tests A/B sans erreur : le guide complet

Un test A/B n’a rien de sorcier, mais il est impitoyable avec ceux qui trichent sur les règles statistiques. Après 10 ans à analyser des données de tracking, voici ce que j’ai appris pour mener des tests dont les résultats sont fiables.

1. Calculer la taille d’échantillon AVANT de commencer

Ne lancez jamais un test sans savoir combien de visiteurs il vous faut. C’est l’erreur la plus fréquente que je vois. Avec un échantillon trop petit, vous ne détecterez pas de vraie différence. Et si vous arrêtez trop tôt parce que vous voyez de la « significativité », vous voyez probablement du bruit, pas du signal.

La formule : n = 2 × [σ² × (Z₁₋α/₂ + Z₁₋β)²] / δ². C’est une version simplifiée qui suppose la même variance dans les deux groupes ; les calculateurs utilisent la formule exacte pour deux proportions et donnent un n légèrement plus grand (voir le NIST e-Handbook). Avec :

σ² = p₀(1-p₀), où p₀ est votre taux de conversion de référence ;
Z₁₋α/₂ = 1,96 pour 95 % de confiance ;
Z₁₋β = 0,84 pour 80 % de puissance (ou 1,28 pour 90 %) ;
δ = effet minimal détectable (MDE).

Exemple concret : taux de conversion de référence 5 %, MDE de +1 point (donc 6 %), confiance 95 %, puissance 80 %. Il faut environ 7 500 à 8 200 visiteurs par groupe selon la formule (calculateur d’Evan Miller : environ 8 150).

Outils : le calculateur d’Evan Miller et celui d’Optimizely. Point critique : plus l’amélioration attendue est faible, plus l’échantillon doit être grand. Pour tester des changements subtils, il faut un trafic massif.

2. Tester pendant au moins deux cycles d’activité complets

Même si vous atteignez la significativité au bout de 3 jours, continuez. Pour la plupart des sites, cela veut dire deux semaines pleines, pour trois raisons :

Cycles d’activité : les utilisateurs se comportent différemment en semaine et le week-end. Il faut au moins 2 cycles hebdomadaires complets pour lisser ces écarts.
Acheteurs récurrents : ceux qui ont commencé leur parcours avant le test ajoutent du bruit aux deux groupes ; un test plus long les dilue.
Sources de trafic : organique, payant et email n’arrivent pas aux mêmes moments et ne se comportent pas pareil.

Ne testez pas non plus beaucoup plus longtemps que nécessaire : la perte de cookies et les événements extérieurs s’accumulent (cookies supprimés, habitudes qui changent, facteurs externes, nouvelles variables). Même sur un site à fort trafic qui atteint son échantillon en 2 ou 3 jours, il ne faut pas s’arrêter tout de suite : il faut vérifier que le schéma tient sur différents jours et segments.

Les sources le confirment. Evan Miller : « Repeated significance testing always increases the rate of false positives » (How Not To Run an A/B Test). Kameleoon recommande au moins 2 cycles d’activité, en général 2 à 4 semaines (Kameleoon).

3. Vérifier le Sample Ratio Mismatch (SRM)

C’est un contrôle critique que la plupart des gens sautent. Le SRM apparaît quand la répartition réelle ne correspond pas à la répartition prévue. Exemple : vous configurez 50/50, et vous observez 5 000 visiteurs dans le groupe A contre 2 100 dans le groupe B. C’est un SRM majeur.

Microsoft Research a constaté qu’environ 6 % des tests A/B ont un problème de SRM. Même un petit déséquilibre peut fausser les taux de conversion, faire détecter de fausses hausses, masquer de vrais changements, voire inverser complètement les résultats.

Pour le détecter, on utilise un test d’adéquation du khi-deux (χ²) : χ² = Σ [(Observé – Attendu)² / Attendu]. Prenez un seuil strict : Microsoft utilise p < 0,0005, beaucoup d’outils p < 0,01 (source : Microsoft Research).

Exemple : 10 000 visiteurs attendus en 50/50, soit 5 000 chacun. Observé : 5 200 et 4 800. χ² = (200²/5 000) + (200²/5 000) = 16. Avec 1 degré de liberté, p < 0,01 correspond à χ² > 6,63 (NIST : valeurs critiques du khi-deux). Ici 16 > 6,63 : SRM détecté (p ≈ 0,00006).

Causes courantes :

randomisation défaillante (utilisateurs mal affectés aux groupes) ;
variations qui ne démarrent pas en même temps ;
filtrage des bots qui retire à tort de vrais utilisateurs ;
redirection de la variante B qui plante ou qui est lente ;
cookies bloqués ou supprimés.

Outil : le SRM Checker de Lukas Vermeer ; la plupart des plateformes de test ont aujourd’hui des alertes SRM intégrées. Si un SRM est détecté, ne faites pas confiance aux résultats : identifiez la cause, corrigez-la, relancez le test. Vos données sont compromises et toute conclusion est potentiellement invalide.

4. Ne jamais arrêter un test parce qu’il est « significatif »

C’est le « peeking » (arrêt optionnel), une forme courante de p-hacking, et l’une des pires erreurs en A/B testing. Si vous surveillez le test en continu et l’arrêtez dès que p < 0,05, vous faites exploser le taux de faux positifs : la « significativité » peut venir de fluctuations aléatoires.

La règle : attendre À LA FOIS la taille d’échantillon prévue et la durée minimale du test (2 semaines). C’est difficile, parce que les parties prenantes s’impatientent et que les premiers « gains » donnent envie de livrer. Résistez : déployer un changement qui ne marche pas (ou pire, qui fait baisser la conversion) coûte bien plus cher que quelques jours d’attente.

Si vous devez absolument regarder les résultats plus tôt, utilisez de vraies méthodes séquentielles (comme le Sequential Probability Ratio Test), conçues pour une surveillance continue. Mais ne « jetez pas un œil » à un test A/B standard.

5. Viser au minimum 95 % de confiance et 80 % de puissance

Ce sont deux mesures différentes, aussi importantes l’une que l’autre.

Niveau de confiance (en général 95 %) : il fixe la fréquence des fausses alertes acceptées. À 95 %, s’il n’y a vraiment aucune différence, vous en détecterez une à tort 5 % du temps (erreur de type I). 99 % est plus prudent mais demande plus de données ; 90 % est parfois acceptable pour des tests à faible risque.
Puissance (en général 80 %) : la probabilité de détecter un effet réel s’il existe. Une faible puissance, c’est un risque élevé de faux négatifs (erreur de type II). 90 % est mieux mais demande plus de données.

Erreur fréquente : ne regarder que la confiance et ignorer la puissance. On conclut alors à « pas de différence » alors qu’il y en a une : on n’avait simplement pas assez de données pour la voir.

6. Contrôler les métriques invariantes

Avant de croire vos résultats, vérifiez que les métriques qui ne devraient pas bouger n’ont pas bougé. Ce sont des métriques théoriquement non affectées par votre variante :

test de couleur de bouton sur une fiche produit : le total de pages vues ne doit pas changer ;
test du tunnel de commande : le taux d’ajout au panier (avant le checkout) ne doit pas changer ;
le nombre de sessions par utilisateur doit rester stable.

Si elles changent, c’est un signal d’alerte : bug technique, erreur de tracking, problème de ciblage ou de cookies. Vérifiez aussi qu’il n’y a pas eu de choc externe (campagne, bug, pic de trafic), que le mix de sources de trafic est resté stable, que rien d’autre n’a été déployé sur le site, et que les deux variantes se chargent à la même vitesse sans erreur.

Un exemple de bug attrapé ainsi : dans une entreprise, les pages vues augmentaient dans la variante d’un test de couleur de bouton, ce qui n’avait aucun sens. L’enquête a montré qu’une erreur JavaScript provoquait un rechargement de page supplémentaire. Sans ce contrôle, ils auraient fait confiance à des données corrompues.

7. Comprendre ses statistiques, sans se compliquer

Pas besoin d’être statisticien, mais il faut connaître les bases. Pour un test de taux de conversion : z = (p₁ – p₂) / SE, avec SE = √[p(1-p) × (1/n₁ + 1/n₂)], où p est le taux de conversion agrégé, p₁ et p₂ ceux de chaque groupe, n₁ et n₂ les tailles d’échantillon. Si |z| > 1,96, le résultat est significatif à 95 %. Le test du khi-deux marche aussi, et il est souvent plus simple pour les tableaux de contingence.

Le principe le plus important : significativité statistique ≠ impact business. Un test peut être significatif (p < 0,05) avec un effet si faible qu’il ne vaut pas la peine d’être déployé. Demandez-vous toujours si la hausse compte pour l’entreprise, ce que coûte la mise en œuvre et quels sont les risques.

Bonnes pratiques complémentaires

Tests multiples : si vous testez plusieurs variantes ou métriques, ajustez le seuil de significativité. La correction de Bonferroni est prudente mais simple : divisez alpha par le nombre de comparaisons.
Un changement à la fois : si vous changez la couleur du bouton ET le texte, vous ne saurez pas lequel a joué.
Tout documenter : hypothèse, calcul de taille d’échantillon, durée, détails de mise en œuvre, résultats et décision.
Pré-enregistrer le plan d’analyse : métriques, taille d’échantillon, durée et critère de succès, décidés à l’avance. Cela évite la rationalisation a posteriori et le HARKing (Hypothesizing After Results are Known).

Pièges courants

Tester trop de choses à la fois : des tests simultanés peuvent interagir.
Modifier le test en cours de route : ne touchez ni aux variantes ni au ciblage.
Faire confiance aux petits échantillons : même « significatifs », ils sont peu fiables.
Ignorer la saisonnalité : évitez les tests à cheval sur de grandes fêtes ou événements.
Ne pas documenter les enseignements : un test raté apprend autant qu’un gagnant.

L’essentiel

L’A/B testing n’est pas compliqué, mais il ne pardonne pas à ceux qui coupent les coins. Les quatre règles critiques : calculer la taille d’échantillon avant de démarrer, tester au minimum 2 semaines, vérifier le Sample Ratio Mismatch, ne jamais s’arrêter tôt parce que c’est « significatif ». Respectez-les et vos tests seront fiables. Sinon, vous ne produisez que du bruit.

Les statistiques ont été vérifiées avec la déclaration de l’ASA sur les p-values et le NIST e-Handbook. Les principes viennent de 10 ans de travail de terrain en tracking et analytics pour des entreprises de télécoms, de voyage et d’e-commerce.

Sources

Pour aller plus loin, lisez la version complète de l’article (en anglais) : How to Run A/B Tests Without Screwing Up: A Complete Guide.

Comment faire des tests A/B sans se tromper : le guide complet