Claude Code en pratique

Claude Code est installé ; apprenons à en tirer le maximum. L’outil est conçu pour travailler avec vous tout au long de chaque phase d’un projet logiciel — comme un ingénieur supplémentaire dans votre équipe, qui aurait lu tout le code mais attendrait vos directives. Et comme avec un nouvel équipier, la qualité de la collaboration dépend surtout du contexte que vous lui donnez : c’est le fil rouge de cette leçon.

La commande /init

Le premier geste sur tout projet : lancez /init pour que Claude scanne votre codebase et génère un fichier CLAUDE.md — structure du projet, dépendances, commandes, conventions — qui sera automatiquement inclus comme contexte dans toutes les conversations futures. C’est la mémoire longue du projet : ce qui y figure n’a plus jamais besoin d’être réexpliqué, session après session.

Portées disponibles :

• Projet : partagé entre tous les ingénieurs
• Local : vos notes personnelles (non dans git)
• Utilisateur : utilisé sur tous vos projets

Les trois portées se superposent naturellement : les conventions d’équipe dans le fichier projet (commité), vos préférences globales au niveau utilisateur, vos notes de travail en local. Enrichissez-le au fil de l’eau — chaque règle documentée améliore toutes les sessions futures.

Flux de travail recommandé

Le réflexe naïf — décrire la fonctionnalité et laisser Claude foncer — fonctionne sur les petites tâches et déçoit sur les grandes. Le flux recommandé sépare les phases :

Étape 1 : Alimenter Claude en contexte

Identifiez les fichiers pertinents et demandez à Claude de les lire d’abord. Un agent qui a lu le code existant s’y intègre ; un agent qui ne l’a pas lu plaque du code générique dessus.

Étape 2 : Demander à Claude de planifier

Demandez à Claude de réfléchir au problème et créer un plan — en lui disant explicitement de ne pas encore écrire de code. C’est l’étape qui change tout : un plan se lit en une minute et se corrige en une phrase, là où un mauvais code se détecte après coup et se réécrit longuement. Vous validez la direction avant d’engager l’exécution.

Étape 3 : Demander l’implémentation

Une fois le plan validé, demandez à Claude de l’implémenter. Il s’appuie alors sur le contexte lu et le plan approuvé — les deux investissements des étapes précédentes paient ici.

Approche TDD

Pour les fonctionnalités où la robustesse prime, la variante Test-Driven Development ajoute un cran de rigueur :

1. Alimenter Claude en contexte
2. Demander des cas de test
3. Implémenter les tests
4. Écrire le code qui passe les tests

La beauté du TDD avec un agent : les tests donnent à Claude un critère de succès exécutable. À l’étape 4, il lance la suite, lit les échecs, corrige, relance — et itère seul jusqu’au vert. Vous obtenez du code qui couvre des cas limites auxquels vous n’auriez pas pensé, validé par une définition du « fini » que personne ne peut discuter.

Commandes utiles

Deux habitudes à prendre avec ce trio : # capture une convention à la volée sans interrompre le travail (« # toujours utiliser pnpm ici »), et /clear repart de zéro quand la conversation a accumulé du contexte hors sujet — un historique pollué dégrade les réponses, et le nettoyer est souvent le correctif le plus simple.

Points clés à retenir

• /init crée le CLAUDE.md, mémoire du projet lue à chaque session — enrichissez-le en continu
• Trois portées complémentaires : projet (équipe), local (perso), utilisateur (global)
• Flux gagnant : contexte → plan sans code → implémentation — corriger un plan coûte moins qu’un refactor
• TDD : les tests font critère de succès exécutable, Claude itère seul jusqu’au vert
• # pour noter à la volée, /clear pour assainir une conversation encombrée