Stack frontend d’un solo founder : choisir Astro, Next.js, React, Tailwind et shadcn/ui

Le projet contient quatre surfaces : /blog, /tools/image-resizer, /dashboard/settings et /pricing. Faut-il tout placer dans Next.js ou séparer le blog Astro du dashboard Next.js ? Un blog Astro auquel on ajoute connexion, paiement et historique pose la question d’une migration. À l’inverse, un projet Next.js avec vingt articles Markdown oblige déjà à comprendre le cache, les Server/Client Components et le déploiement.

Le choix frontend d’une entreprise solo n’est pas un classement de frameworks. Le type de page, la quantité de données dynamiques et le coût de maintenance déterminent le framework, la limite du dépôt et la responsabilité du code shadcn/ui copié. Il faut savoir quand les islands suffisent, quand l’App Router coûte plus qu’il ne rapporte et quand React + Vite reste plus simple.

Backend, déploiement, base de données, paiement et authentification seront traités dans les articles suivants.

Tableau de décision des frameworks

On part du type de page, pas de la popularité.

Plusieurs surfaces dans un produit

Avec environ 80 % de contenu et 20 % de dashboard, Astro peut rester l’application principale, complétée par des islands React ou une application Next.js séparée.

Avec 80 % d’application et 20 % de blog, Next.js peut porter le produit et générer le blog statiquement.

À parts égales, une application Astro pour le contenu et une application Next.js pour le dashboard rendent la frontière explicite. Un monorepo peut conserver cette séparation.

Deux applications ajoutent dépendances et déploiements, mais évitent que les règles de cache d’une surface contaminent toutes les pages.

Avertissement sur la maintenance

Cache Next.js, frontières Server/Client Components et différences entre Vercel, Cloudflare et l’auto-hébergement demandent une validation. Avec peu de pages dynamiques, Astro ou React + Vite peuvent coûter moins cher.

Le comparatif Astro vs Next.js détaille l’architecture.

Sites de contenu : Astro et l’architecture Islands

Astro vise les blogs, documentations, pages marketing et autres sites centrés sur le contenu. Server-first et zero JS by default signifient que le HTML est rendu au build ou sur le serveur ; seuls les composants explicitement interactifs chargent du JavaScript client.

Les content collections organisent, valident et typent Markdown ou des données structurées. Le frontmatter et les requêtes par date, tag ou catégorie peuvent être vérifiés au build.

Islands : HTML statique et interaction locale

La majorité de la page reste en HTML. Une petite zone interactive devient une island, chargée selon client:load ou client:visible.

Un bouton d’envoi peut être le seul composant React avec client:load.

Un sélecteur de thème peut lire localStorage et modifier des variables CSS.

Une visionneuse d’images peut attendre client:visible.

Cette approche évite d’hydrater toute la page pour un formulaire ou un petit outil.

Quand Astro ne doit pas tout porter

Si presque chaque route vérifie l’identité, charge des données privées, partage beaucoup d’état ou exige un routage client complexe, Astro n’est plus le socle évident. Un dashboard rempli d’islands authentifiées se décrit mieux dans Next.js ou une application React autonome.

Le retour d’expérience Astro 5 et Lighthouse montre collections et islands sur un site de contenu.

Outils et produits interactifs : React + Vite vs Next.js

Un outil se concentre souvent sur une action ; un produit interactif ajoute routes, état partagé, collaboration ou éditeur.

Quand React + Vite convient

React + Vite convient à une SPA client ou à un outil autonome sans rendu serveur.

Un compresseur traite les images dans le navigateur.

Un formateur JSON analyse les données localement.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Un éditeur Markdown combine édition, aperçu et sauvegarde localStorage.

Le déploiement statique et l’absence de cache Next.js simplifient l’ensemble. Si le référencement de l’outil est central, une SPA client demande cependant une stratégie SEO spécifique.

Quand Next.js convient

Next.js devient utile avec rendu serveur, plusieurs routes ou rendu mixte.

Accueil, outil et résultat peuvent avoir leurs propres routes rendues côté serveur.

