Si vous avez un dashboard de résultats qui se met à jour en temps réel et que vous le consultez tous les jours, vous peekez. Et si vous peekez, vos taux de faux positifs explosent silencieusement. Cet article explique pourquoi, comment y remédier via sequential testing, et un troisième concept lié, le SRM, qui signale qu’un test est cassé techniquement.
Le peeking, pourquoi c’est un piège statistique
Un test A/B fréquentiste classique repose sur une décision unique en fin de test : à la fin de la période planifiée, vous regardez la p-value, vous décidez.
Si vous consultez plusieurs fois la p-value avant la fin et que vous arrêtez le test dès qu’elle passe sous 0,05, vous avez augmenté la probabilité de faux positifs.
Le calcul de l’inflation
Pour un test simple avec décision unique, α = 0,05 → 5 % chance de faux positif.
Si vous peekez 5 fois pendant le test (à 20 %, 40 %, 60 %, 80 %, 100 % du sample size requis) et que vous décidez d’arrêter dès que p < 0,05 :
- Probabilité réelle de faux positif ≈ 14 %
À 10 peeks : ~19 %. À 20 peeks : ~24 %.
Vous êtes passé d’une promesse “5 % de faux positifs” à “1 chance sur 4 de déclarer un winner qui n’existe pas”.
Référence : Johari et al. 2017, “Peeking at A/B tests: Why it matters, and what to do about it” (KDD 2017).
Pourquoi tout le monde peeke quand même
Parce que c’est humain. Vous lancez un test, vous êtes excité, vous regardez chaque jour. Si vous voyez +18 % significatif au jour 4, vous voulez déployer maintenant et pas attendre le jour 21.
Le coût d’opportunité d’attendre est réel, pendant 17 jours, les visiteurs voient peut-être la variante perdante. Mais le coût de déployer trop tôt est aussi réel, vous risquez de pousser un winner factice.
Le sequential testing, la solution propre
Le sequential testing (séquentiel) résout le problème en ajustant la p-value en continu pour rester valide à toute étape du test.
Méthodes principales
-
mSPRT (mixture Sequential Probability Ratio Test) : la méthode bayésienne-fréquentiste hybride utilisée par Optimizely et Statlift. Permet une “always-valid p-value”, vous pouvez consulter et arrêter à tout moment, p < 0,05 reste 5 % de faux positifs garantis.
-
Group Sequential Methods (Pocock, O’Brien-Fleming) : utilisées en essais cliniques. Plus rigide, exige des “interim analyses” préplanifiées.
-
Always-Valid Inference (Howard et al. 2021) : framework plus récent, intervalles de confiance valides à tout instant.
Le trade-off
Le sequential testing demande légèrement plus de visiteurs que le test fixe équivalent, typiquement 10-20 % de plus pour atteindre la même puissance statistique.
C’est le prix de la flexibilité : vous pouvez peeker quand vous voulez, kill un test au jour 4 si la signification est atteinte, sans inflation d’erreur.
Sur Statlift
Activé par défaut sur les plans Croissance et Pro. À chaque consultation des résultats, vous voyez :
- p-value séquentielle (ajustée pour peeking)
- “Décision possible maintenant” si seuil atteint
- Estimation du temps restant si seuil pas atteint
Pas besoin de calculer le sample size à l’avance, l’outil vous dit “OK, vous pouvez décider, p reste valide”.
Le SRM (Sample Ratio Mismatch)
SRM = la répartition observée du trafic entre variantes diffère significativement de la répartition attendue.
Exemple
Vous configurez un test 50/50. Au jour 7, votre dashboard affiche :
- Variante A : 52 380 visiteurs (53,4 %)
- Variante B : 45 720 visiteurs (46,6 %)
χ² test sur cette répartition (vs 50/50 attendu) : p < 0,001. C’est un SRM.
Pourquoi c’est grave
Si l’attribution n’est pas équilibrée, vous avez un bug technique quelque part, pas un effet de comportement utilisateur (la variante n’est pas affichée encore quand l’attribution se fait, donc impossible que ça change le comportement).
Causes typiques :
- Cookies Safari ITP qui expirent à 7 jours et réattribuent
- Hash de user ID biaisé (modulo qui ne distribue pas uniformément)
- Pre-fetch / pre-render qui assigne avant l’arrivée réelle
- Bots scrapers qui touchent une variante mais pas l’autre
Conséquence
Un SRM invalide complètement les résultats du test, même si la p-value globale est belle. Parce que les deux populations ne sont pas comparables (ce n’est pas un échantillonnage aléatoire correct).
Détection automatique
Sur Statlift, χ² SRM check tous les jours pendant le test :
- p > 0,05 sur la répartition → tout va bien
- p < 0,01 → alerte rouge, test bloqué, investigation requise
- p entre 0,01 et 0,05 → alerte orange, surveillance accrue
Référence : Fabijan et al. 2019, “Diagnosing Sample Ratio Mismatch in Online Controlled Experiments” (KDD 2019, Microsoft).
En résumé, les 3 garde-fous
| Concept | Problème | Solution |
|---|---|---|
| Peeking | Inflation type I (5 % → 20 % faux positifs si peeks répétés) | Sequential testing (mSPRT, always-valid p-value) |
| Sequential testing | Coût 10-20 % de visiteurs supplémentaires | Acceptable, le bénéfice de flexibilité l’emporte |
| SRM | Attribution déséquilibrée, résultats invalides | χ² check quotidien, alerte automatique, kill du test |
Trois règles de pouce :
- Si vous voulez peeker, activez le sequential testing. Sinon, fixez le sample size avant et n’y touchez plus.
- Au moindre signal SRM, arrêtez le test et investiguez avant de relancer.
- Toujours faire un A/A préalable sur un nouvel outil, c’est là que le SRM apparaît avant de polluer vos vrais tests (voir A/A test : la pratique qui révèle les biais cachés).
Pour approfondir : Calcul de la taille d’échantillon et Fréquentiste vs Bayésien.
