Workflows de base : plan, edit, run, review

La plus grosse erreur avec Claude Code est de le traiter comme un distributeur automatique : on y glisse une demande vague en espérant qu'une fonctionnalité finie en tombe. Les ingénieurs qui en tirent un vrai levier font tourner une boucle serrée : cadrer la tâche, laisser Claude planifier, faire de petites modifications, lancer les tests et relire le diff avant que quoi que ce soit touche `main`. Cette leçon parcourt cette boucle de bout en bout.

Si vous ne l'avez pas encore installé, Claude Code est l'agent de codage d'Anthropic qui fonctionne dans le terminal. Vous lancez claude dans un repo et il lit vos fichiers, propose des modifications et exécute des commandes avec votre permission. La documentation Claude Code est la référence canonique ; cette leçon porte sur les *habitudes* qui le rendent fiable.

Cadrez avant de taper

Claude Code est à son pire quand la cible est floue. « Refactorise le module d'auth » invite à un changement tentaculaire, difficile à relire. La solution consiste à cadrer serré avant de demander quoi que ce soit.

Une tâche bien cadrée a trois propriétés :

• Une frontière claire. Un module, un bug, un endpoint. Pas « tout le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → ».
• Une définition du « terminé ». En général un test qui passe ou un comportement que vous pouvez vérifier.
• Des fichiers nommés, quand vous les connaissez. Pointer Claude vers src/auth/session.ts vaut mieux que le laisser grep à l'aveugle.

Comparez ces deux ouvertures :

Corrige le bug de login.

Dans src/auth/session.ts, les sessions n'expirent pas après le TTL de 30 minutes. Trouve la cause et corrige-la. Il y a un test en échec dans session.test.ts qui doit passer quand tu auras terminé.

La seconde donne à Claude une frontière, une condition de fin et un fichier de départ. Vous obtiendrez un changement plus petit et plus juste.

Plan mode : réfléchir avant d'éditer

Le plan mode est la fonctionnalité qui transforme Claude Code d'un générateur de code en collaborateur. Quand vous l'activez, Claude investigue votre codebase et produit un plan écrit sans modifier aucun fichier. Rien ne se passe sur le disque avant votre validation.

Vous le basculez en cours de session. Appuyez sur Shift+Tab pour faire défiler les permission modes (plus de détails ci-dessous) ; l'un d'eux est le plan mode. Vous pouvez aussi démarrer une session dedans.

Voici la différence que cela fait. Sans plan mode, Claude peut réécrire immédiatement trois fichiers sur la base d'une supposition. En plan mode, il revient avec quelque chose comme :

Plan : la vérification du TTL dans validateSession() compare createdAt à Date.now() mais utilise des secondes d'un côté et des millisecondes de l'autre. Je vais : (1) normaliser les deux en millisecondes, (2) ajouter une garde pour createdAt manquant, (3) confirmer que session.test.ts passe. Je continue ?

Vous pouvez maintenant corriger l'approche *avant* la moindre modification. Si Claude a mal lu le bug, vous passez dix secondes à le réorienter au lieu de relire un diff erroné de 200 lignes. Pour tout ce qui n'est pas trivial, planifiez d'abord. Le coût est de quelques secondes ; le gain est de piloter au moment le moins cher possible.

Permission modes : quelle laisse lui donner

Claude Code ne s'emballe pas sur votre machine. Chaque action potentiellement impactante (modifier un fichier, lancer une commande shell, accéder au réseau) est encadrée par un permission mode : la politique qui décide de ce que Claude peut faire sans s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êter pour vous demander.

Les modes que vous utiliserez en pratique :

• Default (ask). Claude propose chaque modification et chaque commande, puis attend votre validation. Le plus sûr. À utiliser sur du code inconnu ou tout ce qui approche la production.
• Plan mode. Lecture et analyse uniquement. Pas de modifications, pas de commandes. À utiliser pour cadrer et concevoir.
• Accept edits. Claude applique les modifications de fichiers automatiquement mais demande encore avant de lancer des commandes. Bien quand vous faites confiance aux modifications mais voulez un garde-fou sur l'exécution.
• Bypass / « dangerously skip permissions ». Claude agit sans demander. Rapide, et réellement risqué. Réservez-le aux sandboxes, aux branches jetables ou aux conteneurs que vous pouvez détruire.

