Si vous cherchez à gagner en vitesse dans le marketing de performance, il se peut que vous testiez vos A/B par la mauvaise méthode. Les tests fréquentistes classiques fonctionnent avec une taille d'échantillon fixe et une logique d'horizon défini : vous lancez le test, vous attendez 2 à 4 semaines, vous ne touchez à rien jusqu'à atteindre le seuil de p-value. Pendant ce temps, la variante gagnante est déjà évidente, mais vous ne pouvez pas décider. L'approche Bayésienne change ce point critique : avec la probabilité posterieure, vous pouvez évaluer la décision à chaque instant, réaliser des tests séquentiels, maintenir une taille d'échantillon dynamique. La fermeture du moteur Bayésien de Google Optimize n'a pas tué cette méthode — elle a plutôt ouvert la voie pour l'intégrer dans votre propre stack.
Le piège du temps avec les tests fréquentistes
La logique classique du test A/B repose sur cette hypothèse : le test doit continuer jusqu'à ce que la p-value chute sous 0,05, et faire un contrôle intermédiaire augmente le risque de faux positif. Théoriquement correct, mais deux problèmes en découle en pratique. D'abord : si vous voulez arrêter le test tôt, il n'existe pas de garde-fou statistique — le risque de mauvaise décision est présent. Ensuite : même si la variante gagnante est évidente tôt, vous êtes obligé d'attendre jusqu'à remplir la taille d'échantillon fixe — une période moyenne de 14 à 21 jours.
Derrière cette approche se trouve le cadre de test d'hypothèse de Neyman-Pearson : vous prenez la décision de rejeter ou non l'hypothèse nulle via un seul seuil (généralement α = 0,05). Le problème : ce seuil est lié au calcul de la taille d'échantillon fixe, donc il ne vous permet pas de prendre des décisions dynamiques pendant le test. Par exemple, la variante B affiche 18 % de conversion tandis que le contrôle stagne à 12 %, et cette différence émerge après 500 utilisateurs — le cadre fréquentiste dit « continue à attendre, tu n'as pas atteint les 2000 utilisateurs prévus ».
Le problème s'accentue encore avec les tests d'applications mobiles. Pour une app avec 5000 utilisateurs actifs quotidiens, détecter un uplift de 2 % nécessite ~8000 utilisateurs d'échantillon — cela représente 2 semaines. Mais si le signal gagnant apparaît le jour 3, vous envoyez du trafic vers la variante perdante pendant 11 jours. C'est du manque à gagner (opportunity cost).
Approche Bayésienne : mise à jour continue avec la probabilité posterieure
La statistique Bayésienne pose une question différente : « Quelle est la probabilité que cette variante soit meilleure que le groupe de contrôle ? » La réponse n'est pas une p-value, mais une distribution de probabilité posterieure. Vous mettez à jour le prior (votre croyance initiale) avec chaque nouveau point de données (chaque nouvel utilisateur) et recalculez la posterieure. Cela vous permet de dire « la variante B a 95 % de probabilité que son taux de conversion soit plus élevé que le groupe de contrôle » — et cette affirmation autorise les tests séquentiels.
Mathématiquement, le théorème de Bayes fonctionne avec cette formule :
P(θ|data) = P(data|θ) × P(θ) / P(data)
Ici, θ est le taux de conversion, P(θ) est le prior (votre croyance initiale), P(data|θ) est la vraisemblance (la probabilité des données observées sous θ), et P(θ|data) est la posterieure (votre croyance mise à jour). Par exemple, si vous utilisez Beta(1,1) comme prior — c'est-à-dire une distribution uniforme — chaque conversion augmente le paramètre α de +1, et chaque bounce augmente β de +1. 100 visiteurs, 18 conversions = Beta(19, 83). Vous comparez cette distribution posterieure avec celle du groupe de contrôle pour calculer « la probabilité que B > A ».
L'article VWO de Chris Stucchio en 2015 a été l'une des premières études de cas portant cette logique en production : tester de manière identique en approche Bayésienne vous offre en moyenne 40 % de résultats plus rapides, car l'arrêt précoce est maîtrisé. Le framework d'expérimentation interne de Google a commencé à partir de 2018 à utiliser des posterieures Bayésiennes comme métrique intermédiaire (aucune documentation publique, mais mentionné dans le livre de Kohavi et al.).
Test séquentiel et règle d'arrêt
Le plus grand avantage de l'approche Bayésienne est la capacité à réaliser des tests séquentiels. Chez les fréquentistes, faire un contrôle intermédiaire en calculant la p-value gonfle l'erreur de type I (problème de comparaisons multiples). Chez les Bayésiens, la probabilité posterieure est toujours une métrique valide car c'est un état de croyance continuellement mis à jour. Vous pouvez donc vérifier « la probabilité posterieure de B > A » chaque jour, arrêter le test lorsqu'elle dépasse 95 %, et c'est statistiquement solide.
La règle d'arrêt fonctionne ainsi :
- Définissez une taille d'échantillon minimum (ex. 200 utilisateurs par variante — pour filtrer le bruit initial)
- Mettez à jour les posterieures chaque jour
- Arrêtez le test quand
P(variante_B > contrôle) > 0,95 - Après 14 jours, si vous n'avez pas atteint 95 %, marquez comme « inconclus »
Cette approche est celle que nous utilisons dans nos processus d'Optimisation du Taux de Conversion : déterminer le prior au démarrage du test, mettre à jour automatiquement les posterieures chaque jour, établir le seuil de règle d'arrêt avec l'équipe d'ingénierie. Par exemple, dans un test de flux de paiement d'e-commerce, nous utilisons un seuil de 98 % au lieu de 95 % car le coût d'un faux positif est élevé — un changement de page de paiement affecte directement le volume de transactions.
Taille d'échantillon dynamique et calcul de perte attendue
Chez les fréquentistes, le calcul de la taille d'échantillon se fait en amont via l'analyse de puissance : vous fournissez l'effet minimum détectable (MDE), la puissance statistique (80 %), le niveau de significativité (α = 0,05), et vous attendez le chiffre résultant. Chez les Bayésiens, la taille d'échantillon est dynamique car la distribution posterieure peut vous mener à une conclusion anticipée. Mais ce n'est pas « arrête-toi quand tu veux » — le concept de perte attendue intervient.
La perte attendue est le coût métrique d'une mauvaise décision. Disons que la posterieure montre que la variante B a 92 % de chance de gagner. Mais il y a 8 % de probabilité que A soit meilleur, et si vous choisissez B, vous subirez une perte de uplift. La perte attendue quantifie ce scénario :
E[Loss_B] = ∫ max(0, θ_A - θ_B) × P(θ_A, θ_B | data) dθ
En termes pratiques : « Si je choisis B et me trompe, la perte attendue est 0,3 point de taux de conversion ». Cette valeur peut être convertie en devise — par exemple, 10 000 sessions quotidiennes, perte de 0,3 % = 30 conversions manquées = multipliez par la valeur de commande moyenne pour obtenir le coût quotidien.
Le « Calculateur de Test A/B Bayésien » d'Evan Miller automatise ce calcul : vous fournissez le nombre de conversions + taille d'échantillon pour le contrôle et la variante, et il retourne la posterieure + la perte attendue + la probabilité que chaque variante soit la meilleure. Cet outil ne suffit pas pour un déploiement en production, mais il est idéal pour comprendre le concept. En production, nous utilisons pymc en Python ou rstan en R pour l'échantillonnage posterieur et calculons la perte attendue via Monte Carlo.
Perspective de minimisation du regret
Il existe un concept tiré de la littérature des bandits multi-bras : le regret. Dans un test A/B, le regret est la perte totale due au fait de ne pas choisir la variante optimale. Les tests séquentiels Bayésiens tentent de le minimiser car lorsqu'un signal gagnant apparaît tôt, vous pouvez décider rapidement. Chez les fréquentistes, le regret croît linéairement au cours du test (car vous continuez à envoyer du trafic vers la variante perdante), alors que chez les Bayésiens, il croît sublinéairement — car vous arrêtez tôt.
Le calcul du regret est critique pour les tests de pages d'accueil d'e-commerce. Par exemple, pendant une campagne Black Friday avec un fenêtre de test de 48 heures. La planification fréquentiste exige 2000 utilisateurs d'échantillon, et si le trafic quotidien est 3000, vous risquez de ne pas compléter le test. Avec Bayesian, si vous pouvez décider avec 97 % de posterieure après 12 heures, vous pouvez ouvrir la variante gagnante à 100 % du trafic pendant les 36 heures restantes et réduire le regret à zéro.
Application : Pipeline de test A/B Bayésien avec Python
Passons de la théorie à la pratique : voyons comment mettre en production les tests Bayésiens. Le code ci-dessous récupère les données de test depuis BigQuery, calcule les posterieures et contrôle la règle d'arrêt :
import numpy as np
from scipy.stats import beta
def calculate_posterior(conversions, trials, prior_alpha=1, prior_beta=1):
"""Calculer posterieure avec le prior conjugué Beta-Binomial"""
return beta(prior_alpha + conversions, prior_beta + trials - conversions)
def prob_b_beats_a(posterior_a, posterior_b, samples=100000):
"""Calculer P(B > A) avec Monte Carlo"""
samples_a = posterior_a.rvs(samples)
samples_b = posterior_b.rvs(samples)
return (samples_b > samples_a).mean()
def expected_loss(posterior_a, posterior_b, samples=100000):
"""Calculer perte attendue si on choisit B"""
samples_a = posterior_a.rvs(samples)
samples_b = posterior_b.rvs(samples)
loss = np.maximum(0, samples_a - samples_b)
return loss.mean()
# Exemple de données : Contrôle 1000 session / 120 conversion, Variante 1000 / 145
posterior_control = calculate_posterior(120, 1000)
posterior_variant = calculate_posterior(145, 1000)
prob_win = prob_b_beats_a(posterior_control, posterior_variant)
loss_variant = expected_loss(posterior_control, posterior_variant)
print(f"P(Variante > Contrôle): {prob_win:.3f}")
print(f"Perte attendue si on choisit Variante: {loss_variant:.4f}")
# Règle d'arrêt
if prob_win > 0.95 and loss_variant < 0.01:
print("DÉPLOYER VARIANTE")
elif prob_win < 0.05:
print("DÉPLOYER CONTRÔLE")
else:
print("CONTINUER LE TEST")
Vous pouvez intégrer ce code dans un modèle dbt et l'exécuter selon un calendrier quotidien. Si vous avez une table BigQuery avec test_id, variant, session_count, conversion_count, vous pouvez calculer les posterieures via une fonction définie par l'utilisateur (UDF) Python et écrire le résultat dans une nouvelle table. Connectée à un tableau de bord Looker ou Metabase, votre équipe produit verra le graphique de la posterieure en temps réel.
Compromis et quand rester fréquentiste
L'approche Bayésienne n'est pas supérieure dans tous les cas. Trois scénarios se distinguent :
1. Tests soumis à la conformité réglementaire : Les essais pharmaceutiques, le secteur financier, les modèles de tarification d'assurance — les régulateurs (FDA, EMA) considèrent la p-value fréquentiste comme le standard. Si vous utilisez la posterieure Bayésienne, une documentation supplémentaire est requise.
2. Taux de base très bas : Par exemple, un taux de conversion de 0,5 % à une étape d'entonnoir. Avec Bayesian, le choix du prior devient critique. Un prior non informatif (Beta(1,1)) rend difficile la distinction du bruit du signal ; un prior informatif introduit un biais subjectif. Ici, fréquentiste semble plus « sûr ».
3. Campagnes uniques à forts enjeux : Comme un test de page d'accueil Black Friday annuel. Si vous arrêtez la méthode Bayésienne tôt et vous vous trompez, vous ne pouvez pas revenir en arrière car la campagne est terminée. Un fréquentiste prudent + correction de Bonferroni peut être préférable.
Mais en dehors de ces exceptions — notamment dans les environnements SaaS, e-commerce et app mobile où l'itération est continue — le gain de vitesse de Bayesian est manifeste. Netflix, Booking.com, Spotify l'utilisent en interne (ils en parlent dans leurs tech blogs publics).
Accélérer la prise de décision
Le test A/B Bayésien n'est pas juste un changement statistique — c'est réorganiser votre processus de décision