Prise en main par la pratique : du lancement à la livraison avec un besoin réel

📚 Navigation de la série : L'article précédent Manuel de référence des plugins 38 vous a appris à packager votre propre configuration. Cet article change complètement de vitesse — les trente-huit premiers articles décortiquaient les fonctionnalités une par une ; celui-ci les réunit pour la première fois dans un parcours pratique complet : prendre un besoin réel et simple, de l'ouverture du projet à l'écriture de CLAUDE.md, en passant par les questions, la revue des modifications et la validation de la livraison, le tout d'un seul coup. Les techniques apprises précédemment sont ici rassemblées pour travailler ensemble.

Pour être honnête, la plupart des gens pensent que coder avec l'IA se résume à « une phrase et on attend le résultat » — vous expliquez le besoin, Claude fait tout tout seul, et vous n'avez plus qu'à l'utiliser. C'est simple en apparence, mais il suffit de trébucher une fois pour comprendre où le processus coince :

Changement de direction inattendu, trois fichiers modifiés de trop au passage, le bug qui devait être corrigé fait toujours planter l'application... Finalement, le temps passé à réparer les dégâts est supérieur à celui qu'il aurait fallu pour le faire soi-même.

Ce n'est pas que l'outil n'est pas assez intelligent, c'est qu'il manque des relais essentiels dans ce flux de travail.

En clair, c'est le fossé entre « avoir appris chaque mouvement » et « être capable de les enchaîner ». Vous vous êtes exercé à tourner le volant, à regarder dans les rétroviseurs, à freiner, mais pour votre première sortie seul sur la route, vous devez enchaîner ces actions dans le bon ordre pour savoir conduire. Cet article n'enseigne aucune nouvelle fonctionnalité, il ne fait qu'une chose : vous accompagner pour assembler pour la première fois les pièces que vous connaissez déjà dans un parcours pratique fonctionnel.

La tâche que nous avons choisie est minuscule, mais elle contient tout le nécessaire : ajouter une fonctionnalité à un petit script de comptage de fréquence de mots et en profiter pour corriger un bug. Bien que ce soit un projet minimaliste, toutes les étapes du parcours complet, du lancement à la livraison, sont bien présentes.

À la fin de cet article, vous obtiendrez :

• Un parcours pratique standard « Lancement → Exploration → Planification → Action → Validation → Livraison », avec ce qu'il faut taper et regarder à chaque étape
• Un petite tâche réelle à reproduire (ajouter --top N au script de comptage de mots et corriger le plantage en cas d'arguments vides), avec l'intégralité des commandes et des sorties attendues
• Pourquoi la règle d'or « d'abord le laisser explorer, ensuite le laisser agir » est le réflexe que les débutants doivent absolument acquérir
• Comment utiliser le plan mode (détails au chapitre 20) pour qu'il propose d'abord une solution avant de générer le code, et comment examiner le diff qu'il vous fournit
• Un tableau comparatif « Approche expert vs Approche débutant » pour mettre en évidence les pièges d'ordre les plus courants

---

01 Vue d'ensemble : une session de pratique en six étapes

Avant de commencer, visualisez tout le parcours dans votre tête. Qu'elle soit grande ou petite, la structure d'une tâche réelle, de sa réception à sa livraison, repose sur ces six étapes :

Analogie : le passage de témoin dans un relais. Ces six étapes représentent six coureurs qui se passent le témoin : l'exploration transmet « ce que j'ai compris » à la planification, la planification transmet « comment j'ai l'intention de modifier » à l'action, l'action transmet « ce qui a été modifié » à la validation. Si un témoin tombe à n'importe quelle étape, tout le parcours doit être repris — 90 % des échecs chez les débutants sont dus à un témoin non transmis, le cas le plus typique étant « passer directement à l'action sans aucune exploration », c'est-à-dire courir avant d'avoir bien saisi le témoin.

Ces six étapes ne sortent pas de nulle part : elles combinent l'ordre pratique des guides de démarrage rapide (quickstart) et des flux de travail courants (common workflows) officiels. La phrase de la documentation officielle résume parfaitement l'idée :

Avant de faire des modifications, laissez Claude comprendre votre code.

Ces six étapes peuvent être contractées, mais jamais sautées. Les utilisateurs expérimentés peuvent fusionner « Exploration + Planification » dans un seul message, ou lier « Validation + Livraison » dans une seule action, ce qui donne l'impression de n'avoir que trois étapes. Cependant, chaque étape reste bien présente, c'est simplement le rythme qui s'accélère. L'erreur des débutants n'est pas de « marcher lentement », mais de supprimer directement les quatre étapes du milieu pour ne garder que « Exprimer le besoin → Obtenir le résultat ». C'est comme jeter le témoin directement du premier relayeur vers la ligne d'arrivée sans personne au milieu pour le réceptionner. Le reste de cet article vous accompagnera pour franchir ces six étapes très concrètement sur une tâche réelle, en passant chaque témoin vous-même. J'indiquerai au début de chaque étape son lien avec les concepts étudiés précédemment afin que vous puissiez faire le lien avec ce que vous avez appris.

💡 Résumé en une phrase : La structure d'une session de pratique repose toujours sur six étapes : « Lancement → Exploration → Planification → Action → Validation → Livraison », transmises avec soin comme dans une course de relais ; le témoin le plus souvent perdu par les débutants est « passer à l'action directement sans laisser l'outil explorer ».

---

02 Préparation : créer un mini-projet d'entraînement

Pour que vous puissiez reproduire le processus à l'identique, nous n'utiliserons pas de projet réel de grande envergure. Nous allons passer deux minutes à mettre en place un environnement d'entraînement minimal. Il comprendra simplement un script Python et un fichier texte, sans aucune dépendance tierce, exécutable simplement avec python3 (intégré par défaut sur Mac/Linux ; sous Windows, il suffit d'avoir installé Python).

