Pourquoi Next.js est notre stack par défaut (et quand on ne le choisit pas)

Si vous jetez un œil au portfolio de Pair Programming, un pattern saute aux yeux : la quasi-totalité des projets partagent la même stack. Next.js en tant que framework, React pour l’interface utilisateur, Supabase comme base de données et backend, Tailwind et shadcn/ui pour le design. Ce n’est ni par hasard ni par flemme. C’est une décision architecturale réfléchie. Voici pourquoi.

Notre grille d’évaluation : les critères qui comptent

Avant de défendre ce stack, voici les critères qui guident nos choix :

1. Time-to-market : pouvoir livrer rapidement un produit opérationnel.
2. Maintenabilité : qu’un développeur puisse comprendre et modifier le code 18 mois plus tard.
3. Coût d’exploitation : éviter les frais mensuels fixes élevés.
4. Performances perçues : garantir une expérience utilisateur fluide et réactive.
5. SEO friendly : essentiel pour les produits accessibles au public.
6. Écosystème : disposer de solutions préexistantes pour résoudre les problèmes courants.

Pourquoi Next.js ?

Ce framework coche toutes les cases mieux que ses concurrents actuels :

Rendering hybride natif. Next.js permet à chaque page de choisir entre plusieurs modes de rendu : serveur (SSR), statique au build (SSG), ou côté client (CSR). Une flexibilité énorme : les pages d’accueil et les landings sont statiques (ultra-rapides, SEO optimisé), les dashboards internes utilisent le SSR avec authentification, et les composants fortement interactifs tournent côté client. Une seule codebase, des modes adaptés à chaque usage.

App Router et Server Components. Depuis Next.js 13 avec l’App Router, les composants sont servis par défaut côté serveur. Résultat : moins de JavaScript envoyé au client, des performances améliorées, et la possibilité d’effectuer des requêtes à la base de données directement depuis le composant, sans API intermédiaire.

Optimisations intégrées par défaut. next/image gère le lazy loading, le srcset et les formats modernes automatiquement. next/font charge les polices sans décalage de mise en page. next/script contrôle l’ordre d’exécution des scripts tiers. Des optimisations qui prendraient des semaines dans d’autres stacks sont disponibles dès le départ.

SEO de premier ordre. La structure du framework est conçue pour les sites indexables : API de métadonnées par page, sitemap.ts dynamique, robots.ts, réécritures et redirections configurables, données structurées simplifiées. Nous avons mis en place un SEO programmatique générant des centaines de pages indexables sans conflit avec le framework.

Déploiement sur Vercel. Zéro configuration, réseau edge mondial, scaling automatique, aperçus pour chaque pull request. Le coût démarre à 0 USD et n’augmente qu’en cas de trafic réel.

Pourquoi Supabase comme partenaire idéal

React seul ne suffit pas : il faut des données, une authentification, du stockage. Les options ? Tout coder soi-même (long), AWS de zéro (complexe), ou opter pour un BaaS (Backend-as-a-Service). Parmi les BaaS, Supabase se distingue par :

• PostgreSQL réel, pas une pseudo-base comme Firebase. SQL, relations, transactions : tout ce qu’on attend d’une base de données.
• Auth complète intégrée, avec magic links, OAuth, connexions sociales.
• Sécurité au niveau des lignes (Row Level Security) directement en base, cruciale pour les applications multi-tenant.
• Stockage de fichiers avec CDN intégré.
• Open source, avec la possibilité de s’auto-héberger si nécessaire.
• pgvector pour les embeddings et l’IA (utilisé dans Tontin).
• Edge functions pour une logique serveur personnalisée.

Ce stack en action : 4 projets aux usages variés

La force de ce stack réside dans sa capacité à s’adapter à des contextes très différents sans friction :

Mi Seguro de Auto : produit public à fort trafic SEO, intégrations avec des assureurs. Next.js génère des pages optimisées pour Google, Supabase stocke les cotisations et les leads. Chaque page est légère et se charge rapidement sur mobile (utilisé par 80 % des utilisateurs pour leurs devis).

La Carolina : CRM interne sans besoin de SEO mais exigeant une authentification robuste, un multi-tenant et des performances pour des opérations complexes. Même stack, approche différente : Server Components pour le fetching de données, RLS pour l’isolation, synchronisation bidirectionnelle avec Google Calendar via edge functions.

Tontin : plateforme IA lourde, avec embeddings et une chaîne de fallback de multiples LLM. Next.js orchestre le frontend et l’API, Supabase stocke les conversations et les embeddings avec pgvector, les edge functions gèrent les appels aux modèles.

Zweifel Capital : site premium pour un family office à Londres, Buenos Aires et Nassau. Pages statiques pures, design soigné, multilingue. Next.js + Tailwind, déploiement statique sur Vercel. Aucune base de données, aucun backend : tout est géré en edge. Une autre facette du même stack.

Quand on ne choisit PAS Next.js

Certains cas d’usage nécessitent une approche différente :

• Backend lourd sans interface : si votre besoin se limite à une API pure sans frontend, Fastify ou NestJS sont plus adaptés.

• Applications mobiles natives : React Native est une autre histoire. Pour des performances natives maximales, Flutter ou Swift/Kotlin natifs sont incontournables.

• Applications temps réel complexes : pour un éditeur collaboratif type Figma ou un jeu multijoueur, il faut une stack plus lourde côté client, comme Vue + Pinia + WebRTC.

• Sites ultra-simples : une landing page pour un seul produit peut être développée avec Astro ou même en HTML/CSS brut. Next.js serait du sur-dimensionnement.

L’argument imparable : l’ennui (le bon !)

Le meilleur avantage d’un stack cohérent est l’ennui productif. Plus besoin, à chaque nouveau projet, de réévaluer les options, de débattre ou de partir de zéro. L’équipe maîtrise les outils, les patterns se réutilisent, et les problèmes courants ont déjà des solutions éprouvées. Cela libère de l’énergie pour résoudre les vrais défis : ceux de nos clients.

Conclusion

Next.js + React + Supabase + Tailwind couvre l’écrasante majorité des applications web modernes. Ce n’est pas la solution optimale pour tout, mais elle est suffisamment performante pour la plupart des cas et excellente pour les plus fréquents. Cette combinaison de polyvalence et de maturité en fait le choix par défaut le plus raisonnable aujourd’hui.

En train de choisir votre stack pour un nouveau projet ou d’envisager une migration ? Prenons contact : nous vous aidons à prendre une décision technique éclairée, adaptée à votre produit, votre équipe et vos délais.

---

Par Esteban Aleart, Fondateur & Lead Engineer chez Pair Programming.