L’A/B test classique modifie des éléments sur la même page (titre, formulaire, agencement). Le test par redirection oppose deux expériences complètes sur deux adresses distinctes. Le choix dépend surtout de l’ampleur du changement. Cette méthode ajoute un biais propre, la redirection, qui peut invalider le verdict si vous ne le neutralisez pas.
Ce choix se pose en amont de toute démarche de CRO avancé et d'analyse comportementale : le mauvais outil biaise la mesure avant même que le test ne commence.
On présente souvent le choix comme une question d’outil ou de plateforme de test. Cet angle masque le vrai critère de décision. Le sujet concret est : quelle est l’ampleur de ce que vous testez ? C’est une décision à prendre en amont, quand vous posez votre méthode de test et d’analyse comportementale, pas au moment d’ouvrir votre plateforme d’expérimentation.
L’A/B classique modifie des éléments sur un support existant : vous changez le titre, raccourcissez le formulaire, déplacez un bloc, ajustez le CTA. La même URL sert la version A ou B par substitution. C’est l’outil des variations incrémentales, et c’est l’immense majorité des expériences utiles, la plupart des décisions d’optimisation se jouent à ce niveau, pas à celui de la refonte.
Le test par redirection, lui, oppose deux destinations complètes, chacune à son adresse. C’est l’outil des changements radicaux : refonte complète, deux concepts qui n’ont presque rien en commun, deux tunnels de conversion différents, deux parcours de destination distincts, bref tout ce qu’on ne peut pas tester par substitution d’éléments.
A/B classique pour une variation localisée ; test par redirection pour une refonte complète.
Le mythe « c’est pareil, l’un redirige c’est tout » rate l’essentiel : on ne choisit pas cette méthode par goût de la redirection, on l’utilise quand l’ampleur du changement rend la substitution impossible.
L’utiliser pour tester un simple titre est surdimensionné : vous dupliquez une destination entière et ajoutez un biais pour un changement qu’une substitution gérait sans risque.
A/B classique
Test par redirection
Les outils de CRO couvrent systématiquement un trio, pas un duo. Ignorer le troisième crée un angle mort réel : le test multivarié (MVT). Il compare plusieurs éléments simultanément sur un seul support, et révèle les interactions entre eux (le titre X fonctionne-t-il mieux avec l’image Y ou Z ?). Mais sa condition d’entrée est stricte : un volume de trafic très élevé, parce que le MVT génère de nombreuses combinaisons et dilue l’échantillon plus vite qu’une expérience à deux variantes. Sous ce seuil, il ne conclut pas, vos résultats restent non significatifs, quelle que soit sa durée.
| Critère | A/B classique | Test par redirection | Multivarié (MVT) |
|---|---|---|---|
| Ce qu’on teste | un élément à la fois, même support | deux destinations complètes, deux adresses | plusieurs éléments simultanément, même support |
| Même adresse | oui | non (redirection) | oui |
| Trafic minimum | modéré | élevé (bruit redirection) | très élevé (nombreuses combinaisons) |
| Biais principaux | faible | vitesse, tracking, indexation, SRM | dilution de l’échantillon |
| Cas d’usage idéal | variation incrémentale (titre, CTA, formulaire) | refonte radicale, deux concepts | optimisation d’interactions entre éléments |
Le MVT n’est pas détaillé ici : il concerne surtout les comptes avec un trafic conséquent et une pratique mature de l’expérimentation. Mais savoir le situer évite de confondre les trois outils et d’utiliser le mauvais pour la mauvaise question.
Voici les points souvent négligés qui peuvent invalider un test par redirection. Ce passage intermédiaire a un coût, et ce coût biaise le résultat sur trois fronts classiques, plus un quatrième que la plupart des guides ignorent complètement.
La vitesse. Rediriger prend du temps, quelques fractions de seconde, parfois plus selon l’implémentation. Sur une connexion lente, certains visiteurs voient la version d’origine s’afficher un instant avant que le script ne bascule vers la variante, un délai qui n’existe pas dans un A/B classique, où les deux versions partagent le même chargement initial. Si l’une des deux destinations se charge plus lentement (à cause de la redirection ou de sa propre conception), elle perdra des conversions et des visiteurs pour une raison qui n’a rien à voir avec son contenu : juste parce qu’elle est plus lente. La vitesse reste un levier majeur de la conversion après le clic. Vous croiriez tester deux concepts, vous testeriez en réalité deux vitesses. Il faut mesurer et, autant que possible, égaliser les temps de chargement avant de conclure, et vérifier que la perte de visiteurs pendant la redirection reste comparable sur les deux variantes, sinon l’échantillon lui-même est biaisé avant la première conversion.
Le suivi. Avec deux adresses distinctes, vous devez vous assurer que la mesure des conversions est cohérente et identique des deux côtés : mêmes événements, même définition, même fiabilité, mêmes données remontées à votre outil d’analyse. Une mesure qui fonctionne mieux sur une version que sur l’autre fabrique un faux écart et fausse le taux de conversion. La cohérence entre les deux versions est un prérequis, pas un détail.
L’indexation. Deux adresses qui servent un contenu concurrent posent des questions d’adresse canonique et d’indexation à traiter pour ne pas brouiller votre référencement pendant le test : le SEO de la page n’attend pas la fin de l’expérimentation. C’est une dimension que l’A/B classique n’a pas. Ce surcoût vient s’ajouter aux biais d’historique et de saisonnalité qu’un test doit déjà neutraliser : la redirection en empile un de plus, propre à elle.
Utilisez une 302 (temporaire) plutôt qu’une 301 (permanente). Une 301 signale à Google que l’adresse d’origine est remplacée définitivement, le moteur peut transférer l’autorité SEO vers la variante, et les effets sont difficiles à annuler une fois le test terminé. Une 302 indique un état provisoire et préserve le statut de la page originale dans l’index pendant toute la durée du test.
Ce point s’applique aussi bien aux outils de CRO (VWO, AB Tasty, Convert) qu’à une redirection configurée côté serveur.
Le SRM est une erreur propre aux tests à redirection. Au lieu de recevoir une répartition conforme au plan, une variante capte plus de trafic que l’autre, souvent parce que des robots de surveillance ou des moteurs indexent une page davantage que l’autre, ou parce que la redirection échoue silencieusement pour certains navigateurs.
Conséquence : les résultats sont viciés même si la significativité statistique est atteinte. Vous concluez sur des données corrompues.
Détection : comparez le nombre de sessions enregistrées sur chaque variante. Un écart notable par rapport à la répartition théorique est un signal d’alerte SRM et doit déclencher une vérification avant toute lecture des conversions.
Correction : excluez les bots du test, vérifiez l’installation du script sur les deux adresses, et assurez-vous que la redirection fonctionne pour tous les agents utilisateurs pertinents. Le SRM se détecte avant l’analyse des conversions, c’est un prérequis de validité, pas un détail de fin de test.
Non, pas nécessairement, et c’est un angle que la plupart des guides sautent complètement. Un test par redirection agrège un résultat global, mais l’audience mobile et celle sur ordinateur ne subissent pas le même délai : sur mobile, le réseau est souvent plus lent et plus variable, donc la latence ajoutée pénalise davantage cette audience-là, sans lien avec la qualité du contenu testé. Un visiteur qui découvre votre marque et un visiteur qui revient peuvent aussi réagir différemment à une refonte radicale : le premier juge la page sur ce qu’il voit, le second compare avec ce qu’il connaissait.
Concrètement : si votre outil le permet, segmentez vos résultats par appareil et par type de visiteur avant de conclure. Une variante qui gagne globalement mais perd sur mobile mérite d’être creusée avant d’être généralisée : l’effet peut n’être qu’un artefact de vitesse, pas une préférence réelle pour le nouveau concept.
Le test par redirection exige plus de trafic et plus de visiteurs qu’un A/B classique pour atteindre la même puissance statistique. Une fraction des visiteurs ne termine pas le chargement ou quitte avant de voir la variante. Ce bruit s’ajoute à la dilution normale d’un test à deux versions et pénalise en premier lieu les pages à faible trafic.
Ordre de grandeur : plus l’écart attendu est faible, plus le test demande de sessions par variante. C’est un budget d’optimisation à prévoir avant de lancer, pas à découvrir en cours de route. Calculez votre taille d’échantillon avant de lancer, en partant de votre taux de conversion réel, de vos données historiques et de l’effet minimum détectable.
En pratique : si votre volume mensuel est faible, ce protocole risque de ne jamais conclure dans un délai raisonnable. Dans ce cas, l’A/B classique, moins de bruit et sans changement d’adresse, est souvent l’option viable.
En Google Ads, la page de destination et la continuité entre l’annonce et la page comptent, pour l’expérience utilisateur comme pour le Quality Score. Une redirection mal configurée peut perturber cette continuité : une annonce qui pointe vers une adresse intermédiaire, des paramètres de suivi perdus pendant le transfert, une cohérence message-annonce rompue sur l’une des variantes.
Cela reste possible, mais à condition de vérifier que les deux destinations offrent une expérience publicitaire équivalente, avec un ciblage et des enchères identiques des deux côtés. Sinon, vous testez autre chose que ce que vous croyez.
La nuance à garder : ce protocole est plus puissant (il teste des refontes qu’aucun autre outil ne peut tester) mais plus fragile.
Quand le changement est incrémental, l’A/B classique est non seulement suffisant mais plus sûr, parce qu’il a moins de biais à neutraliser.
| A/B classique | Redirection | |
|---|---|---|
| Variation | éléments, même URL | deux pages distinctes, redirection |
| Ampleur | incrémentale | radicale |
| Biais | faible | redirection (vitesse, tracking, indexation) |
| Quand l’utiliser | tester un élément | tester un concept entier |
| Ads | setup standard | vérifier continuité annonce/page |
Oui, et c’est l’angle mort du sujet : la plupart des guides s’arrêtent au Quality Score et ignorent l’effet sur les enchères automatiques. Si vos deux URLs sont servies par deux annonces distinctes plutôt que par une redirection transparente pour l’utilisateur, votre stratégie d’enchères intelligentes (Smart Bidding) reçoit des signaux de conversion coupés en deux au lieu d’un flux unique, et l’algorithme réapprend sur un volume divisé par deux, exactement comme lors du lancement d’une expérience de campagne côté enchères.
Concrètement : un compte qui roule sur Maximiser les conversions ou un CPA cible peut voir son apprentissage se recalibrer sur chaque bras du test, avec deux fois moins de données par variante pour la stabiliser. Le risque vient surtout d’enchères devenues instables pendant l’expérience, ce qui ajoute du bruit à la mesure elle-même. La bonne pratique : garder le ciblage, les enchères et le budget strictement identiques sur les deux bras, et ne changer que la page de destination, vous ne pouvez pas optimiser les enchères et la page dans la même expérience sans mélanger les causes. Si vous testez aussi la stratégie d’enchères, séparez les deux tests et évitez de les lancer en même temps sur la même campagne.
Chaque étape ratée devient ici un biais supplémentaire, et un biais non corrigé vous empêche d’optimiser sur des résultats fiables. Voici la séquence à respecter avant d’ouvrir votre outil de test.
Pour les tests de paramètres de campagne côté Google Ads (enchères, ciblage, créatifs) : c’est le territoire des Expériences Google Ads, pas du test par redirection. Les deux outils ne testent pas la même chose : l’un compare des pages, les Expériences comparent des paramètres de campagne.
Cette méthode se résume à deux décisions successives, pas une seule. Ampleur d’abord : mon changement est-il une variation d’éléments sur une page existante (→ A/B classique, plus simple, plus sûr) ou une page radicalement différente, une refonte, deux concepts (→ test par redirection, le seul qui le permette) ?
Vérification ensuite : ai-je neutralisé le biais de redirection, égalisé les vitesses, fiabilisé le suivi sur les deux adresses, géré l’adresse canonique et contrôlé l’expérience publicitaire ?
Le bon outil dépend de ce que vous testez, pas de vos habitudes ni de la plateforme que vous avez sous la main. La comparaison ne dit la vérité sur l’impact réel des deux versions que si vous avez d’abord éliminé, en amont de l’expérimentation, tout ce qui, en dehors du contenu, pourrait faire pencher la balance.
Quel que soit l’outil, le verdict ne tient que sur une base statistique solide : taille d’échantillon et p-value à la hauteur avant d’acter quoi que ce soit.
On choisit l’outil selon l’ampleur.
Réserver un appel