Combien de tests A/B vous avez lancés depuis 1 an ? 50 ? 200 ? Si vous n’avez jamais lancé de test A/A entre deux, statistiquement, vous avez déclaré 5-10 % de fausses victoires sans le savoir.
Le test A/A est la procédure de contrôle qualité la plus puissante de l’A/B testing. Et la moins pratiquée.
Qu’est-ce qu’un test A/A ?
Un test A/A est un test A/B où les deux variantes sont identiques. Vous prenez votre page de contrôle, vous la dupliquez, et vous la testez contre elle-même via votre outil d’AB testing.
Logiquement, vous devriez observer :
- Pas de différence significative entre les deux variantes (p > 0,05).
- Une répartition de trafic 50/50 (pas de SRM).
- Des taux de conversion qui convergent vers la même valeur à mesure que l’échantillon grandit.
Si vous observez autre chose, c’est un signal : votre outil ou votre instrumentation a un biais.
Pourquoi 60 % des plateformes échouent en silence
Quand vous lancez un test A/B sur un outil mal calibré, les biais peuvent se déguiser en victoire. Quelques exemples vécus :
Cas 1, Targeting de cookies asymétrique
Outil X attribue les visiteurs en cookies persistants, sauf que sur Safari les cookies ITP expirent à 7 jours. Conséquence : sur un test de 4 semaines, 30 % des visiteurs Safari sont réattribués mi-test et apparaissent dans les deux variantes. SRM massif, mais l’outil ne le signale pas.
Un A/A préalable aurait montré : “Variante A reçoit 53 % du trafic, Variante B 47 %. Ratio attendu 50/50. p-value du χ² sur la répartition = 0,003 → SRM.”
Cas 2, Instrumentation événements asymétrique
Une équipe trackait le clic CTA via un attribut data-variant injecté côté client. Sur la variante B, l’injection arrivait 200 ms après le rendu, certains utilisateurs cliquaient pendant ces 200 ms, leur conversion n’était pas trackée. Résultat : variante B sous-mesurée de 4 %.
Un A/A propre aurait révélé : “Conversion variante A = 3,4 %, conversion variante B = 3,2 %, p = 0,04”. Avec deux variantes pourtant identiques, ça devrait être 3,3 % vs 3,3 %.
Cas 3, Distribution non-uniforme du contrôle
L’outil utilise une fonction de hash sur le user ID pour assigner la variante. Si le hash a un biais (modulo qui sous-représente les power users), la moyenne de variante A peut différer structurellement de celle de variante B.
A/A test révèle : “Conversion A = 2,8 %, conversion B = 3,5 %, p < 0,001. Mais les deux variantes affichent exactement la même page.” → bug d’assignation.
Comment implémenter un A/A propre
Étape 1, Cloner la page de contrôle
Dans votre outil, créez un test avec deux variantes strictement identiques au contrôle. Pas de cosmétique différente. Vraiment identiques au pixel près.
Étape 2, Lancer sur le même volume qu’un test A/B classique
Visez le même sample size que vous calculeriez pour un test A/B avec MDE 5-10 %. Sur un site qui fait 100 K visiteurs/mois, comptez 2-3 semaines pour le A/A.
Étape 3, Mesurer 3 choses
- Distribution du trafic : χ² sur la répartition observée vs attendue (50/50). Si p < 0,05 → SRM.
- Différence de conversion : Z-test sur les deux taux. Si p < 0,05 → biais d’instrumentation.
- Convergence dans le temps : tracer le delta de conversion jour par jour. Doit converger vers 0. S’il diverge ou stagne loin de 0, problème.
Étape 4, Documenter et fixer
Si A/A fail, ne lancez pas de test A/B avant d’avoir identifié et corrigé la cause. Demandez au support de l’outil. Vérifiez votre instrumentation.
Étape 5, Cadence
Pas un A/A unique. Trimestriel : votre stack évolue (nouveaux trackers, mises à jour, etc.), un A/A passé il y a 6 mois ne dit rien sur aujourd’hui.
Sur Statlift
Statlift exécute un A/A automatique à chaque test A/B lancé. Pendant les 5 premiers jours :
- Avant que les variantes A et B ne soient servies, un sous-échantillon (5 % du trafic) reçoit la variante A en double (A vs A).
- Si les deux affichages de A divergent significativement (p < 0,05 ou SRM détecté), l’outil bloque le test principal et alerte l’équipe.
- Si tout est propre, le test A/B se poursuit normalement.
Cette double sécurité a sauvé 3 fausses victoires en 6 mois chez Maison Loriot (cf. étude de cas).
La règle de pouce
Un test A/A par trimestre. Un test A/A à chaque changement de stack (nouveau CMP, nouvelle Tag Manager, nouvelle version GA4). Un test A/A à chaque suspicion de résultat trop beau pour être vrai.
Si votre outil ne supporte pas le A/A automatique, c’est un signal d’alarme : pourquoi pas ? Quelles informations cherche-t-il à vous cacher ?
En résumé
Le test A/A est l’outil de validation le plus efficace de l’A/B testing :
| Bénéfice | Détail |
|---|---|
| Détecte les biais d’instrumentation | Tracking asymétrique, événements ratés |
| Détecte les SRM | Cookies expirés, hash biaisé, targeting cassé |
| Calibre l’outil | Valide que la plateforme calcule correctement |
| Forme l’équipe | Voir 0 différence sur 2 semaines casse l’illusion du “tout est significatif” |
À combien de tests A/A vous avez-vous droit dans votre outil actuel ? Si la réponse est “aucun”, c’est par là qu’il faut commencer.
Pour approfondir : Peeking, sequential testing et SRM, détail sur la détection automatique du SRM.
