Test AB ou bandit IA : 30 jours de données CRO et le vrai compromis

J’ai cessé de programmer le test AB suivant sur ma landing page la plus fréquentée pour confier le trafic à un multi armed bandit — autrement dit, un bandit multi-bras — piloté par l’IA. Trente jours plus tard, les inscriptions avaient progressé et l’algorithme avait presque coupé le trafic de la variante perdante. En revanche, impossible d’attribuer cette hausse avec un résultat statistiquement significatif : ce n’est tout simplement pas ce que produit un bandit. Tout l’enjeu est là.

Le chiffre, puis sa contrepartie

Cette page de vente longue convertit à la fois un trafic payant froid et des visiteurs organiques déjà sensibilisés en inscriptions à l’essai. Pendant les 30 jours précédant l’activation du bandit, son taux de conversion moyen était de 3.41%. Même page, même offre, même répartition du trafic : sur les 30 jours suivants, après avoir confié l’allocation au bandit, il est passé à 4.62%. Soit une hausse relative de 35.5% sur l’événement de conversion principal.

Mais avant de faire une capture d’écran de ce chiffre, il faut préciser ce qu’il mesure : une amélioration du résultat cumulé, pas un effet causal identifié. Un bandit multi-bras réalloue le trafic à la variante qui gagne à cet instant. Il ne conserve pas une répartition nette à 50/50 assez longtemps pour calculer l’intervalle de confiance d’une variante donnée. Pas de valeur p. Pas de « la variante B a battu la variante A avec un niveau de confiance de 95% ». Seulement ce constat : « sur l’ensemble des visiteurs, davantage de personnes ont converti que pendant la période de contrôle précédente ». Ces affirmations ne se valent pas, et un conseil d’administration averti demandera laquelle vous avancez.

Côté coûts, pour situer l’expérience : environ 84,000 pages vues sont passées par le bandit en 30 jours. J’ai dépensé $299 pour un mois de Webflow Optimize avec le forfait 100K vues, auxquels s’est ajouté un pilote Coframe (tarif sur devis — j’y reviens plus loin). Au total, moins de $500 de coûts de plateforme pour une hausse bien réelle sur une page qui génère un volume significatif d’essais. L’équation économique tient. La réserve sur l’attribution, elle, demeure.

Pourquoi j’ai abandonné le test AB prévu

La page se trouve au bout de deux sources de trafic : les campagnes Meta payantes qui suivent la rotation AdCreative.ai / Pencil Pro / contrôle humain déjà détaillée, puis le trafic organique et les visites envoyées par les moteurs d’IA grâce au playbook GEO sur 14 jours. Au total : environ 2,800 sessions par jour, avec une répartition payant/organique de 30/70 qui fluctue d’une semaine à l’autre.

Ce profil de trafic est précisément celui qui se prête mal à un test AB classique. Pour détecter une hausse relative de 10% avec une puissance de 80%, à partir d’un taux de conversion initial de 3.4%, il me fallait environ 50,000 visiteurs par branche. Avec deux variantes maintenues à 50/50, le test aurait duré quelque 35 jours. Autrement dit, cinq semaines à envoyer 50% du trafic payant vers une variante que l’on sait perdante, en attendant d’atteindre la significativité. Avec un CPL de $24 sur le trafic payant, chaque point de sous-performance de cette variante revenait à brûler de l’argent, délibérément.

C’est le problème du regret. Un test AB repose sur l’exploration pure : la répartition reste fixe parce qu’il faut préserver la puissance statistique. Le prix à payer consiste à servir une mauvaise expérience à la moitié des visiteurs pendant toute la durée du test. Un bandit échange cette qualité d’inférence contre de meilleurs résultats cumulés : il exploite la variante en tête tout en continuant à explorer les autres. Sur des problèmes stationnaires, les comparaisons empiriques montrent qu’il réduit le regret cumulé de 30–60% par rapport à un test AB réparti à parts égales.

Voici la règle de décision que j’avais fixée avant de commencer :

• Bandit lorsque le trafic est faible au regard de l’effet à détecter, qu’exposer la variante perdante coûte cher, que la page fonctionne en continu sans fenêtre de campagne définie et que les conversions cumulées du trimestre comptent davantage qu’un chiffre causal défendable.
• Test AB lorsqu’il faut justifier la hausse auprès de la personne responsable du P&L, lorsque la modification est importante et rare (prix, hero, positionnement), ou lorsque les variantes diffèrent trop pour permettre un apprentissage commun.

