
Vous savez lancer la CLI, utiliser ses commandes et écrire un prompt borné. Ce guide est le premier cas d'usage complet sur lab-claude : vous déroulez la boucle Explorer → Planifier → Exécuter → Valider sur une tâche volontairement petite, avec un périmètre strict et une validation technique à chaque étape. L'objectif n'est pas de livrer une feature, c'est d'installer un rythme reproductible.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Appliquer la boucle Explorer → Planifier → Exécuter → Valider sur un cas réel
- Tenir un périmètre strict pendant toute la session
- Exécuter une étape à la fois, puis valider avec
ruff+pytest - Reconnaître une dérive et savoir vers quel guide renvoyer pour la corriger
Prérequis
Section intitulée « Prérequis »Claude Code CLIinstallé et fonctionnel- Commandes de la CLI maîtrisées (voir prise en main CLI)
- Prompt borné à rédiger (voir prompting de base)
- Projet fil rouge disponible localement :
~/Projets/lab-claude - Commandes de validation vérifiées :
uv run ruff check .uv run pytest -qLa boucle Explorer → Planifier → Exécuter → Valider
Section intitulée « La boucle Explorer → Planifier → Exécuter → Valider »Une session Claude Code est une conversation pilotée : vous cadrez, l'agent propose, vous validez. Pour débuter, la boucle la plus utile tient en 4 temps courts :
Explorer -> Planifier -> Exécuter -> Valider| Phase | Ce que vous demandez | Ce que vous vérifiez |
|---|---|---|
| Explorer | Lecture, résumé, diagnostic sans modification | Claude comprend la zone concernée |
| Planifier | Plan court, borné, en 3 étapes | Le plan ne sort pas du périmètre |
| Exécuter | Une seule étape à la fois, après validation | Diff propre et aligné sur le plan |
| Valider | ruff + pytest + git diff | Aucune régression ni débordement |
Cette boucle doit rester courte. Mieux vaut quatre cycles d'une minute qu'un cycle de dix minutes mal cadré.
Règle de répartition : Claude lit, résume, propose et exécute dans un cadre donné ; vous cadrez, validez et décidez. Tout le reste de ce guide découle de cette répartition.
Définition du périmètre sur lab-claude
Section intitulée « Définition du périmètre sur lab-claude »Dans ce guide, le périmètre est explicitement limité à :
app/main.pytests/test_health.py
Tout le reste est hors scope.
État de départ : vérifier que le projet est propre
Section intitulée « État de départ : vérifier que le projet est propre »Avant de demander quoi que ce soit à Claude, partez d'un état validé :
cd ~/Projets/lab-claudeuv run ruff check .uv run pytest -qSi ces commandes sont vertes, vous avez un point de référence propre.
Workflow pas à pas sur lab-claude
Section intitulée « Workflow pas à pas sur lab-claude »-
Ouvrez le projet
Fenêtre de terminal cd ~/Projets/lab-claudeclaude -
Demandez une exploration en lecture seule
Lis app/main.py et tests/test_health.py.Résume le comportement actuel de /health en 6 points maximum.Ne modifie aucun fichier. -
Demandez un plan court et borné
Propose un plan en 3 étapes pour une amélioration mineure de /health.Limite le périmètre à app/main.py et tests/test_health.py uniquement.N'exécute rien tant que je n'ai pas validé. -
Lancez une exécution contrôlée
Exécute uniquement l'étape 1 du plan validé.Ne touche à aucun autre fichier.À la fin, résume exactement ce qui a été modifié. -
Validez immédiatement
Fenêtre de terminal uv run ruff check .uv run pytest -q
Schéma 2 (rythme recommandé) :
petit changement -> validation -> petit changement -> validationCe qu'il faut observer à chaque étape
Section intitulée « Ce qu'il faut observer à chaque étape »- Étape exploration : Claude reste en lecture seule
- Étape plan : le plan tient en 3 étapes et reste dans le périmètre
- Étape exécution : une seule étape est exécutée, sans débordement
- Étape validation :
ruffetpytestrepassent au vert
Prompt d'exécution bornée (le seul propre à ce workflow)
Section intitulée « Prompt d'exécution bornée (le seul propre à ce workflow) »Les prompts d'exploration et de plan viennent de prompting de base. Le seul prompt vraiment propre au workflow est celui d'exécution bornée, qui vient après validation du plan :
Exécute uniquement l'étape 1 du plan validé.Ne touche à aucun autre fichier.Résume exactement ce qui a été modifié.Si Claude déborde pendant cette exécution, le recadrage est traité à part dans erreurs courantes et recadrage.
Erreurs fréquentes
Section intitulée « Erreurs fréquentes »| Symptôme | Cause probable | Correction |
|---|---|---|
| Le plan part dans trop de directions | Objectif trop large | Revenir à une amélioration mineure unique |
| Claude modifie d'autres fichiers | Périmètre mal rappelé | Repréciser les fichiers autorisés avant exécution |
| La validation échoue | Trop de changements d'un coup | Revenir à une seule étape et revérifier immédiatement |
| Résumé final difficile à relire | Demande de sortie absente | Exiger un résumé borné en 5 points |
Checklist de fin de guide
Section intitulée « Checklist de fin de guide »- J'ai démarré depuis un état initial propre (
ruffetpytestverts) - J'ai gardé le périmètre sur
app/main.pyettests/test_health.py - J'ai demandé un plan en 3 étapes avant exécution
- J'ai exécuté uniquement l'étape 1 du plan validé
- J'ai validé immédiatement avec
uv run ruff check .etuv run pytest -q - J'ai utilisé un prompt de recadrage si le scope a débordé
- J'ai obtenu un résumé final court et vérifiable
À retenir
Section intitulée « À retenir »- Le premier workflow réel doit rester petit et borné
- La valeur vient de la répétabilité, pas d'un gros changement
- Le plan court protège la qualité d'exécution
- La validation rapide évite de propager les erreurs
- Le premier objectif est la maîtrise, pas la vitesse