React & Next.js — Applications web haute performance
Nous utilisons React 18 et Next.js 15 (App Router) sur tous nos projets frontend : du site vitrine au SaaS complexe servant des dizaines de milliers d'utilisateurs. Le code est en TypeScript strict, les tests sont automatisés et le déploiement suit un pipeline CI/CD.
Pourquoi Next.js pour nos projets
Next.js 15 avec App Router propose un modèle hybride unique : les pages statiques (SSG) sont servies depuis le CDN, les pages dynamiques s'exécutent en Server Components qui n'envoient aucun JavaScript inutile au navigateur, et les pages à données temps réel s'appuient sur des Client Components isolés.
Les images sont optimisées automatiquement par le composant `<Image>` (WebP/AVIF, srcSet responsive, lazy loading), les polices sont intégrées au CSS critique avec `next/font`, et les scripts tiers se chargent selon des stratégies de priorité. Ensemble, ces optimisations ciblent l'indicateur LCP sur les réseaux mobiles.
- Server Components pour les pages marketing — zéro JS côté client
- Streaming SSR avec Suspense pour les tableaux de bord à données live
- Incremental Static Regeneration (ISR) pour les contenus semi-dynamiques
- Route Groups et Parallel Routes pour des mises en page complexes sans re-render
TypeScript strict — aucun bug silencieux
Tous nos projets utilisent TypeScript avec `strict: true`, `noImplicitAny`, `exactOptionalPropertyTypes` et `noUncheckedIndexedAccess`. Ces réglages bloquent à la compilation des catégories entières de bugs d'exécution : accès à undefined, types incomplets sur les réponses d'API, comparaisons erronées. Un projet type affiche 0 erreur TypeScript en CI avant même le moindre test.
Pour la gestion d'état, nous utilisons Zustand (léger, sans boilerplate) ou React Context pour l'état local. La récupération des données passe par TanStack Query (cache automatique, invalidation intelligente, stale-while-revalidate). Les formulaires reposent sur React Hook Form et la validation par schéma Zod — validation synchrone et asynchrone sans code dupliqué.
- ESLint avec des règles maison pour les motifs interdits (any, console.log, chaînes magiques)
- Prettier avec une configuration uniforme — aucune PR rejetée pour un problème de formatage
- Zod pour valider à l'exécution les données issues d'API externes
- Alias de chemins (`@/components/...`) — des imports lisibles sans `../../..`
Tests automatisés et CI/CD
Tests unitaires avec Vitest (rapide, compatible avec l'API Jest), tests de composants avec React Testing Library, E2E avec Playwright sur 3 navigateurs (Chromium, Firefox, WebKit). Le pipeline GitHub Actions exécute tous les tests à chaque PR ; la fusion est bloquée dès qu'un test échoue. Couverture minimale de 80 % sur la logique métier.
- Lighthouse CI — un score inférieur à 90 bloque le déploiement en staging
- Analyseur de bundle automatique — alerte si le bundle grossit de plus de 5 % par rapport à main
- Storybook pour les composants d'interface — une documentation visuelle vivante
Avantages et limites
Avantages
- Optimisations de rendu intégrées : images, polices et scripts tiers.
- SSR et SSG natifs — du HTML complet pour Google et les moteurs d'IA.
- TypeScript strict attrape les bugs à la compilation, pas en production.
- Écosystème mature : Vercel, des milliers de paquets, une immense communauté.
Limites
- La courbe d'apprentissage de l'App Router et des Server Components est raide.
- Des changements fréquents entre versions majeures — un entretien régulier est nécessaire.
- Pour un site statique simple, Next.js peut être surdimensionné face à du HTML pur.
- Les gros builds allongent le temps de compilation et alourdissent la facture CI.
Verdict en bref
Choisissez React & Next.js pour des sites et des applications web qui doivent être rapides, indexables et évolutifs. Pour une simple landing page statique sans interactivité, une solution plus légère suffit.
Tableau des spécifications
| Capacité | Limite / seuil | Usage courant | |
|---|---|---|---|
| Rendu | SSR, SSG, ISR, CSR | Les Server Components limitent les API du navigateur | Marketing statique + tableau de bord dynamique |
| Performance | Server Components et JS limité aux composants interactifs | Le JS d'hydratation croît avec l'interactivité | Sites à fort trafic, SEO critique |
| Montée en charge | Des dizaines de milliers d'utilisateurs, CDN en edge | Nécessite un hébergement Node ou serverless | SaaS, portails, e-commerce |
| Coût courant | Open source, hébergement à partir d'environ 0 € | Les fonctions serverless sont facturées à l'usage | Du petit projet à l'entreprise |
Next.js face aux alternatives
| Critère | Next.js | Nuxt / Astro / Vite |
|---|---|---|
| SSR + SSG dans un seul framework | Oui, nativement | Partiellement (Nuxt oui, Vite non) |
| Écosystème React | Complet | Vue (Nuxt) ou multi-framework (Astro) |
| Optimal pour un site purement statique | Bon | Astro est plus léger |
Questions fréquentes
Pourquoi Next.js plutôt que React seul (Vite) ?
React avec Vite ne fait le rendu que côté client : le HTML initial est donc vide, ce qui pénalise le SEO et le GEO. Next.js ajoute le SSR et le SSG et livre un HTML complet, lisible par Google et par les moteurs d'IA.
Next.js est-il bon pour le SEO ?
Oui. Le SSR/SSG livre du HTML indexable, les métadonnées et le JSON-LD sont générés côté serveur, et le framework intègre des optimisations pour les Core Web Vitals — autant de signaux forts pour le classement.
Puis-je migrer un site existant vers Next.js ?
Oui, de façon incrémentale : les pages sont déplacées une à une en conservant les URL et les redirections 301.
Quel hébergement Next.js exige-t-il ?
Les pages statiques fonctionnent sur n'importe quel CDN. Les fonctions dynamiques (SSR, routes d'API) réclament Node.js ou un runtime serverless comme Vercel, Netlify ou un conteneur Docker.