Suite du développement
À l'issue de cette leçon, le stagiaire identifie les quatre chantiers prioritaires post-MVP (tests, performance, refactoring, documentation), et sait par où commencer selon le contexte de son projet.
Le piège du MVP qui ne grandit pas
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. Quatre chantiers à prioriser, dans l'ordre.
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. Chacun mériterait une formation complète.
Chantier 1 — Tests
Commencez par les tests qui rapportent le plus. Les 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. Le test d'authentification qui plante en CI vous épargne un incident en production. Le test du calcul de marge vous épargne une réclamation client.
# Prompt type pour générer des tests avec Claude → Génère des tests Jest pour cette fonction d'authentification, en couvrant : - les cas nominaux (login réussi avec email/password valides) - les cas limites (email vide, password trop court) - au moins un cas d'erreur (mauvais password, compte verrouillé) Utilise des mocks pour les appels Supabase.
Claude est particulièrement efficace pour générer des tests à partir d'une fonction existante. Le résultat est généralement bon en première passe, à relire et compléter manuellement.
Chantier 2 — Performance
Trois métriques à mesurer avant d'optimiser. Optimiser sans mesurer fait perdre du temps — un goulot d'étranglement perçu n'est presque jamais le vrai.
Time to First Byte (TTFB)
Rapidité du serveur à répondre. Au-delà de 600 ms, le problème est côté backend (base de données lente, calcul lourd, API externe).
Largest Contentful Paint (LCP)
Rapidité d'affichage perçue par l'utilisateur. Objectif sous 2,5 secondes. Au-delà, ressentis comme lent.
Requêtes base de données
Combien par page chargée, lesquelles, leur durée. Souvent le vrai goulot caché : 50 requêtes au lieu d'une seule jointure bien faite.
Les outils gratuits du navigateur — l'onglet Performance des DevTools — et les indicateurs de Vercel ou Supabase suffisent pour démarrer. Pas besoin d'outillage cher pour les premières phases d'optimisation.
Chantier 3 — Refactoring
Identifiez les zones où vous hésitez à ouvrir le code. Vous savez celles dont vous parlez. Ce sont vos zones de dette technique.
Refactorez-les quand vous y touchez, pas en grandes opérations isolées. La règle du « boy-scout » : laissez le code un peu plus propre que vous ne l'avez trouvé. Une petite amélioration à chaque passage finit par transformer en profondeur sans jamais bloquer le développement de features.
Refactor opportuniste
Quand vous modifiez une fonction de toute façon, en profitez pour la rendre plus claire. Ratio amélioration / risque excellent.
Demander à Claude un audit
« Examine ce fichier et propose 3 refactos prioritaires, du moins risqué au plus risqué. » Claude est doué pour repérer les patterns à améliorer.
Tests d'abord, refacto ensuite
Avant de refactorer une fonction critique, vérifiez qu'elle est testée. Sinon, écrivez les tests, puis refactorez. Le filet de sécurité est non négociable.
Chantier 4 — Documentation
Deux fichiers à tenir à jour, deux publics différents :
CLAUDE.md — pour l'agent
Mis à jour au fil des décisions d'architecture importantes. C'est ce qui permet à Claude de garder le contexte à chaque nouvelle session. Vu en Découverte L11.
README.md — pour les humains
Mis à jour à chaque évolution majeure. Ce qu'un nouveau collaborateur lit en premier. Doit permettre d'installer, lancer, comprendre le projet en 15 minutes.
Dossier docs/ — décisions
Pour les décisions d'architecture importantes, un fichier par décision (Architecture Decision Record). Contexte, alternatives considérées, décision retenue, conséquences.
Trois pages tenues > wiki abandonné
Mieux vaut une documentation minimale mais à jour qu'un grand wiki que personne ne maintient. Le coût d'une doc fausse dépasse le coût de l'absence de doc.
Ordre de priorité — la séquence qui rapporte
Sur un projet qui démarre la vie post-MVP, voici l'ordre qui maximise le retour :
- Tests sur les fonctions critiques (semaine 1) — non négociable, c'est le filet de sécurité pour tout le reste
- Mesure de performance (semaine 2) — repère les vrais goulots avant d'optimiser à l'aveugle
- Refactor opportuniste (en continu) — pas un chantier isolé, mais un réflexe à chaque modification
- Documentation (semaine 3-4) — utile quand il y a quelque chose à documenter, donc plutôt après les premiers refactors
Cette séquence n'est pas absolue. Sur un projet qui croît vite côté équipe, la documentation peut passer en numéro 2. Sur un projet à fort enjeu de conformité, les tests sont d'autant plus urgents. Mais tests d'abord reste le réflexe par défaut.
Trois chantiers prioritaires sur votre projet
Pour votre application en cours, listez les trois chantiers prioritaires post-MVP. Pour chacun : (1) périmètre concret, (2) durée estimée, (3) livrable attendu, (4) métrique de succès. Identifiez celui qui vous coûte déjà le plus aujourd'hui — c'est par celui-là qu'il faut commencer. Si vous avez des doutes, demandez à Claude un audit de votre projet pour vous aider à hiérarchiser.
Cet exercice est à conserver dans votre dossier de stagiaire. Il n'est pas évalué mais il est tracé.
- web.dev — Core Web Vitals métriques Google de performance perçue
- adr.github.io format Architecture Decision Record pour documenter les choix
- jestjs.io framework de tests JavaScript le plus utilisé
Vous avez identifié et priorisé les 3 chantiers post-MVP les plus rentables pour votre projet ?