A/B testing d’un site web : quand tester et comment décider

Un test A/B doit répondre à une question de décision

Un test A/B compare les résultats de groupes répartis aléatoirement entre une version de référence et une variante, pendant une période commune. Il peut aider à estimer l’effet d’un changement sur une action définie. Il devient utile lorsque la page fonctionne déjà, que la mesure est fiable et que le nombre d’unités éligibles permet d’éclairer une décision dans un délai acceptable.

Il n’existe donc pas de nombre universel de visiteurs ni de durée valable pour tous les sites. Un site B2B recevant peu de demandes peut apprendre davantage d’une vérification du formulaire, d’entretiens ou de tâches de compréhension. La bonne première question est : « Quelle décision voulons-nous prendre, et ce dispositif peut-il réduire l’incertitude qui nous empêche de la prendre ? »

Ce qui distingue une expérience d’un avant/après

Publier une nouvelle page puis constater une hausse ne suffit pas à isoler son effet. La campagne, la saison, l’offre ou la composition de l’audience peuvent avoir changé. Dans une expérience correctement conçue, contrôle et variante sont observés en parallèle auprès de groupes comparables par la répartition aléatoire. La qualité de cette répartition et de la mesure reste à vérifier.

Vous pouvez comparer une formulation, un bloc ou une page complète. Si plusieurs choses changent ensemble, l’expérience porte sur cet ensemble : elle ne dira pas quel composant a produit l’effet. Un plan multivarié cherche à distinguer plusieurs facteurs et leurs interactions ; il demande une conception et une capacité de collecte adaptées. Ajouter des variantes ne crée pas davantage de données disponibles.

Quand corriger ou comprendre avant de tester

Un formulaire qui n’envoie pas, un bouton inaccessible ou une confirmation erronée appelle une correction et une recette. Une offre incomprise peut d’abord être reformulée avec l’aide de retours de la cible. Dans ces situations, le contrôle utile consiste à vérifier que le parcours annoncé fonctionne et se comprend.

Si la page nécessite une reprise de son contenu, de son design ou de son intégration, il peut être préférable de concevoir ou reprendre une landing page Webflow avant de prévoir une expérience. Le cadrage de cette page et la mise en place d’un dispositif de test sont deux besoins à préciser séparément.

Formuler une hypothèse qui peut être contredite

Une hypothèse relie un problème observé à un changement et à un effet attendu. Écrivez par exemple : « Les visiteurs ne savent pas ce qui suit le formulaire ; expliquer la prochaine étape pourrait augmenter la part de demandes abouties, sans dégrader leur pertinence. » L’observation initiale doit provenir d’un contrôle ou d’un retour réel, et non de la seule envie de changer la page.

Précisez la version de référence, le contenu exact de la variante et ce qui restera identique. Le lecteur du protocole doit pouvoir comprendre la différence sans ouvrir l’outil de test. Si vous cherchez encore la friction à traiter, les sept hypothèses à vérifier sur une landing page aident à construire ce premier diagnostic.

Choisissez un indicateur principal en rapport avec la décision. Les métriques intermédiaires aideront ensuite à interpréter le parcours. La méthode de préparation d’expérience de Microsoft Research insiste notamment sur l’hypothèse mesurable, la population affectée et le choix de l’unité de répartition. Ces principes doivent être adaptés à votre site et à votre cycle de demande.

Définir la population, l’allocation et les indicateurs

Choisir qui peut entrer dans l’expérience

Décrivez la population avant le lancement : page ou parcours, sources, appareils, pays, éventuelles exclusions et période d’entrée. Le trafic total du site ne correspond pas forcément aux unités concernées. Si la modification ne touche qu’un formulaire précis, une grande partie des visiteurs peut ne jamais être éligible.

Fixez une règle d’éligibilité indépendante de la réaction à la variante. Ne comparez pas uniquement les personnes qui ont cliqué après avoir vu chaque version : le changement peut lui-même influencer ce clic et donc la composition des groupes retenus. Définissez aussi ce que signifie « exposé », comment cette exposition est tracée et comment les cas de non-affichage seront traités.

Conserver une affectation cohérente

L’unité de répartition peut être un identifiant de navigateur ou, dans certains contextes, un compte. Ce choix doit correspondre à l’usage et à la mesure. Un navigateur ne représente pas parfaitement une personne : suppression d’identifiant, changement d’appareil et navigation partagée peuvent brouiller l’exposition. Si plusieurs personnes d’une même entreprise influencent une décision commune, ce contexte mérite aussi un examen.

