La première fois que j'ai lancé un A/B test, j'ai attendu quatre jours, vu la version B gagner de 18 %, et déployé. Trois semaines plus tard, le taux de conversion était revenu exactement à son niveau de départ. J'avais testé du bruit. Personne ne m'avait expliqué que sur mon volume de trafic, il me fallait six semaines pour distinguer un vrai effet d'une fluctuation aléatoire.
Voilà le problème avec l'A/B test : tout le monde connaît la théorie (deux versions, un seul critère qui change, on garde la meilleure), et presque personne ne parle de la partie qui compte vraiment — la statistique et la discipline. C'est cette partie-là que je vais vous raconter, avec les erreurs que j'ai commises et celles que je vois encore partout.
Points clés à retenir
- Un A/B test compare deux variantes d'une même page ou interface en ne modifiant qu'un seul élément à la fois.
- Sans calcul de taille d'échantillon en amont, vous mesurez du hasard, pas un effet réel.
- Arrêter un test dès qu'il « gagne » est la faute la plus répandue, et la plus coûteuse.
- Le RGPD s'applique : un test qui modifie l'expérience utilisateur repose souvent sur des traceurs qu'il faut déclarer.
- Tester une refonte complète ne sert à rien : vous saurez qu'elle gagne ou perd, jamais pourquoi.
L'A/B test, définition honnête : ce que ça mesure vraiment
Un A/B test est une expérience contrôlée. Vous prenez deux versions d'un même élément — une page, un bouton, un objet d'email — qui ne diffèrent que par une seule variable. Vous répartissez aléatoirement votre trafic entre les deux, puis vous comparez les indicateurs qui vous intéressent : taux de conversion, taux d'inscription, clics sur un bouton.
Jusque-là, rien de compliqué. La subtilité arrive avec le mot « aléatoirement ».
Pourquoi la répartition aléatoire change tout
Si vous envoyez les visiteurs du matin sur A et ceux de l'après-midi sur B, vous ne testez pas votre page. Vous testez l'heure de la journée. Le hasard protège contre ces biais invisibles : la source de trafic, l'appareil, le jour de la semaine, la géographie. Un vrai tirage aléatoire répartit ces facteurs de façon à peu près équilibrée entre les deux groupes — ce qui vous permet d'attribuer la différence observée à votre modification, et à elle seule.
Le problème ? « À peu près » n'est pas « parfaitement ». Sur un petit volume, le hasard peut très bien envoyer 60 % des utilisateurs mobiles dans le groupe B, et vous comparerez alors deux populations qui n'ont rien à voir. C'est exactement ce qui m'est arrivé sur mon premier test : aucun contrôle de la répartition par appareil. Le gain venait d'un afflux de trafic desktop ce week-end-là.
Ce qu'un A/B test ne mesure pas
Il ne vous dit pas pourquoi la version B gagne. Il vous dit qu'elle gagne. Nuance énorme, et c'est ce qui rend les tests frustrants quand on cherche à comprendre ses utilisateurs plutôt qu'à grappiller des dixièmes de pourcentage. Si vous voulez la raison, il faut croiser avec des entretiens, des enregistrements de sessions, des tests utilisateurs. Le chiffre tranche, il n'explique pas.
La partie que tout le monde saute : la méthodologie statistique
Combien de visiteurs faut-il ? Question banale, réponse rare. La plupart des articles sur l'A/B testing vous expliquent comment créer deux variantes dans un outil et s'arrêtent là. Or c'est le calcul de taille d'échantillon qui décide si votre résultat vaut quelque chose ou non.
Puissance statistique et significativité, sans jargon
Trois paramètres déterminent la durée de votre test :
- Le taux de base — votre conversion actuelle, disons 3 %.
- L'effet minimum détectable — le gain en dessous duquel vous ne voulez même pas le savoir. Si vous cherchez du 10 % de mieux relatif, il faut beaucoup plus de trafic que pour détecter du 50 %.
- La puissance — la probabilité de détecter un effet s'il existe vraiment. Le seuil usuel est de 80 %.
Concrètement, sur un site à 3 % de conversion qui veut détecter un gain relatif de 10 %, il faut de l'ordre de plusieurs dizaines de milliers de visiteurs par variante. Sur mon projet à 1 200 visiteurs par jour, cela représentait deux mois. Deux mois pendant lesquels je ne pouvais rien changer d'autre sur la page, sous peine de fausser le test.
Le p-value (seuil de significativité) à 0,05 signifie qu'il reste 5 % de chance d'observer une différence alors qu'il n'y en a aucune. Un test sur vingt, statistiquement, vous mentira. C'est pour cette raison qu'un résultat « à 94 % de confiance » ne veut pas dire « prouvé ».
Combien de temps faire tourner un test ?
Au minimum un cycle hebdomadaire complet, pour absorber la différence de comportement entre semaine et week-end. Idéalement deux. Et jamais moins de sept jours, même si les chiffres semblent déjà stables au bout de trois — ils ne le sont pas.
Cette règle m'a coûté un client. Il voulait absolument publier le résultat pour une présentation interne, deux jours après le lancement. J'ai cédé. Le chiffre annoncé était flatteur. Le mois suivant, la métrique réelle n'avait pas bougé d'un poil. Deux jours de test, zéro information.
Les erreurs qui tuent vos tests (je les ai toutes faites)
Une liste concrète vaut mieux qu'un discours sur la rigueur. Voici celles que je retrouve systématiquement quand on me demande de relire un rapport d'expérimentation.
Arrêter le test dès qu'il « gagne »
C'est le peeking : regarder les résultats tous les jours et couper dès que la variante passe devant. Problème mathématique simple : plus vous regardez souvent, plus vous avez de chances de tomber sur un pic aléatoire favorable. Sur un test surveillé quotidiennement pendant trois semaines, la probabilité de voir au moins une fois un faux positif dépasse allègrement ce que vous croyez. Vous ne mesurez plus l'effet, vous cueillez la meilleure journée.
Tester trop de variables à la fois
Un bouton rouge et un nouveau titre et une photo différente : si ça convertit mieux, vous ne saurez jamais laquelle des trois a fait le travail. J'ai fait cette erreur sur une landing page entière refaite en une seule variante. Le résultat : +22 % de conversion, et aucune idée de la cause. Impossible de reproduire le gain ailleurs.
La discipline est ingrate : une variable, un test. Mais c'est la seule façon d'apprendre quelque chose de transférable.
Un échantillon biaisé sans le savoir
Trois pièges classiques :
- Un cookie de test qui ne persiste pas — l'utilisateur change de variante en cours de route et fausse les deux groupes.
- Un outil mal configuré qui exclut les visiteurs sans JavaScript, souvent les plus prudents.
- Un test lancé pendant une campagne publicitaire qui n'envoie qu'un type de trafic sur une seule variante.
Sur le troisième point : j'ai vu un test « gagnant » qui, en réalité, comparait du trafic payant à du trafic organique. Les deux populations ne se comportent pas du tout pareil. Résultat : rien.
A/B test et RGPD : l'angle que personne ne traite
En France, un test qui modifie l'expérience d'un utilisateur repose presque toujours sur un traceur. Consentement, base légale, information : ce n'est pas de la paperasse optionnelle.
Ce que vous devez vérifier concrètement
La CNIL encadre les cookies et traceurs : en règle générale, leur dépôt nécessite le consentement préalable de l'utilisateur, sauf exceptions limitées (certains traceurs strictement nécessaires, ou de mesure d'audience sous conditions). Un cookie qui décide quelle version de page afficher n'entre pas dans ces exceptions.
En pratique, cela impose :
- Déclarer le traceur de test dans votre politique de cookies.
- Recueillir le consentement avant de lui attribuer une variante — ou basculer tout le monde sur la version par défaut en cas de refus.
- Limiter la durée de vie du cookie.
- Documenter la finalité : amélioration de l'expérience, pas profilage publicitaire.
Côté médical, le sigle AB test désigne tout autre chose : le test d'ABO et de Rhésus, notamment pendant la grossesse, pour prévenir les incompatibilités sanguines. Aucun rapport avec le web, mais si vous tombez sur le terme dans un contexte santé, ne cherchez pas de bouton.
Quel outil choisir pour faire de l'A/B testing ?
Trois familles d'outils, trois usages. J'ai travaillé avec les trois, et franchement, le choix dépend plus de votre volume de trafic que de la longueur de la liste de fonctionnalités.
| Type d'outil | Pour qui | Point fort | Limite |
|---|---|---|---|
| Plateforme dédiée (type AB Tasty) | Sites à trafic conséquent, équipe marketing | Éditeur visuel, gestion des tests sans développeur | Coût, dépendance à l'outil |
| Intégré au CMS ou à la régie (YouTube, plateformes d'ads) | Créateurs de contenu, publicitaires | Test de miniatures et de titres natif, sans code | Périmètre limité à l'écosystème de la plateforme |
| Librairie maison ou solution open source | Équipes techniques | Contrôle total, pas de coût de licence | Il faut construire le calcul statistique soi-même |
Un mot sur Google Optimize : l'outil a été arrêté, il n'est plus disponible. Si vous cherchez encore un tutoriel dessus, vous perdez votre temps. Les alternatives existent, mais vérifiez toujours qu'elles savent calculer une taille d'échantillon et gérer la persistance du cookie — deux fonctions que beaucoup d'outils « simples » escamotent.
Comment fonctionne l'A/B test sur YouTube ?
YouTube permet de tester plusieurs miniatures pour une même vidéo : la plateforme les montre à des échantillons de spectateurs, puis retient celle qui génère le meilleur taux de clic. Le test est automatique et ne vous demande aucune compétence statistique. Mais — et c'est là que ça devient intéressant — les résultats ne sont pas toujours reproductibles d'une vidéo à l'autre. Une miniature qui gagne sur un sujet peut perdre sur un autre. Traitez chaque résultat comme une observation locale, pas comme une règle générale.
Ce que j'ai fini par retenir
L'A/B test n'est pas un bouton magique qui optimise votre site. C'est un instrument de mesure, et comme tout instrument, il a une précision, une portée, et des conditions d'utilisation. Utilisé sans calcul d'échantillon, sans durée minimale, sans discipline sur les variables, il produit des certitudes fausses — et des certitudes fausses coûtent plus cher que des doutes honnêtes.
Ce que je fais maintenant, systématiquement, avant de lancer quoi que ce soit : j'écris sur papier l'effet minimum que je cherche, je calcule le volume nécessaire, je vérifie si mon trafic le permet. Si la réponse est non, je ne lance pas de test. Je fais des entretiens utilisateurs à la place.
La question qui reste, et que je n'ai pas résolue : dans une entreprise où l'on demande des résultats chaque semaine, comment défendre un test qui doit tourner deux mois pour valoir quelque chose ? Si vous avez la réponse, je prends.
