Claude Code productivité : 10 astuces pratiques pour travailler mieux

La vraie productivité vient d’un workflow répétable

Claude Code impressionne au début. Il peut lire un dépôt, corriger un bug, écrire des tests, préparer une description de PR ou réorganiser une documentation. Puis les problèmes quotidiens arrivent : vous répétez le contexte à chaque session, l’agent modifie trop de fichiers, le build n’est pas lancé, ou une décision prise hier disparaît de la conversation.

Le gain de productivity ne vient donc pas d’un prompt magique. Il vient d’un workflow clair : contexte du projet, objectif, périmètre, contraintes et vérification. Quand Claude Code sait ce qu’il peut toucher et quel résultat prouve que le travail est terminé, la qualité devient beaucoup plus stable.

Les pages officielles Common workflows, Memory et Settings donnent la base. Cette version traduit ces principes en habitudes simples pour un projet réel.

Objectif	Habitude	Effet
Réduire le contexte répété	Maintenir un CLAUDE.md court	Meilleures premières réponses
Limiter les modifications risquées	Définir portée et permissions	Moins de surprises
Finir avec preuve	Donner les commandes de vérification	Moins de “ça devrait marcher”

Tip 1: Commencez par un CLAUDE.md court

CLAUDE.md est la mémoire de projet que Claude Code consulte pour comprendre vos règles. Ce n’est pas un journal complet. C’est le brief que vous aimeriez donner à chaque nouveau membre de l’équipe.

# Project Rules

## Goal
- Grow ClaudeCodeLab as a monetized traffic source.
- Prefer useful evergreen content over thin daily posts.

## Stack
- Astro content collections
- MDX articles under site/src/content/blog*
- Cloudflare Pages deployment

## Quality
- Include real examples, pitfalls, and runnable commands.
- Preserve frontmatter, lang, and heroImage.
- Check code fences and mobile layout before publishing.

## Safety
- Do not revert user changes.
- Do not run destructive git commands.

Avec ce fichier, Claude Code sait déjà quel est le but du site, quelle pile technique utiliser et quelles erreurs éviter. Pour un modèle plus complet, lisez CLAUDE.md best practices.

Le pitfall courant est de tout mettre dans ce fichier. Les notes temporaires, décisions obsolètes et longues explications rendent le signal plus faible. Gardez objectifs, pile, qualité, commandes utiles et interdictions.

Tip 2: Formulez vos demandes avec objectif, cible, limites et fin

“Améliore cet article” est trop vague. Une demande exploitable contient quatre blocs.

Objectif:
  Aider un débutant à appliquer Claude Code dans son travail quotidien.

Cible:
  site/src/content/blog-fr/claude-code-productivity-tips.mdx

Limites:
  Ne pas modifier d'autres fichiers.
  Préserver le frontmatter.
  Ajouter des liens vers la documentation officielle.

Critères de fin:
  Au moins 3 use cases réels.
  Commandes ou configuration copiables.
  Pitfalls, risques et note de vérification.

Ce format fonctionne aussi pour un bug, une API, une interface ou des tests. Le plus important est d’écrire la définition de “terminé”. Si vous attendez un build, un test, une capture mobile ou une vérification de liens, dites-le dès le début.

Tip 3: Découpez les gros sujets en explorer, modifier, vérifier

Une demande trop large mélange trop de décisions. Mieux vaut découper.

Step 1: Explore
Lis les fichiers concernés et propose un plan. Ne modifie rien pour l'instant.

Step 2: Edit
Applique le plus petit changement qui respecte le plan.

Step 3: Verify
Lance lint, tests, build ou les contrôles spécifiques. Corrige si ça échoue.

Ce workflow est très utile dans une base de code inconnue. Claude Code peut d’abord cartographier le dépôt, ensuite modifier une zone limitée, puis prouver le résultat. La documentation officielle décrit aussi l’exploration de code, les bugs, les refactorings, les tests et les PR comme des tâches répétables.

Note de Masa: lorsque nous demandions “améliore tous les articles” en une seule fois, la qualité variait beaucoup. En traitant un groupe de slugs à la fois, puis en lançant les contrôles qualité et mobile, la publication devenait beaucoup plus sûre.

Tip 4: Collez l’erreur réelle, pas seulement votre résumé

Évitez “TypeScript est cassé”. Donnez la commande, l’erreur et les étapes.

npm run build

Type error: Property 'name' does not exist on type 'User | undefined'.
File: src/components/Profile.tsx:15:22

Reproduction:
1. npm install
2. npm run build
3. Le build s'arrête sur l'erreur ci-dessus

Demande:
Explique la cause, corrige avec le plus petit diff possible, puis relance npm run build.

Ce use case marche pour les tests en échec, les déploiements cassés et les erreurs de console. Une capture d’écran peut aider, mais le log textuel reste plus utile.

