Mon workflow avec Claude Code : contexte, plan et relecture

Claude Code est mon environnement de code principal et fait partie de mon setup de développement. Voici ma méthode : donner à l'outil le contexte du projet, planifier les changements qui traversent plusieurs fichiers, réutiliser les procédures stables, puis relire le diff. C'est un retour d'expérience, pas un benchmark contrôlé de vitesse.

Le changement : de l'éditeur à la conversation

L'intérêt est de pouvoir montrer un pattern existant : "implémente la page blog en suivant le même pattern que la page freebie". Claude peut examiner le projet et proposer un changement qui suit ses types, sa gestion d'erreurs et ses imports. Je vérifie ensuite ce qu'il a réellement fait.

Ça ne marche que si Claude connaît les conventions de ton projet. Ce qui m'amène au premier point.

1. CLAUDE.md n'est pas optionnel

Chaque projet reçoit un CLAUDE.md à la racine. C'est un fichier markdown que Claude Code lit au début de chaque session. Le mien contient :

• Stack : framework, langage, bibliothèques clés
• Conventions : ordre des imports, pattern de gestion d'erreurs, style de logging
• Règles : ce qu'on ne fait jamais (ex. pas de try/catch dans les actions, pas de console.log)
• Architecture : structure des dossiers et quelle couche possède quoi

Sans ces consignes, Claude doit déduire davantage de conventions à partir des fichiers qu'il voit. Un CLAUDE.md réduit cette part d'interprétation, mais ne remplace pas la relecture du diff.

2. Plan Mode avant toute tâche non triviale

Pour un changement qui traverse plusieurs fichiers ou frontières, je demande d'abord à Claude d'examiner le code concerné et de proposer une approche. Je corrige le plan s'il manque une contrainte. Pour une typo ou une retouche locale, ce détour ajouterait du travail : je fais plus simple.

3. Des skills pour les tâches qui reviennent

Les tâches répétées deviennent des skills. J'en ai pour committer proprement, faire une revue avant livraison, scanner la sécurité et préparer mon briefing du matin.

Chaque skill est un fichier markdown décrivant exactement ce qu'il faut faire. On l'invoque, il s'exécute. Pas de copier-coller de prompts, pas de remise en contexte. Le Claude Code Skills Starter Kit regroupe ceux que j'utilise chaque jour, prêts à déposer dans ~/.claude/.

4. Des hooks pour les tâches répétitives

Les hooks Claude Code sont des commandes shell qui s'exécutent sur des événements (fichier sauvegardé, session démarrée, Claude s'est arrêté). Je les utilise pour :

• Injecter automatiquement la date du jour dans chaque session
• Envoyer une notification push quand une longue tâche est terminée
• Lancer le linter après chaque écriture de fichier

Ce hook repère certaines erreurs de format plus tôt. Je n'ai pas mesuré de gain hebdomadaire, donc je ne lui attribue pas de durée économisée.

5. Je le laisse explorer, puis je relis

La boucle qui m'a le plus surpris : je décris une fonctionnalité, Claude explore le codebase, propose une approche dans le chat, je valide ou je corrige. Ensuite seulement il implémente. Moi, je relis le diff.

J'ai arrêté de dicter chaque ligne. La qualité a monté quand je me suis concentré sur le plan, les contraintes et la relecture.

Ce qui n'a pas marché

• Déléguer sans contexte : Claude écrit du code générique sans tes conventions. CLAUDE.md corrige ça.
• Accepter aveuglément le premier résultat : c'est rapide, pas parfait. Lis le diff.
• L'utiliser pour tout : les petites modifications sont plus rapides à la main. Réserve Claude pour ce qui demande de la réflexion.

Ce que ce workflow ne prouve pas

J'avais comparé une estimation de 2 h 30 pour une fonctionnalité à une estimation de 40 minutes avec ce workflow. Je n'avais ni journal daté des tâches, ni contrôle de leur difficulté, de ma familiarité avec le code ou des retouches nécessaires. Cette comparaison ne permet donc pas d'affirmer un multiplicateur de vitesse. Ce que je peux dire plus précisément : mon workflow actuel inclut des consignes de projet, un plan pour les changements qui traversent plusieurs fichiers et une relecture du diff. Le résultat dépend de la tâche et du niveau de vérification nécessaire.

Pour mesurer votre propre résultat, choisissez plusieurs tâches comparables et chronométrez toujours les mêmes étapes : compréhension, plan, implémentation, relecture et corrections. Gardez le type de tâche et la définition de « terminé » constants ; indiquez l'échantillon et les dates si vous publiez un chiffre.

---

Tu veux les Skills et hooks de ce workflow ? Le Claude Code Skills Starter Kit peut servir de base ; vérifie chaque fichier selon les règles de ton projet avant de l'activer.