Les pages explicatives peuvent rester indexables via SSG ou SSR.

La présentation peut être statique tandis que les résultats privés restent dynamiques.

Conditions pour choisir React + Vite

L’action centrale utilise Browser APIs, localStorage ou Canvas.

Le déploiement doit rester statique sans runtime Node.js.

Le routage, le cache et le SSR de Next.js ne sont pas nécessaires.

Une frontière nette entre client et backend est plus simple à maintenir.

Si recherche et routes serveur sont centrales, leur bénéfice doit compenser le coût Next.js.

React 19 Actions approfondit formulaires et actions asynchrones.

Dashboards SaaS : Server et Client Components de Next.js

L’App Router sépare le travail serveur de l’interaction navigateur. 'use client' marque la frontière client.

Server Components vs Client Components

Les Server Components s’exécutent sur le serveur ou au build sans ajouter leur logique au bundle JavaScript du navigateur.

Ils conviennent au contenu statique, aux requêtes de base et aux appels API.

Ils ne peuvent pas utiliser localStorage, window, useState, useEffect ou onClick.

Les Client Components s’exécutent dans le navigateur et gèrent interaction, état et Browser APIs.

Ils conviennent aux formulaires, boutons et mises à jour en direct.

Le fichier de frontière déclare 'use client'.

Un Server Component peut importer un Client Component. L’inverse direct n’est pas permis, mais un contenu rendu par le serveur peut être transmis comme contenu affichable.

Cas d’usage d’un dashboard SaaS

L’App Router convient aux dashboards avec authentification, données dynamiques et nombreux formulaires.

Les paramètres lisent l’utilisateur et écrivent ses préférences.

Les commandes affichent listes, détails et changements d’état.

Les analytics chargent les données protégées sur le serveur et les graphiques interactifs dans le navigateur.

L’accès direct à la couche de données aide lorsque identité et permissions sont centrales.

Avertissement sur la maintenance

Rendu statique ou dynamique, revalidate, frontières et runtime doivent correspondre à la version Next.js utilisée. La documentation actuelle prime sur les anciens extraits.

Avec quelques pages dynamiques, React + Vite et un backend Node.js ou Supabase séparé peuvent être plus simples.

La série App Router traite routage, migration, Middleware, Auth et Dark Mode séparément.

Couche de styles : Tailwind et utility-first

Utility-first assemble de petites classes dans HTML ou JSX. Dans <div class="bg-blue-500 text-white p-4 rounded-lg">, chaque classe contrôle une partie du style.

Tailwind est une couche de collaboration, pas un substitut au design produit.

Il réduit la création de noms CSS.

Le style reste près du markup qui l’utilise.

Humains et agents disposent d’un vocabulaire commun pour modifier l’interface.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Tailwind ne crée pas la qualité du design

Couleurs, typographie, espacements et rayons exigent des règles cohérentes.

Des tokens produit valent mieux qu’un assemblage aléatoire d’utilities.

Les groupes répétés pour boutons, cartes et lignes doivent devenir des composants.

Sans ces limites, le markup se densifie sans rendre le produit cohérent.

Tailwind reste indépendant du framework

Tailwind fonctionne avec Astro, Next.js et React + Vite. Le chemin Vite actuel de Tailwind CSS v4 utilise @tailwindcss/vite et @import "tailwindcss";; Astro peut employer le même plugin. Il faut vérifier le guide officiel lors de l’implémentation.

Couche de composants : propriété et intégration de shadcn/ui

shadcn/ui n’est pas un paquet classique qui masque une implémentation fixe. Sa CLI copie le code dans le projet, qui en devient propriétaire.

Le projet possède le code des composants

Les mises à jour amont ne modifient pas automatiquement les copies.

Clavier, ARIA et lecteurs d’écran doivent être testés dans les combinaisons réelles.

Couleurs, rayons et espacements doivent rejoindre le design system.

Validation, soumission et logique métier restent du code applicatif.

Le code visible et modifiable est l’avantage ; mises à jour, accessibilité, thème et états sont la responsabilité associée.

shadcn/ui et Tailwind

