Tester une hypothèse : ce qu’un test A/B peut dire

Sommaire

L’expérimentation est le seul outil du marketing digital qui produise une preuve plutôt qu’une corrélation. C’est aussi celui qu’on utilise le plus mal, parce que ses conditions d’usage sont exigeantes et rarement vérifiées avant de commencer.

Ce qu’un test répond

Un test A/B répond à une question de la forme : « sur cette page, pour ce public, cette version produit-elle plus de cette action que celle-ci ? ». Trois restrictions, toutes importantes : une page, un public, une action.

Il ne répond pas à « quelle est la meilleure page », ni à « pourquoi », ni à « est-ce que ça marchera ailleurs ». Ces trois questions demandent autre chose, et la troisième est celle qui produit le plus de déceptions.

L’hypothèse vient avant la variante

Un test sans hypothèse écrite est une comparaison, pas une expérience. La différence est pratique : sans hypothèse, un résultat négatif n’apprend rien, alors qu’il devrait apprendre autant qu’un positif.

Une hypothèse utile a trois parties : une observation, une explication proposée, une prédiction. « La moitié des visiteurs quittent le formulaire au champ budget ; nous supposons qu’il est perçu comme intrusif à ce stade ; le retirer devrait augmenter les soumissions sans dégrader la qualification. »

Notez la seconde partie de la prédiction. Un test qui ne prévoit qu’un effet positif ne saura pas reconnaître un effet secondaire — et l’effet secondaire est souvent le vrai résultat.

Ce qu’il faut avant de tester

Sur le volume, l’ordre de grandeur se calcule avant de commencer, à partir de trois éléments : le taux de conversion actuel, l’écart minimal qu’on souhaite pouvoir détecter, et le trafic disponible. Le résultat est souvent décourageant, et c’est une information en soi : détecter un gain de 5 % relatif demande beaucoup plus de trafic que détecter un gain de 30 %.

Beaucoup de sites n’ont pas le volume pour tester ce qu’ils veulent tester. Le savoir avant évite de lancer un test qui ne conclura jamais.

Les pièges statistiques

Arrêter dès que c’est significatif. C’est l’erreur la plus répandue et la plus coûteuse. En regardant chaque jour et en s’arrêtant au premier signal favorable, on transforme un test en générateur de faux positifs. La durée se décide avant, et on ne regarde pas le résultat pour décider de continuer.

Tester dix choses à la fois. Plus on multiplie les variantes et les indicateurs, plus la probabilité qu’au moins un écart paraisse significatif par hasard augmente.

Lire un test non concluant comme une égalité. Ne pas détecter de différence n’est pas prouver qu’il n’y en a pas ; c’est souvent prouver qu’on manquait de volume.

Le « presque significatif ». Un résultat qui n’atteint pas le seuil n’est pas un petit résultat : c’est une absence de résultat. Le prolonger jusqu’à ce qu’il passe est la même erreur que la première.

Ce qui ne se teste pas en A/B

• Le positionnement. Il se joue sur des mois et sur l’ensemble du dispositif, pas sur une page.
• Les effets longs. Fidélité, réachat, réputation dépassent la fenêtre d’un test.
• Ce qui touche peu de monde. Une page à trois cents visites par mois ne conclura pas.
• Ce qu’on ne peut pas défaire. Un prix affiché différemment à deux visiteurs pose des questions qui débordent largement la méthode.

Quand le volume manque

C’est la situation la plus fréquente, et elle n’interdit pas d’apprendre. Trois méthodes donnent des réponses utiles sans exiger de volume.

L’observation directe. Regarder cinq personnes utiliser la page en pensant à voix haute apprend plus, en une heure, que trois semaines d’un test qui ne conclura pas. Cela ne mesure rien ; cela révèle des obstacles qu’on ne soupçonnait pas.

Le test séquentiel. Une version pendant un mois, la suivante le mois d’après, en comparant. C’est méthodologiquement inférieur — la saisonnalité et les campagnes polluent — mais lisible, à condition d’assumer la faiblesse.

Le test géographique. Appliquer le changement sur une zone et pas sur une autre. Plus robuste que le séquentiel, et c’est aussi la méthode des mesures d’incrémentalité décrites dans l’article sur les modèles d’attribution.

Où trouver les hypothèses

La pénurie d’un programme d’expérimentation n’est jamais le trafic : c’est la qualité des hypothèses. Quatre gisements, par ordre de rendement.

• Les objections de la vente. Ce que les commerciaux entendent dix fois par semaine désigne exactement ce que le site ne lève pas.
• Les questions du support. Une question récurrente est une information manquante à l’endroit où elle se pose.
• Les points de fuite mesurés. Le tunnel dit où l’on perd ; il ne dit pas pourquoi, mais il oriente.
• L’observation directe. Voir cinq personnes buter au même endroit vaut n’importe quelle intuition.

