LanderKit

Que tester en premier sur une landing page ? Prioriser ses A/B tests

Publié le 1 août 2026 · 8 min de lecture

Chaque A/B test consomme une ressource finie : des semaines de trafic. Un site qui reçoit 10 000 visiteurs par mois sur sa landing page peut mener, statistiquement, une poignée de tests concluants par an — nous détaillons ce calcul dans combien de temps doit durer un A/B test. La question n'est donc pas « que pourrait-on tester ? » (tout) mais « dans quel ordre dépenser un budget de cinq tests ? ». Et sur ce point, les données accumulées par les plateformes d'expérimentation racontent une histoire dérangeante : la grande majorité des tests ne produisent rien de mesurable, et l'essentiel des gains vient d'une petite minorité d'idées. Prioriser n'est pas un raffinement de méthode — c'est ce qui sépare les programmes de test rentables des occupations statistiques.

Ce que dit la recherche : des gains très inégalement répartis

Une étude d'Azevedo, Deng, Montiel Olea, Rao et Weyl publiée en 2020 dans le Journal of Political Economy (« A/B Testing with Fat Tails ») a analysé des milliers d'expérimentations menées sur la plateforme du moteur de recherche Bing et posé la question en économistes : comment répartir un budget d'expérimentation quand on ignore quelles idées gagneront ? Leur constat empirique : la distribution des gains est à « queue épaisse » — la plupart des idées testées ont un effet minuscule, et une petite fraction produit des effets démesurément grands. Leur conclusion pratique : dans un tel régime, mieux vaut tester plus d'idées vraiment différentes, quitte à les tester moins finement, que raffiner à l'infini des micro-variations. Pour une landing page, la traduction est directe : cinq tests portant sur cinq hypothèses radicalement différentes (promesse, offre, structure, preuve, formulaire) ont bien plus de chances de contenir un gagnant majeur que cinq variations du même bouton. Les pionniers du domaine chez Microsoft faisaient déjà ce constat d'humilité dans leur guide de référence publié en 2009 dans Data Mining and Knowledge Discovery (« Controlled Experiments on the Web: Survey and Practical Guide », Kohavi et al.) : la majorité des idées testées, y compris celles des experts, échouent à améliorer les métriques qu'elles visaient.

La hiérarchie des éléments : tester du haut vers le bas

À défaut de données propres à votre page, la hiérarchie par impact potentiel est bien établie — elle va des éléments qui changent ce que la page dit vers ceux qui changent comment elle le dit :

  1. L'offre elle-même — garantie, essai, prix d'appel, bonus : c'est le levier le plus puissant et le moins testé, parce qu'il demande une décision business et pas seulement un changement de page.
  2. La proposition de valeur et le titre — ce que le visiteur comprend en cinq secondes ; le titre et la proposition de valeur conditionnent tout ce qui suit.
  3. La structure et l'ordre des sections — quels arguments, quelles preuves, dans quel ordre (voir l'anatomie d'une page qui convertit).
  4. Le formulaire et le CTA — nombre de champs, formulation du bouton, friction du parcours.
  5. Les éléments cosmétiques — couleurs, images, micro-formulations : à tester en dernier, quand le reste est solide ; la couleur du bouton est l'exemple canonique du test populaire à faible enjeu.

ICE et PIE : des cadres utiles, à condition de rester honnête

Les cadres de priorisation classiques notent chaque idée de test sur trois critères. ICE : Impact espéré, Confiance dans l'hypothèse, Facilité de mise en œuvre (Ease). PIE : Potentiel de la page, Importance du trafic qu'elle reçoit, facilité d'Exécution. On note chaque critère sur 10, on moyenne, on trie. Leur vraie valeur n'est pas la pseudo-précision du score — c'est de forcer trois questions explicites avant chaque test. Deux garde-fous les rendent réellement utiles : d'abord, ancrer la note de « confiance » dans des indices concrets (enregistrements de sessions, heatmaps, retours clients, résultats d'un test des 5 secondes) plutôt que dans l'enthousiasme de l'auteur de l'idée ; ensuite, se souvenir de la leçon des queues épaisses : les idées audacieuses méritent un bonus d'impact, pas un malus de confiance — c'est précisément parce qu'on est incertain de leur effet qu'elles peuvent rapporter gros.

Le cas des petits trafics : prioriser encore plus fort

Sous quelques milliers de visiteurs mensuels, la plupart des tests n'atteindront jamais la significativité — notre article sur l'A/B test sans trafic propose les alternatives (tests séquentiels, recherche utilisateur, refontes franches mesurées avant/après). La logique de priorisation reste la même, portée à l'extrême : ne testez que des changements dont l'effet espéré est assez gros pour être détectable chez vous, c'est-à-dire les niveaux 1 à 3 de la hiérarchie ci-dessus. Un site à petit trafic qui teste une couleur de bouton s'est condamné d'avance à ne rien apprendre.

En pratique : un pipeline de tests, pas des tests isolés

Tenez une liste unique d'hypothèses, notée ICE ou PIE, réévaluée à chaque résultat : un test gagnant sur le titre reclasse les tests suivants (la nouvelle promesse change ce que la preuve sociale doit prouver), un test perdant est une information qui recalibre les notes de confiance voisines. Et commencez avec une structure déjà éprouvée plutôt qu'une page à inventer : les dix templates LanderKit (89 € l'unité, 229 € le pack) fournissent l'anatomie standard — promesse, preuve, offre, formulaire — sur laquelle vos tests portent alors sur le contenu, là où la recherche situe les gros gains, plutôt que sur des questions de structure déjà tranchées par l'usage. Le mode d'emploi complet de l'exécution, lui, est dans notre guide de l'A/B test de landing page.

FAQ

Questions fréquentes

Quel est le premier A/B test à faire sur une landing page ?

Dans la grande majorité des cas : le titre et la proposition de valeur, testés avec deux angles réellement différents (pas deux formulations voisines). C'est l'élément que 100 % des visiteurs voient, celui qui conditionne la lecture du reste, et celui dont les variations produisent les effets les plus détectables.

Faut-il utiliser ICE ou PIE ?

Les deux se valent : ils forcent les mêmes questions (combien ça peut rapporter, pourquoi on y croit, combien ça coûte à mettre en place). Choisissez-en un, appliquez-le à toutes les idées de la même façon, et ancrez les notes dans des indices concrets plutôt que dans l'intuition seule.

Combien d'idées faut-il avoir dans son backlog de tests ?

Une dizaine d'hypothèses vivantes suffit : assez pour comparer et prioriser, pas trop pour rester à jour. L'important n'est pas la taille de la liste mais sa diversité — des hypothèses portant sur l'offre, le message, la structure et la friction, pas dix variantes du même élément.

Que faire quand un test est perdant ?

L'enregistrer avec la même rigueur qu'un gagnant : un test perdant sur un élément majeur est une vraie information (l'hypothèse derrière la variante était fausse) qui doit recalibrer la confiance des hypothèses voisines. Les programmes de test qui ne documentent que les victoires refont les mêmes erreurs en boucle.

À lire ensuite

Articles liés