Pourquoi je ne code jamais en premier
PREDEV/POSTDEV, lots numerotes, audit post-livraison. La methode que j'applique sur chaque projet, du jeu idle au Play Store.
La tentation de coder d'abord
Chaque projet commence par la même pression: il faut avancer, donc il faudrait coder tout de suite. Le problème, c'est que le code valide aussi des décisions qu'on n'a parfois pas encore prises consciemment.
Les projets qui tiennent dans le temps sont rarement ceux qui ont été codés le plus vite au début. Ce sont ceux qui ont structuré leurs choix avant la première ligne.
Ce que contient vraiment le PREDEV
Le PREDEV contient la promesse produit en une phrase, les user stories prioritaires, l'architecture technique retenue, le découpage en lots avec critères de validation, et les décisions clés avec leur justification.
Si une décision importante n'est pas documentée, elle sera oubliée ou réouverte au pire moment: en plein dev, sous pression, avec des dépendances déjà posées.
Un lot n'est pas une feature
La différence la plus importante est là: un lot est un bloc livrable, testable, auditable. Une feature peut rester floue ou partiellement terminée pendant des semaines.
Sur Grimoire, le lot 8 n'était pas 'faire l'auth'. C'était un périmètre défini avec écran unifie, Google OAuth, mode invite, vérification email et critères de validation avant code.
Le POSTDEV n'est pas une formalite
Le POSTDEV intervient après chaque lot: relecture du code avec recul, identification de la dette naissante, corrections avant de passer au lot suivant.
A la fin du MVP, il sert aussi a produire un audit global et une roadmap post-MVP. C'est la partie qui empêche le projet de s'accumuler sur lui-même.
Quand cette methode doit se taire
Un PREDEV ne remplace pas la compréhension du problème. Si le sujet est encore trop flou, il faut d'abord un proto exploratoire de 2 ou 3 jours.
La bonne règle n'est pas 'écrire un document avant tout'. La bonne règle, c'est 'ne pas laisser le code choisir a ta place ce que tu n'as pas encore arbitre'.