Le blog

Technique6 min de lecture

Next.js pour un site vitrine : sur-dimensionné ou pertinent ?

La critique est légitime : pourquoi un cadre applicatif React pour vingt pages qui ne bougent pas ? Voici la réponse honnête, y compris les trois cas où nous déconseillons Next.js et où un site plus simple fait mieux le travail.

Écrit par Thomas, avec ClaudeCofondateur de Levupp

Next.js se justifie sur un site vitrine pour quatre raisons : il produit des pages statiques servies depuis un réseau de diffusion, ce qui donne une performance qu'un hébergement PHP mutualisé n'atteint pas ; il n'a pas de surface d'attaque comparable à celle d'un CMS installé ; il permet d'intégrer des parties applicatives sans changer d'outil ; et il ne se dégrade pas par accumulation d'extensions. Il est en revanche un mauvais choix quand personne ne pourra le maintenir.

La critique, prise au sérieux

Elle mérite d'être formulée correctement avant qu'on y réponde.

Next.js est un cadre applicatif construit sur React. Il suppose une chaîne de compilation, des dépendances qui se mettent à jour, un environnement de déploiement, et un développeur pour intervenir. Pour vingt pages de présentation qui changent trois fois par an, c'est disproportionné.

Cette critique est fondée dans un cas précis : quand la personne qui choisit ne pourra pas assumer la suite. Elle est infondée dans les autres, et voici pourquoi.

Les quatre raisons qui tiennent

1. La performance n'est pas un réglage, elle est structurelle

Une page prérendue est un fichier HTML servi depuis un point de présence proche du visiteur. Aucune base n'est interrogée, aucun code n'est exécuté à la demande. Le temps de réponse est de l'ordre de quelques dizaines de millisecondes, partout.

Un WordPress sur un hébergement mutualisé exécute du PHP, interroge MySQL et assemble la page à chaque requête. Le cache masque une partie du problème, il ne le supprime pas.

Ce n'est pas une question de qualité de développement. C'est une différence de nature entre servir un fichier et calculer une réponse.

2. La surface d'attaque

Un site prérendu n'a pas d'administration exposée sur internet, pas de base accessible, pas d'extensions tierces qui exécutent du code sur le serveur public. Les vulnérabilités WordPress viennent très majoritairement des extensions, et le nombre d'extensions installées est le meilleur prédicteur d'une compromission.

Ce n'est pas un argument marginal pour un cabinet, un promoteur ou une marque : un site compromis qui redirige vers un site douteux coûte en référencement et en réputation.

3. La dégradation ne se produit pas de la même façon

Un WordPress se dégrade parce que le modèle encourage à ajouter. Chaque besoin nouveau se règle par une extension, et rien ne se retire jamais. Les mécanismes sont décrits dans notre article sur les sites WordPress qui ralentissent.

Une application Next.js se dégrade autrement : les dépendances vieillissent, et une mise à jour majeure du cadre demande du travail. C'est une dette réelle, mais elle est visible, datée, et elle ne s'accumule pas silencieusement page par page.

4. Le site vitrine finit toujours par ne plus l'être

C'est l'argument le plus décisif dans notre expérience. Un site de présentation reste rarement un site de présentation. En dix-huit mois, il faut un formulaire qualifiant, un espace client, un calculateur, une intégration à un agenda, un portfolio filtrable.

Sur WordPress, chacun de ces besoins ajoute une extension. Sur Next.js, ce sont des pages de plus dans le même projet, écrites de la même manière.

Les trois cas où nous déconseillons Next.js

Il faut aussi savoir dire non, et voici quand nous le disons.

Personne ne pourra intervenir. Une association, une TPE sans budget de maintenance, un client qui veut pouvoir demander une modification à n'importe qui. Un site Next.js demande un développeur, et un développeur qui n'est pas là est un site figé. Dans ce cas, un WordPress sobre avec un thème léger et cinq extensions est un meilleur service rendu.

