Ce choix se pose avant toute démarche de CRO avancé et d'analyse comportementale : une attribution instable ou une mesure différente entre les variantes invalide le verdict, quel que soit le logiciel utilisé.
Choisir selon l’hypothèse et l’architecture
La première question n’est pas « petit ou grand changement ? », mais « quel effet voulons-nous attribuer ? ». Une expérience A/B peut comparer un seul titre, plusieurs changements regroupés en un concept ou deux refontes complètes. Plus la variante combine de modifications, plus le verdict porte sur le concept entier : vous saurez quelle expérience gagne, pas quel élément l’explique.
La seconde question concerne la diffusion. Un script côté navigateur remplace le contenu après le chargement ; il est simple à déployer, mais peut produire une latence ou un scintillement si le chargement est tardif. Une diffusion côté serveur ou en périphérie du réseau sert directement la bonne variante sur la même adresse. Deux adresses séparées facilitent parfois des architectures ou tunnels très différents, sans être l’unique moyen de tester une refonte.
Dans votre protocole d'expérimentation et d'analyse, tranchez selon quatre contraintes : capacité technique à servir les variantes, persistance de l’assignation, cohérence de mesure et risque SEO. L’ampleur du changement vient ensuite. Choisissez l’architecture qui isole votre hypothèse, maintient une expérience technique comparable, attribue chaque unité à une seule variante et applique une règle de comptage stable. Une redirection peut ajouter de la latence ; un script côté navigateur peut, lui aussi, ralentir ou faire scintiller la page.
Même adresse
- Diffusion côté navigateur, serveur ou réseau
- Adresse et attribution généralement plus simples
- Refonte possible si l’architecture le permet
- Risque de scintillement côté navigateur à mesurer
Adresses séparées
- Utile pour des pages ou tunnels indépendants
- Routage ou redirection à documenter
- Mesure et paramètres à vérifier des deux côtés
- Consignes d’indexation temporaires à appliquer
A/B ou test multivarié : deux questions différentes
Un A/B compare des variantes globales. La variante B peut ne modifier qu’un élément ou réunir plusieurs changements cohérents. Un test multivarié fait varier plusieurs facteurs et leurs combinaisons afin d’estimer leurs effets propres et leurs interactions : par exemple, savoir si un titre fonctionne différemment selon l’image associée.
Le test multivarié crée davantage de cellules expérimentales. À effet minimal, taux de base, risque d’erreur et puissance identiques, il répartit donc les observations entre davantage de combinaisons. Il peut rester faisable avec un plan réduit ou un trafic important. À faible volume, sa durée augmente et expose davantage le résultat aux évolutions de saison, de campagne ou d’audience ; ce n’est pas une impossibilité mathématique absolue, mais souvent un mauvais compromis opérationnel.
| Critère | A/B | Adresses séparées | Test multivarié |
|---|---|---|---|
| Question estimée | Effet global d’une variante face à l’autre | Même effet global, avec une architecture distincte | Effets de plusieurs facteurs et de leurs interactions |
| Diffusion | Navigateur, serveur ou réseau | Routage ou redirection temporaire | Navigateur ou serveur selon l’outil |
| Besoin d’échantillon | Calculé selon le taux de base et l’effet minimal | Même calcul, ajusté si une perte technique est mesurée | Souvent supérieur car les observations se répartissent entre plusieurs cellules |
| Risques à contrôler | Assignation, scintillement, mesure, arrêt anticipé | Assignation, latence, mesure, indexation | Puissance, multiplicité, dérive temporelle |
| Cas pertinent | Comparer deux expériences, simples ou complètes | Pages ou tunnels techniquement indépendants | Identifier quels facteurs se renforcent ou se neutralisent |
Les catégories peuvent se chevaucher : une expérience A/B peut utiliser deux adresses, et un test multivarié peut être servi côté serveur. Ne laissez pas le nom commercial de l’outil décider à la place du protocole.
Les biais techniques à contrôler dans toutes les architectures
Une redirection n’est pas neutre, mais elle n’est pas le seul risque. Comparez l’expérience réellement reçue après l’assignation : délai, stabilité visuelle, erreurs, conservation de l’identifiant expérimental et déclenchement des événements. Cette vérification doit couvrir les deux variantes, les appareils principaux et les navigateurs significatifs.
Vitesse, mesure et indexation
Vitesse. Une redirection ajoute un aller-retour lorsqu’elle est effectivement utilisée. Un script côté navigateur peut attendre son chargement, afficher brièvement la version témoin puis la remplacer. Un routage serveur bien conçu peut éviter ces deux phénomènes. Mesurez donc la chaîne réelle et la performance de chaque page de destination, au lieu d’attribuer une pénalité fixe à une catégorie de test.
Mesure. Les variantes doivent partager la même définition de conversion, le même consentement, les mêmes règles de déduplication et la même fenêtre d’observation. Vérifiez la conservation des identifiants publicitaires et des paramètres de campagne. Leur perte dégrade l’attribution ; elle ne fait pas baisser directement le niveau de qualité Google Ads.
Indexation. Des adresses de variante accessibles aux moteurs demandent un traitement temporaire cohérent. Ce risque SEO s’ajoute aux effets d’histoire et de saisonnalité qui peuvent toucher toute expérience prolongée.
Règles SEO pour une variante sur une adresse séparée
Si le test redirige une partie des utilisateurs depuis l’adresse d’origine, Google Search recommande une redirection temporaire 302 plutôt qu’une redirection permanente 301. Le signal indique le caractère provisoire du routage ; il ne garantit pas à lui seul le comportement de l’index.
Google recommande aussi de déclarer l’adresse d’origine comme adresse canonique sur les variantes proches. La balise canonique est un signal, pas une interdiction d’indexer ni une protection absolue. Ne présentez pas une version aux robots et une autre aux humains, ne bloquez pas artificiellement le test pour masquer ce décalage, et retirez variantes, scripts et redirections dès que la durée nécessaire est atteinte.
Déséquilibre du ratio d’échantillon : le détecter correctement
Le déséquilibre du ratio d’échantillon, souvent abrégé SRM en anglais, peut toucher une redirection, un script côté navigateur, un routeur serveur ou une expérience de campagne. Il apparaît lorsque les unités assignées ne suivent pas la proportion prévue au-delà de ce que le hasard explique.
Comptez l’unité réellement randomisée : utilisateurs si l’assignation est persistante par utilisateur, appareils ou sessions si le protocole repose sur eux. Un simple écart entre nombres de sessions ne suffit pas quand une personne peut revenir plusieurs fois. Testez l’écart avec un test d’adéquation, selon un seuil fixé avant de regarder les résultats.
En cas d’alerte, examinez l’ordre d’activation, les erreurs, le consentement, les exclusions, les robots, la persistance et les pertes de mesure. N’enlevez pas après coup des observations uniquement pour remettre le ratio à 50/50 : vous fabriqueriez un échantillon conforme en apparence sans réparer l’assignation.
Sous-groupes : prévoir les interactions avant le test
Un effet peut différer entre mobile et ordinateur, ou entre nouveaux visiteurs et visiteurs connus. Cette possibilité ne justifie pas de découper les données après coup jusqu’à trouver un gagnant. Chaque comparaison supplémentaire augmente le risque de faux positif.
Préspécifiez les sous-groupes qui répondent à une hypothèse métier, vérifiez que leur volume permet une lecture et testez l’interaction entre variante et sous-groupe. Corrigez les comparaisons multiples lorsque plusieurs segments sont examinés. Une différence significative dans un segment et non dans l’autre ne prouve pas, à elle seule, que leurs effets diffèrent.
Calculer le trafic nécessaire sans coefficient arbitraire
À deux variantes, une adresse séparée n’exige pas intrinsèquement plus de trafic. La taille dépend du taux de conversion de référence, de l’effet minimal utile, du risque de faux positif, de la puissance recherchée et de l’allocation. Ajoutez une marge seulement si le contrôle technique mesure une attrition ou une donnée inexploitable.
Calculez la taille d’échantillon avant le lancement, puis traduisez-la en durée avec le nombre d’unités éligibles, pas le trafic brut du site. Prévoyez des cycles commerciaux complets et une règle d’arrêt. Si la durée attendue expose le test à un changement de saison ou de campagne, augmentez l’effet minimal recherché, simplifiez l’hypothèse ou renoncez ; changer d’adresse ne crée pas de puissance.
Google Ads : préserver la continuité sans confondre les métriques
Les deux variantes doivent respecter la promesse de l’annonce et les règles d’adresse finale. Une redirection défectueuse peut perdre le GCLID ou les paramètres UTM et priver l’analyse de sa source. Ce défaut touche l’attribution. L’expérience sur la page de destination, composante du niveau de qualité, concerne la pertinence et l’utilité de l’expérience reçue ; elle ne dépend pas directement de la présence d’un paramètre UTM.
Si le visiteur est randomisé après le clic au sein de la même campagne, conservez annonces, ciblage, budget et stratégie d’enchères stables pendant le test. Si vous utilisez une Expérience Google Ads pour comparer des adresses finales, le groupe témoin et le groupe test doivent différer uniquement par la variable étudiée. Dans les deux cas, documentez le domaine, les redirections, la mesure des conversions et l’unité d’assignation.
Une adresse différente perturbe-t-elle les enchères intelligentes ?
Pas automatiquement. Deux adresses finales dans une même campagne ne créent pas deux modèles d’enchères et ne divisent pas mécaniquement l’apprentissage par deux. La stratégie optimise à partir de l’architecture de campagne, des objectifs de conversion configurés et des données disponibles.
Une Expérience Google Ads, en revanche, répartit l’éligibilité et le budget entre un groupe témoin et un groupe test. Cette architecture peut demander une phase de stabilisation, mais elle vient de la séparation expérimentale, pas du nombre d’adresses. Ne modifiez pas simultanément page, stratégie d’enchères et objectifs de conversion : vous ne sauriez plus attribuer l’écart.
Protocole de lancement d’un test par URL séparée
- Écrire l’hypothèse. Définissez la métrique principale, l’effet minimal utile et les garde-fous commerciaux.
- Choisir l’unité d’assignation. Précisez si la variante persiste pour l’utilisateur, l’appareil ou la session, puis fixez le ratio.
- Dimensionner l’expérience. Calculez l’échantillon et la durée avec taux de base, puissance, seuil d’erreur, allocation et attrition mesurée.
- Configurer la diffusion. Utilisez le routage adapté ; si l’adresse d’origine redirige vers une variante, employez un statut temporaire.
- Fiabiliser la mesure. Testez consentement, identifiants, déduplication, événements, GCLID, paramètres de campagne et persistance.
- Préparer le SEO. Adresse canonique vers l’original, aucune variante réservée aux moteurs et durée limitée.
- Contrôler avant lecture. Vérifiez performance, erreurs, ratio d’échantillon et intégrité des données avant toute comparaison de conversion.
- Une expérience A/B peut porter sur un élément ou sur un concept complet.
- Une refonte n’impose ni deux adresses ni une redirection HTTP.
- Le déséquilibre d’échantillon concerne toute méthode d’assignation et se teste statistiquement.
- Une perte de paramètres nuit à l’attribution, pas directement au niveau de qualité.
Décider sans réduire le verdict à une valeur p
Décidez d’abord de l’architecture la moins risquée qui permet de servir fidèlement les deux variantes. Décidez ensuite du plan d’analyse : hypothèse, taux de base, effet minimal, puissance, durée, cycles complets, règle d’arrêt, sous-groupes prévus et garde-fous.
La valeur p mesure la compatibilité des données avec une hypothèse nulle dans un modèle donné. Elle ne donne ni la probabilité que la variante soit meilleure ni l’importance économique de l’effet. Lisez aussi l’estimation, son intervalle de confiance, les conversions utiles et les éventuels dommages sur les garde-fous.
Un résultat statistiquement détectable mais trop faible pour rembourser le coût de déploiement ne mérite pas forcément d’être généralisé. À l’inverse, un intervalle encore large appelle plus de données ou une décision prudente, pas une victoire déclarée au premier passage sous un seuil.
Le protocole doit donc fixer avant le lancement ce qui comptera comme un effet utile, pas seulement comme un écart détectable.
Sources officielles consultées le 26 juillet 2026 : bonnes pratiques Google Search pour les tests de site, redirections temporaires et permanentes, types d’expériences Google Ads et écarts de mesure liés aux redirections.
