YOAT Lab
13 · Module 4 — Développement assisté

Suite du développement

MVP validé. Ce qu'on fait ensuite :
tests, performance, refactoring, documentation.

5 minutesPost-MVPTests · Perf · Refactoring
§01 · Le MVP est livré — et maintenant ?

Le vrai travail commence après le MVP

Le MVP (Minimum Viable Product) est la première version qui fonctionne. C'est une victoire. Mais un MVP n'est pas un produit. Les étapes suivantes déterminent si le projet tient dans le temps ou s'effondre sous le premier incident. Claude Code vous accompagne sur chacune d'elles.

Ne pas sauter le post-MVP

La tentation est forte de livrer le MVP et de passer à autre chose. Ce sont les projets qui résistent le mieux qui ont systématiquement un post-MVP structuré : tests, nettoyage du code, documentation de base. 20% du temps de développement supplémentaire évitent 80% des incidents futurs.

§02 · Tests — la couverture minimale

Tester ce qui compte vraiment

Il ne s'agit pas d'atteindre 100% de couverture de tests. Il s'agit de couvrir les chemins critiques — ceux dont la rupture serait catastrophique pour les utilisateurs.

Tests à faire

Chemins critiques

Création d'une mission, modification d'un statut, export CSV, connexion utilisateur. Les actions que les utilisateurs font tous les jours.

Tests à faire

Validations de formulaire

Champs obligatoires manquants, formats invalides, longueurs maximales. Claude génère les tests de validation en une passe.

Tests optionnels

Composants UI unitaires

Si le projet dure dans le temps et aura des contributeurs. Sinon, le test manuel via navigateur est suffisant pour un projet interne.

À éviter

Tests de snapshot

Les tests de snapshot (capture du rendu HTML) cassent à chaque modification visuelle mineure. Plus de bruit que de signal sur un projet en évolution rapide.

§03 · Performance — vérifications rapides

Quatre points en dix minutes

1.
Requêtes N+1. Demandez à Claude : « Analyse les appels Supabase dans le code et signale les patterns N+1 (une requête par item d'une liste). » Les N+1 sont la première cause de lenteur applicative.
2.
Index manquants. « Propose les index manquants sur la table missions pour les requêtes courantes (filtre par statut, tri par date). » Un index peut diviser un temps de requête par 100.
3.
Bundle size. Sur un projet Next.js : next build affiche la taille de chaque page. Si une page dépasse 200 Ko, demander à Claude d'identifier les imports lourds à remplacer.
4.
Images non optimisées. « Vérifie que toutes les balises img utilisent next/image avec les attributs width, height et priority appropriés. »
§04 · Refactoring opportuniste

Nettoyer en passant, pas en bloquant

Le refactoring complet d'un projet est une opération à haut risque et faible retour. Le refactoring opportuniste — corriger un mauvais pattern quand on passe dans le fichier — est la bonne approche.

Quand refactorer

En passant dans un fichier

On modifie la leçon-12. Le fichier contient aussi du code dupliqué d'une session précédente. On le nettoie pendant qu'on est là.

Quand ne pas refactorer

Pour refactorer

Ouvrir une session dédiée uniquement au refactoring d'un module entier, sans livraison fonctionnelle. Ratio risque/valeur défavorable.

Demande type

Ciblée et bornée

« Dans ce composant MissionTable, simplifie les trois fonctions de filtrage qui font la même chose, sans modifier le comportement observable. »

Règle d'or

Pas de refactoring invisible

Toujours commiter l'état avant de refactorer. Si le refactoring introduit un bug, on a un point de retour propre.

§05 · Documentation — le minimum viable

Ce que le prochain développeur a besoin de savoir

La documentation n'a pas besoin d'être exhaustive. Elle doit répondre à quatre questions que se pose tout développeur qui reprend un projet.

1.
README.md mis à jour. « Mets à jour le README avec : installation locale, variables d'environnement requises, commandes de développement, déploiement. » Claude génère un README propre en une passe.
2.
Commentaires sur les fonctions complexes. « Commente les fonctions qui ont une logique non évidente (la gestion des filtres URL, la fonction d'export CSV). »
3.
CLAUDE.md enrichi. Ajouter les décisions architecturales prises pendant le développement. Pourquoi Supabase et pas Firebase. Pourquoi cette structure de dossiers. Les choix qui pourraient surprendre.
4.
Variables d'environnement documentées. « Génère un fichier .env.example avec toutes les variables requises et un commentaire explicatif pour chacune. »
Fin · Leçon 13 acquise

Cap sur la leçon 14

Votre projet est testé, optimisé, refactoré et documenté. La leçon suivante le met en ligne avec Vercel — en moins de 10 minutes.

Exercice — appropriation

Sur votre projet de référence : (1) demandez à Claude d'identifier les 3 requêtes Supabase les plus à risque de N+1, (2) faites générer un .env.example documenté, (3) demandez un README mis à jour. Notez les constats de Claude sur la qualité actuelle du code.

Quiz · Validation des acquis

Quiz · Suite du développement

8 questions · une seule bonne réponse par question · vous pouvez recommencer autant de fois que nécessaire.

1 / 8
Vrai ou faux

L'objectif en matière de tests est d'atteindre 100% de couverture de code.

Score : 0 / 8
Cliquez sur lecture pour démarrer.
§00 · Intro 0:00 / 5:00 Voix activée