A/B tester deux landing pages avec des liens de campagne : le guide développeur

Dans le cycle de vie d'un produit SaaS ou d'une application web, concevoir une architecture irréprochable ne suffit pas si l'interface ne convertit pas ses visiteurs. Pour valider une refonte, tester un nouvel angle marketing ou optimiser un appel à l'action (CTA), l'A/B testing est l'approche empirique par excellence. Cependant, l'intégration d'outils tiers côté client engendre souvent des problèmes de performance, des scintillements d'écran (flicker effect) et dégrade l'expérience utilisateur.

Une alternative élégante et légère consiste à exploiter des liens de campagne couplés à une logique de routage côté serveur ou à l'Edge. Voici comment mettre en place une telle architecture.

1. Le concept : distribuer le trafic à la source

Plutôt que de modifier le DOM dans le navigateur avec un script JavaScript lourd, la méthode repose sur un lien de campagne unique (par exemple partagé sur vos réseaux, vos newsletters ou vos annonces payantes) qui redirige dynamiquement les utilisateurs vers l'une des deux variantes :

• Variante A (Contrôle) : /landing-a ou URL canonique /
• Variante B (Challenger) : /landing-b

Ce lien d'entrée contient généralement des balises UTM précises (comme utm_campaign=launch_v2) permettant d'attribuer chaque conversion dans vos outils d'analytique.

2. L'orchestration technique : Edge Middleware ou Reverse Proxy

Pour distribuer les requêtes de manière équitable sans impacter le temps de chargement, la meilleure approche moderne consiste à intercepter la requête au niveau de l'Edge (via Cloudflare Workers, Vercel Middleware ou un reverse proxy Nginx).

Le mécanisme suit une logique simple :

• Vérification du visiteur : Le middleware inspecte la présence d'un cookie (ex. ab_bucket=A). Si le cookie existe, le visiteur est dirigé en toute transparence vers sa variante d'origine pour préserver la cohérence de navigation.
• Attribution aléatoire : En l'absence de cookie, une fonction pseudo-aléatoire (50/50) attribue une variante au nouvel entrant.
• Persistance et réécriture : Le serveur renvoie un en-tête Set-Cookie et réécrit l'URL (rewrite interne) sans redirection visible côté client si possible, ou effectue une redirection HTTP 307 temporaire.

3. Préserver le SEO et la performance

L'exécution de tests fractionnés via des URL distinctes nécessite quelques précautions techniques :

• Balise canonique unifiée : Indiquez toujours sur la variante B une balise <link rel="canonical" href="https://votredomaine.com/landing-a" /> pour éviter les pénalités pour contenu dupliqué.
• Zéro layout shift : En gérant la séparation en amont du rendu navigateur, vous éliminez tout décalage de mise en page (CLS) lié au chargement d'un script tiers.
• Propagation des paramètres UTM : Veillez à ce que votre script de routage transmette scrupuleusement l'ensemble des paramètres de tracking vers la page de destination finale.

4. Mesure et prise de décision

La dernière étape réside dans la remontée des données. À l'aide de custom events dans votre outil d'analytics (PostHog, Plausible ou Google Analytics), associez l'identifiant de la variante à chaque conversion : soumission de formulaire, clic sur un bouton d'inscription ou temps passé sur la page.

En tant que développeur full-stack, intégrer cette mécanique directement dans l'infrastructure applicative permet d'allier rigueur scientifique et respect des standards web, offrant des résultats fiables tout en conservant une réactivité maximale.