«Combien de temps avant d'avoir quelque chose qui fonctionne ?», c'est la question que les clients posent le plus souvent au premier appel. Ma réponse est la même depuis un moment : quatre semaines pour passer d'une idée à une web app en production, avec un périmètre bien défini. Ce n'est pas une formule magique, c'est un processus que j'ai affiné projet après projet. Je le partage tel quel.
Semaine 1 : Découverte et architecture
Pas de code pour l'instant. Cette semaine sert à définir le périmètre réel : quel problème résout l'app, qui l'utilise, quels flux sont critiques et lesquels peuvent attendre une v2. J'en ressors avec un document court (jamais plus de 2-3 pages) couvrant le modèle de données, l'architecture technique et une liste de fonctionnalités priorisée.
L'objectif est de réduire l'ambiguïté au maximum avant d'écrire la première ligne de code.
Semaine 2 : MVP fonctionnel
Je construis le squelette complet : auth, base de données, routes principales et le flux critique de bout en bout, même moche. Je préfère avoir quelque chose de cliquable et fonctionnel plutôt qu'une interface soignée sans logique derrière.
C'est la semaine où les vrais problèmes de modélisation des données apparaissent généralement, et ils coûtent bien moins cher à résoudre maintenant qu'en semaine 4.
Semaine 3 : Finitions et contenu
Une fois la logique en place, place à une vraie UI, aux états de chargement et d'erreur, à la validation, au responsive, et à du contenu réel au lieu de lorem ipsum.
C'est aussi le moment où le client commence à vraiment utiliser l'app, pas seulement à regarder une démo, et c'est là que sortent les ajustements UX qui ne se voient jamais lors d'un appel.
Semaine 4 : QA, déploiement et remise
Tests manuels des flux critiques, revue de sécurité de base (RLS, variables d'environnement, permissions), déploiement en production, et documentation minimale pour que le client puisse faire fonctionner l'app sans dépendre de moi pour tout. Je termine par un appel de remise et un backlog priorisé pour la v2.
La stack que j'utilise
- Next.js + TypeScript pour le frontend et les routes API.
- Tailwind pour ne pas perdre de temps à me battre avec le CSS.
- Supabase pour l'auth, la base de données et le storage sans monter d'infrastructure depuis zéro.
- Vercel pour un déploiement continu dès le premier commit, pas seulement à la fin.
Leçons apprises
- C'est le scope creep qui tue les délais, pas la complexité technique. Toute nouvelle fonctionnalité qui apparaît en cours de projet part directement dans la liste v2, sans exception.
- Déployer dès le premier jour, même s'il n'y a encore rien à voir, évite les mauvaises surprises de dernière minute avec l'environnement de production.
- Montrer le MVP moche en semaine 2 génère un meilleur retour que montrer quelque chose de joli en semaine 4, parce que le client réagit à la fonction, pas aux couleurs.
- Un document de périmètre court mais validé vaut plus que cent réunions. Il réduit à presque zéro les «mais je pensais que c'était inclus».
Si vous avez une idée et voulez savoir si elle rentre dans un processus de quatre semaines, contactez-moi et regardons ça ensemble.