Cette page cochait toutes les cases du bandit. J’ai donc annulé le test AB en attente et lancé le bandit.

La stack : chaque outil et chaque coût

J’ai évalué quatre outils d’optimisation continue par l’IA, plutôt que des solutions limitées aux workflows de test AB classiques. Deux ont été déployés en production ; j’ai étudié sérieusement les deux autres avant de les écarter pour cette expérience. Voici mon bilan, sans détour.

Coframe. Son moteur repose sur une version modifiée du bandit multi-bras. Il génère des variantes de textes, de visuels et même de code de composants, puis répartit le trafic entre elles. L’installation passe par une balise script. L’entreprise a levé environ $9M. Le tarif est disponible uniquement auprès du service commercial : il n’existe aucune page de prix publique. C’est déjà une information utile pour planifier le projet : budget imprévisible, cycle commercial obligatoire avant le moindre test et approche enterprise peu adaptée aux indépendants. J’ai mené un pilote. Sur les quatre outils, Coframe produisait les meilleures variantes génératives, mais aussi le parcours d’achat le plus contraignant.

Webflow Optimize. La solution s’appuie sur le moteur Intellimize acquis par Webflow. Le forfait Standard coûte $299/month pour 100K pages vues ; les paliers sont de 25K, 50K, 100K, 250K et 500K. Il autorise jusqu’à 5 tests simultanés. Il ne fonctionne qu’avec les pages hébergées sur Webflow : aucun problème dans mon cas, mais c’est rédhibitoire si le site repose sur une autre plateforme. C’est l’outil que j’ai utilisé en production pendant 30 jours, car la page était déjà sur Webflow et que le calcul du coût des forfaits Webflow était déjà réglé.

Optimizely Opal. Une couche d’expérimentation pilotée par des agents, ajoutée à la plateforme Optimizely existante. D’après les propres chiffres publiés par Optimizely, les utilisateurs d’Opal lancent 78.7% d’expériences en plus, 24.1% de campagnes de personnalisation supplémentaires et obtiennent une hausse de 9.3% du taux de réussite. Ce sont des chiffres fournisseur, calculés selon sa propre méthodologie ; je les cite pour que vous puissiez les pondérer comme il se doit. Tarification enterprise. L’offre avait du sens pour une équipe déjà cliente d’Optimizely, pas pour une seule landing page.

VWO Copilot. Une stack Testing + Insights + Personalize complétée par une couche d’IA. C’est la plateforme la plus établie, et son approche des fonctions d’IA reste profondément ancrée dans le modèle classique du test AB. Je la choisirais pour un workflow de test AB propre, enrichi par l’IA, plutôt que pour un workflow centré sur le bandit où le test AB n’est qu’une option.

Pour cette expérience : Webflow Optimize en production durant l’intégralité des 30 jours, et Coframe en pilote parallèle sur une page secondaire afin de comparer la qualité des variantes.

Le playbook d’optimisation du taux de conversion sur 30 jours

Jours 0–3 : instrumenter et figer. Un seul événement de conversion : l’inscription à l’essai, confirmée côté serveur, et non un clic sur un bouton. Tout ce qui est comptabilisé côté client gonflera les résultats de chaque variante de la même manière ; vous croirez progresser alors que vous ne faites que recycler du bruit. J’ai figé le contrôle : la page existante est restée la variante A, sans aucune modification, avec un plancher garanti de 20% du trafic pendant toute l’expérience. Je conservais ainsi une cohorte témoin exploitable par la suite. Sans ce plancher, le bandit aurait privé le contrôle de trafic dès l’apparition d’un leader et je n’aurais plus eu de point de comparaison.

Jours 4–10 : générer et laisser apprendre. J’ai lancé quatre variantes portant sur le titre du hero, le texte du CTA principal et l’ordre du bloc de preuve sociale. La première semaine correspond à la phase d’exploration du bandit. La répartition semblait presque uniforme : 22%, 19%, 21%, 18% et 20% entre le contrôle et les quatre variantes au jour 7. C’est généralement là que les opérateurs paniquent et cherchent à « aider » l’algorithme. Ne le faites pas. Modifier les variantes pendant l’apprentissage réinitialise les a priori et fait perdre toute la semaine.

