A/B tester une landing page statique en Next.js : split URL, edge et feature flags

Une landing page statique en Next.js est construite pour une seule chose : s'afficher le plus vite possible, sans travail supplémentaire du navigateur. C'est exactement ce que cassent la plupart des outils d'A/B testing visuels grand public (Optimizely, VWO, l'ex-Google Optimize) : ils chargent la page originale, puis réécrivent le DOM en JavaScript une fois arrivés côté client pour afficher la variante. Le visiteur voit une fraction de seconde de clignotement — la version A avant la version B — et chaque réécriture du DOM après le rendu initial dégrade le score CLS. Sur un site pensé pour la performance, c'est contre-productif. Voici trois méthodes qui évitent ce problème, et comment choisir selon vos moyens techniques.

Pourquoi les outils visuels classiques posent problème sur une page statique

Les outils d'A/B testing « no-code » ont été conçus pour des sites générés dynamiquement côté serveur (WordPress, Shopify), où modifier le HTML avant l'envoi au navigateur est complexe. Injecter un script qui réécrit la page après coup était la solution la plus simple à intégrer partout. Sur une page statique pré-générée (generateStaticParams), ce choix devient un handicap : vous perdez d'un côté ce que vous avez optimisé de l'autre. Nous détaillons ce mécanisme de décalage visuel dans notre article sur le Core Web Vitals CLS, et l'impact global de la vitesse sur la conversion dans notre guide sur la vitesse de chargement.

Trois méthodes pour A/B tester une landing page statique

1. Le split URL testing : deux pages, une redirection à l'edge

C'est la méthode la plus fiable pour une page statique : vous construisez deux versions complètes (/offre et /offre-b), et un middleware exécuté à l'edge (Vercel Edge Middleware, Cloudflare Workers) redirige chaque nouveau visiteur vers l'une ou l'autre selon un cookie posé à la première visite, pour qu'il voie toujours la même version. Aucune réécriture côté client : chaque variante est servie déjà finalisée, avec ses propres Core Web Vitals natifs. La contrepartie : deux pages à maintenir en parallèle et une attention SEO particulière, à traiter comme lors d'une refonte sans perdre son référencement — noindex sur la variante perdante, canonical vers la version gagnante une fois le test terminé.

1. Dupliquez la page dans un nouveau dossier de route (/offre-b) et modifiez uniquement l'élément testé — un seul changement à la fois pour pouvoir attribuer l'effet avec certitude.
2. Écrivez un middleware qui lit un cookie existant ou, à défaut, tire une variante au hasard et pose ce cookie pour la durée du test (30 jours suffisent dans la plupart des cas).
3. Redirigez silencieusement (rewrite, pas redirect visible) les visiteurs affectés à la variante B depuis l'URL d'origine, pour garder une seule URL partagée en publicité.
4. Envoyez la variante vue dans un paramètre personnalisé à votre outil d'analytics, pour pouvoir comparer les taux de conversion par groupe une fois le test terminé.

2. Les feature flags à l'edge : une seule page, deux rendus

Plus proche de l'esprit React Server Components de Next.js : un service de feature flags (Vercel Edge Config, GrowthBook, Statsig) détermine la variante d'un visiteur au moment de la requête, avant que le HTML ne soit généré ou servi depuis le cache. Le composant serveur lit le flag et rend directement la bonne version du hero, du prix ou du CTA — sans JavaScript client, sans clignotement. C'est la méthode la plus élégante pour tester un seul élément (un titre, une couleur de bouton) sans dupliquer toute la page, mais elle demande de coder les deux variantes dans le composant plutôt que de les piloter depuis une interface visuelle.

3. Les outils visuels classiques : un compromis parfois acceptable

Le clignotement n'est pas toujours rédhibitoire. Sur un test rapide, à faible trafic, ou sur une section basse de page peu visible au chargement initial, l'effet reste marginal et l'outil visuel reste imbattable en simplicité pour une équipe non technique. Réservez cette option aux tests exploratoires et repassez en split URL ou feature flag dès qu'un test touche le hero ou dépasse quelques semaines en production.

Le piège invisible : le sample ratio mismatch

Quelle que soit la méthode choisie, un danger plus sournois guette : le déséquilibre involontaire du partage de trafic. Dans leur étude de référence publiée en 2012 à la conférence KDD, Ron Kohavi et ses coauteurs (Microsoft) documentent ce phénomène sous le nom de sample ratio mismatch — un partage 50/50 programmé qui se retrouve, en pratique, à 47/53 à cause du cache CDN, des robots d'indexation mal filtrés ou d'une redirection plus lente pour une variante que pour l'autre (étude sur Google Scholar). Un tel déséquilibre invalide silencieusement les résultats du test, sans qu'aucune alerte ne se déclenche. Sur une architecture edge comme Vercel, vérifiez concrètement la répartition réelle du trafic dans vos analytics après quelques jours, avant de faire confiance aux chiffres de conversion.

Garder une méthodologie rigoureuse

Le choix de l'infrastructure technique ne remplace pas la rigueur de l'expérimentation elle-même. Dans leur guide fondateur sur les expérimentations contrôlées en ligne, Kohavi, Longbotham, Sommerfield et Henne rappellent que la valeur d'un A/B test tient à sa méthodologie — hypothèse claire, échantillon suffisant, durée respectée — bien plus qu'à l'outil utilisé pour l'exécuter (étude sur Google Scholar). Avant de choisir votre méthode d'implémentation, assurez-vous d'avoir dimensionné le test correctement : notre guide complet de l'A/B testing couvre les bases, et nos articles sur la durée d'un test et la signification statistique évitent d'arrêter un test trop tôt sur un simple coup de chance.

Le cas particulier des templates LanderKit

Chaque template LanderKit est livré comme un mini-projet Next.js autonome, ce qui simplifie justement le split URL testing : dupliquer le dossier du template pour créer une variante B ne casse rien côté architecture, puisque chaque projet est déjà indépendant. C'est une bonne manière de tester deux angles de vente (un titre orienté résultat contre un titre orienté méthode, par exemple) sans mettre en péril votre page en production. Pour la mise en ligne des deux versions, notre guide sur le déploiement Next.js sur Vercel détaille la marche à suivre, y compris pour deux déploiements distincts derrière un même nom de domaine.