Test A/A avant l'A/B test : vérifier que votre outil de test ne ment pas

Vous lancez un A/B test sur votre landing page, la variante B l'emporte avec 8 % de conversions en plus, et vous généralisez le changement. Raisonnable — sauf si l'outil qui a mesuré ce chiffre a lui-même un biais : trafic mal réparti entre les deux versions, tracking qui rate certains visiteurs sur une branche, cache qui sert la mauvaise variante à une partie des utilisateurs. Dans ce cas, le « gagnant » n'a rien gagné : c'est l'outil qui a menti. Le test A/A sert précisément à vérifier ça, en amont, avant d'engager de vraies décisions sur un vrai A/B test. C'est un contrôle de plomberie, pas une expérience marketing — et c'est justement pour ça qu'il est presque toujours ignoré.

Qu'est-ce qu'un test A/A ?

Un test A/A fonctionne comme un A/B test classique — deux groupes de visiteurs, répartition aléatoire, mesure du taux de conversion — sauf que les deux groupes voient exactement la même page. Aucun changement de contenu, de bouton ni de mise en page. En théorie, les deux groupes doivent donc converger vers le même taux de conversion, aux fluctuations statistiques normales près. Si l'écart mesuré dépasse largement ce que le hasard explique, ou si la taille des deux groupes elle-même est déséquilibrée alors que le partage était censé être 50/50, le problème ne vient pas de la page : il vient de l'instrumentation. C'est la seule façon de distinguer un vrai effet d'un artefact de mesure — voir notre guide de l'A/B test de landing page pour la mécanique d'un test classique.

Le problème qu'il révèle : le sample ratio mismatch

Ce déséquilibre de répartition a un nom dans la littérature sur l'expérimentation en ligne : le sample ratio mismatch (SRM), un écart entre la proportion de trafic attendue par groupe (50/50, par exemple) et celle réellement observée. Une étude de Fabijan, Gupchup, Gupta, Omhover, Qin, Vermeer et Dmitriev, présentée à la conférence KDD en 2019 (« Diagnosing Sample Ratio Mismatch in Online Controlled Experiments »), a analysé les expérimentations menées dans quatre grandes entreprises technologiques et construit une taxonomie des causes de SRM : redirections plus lentes sur une branche qui font perdre des visiteurs en cours de route, filtrage de bots asymétrique entre les deux versions, mise en cache qui sert une page à des utilisateurs assignés à l'autre, ou bug dans le hachage qui assigne chaque visiteur à un groupe. Le point central de l'étude : un SRM, même petit, suffit à invalider complètement le résultat d'un test — pas seulement à le rendre moins précis.

• Redirection ou script de test qui charge plus lentement sur une des deux variantes, perdant des visiteurs impatients avant l'assignation
• Filtrage de robots et de trafic non humain qui n'agit pas identiquement sur les deux branches
• Cache CDN ou navigateur qui sert une ancienne version à une partie des visiteurs supposés voir l'autre
• Bug dans la fonction de hachage ou le cookie d'assignation, qui biaise la répartition pour certains segments (mobile, certains navigateurs, certaines zones géographiques)
• Redirections HTTP supplémentaires sur une variante qui déclenchent un abandon avant même l'arrivée sur la page

Pourquoi c'est vital avant de lancer un vrai A/B test

L'idée n'est pas nouvelle : dès 2009, Crook, Frasca, Kohavi et Longbotham, dans un article resté une référence de la conférence KDD (« Seven Pitfalls to Avoid when Running Controlled Experiments on the Web »), recommandaient déjà de faire tourner régulièrement des tests A/A — qu'ils appellent aussi « tests nuls » — pour exercer le système d'expérimentation lui-même et vérifier qu'il ne produit pas de faux positifs. Leur constat : sans ce contrôle, une équipe peut très bien optimiser sa landing page pendant des mois sur la base de résultats qui ne mesurent rien de réel, simplement parce que l'outil sous-jacent (le script d'A/B testing, l'intégration analytics, le CDN) introduit un biais systématique. Un test A/A ne remplace pas la vigilance méthodologique de chaque expérience, mais il détecte les défauts structurels que rien d'autre ne révèle — parce qu'il élimine la seule variable qu'un A/B test classique ne peut pas isoler : le contenu lui-même.

Quand le faire

Un test A/A n'a pas besoin d'être permanent. Il est surtout utile à trois moments : au changement d'outil d'A/B testing (nouvel outil, nouvelle intégration, migration de plateforme), avant une série de tests à fort enjeu où une décision de plusieurs milliers d'euros de budget publicitaire va reposer sur le résultat, et périodiquement si le volume de trafic le permet, pour s'assurer qu'aucune régression technique (mise à jour du site, nouveau CDN, changement de consentement cookies) n'a introduit un biais silencieux.

Comment lancer un test A/A sur sa landing page

1. Dupliquez votre page actuelle à l'identique dans l'outil de test, sans aucune modification de contenu, de style ni de script
2. Répartissez le trafic 50/50 exactement comme vous le feriez pour un vrai A/B test, avec le même mécanisme d'assignation
3. Laissez tourner jusqu'à atteindre le volume de conversions que vous utiliseriez normalement pour un test réel — voir combien d'utilisateurs il faut pour un test fiable et combien de temps un A/B test doit durer
4. Vérifiez d'abord la taille des deux groupes : un test du χ² (chi carré) simple permet de savoir si l'écart de répartition (par exemple 51 % / 49 % au lieu de 50 % / 50 %) est compatible avec le hasard ou signale un SRM
5. Comparez ensuite les taux de conversion des deux groupes : un écart significatif entre deux pages identiques est la preuve qu'il faut chercher le problème dans l'instrumentation, pas dans le marketing

Si le test A/A révèle un écart : où chercher

Un SRM détecté ne dit pas immédiatement où est le bug, mais il oriente la recherche. Commencez par l'emplacement du script de test dans le <head> — un script chargé trop tard laisse le temps à un visiteur de voir un flash de contenu ou d'abandonner avant assignation, souvent de façon asymétrique entre variantes. Vérifiez ensuite que le cache (CDN, navigateur, extension de blocage de publicité) ne fige pas une variante pour certains segments de visiteurs, que le tracking (GA4, pixel Meta — voir notre guide du tracking GA4) se déclenche identiquement sur les deux branches, et enfin que la bannière de consentement cookies ne bloque pas la mesure différemment selon la variante affichée. Un SRM est presque toujours un problème d'infrastructure, jamais un problème de contenu — c'est justement ce qui le rend difficile à repérer sans un test A/A dédié.

Et si votre trafic ne permet pas un vrai test A/A ?

Sur une landing page à faible trafic, un test A/A formel avec seuil statistique n'est souvent pas réalisable — c'est le même problème de volume que pour n'importe quel A/B test, détaillé dans notre guide de priorisation des tests. Dans ce cas, un contrôle plus léger reste utile avant de lancer une série de tests importants : vérifier manuellement, sur plusieurs navigateurs et appareils, que l'outil affiche bien la même page aux deux groupes, que les événements de conversion se déclenchent des deux côtés dans l'outil analytics, et que l'assignation ne dépend pas d'un paramètre qui varie selon la source de trafic (UTM, appareil, zone géographique). Partir d'une structure de page propre limite déjà une partie de ces risques : les 10 templates LanderKit (89 € l'unité, 229 € le pack complet) sont livrés en Next.js statique, sans dépendance tierce cachée qui pourrait interférer avec un script de test, du SaaS en liste d'attente à la prise de rendez-vous coaching.