Bandit algorithms vs A/B testing classique : quand utiliser quoi ?

Mis à jour le 15 octobre 2026

12,75 %. C’est le taux de faux gagnants que nous avons obtenu en appliquant un test statistique classique à la fin de tests pilotés par un algorithme bandit, sur 2 000 simulations où les deux versions étaient strictement identiques. Avec une répartition fixe 50/50, ce taux reste à 4,65 %, conforme au seuil de 5 % attendu. Le bandit n’est pas un mauvais outil. Il répond simplement à une autre question que l’A/B testing, et le lire comme un A/B test produit des erreurs.

Ce guide compare les deux approches sous l’angle statistique (exploration, Thompson sampling, regret, puissance), puis par cas d’usage, chiffres de simulation à l’appui.

Multi-armed bandit ou A/B testing : la réponse courte

Un test A/B classique répartit le trafic de façon fixe pour mesurer précisément l’écart entre deux versions ; un multi-armed bandit déplace le trafic vers la version qui semble gagner pour perdre le moins de conversions possible pendant le test. Choisissez l’A/B testing quand vous devez prendre une décision durable et chiffrer son impact, le bandit quand la fenêtre est courte et que seul le résultat cumulé compte.

Les deux méthodes optimisent deux grandeurs différentes :

• L’A/B testing minimise l’erreur d’estimation. Il vous dit si B bat A, de combien, avec quel intervalle de confiance. Vous payez cette certitude en envoyant la moitié du trafic sur la moins bonne version jusqu’à la fin.
• Le bandit minimise le regret, c’est-à-dire les conversions perdues par rapport à un monde où vous connaîtriez le gagnant dès le premier jour. Vous payez ce gain en précision : la version perdante reçoit trop peu de visiteurs pour être mesurée correctement.

Aucune méthode ne gagne sur les deux tableaux.

Exploration contre exploitation : le dilemme du bandit manchot

Le nom vient des machines à sous, les « bandits manchots » : face à plusieurs machines dont vous ignorez les gains, vous devez à la fois en essayer plusieurs (explorer) et jouer le plus souvent possible sur la meilleure (exploiter).

En CRO, chaque variante est un « bras », chaque visiteur une partie, la conversion le gain. Un test A/B classique fait 100 % d’exploration pendant le test, puis 100 % d’exploitation une fois le gagnant déployé. Un bandit mélange les deux en continu.

Le problème est ancien : William R. Thompson a publié dès 1933 la méthode qui porte son nom, pour des essais médicaux.

Si les termes « bras », « regret » ou « allocation » vous sont nouveaux, le glossaire de l’A/B testing et du CRO les définit en une ligne chacun.

Epsilon-greedy, UCB, Thompson sampling : trois façons d’arbitrer

Les trois familles d’algorithmes bandit diffèrent par la manière de doser l’exploration : au hasard (epsilon-greedy), par optimisme calculé (UCB) ou par tirage probabiliste (Thompson sampling), et c’est cette dernière qui domine aujourd’hui dans les outils de test.

Epsilon-greedy : simple, mais gaspilleur

L’algorithme envoie une part fixe du trafic, par exemple 10 %, au hasard entre toutes les variantes, et le reste sur la meilleure du moment. Simple, il continue pourtant d’alimenter une variante clairement mauvaise jusqu’à la fin. Les répartitions du type « 80 % selon la performance, 20 % au hasard » relèvent de cette logique.

UCB : l’optimisme face à l’incertitude

Upper Confidence Bound calcule pour chaque variante une borne haute de ce qu’elle pourrait rapporter, et choisit la plus élevée. Une variante peu testée a une borne large, donc elle sera essayée. Une variante très testée et médiocre ne le sera plus. Elle est déterministe, donc moins adaptée aux mises à jour par lots.

Thompson sampling : parier selon la probabilité d’être le meilleur

Pour chaque variante, l’algorithme tient une distribution de probabilité de son taux de conversion. À chaque visiteur, il tire une valeur dans chaque distribution et affiche la variante qui a tiré la plus haute. Résultat : une variante qui a 70 % de chances d’être la meilleure reçoit environ 70 % du trafic. Le tutoriel de référence de Russo et al. sur Thompson sampling détaille pourquoi cette règle approche le regret minimal théorique sans réglage particulier.

C’est la méthode retenue par la plupart des plateformes. La documentation de l’allocation dynamique d’AB Tasty indique qu’elle s’appuie sur Thompson, qu’elle n’affecte que les nouveaux visiteurs (un visiteur déjà exposé garde sa variante), et qu’elle attend au moins une conversion par variante sur l’indicateur choisi avant de démarrer. Le comparatif entre BlastOptimize et AB Tasty revient sur les différences de réglage entre les deux outils.

