Une variante de page produit affiche 20 % de conversions supplémentaires. Le tableau de bord la colore en vert. Faut-il la déployer ? Pas forcément : derrière ce chiffre peuvent se cacher douze commandes de différence, un trafic mal réparti ou une promotion qui a réduit la marge. Le test A/B n’est utile que si son résultat permet une décision économique défendable.
Le travail commence avant la première exposition. Il consiste à définir ce que l’on cherche à améliorer, combien de visiteurs seront nécessaires et quels dégâts rendraient une hausse de conversion inacceptable. Voici une méthode pour construire ce protocole, lire les chiffres et reconnaître les situations où tester serait moins raisonnable que corriger directement un problème connu.
En bref — Fixez une mesure principale et un effet minimal utile avant le lancement. Dimensionnez l’échantillon en visiteurs réellement éligibles. Gardez une affectation stable, contrôlez la collecte et attendez la maturation des achats. Une différence observée peut rester incertaine ; une conversion supérieure peut également cacher une contribution financière inférieure.
Transformer une idée en hypothèse mesurable
« Améliorer le tunnel » n’est pas une hypothèse. « Afficher le coût de livraison avant la saisie de l’adresse réduit les abandons liés à la surprise tarifaire » en est une. Elle précise le mécanisme attendu, la population et la modification. On peut alors choisir un indicateur qui correspond au mécanisme sans oublier l’objectif commercial.
Une fiche d’expérience peut tenir sur une page : problème observé, variante, population éligible, unité de randomisation, événement de conversion, fenêtre d’observation, effet minimal, durée maximale et critères de sécurité. Ajoutez le responsable de la décision et la règle prévue si le test ne tranche pas. Ce dernier point évite de prolonger indéfiniment une expérience parce qu’elle n’a pas confirmé une préférence personnelle.
La mesure principale devrait être suffisamment proche de la valeur recherchée. Pour un panier, ce peut être la proportion de visiteurs éligibles ayant passé une commande valide dans un délai défini. Un clic sur le bouton reste un indicateur intermédiaire : il peut augmenter alors que les paiements échouent ensuite.
Définissez « valide ». Une commande annulée immédiatement, un doublon de paiement et une transaction de test ne constituent pas nécessairement trois succès. Les conventions doivent être identiques entre A et B. Notre dossier sur la définition des indicateurs métier explique pourquoi un bon calcul ne sauve pas une définition ambiguë.
Le gain relatif masque facilement la petite différence absolue
Prenons un exemple fictif : le taux de commande habituel vaut 2 %. L’entreprise estime qu’une variante à 2,4 % aurait assez de valeur pour justifier le développement et la maintenance. La différence est de 0,4 point de pourcentage, soit une progression relative de 20 %.
Ces deux formulations décrivent le même objectif, mais elles ne donnent pas la même impression. L’échantillon dépend de la différence absolue et de la variabilité du taux, pas de l’enthousiasme que provoque « +20 % » dans une présentation.
L’effet minimal détectable doit correspondre à un seuil économiquement pertinent. Si une hausse de 0,05 point ne paierait jamais la fonctionnalité, dimensionner le test pour cette hausse peut immobiliser inutilement le trafic. À l’inverse, choisir un effet énorme uniquement pour raccourcir l’expérience risque de rendre invisibles des progrès modestes mais rentables.
Le taux de référence doit venir d’une période comparable, avec la même population et la même définition de conversion. Le taux global du site n’est pas automatiquement celui des visiteurs atteignant une page produit. Une campagne de retargeting, un lancement commercial ou un incident récent peuvent modifier cette base. Documentez l’incertitude plutôt que de fabriquer une précision artificielle.
Calculer l’échantillon : un ordre de grandeur, avec des hypothèses
Pour comparer deux proportions indépendantes avec des groupes équilibrés, une approximation normale courante donne le nombre nécessaire par groupe :
n ≈ [zα × √(2p̄(1−p̄)) + zβ × √(pA(1−pA)+pB(1−pB))]² / (pB−pA)²
Ici, p̄ est la moyenne des deux taux attendus. Pour un test bilatéral au seuil de 5 %, zα vaut environ 1,96 ; pour une puissance de 80 %, zβ vaut environ 0,842. Le seuil contrôle le risque de rejeter l’absence d’effet lorsque cette hypothèse est vraie, dans les conditions du test. La puissance représente la chance de détecter l’effet choisi s’il existe réellement.
Avec 2 % et 2,4 %, ce calcul donne environ 21 109 visiteurs par variante, donc 42 218 au total, après arrondi au supérieur. Il s’agit d’une approximation sans correction de continuité, pour des observations indépendantes et une procédure à horizon fixe. Un calculateur utilisant une autre méthode peut fournir un nombre légèrement différent. Pour un enjeu important, faites valider la méthode et les hypothèses par un spécialiste.
À 300 visiteurs éligibles par jour, recueillir ce total exige environ 141 jours. Ce n’est pas un petit test d’une semaine. Si le site reçoit 10 000 visites quotidiennes mais que seules 300 entrent dans le parcours concerné, les 10 000 ne réduisent pas ce délai.
| Paramètre de l’exemple fictif | Valeur retenue | Conséquence pratique |
|---|---|---|
| Conversion de référence | 2 % | Ne pas utiliser une population différente |
| Conversion cible | 2,4 % | Gain de 0,4 point, pas 20 points |
| Allocation | 50 % / 50 % | Environ 21 109 personnes dans chaque groupe |
| Seuil et puissance | 5 % bilatéral ; 80 % | Convention fixée avant les résultats |
| Trafic éligible | 300 personnes par jour | Environ 141 jours de collecte |
Ce résultat peut suffire à abandonner l’idée d’un A/B classique. Une modification ciblée sur un site peu fréquenté pourra être étudiée par des tests utilisateurs, des entretiens, une analyse des erreurs ou une vérification de parcours. Ces approches répondent à d’autres questions ; elles ne fournissent pas automatiquement une estimation causale du gain de conversion.
Randomiser au bon niveau, puis conserver l’affectation
Le visiteur doit rester dans la même variante au fil du parcours. Si un utilisateur voit A sur mobile puis B sur ordinateur, l’interprétation devient plus compliquée. Lorsque l’identification authentifiée est disponible, elle peut faciliter une affectation stable ; sinon, documentez les limites des identifiants utilisés, leur durée et les contraintes de confidentialité.
L’unité peut être une personne, un compte client ou une entreprise. En B2B, plusieurs acheteurs du même compte peuvent partager un processus d’approbation. Les répartir entre deux expériences incompatibles introduit des interactions. Randomiser par compte devient parfois plus pertinent, mais réduit le nombre d’unités indépendantes. Un calcul pensé pour des visiteurs individuels ne s’applique alors plus tel quel.
Il faut également séparer affectation et exposition. Un visiteur affecté à B peut quitter le site avant que le composant ne s’affiche. Exclure ensuite les personnes non exposées peut sélectionner une population influencée par la variante elle-même. Choisissez à l’avance l’analyse principale et gardez les événements nécessaires pour examiner ce problème.
La stabilité concerne aussi le produit testé. Modifier le texte de B au milieu du test crée une troisième expérience déguisée. Si une correction urgente est indispensable, journalisez-la, interrompez si nécessaire et repartez avec un protocole clair. Une date de changement dans un fichier ne suffit pas toujours à rendre les anciennes données comparables.
Vérifier les données avant de regarder le gagnant
Un partage prévu à 50/50 ne doit pas devenir inexplicablement 60/40. Le sample ratio mismatch, ou déséquilibre du ratio d’échantillon, sert de signal d’alerte. Il peut révéler un problème d’affectation, d’exposition ou de journalisation. Il n’établit pas à lui seul la cause ; il impose une investigation avant d’interpréter la performance.
Regardez les effectifs réellement affectés, les appareils, les pays autorisés et les versions du navigateur. Un script bloqué sur une variante peut faire disparaître certaines visites du journal. Le résultat apparent refléterait alors un défaut de mesure plutôt qu’un meilleur parcours.
Vérifiez aussi les achats côté serveur. Un événement émis à chaque rechargement de la page de confirmation peut compter deux conversions pour une seule commande. Utilisez un identifiant de transaction stable, contrôlez les annulations et rapprochez un échantillon avec le système de vente. Ces vérifications prolongent les principes de gestion des doublons dans les automatisations.
Un test A/A, où les deux groupes reçoivent la même expérience, peut aider à vérifier l’instrumentation et le chemin de décision. Il ne prouve pas que tous les futurs tests seront corrects. Les versions de code, les campagnes et les populations changeront. Gardez donc les contrôles de qualité actifs pendant chaque expérience.
Douze commandes supplémentaires ne font pas une preuve
Reprenons un second exemple fictif : A recueille 60 commandes sur 3 000 visiteurs, B en recueille 72 sur 3 000. Les taux observés sont 2 % et 2,4 %. L’amélioration relative affichée vaut bien 20 %.
Mais l’échantillon est bien inférieur à celui prévu pour détecter cet effet. Avec une comparaison bilatérale normale usuelle des proportions, la différence donne une valeur p d’environ 0,29. Elle ne permet pas de conclure au seuil de 5 %. Cela ne démontre pas non plus que les variantes sont équivalentes.
Incertitude ne signifie pas absence d’effet. La conclusion utile est que les données ne tranchent pas suffisamment avec ce protocole. Affichez les effectifs, les taux et l’intervalle d’incertitude, pas seulement un voyant rouge ou vert. Si l’outil fournit une probabilité bayésienne, sa signification dépend du modèle et des hypothèses ; elle n’est pas interchangeable avec une valeur p.
Le piège classique consiste à regarder les résultats chaque matin et à s’arrêter au premier passage sous un seuil. Les procédures à horizon fixe ne sont pas conçues pour cette règle. Si l’organisation veut une surveillance continue, elle doit choisir une méthode séquentielle adaptée avant le lancement, avec ses propres règles d’arrêt.
Autre piège : chercher après coup le segment gagnant parmi vingt découpages. Un effet sur « Android, le mardi, nouveaux visiteurs » peut être un accident statistique. Les analyses exploratoires sont utiles pour formuler une nouvelle hypothèse, puis la tester séparément. Elles doivent rester présentées comme exploratoires.
Garder une barrière économique autour de la conversion
Une variante peut augmenter les achats en mettant en avant une remise, tout en réduisant la marge contributive. Dans un exemple pédagogique, A génère 100 commandes à 30 € de contribution moyenne, soit 3 000 €. B en génère 110 à 25 €, soit 2 750 €. Les commandes progressent de 10 %, la contribution recule de 250 €.
Définissez donc des garde-fous : contribution par visiteur, remboursements, incidents de paiement, temps de réponse, contacts au support ou erreurs de commande. Leur sélection dépend du changement. Une interface de paiement demande des protections différentes d’un bloc de recommandations sur une fiche produit.
La valeur moyenne par visiteur peut avoir une distribution très asymétrique : quelques commandes importantes pèsent lourd. Ne réutilisez pas sans examen une formule conçue pour une conversion binaire. Selon les données, l’analyse demandera une autre méthode et davantage de précautions sur les observations extrêmes.
Laissez enfin les résultats mûrir. Une commande passée aujourd’hui peut être annulée demain. Une vente B2B peut attendre une approbation plusieurs jours. La fenêtre de conversion et la période de suivi doivent refléter ce délai. Arrêter la collecte ne signifie pas toujours pouvoir décider immédiatement.
Rédiger une décision qui survive à la présentation
Le compte rendu devrait indiquer la question, les dates, les effectifs, les exclusions prévues, les incidents, le résultat principal et les garde-fous. Ajoutez l’écart économique estimé et ce qui demeure incertain. Une autre équipe doit pouvoir comprendre pourquoi la variante a été déployée, rejetée ou laissée en attente.
Un résultat négatif documenté est une connaissance utile. Il peut éviter des développements coûteux ou révéler que le problème supposé n’était pas central. Conservez également les variantes sans effet concluant : relancer le même test avec un autre nom ne crée pas une nouvelle hypothèse.
Pour une petite équipe, la meilleure discipline consiste à tester moins d’idées, mais à mieux les préparer. Priorisez les changements plausibles, mesurables et assez importants pour le trafic disponible. Corrigez directement un paiement cassé ou une information trompeuse ; il n’est pas nécessaire de conserver une expérience défaillante pour fabriquer un groupe témoin.
Avant un déploiement complet, prévoyez une vérification technique progressive. Le test avait peut-être réparti le trafic sur deux versions, tandis que la généralisation concentre désormais tous les achats sur un nouveau service. Une dépendance peut devenir le goulot d’étranglement précisément après la victoire statistique. Comparez alors les erreurs, les délais de paiement et la contribution aux valeurs attendues, avec une procédure de retour arrière réellement praticable.
La décision doit aussi avoir une date de réexamen. Un changement gagnant pendant une campagne d’automne ne constitue pas une garantie valable pour tous les publics et toutes les saisons. Il reste préférable de surveiller durablement quelques indicateurs stables plutôt que de multiplier les petits tests incapables de distinguer un effet plausible du bruit.
Le bon test n’est finalement pas celui qui produit le plus beau pourcentage. C’est celui qui transforme une incertitude précise en une décision proportionnée, sans oublier les clients, la qualité des données et l’argent réellement gagné.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
