Déployer sa landing page Next.js sur Vercel : le guide pas à pas

Vous avez acheté un template et suivi le raisonnement Next.js plutôt que WordPress : bonne nouvelle, la partie la plus dure est faite. Il reste une étape que beaucoup de non-développeurs redoutent sans raison — mettre le projet en ligne. Avec Vercel (la plateforme créée par les auteurs de Next.js), c’est en réalité la partie la plus rapide : dix minutes, zéro carte bancaire, et une landing page accessible au monde entier. Voici la marche à suivre, du dossier téléchargé jusqu’au domaine personnalisé qui pointe dessus.

Pourquoi Vercel plutôt qu’un hébergeur classique

Un hébergement mutualisé classique fait tourner votre page depuis un seul serveur, quelque part dans un pays donné : un visiteur situé loin de ce serveur attend plus longtemps que les autres. Vercel fonctionne à l’inverse — votre landing page statique est répliquée sur un réseau mondial de points de présence (« edge »), et chaque visiteur reçoit la page depuis le nœud le plus proche de chez lui. C’est exactement le sujet qu’étudie une recherche récente sur la latence des centres de données en périphérie de réseau : rapprocher le calcul de l’utilisateur réduit mesurablement les temps de réponse par rapport aux régions cloud traditionnelles, avec des gains de l’ordre de 15 à 19 % selon la position de l’utilisateur (Martin & Dogar, 2023). Pour une page dont chaque seconde de chargement coûte des conversions, ce n’est pas un détail d’infrastructure : c’est un avantage direct, obtenu sans configuration particulière.

L’autre différence tient au modèle : pas de FTP, pas de panneau d’administration à sécuriser, pas de base de données à sauvegarder. Vercel déploie directement depuis un dépôt Git — chaque mise à jour du code devient une mise en ligne en quelques secondes. Le plan gratuit (« Hobby ») suffit largement pour une landing page de vente : bande passante généreuse, certificat HTTPS automatique, domaine personnalisé inclus.

Ce qu’il vous faut avant de commencer

• Le dossier du template téléchargé après achat (un mini-projet Next.js autonome, avec son propre package.json).
• Un compte GitHub gratuit — c’est le pont entre votre code et Vercel.
• Un compte Vercel gratuit (inscription possible directement « Continue with GitHub », sans mot de passe supplémentaire).
• Facultatif à ce stade : un nom de domaine, si vous ne voulez pas rester sur l’adresse fournie par défaut (votre-projet.vercel.app).

Le guide pas à pas : du dossier téléchargé à la page en ligne

1. Créer un dépôt Git pour le projet

Sur GitHub, créez un nouveau dépôt (privé de préférence, tant que la page n’est pas prête à être montrée). Depuis le dossier du template en local, initialisez Git et poussez le code : git init, git add ., git commit -m "Premier import", puis git remote add origin <url-du-dépôt> et git push -u origin main. Si vous n’êtes pas à l’aise avec la ligne de commande, GitHub Desktop propose le même résultat en glisser-déposer.

2. Importer le projet dans Vercel

Depuis le tableau de bord Vercel, cliquez sur « Add New… → Project », puis sélectionnez le dépôt que vous venez de pousser. Vercel détecte automatiquement qu’il s’agit d’un projet Next.js et pré-remplit la configuration de build — dans la grande majorité des cas, vous n’avez rien à modifier. Laissez les champs par défaut et cliquez sur « Deploy ».

3. Premier déploiement et prévisualisation

Le build tourne en général entre 30 secondes et 2 minutes. À la fin, Vercel affiche une URL de type votre-projet.vercel.app avec un aperçu cliquable : votre landing page est déjà en ligne, publiquement accessible, avec HTTPS activé par défaut. C’est le moment de tester le rendu mobile et desktop, et de vérifier que chaque section s’affiche correctement.

4. Personnaliser avant de partager le lien