Prévoyez une affectation aléatoire persistante pendant l’expérience. Une répartition de 50 % vers chaque version peut constituer un choix de départ, mais la proportion doit être écrite et justifiée dans le protocole. Elle ne signifie pas que les nombres observés seront exactement égaux. Évitez d’affecter arbitrairement une version aux visiteurs mobiles et l’autre aux visiteurs sur ordinateur : vous compareriez alors aussi des populations différentes.

Nommer numérateur, dénominateur et fenêtre de résultat

Pour une mesure binaire par unité, comptez au numérateur les unités affectées ayant accompli au moins une fois l’action définie, et au dénominateur les unités affectées du groupe selon la règle d’analyse prévue. Les clics répétés d’une unité ne deviennent pas plusieurs unités converties. Si la répartition se fait par identifiant mais que le rapport compte des sessions, la méthode doit tenir compte de cette différence.

Précisez le délai laissé à chaque unité pour réaliser l’action et le traitement des résultats tardifs. Une demande peut être envoyée plus tard, puis qualifiée après un échange commercial. Ne comparez pas une cohorte ayant eu tout son temps pour convertir à une cohorte à peine entrée. Pour les définitions de source, d’unité et de réception, commencez par définir les indicateurs du site.

Prévoir les indicateurs de protection

Une hausse du clic principal ne suffit pas si les demandes n’arrivent plus ou deviennent inutilisables. Retenez les protections adaptées : réception effective, erreurs, spam et doublons, pertinence des demandes ou temps de chargement du parcours. Ajoutez les contrôles de qualité de collecte nécessaires à la confiance dans le résultat.

Indiquez ce qui déclencherait une alerte et qui peut intervenir. Les seuils opérationnels doivent suivre vos contraintes réelles. Un incident de transmission ne doit pas attendre une conclusion statistique pour être traité.

Dimensionner le test avant de le lancer

Rassembler les hypothèses de calcul

Le dimensionnement dépend notamment du taux initial, de l’effet minimum que vous souhaitez pouvoir détecter, de la puissance recherchée, du risque d’erreur retenu, de la répartition des groupes et de la méthode d’analyse. Le type de métrique, les répétitions par unité et les dépendances éventuelles comptent également. Utilisez une méthode adaptée à la comparaison de deux groupes et faites relire les hypothèses ; un calcul pour une seule proportion ne peut pas être transféré tel quel.

Le taux initial doit provenir d’une mesure vérifiée dans une population comparable. S’il manque, commencez par une collecte de référence utile. Un zéro observé sur quelques visites ne décrit pas nécessairement le taux habituel.

L’effet minimum utile correspond à une différence qui pourrait changer la décision au regard du coût, du risque et de l’enjeu commercial. La capacité à détecter une différence minuscule n’est pas automatiquement un objectif pertinent.

La puissance décrit la capacité du plan à détecter un effet de la taille envisagée selon ses hypothèses. Le seuil d’erreur encadre un risque statistique dans la procédure choisie. Aucun de ces paramètres ne garantit qu’un résultat sera utile ni qu’un test donnera un vainqueur.

Distinguer points de pourcentage et hausse relative

Illustration arithmétique fictive : passer d’un taux de 2 % à 2,4 % correspond à une différence de 0,4 point de pourcentage. La hausse relative est de (2,4 − 2) ÷ 2 = 20 %. Ces deux présentations décrivent le même écart, avec des dénominateurs différents. Ce n’est ni un résultat client ni une taille d’effet recommandée.

Écrivez les deux valeurs lorsque vous discutez d’un effet attendu. « Gagner 20 % » sans taux de départ peut donner une impression très différente du nombre de demandes supplémentaires réellement envisageable.

Vérifier que le calendrier est compatible avec la décision

À partir du nombre d’unités nécessaire, estimez le rythme d’entrée réellement éligible, puis tenez compte de la fenêtre de résultat et du cycle d’activité. Les visites du site entier ne peuvent pas remplir artificiellement l’échantillon d’une page peu fréquentée. Le calendrier doit aussi rester compatible avec les campagnes, les évolutions d’offre et la capacité à maintenir l’expérience.