Étape 1 : Créer le répertoire, y entrer et créer deux fichiers

Exécutez dans votre terminal (cette étape est une préparation purement manuelle, Claude Code n'est pas encore utilisé) :

mkdir wordcount-demo && cd wordcount-demo

Créez un fichier wordcount.py avec le contenu suivant (voici le « code hérité » que nous voulons modifier, délibérément écrit de manière un peu brute) :

import sys
from collections import Counter

def count_words(path):
    with open(path) as f:
        text = f.read()
    words = text.lower().split()
    return Counter(words)

def main():
    path = sys.argv[1]
    counts = count_words(path)
    for word, n in counts.items():
        print(f"{word}: {n}")

if __name__ == "__main__":
    main()

Créez ensuite un fichier sample.txt pour servir de données de test :

the quick brown fox the lazy dog the fox

Étape 2 : L'exécuter manuellement pour s'assurer qu'il fonctionne

python3 wordcount.py sample.txt

Sortie attendue (l'ordre peut être légèrement différent, mais les chiffres seront identiques) :

the: 3
quick: 1
brown: 1
fox: 2
lazy: 1
dog: 1

Une fois ces comptes affichés = le script fonctionne correctement, notre environnement de test est prêt. Ce script présente deux défauts, qui feront office de tâches :

• Fonctionnalité manquante : Je souhaite n'afficher que les « N mots les plus fréquents ». Actuellement, il affiche tout d'un coup.
• Un bug caché : Essayez de lancer python3 wordcount.py sans spécifier de nom de fichier ; le script va planter en affichant une erreur IndexError, au lieu de vous indiquer poliment qu'il faut fournir un fichier.

Étape 3 : L'intégrer à Git (cette étape est cruciale, ne la sautez pas)

git init && git add . && git commit -m "init: 一个简陋的数词脚本"

Attendu : Une confirmation de validation apparaît à la fin, affichant quelque chose comme 2 files changed (wordcount.py et sample.txt sont enregistrés). Cela signifie que = vous disposez désormais d'un « point d'origine » propre. Peu importe les modifications apportées par Claude au code par la suite, vous pourrez y revenir en un clic.

Pourquoi effectuer un git commit avant de commencer ? Parce que c'est votre filet de sécurité le plus solide. Le chapitre 37 expliquait que les points de contrôle (checkpoints) permettent d'annuler les modifications apportées par Claude, mais les points de contrôle et Git sont deux systèmes distincts (ce point a été détaillé au chapitre 37). Un commit Git propre avant de démarrer est la base qui vous permet de « revenir au point de départ peu importe les manipulations ultérieures ». Permettre à l'outil de faire de grosses modifications sans commit préalable, puis vouloir revenir en arrière sans base de comparaison saine est une erreur classique. Il faut donc s'engager à valider ses modifications avant de lancer l'outil.

💡 Résumé en une phrase : L'environnement d'entraînement se compose d'un script brut et d'un fichier texte, prêt à tourner avec python3 ; il contient volontairement une « fonctionnalité manquante » et un « bug masqué » ; faites un git commit avant de démarrer pour vous assurer une sécurité maximale.

---

03 Lancement : démarrer dans le répertoire du projet, puis écrire un CLAUDE.md minimal

Une fois l'environnement prêt, passons au premier relais — le lancement. Cette étape correspond au chapitre 02 (Démarrage), au chapitre 07 (Premier lancement réussi) et aux chapitres 12 / 18 (CLAUDE.md).

Étape 1 : Démarrer Claude Code à la racine du projet

Vous devez saisir claude dans le répertoire wordcount-demo, et nulle part ailleurs. Par défaut, Claude Code définit le répertoire depuis lequel vous le lancez comme espace de travail — si vous vous trompez d'emplacement, il lira les fichiers d'un autre projet.

claude

Attendu : Vous voyez l'écran d'accueil de Claude Code, indiquant en bas que le répertoire actuel est bien wordcount-demo. C'est le point de départ que nous avons vu au chapitre 07.

Étape 2 : Lui fournir un fichier CLAUDE.md « minimal mais fonctionnel »

Le chapitre 18 a répété cette vérité : un fichier CLAUDE.md de trois cents lignes dont Claude ne suit aucune règle ne sert absolument à rien. Pour notre projet d'entraînement, ne voyez pas trop grand : trois ou quatre lignes suffisent pour poser les règles indispensables. Pour notre petit script, il n'y a que deux règles clés : comment l'exécuter et comment valider les modifications. Demandez-lui directement de le générer au sein de la conversation (vous pouvez aussi l'écrire à la main, mais le laisser faire est plus rapide) :

帮我在项目根目录建一个 CLAUDE.md，写清两条：
1. 这是个纯标准库的 Python 命令行小工具，不要引入任何第三方依赖
2. 每次改完代码，用 python3 wordcount.py sample.txt 跑一遍验证不报错

Attendu : Claude vous présentera d'abord le contenu à écrire avant de demander l'autorisation de créer le fichier (il s'agit du mécanisme de permission présenté au chapitre 20 — il vous consulte systématiquement avant de modifier des fichiers). Après approbation, un fichier CLAUDE.md apparaîtra à la racine du projet, ressemblant à ceci :

# wordcount-demo

一个数文本里单词频率的命令行小工具。

## 技术约束
- 纯 Python 标准库，**不要引入任何第三方依赖**。

## 验证
- 每次改完代码，跑一遍确认不报错：`python3 wordcount.py sample.txt`

C'est court, mais les deux règles principales y sont bien ancrées. Ne le trouvez pas trop simpliste — si trois lignes suffisent pour définir le cadre, inutile d'en écrire trente.

这里你可能想到第 12 篇的 /init。区别在：/init 是让 Claude 自己扫一遍代码库、自动生成一份较完整的说明书，适合有点规模的真实项目；咱们这个脚本就两个文件，手动指明那两条核心规矩反而更准、更短。两条路都对，看项目大小挑。

Pourquoi passer du temps à écrire CLAUDE.md dès le début ? Parce qu'il fixe la « règle générale » pour toutes les étapes suivantes. Lorsque vous lui demanderez d'ajouter des fonctionnalités plus tard, il se souviendra automatiquement de « ne pas importer de dépendances tierces » ; après modification, il pensera de lui-même à « exécuter la validation » — vous ne le dites qu'une fois, et c'est valable pour toute la session, sans avoir à le répéter dans chaque instruction. C'est l'intérêt principal de CLAUDE.md : graver dans le marbre les consignes récurrentes sous forme de contexte chargé automatiquement à chaque session.

💡 Résumé en une phrase : Lancement = se positionner dans le bon répertoire et taper claude + écrire un CLAUDE.md minimal de quelques lignes pour fixer les règles indispensables ; pour un petit projet d'entraînement, déclarer manuellement deux règles est plus efficace et plus direct que d'utiliser /init pour scanner l'intégralité du projet.

---

04 Exploration : le laisser « comprendre » d'abord, sans se presser de le faire « agir »

C'est l'étape du parcours qui doit le plus devenir un réflexe et qui est la plus souvent éludée par les débutants : l'exploration. Elle correspond à la première catégorie des « quatre tâches les plus courantes » présentées au chapitre 16.

Pour aller droit au but : le premier message que vous envoyez à la réception d'une tâche ne doit pas être « modifie ceci », mais « comprends cela d'abord ».

Le scénario du blocage initial illustre cette erreur : vouloir tout de suite écrire « ajoute un paramètre --top au script ». Quel est le problème ? Claude ne sait absolument rien de votre code. Il va essayer de deviner tout en le modifiant, et s'il devine mal, il produira un code incohérent. La bonne méthode consiste à l'envoyer d'abord analyser la situation :

先别改任何代码。给我讲讲 @wordcount.py 现在是怎么工作的，
入口在哪、有没有什么明显的问题或者容易崩的地方？

Notez deux détails :

• La phrase d'introduction « Ne modifie aucun code pour l'instant » trace une ligne claire — cette étape autorise la lecture, mais pas l'écriture. Comme indiqué au chapitre 15, définir clairement les limites empêche l'outil de les franchir.
• Le tag @wordcount.py transmet directement le contenu du fichier dans la conversation (la référence via @ abordée aux chapitres 16 et 17), lui évitant ainsi d'avoir à faire une recherche supplémentaire.

Attendu : Claude lira le fichier et vous fournira des explications. Il indiquera en substance : c'est un script comptant la fréquence des mots avec Counter, le point d'entrée est main(), et il récupère le chemin du fichier depuis sys.argv[1]. Ensuite, il y a de grandes chances qu'il pointe de lui-même la faille : si aucun nom de fichier n'est fourni, sys.argv[1] provoquera une erreur d'index hors limites et fera planter le script.

Vous voyez ? Alors que vous n'avez pas encore mentionné le bug, il l'a découvert de lui-même durant l'exploration. C'est le bénéfice immédiat de la phase « d'exploration préalable » : non seulement il comprend l'existant, mais il détecte aussi au passage les faiblesses. Une fois ce témoin transmis proprement, l'étape suivante (la planification) peut s'appuyer sur des bases solides.

Ce script ne fait qu'une quinzaine de lignes, une seule question d'exploration suffit donc. Sur un projet réel, l'exploration se fait généralement en plusieurs étapes, du plus large au plus précis. La routine d'exploration recommandée dans les common workflows officiels suit ce rythme : d'abord le contexte global, puis les détails locaux —

先给我这个代码库的整体结构和它是干嘛的（先别改任何代码）

处理用户登录的逻辑在哪几个文件？它们怎么配合的？

La première phrase permet d'obtenir la « carte générale », la seconde vous permet de vous enfoncer dans la zone spécifique à modifier en suivant cette carte. Pourquoi ne pas poser des questions détaillées d'emblée ? Moins il a de contexte sur le projet, plus il risque de confondre un fichier « potentiellement lié » avec le « fichier réellement concerné ». Lui fournir d'abord une carte d'ensemble garantit un ciblage précis par la suite. Face à un projet de taille moyenne inconnu, commencez systématiquement par ces deux ou trois questions : mieux vaut investir deux minutes dans l'exploration plutôt que de le laisser travailler avec une vision globale erronée.

Analogie : faire le tour du véhicule avant de prendre la route pour la première fois. Un conducteur expérimenté jette un regard instinctif avant de monter à bord — pression des pneus, obstacles à l'arrière, réglage des rétroviseurs. Ce tour visuel prend moins de dix secondes, mais évite de « passer la marche arrière et de heurter un poteau invisible ». Demander à Claude d'explorer d'abord correspond à ce contrôle visuel préalable — ces dix secondes d'observation évitent de perdre une demi-heure à corriger des modifications erronées.

探索阶段读文件会吃上下文（第 19 篇讲过工作台塞满会变蠢）。任务大、要翻一堆文件时，可以让它派个 subagent 去探索（第 23 篇）——子代理在自己的窗口里翻，只把结论递回来，你的主对话不被一堆文件内容灌满。小任务用不上，知道有这条路即可。

💡 Résumé en une phrase : Face à une tâche, le premier réflexe doit toujours être « ne modifie rien pour le moment, commence par comprendre » ; cette exploration évite les approximations et réserve souvent de bonnes surprises en révélant des anomalies qu'il identifie de lui-même. C'est le réflexe numéro un à acquérir.

---

05 Planification : exiger d'abord une proposition, puis valider avant d'écrire le code

L'exploration terminée, il comprend l'état actuel et sait ce que vous attendez. Mais il reste une étape indispensable : lui demander d'exposer son plan de modification pour validation avant d'agir. Ce relais correspond au plan mode (mode planification) décrit au chapitre 20.

Pourquoi ne pas le laisser modifier directement ? Parce que la solution qu'il conçoit n'est pas forcément celle que vous souhaitez. L'obliger à détailler son approche au préalable est la protection la plus simple et la plus économique pour éviter qu'il ne s'égare et modifie tout le projet sur de mauvaises bases.

Option 1 : Lui demander directement d'exposer le plan sans modifier de code

La méthode la plus simple consiste à le guider par une consigne claire :

我想给这个脚本加一个 --top N 参数，只显示最高频的前 N 个词；
顺手把不传文件名就崩溃的问题也修了。
先告诉我你打算怎么改、动哪几个地方，等我说「开始」你再动手。

Attendu : Il vous proposera un plan, par exemple : remplacer le traitement manuel de sys.argv par argparse, ajouter l'option --top, utiliser Counter.most_common(N) pour extraire les N premiers éléments, et laisser argparse afficher un message d'aide convivial au lieu de planter si le nom de fichier est absent. Il s'arrêtera à cette étape en attendant votre feu vert, sans modifier aucun fichier de sa propre initiative.

Option 2 : Utiliser le plan mode officiel

Pour des tâches plus importantes, il est plus prudent de basculer sur le mode planification officiel. Ce mode impose à Claude de ne pas éditer le code source et de se limiter à la rédaction du plan. Il ne touchera à aucune ligne de code sans votre accord (bien qu'il reste libre de lancer des commandes shell pour explorer le projet). Il existe deux manières d'y accéder (décrites au chapitre 20) :

claude --permission-mode plan

Ou en appuyant sur Shift+Tab dans la session pour basculer en plan mode. La documentation officielle définit ce mode très clairement :

Claude lit les fichiers et propose un plan, mais n'effectue aucune modification avant votre approbation.

Voici un comparatif rapide de ces deux approches :

Approche	Comment le contraindre	Niveau de contrainte	Adapté pour
Lui demander d'exposer la solution par message	En précisant « n'apporte aucune modification » dans le prompt	Contrainte souple (il obtempère généralement, mais sans barrière technique)	Petites modifications, sous votre surveillance directe
plan mode	Interdiction d'éditer le code source au niveau du mode (les commandes shell restent disponibles)	Contrainte stricte (aucune ligne de code source ne peut être modifiée avant approbation)	Grandes modifications, en cas de doute, pour valider sérieusement l'approche

Une bonne habitude pratique : pour une modification aussi mineure que --top, l'option 1 avec une simple phrase suffit. Cependant, dès qu'il s'agit de modifier plusieurs fichiers ou que vous avez un doute, appuyez systématiquement sur Shift+Tab pour passer en plan mode — laisser le mode technique verrouiller l'édition à votre place est bien plus reposant que de surveiller chaque action. Si vous tentez de faire une modification importante sur un projet mal maîtrisé sans utiliser le plan mode par souci de rapidité, l'outil risque de modifier quatre fichiers d'un coup dans une direction opposée à vos attentes. Le temps perdu à revenir en arrière dépassera largement celui nécessaire à l'analyse de trois variantes de plans. En cas de doute, utilisez le plan mode.

💡 Résumé en une phrase : Avant d'agir, exigez une proposition de solution et validez-la avant modification ; une simple mention « n'apporte aucune modification pour le moment » suffit pour les petits changements, tandis que pour les modifications complexes ou incertaines, utilisez le plan mode (Shift+Tab) pour bloquer techniquement toute édition sans accord.

---

06 Action + Revue : le laisser modifier, mais examiner chaque diff

Le plan ayant été validé, passons au relais suivant (qui combine en réalité l'action et la revue) — le laisser appliquer les modifications tout en surveillant chaque étape. Cette phase s'appuie sur la validation des permissions abordée au chapitre 20.

Étape 1 : Lui donner le feu vert

方案可以，开始改吧。

Attendu : Claude commence à éditer wordcount.py. C'est ici que réside la clé — à chaque modification, il affiche le diff correspondant (comparaison des modifications : lignes supprimées, lignes ajoutées) sous vos yeux pour validation (sauf si vous avez activé le mode d'acceptation automatique, ce qui est fortement déconseillé aux débutants). Le chapitre 20 décrivait ce système de permissions : c'est à cette étape qu'il s'applique concrètement.

Étape 2 : Examiner attentivement le diff, sans valider mécaniquement

C'est le piège le plus fréquent pour les débutants — valider à la chaîne en tapant y sans regarder le défilement du diff. Ma règle absolue est : pour chaque modification, vérifiez d'un coup d'œil si l'outil intervient bien à l'endroit convenu. Pour cette tâche, la modification affichée devrait ressembler à ceci :

- import sys
+ import argparse

- def main():
-     path = sys.argv[1]
-     counts = count_words(path)
-     for word, n in counts.items():
+ def main():
+     parser = argparse.ArgumentParser(...)
+     parser.add_argument("path", ...)
+     parser.add_argument("--top", type=int, default=None, ...)
+     args = parser.parse_args()
+     counts = count_words(args.path)
+     items = counts.most_common(args.top) if args.top else counts.most_common()
+     for word, n in items:

Vérifiez trois éléments d'un simple coup d'œil : 1) Il ajoute effectivement --top et modifie la gestion des arguments (conforme au plan) ; 2) Il n'a pas touché sans raison à la fonction fonctionnelle count_words ; 3) Il n'a pas introduit en douce de dépendances tierces (règle fixée par le fichier CLAUDE.md). Si tout correspond, validez.

Comment parcourir rapidement un diff ? Inutile de le lire mot à mot, concentrez-vous sur trois signaux : les lignes rouges (-, ce qui est supprimé) ne doivent pas contenir de code que vous souhaitez conserver ; les lignes vertes (+, ce qui est ajouté) ne doivent pas importer de dépendances non souhaitées ou ajouter des fonctions non demandées ; le périmètre modifié ne doit pas déborder des zones prévues. Dans notre exemple, les lignes rouges retirent la gestion manuelle de sys.argv, les lignes vertes ajoutent argparse et --top, et les modifications sont circonscrites à la fonction main() — tout est conforme à ce qui était prévu, vous pouvez approuver sans crainte.

Concernant le mode d'acceptation automatique, voici un conseil pour les débutants : évitez de l'utiliser durant votre phase d'apprentissage. Le guide de démarrage rapide (quickstart) indique que vous pouvez activer le mode d'acceptation automatique pour la session (l'option acceptEdits vue au chapitre 20) ; une fois activé, l'outil applique toutes les modifications directement sans vous solliciter. C'est pratique, mais vous perdez totalement votre contrôle d'interception en cours de route. La démarche la plus sûre consiste à ne l'activer que dans deux situations : soit les modifications ont déjà été analysées ligne par ligne en plan mode et vous êtes confiant, soit il s'agit d'une série de modifications répétitives et mécaniques (comme renommer une variable sur plusieurs occurrences). Durant les premiers mois, validez consciencieusement chaque étape pour aiguiser votre regard sur les diffs avant d'automatiser le processus.

Pourquoi la phase de revue est-elle indispensable ? Parce que la génération de code par l'IA n'est pas binaire (juste ou faux) : il arrive fréquemment que le résultat soit correct dans les grandes lignes mais s'égare sur des détails — il peut modifier des éléments non demandés ou retenir une implémentation non souhaitée. Rappelons cette consigne essentielle du chapitre 20 :

Claude Code demande toujours la permission avant de modifier des fichiers.

Cette demande de permission n'est pas une simple formalité, c'est votre unique opportunité d'intercepter les erreurs en direct — une fois validée et appliquée, vous devrez recourir aux points de contrôle du chapitre 37 ou à Git pour annuler les changements a posteriori, ce qui s'avère plus fastidieux. Vérifier le diff en cours de route sera toujours plus efficace que de devoir faire un rollback après coup.

💡 Résumé en une phrase : Durant la phase d'action, laissez-le modifier mais examinez chaque diff — validez que les changements ciblent bien les zones prévues, ne dégradent pas le code existant et respectent les consignes de CLAUDE.md ; cette étape est votre seule fenêtre d'interception en direct, valider sans regarder revient à repousser la correction des erreurs à plus tard.

---

07 Validation : exiger des tests réels, ne croyez pas sur parole le « j'ai fini »

Une fois le code modifié, il vous affichera sans doute un message comme « J'ai appliqué les modifications, ajouté l'argument --top et résolu le problème de plantage ». Ne croyez pas un traître mot de cette affirmation tant que vous ne l'avez pas vu fonctionner de vos propres yeux. C'est l'avant-dernier relais du parcours, et c'est celui que les débutants ont le plus tendance à ignorer.

Pour faire court : le « c'est réparé » déclaré par l'outil ne prouve rien, seule « l'exécution validée » fait foi. C'est précisément l'exigence de la consigne « valider activement après modification, ne pas se contenter de modifier » ; en pratique, cela se traduit par : exécuter vous-même les critères d'acceptation.

Étape 1 : Valider la nouvelle fonctionnalité (--top)

python3 wordcount.py sample.txt --top 3

Sortie attendue (triée par fréquence décroissante, limitée aux 3 premiers mots) :

the: 3
fox: 2
quick: 1

Si vous n'obtenez que les trois premiers mots triés par fréquence = la nouvelle fonctionnalité est opérationnelle. (the apparaît 3 fois, fox 2 fois, et le troisième mot est l'un de ceux qui n'apparaissent qu'une seule fois).

Étape 2 : Vérifier que l'existant n'a pas été dégradé (régression)

Après l'ajout du nouveau paramètre, l'ancien comportement ne doit pas planter — l'exécution sans --top doit continuer à tout afficher comme avant :

python3 wordcount.py sample.txt

Attendu : La sortie doit être identique à celle obtenue à la section 02 (les six mots sont présents). Cette identité prouve que = vous n'avez pas introduit de régression en ajoutant la nouvelle fonctionnalité.

Étape 3 : S'assurer que le bug est réellement résolu

C'est l'étape la plus critique — reproduire la situation du plantage initial pour vérifier si le script affiche désormais un avertissement propre plutôt qu'une erreur de traceback :

python3 wordcount.py

Attendu : Le script ne s'arrête plus sur une exception IndexError, mais affiche une invite d'utilisation propre, du type :

usage: wordcount.py [-h] [--top TOP] path
wordcount.py: error: the following arguments are required: path

Le passage de « l'application se crash en affichant un traceback indéchiffrable » à « l'application indique clairement qu'il manque l'argument path » — est la preuve formelle que le bug est corrigé. Ces trois tests validés, le travail est officiellement accompli.

Vous voulez encore plus de sécurité ? Demandez-lui d'en faire un test automatisé. Les trois étapes ci-dessus consistent en des vérifications manuelles uniques ; cependant, lors d'une prochaine modification de code par un tiers, le bug pourrait réapparaître. Une approche plus robuste consiste à demander à Claude de rédiger un petit script de test, transformant la règle « afficher un message d'erreur propre en l'absence de fichier » en un test répétable — les common workflows officiels recommandent d'ailleurs de « commencer par écrire un test qui reproduit le bug, puis de faire passer ce test » (ce qui fait écho à la consigne « écrire un test reproduisant le bug puis le valider ») :

给「不传文件名时不崩溃、而是退出码非 0 并打印用法提示」写一个测试，再确认它通过。

Attendu : Claude rédige un court test (exécutant le script avec subprocess et vérifiant le code de retour ainsi que la sortie standard), puis le lance pour obtenir un voyant vert. Cette étape transforme une vérification ponctuelle en une assurance de non-régression automatique pour l'avenir — optionnel pour un entraînement rapide, cela devient indispensable sur un projet professionnel. Vous pouvez vous en passer sur de petites tâches, mais gardez cette logique à l'esprit.

Pourquoi insister autant sur les tests réels ? Parce que le piège du « c'est réparé » a déjà fait de nombreuses victimes. L'outil assure avoir résolu un cas aux limites et valide le commit sans exécuter le code. Or, le cas aux limites n'est pas couvert, car les modifications ont ciblé une portion de code connexe mais non concernée. Retenez donc cette règle d'or : le « terminé » affirmé par l'IA n'est qu'une hypothèse ; seul le succès du test exécuté fait foi. Cela rejoint directement la règle du projet : « Si une validation est déclarée, elle doit avoir été physiquement exécutée ».

💡 Résumé en une phrase : Validation = effectuer trois tests manuels — vérifier la nouvelle fonctionnalité, s'assurer de l'absence de régression et valider la correction du bug ; le « c'est fait » de l'IA n'est qu'une hypothèse, seule votre exécution valide la réalité. Ne négligez jamais cette étape.

---

08 Livraison : lui déléguer la rédaction du commit et archiver le travail

Une fois les trois tests validés, passons au dernier relais — la livraison, pour enregistrer proprement ce travail dans Git. Cela correspond à la fonctionnalité de « Git conversationnel » présentée à la fin du chapitre 07.

Étape 1 : Passer en revue les modifications appliquées

我改了哪些文件？给我一个改动概览。

Attendu : Claude lance git status / git diff et indique que seul wordcount.py a été modifié pour ajouter le paramètre --top et intégrer argparse. Cette dernière vérification permet de s'assurer que le périmètre modifié correspond bien à vos attentes avant la livraison.

Étape 2 : Lui faire générer le message de commit et valider

用一句话描述清楚这次改动，提交它。

Attendu : Claude vous présentera d'abord sa proposition de message de commit — par exemple « feat: ajouter le paramètre --top N à wordcount et corriger le plantage par manque d'arguments avec argparse » — avant de solliciter l'autorisation d'exécuter git commit. Il s'agit à nouveau de la barrière de sécurité vue au chapitre 20 : il vous consultera systématiquement avant de modifier votre historique Git.

Précisons une limite essentielle : l'outil vous demande confirmation pour un git commit ; en revanche, le git push (envoi vers le serveur distant) est une autre affaire. Avant d'envoyer votre travail sur un dépôt distant comme GitHub, assurez-vous de garder le contrôle et de vérifier vous-même cette étape — c'est le sujet détaillé du chapitre 43 « Flux de travail Git ». Pour le moment, retenez ceci : vous pouvez lui déléguer le commit local, mais gardez la main sur le push distant.

Étape 3 : Confirmer la réussite du commit

显示我最后 1 次提交。

Attendu : Il exécute git log -1, affichant le message et les détails du commit que vous venez de valider. La vue de ce commit confirme que = la tâche est officiellement livrée, bouclant ainsi l'intégralité du cycle de développement.

Prenez un instant pour contempler le chemin parcouru : d'un script brut instable et incomplet, vous avez abouti à un outil fonctionnel gérant l'argument --top et affichant des instructions claires en cas d'erreur. Et tout cela en n'utilisant que quelques phrases simples en langage naturel — dont chacune s'insérait précisément à sa place dans le cycle des six étapes. C'est cela, savoir orchestrer les différentes briques.

💡 Résumé en une phrase : Livraison = vérifier le résumé des modifications → lui demander de préparer le message et de faire le commit (après confirmation) → lancer git log pour valider l'archivage ; gardez à l'esprit la limite : déléguer le commit local oui, mais gérer le push distant soi-même (sujet du chapitre 43).

---

09 Que faire en cas d'erreur : revenir à un état propre, ne tentez pas de réparer un code bancal

Le parcours ci-dessus s'est déroulé sans accroc car la tâche avait été calibrée pour cela. Les cas réels sont rarement aussi simples — l'étape de validation échoue souvent, que ce soit parce que la fonctionnalité ne répond pas aux attentes ou parce qu'un autre composant a été cassé. Face à cette situation, la réaction instinctive des débutants est généralement inappropriée : demander à l'outil de « corriger à partir du code déjà altéré ».

Éviterez cela à tout prix. Appliquer des correctifs successifs sur un état déjà instable ne fera qu'aggraver la situation — l'outil s'appuyant à chaque fois sur le contexte erroné de la version précédente, les anomalies risquent de se multiplier. La bonne approche consiste à revenir proprement à un état sain connu, puis à relancer le processus en formulant des instructions plus précises. C'est à ce moment que les points de contrôle du chapitre 37 et le commit Git initial effectué à la section 02 prennent tout leur sens.

Il existe deux niveaux de retour en arrière, selon l'avancement de vos modifications :

Niveau de retour	Outil à utiliser	Point d'arrivée	Adapté pour
Niveau léger : annuler les dernières éditions	Les points de contrôle du chapitre 37, /rewind	Avant les modifications de fichiers par Claude	Une ou deux erreurs identifiées immédiatement et que l'on souhaite annuler
Niveau lourd : retour à l'origine	Git, git restore . ou git reset --hard	Votre commit propre avant de démarrer	Une mauvaise direction globale nécessitant de repartir de zéro

Le niveau léger est le plus courant : saisir /rewind dans la session permet d'annuler les éditions de fichiers effectuées lors de la dernière passe de Claude (le chapitre 37 détaillait ses limites — il gère les fichiers et la conversation, mais ne doit pas remplacer Git). Le niveau lourd sert de sécurité ultime : si le code est devenu totalement illisible et que les points de contrôle ne suffisent plus, revenez au commit initial créé à la section 02 — c'est pour cette raison qu'un commit avant de démarrer est indispensable, ce commit propre est votre refuge permanent pour repartir à zéro.

Une fois revenu en arrière, ne répétez pas la même instruction à l'identique. Analysez d'abord pourquoi l'outil s'est égaré — c'est le plus souvent dû à une exploration insuffisante ou à une consigne trop évasive (l'importance de « s'exprimer clairement » vue au chapitre 15). Un retour d'expérience précieux : si l'outil se trompe lors de sa première tentative, c'est à 90 % parce que l'instruction manquait d'une contrainte essentielle, par exemple omettre de préciser « ne modifie que cette fonction, ne touche à rien d'autre ». Revenir au point de départ et affiner la consigne permet généralement de réussir la seconde tentative. Revenir en arrière n'est pas un échec, c'est une mesure de protection — cela vous fera gagner bien plus de temps que de vous acharner à corriger un code corrompu.

💡 Résumé en une phrase : Si les modifications dévient, le premier réflexe doit être de revenir à un état propre, pas de tenter de corriger le code altéré ; utilisez /rewind pour les ajustements légers et Git pour revenir au point de départ initial ; affinez vos consignes avant de relancer l'outil.

---

10 Comparatif : l'approche de l'expert vs l'approche du débutant

Bien que les six étapes soient identiques, la mise en œuvre varie grandement entre un utilisateur expérimenté et un débutant — tout se joue dans la rigueur apportée à chaque relais. Voici un comparatif des pièges classiques pour vous aider à vous évaluer :

Étape	❌ Pièges classiques du débutant	✅ Pratique de l'expert
Lancement	Lance claude depuis n'importe quel répertoire, sans fichier CLAUDE.md	Se place dans le bon répertoire, rédige un CLAUDE.md minimal de quelques lignes pour fixer les règles
Exploration	Lance directement les modifications, fait l'impasse sur la compréhension	Commence systématiquement par « ne modifie rien pour l'instant, explique-moi », pour le laisser analyser l'état existant
Planification	Le laisse coder directement, ne constate les dérives qu'une fois le travail fini	Exige un plan de modification, attend sa validation avant de lancer le code ; utilise le plan mode en cas de doute
Action	Approuve tous les diffs en tapant y à la chaîne sans les lire	Vérifie chaque diff d'un coup d'œil : justesse des lignes, respect du périmètre
Validation	Se fie au message « c'est corrigé » pour considérer le travail terminé	Exécute physiquement trois validations : nouvelle fonction, régression, correction de bug
Livraison	Laisse les modifications en attente, ou valide sans vérifier le périmètre	Vérifie le résumé des modifications, lui fait rédiger le commit, contrôle avec log

Ce tableau se résume en une formule : le débutant raccourcit le cycle à deux étapes (exprimer le besoin → obtenir le résultat), tandis que l'expert applique scrupuleusement les six étapes. Tout le monde a tendance à chercher des raccourcis au début. Ce n'est qu'après avoir subi les conséquences de dérives de code combinées à des validations sans test que l'on intègre la nécessité de ce cycle. Les deux étapes clés à acquérir en priorité comme des réflexes sont l'exploration préalable et la validation manuelle finale. En sécurisant ces deux verrous, vous éliminez la grande majorité des risques de dysfonctionnement majeur.

Une question revient souvent : « N'est-il pas trop fastidieux de répéter ces six étapes à chaque fois ? » Non, car plus la tâche est simple, plus chaque étape s'exécute rapidement — pour notre exercice, l'ensemble du cycle a demandé à peine dix minutes. De plus, avec l'expérience, vous combinerez fréquemment l'exploration et la planification en une seule consigne (comme « analyse @file puis propose-moi ton plan pour modifier X, sans toucher au code »). La méthode fournit un cadre structurant, ce n'est pas une contrainte rigide ; une fois le cadre assimilé, libre à vous d'accélérer le rythme.

💡 Résumé en une phrase : La différence entre l'expert et le débutant réside uniquement dans le respect de la transmission des relais ; les deux verrous indispensables à acquérir sont l'exploration en amont et la validation manuelle en aval ; le cycle s'adapte à la taille de la tâche, la méthode est un repère et non une contrainte.

---

Conclusion

Cet article n'a introduit aucune nouvelle fonctionnalité, il s'est concentré sur une seule mission : vous guider pour assembler pour la première fois les briques abordées dans les trente-huit chapitres précédents au sein d'un cycle de développement complet sur un cas pratique réel.

Si l'on passe en revue la séquence de messages que vous avez saisis, vous constaterez qu'elle se compose de six ou sept instructions simples, chacune correspondant à un relais précis :

# 开工后（先定规矩）
帮我建个 CLAUDE.md：纯标准库别引第三方依赖；改完跑 python3 wordcount.py sample.txt 验证

# 探索（先看懂、别动手）
先别改任何代码。讲讲 @wordcount.py 怎么工作的、有没有容易崩的地方？

# 规划（出方案、等点头）
我想加 --top N 只看高频前 N 个词，顺手修不传文件名就崩溃的问题。先说方案，等我说开始再动手。

# 动手（点头放行，然后逐处审 diff）
方案可以，开始改吧。

# 验证（亲手跑，不信它说的）
（回终端跑：--top 3 / 不带 top / 不带文件名，三条各验一遍）

# 交付（看范围 → 提交 → 确认）
我改了哪些文件？ → 用一句话描述清楚这次改动，提交它。 → 显示我最后 1 次提交。

Vous le voyez bien : le développement en conditions réelles s'appuie sur ces quelques instructions en langage naturel. La difficulté ne réside pas dans la formulation des phrases, mais dans leur enchaînement logique. Récapitulons les six étapes de ce flux de travail :

Étape	Rôle de l'étape	Chapitres de référence	Point clé en une phrase
Lancement	Se placer dans le bon répertoire et rédiger un CLAUDE.md minimal	02 / 07 / 12 / 18	Fixer la règle générale une fois pour toute la session
Exploration	Lui faire analyser le code sans le modifier	16	Commencer impérativement par « ne modifie rien pour l'instant »
Planification	Exiger un plan de modification pour validation	20 (plan mode)	Utiliser Shift+Tab pour verrouiller l'édition en cas de doute
Action	Appliquer les modifications et examiner chaque diff	20 (permissions)	Intercepter en direct est plus efficace qu'un rollback a posteriori
Validation	Exécuter les tests manuellement, ignorer les affirmations d'état	16 / 37	Seul le succès du test exécuté fait foi
Livraison	Valider le périmètre → préparer le message → commit	07	Déléguer le commit local oui, mais gérer le push soi-même

Vous devriez désormais être capable de : aborder n'importe quelle tâche simple de type « ajoute cette fonctionnalité / corrige ce bug » sans vous demander par quelle commande démarrer dans le terminal. Suivez mentalement ces six étapes (Lancement, Exploration, Planification, Action, Validation, Livraison) en transmettant chaque témoin avec rigueur ; veillez particulièrement aux deux verrous clés (exploration préalable et validation finale) pour éviter que Claude ne modifie le code de façon aléatoire et vous assurer du bon fonctionnement après modifications. Une fois ce flux de travail maîtrisé, toutes les briques techniques étudiées précédemment s'assemblent pour devenir réellement opérationnelles au service de vos développements.

Cet article marque un tournant — à partir d'ici, nous considérerons que vous maîtrisez l'enchaînement de ce cycle de travail. Les chapitres suivants s'appuieront sur ce socle pratique pour introduire de nouvelles compétences.

Le chapitre suivant 40 « Chrome : lui faire manipuler le navigateur » — dans cette session pratique, Claude s'est limité à des actions sur les fichiers locaux et la console. Mais dans l'activité réelle, de nombreuses opérations s'effectuent au sein du navigateur : soumettre un formulaire, interagir avec une page, extraire des données web, ajuster des styles sur un rendu réel. Le chapitre suivant lui associera cette capacité de navigation pour lui permettre de dépasser la simple édition de code et d'effectuer des interactions physiques à la souris. Imaginez — lorsque Claude pourra non seulement modifier votre code mais aussi manipuler le navigateur à votre place, l'éventail de ses contributions s'élargira considérablement.

---

Lectures recommandées

• Intégration JetBrains
• Output Styles : changer de « programme », pas d'animateur
• Les quatre tâches les plus courantes : explorer le codebase, corriger des bugs, refactoriser, écrire des tests