Ce qui ne produit pas d’hypothèses utiles : les listes de bonnes pratiques, les captures de concurrents, et les avis en réunion. Ils produisent des variantes, ce qui n’est pas la même chose.

Comment répartir le trafic

Deux versions, parts égales. C’est la répartition qui détecte le plus petit écart pour un volume donné, et il n’y a pas de raison d’en changer sauf risque particulier.

La tentation d’exposer 10 % des visiteurs à la nouveauté « pour limiter le risque » a un coût rarement calculé : elle allonge considérablement la durée nécessaire. Si le risque est réel au point de justifier cette précaution, la vraie question est de savoir si le changement doit être testé ou d’abord corrigé.

Ce qui invalide un test en cours

Quatre événements suffisent à rendre un résultat ininterprétable, et ils se produisent tout le temps.

Une mise en production qui touche la page ou le tunnel. Un changement de campagne qui modifie la composition du trafic — c’est le plus fréquent, et le plus invisible. Une période atypique : soldes, vacances, actualité. Du trafic automatisé non filtré, qui dilue les deux groupes de façon inégale.

D’où une discipline simple : noter les dates de tous les tests dans le même calendrier que les mises en production et les campagnes. C’est ce calendrier qui permet, trois mois plus tard, de savoir si un résultat bizarre était un résultat.

Documenter, surtout les perdants

Un programme d’expérimentation vaut par sa mémoire. Sans registre, la même idée est retestée tous les dix-huit mois, au gré des arrivées dans l’équipe.

Cinq colonnes suffisent : la date, l’hypothèse, ce qui a été changé, le résultat, et ce qu’on en a conclu. La dernière est la plus importante et la plus souvent vide : un test perdant qui a appris que le budget n’était pas l’obstacle vaut plus qu’un test gagnant dont personne ne sait pourquoi il a gagné.

Ce qu’on mesure pendant le test

Un test a un indicateur principal, décidé avant de commencer, et un seul. Choisir après coup celui qui donne le résultat le plus favorable est la façon la plus courante de se tromper soi-même.

À côté de lui, deux ou trois garde-fous : des indicateurs qu’on ne cherche pas à améliorer mais qu’on refuse de voir se dégrader. Sur un formulaire raccourci, l’indicateur principal est le taux de soumission ; le garde-fou est le taux d’acceptation par la vente, puisque c’est précisément ce que le raccourcissement risque d’abîmer.

Sans garde-fou, un test peut être déclaré gagnant tout en dégradant le résultat de l’entreprise. C’est fréquent, et cela ne se voit que des semaines plus tard, dans un autre service.

Après le test

Un résultat positif n’est pas la fin de l’expérience. Trois choses restent à faire, et la troisième est presque toujours oubliée.

1. Déployer proprement — la variante gagnante devient la version de référence, et l’outil de test cesse de la servir.
2. Vérifier que le gain tient sur les semaines suivantes. Un effet de nouveauté s’estompe ; un vrai gain, non.
3. Chercher où le même raisonnement s’applique. Si retirer le champ budget a fonctionné sur une page, la question se pose sur les cinq autres formulaires du site — pas comme une certitude, comme la prochaine hypothèse.

Le taux de réussite

Une attente à corriger, parce qu’elle démoralise les équipes : la majorité des tests bien conçus ne produisent pas d’effet détectable. C’est le fonctionnement normal de la méthode, et non un échec du programme.

Un programme dont presque tous les tests gagnent doit inquiéter plutôt que rassurer : soit on ne teste que l’évident, soit on arrête les tests trop tôt. Les deux se corrigent.

Les erreurs fréquentes

Tester avant d’avoir corrigé l’évident. Une page de destination qui ne correspond pas à son annonce n’a pas besoin d’un test, mais d’une correction.

Tester sans mesure fiable. Un test s’appuie sur des événements ; si ceux-ci sont faux, le test l’est aussi. Le plan de marquage vient avant.

Généraliser un résultat. Ce qui a fonctionné sur une page, pour un public, à un moment, est une information sur ce contexte — pas une règle.

Confondre le test et l’outil. Acheter une plateforme d’expérimentation ne crée pas de programme d’expérimentation. Ce qui manque, dans la quasi-totalité des cas, n’est pas la capacité technique à servir deux versions : c’est la discipline d’écrire une hypothèse, de fixer une durée, de tenir un registre et d’accepter les résultats négatifs. Une équipe qui a cette discipline peut commencer sans outil dédié ; une équipe qui ne l’a pas produira des tests ininterprétables avec le meilleur des outils.