Astro ou Next.js pour un site vitrine : comment trancher

Une fois la décision du headless prise, la question suivante tombe immédiatement : avec quoi construire le site public ? Deux noms reviennent, Astro et Next.js. Les comparatifs en ligne les opposent sur des critères de performance brute, ce qui est le plus mauvais angle possible : sur un site vitrine correctement construit, les deux atteignent d’excellents résultats.

Le vrai critère est ailleurs, et il tient en une question. Avant d’y venir, il faut comprendre d’où viennent ces deux outils, parce que leur origine explique tout le reste.

Deux outils, deux problèmes d’origine

Astro part du contenu

Astro a été conçu pour des sites dont l’essentiel est du contenu à afficher : documentation, blogs, sites vitrines, catalogues. Son principe fondateur tient en une phrase — n’envoyer aucun JavaScript au navigateur tant que ce n’est pas explicitement demandé.

Une page produite par Astro est du HTML et du CSS. Si vous avez besoin d’un carrousel interactif, vous le déclarez comme tel et lui seul embarque du JavaScript : c’est ce qu’on appelle une architecture en îlots. Le reste de la page — les 90 % qui ne font qu’afficher du texte et des images — n’en contient pas une ligne.

Pour un site vitrine, un blog ou des pages locales, c’est un alignement presque parfait entre l’outil et le besoin. On n’a rien à désactiver, rien à alléger : il n’y avait rien de trop au départ.

Next.js part de l’application

Next.js vient de l’univers React et vise des interfaces riches : espaces clients, tableaux de bord, tunnels d’achat, contenus personnalisés par utilisateur. Il sait produire des pages statiques très rapides — ce n’est pas le sujet — mais sa raison d’être est ailleurs, dans tout ce qui demande de l’état, de la session et de l’interactivité continue.

Cette vocation a une conséquence concrète : même une page purement textuelle embarque le socle React nécessaire à faire tourner l’ensemble. On peut réduire cette charge, on ne l’annule pas. C’est le prix d’un outil prêt à devenir une application le jour où on le lui demande.

Le critère qui tranche vraiment

Posez-vous une seule question : votre site a-t-il des utilisateurs connectés ou des données propres à chaque visiteur ?

• Non — vitrine, blog, catalogue consultable, pages par ville, prise de rendez-vous externalisée : Astro fait le travail avec beaucoup moins de pièces mobiles.
• Oui — compte client, panier, devis en ligne, contenu réservé aux abonnés : Next.js évite de reconstruire à la main ce qu’il fournit d’origine.

Le reste — écosystème, popularité, préférence syntaxique du développeur — est secondaire tant que le socle est adapté au problème. Un mauvais alignement ne se rattrape pas à coups de bonnes pratiques.

Ce que ça change pour vous, concrètement

Le coût de maintenance sur deux ans

C’est la partie que les comparatifs techniques ignorent, et c’est pourtant celle que vous paierez.

Un projet Astro de site vitrine repose sur peu de dépendances. Les mises à jour sont espacées et rarement cassantes. Un site laissé six mois sans intervention se remet à jour en une heure.

Un projet Next.js embarque React, son écosystème et les conventions du cadre applicatif, qui évoluent vite. Les montées de version majeures demandent régulièrement des adaptations. Sur un site vitrine, on paie cette maintenance sans jamais utiliser ce qu’elle finance.

Sur deux ans, l’écart se compte en journées de travail. Pour un site qui affiche les mêmes textes dans les deux cas.

Et le référencement ?

Aucun des deux n’est mieux référencé par nature. Les moteurs jugent le HTML servi, sa vitesse d’arrivée et sa structure. Un site Astro négligé sera moins bien classé qu’un site Next.js soigné, et inversement.

Une nuance existe malgré tout, et elle concerne l’INP — la mesure de réactivité qui fait partie des Core Web Vitals depuis mars 2024. Elle sanctionne le JavaScript qui monopolise le fil d’exécution au moment où le visiteur clique. Un site qui n’embarque aucun JavaScript part avec une avance structurelle sur cette mesure. Ce n’est pas décisif, mais c’est un point de moins à défendre.

L’erreur la plus fréquente

