Aller au contenu principal
ValidéBaptiste2026-08-07

Utiliser Astro pour les sites éditoriaux et Next.js pour les outils métier

Statut de la décision​

Acceptée

Contexte​

Les offres B1 et B2 produisent toutes les deux des applications web, mais leurs contraintes diffèrent.

B1 vise principalement des pages publiques, du contenu éditorial, une forte performance et peu de logique côté navigateur. B2 vise des outils authentifiés avec formulaires, états, règles métier et interactions fréquentes.

Utiliser un framework unique simplifierait marginalement la formation et les composants partagés, mais imposerait le mauvais compromis à l'une des deux offres.

Décision​

Astro avec TypeScript est le framework de référence pour B1 et les portails principalement éditoriaux.

Next.js avec TypeScript est le framework de référence pour B2 et les outils métier authentifiés.

Une dérogation est possible lorsqu'une contrainte fonctionnelle le justifie. Elle doit être documentée pendant le cadrage.

Options considérées​

Astro pour toutes les offres web​

Astro produit des sites statiques rapides et limite le JavaScript côté client. Il reste adapté aux contenus et interfaces faiblement interactives.

Il n'est pas retenu comme référence universelle car une application métier riche nécessiterait davantage de conventions propres au projet pour l'authentification, les mutations, les états et les règles serveur.

Next.js pour toutes les offres web​

Next.js fournit dans une même base de code le rendu serveur, les endpoints et les composants interactifs.

Il n'est pas retenu pour B1 par défaut car un site éditorial statique n'a pas besoin de cette surface applicative. Astro produit un résultat plus simple et plus facilement transférable pour ce cas.

Deux références selon le produit​

Cette option est retenue car elle aligne le framework sur le type de produit plutôt que sur une préférence technique unique.

Conséquences​

Gains​

  • B1 conserve une sortie statique performante et portable.
  • B2 dispose d'une stack adaptée aux interactions et règles métier.
  • Le choix peut être expliqué par le périmètre du produit.
  • Les deux stacks utilisent TypeScript et peuvent partager des pratiques de qualité.

Coûts acceptés​

  • Alpene maintient des compétences sur deux frameworks.
  • Les composants ne sont pas toujours transférables directement.
  • Le cadrage doit distinguer un portail éditorial d'un véritable outil métier.

Conditions de révision​

Cette décision sera revue si :

  • l'une des deux stacks ne permet plus de maintenir les offres efficacement ;
  • une contrainte client impose un framework différent ;
  • un benchmark montre qu'une stack unique couvre les deux cas sans complexité supplémentaire.