Le réflexe des nouveaux utilisateurs est de contourner les permissions pour « aller plus vite ». Résistez-y sur de vrais repos. Toute la valeur de la boucle est que vous y restez. Un bon défaut : plan mode pour concevoir, accept-edits pour implémenter, validation manuelle pour toute commande qui écrit hors du répertoire de travail.

Vous pouvez aussi pré-autoriser certains outils pour ne pas valider cinquante fois la même commande inoffensive. Mettez-les en allowlist dans `.claude/settings.json` à la racine du repo :

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint)",
      "Read(src/**)"
    ],
    "ask": ["Bash(git push:*)"]
  }
}

Cela dit : lance librement les commandes de test et de lint, lis tout ce qui est sous src/, mais arrête-toi toujours pour demander avant un push. Committez ce fichier et toute votre équipe hérite des mêmes garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète →.

Éditez par petites étapes relisibles

La tentation est de demander la fonctionnalité entière d'un coup. Ne le faites pas. L'unité relisible est le diff que *vous* pouvez tenir en tête, et c'est généralement 50 à 150 lignes, pas 600.

Découpez le travail en étapes et validez chacune :

1. « Ajoute la constante SessionTTL et branche-la dans le config loader. »
2. « Maintenant corrige l'incohérence d'unités dans validateSession(). »
3. « Ajoute un test de régression pour le cas d'expiration. »

Après chaque étape, vous regardez ce qui a changé. Ce n'est pas de la bureaucratie ; c'est ainsi que vous attrapez un mauvais virage à l'étape un plutôt que de le dérouler à l'étape cinq. Les petites étapes gardent aussi le contexte de Claude focalisé : il raisonne sur un changement, pas sur une epic entière.

Un pattern de prompt utile : terminez vos demandes par « Fais uniquement ce changement. Arrête-toi et montre-moi avant de faire autre chose. » Cela empêche un modèle zélé de sprinter trois étapes en avant.

Lancez les tests, laissez Claude lire les échecs

Une fois les modifications en place, lancez vos tests. Le mouvement puissant consiste à laisser Claude les lancer lui-même (en allowlist, comme ci-dessus) et lire la sortie. Les tests en échec sont le feedback le plus riche en signal que vous pouvez donner à un agent de codage.

claude "Run the test suite. If anything fails, diagnose and fix it, then re-run until green. Show me the diff before committing."

Claude va exécuter npm test (ou ce que votre projet utilise), analyser les échecs, patcher et boucler. Ce cycle de feedback fermé est là où Claude Code gagne sa place : il ne devine pas si le correctif a marché, il *vérifie*. Votre travail est de vous assurer que les tests sont pertinents. Si votre test n'affirme rien de réel, un run vert ne signifie rien, et c'est de votre faute, pas de celle du modèle.

Slash commands : les commandes que vous utiliserez vraiment

Les slash commands sont des raccourcis tapés dans une session Claude Code. Quelques-unes à connaître par cœur :

• `/clear` efface le contexte de la conversation. À utiliser entre des tâches sans rapport pour qu'un raisonnement périmé ne vienne pas s'infiltrer. Peu coûteux et sous-utilisé.
• `/review` demande à Claude de relire du code, souvent un diff ou une PR en attente.
• `/init` génère un fichier CLAUDE.md : un document de mémoire projet où vous consignez les commandes de build, les conventions et les pièges, pour que Claude les lise à chaque session.
• `/model` change le modèle Claude utilisé par la session.
• `/permissions` ouvre les réglages de permissions.

La plus précieuse est celle que vous écrivez vous-même. Les slash commands personnalisées ne sont que des fichiers Markdown dans .claude/commands/. CrCrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éez .claude/commands/fix-issue.md :

