Les 5 phases de la méthode NXL Forge
| Phase | Durée typique | Livrable | Acteur principal |
|---|---|---|---|
| 1. Cadrage | 1 – 2 jours | Cahier des charges validé | NXL Forge + Client |
| 2. Architecture | 0,5 – 1 jour | Schéma BDD + arborescence | NXL Forge |
| 3. Développement IA | 3 – 20 jours | Application fonctionnelle sur staging | NXL Forge |
| 4. Tests & recette | 1 – 2 jours | Rapport de tests + corrections | NXL Forge + Client |
| 5. Livraison | 0,5 jour | Code + accès + documentation | NXL Forge |
Phase 1 — Cadrage et cahier des charges
Objectif
Transformer un besoin exprimé en langage métier en une spécification technique précise et partagée. Un cadrage bien fait prévient 80 % des litiges et des malentendus en cours de projet. C'est la phase la plus importante — et la moins coûteuse à corriger si quelque chose est mal défini.
Ce que le client prépare
- Une description du problème à résoudre (pas nécessairement une solution technique)
- Les profils des utilisateurs qui utiliseront l'application et leurs besoins distincts
- Les contraintes non négociables : conformité réglementaire, intégrations obligatoires, délai
- Les exemples de concurrents ou d'outils existants qui se rapprochent de ce que vous cherchez
NXL Forge met à disposition un générateur de cahier des charges en ligne qui structure ces éléments en 15 minutes via une série de questions guidées. Le document généré sert de base de travail pour la réunion de cadrage et évite les heures passées à rédiger un document from scratch.
Ce que NXL Forge produit
- Périmètre fonctionnel structuré par module avec critères d'acceptation
- Matrice des rôles utilisateurs et des droits d'accès associés
- Liste des intégrations tierces identifiées avec impact estimé
- Estimation ferme du nombre de jours et du budget
- Identification des risques et des points à clarifier avant développement
Un cahier des charges utile n'est pas exhaustif — il est précis sur ce qui compte. Décrire ce que chaque rôle doit pouvoir faire (et ne pas pouvoir faire) est plus utile que cent pages sur des fonctionnalités hypothétiques. NXL Forge fixe volontairement le périmètre au strict nécessaire pour livrer une valeur immédiate — les évolutions viennent après les retours des premiers utilisateurs réels.
Phase 2 — Architecture technique
Pourquoi cette phase est critique
L'architecture conditionne la qualité de tout ce qui suit. Une mauvaise modélisation de la base de données génère des requêtes complexes et lentes à chaque module. Un mauvais choix de stack crée des frictions tout au long du développement. Cette phase prend 0,5 à 1 jour mais économise plusieurs jours de refactoring en aval.
La stack par défaut NXL Forge
NXL Forge travaille sur une stack moderne, éprouvée et parfaitement maîtrisée par les LLMs de génération de code :
- Next.js 14 (App Router) — framework React fullstack, rendu serveur et client, API Routes intégrées
- TypeScript strict — typage complet, zéro
any, erreurs détectées à la compilation - Prisma ORM + PostgreSQL — schéma de base de données typé, migrations automatisées, requêtes sécurisées
- Vercel — déploiement continu, edge network mondial, scaling automatique
- Resend — emails transactionnels (confirmations, notifications, réinitialisation de mot de passe)
- Stripe — paiements et abonnements si applicable
Les livrables de la phase architecture
À l'issue de cette phase, NXL Forge produit un schéma de base de données commenté avec toutes les entités et leurs relations, l'arborescence des routes et des composants principaux, et les choix techniques justifiés pour les modules complexes. Ces documents sont partagés avec le client avant le démarrage du développement.
Phase 3 — Développement piloté par IA
La boucle de développement
Le développement suit une boucle module par module. Pour chaque module, le processus est identique :
Spécification du module
Le développeur définit précisément ce que le module doit faire : entrées, sorties, règles de validation, cas d'erreur, comportement attendu selon le rôle. Plus la spécification est précise, plus le code généré est juste du premier coup.
Génération et première validation
Le modèle IA génère le code du module. Le développeur revue immédiatement le résultat : logique correcte, TypeScript strict, gestion des erreurs, sécurité. Les corrections sont appliquées avant intégration.
Intégration et test local
Le module est intégré dans le projet global et testé dans le contexte réel : interactions avec les autres modules, données de base de données réelles, comportement avec différents rôles utilisateurs.
Déploiement sur staging
Chaque module terminé est déployé sur l'environnement de staging accessible par le client. La démo est continue — le client voit l'application se construire en temps réel, sans attendre la livraison finale.
La gestion des imprévus
Tout projet rencontre des imprévus : une API tierce dont la documentation est incomplète, une règle métier plus complexe que prévu, une contrainte technique découverte en cours de route. NXL Forge applique une règle simple : si un imprévus consomme moins d'un demi-jour, il est absorbé sans discussion. Au-delà, il est signalé au client avec une estimation de l'impact et une proposition de traitement avant de continuer.
Phase 4 — Tests et recette
Les tests automatisés
Avant la recette client, NXL Forge exécute une suite de tests automatisés sur l'intégralité de l'application. Ces tests couvrent trois niveaux :
- Tests unitaires sur la logique métier critique (calculs, transformations de données, règles de validation)
- Tests d'intégration sur les routes API (authentification, autorisation, formats de réponse)
- Tests end-to-end Playwright sur les parcours utilisateurs principaux (inscription, connexion, flux métier central, déconnexion)
Les tests qui échouent sont corrigés avant que la recette client commence. Le rapport de tests est inclus dans les livrables finaux.
La recette client
La recette est une session d'une heure avec le client sur l'environnement de staging. NXL Forge présente chaque module en suivant les critères d'acceptation définis lors du cadrage. Le client valide, pose des questions et signale les ajustements. Les corrections identifiées sont intégrées dans les heures qui suivent.
La recette ne doit pas être un moment de découverte pour le client : si la démo sur staging a été suivie régulièrement en phase 3, la plupart des ajustements ont déjà été identifiés et traités.
Phase 5 — Livraison et transfert
Ce que vous recevez à la livraison
- Code source complet — dépôt Git avec l'historique de tous les commits, transféré à votre organisation GitHub/GitLab
- Documentation d'architecture — diagramme entité-relation, description des modules, flux API principaux
- Guide de déploiement — instructions pas à pas pour déployer sur Vercel, configurer les variables d'environnement, connecter la base de données
- Inventaire des services tiers — liste de tous les services utilisés (Stripe, Resend, etc.) avec les comptes créés et les credentials transférés
- Suite de tests — fichiers de tests Playwright et instructions pour les exécuter en local et en CI
- Appel de passation — 1 heure avec votre équipe technique pour répondre aux questions sur le code et l'architecture
La garantie de 30 jours
Les 30 jours suivant la mise en production sont couverts sans frais supplémentaires. Si un comportement ne correspond pas aux critères d'acceptation du cahier des charges, NXL Forge le corrige en priorité. Cette garantie couvre les bugs, pas les évolutions de périmètre.
Timelines réelles : deux projets semaine par semaine
Empreinte Fiscale — 5 jours de développement
SaaS de transparence fiscale : 14 modules, 78 écrans, logique de calcul complexe, open source. Le périmètre avait été défini précisément en amont, ce qui a permis de démarrer l'architecture dès le jour 1.
| Jour | Travail effectué |
|---|---|
| J1 | Cadrage final + architecture BDD + setup Next.js / Prisma / auth |
| J2 | Modules calculs fiscaux (logique cœur) + tests unitaires calculs |
| J3 | Quiz interactif + profils types + visualisations de données |
| J4 | Dashboard utilisateur + export + modules secondaires (6 modules) |
| J5 | Tests Playwright + recette + corrections + mise en production |
Champaura — 10 jours de développement
Plateforme de gestion de championnat de golf inter-clubs : 3 rôles, classements temps réel, 6 clubs. La complexité du temps réel et des trois interfaces distinctes a nécessité une architecture plus élaborée.
| Période | Travail effectué |
|---|---|
| S1 J1-2 | Cadrage + architecture multi-rôles + modélisation championnat / équipes / matchs |
| S1 J3-5 | Espace administrateur complet + gestion des clubs, équipes et journées |
| S2 J1-3 | Espace capitaines + saisie des résultats + classements temps réel |
| S2 J4-5 | Espace public + tests Playwright multi-rôles + recette + mise en production |
Les deux projets ont en commun une phase de cadrage courte mais dense, une architecture posée en moins d'un jour, et un développement qui avance module par module avec déploiement continu. La différence de durée (5 vs 10 jours) reflète directement la différence de périmètre : 3 interfaces distinctes avec temps réel nécessitent deux fois plus de travail qu'une interface unique avec calculs complexes.
Questions fréquentes sur la méthode
Dois-je avoir un cahier des charges complet avant de contacter NXL Forge ?
Non. Beaucoup de clients arrivent avec une idée et quelques contraintes. NXL Forge propose un générateur de cahier des charges en ligne qui structure le besoin en 15 minutes. Lors de la réunion de cadrage (1 heure), nous affinons ensemble le périmètre. Un cahier des charges trop rigide en amont est souvent contre-productif — mieux vaut un scope clair et maîtrisé qu'un document exhaustif qui change dès le premier sprint.
Combien de réunions sont nécessaires pendant le développement ?
Typiquement deux à trois points formels : la réunion de cadrage (1h), un point mi-parcours pour validation des modules principaux (30 min), et la réunion de recette finale (1h). Entre ces jalons, le client suit l'avancement en temps réel sur l'environnement de démo accessible en permanence. NXL Forge privilégie la démo au compte-rendu écrit.
Que se passe-t-il si le périmètre change en cours de développement ?
Les demandes d'évolution en cours de projet sont traitées de deux façons : si elles concernent le périmètre initial mal défini (un oubli dans le cadrage), NXL Forge les intègre sans surcoût dans la mesure du raisonnable. Si elles représentent un périmètre additionnel clairement nouveau, un avenant au nombre de jours est proposé. La transparence sur ce point est posée dès le cadrage.
Puis-je accéder au code pendant le développement ?
Oui. Le dépôt Git est partagé dès le premier jour. Vous pouvez suivre les commits en temps réel, voir chaque module au moment où il est intégré, et faire des retours sur le code en cours de développement. Cette transparence est une garantie de qualité pour les deux parties.
Comment se passe le transfert si je veux reprendre le développement en interne ?
NXL Forge livre un dossier de transfert complet : README détaillé avec instructions d'installation, documentation d'architecture (diagrammes de base de données, flux API), guide de déploiement Vercel, et inventaire des services tiers utilisés (avec credentials). Un appel de passation d'une heure est inclus pour répondre aux questions de l'équipe technique qui reprend le projet.
La garantie de 30 jours couvre-t-elle les nouvelles fonctionnalités ?
Non. La garantie de 30 jours couvre les corrections de bugs sur le périmètre livré — comportements inattendus, erreurs de logique, régressions. Elle ne couvre pas les nouvelles fonctionnalités ni les modifications du périmètre initial. Ces évolutions sont traitées comme un nouveau projet ou des jours supplémentaires au TJM habituel.
Prêt à démarrer votre projet ?
Générez votre cahier des charges en 15 minutes ou obtenez une estimation budgétaire immédiate — sans engagement.