Jours 11–21 : observer la courbe de réallocation. Vers le jour 12, le bandit a commencé à pencher visiblement en faveur d’une variante. Au jour 18, la gagnante recevait 41% du trafic ; le contrôle restait à son plancher de 20%, les deux variantes intermédiaires tournaient autour de ~15% chacune, et la pire était passée sous les 10%. Le bandit remplissait sa mission : chaque visiteur envoyé vers la perdante représente du regret, que l’algorithme réduit en temps réel.

Jours 22–30 : verrouiller et décider. J’ai retenu la direction gagnante, et non la variante au mot près : hero plus court, CTA centré sur le bénéfice, preuve sociale au-dessus de la ligne de flottaison. Puis j’ai exporté les variantes. Au jour 30, une question se pose : faut-il promouvoir la gagnante dans un test AB propre face au contrôle, afin d’obtenir un résultat causal présentable au conseil d’administration, ou laisser le bandit tourner sur une nouvelle série de variantes ?

Mes garde-fous pendant toute l’expérience : un plancher de 20% du trafic pour le contrôle ; un coupe-circuit si la borne inférieure de confiance d’une variante révélait une baisse relative de 50% face au contrôle pendant plus de 48 heures ; et une vérification hebdomadaire de l’évolution du mix de trafic. Si la part payant/organique variait de plus de 10 points d’une semaine à l’autre, je gelais le bandit jusqu’à stabilisation. Un trafic non stationnaire est un piège silencieux.

Le problème d’attribution, sans faux-semblants

C’est le passage que les comparatifs superficiels omettent. C’est aussi la seule raison d’être de cet article.

Par construction, un bandit multi-bras ne permet pas d’établir la significativité statistique d’une variante isolée. L’appareil statistique du test AB — valeurs p, intervalles de confiance, calculs de puissance — suppose une règle d’allocation fixe. Or toute la proposition de valeur du bandit repose sur une allocation qui ne l’est pas : elle évolue selon les premiers résultats observés. Dès que l’allocation dépend des résultats, l’inférence classique ne tient plus. Chaque branche contient des échantillons biaisés. Il reste possible de mesurer les conversions cumulées dans la population complète, mais pas d’établir proprement que la variante B a causé un meilleur résultat que la variante A.

Ce n’est pas un bug, mais le principe même du système. Le bandit poursuit un autre objectif : réduire le regret cumulé et maximiser les conversions cumulées. Les comparaisons empiriques montrent régulièrement une réduction du regret de 30–60% par rapport à un test AB à répartition égale sur des problèmes stationnaires. La bonne métrique est donc « moins de regret », pas « hausse causale démontrée pour la variante B ».

Cette distinction impose un vocabulaire rigoureux :

• Défendable : « Après le déploiement du bandit, la page a converti à 4.62% sur 84,000 visiteurs en 30 jours, contre 3.41% sur la même page pendant les 30 jours précédents. »
• Indéfendable : « La variante B a provoqué une hausse de 35% du taux de conversion. »

La première phrase décrit un résultat cumulé. La seconde avance un lien causal que le bandit ne permet pas d’établir.

Ma demi-solution : réserver 20% du trafic au contrôle. En garantissant à la page d’origine une allocation de 20% pendant les 30 jours, j’ai conservé une cohorte de comparaison réduite, mais propre. Sur la période, cette cohorte a converti à 3.38% — pratiquement au même niveau que pendant les 30 jours précédents. La cohorte hors contrôle a atteint 4.93%. J’obtiens ainsi une lecture directionnelle : la hausse est réelle, pas un simple effet de saisonnalité. Ce n’est toujours pas un résultat propre issu d’un test AB, puisque le groupe hors contrôle est lui-même composé d’un mix de variantes mouvant. Mais cela suffit pour expliquer au conseil d’administration : « l’expérience a battu son propre groupe témoin interne ; voici l’écart, ce que nous affirmons et ce que nous n’affirmons pas ».

Si vous avez besoin d’un résultat causal défendable, utilisez le bandit pour repérer la direction prometteuse, puis opposez la variante en tête au contrôle dans un test AB à 50/50. Ce workflow respecte à la fois le budget de regret de l’opérateur et le niveau de preuve exigé par l’analyste.