Si le plan ne peut détecter qu’un effet très important, ou demande une durée pendant laquelle le contexte changera profondément, renoncez au lancement ou reformulez la question. Consignez ce qui permettrait de la rouvrir : mesure plus fiable, population différente réellement pertinente ou changement à plus fort enjeu. Prolonger indéfiniment un test peu informatif n’est pas une stratégie.

Préparer l’expérience et contrôler son fonctionnement

Faire une recette des deux versions

Avant l’exposition, vérifiez référence et variante sur les parcours concernés : affichage, liens, mobile, clavier, erreurs et confirmation du formulaire. Contrôlez la réception et le contenu des demandes. Assurez-vous que la mesure attribue correctement la version, l’entrée dans l’expérience et l’action attendue.

Vérifiez aussi la persistance de l’affectation, l’absence de bascule involontaire entre versions et les effets du chargement du dispositif. Documentez les interactions avec d’autres campagnes ou expériences. Une recette ne remplace pas le suivi pendant le test, mais elle évite de commencer avec un défaut déjà reproductible.

Surveiller la qualité sans sélectionner le premier résultat favorable

Pendant l’expérience, contrôlez les affectations observées par rapport à celles prévues, les erreurs, les données manquantes et la réception. Un déséquilibre inhabituel peut signaler un problème de répartition, de filtrage ou de collecte. Faites-le examiner avant d’interpréter l’effet ; une simple différence de nombres n’est pas automatiquement une anomalie.

Les recommandations de suivi de Microsoft Research distinguent notamment qualité des données, résultat recherché et protections. Elles rappellent aussi que les lectures répétées exigent une méthode adaptée. Leur rythme interne d’expérimentation n’est pas une durée à appliquer à tous les sites.

Écrire les règles d’arrêt avant de lire les résultats

Dans un plan à horizon fixé, définissez à l’avance les conditions de fin et de lecture, puis respectez-les. Arrêter dès qu’un indicateur paraît favorable multiplie les occasions de conclure à tort si la procédure n’en tient pas compte. Un dispositif séquentiel peut autoriser des lectures intermédiaires selon des règles spécifiques ; il doit être choisi et compris avant le test.

Distinguez cette règle d’analyse d’un arrêt opérationnel : formulaire cassé, effet indésirable important ou problème de collecte. Dans ce cas, protégez le parcours, consignez l’incident et expliquez pourquoi les données ne permettent éventuellement plus de répondre à la question initiale. Changer la variante ou les exclusions en cours de route peut nécessiter un nouveau protocole.

Interpréter les résultats et prendre une décision

Commencez la lecture par la validité : groupes, exposition, collecte, fenêtre de résultat et incidents. Présentez ensuite les volumes, le taux de chaque groupe, la différence estimée et son incertitude selon la méthode prévue. Les protections et le coût de mise en œuvre font partie de la décision.

Un effet favorable n’est pas automatiquement une raison de déployer

Comparez l’effet plausible à celui qui justifierait une action. Un écart statistiquement détectable peut être trop faible au regard du coût ou s’accompagner de demandes moins pertinentes. Une estimation favorable avec une forte incertitude peut rester insuffisante pour engager une modification coûteuse.

Un niveau de significativité ne donne pas directement la probabilité que la variante soit la meilleure. Il ne décrit pas non plus le bénéfice commercial. Utilisez les explications de la méthode choisie et évitez de transformer une couleur verte dans un outil en décision automatique.

Un résultat non concluant n’établit pas l’absence d’effet

Si l’incertitude reste compatible avec une baisse et une amélioration utiles à la décision, vous ne disposez pas d’une réponse assez précise. Vous pouvez conserver la référence, décider un changement pour une autre raison documentée ou concevoir une autre recherche. N’affirmez pas que les versions sont équivalentes : démontrer une équivalence demande un plan et des marges adaptés.

Une conclusion négative peut aussi être informative : la variante ne répond pas au problème supposé, dégrade un indicateur important ou ne mérite pas son coût. Archivez alors la question, la version testée et ce que les données permettent réellement de dire.

Éviter de chercher après coup le sous-groupe gagnant

Découper les résultats par de nombreux pays, appareils ou canaux augmente les occasions de trouver un écart fortuit. Prévoyez les segments qui comptent pour la décision ; distinguez les analyses prévues des explorations. Une découverte après coup peut devenir une nouvelle hypothèse, à vérifier avec une méthode adaptée.

Après un déploiement décidé, contrôlez le parcours et la réception. Gardez une trace de la date, du résultat et de la population étudiée. Un effet observé pendant une campagne ne devient pas une vérité permanente pour toutes les audiences.

