Le vrai coût d’un nouveau projet

Créer un dossier Next.js ou Vite ne prend que quelques secondes. Construire une base d’application cohérente prend beaucoup plus de temps.

Il faut choisir une base de données, connecter un ORM, préparer l’authentification, valider les variables d’environnement, organiser les routes, ajouter les paiements ou l’IA, puis vérifier que toutes ces décisions restent compatibles. Ce travail est nécessaire, mais il se répète d’un projet à l’autre. Et plus on assemble de services, plus le risque d’obtenir une architecture difficile à comprendre augmente.

J’ai créé Nextron pour réduire ce coût de départ. Ce n’est pas un nouveau framework et il ne cherche pas à remplacer Next.js, Vite ou Express. C’est un générateur full-stack modulaire qui compose ces outils et écrit une base TypeScript ordinaire, directement dans votre projet. Le dépôt public décrit le principe simplement : choisir la stack et les modules nécessaires, puis conserver un code que l’on peut lire, modifier et déployer librement (dépôt Nextron sur GitHub).

Ce que Nextron génère

Nextron commence par une question structurante : quel type d’application voulez-vous construire ?

La première voie produit une application Next.js avec App Router. L’App Router repose sur le routage par fichiers et permet notamment d’utiliser les Server Components, Suspense et les Server Functions (documentation officielle de Next.js). À partir de cette base, Nextron peut configurer :

  • Drizzle ou Prisma ;
  • PostgreSQL, SQLite ou MySQL ;
  • Better Auth, Clerk ou NextAuth ;
  • tRPC, un module d’IA, Stripe, Polar ou Inngest ;
  • un dashboard protégé lié au fournisseur d’authentification choisi.

La seconde voie cible Vite + Node.js. Elle peut générer une API Express en TypeScript seule, ou un monorepo pnpm contenant l’API et une interface Vite + React. Vite fournit le serveur de développement et la chaîne de build du frontend (guide officiel de Vite), tandis qu’Express reste la couche HTTP minimale du backend (documentation officielle d’Express). Pour les données, cette stack propose MongoDB avec Mongoose ou SQL Server avec un helper de requêtes typé. Des modules de paiement Stripe et Polar sont également disponibles.

Cette deuxième stack a été introduite dans la version 0.1.3, avec la validation des modules selon leur cible : un module réservé à Next.js ne peut pas être ajouté par erreur à un projet Express, et inversement (changelog de Nextron).

L’objectif n’est donc pas de générer « tout ». Il est de générer uniquement les fondations choisies, déjà reliées entre elles.

Générer, puis s’effacer

Le choix le plus important de Nextron est peut-être ce qu’il ne fait pas : il n’ajoute aucun runtime propriétaire à votre application.

Une fois la génération terminée, le projet contient du code TypeScript classique. Les routes, les composants, les schémas et les intégrations sont dans votre dépôt. Vous pouvez les inspecter, les remplacer, les déplacer ou les supprimer. Votre application n’a pas besoin que Nextron tourne en production.

Cette approche évite une forme de dépendance souvent cachée dans les starters très abstraits. Le générateur est directif au moment de créer une base cohérente, puis il laisse la place au projet. Le fichier nextron.config.ts conserve les choix effectués afin que la CLI puisse comprendre la stack plus tard, mais il ne devient pas le cœur de l’application.

Une architecture pensée pour évoluer

La vitesse initiale n’a de valeur que si le code reste compréhensible après les premières fonctionnalités.

Dans une application Next.js générée, les fonctionnalités vivent sous src/modules. Les points d’entrée App Router restent légers et délèguent le travail aux modules. Les mutations, les requêtes en lecture seule et les types ont des emplacements explicites. Les variables d’environnement attendues sont regroupées et validées dans src/env.ts.

Cette organisation crée des frontières visibles :

TEXT
src/
├── app/
├── components/ui/
├── env.ts
├── modules/
│   ├── auth/
│   ├── database/
│   ├── dashboard/
│   ├── ai/
│   └── stripe/
└── shared/

Chaque projet inclut aussi des fichiers AGENTS.md et CLAUDE.md adaptés à la stack sélectionnée. Leur rôle est de donner aux agents de code les conventions réelles du projet : fournisseurs installés, limites entre modules et commandes de vérification. Ce contexte réduit le risque qu’un agent propose du code pour Prisma dans un projet Drizzle, ou mélange les API de plusieurs systèmes d’authentification.

Un projet peut ensuite évoluer sans être régénéré. La commande suivante ajoute, par exemple, le module Stripe :

BASH
npx @edwinfom/nextron@latest add stripe

Avant d’écrire, la CLI vérifie les dépendances et la compatibilité avec la stack. Elle préserve les fichiers de destination déjà présents, met à jour package.json et nextron.config.ts, puis propose d’installer les nouvelles dépendances (référence des modules Nextron).

Démarrer en quelques minutes

Le paquet public porte le nom complet @edwinfom/nextron. Pour lancer le générateur :

BASH
npx @edwinfom/nextron@latest create mon-app

La CLI demande ensuite la stack, la base de données, l’authentification, les modules et le gestionnaire de paquets. Un résumé apparaît avant la génération afin de vérifier les choix.

Une fois le projet créé :

BASH
cd mon-app
cp .env.example .env.local
pnpm dev

Il reste à remplacer les valeurs d’exemple dans .env.local et, si nécessaire, à préparer le schéma de base de données. Le guide de démarrage détaille les commandes pour Drizzle et Prisma ainsi que les fichiers attendus dans un projet valide (guide de démarrage Nextron).

À qui s’adresse Nextron ?

Nextron est utile lorsque l’on veut démarrer :

  • un produit SaaS ou un outil interne avec une base structurée ;
  • une API Express en TypeScript ;
  • un prototype qui doit pouvoir devenir un vrai produit ;
  • un projet sur lequel des développeurs et des agents de code vont collaborer.

Il est moins pertinent pour une application déjà avancée qui possède ses propres conventions, pour un projet hors de l’écosystème TypeScript, ou pour une équipe qui préfère déléguer toute l’infrastructure à une plateforme hébergée. Nextron accélère un point de départ ; il ne remplace ni les décisions métier, ni les tests, ni la sécurité, ni l’exploitation en production.

Construire plus vite sans abandonner la compréhension

Je ne voulais pas créer une autre boîte noire. Je voulais transformer une série de décisions répétitives en un flux guidé, tout en laissant derrière lui du code ordinaire.

C’est la promesse de Nextron : générer la bonne fondation, rendre chaque choix visible, puis vous laisser construire.

Le projet est open source sous licence MIT. Vous pouvez consulter le code, essayer la CLI et suivre son évolution sur le dépôt GitHub, ou ouvrir la page du paquet @edwinfom/nextron sur npm.

Sources

1. Nextron — dépôt et README 2. Nextron — guide de démarrage 3. Nextron — référence des modules 4. Nextron — changelog de la CLI 5. Next.js — App Router 6. Vite — Getting Started 7. Express — documentation officielle