Comment lancer un A/B test : de l'hypothèse à la décision

L’A/B testing intimide souvent parce qu’on associe le sujet à la statistique. Mais en pratique, lancer un test utile, c’est d’abord un travail de méthodo et d’outils — la partie stats arrive seulement à l’analyse. Cet article couvre les sept étapes concrètes pour passer d’une intuition (“on devrait peut-être changer le CTA”) à un test exploitable, jusqu’à la décision finale.

Pour la partie “comment interpréter les résultats” (taille d’échantillon, durée, peeking), c’est traité dans l’article complémentaire sur la méthodologie A/B testing.

Le pipeline complet

Étape 1 — Formuler une hypothèse testable

C’est l’étape la plus souvent ratée. Une bonne hypothèse n’est pas “on va tester un bouton vert” mais une affirmation falsifiable qui dit ce qu’on attend et pourquoi.

Le format d’une hypothèse utile

Si on change [élément X], alors [métrique Y] va [augmenter / diminuer] de [Z %], parce que [raison comportementale].

Exemple :

Si on remplace le CTA “Acheter” par “Ajouter au panier” sur la page produit, alors le taux de clic sur le CTA va augmenter de 15 %, parce que “Ajouter au panier” est moins engageant et lève la friction de la décision d’achat immédiate.

Cette formulation force à clarifier :

• L’élément modifié (single change)
• La métrique mesurée
• L’effet attendu (sens et amplitude)
• La logique comportementale derrière

Sans hypothèse, on lance des tests “au cas où” et on ne tire aucun apprentissage des résultats. Avec, même un test perdant produit un apprentissage.

Étape 2 — Identifier la métrique principale (et les garde-fous)

Une seule métrique principale par test. C’est celle qui décide du gagnant.

Choisir la bonne métrique

• Pas trop éloignée du changement : tester le CTA d’une page produit avec comme métrique le revenu mensuel global = trop de bruit, trop indirect
• Pas trop proche : tester un CTA en mesurant uniquement le clic = on peut “gagner” le clic mais perdre la conversion finale
• Le bon équilibre : la métrique qui exprime l’objectif business du changement

Sur l’exemple CTA “Acheter” vs “Ajouter au panier”, la métrique principale serait le taux d’ajout au panier, pas le taux d’achat final (trop distant et influencé par trop d’autres facteurs).

Métriques garde-fous

À surveiller en parallèle pour détecter les régressions cachées :

• Bounce rate : si la variante gagne en clics mais fait monter le bounce, c’est suspect
• Revenu par session : la métrique anti-cannibalisation
• Taux d’abandon panier : si le clic au panier monte mais l’abandon aussi, gain illusoire

Étape 3 — Concevoir les variantes (une seule variable à la fois)

Une règle simple : ne changer qu’une seule chose entre A et B. Sinon, impossible de savoir d’où vient l’effet observé.

Mauvais design :

• A = bouton bleu “Acheter”
• B = bouton vert “Ajouter au panier” + nouvelle police + nouveau wording sous le bouton

Bon design (test 1) :

• A = bouton bleu “Acheter”
• B = bouton bleu “Ajouter au panier”

Puis test 2 (séquentiel ou multi-bras) sur la couleur. Tester plusieurs variables à la fois est possible (tests multivariés), mais ça demande beaucoup plus de trafic et complique l’analyse — à réserver aux setups matures.

Pour les changements visuels lourds

Si le changement teste une refonte complète (nouvelle page produit, nouveau funnel checkout), on accepte que ce ne soit plus un “vrai” A/B test au sens scientifique — c’est un test produit, dont les apprentissages seront plus directionnels que causaux. À documenter comme tel.

Étape 4 — Choisir l’outil

Le choix dépend du volume du site, du niveau d’autonomie souhaité côté équipe, et du budget. Tour d’horizon :

Outil	Pour qui	Forces	Limites
AB Tasty	Mid-market FR, e-commerce	Éditeur visuel, support FR, gestion des audiences fine	Tarif élevé (à partir de ~1k€ / mois)
Optimizely	Grands comptes	Stats Engine bayésien intégré, intégrations DAM, expérimentation server-side	Très cher, courbe d’apprentissage
VWO	PME et mid-market	Bon rapport qualité-prix, heatmaps incluses	Moins puissant qu’Optimizely sur les segments avancés
Convert	PME tech-friendly	Tarif raisonnable, code propre, support développeur	Moins d’UX no-code pour le marketing
GTM + dataLayer custom	Débrouille technique	Gratuit, contrôle total, intégration native GA4	Calcul stats à faire à la main, pas d’UI éditeur, risque d’erreur
Google Optimize	(fermé en 2023)	—	N’est plus disponible

