Pourquoi on choisit toujours Next.js + Postgres pour les vraies web apps en 2026

Résumé : Pour la plupart des produits sérieux, Next.js + PostgreSQL reste notre défaut—prévisible, recrutable, et suffisant jusqu'à de vraies contraintes.

Tous les six mois, un nouveau framework débarque en promettant 10× la performance, la moitié du bundle, et un mental model flambant neuf. La plupart sont vraiment intéressants. Presque aucun n'est le bon choix pour une boîte qui a besoin que l'app marche encore en 2030.

Les défauts qui ont gagné leur place

Notre stack par défaut pour les vraies applications web n'a pas vraiment bougé depuis trois ans : Next.js (App Router) + TypeScript + PostgreSQL + Tailwind, déployé sur Vercel ou un petit VPS, avec Stripe pour la facturation et un Postgres managé type Neon ou Supabase quand l'équipe est petite. Ennuyeux. Prévisible. Facile à recruter.

Pourquoi Next.js, précisément

Pas parce que c'est le framework le plus rapide en benchmarks (généralement non). Parce que c'est le framework où :

• Le rendu côté serveur, la génération statique et le rendu client marchent tous out of the box, dans le même projet, avec le même mental model
• Le SEO marche sans setup Gatsby/Astro séparé ou un CMS headless
• Les routes API, l'optimisation d'images, le routing i18n et le middleware sont natifs — pas trois plugins collés ensemble
• Le recrutement est réaliste : un dev React compétent devient productif en jours, pas en semaines
• L'écosystème (libs d'auth, kits UI, ORMs) prend tous Next.js comme cible

Pourquoi Postgres, précisément

Postgres est ce qui se rapproche le plus en logiciel d'un pari sûr. Il fait les requêtes relationnelles magnifiquement, des colonnes JSON quand il faut, du full-text search assez bon pour zapper Elasticsearch les premières années, des requêtes géographiques via PostGIS, et maintenant même de la vector search via pgvector. Une seule base. Une seule story de backup. Une seule chose à monitorer.

Ce qu'on évite explicitement jusqu'à y être forcés

• NoSQL « par défaut ». La plupart des équipes prennent MongoDB et passent ensuite deux ans à recoder des joins à la main.
• Microservices sous 10 ingénieurs. Le coût opérationnel est réel ; le bénéfice architectural ne l'est pas, jusqu'à ce que vous ayez des problèmes d'organisation.
• Bases serverless pour les workloads write-heavy. Cold starts et tarification à la requête punissent exactement les apps qui marchent.
• Design systems custom avant le product-market fit. shadcn/ui + Tailwind couvrent 90% des besoins à 5% du temps.

Quand on dévie du défaut

On change effectivement de stack — mais seulement quand le projet le demande vraiment :

• Apps temps-réel à forte concurrence (chat, trackers live, multijoueur) : on ajoute un service WebSocket dédié et Redis, parfois en Go ou Elixir.
• Traitement de données lourd ou pipelines ML : services Python à côté de l'app Next.js, parlant via une queue.
• Produits mobile-first avec support offline : React Native ou un vrai shell natif, partageant le même backend Postgres.

La question qui compte plus que la stack

« Le prochain dev peut-il reprendre cette codebase en deux semaines ? » Si la réponse est oui, vous avez choisi la bonne stack. Si la réponse implique d'expliquer un framework custom, un build system fait maison, ou un runtime dont personne n'a entendu parler — vous avez choisi quelque chose qui deviendra du legacy plus vite que vous ne le pensez.

Ennuyeux est une fonctionnalité. Ennuyeux, c'est ce qui marche encore en 2030.