Le mode plan en développement web
À l'issue de cette leçon, le stagiaire applique systématiquement le mode plan au développement web, demande à Claude un plan en cinq angles (données, API, UI, tests, migration), et amende le plan avant exécution.
Rappel et spécificité web
Le mode plan a été vu en Découverte L13 dans le contexte général. Cette leçon-ci l'applique concrètement au développement web, où les enjeux d'interdépendance entre couches le rendent encore plus précieux.
Les features web touchent souvent plusieurs couches en cascade. Un nouveau formulaire, par exemple, implique un schéma de base de données, une route d'API, un composant frontend, des validations, des tests. Sans plan, Claude commence par un bout — souvent l'UI parce que c'est ce que vous demandez en premier — et vous découvrez en cours de route que la décision prise à l'étape 1 contraint mal l'étape 4.
Avec plan, ces interdépendances sont visibles avant que la première ligne de code soit écrite.
Anatomie d'un plan de feature — cinq angles
1. Couche données
Quelles tables, quelles colonnes, quelles politiques RLS faut-il créer ou modifier ? Quelles migrations ?
2. Couche API
Quels endpoints, quelles validations d'entrée, quelles erreurs renvoyées au client ?
3. Couche UI
Quels écrans ou composants, quels états (chargement, erreur, vide), quels parcours utilisateur ?
4. Tests
Que faut-il tester pour considérer la feature comme fiable ? Cas nominaux, limites, erreurs.
5. Migration et déploiement
Comment passer de l'état actuel au nouvel état sans casser ce qui marche ? Migration de base, compatibilité descendante, rollback.
Demandez explicitement à Claude de couvrir ces cinq angles dans son plan. Sans cette consigne, il oublie souvent les deux derniers — tests et migration. Or ce sont précisément ceux dont l'absence vous coûtera le plus cher si la feature part en production sans les couvrir.
Itérer le plan, pas le code
Le bon réflexe : passer plus de temps à amender le plan, moins à corriger le code généré. Une heure passée à clarifier le plan évite des heures de refacto sur des choix qui auraient pu être posés en amont.
Trois questions utiles à poser sur un plan avant validation
- « Pourquoi cette table plutôt qu'un champ JSON ? » — force Claude à justifier les choix de modèle
- « Que se passe-t-il si l'utilisateur soumet le formulaire deux fois ? » — révèle les angles morts sur les cas limites
- « Comment cette feature interagit-elle avec celle déployée la semaine dernière ? » — fait remonter les interdépendances cachées
Ces questions forcent Claude à expliciter ses hypothèses, et révèlent souvent les angles qu'il n'avait pas considérés.
Démo — feature « commentaires sur un post »
Pour illustrer, prenons une feature concrète : permettre aux utilisateurs de commenter un post existant. Voici le prompt qui demande le plan complet :
# Dans VS Code, panneau Claude. Activer mode plan (Shift+Tab) → Permettre aux utilisateurs de commenter un post existant. Couvre les 5 angles : 1. Données (table, colonnes, RLS, relations) 2. API (endpoints, validation, erreurs) 3. UI (composants, états, parcours) 4. Tests (cas nominaux, limites, erreurs) 5. Migration (déploiement sans casse) # Une fois le plan généré, l'amender : → Sur la table commentaires : - ajoute une colonne updated_at - précise la stratégie de suppression cascadée (soft delete / anonymisation / suppression dure) quand un utilisateur supprime son compte
Claude met à jour le plan. Une fois les cinq angles couverts proprement et les questions critiques tranchées, on valide l'exécution. Claude exécute pas-à-pas, vous vérifiez au fil de l'eau que le résultat correspond.
Quand sauter le mode plan
Le mode plan a un coût en temps initial. Trois situations où il est sur-dimensionné :
- Tâche mono-fichier triviale — renommer une variable, ajouter un commentaire, corriger une faute de frappe. Une instruction directe suffit.
- Exploration / prototypage rapide — quand vous testez une idée et que vous savez que vous jetterez le résultat. Le plan ralentirait sans rapporter.
- Tâche sur fichier inconnu en lecture seule — quand vous demandez juste à comprendre un code existant. Pas de modification, pas besoin de plan.
Dans tous les autres cas — toute feature qui touche plus d'un fichier, toute modification de schéma de base, toute évolution d'API — le mode plan est la pratique par défaut.
Une feature, un plan complet
Sur votre projet de référence, ajoutez une feature concrète en passant rigoureusement par le mode plan. Tenez un journal court : (1) besoin initial formulé en deux phrases, (2) plan généré par Claude (les 5 angles), (3) amendements apportés, (4) durée totale du plan (avant exécution), (5) retours d'expérience sur l'écart prévu / réel. Cet exercice est le cœur du Module 4.
Cet exercice est à conserver dans votre dossier de stagiaire. Il n'est pas évalué mais il est tracé.
- docs.claude.com — Best practices guide officiel des bonnes pratiques Claude Code
Vous appliquez systématiquement le mode plan en couvrant les 5 angles (données, API, UI, tests, migration) ?