A/B Testing
- produit
- méthodologie
- data
"Je pense que le bouton vert convertira mieux." "Non, le bleu est plus professionnel." "Mettons du orange, c'est plus visible." Ce débat, vous l'avez eu. Et la réponse honnête est : personne ne sait. Ni le designer, ni le PM, ni le CTO. L'A/B Testing existe pour remplacer les opinions par des données.
Le principe : une expérience contrôlée
Un A/B Test est une expérience scientifique appliquée au produit. On prend deux versions d'un élément (A et B), on divise le trafic en deux groupes aléatoires, et on mesure laquelle performe le mieux sur une métrique définie à l'avance.
Trafic total : 10 000 visiteurs/jour
│
├── 50% → Version A (bouton "S'inscrire" vert)
│ → Taux de conversion : 3.2%
│
└── 50% → Version B (bouton "Créer mon compte" orange)
→ Taux de conversion : 4.1%
Résultat : Version B → +28% de conversions
C'est la version la plus simple. En réalité, un bon A/B Test suit un processus rigoureux.
Le processus en 5 étapes
1. Formuler une hypothèse
Pas de test sans hypothèse. "Testons un nouveau bouton" n'est pas une hypothèse. Une hypothèse est spécifique et mesurable :
"En changeant le texte du CTA de 'S'inscrire' à 'Créer mon compte gratuit' et sa couleur de vert à orange, nous pensons augmenter le taux d'inscription de 15% car le texte est plus explicite sur la gratuité et la couleur attire davantage l'attention."
L'hypothèse définit : le changement, la métrique, l'effet attendu, et le raisonnement.
2. Définir les métriques
Métrique primaire — celle qui détermine le gagnant. Une seule. Exemples : taux de conversion, taux de clic (CTR), revenu par utilisateur, taux de rétention à J7.
Métriques de garde — celles qui ne doivent pas se dégrader. Si le nouveau bouton augmente les inscriptions mais fait chuter la rétention, c'est un faux positif.
3. Calculer la taille d'échantillon
C'est l'étape la plus négligée — et la plus importante. Pour détecter un effet de +15% sur un taux de conversion de 3%, avec un niveau de confiance de 95%, il faut environ 7 000 visiteurs par variante. Si vous n'avez que 500 visiteurs par jour, votre test devra durer au minimum 28 jours.
Lancer un test trop tôt ou l'arrêter trop tôt, c'est tirer à pile ou face en pensant faire de la science.
4. Exécuter le test
Diviser le trafic de manière aléatoire et uniforme. Un utilisateur assigné à la variante A doit voir la variante A à chaque visite (pas de basculement aléatoire entre les visites). C'est le sticky assignment, généralement basé sur un cookie ou un identifiant utilisateur.
5. Analyser les résultats
Attendre que la taille d'échantillon soit atteinte. Vérifier la significativité statistique — la probabilité que la différence observée ne soit pas due au hasard. Le standard est un seuil de 95% (p-value < 0.05).
| Métrique | Variante A | Variante B | Différence | Significatif ? |
|---|---|---|---|---|
| Taux de conversion | 3.2% | 4.1% | +28% | Oui (p=0.003) |
| Revenu/utilisateur | 2.40€ | 2.35€ | -2% | Non (p=0.42) |
| Taux de rebond | 45% | 43% | -4% | Non (p=0.18) |
La variante B convertit significativement mieux, sans dégrader les autres métriques. On peut la déployer.
Les outils
| Outil | Type | Notes |
|---|---|---|
| LaunchDarkly | Feature flags + A/B | Intégration code, ciblage avancé |
| PostHog | Analytics + A/B | Open-source, self-hosted possible |
| Optimizely | Plateforme dédiée | Référence enterprise, UI puissante |
| VWO | Plateforme dédiée | Bon éditeur visuel, pas besoin de dev |
| Statsig | Feature flags + A/B | Gratuit jusqu'à un volume élevé |
| AB Tasty | Plateforme dédiée | Acteur français, adapté au marché EU |
Pour les équipes techniques, une implémentation maison avec des feature flags et un outil d'analytics (Mixpanel, Amplitude, PostHog) peut suffire pour démarrer.
Les erreurs classiques
Arrêter le test dès qu'un résultat "semble bon". Vous regardez après 2 jours, la variante B est à +40%. Vous arrêtez le test et déployez. Erreur : avec un petit échantillon, les résultats fluctuent énormément. Ce que vous avez vu était probablement du bruit statistique.
Tester trop de choses à la fois. Changer le texte, la couleur, la taille et la position du bouton en même temps, c'est un test multivarié, pas un A/B Test. Si ça marche, vous ne savez pas pourquoi. Testez une variable à la fois.
Pas d'hypothèse. "On va tester pour voir" produit des résultats difficiles à interpréter et des actions difficiles à prioriser. L'hypothèse guide le test et aide à en tirer des apprentissages.
Ignorer les effets de nouveauté. Un changement radical attire l'attention à court terme. La variante B peut surperformer pendant deux semaines, puis revenir au niveau de A une fois la nouveauté passée. Laissez le test tourner assez longtemps.
Tester des choses insignifiantes. Changer la nuance de bleu d'un bouton ne changera pas votre business. Concentrez vos tests sur les décisions à fort impact : proposition de valeur, structure de pricing, flow d'onboarding, parcours de conversion.
Quand ne PAS faire d'A/B Test
L'A/B Testing n'est pas toujours la bonne approche :
- Pas assez de trafic — si vous avez 100 visiteurs par jour, un test prendra des mois. Utilisez plutôt des tests utilisateurs qualitatifs.
- Décision évidente — un bug UX flagrant n'a pas besoin d'un A/B Test pour être corrigé.
- Changement structurel — une refonte complète du produit ne se teste pas en A/B. Utilisez un beta test avec un groupe restreint.
- Coût d'implémentation trop élevé — si créer la variante B demande deux sprints, assurez-vous que l'enjeu justifie l'investissement.
L'A/B Testing transforme les débats d'opinion en décisions factuelles. Mais c'est un outil statistique, pas de la magie. Il demande de la rigueur : une hypothèse claire, un échantillon suffisant, une métrique définie à l'avance, et la patience d'attendre le résultat. Bien exécuté, c'est l'un des leviers les plus puissants pour améliorer un produit. Mal exécuté, c'est du hasard déguisé en data.