Le README livré avec chaque template LanderKit détaille comment modifier les textes, les couleurs et les images depuis les fichiers de components/. Les formulaires sont volontairement livrés en mailto: ou en état factice « Merci ! » — à vous de les brancher sur votre outil (Brevo, Tally, Google Forms…) avant la mise en ligne définitive. Chaque modification poussée sur GitHub redéclenche automatiquement un nouveau déploiement.

5. Brancher un nom de domaine personnalisé

Dans les réglages du projet Vercel, l’onglet « Domains » permet d’ajouter un domaine ou un sous-domaine : Vercel indique les deux enregistrements DNS à créer chez votre registrar (un A ou CNAME, plus souvent une redirection automatique de www). La propagation prend de quelques minutes à 24 heures selon le registrar. Le choix entre domaine dédié et sous-domaine dépend de votre stratégie globale — nous détaillons les deux options dans notre comparatif sous-domaine ou domaine dédié.

6. Déploiements automatiques et prévisualisations par branche

Une fois le dépôt connecté, chaque git push sur la branche principale republie automatiquement la page en production — sans FTP, sans clic manuel. Et chaque branche ou pull request annexe génère sa propre URL de prévisualisation, isolée de la production : vous pouvez tester une nouvelle accroche ou un nouveau visuel sans risquer de casser la page en ligne. Ce n’est pas qu’un confort de développeur : une étude portant sur les pratiques de livraison continue montre que les organisations qui déploient fréquemment et automatiquement, par petits changements réversibles, obtiennent de meilleurs résultats opérationnels que celles qui procèdent par mises en production rares et volumineuses (Forsgren & Humble, 2016). Pour une landing page qu’on ajuste régulièrement au fil des tests, ce filet de sécurité change concrètement la façon d’itérer.

Les erreurs qui font échouer un déploiement

• Tester le build en local avant de pousser : lancez npm run build sur votre machine avant chaque déploiement important — une erreur TypeScript ou un import cassé s’y révèle en quelques secondes, plutôt qu’après un aller-retour vers Vercel.
• Dépôt public trop tôt : si la page n’est pas prête à être vue, gardez le dépôt GitHub privé (gratuit) — Vercel s’y connecte sans problème.
• DNS mal recopié : une valeur DNS copiée avec un espace ou un point final en trop suffit à bloquer la propagation ; recopiez exactement ce qu’affiche Vercel, sans rien ajouter.
• Confondre l’URL de prévisualisation et le domaine final : tant qu’aucun domaine personnalisé n’est branché, l’URL .vercel.app fonctionne parfaitement mais n’est pas destinée à être diffusée en publicité — configurez le domaine avant de lancer vos campagnes.

Après la mise en ligne : la checklist des 24 premières heures

• Passer la page au test PageSpeed Insights pour confirmer des Core Web Vitals au vert.
• Déclarer le domaine dans Google Search Console et soumettre le sitemap.
• Brancher le suivi des conversions dans GA4 avant d’envoyer le moindre visiteur payant.
• Remplir un vrai formulaire de bout en bout pour vérifier que la notification ou l’e-mail de confirmation arrive bien.

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