Les cas où le bandit n’a rien amélioré

J’ai appliqué le même playbook à deux pages sur lesquelles le bandit a fait moins bien qu’un simple test AB. La première était une page de tarifs à faible trafic, avec moins de 400 sessions quotidiennes. Le bandit a mis trop de temps à sortir de l’exploration et les tendances restaient bruitées. Un simple test AB à 50/50 sur six semaines m’a apporté une réponse plus nette, avec moins de travail opérationnel. La seconde était un tunnel de paiement où l’événement de conversion survenait 3–5 jours après l’exposition à la variante. Les bandits supposent un retour relativement rapide ; lorsque le délai entre exposition et résultat s’allonge, l’algorithme réalloue le trafic à partir de données périmées et poursuit des mirages.

J’ai rejeté environ 40% des variantes générées par Coframe, et une proportion plus faible de celles de Webflow Optimize. Les signes ne trompaient pas : tirets cadratins là où ils n’avaient rien à faire, verbes grandiloquents interchangeables, rythme de listes parallèles évoquant un modèle qui s’efforce de parler comme un marketeur. Tout texte tombé dans l’étrange vallée de la voix de marque était écarté avant de recevoir du trafic. Ce taux de rejet est le coût que les pages tarifaires ne mentionnent jamais.

Le piège du trafic non stationnaire a failli se refermer pendant la troisième semaine. La part du trafic payant est passée de 30% à 47% en quatre jours lorsqu’une campagne Meta a changé d’échelle. La variante en tête s’était imposée sur un autre mix de trafic que celui qui arrivait désormais, et son taux de conversion a commencé à fléchir. J’ai gelé le bandit pendant 48 heures, attendu que le mix se stabilise, puis relancé une nouvelle exploration. Si je l’avais laissé tourner, il aurait tiré une mauvaise conclusion d’une audience temporairement différente.

Le principe à reproduire

Voici la règle de décision, généralisée et débarrassée des particularités de ma page :

Lancez un bandit lorsque le trafic est faible au regard de la hausse à détecter, que montrer une variante perdante à la moitié des visiteurs représente un vrai coût, que la page fonctionne en continu sans fenêtre de campagne et que les conversions cumulées du trimestre priment sur un chiffre causal défendable pour une variante donnée. Lancez un test AB lorsqu’il faut justifier la hausse auprès de la personne responsable du P&L, lorsque le changement est assez important et assez rare pour exiger une lecture nette avant de s’engager, ou lorsque la variante gagnante doit être déployée sur d’autres surfaces et qu’il faut savoir si elle a réellement fonctionné.

La plupart des opérateurs finiront par employer les deux. Le bandit convient aux surfaces de conversion permanentes : page d’accueil, page d’offre principale, tunnel d’inscription. Le test AB sert aux paris de fond : tarification, positionnement, refonte du hero. L’erreur consiste à opposer les deux méthodes alors qu’elles optimisent des objectifs différents. Les comparatifs se trompent lorsqu’ils présentent le bandit comme une amélioration gratuite, sans contrepartie statistique. Ce n’est pas le cas. Le prix à payer, c’est la valeur p : il faut l’accepter en connaissance de cause, ou ne pas lancer de bandit.

À l’échelle décrite ici, le fonctionnement continu coûte $299/month pour Webflow Optimize avec le forfait 100K pages vues, puis davantage à mesure que le trafic augmente. Prévoyez aussi une demi-journée de travail opérateur par semaine pour contrôler les allocations, éliminer les mauvaises variantes et surveiller les dérives non stationnaires. Voilà le coût réel. Si vous intégrez ce workflow à une agence ou à une équipe growth interne et souhaitez de l’aide pour relier proprement l’attribution des conversions au CRM et au data warehouse, c’est un autre sujet. Le déploiement du bandit lui-même ne demande toutefois qu’un opérateur, un après-midi et une balise script.

Un seul CTA, car cet article est long et mérite une prochaine étape claire : la checklist d’audit des workflows métier par l’IA est celle que j’utilise pour déterminer quelles surfaces peuvent accueillir un bandit et lesquelles exigent un véritable test AB. Passez votre funnel au crible avant de choisir l’outil. Choisir l’outil en premier, c’est ainsi que les équipes growth finissent par payer pour des fonctions qu’elles n’ont pas le trafic nécessaire pour exploiter.