Test A/B sur un site : définir une hypothèse et une règle de décision

8 min de lecture

Un test A/B sur un site web compare des variantes dans un dispositif préparé, avec une hypothèse, une répartition des visiteurs et une règle d’analyse définies avant l’essai. Il ne consiste pas à changer une page, attendre une hausse puis attribuer celle-ci au nouveau texte. Commencez par un problème documenté, choisissez une modification interprétable et vérifiez la mesure du résultat. Préparez aussi les critères d’arrêt technique et les limites statistiques avec une personne compétente. Si le trafic ou la collecte ne permet pas une conclusion fiable, préférez un test qualitatif ou une correction évidente plutôt qu’un faux verdict expérimental.

À retenir : une variante n’est pas encore une expérience

Le résultat peut varier avec le canal, le moment ou le profil des visiteurs. Le NIST explique que des facteurs secondaires peuvent affecter la mesure et doivent être identifiés, contrôlés ou pris en compte dans la conception expérimentale.^[29] Votre comparaison doit traiter ce problème, pas seulement produire deux versions visuellement différentes.

Formuler l’hypothèse de votre test A/B de site web

Décrivez le problème constaté : une condition d’offre introuvable, une action ambiguë ou un formulaire difficile à comprendre. Appuyez-vous sur des observations disponibles, sans inventer un motif de départ. « Le bouton ne convertit pas » reste trop vague si vous ne savez pas quelle étape échoue.

Écrivez une hypothèse reliant modification et résultat : rendre la condition de service plus visible pourrait aider les visiteurs concernés à soumettre une demande valide. Le mot « pourrait » reflète l’incertitude que le test cherche à examiner. Ne transformez pas cette hypothèse en promesse de hausse.

Choisissez une variation dont le sens est interprétable. Si vous changez simultanément titre, prix, formulaire et visuels, une différence de résultat ne permet pas d’identifier l’élément responsable. Un ensemble de changements cohérent peut se tester comme une offre complète, mais vous devez alors annoncer cette portée et renoncer à attribuer le résultat à un détail isolé.

Définir résultat principal et garde-fous

Le résultat principal doit correspondre à une action validée : demande acceptée, commande ou autre événement précisément défini. Une progression comme le clic principal peut aider au diagnostic, mais ne démontre pas automatiquement la réussite du parcours. Vérifiez l’événement dans le système final.

Ajoutez des garde-fous métier et techniques. Une variante ne doit pas augmenter les erreurs de formulaire, dégrader l’accès à l’information ou produire des demandes hors offre pour améliorer une métrique superficielle. Le W3C recommande des instructions, des validations et des notifications permettant de comprendre et corriger les erreurs des formulaires.^[33]

Le guide de landing page de 4SYSTEM aide à vérifier la cohérence entre promesse et action. Cette cohérence doit rester vraie dans toutes les variantes. Une version qui supprime une condition essentielle ne constitue pas une optimisation acceptable, même si davantage de visiteurs cliquent.

Préparer l’affectation et les facteurs parasites

La comparaison doit répartir les unités selon une règle conçue pour la question et maintenir une exposition cohérente. Examinez la persistance de la variante pour une personne ou une session, selon votre dispositif. Une alternance involontaire entre les versions peut rendre le résultat difficile à interpréter.

Le NIST résume son principe expérimental par la maîtrise des facteurs contrôlables et la randomisation des autres ; il décrit aussi le blocage pour certains facteurs parasites.^[29] Ce guide n’est pas un mode d’emploi prêt à l’emploi pour tout site. Il fournit une base pour concevoir une comparaison qui ne confond pas variante et composition des populations.

Documentez les sources de contamination : changements de campagne, visiteurs internes, reprise d’une session, cache ou intégration externe. Une version montrée surtout sur mobile et l’autre surtout sur ordinateur ne crée pas une comparaison propre par le simple affichage de deux taux. Faites vérifier le dispositif avant d’exposer de vrais visiteurs.

Écrire le protocole avant le lancement

Définissez l’unité, le résultat principal, les exclusions, le mode d’affectation et la règle d’analyse. Faites estimer les besoins de données à partir du niveau observé, de l’effet que vous cherchez à détecter et de la méthode choisie. Aucun nombre universel de visites ou de jours n’est proposé ici.

Prévoyez une issue « inconclusif ». L’absence de preuve de différence ne démontre pas l’équivalence des versions. Un échantillon insuffisant, une collecte interrompue ou un effet trop incertain doit rester décrit comme tel. Cette issue est un résultat honnête du dispositif, pas un échec à masquer.

Distinguez l’arrêt d’urgence et la fin d’analyse. Une erreur fonctionnelle ou une exposition inappropriée peut justifier l’arrêt immédiat selon vos critères. En revanche, arrêter dès qu’un graphique paraît favorable peut rendre l’interprétation trompeuse si la méthode n’a pas prévu cet examen. Écrivez la règle avant de voir les résultats.