Find the root cause of issue #$ARGUMENTS, scope a minimal fix,
write a failing test that reproduces it, then make it pass.
Show me the diff before committing.

Désormais /fix-issue 412 exécute tout ce workflow avec le numéro d'issue injecté. Tout ce que vous faites de manière répétée devrait devenir une commande que votre équipe partage via le repo.

Relisez le diff comme si vous l'aviez écrit

Voici la discipline qui sépare les professionnels des utilisateurs « prompt-and-pray » : vous relisez chaque diff avant qu'il ne soit committé, exactement comme vous relirez la pull request d'un collègue humain.

Demandez le diff explicitement, ou utilisez /review. Puis lisez-le vraiment. Guettez les modes de défaillance propres au code généré par IA :

• Dérive de périmètre silencieuse. Vous avez demandé un correctif de TTL ; le diff a aussi « gentiment » renommé trois fonctions. Refusez les extras.
• Logique plausible mais fausse. Du code qui se lit bien et qui est subtilement incorrect est la sortie la plus dangereuse de Claude. Les tests en attrapent beaucoup ; vos yeux attrapent le reste.
• Cas limites supprimés. Une réécriture « plus propre » qui a discrètement supprimé un contrôle de null.
• Erreurs avalées. Un try/catch qui masque précisément l'échec que vous déboguiez.

Comme vous avez travaillé par petites étapes, cette relecture est rapide. Un diff de 100 lignes face à un plan clair prend deux minutes. Un diff de 600 lignes face à une demande vague, c'est là que les bugs se glissent dans main.

Committez, puis poussez via GitHub

Quand le diff est bon, committez-le. Claude peut écrire le message ; vous confirmez qu'il correspond à ce qui a réellement changé.

Pour le dernier kilomètre, l'intégration GitHub de Claude vous permet d'aller plus loin que votre terminal. Mentionnez @claude dans une issue ou un commentaire de PR et il peut ouvrir des pull requests, répondre aux retours de revue et s'exécuter comme GitHub Action en CI. La boucle locale que vous venez de pratiquer (plan, edit, run, review) est la même boucle, tournant désormais sur une pull request où vos coéquipiers relisent aussi le diff.

Cette symétrie compte. Les habitudes passent à l'échelle : une boucle serrée sur votre portable est une boucle serrée en CI.

Assembler la boucle

Une vraie session, du début à la fin :

1. Scope. « Les sessions n'expirent pas après le TTL de 30 min. Corrige ça dans session.ts, fais passer session.test.ts. »
2. Plan (Shift+Tab pour le plan mode). Lisez le diagnostic de Claude, validez-le ou corrigez-le.
3. Edit (mode accept-edits). Appliquez le changement minimal.
4. Run. Laissez Claude lancer la suite et itérer jusqu'au vert.
5. Review. Lisez le diff. Refusez la dérive de périmètre.
6. Commit et push. Confirmez le message, ouvrez la PR.

Chaque étape est un point de contrôle où un mauvais virage coûte des secondes au lieu d'heures.

Points clés

• Cadrez chaque tâche avec une frontière, une condition de fin et des fichiers nommés. Les demandes vagues produisent des diffs tentaculaires, impossibles à relire.
• Planifiez avant d'éditer. Utilisez le plan mode (Shift+Tab) pour corriger l'approche avant qu'un seul fichier ne change, au moment où le pilotage coûte le moins cher.
• Réglez les permission modes délibérément et mettez les commandes sûres en allowlist dans .claude/settings.json. Plan mode pour concevoir, accept-edits pour construire, validation manuelle pour tout ce qui écrit hors du répertoire de travail.
• Travaillez par étapes de 50 à 150 lignes et laissez Claude lancer les tests. Les tests en échec sont le feedback le plus riche en signal sur lequel un agent peut agir.
• Relisez chaque diff comme une PR avant de committer, en guettant la dérive de périmètre et la logique plausible mais fausse. Transformez les workflows répétés en slash commands personnalisées partagées par votre équipe.