Suite du développement

Une application livrée en MVP marche pour quelques utilisateurs. Si elle réussit, elle doit grandir. Et c'est là que les coupes prises au démarrage commencent à coûter. Pas de tests : chaque modification est risquée. Pas de documentation : un nouveau collaborateur prend une semaine à comprendre. Code écrit dans l'urgence : la dette technique freine chaque évolution.

Cette leçon n'est pas un cours de génie logiciel. C'est un repérage des quatre chantiers les plus rentables après le MVP, dans l'ordre où il est généralement utile de les attaquer.

Commencez par les tests qui rapportent le plus : les tests des fonctions critiques côté serveur (authentification, calculs financiers, transformations de données importantes), pas les tests d'UI exhaustifs. Une couverture de 30 % bien placée vaut mieux que 80 % de tests fragiles sur des détails d'affichage.

Claude est particulièrement efficace pour générer des tests à partir d'une fonction existante. « Génère des tests Jest pour cette fonction, en couvrant les cas nominaux, les cas limites, et au moins un cas d'erreur. » Le résultat est généralement bon en première passe, à relire et compléter manuellement.

Trois métriques à mesurer avant d'optimiser : Time to First Byte (rapidité du serveur), Largest Contentful Paint (rapidité d'affichage), requêtes base de données (combien, lesquelles, leur durée).

Optimiser sans mesurer fait perdre du temps. Un goulot d'étranglement perçu n'est presque jamais le vrai. Les outils gratuits du navigateur (Performance tab des DevTools) et les indicateurs de Vercel ou Supabase suffisent pour démarrer.

Refactoring. Identifiez les zones où vous hésitez à ouvrir le code (vous savez celles dont vous parlez). Ce sont vos zones de dette. Refactorez-les quand vous y touchez, pas en grandes opérations isolées. Boy-scout rule : laissez le code un peu plus propre que vous ne l'avez trouvé.

Documentation. Tenez à jour le CLAUDE.md (cf. leçon 11) et un fichier README.md côté humain. Documentez les décisions d'architecture importantes au fil de l'eau dans un dossier docs/. Trois pages bien tenues valent mieux qu'un wiki abandonné.