Fiche de protocole à partager

Un protocole rempli permet de distinguer l’expérience réelle d’une démonstration graphique. Gardez les versions de page et les réglages correspondant au test : sans ces éléments, le résultat ne peut pas être rattaché à un changement précis.

Recette technique et cadre de collecte

Testez les versions sur les appareils pertinents, au clavier et dans les parcours d’erreur. Vérifiez la répartition, le maintien de la variante et le déclenchement du résultat. Une page qui apparaît correctement peut encore envoyer un événement différent selon la version.

Examinez les traceurs utilisés pour affecter ou mesurer les visiteurs. La CNIL rappelle le principe de consentement préalable pour certains dépôts et lectures de traceurs, avec des exceptions encadrées.^[31] Un outil présenté comme « A/B testing » ne dispense pas d’analyser son fonctionnement et ses finalités.

Préparez le retrait des modifications. Une pause du test doit laisser un site fonctionnel et ne pas conserver des scripts inutiles. Documentez les accès, la version de retour et le contrôle après arrêt. Le protocole expérimental et la sécurité du site doivent être traités ensemble.

Exemple fictif : rendre une condition B2B visible

Une entreprise imaginaire reçoit des demandes hors zone d’intervention. Elle suppose que la condition géographique est difficile à repérer sur une page d’offre. Elle prépare une variante qui présente cette condition près de l’action principale, sans changer l’offre ni ajouter une fausse promesse.

Dans le scénario illustratif, l’équipe choisit les demandes valides selon sa définition comme résultat principal et surveille les demandes hors périmètre ainsi que les erreurs du formulaire. Elle fait vérifier l’affectation et la méthode d’analyse avant lancement. Le nombre de clics reste un signal secondaire.

Si la variante attire moins de clics mais des demandes mieux adaptées, la décision doit suivre les critères prévus, pas un objectif de clics ajouté après coup. Si les données sont insuffisantes, le test reste inconclusif. Aucun chiffre, niveau de confiance ou gain client n’est inventé ; l’exemple montre seulement la logique du protocole.

Lire le résultat et décider sans récit opportuniste

Conservez les volumes, les exclusions, les incidents et les limites de la méthode. Recherchez les différences d’exposition et les ruptures de collecte avant de choisir une version. Un résultat favorable n’autorise pas à ignorer un garde-fou dégradé.

Préparez trois décisions possibles : adopter selon les critères, conserver le dispositif précédent ou conclure que l’essai ne permet pas de trancher. Si vous déployez une version, vérifiez le fonctionnement après arrêt du test. Les paramètres expérimentaux, caches et scripts peuvent différer de la version finale.

Sur un site à faible trafic, une observation qualitative, une recette d’accessibilité ou une clarification de contenu peut être plus utile qu’un long test sans puissance adaptée. Ne transformez pas une erreur évidente en expérience pour retarder sa correction. Le test sert une incertitude réelle et une décision réalisable.

Questions fréquentes

Combien de temps doit durer un test ?

La durée dépend des besoins de données, du trafic, de la variabilité et de la méthode d’analyse. Faites définir ces éléments avant le lancement, avec une règle de fin explicite. Aucun délai universel ne prouve la fiabilité. Une période écoulée n’efface pas une affectation défectueuse ou une collecte incohérente entre les variantes.

Peut-on tester seulement un bouton ?

Oui, si vous avez une hypothèse sur sa compréhension ou son rôle et un résultat correctement mesuré. Vérifiez cependant que les versions restent cohérentes avec l’offre et accessibles. Un changement de couleur sans problème identifié peut produire une comparaison difficile à interpréter et détourner l’attention d’un obstacle plus concret du parcours.

Que faire si les résultats restent proches ?

Appliquez la méthode et la règle prévues, puis conservez l’incertitude lorsque les données ne permettent pas de trancher. Ne choisissez pas après coup une autre métrique pour fabriquer un gagnant. Vous pouvez examiner les limites du dispositif et préparer un test différent, mais il doit partir d’une nouvelle hypothèse clairement annoncée.

Prochaine étape : valider le protocole

Préparez une hypothèse, une fiche complète et des variantes fonctionnelles avant toute exposition. Les services de 4SYSTEM peuvent aider à cadrer le parcours et la mesure. Faites qualifier l’analyse statistique selon votre question ; aucun bouton « lancer le test » ne garantit une conclusion exploitable.

Sources

• 5.3.3.2. Randomized block designs (consulté le 2026-10-08)
• Cookies et traceurs : que dit la loi ? | CNIL (consulté le 2026-10-08)
• Forms Tutorial | Web Accessibility Initiative (WAI) | W3C (consulté le 2026-10-08)