Astro vs Next.js en 2026 : quel framework choisir ?

« Astro ou Next.js ? » La question revient dans presque chaque cadrage technique, et elle est mal posée. Les deux outils ne résolvent pas le même problème. Poser le choix comme un duel revient à demander s'il faut un camion ou une berline : la réponse dépend entièrement de ce que vous transportez.

Ce site tourne sur Astro 7. Voici pourquoi, avec les chiffres de notre propre migration plutôt qu'un tableau comparatif générique.

Ce que ce site envoie réellement au navigateur

Chiffres relevés sur la page d'accueil de playdigital.ch, en production :

• 60 ko de HTML, entièrement pré-rendu au moment de la construction
• 152 ko de JavaScript, dont 136 ko sont nos animations (GSAP et Lenis) — un choix esthétique, pas une dépense imposée par le framework
• 61 ko de CSS pour les 219 pages du site
• 219 pages générées en un peu plus de six secondes

Le point important est ailleurs : notre interface d'administration Keystatic pèse 2,7 Mo de JavaScript. Ce fichier n'atteint jamais un visiteur. Il n'est chargé que sur /keystatic, derrière une authentification. C'est l'architecture en îlots : le code interactif est envoyé là où il sert, et nulle part ailleurs.

Avec un framework qui hydrate l'application entière, cette séparation demande un travail délibéré. Avec Astro, c'est le défaut.

La vraie ligne de partage

Elle ne passe pas entre « site vitrine » et « application ». Elle passe ici :

Vos pages sont-elles identiques pour tous les visiteurs, ou dépendent-elles de qui regarde ?

Une page de service, un article, une fiche projet : identiques pour tout le monde. Elles peuvent être calculées une fois, à la construction, et servies comme des fichiers. C'est le terrain d'Astro.

Un tableau de bord, un panier, un espace client, une liste filtrée par droits d'accès : différents à chaque visite. Il faut un serveur qui rende à la demande, une couche de session, une gestion de cache par utilisateur. C'est le terrain de Next.js, et il le couvre mieux qu'Astro.

La plupart des sites d'entreprise sont à 90 % dans la première catégorie et à 10 % dans la seconde. Le piège consiste à choisir l'outil pour les 10 %, et à faire payer aux 90 % restants le poids d'une application complète.

Ce que Next.js fait mieux

Soyons honnêtes, la liste est réelle :

• Le rendu par utilisateur. Server Components, streaming, revalidation granulaire : rien dans Astro n'égale cette maturité quand chaque page dépend d'une session.
• Les applications lourdes en état. Formulaires à plusieurs étapes, optimistic updates, synchronisation client-serveur : l'écosystème React y est chez lui.
• Le vivier de développeurs. Recruter sur Next.js est plus simple. Ce n'est pas un argument technique, mais c'est un argument de direction.
• Vercel. Le déploiement y est sans friction — au prix d'une dépendance à un hébergeur précis, ce qui n'est pas neutre pour une entreprise suisse soumise à des exigences de localisation des données.

Ce qu'Astro fait mieux

• Le JavaScript par défaut : zéro. Vous ajoutez de l'interactivité là où vous en avez besoin, avec la directive qui convient (client:load, client:visible, client:idle). L'inverse — retirer du JavaScript d'une application hydratée — est beaucoup plus difficile.
• Le multilingue sans acrobaties. Trois langues, des slugs différents par langue, des hreflang complets sur 219 pages : c'est du routage de fichiers, pas de la configuration.
• La liberté de bibliothèque. React, Svelte, Vue ou rien du tout, dans le même projet. Notre administration est en React ; le site public n'en contient pas une ligne.
• L'hébergement où vous voulez. Un adaptateur Node, un conteneur, votre serveur. Nous servons ce site depuis un VPS à Satigny.

Trois questions pour trancher

1. Quelle proportion de vos pages dépend de l'identité du visiteur ? Sous 20 %, Astro. Au-dessus de 60 %, Next.js. Entre les deux, la question suivante départage.
2. Qui va maintenir ce projet dans deux ans ? Une équipe React installée a de bonnes raisons de rester sur Next.js. La cohérence d'équipe vaut souvent plus que quelques kilo-octets.
3. Où doivent vivre vos données ? Si la réponse est « en Suisse, sur une infrastructure que nous contrôlons », le confort de Vercel disparaît du tableau.

Notre position

Nous utilisons les deux. Pour un site de contenu multilingue avec une administration intégrée — exactement le cas de playdigital.ch — Astro donne un meilleur résultat pour un coût de maintenance plus faible. Pour un portail client avec des comptes, des droits et des données par utilisateur, nous partons sur Next.js sans hésiter.

Ce qui est faux, c'est l'idée qu'un choix vaut mieux que l'autre dans l'absolu. Ce qui est coûteux, c'est de choisir avant d'avoir répondu aux trois questions ci-dessus.