Les outils d'A/B testing visuels classiques réécrivent la page après son chargement — un problème sur une landing page statique optimisée pour la vitesse. Voici trois méthodes qui préservent vos Core Web Vitals : split URL, feature flags à l'edge, et quand accepter le compromis d'un outil visuel.

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

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é.

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 (voir l'étude). 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.

De Figma à une landing page Next.js : ce qui se perd toujours dans la traduction

Une maquette validée en réunion, puis une landing page livrée qui n'a plus tout à fait le même rendu : espacements resserrés, police de secours qui s'affiche une seconde de trop, bouton qui ne réagit pas comme sur le prototype. Ce n'est pas un accident isolé — c'est un écart mesuré dans la recherche sur le travail de conception, et il existe des façons concrètes de le réduire.

Une étude de K. J. Kevin Feng, Tony W. Li et Amy X. Zhang, présentée en 2023 à la conférence CHI — la plus grande conférence de recherche en interaction homme-machine — et consacrée aux pratiques collaboratives des designers d'interface en entreprise, documente ce que les auteurs appellent la divergence design-développement : la maquette et le produit livré s'écartent l'un de l’autre au fil du projet, parce que le raisonnement derrière chaque choix visuel (pourquoi cet espacement, pourquoi cette police de secours) ne survit pas au passage de l'outil de design à l'éditeur de code. L'information visuelle traverse la maquette ; l'intention qui l'a produite, elle, se perd souvent en route.

Ce qu'une maquette Figma ne montre jamais

• Le comportement responsive entre les points de rupture. Figma affiche un état par largeur d'écran (mobile, tablette, desktop) ; il ne montre pas comment un titre se recompose à 850 pixels de large, entre les deux frames dessinées — c'est au développeur de décider, souvent sans consigne écrite.
• Les états d'interaction réels. Un survol, un focus clavier, un état « en cours d'envoi » du formulaire existent parfois en prototype Figma, mais rarement pour chaque composant ; l'accessibilité au clavier en particulier se code de zéro la plupart du temps.
• Le chargement des polices et des images. Une maquette affiche la police finale instantanément ; un navigateur, lui, télécharge la police avant de l'afficher, avec un effet de bascule (FOUT) que Figma ne peut pas représenter — un point qui pèse directement sur le LCP mesuré en production.
• Le contenu réel, plus long ou plus court que le texte de démonstration. Un nom de client de 4 caractères dans la maquette peut en faire 22 en production, et casser une mise en page qui n'a jamais été testée avec du texte réel.

Export statique Next.js : faut-il héberger sa landing page sans Vercel ni serveur ?

Un template Next.js n'a pas besoin d'un serveur pour tourner. Avec l'option output: "export", Next.js génère un dossier de fichiers HTML, CSS et JavaScript déjà calculés, déployable sur n'importe quel hébergeur ou CDN — gratuit, sans base de données, sans fonction serverless. Ce qu'on y gagne, ce qu'on y perd, et pour quelles landing pages ce choix est le bon.

Ce choix a aussi un effet de sécurité rarement mis en avant. Behnam Shobiri, Mohammad Mannan et Amr Youssef, dans « CDNs' Dark Side: Security Problems in CDN-to-Origin Connections », publié en 2023 dans Digital Threats: Research and Practice (ACM) (voir l'étude), montrent en auditant 14 CDN commerciaux qu’aucun ne valide correctement le certificat du serveur d’origine, et que plusieurs laissent transiter la connexion CDN-origine en clair — une faille qui expose spécifiquement les sites qui gardent un serveur d’origine à interroger derrière leur CDN. Une landing page exportée en pur statique n’a justement plus de serveur d’origine à protéger : le CDN sert directement les fichiers HTML depuis son propre cache, sans jamais rouvrir de connexion vers un serveur applicatif qui pourrait être mal configuré ou mal authentifié. Ce n’est pas une garantie d’invulnérabilité, mais une catégorie entière de risque qui disparaît avec le serveur qu’elle visait.

Comparatif : export statique vs hébergement managé (Vercel)

Next.js 16 sur une landing page : Turbopack stable, mais Cache Components incompatible avec l’export statique

Turbopack devient stable et par défaut, middleware.ts change de nom, et Cache Components promet un cache plus explicite — mais cette dernière fonctionnalité, la plus mise en avant de Next.js 16, ne fonctionne tout simplement pas avec l’export statique que la plupart des landing pages sans serveur utilisent déjà. Ce qui compte vraiment pour un projet comme un template LanderKit, et comment migrer sans casse.