Le pitfall est de reformuler l’erreur et de supprimer la ligne importante. Collez d’abord le texte original, puis ajoutez votre hypothèse.

Tip 5: Autorisez les commandes sûres, bloquez les commandes dangereuses

Si Claude Code s’arrête à chaque npm test, le rythme se casse. Si tout est autorisé, le risque augmente. Autorisez lecture et vérification, bloquez suppression et retour arrière.

{
  "permissions": {
    "allow": [
      "Read",
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(npx tsc --noEmit)",
      "Bash(git diff --check)"
    ],
    "deny": [
      "Bash(git reset --hard)",
      "Bash(git checkout --)",
      "Bash(rm -rf *)"
    ]
  }
}

Vérifiez toujours la page Settings, car les détails peuvent évoluer. Le principe reste simple : vérifier vite, détruire lentement.

Pour la version orientée sécurité, consultez Claude Code permissions guide.

Tip 6: Transformez les contrôles répétitifs en scripts

Le langage naturel est bon pour cadrer. Les scripts sont bons pour répéter. Si vous faites toujours les mêmes contrôles avant publication, donnez une commande à Claude Code.

#!/usr/bin/env bash
set -euo pipefail

npm run lint
npm run build
node scripts/check-code-fences.mjs
node scripts/check-updated-article-quality.mjs
git diff --check

Sous Windows, PowerShell suffit.

$ErrorActionPreference = "Stop"
npm run build
node scripts/check-code-fences.mjs
node scripts/check-updated-article-quality.mjs
git diff --check

Le vrai bénéfice est une définition commune de “done”. Si la commande échoue, le travail n’est pas terminé.

Tip 7: Gardez dans memory seulement les faits et critères

La memory est utile quand elle conserve les décisions qui comptent pour les prochaines sessions.

## Project memory

- Monetization matters more than raw page count.
- After AdSense approval, avoid thin mass-produced articles.
- Code blocks must be checked on mobile before deploy.
- Preserve frontmatter, lang, and heroImage for localized articles.
- Report changed files, verification, and remaining risks.

Elle ne remplace pas les tests ou la documentation, mais elle évite de répéter les mêmes priorités. Ce point rejoint Claude Code context management.

Tip 8: Trois use cases à utiliser chaque semaine

Use case 1: Comprendre un nouveau dépôt

Lis ce dépôt et explique:
1. Les principaux dossiers et leur rôle
2. Les commandes pour lancer, tester et construire
3. Les 5 fichiers à lire en premier
4. Les zones risquées à ne pas modifier sans contexte

Ne modifie pas encore les fichiers.

Use case 2: Corriger un bug de la reproduction au test

Bug:
Après connexion, /dashboard affiche une page blanche.

Reproduction:
1. npm run dev
2. Se connecter avec test@example.com
3. Ouvrir /dashboard

Attendu:
Les cartes de revenu sont visibles.

Actuel:
Page blanche et Cannot read properties of undefined dans la console.

Demande:
Liste trois causes probables, applique la correction minimale, ajoute un test de régression et lance les contrôles.

Use case 3: Ajouter une petite fonctionnalité sans déraper

Ajoute un champ "consultation type" au formulaire de contact.

Exigences:
- Options: training, consulting, other
- Validation obligatoire
- Garder l'API d'envoi existante
- Ajouter ou mettre à jour un test

Limites:
- Ne pas redessiner tout le formulaire
- Si une migration de base est nécessaire, expliquer d'abord

Fin:
- npm test passe
- npm run build passe

Claude Code est excellent sur de petites tâches bien bornées. Mélanger redesign, base de données, copywriting et tests dans une seule demande crée plus de risque.

Tip 9: Donnez des exemples de mauvais résultat

“Qualité élevée” reste vague. “Évite ceci” est souvent plus utile.

À éviter:
- Conseils abstraits sans implémentation
- Pseudocode quand un vrai code est possible
- Modification de fichiers non liés
- Dire terminé sans vérification
- Revenir sur les changements de l'utilisateur

À préférer:
- Petits diffs
- Commandes copiables
- Résultats de vérification
- Risques restants

Le pitfall est d’écrire cinquante interdictions. Gardez seulement les erreurs coûteuses.

Tip 10: Terminez par fichiers, vérification et risques

Demandez un rapport final court.

À la fin, indique seulement:
1. Fichiers modifiés
2. Commandes de vérification et résultat
3. Risques ou notes restantes

Résultat observé par Masa: l’amélioration la plus nette vient de CLAUDE.md, des critères de fin, des scripts de vérification et des permissions. Pour l’appliquer en équipe, consultez ClaudeCodeLab training and consulting. En solo, copiez simplement ces modèles dans un vrai projet pendant une semaine.