Comment tester la conversion d'une landing sans s'auto-mentir
Mesurer correctement la conversion demande méthode, patience et honnêteté statistique. Voici comment éviter les biais et les fausses victoires.
- Type
- Guide
- Lecture
- 10 min
- Étapes
- 7
- Mis à jour
- mai 2026
Les 7 étapes
- 01
Définir un seul goal de conversion principal
Avant de tester, définissez UN goal principal mesurable. Pas trois. Le goal doit être une action utilisateur claire : soumission formulaire d'essai, clic sur CTA primaire, scroll 75 % de la page, achat complété. Si vous trackez 12 goals, vous diluez votre attention et confondez les signaux. Le goal principal détermine ce que vous optimisez. Goals secondaires (tracking nice-to-have) sont OK mais ne pilotent pas les décisions. Pour une landing SaaS : "trial signup" est typique. Pour un site e-commerce : "ajout au panier" puis "achat". Pour un site service : "demande de contact" ou "réservation".
TipLe goal doit être atteignable. Pour une landing SaaS new, 50-200 conversions/mois est typique. Si votre goal est "achat enterprise 50k€", vous aurez 1-2 conversions/mois et ne pourrez rien tester.
- 02
Installer le tracking correctement
Installez un seul outil analytics (Plausible, Fathom, GA4) avec le goal de conversion configuré. Vérifiez : event de conversion fire bien au bon moment (DevTools > Network), pas de double-counting (un seul script), respect RGPD (Plausible/Fathom sont sans cookies). Ajoutez une heatmap (Hotjar plan gratuit) sur la landing principale. Pour les pages avec formulaire : trackez les abandons par champ (event sur blur sans submit). Pour les CTA : trackez clic + landing post-clic (taux de complétion). Sans tracking propre, toutes les optimisations sont des opinions.
TipVérifiez vos events 24-48h après installation : faites quelques conversions test et regardez si elles remontent en analytics avec les bonnes métadonnées (source, device, page).
- 03
Mesurer la baseline pendant 2 semaines
Avant d'optimiser, mesurez la baseline sur 14 jours (minimum) ou 1000 visites (minimum), le plus long des deux. Cette baseline vous donne : taux de conversion par source de trafic, taux de bounce par section, durée moyenne, top 3 sources, performance par device. Sans baseline, vous ne saurez pas si une amélioration vient de votre changement ou de la variation naturelle. Une variation de ±20 % entre deux semaines est normale en faible trafic. Au-delà de 2 semaines, vous capturez les patterns weekly (lundi-vendredi différent de samedi-dimanche).
TipExcluez les pics anormaux de la baseline (un tweet viral, une mention presse) — ils donnent une fausse moyenne. Notez-les mais ne les comptez pas dans la baseline normale.
- 04
Identifier le frein principal via heatmaps
Avant d'A/B tester, identifiez le frein qualitativement. Heatmaps Hotjar : où les visiteurs cliquent (souvent sur des éléments non cliquables = problème UX), où ils décrochent (scroll dropoff = section ennuyeuse ou confuse), où ils hésitent (rage clicks = bug ou frustration). 30-50 sessions enregistrées suffisent pour identifier les patterns. Notez les hypothèses : "Le CTA hero n'est pas vu" (heatmap froide dessus), "La FAQ n'est pas atteinte" (75 % décrochent avant), "Les visiteurs essaient de cliquer sur les logos clients" (fausse interactivité). Chaque hypothèse devient un test A/B potentiel.
TipRegardez les sessions en entier (pas juste les heatmaps agrégées). Vous verrez des comportements précis : hésitation, scroll de retour, abandon formulaire. C'est 10x plus informatif que les chiffres.
- 05
Calculer la taille d'échantillon nécessaire
Avant d'A/B tester, calculez la sample size requise pour détecter une amélioration significative. Outils : Optimizely calculator, AB Tasty calculator, Evan Miller calculator. Inputs : taux de conversion baseline, amélioration minimum détectable (MDE, typiquement +10-20 %), significance (95 %), power (80 %). Exemple : baseline 3 %, MDE +20 % → besoin de ~5000 visites par variante, soit 10 000 visites total. Si vous avez 1000 visites/semaine, le test prend 10 semaines. Plus court = moins fiable. Plus la baseline est haute, moins il faut de visites.
TipNe déclarez pas vainqueur avant d'atteindre la sample size calculée. Le "peeking" (regarder les résultats en cours) augmente le risque de faux positif. Patience > précipitation.
- 06
Lancer un test A/B avec une variable
Une variable changée par test, jamais plus. Variables à prioriser : hero title (impact gros), CTA label, structure de prix, présence preuve sociale. Outils : Optimizely (cher mais robuste), AB Tasty (français, mid-market), Posthog (open source, gratuit jusqu'à 1M events/mois), Vercel A/B testing (gratuit, basé edge). Configurez : split 50/50, durée minimum calculée, goal de conversion identique, exclusion bots. Pendant le test : ne touchez à RIEN d'autre (ad campaigns, autre page) pour ne pas contaminer.
TipTest A/B sur la PAGE entière, pas sur des micro-éléments. Tester la couleur d'un bouton vs un hero entièrement réécrit donne des amplitudes très différentes. Préférez les gros tests.
- 07
Interpréter les résultats honnêtement
À la fin du test, l'outil donne une significance statistique (%). 95 % = test concluant, < 90 % = inconcluant. Si concluant : analysez la différence (+10 % = bon, +50 % = soupçonneux, vérifiez les segments), implémentez la winner. Si inconcluant : ne déclarez pas un faux winner, refaites le test avec une variable différente. Erreurs classiques : déclarer un winner à 80 % de significance (1 chance sur 5 que ce soit du bruit), tester 10 variables et garder celle qui "marche" (multiple comparisons → faux positif inévitable). L'honnêteté statistique économise des mois d'optimisation dans le mauvais sens.
TipDocumentez chaque test : hypothèse, variable changée, résultat, decision. Tenez un test log. En 6 mois, vous aurez un patrimoine d'apprentissage incomparable.
Les biais qui ruinent un test
Plusieurs biais ruinent les tests sans qu'on s'en aperçoive. Biais de small sample : déclarer un winner sur 50 conversions par variante — pure chance statistique. Biais de durée trop courte : un test sur 3 jours capture une seule fenêtre weekly (lundi-mercredi peut très différer de samedi-dimanche). Biais de peeking : regarder le résultat tous les jours et s'arrêter quand "ça a l'air bien" — augmente le faux positif de 30 %. Biais de multiple comparisons : tester 10 variables et "garder celle qui marche" — 1 sur 20 sera positif par hasard à 95 % de significance.
La solution : calculer la sample size AVANT, fixer la durée AVANT, ne regarder qu'à la fin, ne tester qu'une variable à la fois. Discipline > précipitation.
Tests qualitatifs : 5 sessions valent 1000 visites
Les tests A/B sont quantitatifs et lents. Les tests qualitatifs sont rapides et révélateurs. 5 sessions de test utilisateur (User Testing, Maze, ou Zoom + partage écran) prennent 1 jour et révèlent 70 % des problèmes UX. Vous voyez : où les visiteurs hésitent, ce qu'ils ne comprennent pas, ce qui les fait décrocher. Aucun A/B test ne révèle "le sous-titre est ambigu" — un test qualitatif l'identifie en 30 secondes.
Protocole : recrutez 5 personnes proches de votre cible (LinkedIn, Twitter, ou User Interviews). Demandez-leur d'accomplir une tâche ("Trouvez le pricing", "Inscrivez-vous à l'essai"). Observez en silence. Demandez "qu'avez-vous compris" en fin. 1 heure de tests = 10 hypothèses à A/B tester ensuite.
Quand A/B tester n'a pas de sens
A/B testing demande du trafic. Si vous avez moins de 1000 visites/semaine, oubliez les A/B et concentrez-vous sur : qualité copy (relecture, simplification), qualité design (cohérence, hiérarchie), tests qualitatifs (5 sessions/mois), itération basée sur feedback client. À 100 visites/semaine, un A/B prend 6+ mois et reste inconcluant.
À ce stade, les "best practices" valent mieux que les tests sur faible trafic. Suivez les patterns éprouvés (structure de landing classique, hero clair, friction minimale), récoltez du feedback qualitatif intensif, attendez d'avoir le trafic pour A/B tester. L'A/B testing est un outil d'optimisation marginale, pas un outil de validation produit.
Pièges à éviter
- A/B tester avec moins de 1000 visites/semaine — pure perte de temps, résultats non concluants.
- Peeking quotidien sur un test en cours — augmente le faux positif de 30 %, attendez la fin.
- Tester 5 variables à la fois (multi-variate) sans 10 000+ visites — vous obtenez du bruit.
- Déclarer un winner à 80 % de significance — 1 chance sur 5 que ce soit du hasard.
- Skipper les tests qualitatifs — vous A/B testez de mauvaises hypothèses pendant des mois.
- Pas de baseline mesurée — vous ne savez pas si une amélioration vient de votre changement ou du bruit.
- Changer 3 choses pendant un A/B test en cours — contamination, résultat inutilisable.
Questions fréquentes
Appliquer ce guide avec Eufya
Si ce guide vous a aidé : 3 crédits gratuits à l'inscription. Le pipeline Eufya applique ces principes automatiquement, Hero Lab + section plan + quality gates.