Contrairement à Cache Components, Turbopack profite à n’importe quel projet Next.js, export statique compris : c’est un compilateur, pas une stratégie d’exécution serveur, et il agit avant même que la question du mode d’hébergement se pose. Le gain se mesure surtout en temps de développement — démarrage du serveur local et rebuild après chaque modification de fichier — plutôt qu’en vitesse de chargement pour le visiteur final, puisqu’une page déjà statique se charge à la même vitesse quel que soit le bundler qui l’a produite. Ce gain n’est pourtant pas anodin : Gloria Mark, Daniela Gudith et Ulrich Klocke, dans « The Cost of Interrupted Work: More Speed and Stress », publié en 2008 dans les actes de la conférence CHI (ACM) (voir l'étude), montrent que les personnes interrompues en plein travail compensent en travaillant plus vite, mais au prix d’un stress et d’une frustration mesurablement plus élevés. Un rebuild qui passe de plusieurs secondes à quelques centaines de millisecondes réduit précisément ce genre de micro-interruption répétée, pendant qu’on ajuste un titre ou un CTA sur une landing page.

Faut-il migrer un template LanderKit vers Next.js 16 maintenant ?

1. Vérifier la version de Node.js de l’hébergeur ou de la CI (20.9 minimum) avant de lancer la mise à jour.
2. Mettre à jour next et react vers 16.x et 19.2, puis lancer next build une première fois pour repérer une éventuelle incompatibilité de configuration.
3. Ne pas activer cacheComponents: true si le projet garde output: "export" — les deux sont incompatibles, et le build échoue si les deux options sont présentes en même temps.
4. Ne renommer middleware.ts en proxy.ts que si le projet en utilise un — aucun template LanderKit par défaut n’en a besoin, puisque formulaires et paiement pointent déjà vers des services externes.
5. Relancer un build complet (npm run build) et vérifier que les démos continuent de se générer sans erreur avant de déployer.

Rendre sa landing page installable (PWA) : sur quelles pages ça sert vraiment la conversion

Un manifest et un service worker suffisent à transformer une landing page en icône installable sur l'écran d'accueil — mais l'invite d'installation n'a de sens que sur les parcours où le visiteur revient plusieurs fois : liste d'attente SaaS, inscription à un webinaire, décision immobilière. Sur quelles pages ça vaut le coup, comment l'implémenter proprement en Next.js, et pourquoi il ne faut surtout pas mettre en cache une offre ou un prix qui change.

Sur quelles landing pages l'installation a un sens

• La liste d'attente SaaS — l'utilisateur s'inscrit, puis revient consulter sa position ou attendre l'ouverture ; une icône sur l'écran d'accueil vaut mieux qu'un email retrouvé trois semaines plus tard dans une boîte de réception saturée.
• L'inscription à un webinaire — entre la confirmation et l'événement, la page de compte à rebours peut être rouverte volontairement plusieurs fois ; associée à une notification, elle réduit le taux de no-show.
• La décision à cycle long — une estimation immobilière ou un devis de courtier que le visiteur compare avant de trancher, parfois sur plusieurs jours.

L'invite native de Chrome peut être interceptée avec e.preventDefault() sur l'événement beforeinstallprompt, stockée, puis déclenchée plus tard via un bouton propre au design de la page — par exemple sur l'écran de confirmation qui suit l'inscription à la liste d'attente, plutôt qu'à l'arrivée sur la page. Ce moment compte : proposer l'installation après un engagement réel (le visiteur vient de s'inscrire) plutôt qu'au chargement multiplie les chances d'acceptation, pour la même raison qu'une demande d'autorisation de notifications mal placée se solde par un refus quasi systématique. Sur une page de webinaire, coupler l'installation à une notification de rappel a un effet de rétention documenté : Bell, Garnett et coauteurs, dans un essai clinique randomisé publié en 2023 dans JMIR mHealth and uHealth (voir l'étude), ont mesuré qu'une notification multipliait par 3,5 la probabilité que l'utilisateur rouvre l'application dans l'heure suivante, comparé à l'absence de notification — un effet obtenu hors contexte marketing, mais dont le mécanisme (le rappel visible déclenche le retour) transpose directement à un rappel de webinaire.

Server Actions ou route API pour le formulaire d'une landing page Next.js ?

Depuis Next.js 13, un formulaire peut être traité par une Server Action — une fonction serveur appelée directement, sans passer par une route API séparée. De quoi simplifier le code, mais aussi de quoi changer la robustesse et la sécurité d'un formulaire de landing page. Le comparatif concret, avec le moment où la route API classique reste préférable.

Un argument revient souvent en faveur des Server Actions : la protection CSRF (falsification de requête intersite) serait automatique, alors qu'une route API classique demanderait de la coder à la main. C'est vrai pour l'implémentation de Next.js, qui vérifie automatiquement l'origine de la requête avant d'exécuter une Server Action — un gain réel de simplicité. Mais ça ne veut pas dire qu'une route API est intrinsèquement vulnérable : Adam Barth, Collin Jackson et John C. Mitchell, dans « Robust Defenses for Cross-Site Request Forgery », publié en 2008 dans les actes de la 15^e conférence ACM sur la sécurité informatique (CCS 2008) (voir l'étude), montrent que les défenses CSRF fiables reposent sur la vérification de l'origine ou du referer de la requête — exactement le mécanisme qu'une route API peut implémenter elle-même, avec un peu plus de code. La vraie différence n'est donc pas « sécurisé » contre « pas sécurisé », mais « protégé par défaut sans y penser » contre « protégé si on prend soin de l'implémenter ». Sur un formulaire de capture de leads sans authentification préalable, le risque CSRF reste de toute façon limité — l'enjeu réel se situe plutôt du côté de la validation des données reçues et de la protection anti-spam, comme détaillé dans notre article sur le CAPTCHA.

Comparatif : Server Action ou route API

Sitemap.xml pour une landing page : utile ou pas, et comment le générer avec Next.js

« Faut-il un sitemap.xml pour une seule page ? » La question revient dès qu’un site ne compte qu’une poignée d’URLs. La réponse dépend moins du nombre de pages que de ce qu’un sitemap fait réellement : un canal de découverte, pas un levier de classement. Ce que ça change concrètement, et comment le générer proprement avec Next.js.

Une landing page unique a-t-elle besoin d’un sitemap ?

• Un domaine tout neuf, sans backlink. Sans lien entrant pour signaler son existence, une page peut mettre du temps à être découverte. Un sitemap soumis dans la Search Console donne au robot une liste explicite d’URLs à visiter, ce qui raccourcit surtout ce premier passage.
• Plusieurs pages qui évoluent à des rythmes différents. Une landing page principale stable, une page de remerciement exclue, quelques pages légales, un blog qui publie chaque jour : dès que le site dépasse la page unique, le sitemap devient l’endroit où déclarer une date de modification fiable par URL, plus précise que ce que les liens seuls transmettent.
• Une version multilingue. Si la page FR a un équivalent EN, le sitemap peut porter les relations hreflang entre les deux versions en plus, ou à la place, de celles posées dans le <head> de chaque page — voir notre guide sur les balises hreflang d’une landing page multilingue.

Ce dernier point rejoint un problème plus ancien que le protocole sitemap lui-même : celui de la fraîcheur d’une copie locale d’une ressource qui change. Junghoo Cho et Hector Garcia-Molina, dans une étude publiée en 2000 lors de la conférence ACM SIGMOD (« Synchronizing a Database to Improve Freshness »), montrent, à partir de l’observation de 270 sites web pendant plus de quatre mois, qu’avec des ressources d’exploration limitées, allouer les visites en fonction d’une estimation fiable de la fréquence de changement réelle améliore nettement la fraîcheur globale par rapport à une politique naïve. La date lastmod est précisément ce signal d’estimation — à condition de ne pas le corrompre : Google a confirmé qu’un lastmod mis à la date du jour sur des milliers d’URLs qui n’ont pas changé finit par lui apprendre à ignorer l’attribut pour tout le domaine. Mieux vaut donc un lastmod vrai mais rarement mis à jour qu’un lastmod systématiquement rafraîchi et faux.

Image Open Graph d'une landing page : pourquoi l'aperçu de partage change tout

Vous collez le lien de votre landing page dans un message LinkedIn ou un groupe WhatsApp, et rien ne s'affiche — ou pire, un aperçu cassé, générique, illisible. Ce petit rectangle de 1200×630 pixels est vu avant même que la page ne charge : voici pourquoi il compte, comment le diagnostiquer et comment bien le remplir.

Quand un lien est collé sur LinkedIn, Facebook, WhatsApp, Slack ou X, la plateforme n'affiche pas l'URL brute : elle va chercher dans le <head> de la page des balises Open Graph — og:title, og:description, og:image — normalisées par le protocole Open Graph introduit par Facebook en 2010 et aujourd'hui lu par la quasi-totalité des plateformes sociales et de messagerie. X (ex-Twitter) ajoute sa propre variante, twitter:card. Ces balises sont distinctes de celles que lit Google pour le référencement : une page peut très bien être bien indexée et pourtant totalement muette au moment d'être partagée, simplement parce que personne n'a rempli ces quelques lignes de métadonnées.

Comment vérifier l'aperçu de sa propre landing page

• Facebook Sharing Debugger (developers.facebook.com/tools/debug) — affiche l'aperçu et propose un bouton « Scrape Again » pour forcer la mise à jour après une modification.
• LinkedIn Post Inspector (linkedin.com/post-inspector) — indispensable pour un public B2B francophone, LinkedIn ayant son propre cache indépendant de celui de Facebook.
• Twitter Card Validator, accessible via une recherche « card validator » sur developer.x.com — vérifie spécifiquement la balise twitter:card, qui doit être présente même si og:image l'est déjà.
• Un test manuel dans WhatsApp ou Slack, en collant le lien dans une conversation avec soi-même — le plus rapide pour un premier contrôle, même s'il ne dit pas pourquoi un aperçu est cassé.

Astro ou Next.js pour une landing page : lequel choisir ?

Astro promet du zéro JavaScript par défaut grâce à son architecture en îles, Next.js mise sur l’écosystème React et sa capacité à grandir en produit complet. Comparatif honnête pour choisir la bonne techno de votre landing page.

Ce n’est pas un détail cosmétique. Une étude de référence en mesure de performance web, Butkiewicz, Madhyastha et Sekar (2011), « Understanding Website Complexity: Measurements, Metrics, and Implications » (IMC 2011), a analysé des centaines de sites réels et identifié le nombre d’objets chargés — scripts, requêtes réseau, ressources tierces — comme le facteur le plus déterminant du temps de rendu et de chargement perçu, devant le poids total des données. Moins de JavaScript à parser et exécuter ne signifie pas seulement un fichier plus léger : cela signifie moins de requêtes, moins de blocage du thread principal, et un temps d’interactivité plus court.

Là où Astro tire son épingle du jeu

• Pages très majoritairement statiques : une landing page de capture d’email, un one-pager de présentation, une page de lancement sans logique complexe — Astro n’envoie quasiment rien à faire tourner au navigateur.
• Contenu éditorial dense : article de blog, documentation, page longue mêlant beaucoup de texte — le format MDX d’Astro est particulièrement confortable pour ce cas.
• Liberté de composants : possibilité d’importer un composant React, Vue ou Svelte ponctuel comme île, sans embarquer le framework entier pour le reste de la page.
• Empreinte JavaScript minimale garantie : le zéro-JS n’est pas une option à activer, c’est le comportement par défaut qu’il faut sortir de son chemin pour contourner.

Landing page statique ou SPA React : le choix technique qui plombe (ou sauve) votre taux de conversion

Une landing page en React peut être un SPA entièrement rendu côté client, ou une page statique pré-générée au build. Vitesse perçue, Core Web Vitals, SEO : le choix d’architecture change tout, avant même que le premier mot ne s’affiche à l’écran.

Dès 1968, le psychologue Robert B. Miller posait, dans une étude désormais classique de l’interaction homme-machine, trois seuils de perception du temps de réponse : en dessous de 0,1 seconde, l’utilisateur perçoit une réaction instantanée ; jusqu’à 1 seconde, le fil de sa pensée n’est pas interrompu ; au-delà de 10 secondes, son attention décroche — Miller (1968), « Response Time in Man-Computer Conversational Transactions ». Une SPA qui affiche un écran blanc ou un spineur pendant le téléchargement puis l’exécution de son bundle JavaScript franchit très souvent ce seuil d’une seconde sur une connexion mobile — avant même que le premier mot ne soit lisible.

SSG ou ISR : comment gérer un prix ou une offre qui change sur une landing page Next.js

Une landing page en génération statique (SSG) est la plus rapide à servir : le HTML est déjà prêt, aucun calcul serveur à chaque visite. Mais que se passe-t-il quand le prix ou l'offre qu'elle affiche change plus vite que les rebuilds ? Comparatif concret entre SSG pur, ISR (Incremental Static Regeneration) et calcul côté client, avec l'approche retenue par LanderKit sur son propre site.

Le réflexe « ça change, donc il faut du rendu dynamique » coûte plus cher qu'il n'y paraît. Une page rendue à chaque requête (SSR) recalcule tout le HTML côté serveur à chaque visite, même quand rien n'a changé depuis la précédente — un coût en temps de réponse et en facture serverless que le LCP d'une landing page n'a aucune raison de payer. Lee Breslau, Pei Cao, Li Fan, Graham Phillips et Scott Shenker, dans « Web Caching and Zipf-like Distributions: Evidence and Implications », publié en 1999 dans les actes de la conférence IEEE INFOCOM, montrent à partir de traces de proxys web réels que les requêtes vers un même contenu suivent une distribution très inégale : une poignée de pages concentre l'essentiel du trafic, ce qui rend la mise en cache d'un contenu déjà calculé extrêmement rentable en taux de succès. Une landing page de vente illustre exactement ce cas : la page d'accueil et les pages templates sont visitées des milliers de fois pour un contenu qui, l'essentiel du temps, ne change pas d'une visite à l'autre. Payer un calcul serveur à chaque requête pour re-générer un HTML identique à la précédente n'a donc de sens que si une partie réelle du contenu change effectivement — pas par principe.

Comparatif : SSG pur, ISR, statique calculé, rebuild déclenché

Le Partial Prerendering (PPR) de Next.js : rendre une landing page statique et dynamique à la fois

Toutes les recommandations de performance poussent vers une landing page entièrement statique — et pourtant son bandeau promo, son compte à rebours ou son prix localisé ont besoin d'être recalculés à chaque visite. Le Partial Prerendering de Next.js sert un squelette statique instantané et diffuse ces quelques blocs dynamiques par-dessus, sans rouvrir tout le rendu de la page au serveur.

Nina Bhatti, Anna Bouch et Allan Kuchinsky, dans une étude publiée en 2000 dans Computer Networks et consacrée à la tolérance perçue à la latence sur le Web (voir l'étude), montrent que cette tolérance n'est pas uniforme sur une même page : elle dépend de ce que l'internaute attend de chaque zone visuelle au moment où il la regarde. Un visiteur qui voit le titre, l'image principale et le bouton d'appel à l'action s'afficher instantanément ne remarque généralement pas qu'un petit encart secondaire — un compteur de stock, une mention de prix localisée — se complète une fraction de seconde plus tard. C'est exactement ce que permet le PPR : le LCP, presque toujours calculé sur le titre ou l'image du hero, reste celui d'une page purement statique, puisque ce contenu fait partie du squelette prérendu. Seul le bloc explicitement dynamique attend sa donnée, pendant que le reste de la page est déjà entièrement visible et interactif.

Cas d'usage concrets sur une landing page

• Prix localisé ou converti dans la devise du visiteur : la géolocalisation IP côté serveur détermine la devise à l'intérieur d'un seul composant Suspense, sans rendre le reste de la page dynamique — voir notre article sur devise locale et prix affiché.
• Compte à rebours vers une vraie échéance stockée côté serveur : utile pour une inscription webinaire (démo) dont la date ferme réellement, plutôt qu'un compteur recalculé côté client à chaque rendu.
• Variante d'A/B test décidée côté serveur : un complément naturel à l'approche « feature flags à l'edge » décrite dans notre guide sur l'A/B testing d'une page statique — le flag est lu dans le trou dynamique, le reste de la page garde les bénéfices du prérendu.
• Compteur de places ou de stock restant : une donnée qui change plus souvent que le contenu de la page elle-même ne le justifierait via une revalidation ISR classique.

View Transitions API sur une landing page Next.js : fondu utile ou gadget ?

Un clic sur une carte de template, et la page suivante s'affiche d'un coup sec — aucune continuité visuelle entre l'image qu'on vient de voir et celle qui la remplace. Le View Transitions API du navigateur, désormais pilotable depuis Next.js sans bibliothèque tierce, permet de faire persister un élément visuel d'une page à l'autre. Deux études sur la perception du temps d'attente et l'animation aident à comprendre où ce fondu aide vraiment, et où il n'est qu'un gadget qui ralentit la page pour rien.

L'intérêt ne se limite pas à un effet joli. Une étude publiée en 2025 dans le Journal of Consumer Research par Yu Ding (Baruch College) et Ellie Kyung (Babson College), consacrée à la vitesse d'animation et au temps d'attente perçu, montre une relation en forme de U inversé entre la vitesse d'une animation et le temps d'attente perçu par l'utilisateur : une animation à vitesse modérée réduit davantage l'attente perçue qu'une absence totale d'animation, mais aussi qu'une animation trop rapide ou trop lente, parce qu'elle capte l'attention sans pour autant la saturer. Une étude antérieure, présentée en 2010 à la conférence CHI par Jarmo Huhtala, Ari-Heikki Sarjanoja, Jani Mäntyjärvi et leurs coauteurs (voir l'étude), va dans le même sens sur un autre point précis : montrer un fragment de l'écran suivant plus tôt dans la transition est ce qui fait le plus baisser la perception du temps d'attente, davantage que la durée totale de l'animation elle-même. Autrement dit, ce n'est pas l'animation en tant que telle qui rassure l'utilisateur pendant un chargement, c'est la promesse visuelle que quelque chose de connu va continuer d'exister de l'autre côté.

Où ce fondu a un vrai rôle sur une landing page

• D'une grille de templates vers une fiche détaillée : la vignette cliquée s'agrandit en douceur vers l'image hero de la page suivante, plutôt que de disparaître pour réapparaître ailleurs — utile sur une page qui présente plusieurs offres côte à côte, où le paradoxe du choix rend déjà la comparaison mentalement coûteuse.
• Du hero vers la démo live d'un template : sur le template liste d'attente SaaS (démo), un visiteur qui clique sur « voir la démo » garde le même repère visuel (le nom du produit, le bouton) le temps que la page suivante se charge, ce qui réduit l'impression d'avoir quitté le site.
• Du formulaire vers la page de remerciement : faire persister le bouton d'envoi qui se transforme en confirmation visuelle évite le petit flottement où l'utilisateur se demande si sa soumission a bien été prise en compte.
• Entre deux étapes d'un formulaire en plusieurs étapes : la barre de progression et les champs déjà remplis glissent plutôt que de sauter d'un écran à l'autre, en cohérence avec ce que recommande déjà notre article sur la barre de progression.

Le plus long, dans cette histoire, n’a jamais été l’hébergement — c’est d’avoir une page qui convertit. C’est précisément ce que réglent les templates LanderKit : dix landing pages Next.js prêtes à déployer, structurées pour la conversion dès la première ligne, à 89 € l’unité ou 229 € le pack complet. Le code est à vous, l’hébergement Vercel est gratuit, et la mise en ligne se joue en une poignée de minutes suivant ce guide.