ADR-004 - Next.js pour les applications web (architecture multi-app)

• Statut : Accepté
• Date : 2026-04-05

Contexte

L’application web doit servir deux audiences aux besoins très différents :

• Agriculteurs (web-agri) : consultation de parcelles, suivi d’actions, accès à la marketplace
• Pilotes de drone (web-pilots) : gestion de missions, suivi de vol, interface opérationnelle

Les rôles, les parcours utilisateurs et les interfaces sont suffisamment distincts pour justifier une séparation applicative. L’équipe a de l’expérience en React et cherche une solution avec SSR et bon support TypeScript.

Décision

Nous utilisons Next.js avec TypeScript pour les deux frontends web, organisés en deux applications distinctes dans le monorepo : web-agri (port 3001) et web-pilots (port 3002), partageant les packages api, auth et env.

Alternatives considérées

• Une seule application Next.js avec routing par rôle : moins de duplication de configuration, mais couplage plus fort entre les deux surfaces et risque de fuite de code entre rôles
• Angular : framework complet avec opinions fortes, mais courbe d’apprentissage plus raide et moins adapté à l’écosystème oRPC/TanStack
• React sans framework (Vite + React Router) : plus léger, mais sans SSR natif ni App Router
• Vue.js / Nuxt : écosystème plus léger, mais moins maîtrisé par l’équipe

Conséquences

• SSR natif via App Router pour de meilleures performances initiales et le SEO
• Architecture dual-client oRPC : appels directs en Server Components (zéro overhead réseau), hooks TanStack Query en Client Components
• Séparation claire des surfaces par audience, sans risque de fuite de logique ou d’UI entre rôles
• Duplication de la configuration Next.js entre les deux apps (atténuée par packages/config)
• Deux processus de build distincts à maintenir
• Dépendance forte à l’écosystème Next.js / Vercel pour les évolutions du framework