Le regret : ce qu’un test A/B coûte en conversions

Le regret est le nombre de conversions perdues pendant un test par rapport au scénario idéal où toute l’audience aurait vu la meilleure version dès le départ ; un 50/50 a un regret qui grandit en proportion du trafic, un bandit un regret qui ralentit au fil du test.

Prenons le cas déjà détaillé dans notre guide de l’autopilote BlastOptimize : 40 000 visiteurs, A convertit à 3 %, B à 3,6 %. En 50/50, A reçoit 20 000 visiteurs et B 20 000, soit 600 + 720 = 1 320 conversions. Si tout le monde avait vu B : 1 440. Le regret du test A/B vaut 120 conversions, soit 8,3 % des conversions possibles.

Le travail d’Elea Feit (Drexel) et Ron Berman (Wharton), intitulé « Test & Roll », le montre bien. Pour un site de 100 000 visiteurs, le test qui maximise le profit total n’a besoin que de 2 284 visiteurs par groupe, contre 18 468 pour un test d’hypothèse classique visant à détecter une hausse de 2 %. Le grand test « propre » coûte 476 conversions de plus. Les auteurs montrent aussi que le regret d’un test d’hypothèse grandit avec l’audience, celui de Thompson sampling seulement avec sa racine carrée.

Retenez l’idée : pour une campagne de quinze jours, presque tout le trafic est « dans le test » et le regret pèse lourd. Pour une page d’accueil qui vivra deux ans, le test n’en représente qu’une fraction.

Notre simulation : bandit contre 50/50 sur 2 000 tests

Nous avons rejoué 2 000 fois chaque scénario en comparant une répartition fixe à un Thompson sampling mis à jour par lots de 500 visiteurs : le bandit récupère les trois quarts du regret quand l’écart est réel, mais il détecte le gagnant moins souvent et multiplie presque par trois les faux positifs quand il n’y a pas d’écart.

Méthode : a priori Beta(1,1), mise à jour par lots, test z bilatéral à 5 % calculé à la fin, comme une équipe le ferait en lisant ses résultats.

Scénario	Regret 50/50	Regret Thompson	Significatif en fin de test (50/50 / Thompson)
40 000 visiteurs, 3 % contre 3,6 %	120 conversions	29 conversions	92 % / 66 %
40 000 visiteurs, aucune différence (3 % et 3 %)	0	2 conversions	4,65 % / 12,75 % de faux gagnants
Promotion de 20 000 visiteurs, 4 variantes (3 à 4,2 %)	136 conversions	54 conversions	non mesuré
Petit trafic : 4 000 visiteurs, 3 % contre 3,6 %	12 conversions	8 conversions	17 % / 14 %

Quatre enseignements :

• Le gain existe. Thompson ne perd que 29 conversions contre 120, cohérent avec le calcul du guide de l’autopilote (environ 1 408 conversions).
• La mesure se dégrade. La variante perdante ne reçoit en moyenne que 4 370 visiteurs. Résultat : le test devient significatif dans 66 % des cas seulement, contre 92 % en 50/50.
• Sans écart réel, le bandit crée des certitudes. Il poursuit le hasard des premiers lots, déséquilibre la répartition, et un test classique conclut alors à tort dans près d’un cas sur huit.
• Sur petit trafic, le bandit ne sauve rien. Avec 4 000 visiteurs, les deux méthodes désignent la mauvaise variante dans 15 à 17 % des cas, et l’écart de regret se limite à 4 conversions.

Le prix du bandit : puissance, biais et faux positifs

Un bandit sacrifie trois choses que l’A/B testing protège : la puissance statistique, l’absence de biais sur l’écart mesuré et la validité des tests de significativité classiques.

Moins de puissance

La puissance, probabilité de détecter un écart réel, dépend surtout du plus petit groupe. Un bandit affame volontairement ce groupe : bon pour vos conversions, mauvais pour votre mesure.

Un écart mal estimé

Une variante malchanceuse au départ reçoit vite moins de trafic : son estimation reste figée sur ses mauvais débuts, tandis que la favorite se corrige. L’écart affiché est donc biaisé, souvent surestimé. Avant de présenter une hausse issue d’un bandit à votre direction, prévoyez un test de confirmation.

Des p-values qui ne veulent plus dire la même chose

Les formules de significativité supposent une répartition décidée à l’avance. Quand c’est l’algorithme qui décide de la répartition à partir des résultats, l’hypothèse tombe. C’est un cousin du problème du « peeking », qui consiste à regarder les résultats en continu et à s’arrêter dès qu’ils paraissent favorables. Notre article sur les faux positifs en A/B testing explique pourquoi cette pratique fait exploser le taux d’erreur, et la liste des erreurs classiques des tests A/B la place parmi les plus courantes.