Pour un site qui démarre l’A/B testing, VWO ou Convert sont souvent le bon compromis. Pour les setups avec déjà une équipe data et un volume conséquent, AB Tasty (FR) ou Optimizely apportent les fonctionnalités avancées qui justifient le coût. Pour les setups très contraints, le bricolage GTM + GA4 est faisable mais demande de la rigueur sur le calcul de significativité (cf. l’article méthodologie A/B testing).

Étape 5 — Configurer le test proprement

Une fois l’outil choisi, six points à régler avec attention :

Audience cible

À quels visiteurs le test s’applique ? Tous ? Uniquement mobile ? Uniquement les nouveaux visiteurs ? Uniquement les visiteurs Google Ads ? Plus l’audience est précise, plus les résultats sont actionnables — mais plus il faut de temps pour atteindre le volume nécessaire.

Allocation du trafic

50/50 par défaut. Certains setups testent à 90/10 (90 % sur le contrôle) pour minimiser le risque sur une variante non testée. C’est plus prudent mais ralentit la collecte.

Pages de déclenchement

Sur quelles URLs le test se déclenche ? Précis : une seule URL ? Plus large : tout le tunnel ? Plus l’audience pages est petite, plus le test est ciblé.

Exclusions

Souvent oubliées :

• IPs internes (équipe, agence partenaire)
• Bots et crawlers (filtre user-agent ou liste noire)
• Visiteurs en debug mode
• Audiences QA lors des tests internes

QA initiale

Avant de pousser en live, tester chaque variante manuellement sur tous les browsers principaux + mobile. Vérifier :

• La variante s’affiche bien
• Les événements de tracking partent dans GA4 / l’outil
• Aucun message d’erreur en console
• La performance n’est pas dégradée (CWV)

10 minutes de QA évitent une semaine de test invalide.

Durée et taille d’échantillon

À calculer avant de lancer via Evan Miller’s calculator. Minimum deux cycles hebdomadaires (14 jours). Détail complet dans l’article méthodologie A/B testing.

Étape 6 — Lancer, surveiller (sans peeker), conclure

Pendant la durée du test :

• J0 → J2 : QA quotidienne pour confirmer que tout tourne (volume conforme, pas de bug visible)
• J3 → fin : ne pas regarder les résultats pour décider. On laisse le test atteindre la taille d’échantillon prévue.

À la fin :

• Comparer la métrique principale entre A et B
• Vérifier les métriques garde-fous
• Calculer la significativité (l’outil le fait automatiquement, ou via calculateur si setup GTM custom)
• Décider : gagnant, perdant, ou inconclusive (pas assez de signal, garder A par défaut)

Étape 7 — Documenter le résultat (même perdant)

L’erreur la plus coûteuse en CRO : ne pas documenter les tests perdants. On finit par retester les mêmes choses 6 mois plus tard. Un journal de tests bien tenu vaut de l’or.

Format minimum pour chaque test

Champ	Exemple
Date	2026-04-15 → 2026-04-29
Hypothèse	Si on remplace “Acheter” par “Ajouter au panier”…
Variante A vs B	Capture d’écran A et B
Audience	Mobile uniquement, FR
Volume	8 200 visiteurs / variante
Métrique principale	Taux d’ajout au panier
Résultat	A : 12,3 % / B : 13,8 % / +12 % relatif
Significativité	Oui (p < 0,05)
Décision	Implémenter B en prod
Apprentissage	Wording moins engageant gagne sur ce type de produit

Un Notion / Confluence / Google Sheets bien structuré suffit. La discipline de documentation est probablement la première variable qui sépare un programme CRO mature d’un programme amateur.

Articulation avec le reste

Lancer un A/B test propre, c’est une chose. L’interpréter correctement, c’en est une autre — c’est le sujet de l’article méthodologie A/B testing (taille d’échantillon, peeking, durée). Pour les A/B tests appliqués spécifiquement aux bannières de consentement, voir A/B testing du banner CMP.

Sur un audit complet, je vérifie systématiquement si le programme A/B testing du client tourne sur des hypothèses claires, un journal documenté, et des tailles d’échantillon réalistes — c’est l’un des marqueurs de maturité analytics d’une équipe. Détail dans la méthodologie d’audit ou via un audit tracking complet.

En synthèse

Sept étapes, deux disciplines : la rigueur en amont (hypothèse, métrique unique, variantes minimalistes) et la discipline en aval (pas de peeking, documentation systématique). Le reste — choix de l’outil, configuration — est de la mécanique. La maturité d’un programme CRO ne se mesure pas au nombre de tests lancés, mais à la qualité des apprentissages cumulés sur 6 à 12 mois.

Sources

• Evan Miller — A/B Test Sample Size Calculator — calculateur de référence
• Ron Kohavi — Trustworthy Online Controlled Experiments — livre de référence Microsoft / Airbnb sur l’expérimentation