Choisir un dispositif adapté au site et à l’équipe

Avant de sélectionner un outil, vérifiez les besoins : intégration au site, persistance des groupes, mesure des expositions, événements disponibles, méthode statistique, export des données, gestion des droits, coût et possibilité de retirer le dispositif. Demandez comment sont traités les visites répétées, les retards de conversion et les lectures intermédiaires.

L’outil doit permettre de vérifier le protocole retenu. Il ne remplace ni la recette, ni le rapprochement avec les demandes reçues, ni l’interprétation. Vous pouvez aussi décider que le coût du dispositif dépasse l’apprentissage attendu et commencer par améliorer le parcours de conversion du site à partir de problèmes établis.

Limiter l’impact des variantes sur Google Search

Si le test crée plusieurs URL, la documentation Google sur les tests de site recommande de signaler l’URL d’origine comme canonique sur les variantes. Elle privilégie cette indication à un noindex utilisé pour gérer ces doublons expérimentaux. Si une redirection sert à répartir les visiteurs, elle recommande une redirection temporaire 302 pour ce test, plutôt qu’une redirection permanente 301.

Ne réservez pas un contenu différent à Googlebot dans le but de tromper le moteur. Une fois l’expérience terminée, retirez les URL ou scripts devenus inutiles et contrôlez la version conservée. Ces précautions concernent la mise en œuvre du test ; elles ne garantissent pas un classement ni une absence de variation dans les résultats de recherche.

Exemple pédagogique : comparer deux formulations de CTA

Situation fictive, sans résultats ni cas client : une entreprise de services présente un formulaire de contact projet. Les retours de sa cible indiquent une hésitation sur la nature de la prochaine étape. L’équipe envisage de remplacer « Être recontacté » par « Échanger sur mon projet », sans changer la suite commerciale.

Question : cette formulation aide-t-elle les visiteurs éligibles à aboutir à une demande pertinente ? Référence : libellé actuel. Variante : nouveau libellé. La promesse, les champs, les campagnes et le traitement restent identiques pendant la comparaison.

Population et allocation : identifiants de navigateur éligibles entrant sur la page définie, affectés aléatoirement et de façon persistante selon la proportion fixée. Les règles concernant trafic interne, automatisations et exposition sont documentées avant le lancement.

Indicateur principal : part des unités affectées ayant au moins un envoi confirmé dans la fenêtre prévue. Protections : réception des demandes, erreurs, doublons et qualification selon les critères métier. Les clics servent à comprendre le parcours, sans remplacer l’action principale.

Faisabilité : taux initial vérifié, effet minimum utile, volume nécessaire, rythme d’entrée et fenêtre de résultat restent à renseigner. Tant que ces informations ne permettent pas un plan exploitable, la décision est de ne pas lancer. Une tâche de compréhension peut déjà vérifier ce que chaque formulation fait attendre.

Lecture prévue : examiner qualité des données, estimation et incertitude avec les protections. Déployer seulement si le résultat et les contraintes justifient ce choix ; conserver la référence ou reformuler l’hypothèse si la comparaison reste insuffisante. Aucun gain n’est supposé pour compléter l’exemple.

Fiche de protocole à reprendre dans votre document de travail

1 — Décision : choix à éclairer, responsable et enjeu commercial.

2 — Observation et hypothèse : friction vérifiée, public concerné et effet attendu ; lien vers la preuve initiale.

3 — Versions : contenu exact de la référence et de la variante, éléments conservés et validation fonctionnelle.

4 — Population : critères d’éligibilité, unité de répartition, proportion, persistance et règle d’exposition.

5 — Mesures : indicateur principal, numérateur, dénominateur, source, fenêtre de résultat, protections et contrôle des données.

6 — Dimensionnement : baseline, effet minimum utile, hypothèses statistiques, méthode adaptée, volume et faisabilité du calendrier.

7 — Suivi : recette, alertes, incidents, lectures autorisées, critères de fin et procédure d’arrêt opérationnel.

8 — Décision finale : estimation, incertitude, protections, coût, choix retenu et questions encore ouvertes. Prévoyez aussi le retrait du dispositif et le contrôle après modification.

Cette fiche peut aboutir à « lancer », « corriger d’abord », « chercher autrement » ou « attendre ». Sa valeur est de rendre ce choix explicite et vérifiable, même lorsque le trafic ne permet pas une expérience utile.