React et Next.js — des applications web hautement performantes
Nous utilisons React 18 et Next.js 15 (App Router) pour la plateforme 4myevents : le site de présentation et le panneau de l’équipe d’organisation, avec les événements, les types de billets, les participants, le contrôle d’accès, le programme et les rapports. Le code est en TypeScript strict, les tests sont automatisés et le déploiement se fait sans interruption de service.
Pourquoi Next.js pour nos projets
Next.js 15 avec App Router offre un modèle hybride unique : les pages statiques (SSG) sont servies instantanément depuis le CDN, les pages dynamiques s’exécutent en Server Components qui n’envoient aucun JavaScript superflu au navigateur, et les pages en temps réel utilisent des Client Components isolés. Résultat : un score Lighthouse de 95+ d’emblée, sans artifice.
Les images sont optimisées automatiquement via le composant `<Image>` (WebP/AVIF, srcSet responsive, chargement différé), 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 ramènent le LCP sous 2,5 secondes sur de vrais réseaux 4G.
- Server Components pour les pages du site de présentation — zéro JS côté client, exploration instantanée
- SSR en streaming avec Suspense pour les écrans aux données chargées progressivement
- Incremental Static Regeneration (ISR) pour les articles de blog et les pages de contenu — sans rebuild
- Route Groups et Parallel Routes pour des mises en page complexes sans nouveau rendu
TypeScript strict — pas de bugs silencieux
Tous nos projets utilisent TypeScript avec `strict: true`, `noImplicitAny`, `exactOptionalPropertyTypes` et `noUncheckedIndexedAccess`. Ces réglages bloquent dès la compilation des catégories entières de bugs d’exécution : accès à des valeurs indéfinies, types incomplets sur les réponses d’API, comparaisons erronées. Un projet type compte 0 erreur TypeScript en CI avant le moindre test.
Pour la gestion d’état, nous utilisons Zustand (léger, sans code répétitif) 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 utilisent React Hook Form + validation de schéma Zod — validation synchrone et asynchrone sans code dupliqué.
- ESLint avec des règles personnalisées pour les motifs interdits (any, console.log, chaînes magiques)
- Prettier avec une configuration uniforme — aucune PR rejetée pour le formatage
- Zod pour la validation à l’exécution des données provenant d’API externes
- Alias de chemins (`@/components/...`) — des imports propres sans `../../..`
Tests automatisés et CI/CD
Tests unitaires avec Vitest (rapide, compatible avec l’API Jest), tests de composants avec React Testing Library, tests 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 si l’un d’eux échoue. Couverture minimale de 80 % sur la logique métier.
- Lighthouse CI — un score <90 bloque le déploiement en préproduction
- Analyseur de bundle automatique — alerte si le bundle grossit de >5 % par rapport à main
- Storybook pour les composants d’interface — une documentation visuelle vivante
Avantages et limites
Avantages
- Lighthouse 95+ dès le premier jour, sans réglage manuel.
- SSR et SSG natifs — du HTML complet pour Google et les moteurs d’IA.
- TypeScript strict détecte 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.
- Changements incompatibles fréquents entre versions majeures — maintenance nécessaire.
- Pour un site statique simple, Next.js peut être disproportionné face à du HTML brut.
- Les gros builds allongent le temps de compilation et le coût de la CI.
Verdict rapide
Choisissez React et Next.js pour les sites et applications web qui doivent être rapides, indexables et évolutifs. Pour une simple page d’atterrissage statique sans interactivité, un outil plus simple suffit.
Tableau des spécifications
| Capacité | Limite / seuil | Usage type | |
|---|---|---|---|
| Rendu | SSR, SSG, ISR, CSR | Les Server Components limitent les API du navigateur | Marketing statique + tableau de bord dynamique |
| Performances | LCP < 2,5 s, Lighthouse 95+ | Le JS d’hydratation croît avec l’interactivité | Sites à fort trafic, critiques pour le SEO |
| Montée en charge | Des dizaines de milliers d’utilisateurs, CDN en périphérie | Nécessite un hébergement Node ou serverless | SaaS, portails, plateformes de gestion d’événements |
| Coût type | Open source, hébergement dès ~0 € | Fonctions serverless facturées à l’usage | Des petits projets à 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) |
| Idéal pour un site purement statique | Bon | Astro est plus léger |
Questions fréquentes
Pourquoi Next.js et pas React seul (Vite) ?
React avec Vite n’effectue le rendu que côté client : le HTML initial est donc vide — mauvais pour le SEO et le GEO. Next.js ajoute le SSR et le SSG et livre un HTML complet que Google et les moteurs d’IA lisent immédiatement.
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 sur le serveur, et les Core Web Vitals sont au vert par conception — autant de signaux de classement forts.
Puis-je migrer un site existant vers Next.js ?
Oui, progressivement : les pages migrent une à une, en conservant les URL et les redirections 301 afin de ne pas perdre le positionnement Google.
Quel hébergement Next.js requiert-il ?
Les pages statiques fonctionnent sur n’importe quel CDN. Les fonctionnalités dynamiques (SSR, routes d’API) nécessitent Node.js ou un environnement serverless comme Vercel, Netlify ou un conteneur Docker.