L'équipe éditoriale est nombreuse et non technique. Une rédaction qui publie plusieurs fois par jour, avec des relectures, des droits par rôle, des programmations. WordPress fait ça très bien depuis vingt ans. Un système découplé peut le faire, à condition d'y mettre le budget correspondant, et il faut le dire avant.

Le besoin est réellement standard et temporaire. Une page d'événement, un site de campagne à durée de vie de six mois. Le sur-mesure n'a aucun intérêt, et un outil sans code fait le travail en deux jours.

Ce que ça change pour la personne qui publie

C'est la question qui décide, et elle est rarement posée en ces termes.

Avec un système de contenu découplé, l'expérience d'écriture est celle d'une administration moderne : des champs, un éditeur de texte riche, des brouillons, une prévisualisation. C'est souvent plus agréable que WordPress, parce que les champs sont conçus pour le site précis plutôt que génériques.

Ce qui change vraiment : la mise en page n'appartient plus à la personne qui écrit. Elle ne peut plus faire une colonne de trois blocs sur une page et pas sur l'autre. Pour beaucoup d'entreprises, c'est un soulagement, parce que la liberté totale des constructeurs de pages produit des sites incohérents. Pour d'autres, c'est une perte réelle.

Nous posons toujours cette question au cadrage, et la réponse oriente le choix plus que la performance.

Le coût, honnêtement

Un site vitrine Next.js coûte plus cher à construire qu'un WordPress avec un thème du marché. Il coûte moins cher à maintenir, et il ne demande pas de refonte au bout de trois ans à cause de l'accumulation.

Sur cinq ans, les deux se rapprochent. Sur trois ans, WordPress reste moins cher si le site ne change pas. La comparaison honnête doit inclure la maintenance, les incidents et la probabilité de refonte, pas seulement le devis initial.

Questions fréquentes

Un site Next.js est-il modifiable par une équipe non technique ?

Le contenu, oui, via un système de gestion découplé avec une administration comparable à celle de WordPress. La structure et la mise en page, non : elles appartiennent au code. C'est une contrainte pour qui veut composer librement chaque page, et un avantage pour qui veut que le site reste cohérent.

Next.js est-il meilleur pour le référencement ?

Il n'y a pas de bonus de classement lié à la technologie. Ce que Next.js apporte, c'est un rendu côté serveur ou statique par défaut, donc un contenu réellement présent dans le HTML, et de bonnes performances de départ. Ce sont des conditions nécessaires, pas des avantages compétitifs. Le détail est dans notre article sur ce que Next.js règle en Core Web Vitals.

Faut-il un hébergement spécifique ?

Une plateforme adaptée au déploiement d'applications, ou un serveur avec un environnement conteneurisé. Ce n'est pas un hébergement mutualisé classique. Le coût est comparable à celui d'un hébergement WordPress correct, et l'infrastructure de diffusion est incluse.

Que se passe-t-il si mon prestataire disparaît ?

Le code vous appartient et il est versionné dans un dépôt que vous devez posséder. Next.js et React sont des technologies très répandues, et un développeur peut reprendre un projet standard. Vérifiez trois choses au contrat : la propriété du code, l'accès au dépôt, et la documentation de déploiement.

Notre position

Nous construisons en Next.js parce que c'est le meilleur compromis pour les entreprises que nous accompagnons : des sites qui doivent être rapides, sûrs, et qui deviennent applicatifs plus tôt que prévu. Nous le déconseillons quand la maintenance n'est pas assurée, et nous le disons avant le devis plutôt qu'après. Si votre site actuel montre les signes décrits dans notre article sur la dette technique des constructeurs de pages, la question mérite d'être posée. Nous menons ces migrations, c'est l'objet de notre page migration WordPress vers Next.js.

Écrit par Thomas, avec ClaudeTechnique · Créer un site web

On construit le vôtre ?

Racontez-nous ce que vous avez en tête,on vous dit ce qu'on en ferait.

Démarrer un projet