Test utilisateur ou A/B testing : lequel choisir et quand ?

Test utilisateur vs A/B testing : la question revient dans toutes les équipes produit qui ont un funnel à améliorer et un budget limité. Elle est mal posée, parce que les deux méthodes ne répondent pas à la même question. L'A/B test dit combien : quelle variante convertit le mieux, avec quelle confiance. Le test utilisateur dit pourquoi : ce que les gens ont compris, cherché, raté. Choisir entre les deux, c'est choisir entre mesurer et comprendre. La plupart du temps, vous avez besoin des deux, dans un certain ordre.

Ce que fait vraiment un A/B test

Un A/B test expose deux versions d'une page ou d'un parcours à des utilisateurs réels, en production, et compare un indicateur : taux de clic, taux d'inscription, panier validé. Sa force est la mesure : avec assez de trafic, il tranche entre deux options avec une marge d'erreur connue, sans que personne n'ait à interpréter quoi que ce soit.

Ses limites sont tout aussi nettes :

• Il faut du trafic. Le volume nécessaire se calcule avant de lancer, à partir de l'écart qu'on espère détecter et du taux de conversion actuel : plus l'écart attendu est petit, plus il faut de visiteurs par variante. Sur un produit B2B à faible trafic, le test dure des mois ou ne conclut jamais.
• Il faut des variantes. L'A/B test compare des hypothèses que vous avez déjà. Il ne vous dit pas quoi tester. Si vos deux variantes sont mauvaises, il vous dira laquelle l'est le moins.
• Il ne dit jamais pourquoi. Une variante gagne. Vous ne savez pas si c'est le libellé, la position, la couleur ou le fait qu'un bug affectait l'autre branche. C'est la réserve que formule le Nielsen Norman Group dans « Putting A/B Testing in Its Place » : la méthode mesure un comportement, elle n'en donne pas la raison.
• Il faut un produit en production. Rien à tester sur une maquette ou une préversion.

Ce que fait vraiment un test utilisateur

Un test utilisateur place un petit nombre de personnes, choisies pour ressembler à votre cible, devant votre produit avec des tâches à accomplir. Vous récupérez ce qu'elles ont fait, où elles ont hésité, ce qu'elles ont compris et ce qu'elles en disent. Sa force est l'explication : en dix réponses bien lues, vous savez pourquoi une étape décroche et vous avez souvent la correction sous les yeux.

Ses limites :

• Il ne mesure pas. « 9 testeurs sur 12 ont réussi » décrit un panel, pas votre base d'utilisateurs. Jeff Sauro et James Lewis consacrent un chapitre de « Quantifying the User Experience » aux tailles d'échantillon des études qui cherchent des problèmes : on peut y conclure avec moins de dix participants, mais sur ce qui bloque, pas sur un taux de conversion.
• Il dépend du recrutement. Dix personnes qui ne ressemblent pas à vos clients produisent dix mauvaises réponses. La qualité du panel fait la qualité du test.
• Il dépend de la relecture. Les réponses doivent être lues, triées, confrontées. Un test dont les réponses bâclées sont comptées comme les autres ne vaut rien.

Il a en revanche un avantage décisif : il fonctionne sans trafic et avant la production, sur une maquette Figma ou un environnement de test. Nous décrivons la méthode dans test utilisateur à distance : la méthode complète.

Test utilisateur vs A/B testing : le tableau de décision

Posez-vous quatre questions.

1. Avez-vous assez de trafic ? Non : le test utilisateur est votre seule option de mesure raisonnable. Oui : continuez.
2. Savez-vous ce qu'il faut changer ? Non : commencez par un test utilisateur pour trouver les frictions et formuler des hypothèses. Oui : continuez.
3. Le produit est-il en production ? Non : test utilisateur, sur maquette ou préversion. Oui : continuez.
4. La différence entre vos variantes est-elle petite ? Oui : A/B test, c'est exactement ce pour quoi il est fait. Non, les variantes sont radicalement différentes : un test utilisateur vous évitera de mettre en production une version que personne ne comprend.

