Janvier 2025, je travaille avec une grande DNVB FR (que je ne nommerai pas, l’équipe se reconnaîtra). Un test “winner +18 %” est déployé en production. Six semaines après, l’effet a disparu et le revenu a même légèrement reculé de 4 %.
Ce post-mortem identifie les 4 erreurs commises. Aucune n’est unique, toutes sont reproductibles. C’est pour ça qu’il faut en parler.
Le test
Hypothèse : remplacer le hero homepage (photo lifestyle généraliste) par une photo produit hero spécifique au best-seller de la saison.
Variante A (contrôle) : photo lifestyle “ambiance”. Variante B (test) : photo produit zoomée + badge “Best-seller de la semaine” + CTA “Voir le produit”.
Métrique primaire : taux de clic homepage → fiche produit best-seller (proxy d’engagement). Métrique secondaire : conversion homepage → checkout completed.
Le déroulement apparemment idéal
- Sample size calculé pour MDE 8 % : 38 000 visiteurs/variante
- Test lancé le 6 janvier 2025, durée prévue 21 jours
- Statlift sequential testing activé (donc peeking théoriquement autorisé)
Au jour 9, signification atteinte sur la métrique primaire : +18 % clics homepage → PDP, p = 0,004. Métrique secondaire (conversion checkout) : +6 %, p = 0,07 (à la limite).
L’équipe décide d’arrêter le test au jour 11 et de déployer la variante B sur 100 % du trafic homepage le 20 janvier.
6 semaines après : l’effondrement
Mesures post-déploiement (semaine du 24 février) :
- Clics homepage → PDP : +18 % → +3 % (effet largement dissipé)
- Conversion checkout : +6 % → -1 % (devenu négatif)
- AOV : flat
- Revenue brut : -4 % vs même période avant test
L’équipe revient au hero précédent en urgence. Perte estimée 6 semaines × revenu : ~120 K€.
Post-mortem, les 4 erreurs
Erreur 1, Peeking malgré sequential testing
Le sequential testing autorise le peeking sans inflater l’erreur de type I. Mais il ne corrige pas un autre biais : la décision impatiente.
Au jour 9, l’équipe a vu la signification, est tombée dans le piège du momentum : “ça marche, arrêtons !” Sans considérer que :
- 9 jours = moins d’un cycle hebdo complet (incomplet sur week-end vs semaine)
- Aucune mesure de novelty effect
- La métrique secondaire n’était pas significative
Apprentissage : sequential testing autorise techniquement le peeking, mais n’enlève pas la nécessité d’attendre un cycle métier complet (généralement 21+ jours).
Erreur 2, Sous-estimation du novelty effect
Le novelty effect : effet temporaire causé par la nouveauté visuelle. Les utilisateurs cliquent par curiosité, pas par préférence durable.
Sur un hero homepage, le novelty effect peut durer 3-5 semaines avant de se dissiper. Notre test a duré 9 jours. Toute notre mesure était du novelty.
Apprentissage : sur des changements visuels forts (hero, headlines, images), post-rollout monitoring de 6-8 semaines obligatoire. Si possible, holdout group (5 % du trafic exposé à la variante A pendant la mesure post-rollout) pour comparer.
Erreur 3, Segment biaisé non détecté
Re-analyse post-mortem segment par segment :
- Trafic Paid Search Brand : variante B +28 % (effet réel)
- Trafic Paid Search Non-Brand : variante B +12 % (effet partiel)
- Trafic SEO organique : variante B +2 % (quasi-flat)
- Trafic Direct/Returning : variante B -3 % (perdant !)
Le test a été lancé pendant une campagne paid forte en janvier (soldes). Le trafic Paid était sur-représenté pendant le test. Une fois la campagne paid terminée, la variante a perdu son avantage et le segment Returning (plus important hors-promo) a fait basculer le résultat global.
Apprentissage : toujours analyser par segment (source, returning vs new, device). Et ne jamais tester pendant une campagne saisonnière atypique sans en tenir compte.
Erreur 4, Instrumentation cassée sur 2 % du trafic
Audit technique post-déploiement : 2 % du trafic Safari ITP n’était pas trackée correctement (cookies réattribués mid-test). Sur 38 000 visiteurs/variante, ça représentait ~760 utilisateurs aux conversions non-mesurées.
Pas suffisant pour inverser le test à lui seul, mais suffisant pour gonfler artificiellement l’effet apparent en variante B (le pool tracké était biaisé en faveur de la variante gagnante).
Apprentissage : A/A test trimestriel + SRM detection automatique sont des garde-fous non négociables.
Ce qui a changé durablement
Après ce post-mortem, l’équipe a mis en place :
- Durée minimum de test : 21 jours (un cycle hebdo complet × 3 cycles). Pas d’exception.
- Post-rollout monitoring : 6 semaines systématique sur tout test déployé.
- Analyse par segment obligatoire avant déploiement (source, device, new vs returning).
- A/A trimestriel sur l’outil + SRM detection activée.
- Holdout group 5 % sur 60 jours post-déploiement pour les tests majeurs.
Conséquence : moins de tests déployés (3 par trimestre au lieu de 6), mais 0 régression non-détectée en 12 mois.
Ce qu’on aurait dû voir avant
Si on avait attendu 21 jours :
- Métrique primaire serait passée de +18 % à environ +6-8 %
- Métrique secondaire serait restée non-significative
- On n’aurait pas déployé.
Coût d’avoir attendu : 12 jours supplémentaires. Coût de ne pas avoir attendu : 120 K€.
Take-aways
| Erreur | Apprentissage |
|---|---|
| Peeking décisionnel | Sequential autorise mais n’oblige pas. Cycle hebdo complet min. |
| Novelty effect | Post-rollout 6-8 semaines, holdout group |
| Segment biaisé | Analyse segment systématique avant décision |
| Instrumentation cassée | A/A trimestriel + SRM detection automatique |
Trois règles de pouce :
- La signification statistique n’est pas une autorisation de déploiement. C’est un feu vert sous conditions.
- Toujours mesurer 21+ jours minimum, sauf cas exceptionnel.
- Un winner qui n’a pas survécu 6 semaines de prod n’est pas un winner. Documentez en interne pour ne pas refaire.
Pour la méthodologie statistique : Peeking, sequential testing et SRM. Pour les patterns gagnants documentés : Maison Loriot, 14 tests, 5 winners.
