Notre stack de référence — et pourquoi

Chez Citadelle, presque tous nos produits sont construits avec Next.js. Ce n'est pas un choix par défaut — c'est une décision réfléchie qu'on réévalue régulièrement. En 2026, elle tient toujours.

Ce qui a changé depuis Next.js 13

L'App Router a mis du temps à mûrir. Les premières versions avaient des bugs de caching difficiles à déboguer. En 2025-2026, c'est derrière nous.

Ce qu'on utilise aujourd'hui avec confiance :

• React Server Components : la séparation server/client est claire et productive. On réduit significativement le JavaScript envoyé au client.
• Streaming SSR : les pages complexes s'affichent progressivement. L'utilisateur voit quelque chose en moins de 200ms même avec beaucoup de données.
• Server Actions : les mutations de données sans API route intermédiaire, pour les projets qui n'ont pas besoin d'une API publique.

L'écosystème qui fait la différence

Next.js seul ne suffit pas. Ce qui rend la stack productive, c'est l'écosystème :

• Vercel ou auto-hébergement via notre Dockerfile standalone
• Supabase pour la base de données et l'auth sur les projets rapides
• Prisma quand le schéma est complexe
• TypeScript strict en standard

Tout ce stack s'intègre sans friction. On passe moins de temps sur la configuration et plus sur le produit.

Quand Next.js n'est pas le bon choix

• Site statique simple : Astro est plus adapté.
• App mobile : Next.js ne remplace pas React Native.
• Backend lourd sans frontend : un service Node.js ou Go est plus approprié.
• Lock-in Vercel : si vous avez des contraintes d'infrastructure fortes, l'auto-hébergement fonctionne mais demande de la rigueur ops.

Ce que ça donne en production

Sur les produits qu'on maintient : Lighthouse > 90 systématiquement, TTI < 2s sur mobile, déploiements en < 3 minutes via notre pipeline CI/CD.

Next.js en 2026 est mature, bien documenté, et dispose d'une communauté massive. Pour la plupart des produits digitaux, c'est le choix qui minimise le risque et maximise la vélocité.