En pratique, un produit qui a du trafic et des hypothèses claires fait des A/B tests. Un produit qui n'a pas de trafic, ou pas d'hypothèses, fait des tests utilisateurs. Un produit mature fait les deux.

Comment combiner les deux dans un projet produit

La séquence qui fonctionne le mieux, parce qu'elle utilise chaque méthode pour ce qu'elle sait faire :

• Avant : comprendre. Un test utilisateur sur le parcours qui décroche, avec huit à douze participants proches de votre cible. Vous en sortez avec deux ou trois frictions priorisées et, pour chacune, une correction candidate. Pour un funnel en production, voir comprendre pourquoi un funnel ne convertit pas.
• Pendant : mesurer. Chaque correction devient une variante. L'A/B test départage l'ancienne version et la nouvelle sur du trafic réel, avec un chiffre que la direction peut lire.
• Après : vérifier. Quand une variante gagne sans qu'on comprenne pourquoi, ou perd alors que tout le monde y croyait, un second test utilisateur court explique le résultat et évite de tirer la mauvaise leçon.

Cette boucle coûte moins cher qu'une série d'A/B tests à l'aveugle, parce qu'elle réduit le nombre de variantes à tester à celles qui ont une raison d'exister.

Les erreurs qu'on voit souvent

• Faire des A/B tests sans trafic. Le test ne conclut jamais, l'équipe finit par choisir « au feeling » et appelle ça de la data.
• Demander à un test utilisateur un pourcentage. Douze personnes ne donnent pas un taux de conversion. Elles donnent des raisons.
• Tester des variantes que personne n'a comprises. Un A/B test entre deux formulations obscures désigne un gagnant obscur.
• Compter toutes les réponses d'un test utilisateur. Une réponse expédiée en trois mots n'est pas une donnée. Chez earlypanel, elle est refusée après relecture, non payée, et n'entre pas dans le rapport.

En résumé

L'A/B testing mesure, le test utilisateur explique. Sans trafic, sans hypothèses ou avant la production, le test utilisateur est la seule méthode utilisable. Avec du trafic et des variantes crédibles, l'A/B test tranche. Le meilleur programme produit fait précéder chaque A/B test important d'un test utilisateur court, et le fait suivre d'un autre quand le résultat surprend.

Sources

• Nielsen Norman Group, « Putting A/B Testing in Its Place » : nngroup.com
• Nielsen Norman Group, « When to Use Which User-Experience Research Methods » : nngroup.com
• Jeff Sauro et James R. Lewis, « Quantifying the User Experience: Practical Statistics for User Research », 2e édition, Morgan Kaufmann, 2016 : measuringu.com

Questions fréquentes

Quelle est la différence entre test utilisateur et A/B testing ?

L'A/B test compare deux versions sur du trafic réel et mesure laquelle convertit le mieux. Le test utilisateur observe un petit nombre de personnes représentatives en situation et explique où et pourquoi elles bloquent. L'un mesure, l'autre comprend.

Quand faire un A/B test plutôt qu'un test utilisateur ?

Quand le produit est en production, que le trafic est suffisant pour détecter une différence, et que les variantes sont déjà définies et crédibles. Pour de petites différences entre deux versions proches, c'est le seul outil pertinent.

Peut-on combiner les deux ?

Oui, et c'est la meilleure pratique : un test utilisateur court avant pour identifier les frictions et formuler des hypothèses, un A/B test pour départager les corrections, puis un second test utilisateur si le résultat n'est pas compris.

Combien de trafic faut-il pour un A/B test ?

Cela se calcule avant le test, à partir de l'écart attendu et du taux de conversion actuel, avec un calculateur de taille d'échantillon. Plus l'écart attendu est petit, plus il faut de visiteurs par variante. Sur un produit B2B à faible trafic, le test dure des mois ou ne conclut jamais.