Les procédures actuelles pour Astro et Next.js supposent Tailwind. Tailwind fournit le langage de style, shadcn/ui le code source à posséder.

Cas adaptés

Dashboards, paramètres et pages riches en formulaires profitent de Button, Input, Select, Dialog et Table.

Les paramètres réutilisent contrôles et erreurs.

Inscription, login et paiement utilisent les primitives, mais l’application garde validation et état.

Une bibliothèque existante ou un design system complet réduisent l’intérêt.

Intégration dans Astro

L’intégration React est nécessaire aux composants React.

Tailwind fournit leurs styles.

Ils conviennent aux formulaires et dialogues locaux, pas à la transformation de toutes les pages de contenu en application React.

Le modèle Astro officiel configure aujourd’hui Tailwind et React ; vérifiez la CLI actuelle.

Intégration dans Next.js

shadcn/ui propose un modèle Next.js et une initialisation pour projet existant.

Chaque composant doit rester du bon côté de la frontière Server/Client. shadcn/ui n’impose pas de convertir toute la page en Client Component.

CLI, presets et registry peuvent évoluer.

Quand ne pas utiliser shadcn/ui

Quand il faut un design system complet plutôt que des primitives.

Quand le projet ne veut pas posséder code, mises à jour, accessibilité et thème.

Quand Ant Design, Material UI ou une bibliothèque interne suffit déjà.

Quand un site de contenu utilise peu de formulaires et de dashboard.

Le vrai coût de maintenance en solo

Type de page et données ne suffisent pas : complexité du framework, propriété des composants et revue du code IA déterminent le travail durable.

Maintenance de Next.js

Un écart entre intention et règles de rendu ou cache peut livrer des données obsolètes.

Les frontières Server/Client fixent où vivent état et accès aux données.

Vercel, Cloudflare et un runtime Node.js propre doivent être évalués séparément.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Pour des pages surtout statiques, ce coût peut dépasser le bénéfice.

Maintenance de shadcn/ui

Corrections amont et mises à jour doivent être revues.

Clavier, ARIA et lecteurs d’écran exigent des tests produit.

Couleurs, densité et espacements suivent les tokens.

Validation, soumission et état restent internes.

Une bibliothèque packagée ou quelques primitives maison conviennent mieux si cette responsabilité n’est pas souhaitée.

Revue du frontend généré par IA

Les exemples React, Next.js et shadcn/ui abondent, mais la recette reste nécessaire.

Un agent peut créer trop de couches Server/Client.

Il peut produire un cache incompatible avec la version ou la route.

Il peut ignorer tokens et états d’interaction.

L’IA réduit le temps de saisie, pas la revue d’architecture, d’accessibilité et visuelle.

Plusieurs frameworks dans un produit

Astro pour le contenu et Next.js pour le dashboard clarifient la frontière, mais ajoutent dépendances, configuration et CI/CD pour deux applications.

Le routage blog.example.com et app.example.com doit aussi être exploité.

Les deux peuvent rester dans un monorepo. Un produit centré contenu reste surtout Astro, un produit centré app surtout Next.js, et un produit équilibré emploie deux limites explicites.

Étapes suivantes et lectures

Articles publiés

Choisir un framework de blog compare Hugo, Astro et Hexo.

Astro 5 et Lighthouse 100 couvre collections, islands et performance.

Astro vs Next.js compare architecture et rendu.

React 19 Actions approfondit formulaires et asynchronisme.

Série Next.js App Router

Routage, migration, Middleware, Auth et Dark Mode sont traités dans des articles séparés pour les dashboards SaaS.

Prochains articles de la série

Ce texte est le cinquième de la série Solo Founder Tech Stack. Les suivants comparent Node.js, Python, Go, Supabase et des API propres.

Ils couvrent aussi Cloudflare, Vercel, l’auto-hébergement et les conteneurs.

Les bases étudiées sont PostgreSQL, Supabase, PlanetScale et MongoDB.

L’authentification compare services gérés et solutions internes.

Après avoir classé les pages, il faut aligner backend et déploiement sur la frontière frontend choisie.