Les angles morts opérationnels

L’équipe d’expérimentation de DoorDash, qui a construit sa propre plateforme bandit fondée sur Thompson sampling, liste dans son retour d’expérience publié en décembre 2025 plusieurs limites concrètes : la difficulté d’analyser les indicateurs qui ne font pas partie de la récompense optimisée, l’expérience incohérente d’un utilisateur qui change de variante d’une visite à l’autre, et le retard entre l’action et le résultat. Pour limiter les biais quand le comportement des clients change dans le temps, l’équipe a choisi de modéliser l’écart avec la version de contrôle plutôt que le taux brut de chaque variante.

Quand choisir un algorithme bandit

Choisissez un bandit quand le coût de montrer la mauvaise version pendant le test dépasse la valeur de savoir précisément pourquoi l’autre gagne, ce qui arrive surtout sur des fenêtres courtes et des décisions sans lendemain.

• Campagnes à durée limitée : soldes, opération de Black Friday, lancement de produit. Sur une promotion de 20 000 visiteurs avec quatre accroches, notre simulation récupère 82 conversions sur 136, soit 60 % du coût du test, et il n’y aura pas de « déploiement » ensuite.
• Éléments à forte rotation : titres, objets d’emails, bannières, visuels publicitaires, remplacés chaque mois.
• Beaucoup de variantes, peu d’a priori : six accroches proposées par l’équipe ou générées par une IA. Le bandit écarte vite les plus faibles. Le test à répartition fixe paierait le prix fort pour chacune.
• Optimisation permanente : un bloc qu’on laisse tourner indéfiniment, en ajoutant parfois une variante.

Condition commune : l’indicateur optimisé doit se mesurer vite (clic, ajout au panier, envoi de formulaire) et refléter fidèlement la valeur. Sur un site marchand, notre page sur le CRO pour l’e-commerce détaille les pages où ces conditions sont réunies.

Quand garder un A/B testing classique

Gardez un A/B test à répartition fixe pour toute décision durable, coûteuse à annuler ou qu’il faudra justifier chiffres à l’appui, et pour tout test dont la conversion arrive avec retard.

• Refonte, prix, tunnel de paiement : quelques semaines de regret pèsent peu face au risque de déployer un faux gagnant pour des années.
• Besoin d’un chiffre d’impact : prévision de chiffre d’affaires, arbitrage budgétaire, rapport à la direction. Seule une répartition fixe donne un écart non biaisé avec un intervalle de confiance fiable.
• Conversions différées : en B2B ou en génération de leads, l’envoi du formulaire arrive vite mais la valeur réelle (lead qualifié, rendez-vous, signature) arrive des jours plus tard. Un bandit qui optimise l’envoi peut favoriser la variante qui attire les leads les moins qualifiés. Avant de lancer, définissez l’objectif et le tracking qui reflètent vraiment cette valeur.
• Plusieurs indicateurs à surveiller : un bandit optimise une seule récompense et mesure mal le reste, panier moyen compris.
• Effets différents selon les segments : une variante qui gagne sur desktop et perd sur mobile. Le bandit converge vers la moyenne et cesse d’envoyer le segment lésé sur la version qui lui convenait.
• Trafic faible : comme le montre la simulation à 4 000 visiteurs, le bandit n’apporte presque rien quand le signal est trop faible. Mieux vaut un test simple sur un changement marqué.

Même logique pour tester plusieurs éléments à la fois : notre comparatif entre test A/B et test multivarié montre que chaque combinaison ajoutée réclame du trafic supplémentaire.

Combiner les deux : trois stratégies hybrides

Les deux méthodes s’enchaînent bien : exploration rapide d’abord, mesure propre ensuite, selon l’enjeu.

1. Trier au bandit, confirmer en A/B

Lancez cinq ou six variantes en bandit pendant une à deux semaines pour éliminer les plus faibles. Confrontez ensuite les deux meilleures dans un A/B test à taille d’échantillon fixée d’avance.

2. Tester court, puis déployer (« test and roll »)

C’est la recommandation de Feit et Berman : dimensionner le test selon le profit attendu plutôt que selon un seuil de significativité. Le test est plus court, la répartition reste fixe et non biaisée, et le regret reste proche de celui d’un bandit.

3. Valider en A/B, exploiter au bandit

Pour un dispositif permanent (bannières, recommandations), un premier A/B test valide que le dispositif apporte bien un gain. Ensuite, un bandit gère la rotation des contenus à l’intérieur de ce dispositif. Gardez un petit groupe témoin permanent, par exemple 5 % du trafic, pour vérifier que le gain global tient dans le temps.

