Arbitrer entre isoler un changement et grouper plusieurs changements dans un test

Face à une liste d'idées à tester, une question revient systématiquement : faut-il tester chaque changement séparément, ou en regrouper plusieurs dans un même test A/B ou multivarié ? Il n'existe pas de réponse fixe : elle dépend du trafic disponible, du coût de chaque test, et de ce qu'on a réellement besoin de savoir.

Ce que chaque approche coûte et rapporte

Deux forces s'opposent à chaque décision de test. Isoler un changement dans son propre test apporte un bénéfice précis : savoir exactement quel changement a produit quel effet. Mais chaque test isolé a un coût, le temps et l'argent nécessaires à sa mise en œuvre, et un délai, le temps nécessaire pour atteindre une signification statistique.

Isoler chaque changement, quand cela se justifie

Tester un changement seul se justifie quand le besoin de savoir précisément ce qu'il a produit est fort : le changement est coûteux à engager (une garantie audacieuse, un changement de prix, un cadeau promotionnel), les enjeux sont élevés parce que le changement sera répliqué ailleurs (d'autres pages, d'autres sites, d'autres supports), ou la confiance dans l'efficacité du changement reste faible, ce qui rend le test nécessaire pour trancher plutôt que pour confirmer une intuition. Cette approche se justifie d'autant plus que la mise en œuvre du test reste rapide et peu coûteuse, et que le trafic disponible permet d'atteindre une signification statistique rapidement.

Grouper plusieurs changements, quand cela se justifie

Regrouper plusieurs changements dans un même test se justifie dans la direction inverse : quand savoir précisément lequel des changements a fonctionné importe moins que de constater une amélioration globale, ou quand la confiance dans l'efficacité des changements est déjà forte (corriger des éléments manifestement défectueux, ou des changements déjà validés par un test d'utilisabilité). Cette approche se justifie aussi quand les coûts de test sont élevés : mise en œuvre lente à cause de processus d'approbation lourds ou de ressources de développement limitées, changements trop imbriqués pour être séparés proprement, trafic insuffisant pour détecter un petit changement isolé en un temps raisonnable, ou un excédent d'idées valables par rapport à la capacité de mise en œuvre disponible.

Trouver le vrai goulot d'étranglement avant de choisir

La question à se poser n'est pas seulement combien de changements grouper, mais où se situe réellement le frein du processus de test : un manque d'idées, des cycles de développement lents, une chaîne d'approbation bureaucratique, ou un trafic insuffisant pour atteindre la significativité. Chacun de ces freins appelle une réponse différente, et résoudre le mauvais frein de façon efficace n'accélère rien.

Application pratique

Devant une liste de changements à tester, la décision se prend changement par changement plutôt qu'une fois pour toutes : un test peut isoler une hypothèse coûteuse ou incertaine pendant qu'un autre regroupe plusieurs corrections déjà validées par ailleurs. L'objectif constant reste d'apprendre et de mettre en œuvre le plus vite possible, ce qui suppose de savoir, à chaque instant, quel goulot d'étranglement limite réellement la vitesse du programme de test.