Choisir Next.js « au cas où » le site deviendrait une application un jour. Cette assurance se paie tous les mois : davantage de dépendances à maintenir, un hébergement plus exigeant, plus de JavaScript envoyé pour afficher les mêmes textes.

Et si ce jour arrive, l’assurance ne sert généralement à rien : une application client vit très bien à côté du site vitrine, sur son propre sous-domaine. C’est même souvent plus sain que de fondre les deux dans un projet unique, où la moindre évolution de l’application impose de reconstruire et retester le site public.

Et si le choix est déjà fait ?

Un site vitrine déjà construit en Next.js n’est pas un problème à corriger. Tant qu’il est bien réglé, rapide et maintenu, il n’y a aucune raison de le refaire : le gain serait marginal et le coût réel.

La question ne se pose que dans deux cas — le jour d’une refonte, où le choix se rejoue de toute façon, ou lorsque la maintenance commence à coûter plus qu’elle ne rapporte. Ce second signal est facile à repérer : il arrive quand la dernière mise à jour a demandé une journée pour corriger des régressions sur un site dont le contenu n’avait pas bougé.

En résumé

Astro pour afficher du contenu, Next.js pour faire fonctionner une application. La plupart des sites d’entreprise appartiennent à la première catégorie, et se portent mieux avec l’outil qui a été pensé pour eux. Choisir le second n’est pas une faute — c’est simplement payer, chaque mois, une capacité qu’on n’utilise pas.

Trois projets, trois verdicts

Les principes se comprennent mieux appliqués. Voici trois cas typiques et le raisonnement qui les tranche.

Un artisan, quinze pages, six zones d’intervention

Contenu : prestations, réalisations, pages par ville, formulaire de contact, prise de rendez-vous externalisée. Aucun utilisateur connecté, aucune donnée personnalisée.

Verdict : Astro. Le site est entièrement constitué de pages construites à l’avance. Chaque kilo-octet de JavaScript envoyé serait payé sans contrepartie, sur des connexions mobiles qui constituent l’essentiel du trafic local.

Un cabinet de conseil avec un espace documentaire pour ses clients

Site vitrine public, plus une zone protégée où chaque client retrouve ses comptes-rendus et ses factures.

Verdict : les deux, séparés. Le site public en Astro, l’espace client en Next.js sur un sous-domaine. C’est contre-intuitif — on préférerait un seul projet — mais chaque partie utilise l’outil fait pour elle, et une évolution de l’espace client n’oblige jamais à reconstruire et retester le site vitrine.

Une place de marché avec inscription et paiement

Comptes utilisateurs, tableau de bord, transactions, notifications en temps réel.

Verdict : Next.js, sans hésitation. Tenter cela en Astro reviendrait à réécrire à la main ce que Next.js fournit d’origine, avec le résultat que l’on imagine sur les délais et la fiabilité.

Ce qui ne devrait pas entrer dans la décision

Trois arguments reviennent souvent et n’en sont pas.

« Next.js est plus populaire. » C’est vrai, et sans conséquence sur un site vitrine. La popularité facilite le recrutement sur des projets applicatifs ; elle ne rend pas un outil plus adapté à un usage qui n’est pas le sien.

« Astro est plus récent, donc plus risqué. » L’écart d’ancienneté est de quelques années, et les deux sont largement adoptés en production. Le vrai risque, dans les deux cas, n’est pas l’abandon de l’outil : c’est que votre contenu soit prisonnier. Or il vit dans WordPress, ce qui rend la couche d’affichage remplaçable par construction.

« Mon développeur préfère React. » C’est un argument recevable, à condition d’être formulé comme tel — une préférence d’équipe, avec un coût assumé — et non déguisé en argument technique. Un développeur à l’aise avec React travaillera plus vite et fera moins d’erreurs, ce qui peut compenser le surcoût structurel sur un petit projet.

Comment vérifier après coup

Une fois le site en ligne, un contrôle simple révèle si le choix était le bon : ouvrez une page de contenu et regardez la quantité de JavaScript téléchargée.

Sur un site vitrine bien construit, on attend quelques dizaines de kilo-octets, essentiellement pour les animations et le menu. Si une page qui ne fait qu’afficher du texte télécharge plusieurs centaines de kilo-octets de scripts, l’outil travaille contre le projet — quel que soit son nom.