Module
Module 3 sur 5Leçon 1 sur 2~22 min

Explorer, planifier, coder, commiter sur un code existant

Leçon 1 du module « Planifier, puis déléguer avec méthode » de la formation « Travailler avec Claude Code sur un vrai projet : contexte, plan, revue ».

Objectif de la leçon

À la fin de cette leçon, vous serez capable de conduire une tâche non triviale sur un code existant en quatre temps (explorer, planifier, coder, commiter), avec le mode plan, des critères de vérification que l'agent exécute et des commits Git, et de savoir quand les points de restauration suffisent et quand ils ne suffisent pas.

Dans quel module

Planifier, puis déléguer avec méthode

Comment conduire une vraie tâche sans que l'agent parte dans la mauvaise direction, et quel outil lui confier pour quoi ?

Leçons du module

  1. Explorer, planifier, coder, commiter sur un code existant (cette leçon)
  2. Subagents, skills, commandes et serveurs MCP : le bon outil pour chaque besoin

Ce que vous apprendrez dans la formation

Cette leçon fait partie de la formation Travailler avec Claude Code sur un vrai projet : contexte, plan, revue

  • Expliquer ce qui occupe la fenêtre de contexte de Claude Code et la gérer (/context, /clear, /compact, reprise et nommage de sessions), en tenant compte du coût.
  • Rédiger un CLAUDE.md court et utile, placé au bon niveau de la hiérarchie (utilisateur, projet, local, sous-dossier, règles par chemin), avec des imports si besoin.
  • Conduire une tâche sur un code existant en explorer, planifier, coder, commiter, avec le mode plan, des critères de vérification et Git plutôt que les seuls points de restauration.
  • Choisir et justifier le bon mécanisme pour un besoin (CLAUDE.md, skill ou commande, subagent, serveur MCP, hook) et l'installer dans le dépôt.
  • Choisir un mode de permission et écrire des règles allow, ask et deny adaptées au risque du projet, dans le bon fichier de réglages.
  • Écrire des hooks simples comme garde-fous déterministes (bloquer, formater, vérifier) et en connaître les risques et les limites.
  • Relire le travail de l'agent avec une checklist (périmètre, tests, secrets, migrations, dépendances) et une revue indépendante, et savoir quand l'automatiser en mode non interactif ou dans GitHub Actions.