Quelle que soit la stratégie, la diffusion rapide des variantes compte : un clignotement de la page d’origine fausse les deux méthodes de la même façon. Et pour lire l’écart réel entre variantes, avec ses intervalles, le tableau de bord d’analyse de BlastOptimize affiche les résultats sans jargon.

Checklist : choisir la bonne méthode en 7 questions

Répondez à ces sept questions avant chaque test : au moins quatre réponses « bandit » sur les six premières orientent vers l’allocation automatique, sinon restez en répartition fixe. La septième vérifie que le test a une chance d’aboutir.

1. Durée de vie de la décision : moins d’un mois (bandit) ou plusieurs mois et plus (A/B) ?
2. Besoin d’un chiffre d’impact à présenter ou à réutiliser : non (bandit), oui (A/B) ?
3. Délai de la conversion : mesurable dans la session (bandit) ou plusieurs jours après (A/B) ?
4. Nombre de variantes : quatre ou plus sans favori clair (bandit), deux ou trois (A/B) ?
5. Indicateurs secondaires à surveiller (panier moyen, taux de remboursement, qualité des leads) : aucun (bandit), au moins un (A/B) ?
6. Segments susceptibles de réagir différemment : non (bandit), oui (A/B ou bandit contextuel avec un groupe témoin) ?
7. Trafic : au moins quelques centaines de conversions par variante attendues sur la durée (les deux sont possibles) ou moins (ni l’un ni l’autre ne tranchera : testez un changement plus marqué) ?

Moins de dix tests par an ? Évitez de payer une option peu utilisée : comparez avec les tarifs de BlastOptimize.

Ce qu’il faut retenir

Bandit et A/B testing répondent à deux questions différentes.

• L’A/B testing minimise l’erreur de mesure ; le multi-armed bandit minimise le regret, c’est-à-dire les conversions perdues pendant le test.
• Thompson sampling est l’algorithme de référence : chaque variante reçoit une part de trafic proportionnelle à sa probabilité d’être la meilleure.
• Dans notre simulation, le bandit récupère environ 75 % du regret d’un 50/50, mais la détection du gagnant passe de 92 % à 66 % et les faux gagnants de 4,65 % à 12,75 % sans écart réel.
• Bandit pour les campagnes courtes, les contenus à rotation rapide et les nombreuses variantes ; A/B testing pour les décisions durables, les conversions différées et les tests de prix.
• Sur petit trafic, aucune des deux méthodes ne fait de miracle.

Questions fréquentes

Un test bandit est-il plus rapide qu’un test A/B ?

Il est plus rapide pour exploiter, pas pour conclure. Comme la variante perdante reçoit peu de visiteurs, il faut souvent plus de trafic pour démontrer l’écart. Pour une conclusion statistique, l’A/B test à répartition fixe reste le chemin le plus court.

Peut-on calculer une significativité sur un test bandit ?

Pas avec les formules classiques, qui supposent une répartition décidée à l’avance. Dans notre simulation, les appliquer à un bandit produit 12,75 % de faux gagnants au lieu de 5 %. Utilisez plutôt la probabilité d’être la meilleure variante fournie par l’algorithme, ou confirmez le résultat par un A/B test court.

Combien de trafic faut-il pour utiliser un bandit ?

Le bandit n’a pas besoin de moins de trafic qu’un A/B test pour apprendre. Il lui faut des conversions sur chaque variante pour démarrer, au moins une selon la documentation d’AB Tasty, et en pratique quelques dizaines pour sortir du bruit des premiers lots. Avec quelques milliers de visiteurs au total, les deux méthodes se trompent souvent.

Thompson sampling ou epsilon-greedy : lequel choisir ?

Thompson sampling dans la grande majorité des cas : il adapte l’exploration à l’incertitude et ne gaspille pas de trafic sur une variante battue. Epsilon-greedy se justifie seulement si vous voulez une part d’exploration fixe et facile à expliquer.

Un bandit fonctionne-t-il pour la génération de leads B2B ?

Pour les éléments tactiques (accroche d’une landing page, visuel publicitaire, libellé d’un bouton), oui, si l’indicateur optimisé est l’envoi du formulaire. Pour les décisions structurantes, non : la qualité du lead se mesure trop tard pour guider l’algorithme, qui risque de favoriser les formulaires qui attirent des contacts peu qualifiés.

Qu’est-ce qu’un bandit contextuel ?

C’est un bandit qui choisit la variante selon le profil du visiteur : appareil, source de trafic, pages vues. Il sert à personnaliser plutôt qu’à désigner un gagnant unique, demande beaucoup plus de trafic et doit garder un groupe témoin pour mesurer son apport.