Claude Code en pratique : workflows quotidiens d’un développeur en 2026

📍 Article principal du cluster : Claude AI : le guide pratique 2026
Cet article fait partie du cluster « Claude AI 2026 ». Pour la vue d’ensemble — modèles, plans, surfaces — lire d’abord le pilier. Pour l’installation détaillée, voir notre tutoriel Claude Code tutoriel pratique : installation, workflows, sub-agents.

Vous avez installé Claude Code, vous avez tapé claude dans votre terminal, vous lui avez fait corriger un petit bug. Bon. Mais quand vous regardez les vidéos de démos d’Anthropic, vous voyez des développeurs livrer une feature complète en trente minutes, lancer des audits sur tout un dépôt, faire tourner un agent de nuit qui prépare le travail du lendemain. Et chez vous, chaque session reste poussive et vous tapez « approve » trois cents fois par heure. Ce tutoriel comble cet écart.

Le but ici n’est pas l’installation — qui est documentée par ailleurs — mais l’ingénierie de votre flux. Comment configurer les permissions une fois pour ne plus jamais valider des opérations triviales. Comment écrire un fichier CLAUDE.md qui fait gagner deux heures par jour. Comment chaîner des sub-agents, configurer des hooks, brancher des MCP utiles. À la fin, vous aurez un environnement Claude Code prêt pour la production, et un agent qui se comporte comme un coéquipier discipliné.

Prérequis

• Claude Code installé (claude --version doit répondre).
• Un compte Pro, Max ou Team. Le quota Free est insuffisant pour un usage quotidien.
• Un terminal moderne — Windows Terminal, iTerm2, ou Bash sous WSL.
• Git configuré, un dépôt sur lequel travailler.
• Niveau : développeur intermédiaire. Connaissance de la ligne de commande et de Git nécessaire.
• Temps estimé : 90 minutes en lecture-pratique.

Étape 1 — Vérifier l’installation et la version

Avant tout, on s’assure que la base est en ordre. Beaucoup de comportements bizarres viennent d’une installation pas à jour. La commande claude --version affiche la version installée. La commande claude doctor diagnostique l’environnement et signale les soucis classiques — auth expirée, version périmée, dépendance manquante. Lancez les deux dès l’ouverture du terminal.

claude --version
claude doctor

La sortie attendue est une version numérique récente, et un rapport vert de doctor. Si doctor signale un problème — auth, mise à jour, plugin — corrigez avant d’aller plus loin. Tenter de débugger une session productive avec un Claude Code mal installé est une perte de temps. Sur Windows, si vous travaillez dans Git Bash, vérifiez que which claude pointe bien sur le binaire installé en global.

Étape 2 — Créer le fichier CLAUDE.md de votre projet

Le fichier CLAUDE.md à la racine d’un dépôt est ce que Claude Code lit en priorité au démarrage de chaque session. C’est l’équivalent du Custom Instructions des Projets dans le chat — mais ici versionné dans Git, partagé avec l’équipe, et structurant. Sans CLAUDE.md, Claude découvre votre projet à chaque session ; avec, il sait dès la première seconde quel langage, quel framework, quelles conventions, quelles commandes lancer.

À la racine de votre dépôt, créez le fichier :

touch CLAUDE.md
$EDITOR CLAUDE.md

Remplissez avec les sections que voici. Adaptez à votre stack — l’idée est de donner à Claude une carte mentale du projet plus rapide à lire qu’un README long.

# Conventions de ce dépôt

## Stack
- Backend : Node.js 20, TypeScript, Express
- Base de données : PostgreSQL 16, accédée via Prisma
- Tests : Vitest pour l'unitaire, Playwright pour l'E2E

## Commandes principales
- `npm run dev` : démarre le serveur dev (port 3000)
- `npm test` : lance les tests Vitest
- `npm run e2e` : lance les tests Playwright
- `npm run lint` : ESLint + Prettier

## Conventions
- Toujours typer strictement (pas de `any`)
- Tests à côté du fichier, suffixe `.test.ts`
- Commits Conventional Commits (`feat:`, `fix:`, `refactor:`)
- Pas de console.log dans les commits

## Structure
- `src/api/` : routes Express
- `src/domain/` : logique métier pure
- `src/infra/` : accès DB, services externes

Une fois ce fichier créé, lancez claude dans le dépôt et demandez « affiche-moi un résumé de ce que tu sais de ce projet ». Vous devriez voir Claude vous restituer la stack, les commandes et les conventions. Si oui, le fichier est bien lu et vous gagnez désormais ces deux minutes d’explication à chaque session future.

Étape 3 — Configurer les permissions une bonne fois

Le mode par défaut de Claude Code demande validation pour la moindre opération qui touche le filesystem ou exécute du shell. C’est pédagogiquement utile au début, opérationnellement pénible après dix sessions. La solution est de configurer les permissions dans .claude/settings.json à la racine du dépôt — ou dans le settings global au niveau utilisateur — pour autoriser d’emblée les opérations bénignes.

mkdir -p .claude
$EDITOR .claude/settings.json

Voici un settings minimal que vous pouvez adapter. Il autorise les commandes de lecture courantes, les commandes de test, et bloque les commandes destructrices ou réseau qui méritent encore une validation manuelle.

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(npm run typecheck:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Read",
      "Grep",
      "Glob"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}

Au prochain lancement, Claude n’attendra plus votre validation pour faire npm test ou git diff. En revanche, il continuera à demander pour les opérations dangereuses, et il refusera systématiquement les commandes en deny. Vous gagnez environ trente minutes par jour, et vous gardez la sécurité sur ce qui compte.

Étape 4 — Premier flux : déboguer un bug avec /clear

Le flux quotidien le plus courant est le débogage. Voici un déroulé en cinq commandes qui devrait vous devenir réflexe.

claude
# Dans la session :
> /clear
> Le test "calcul TVA panier" échoue depuis le commit 7a3f9. Trouve la cause et corrige sans casser les autres tests.

La commande /clear nettoie le contexte de la session précédente — réflexe à acquérir en début de chaque tâche distincte, parce que conserver du contexte entre tâches non liées dégrade la qualité des réponses. Le prompt précis qui suit donne à Claude un point de départ vérifiable : un test nommé, un commit suspect, et une contrainte (ne pas casser les autres tests). Claude va lire le test, identifier le commit fautif via git log, comparer les deux versions, proposer un correctif, exécuter npm test, et vous présenter le diff.

L’output attendu : un patch concis, le résultat des tests, et un résumé du diagnostic. Si Claude propose plusieurs causes plausibles, choisissez et demandez d’appliquer celle qui correspond à votre lecture. Ne validez pas un correctif que vous ne comprenez pas — Claude se trompe, et vous êtes responsable du code committé.

Étape 5 — Deuxième flux : ajouter une feature avec un plan

Pour les tâches plus larges — ajouter une feature, refactorer un module — l’erreur est de lancer Claude tête baissée. La discipline qui change tout est de demander un plan avant l’exécution. Tapez :

> Je veux ajouter une route POST /api/clients qui crée un client en base.
  Plan d'abord — ne touche encore à aucun fichier. Liste les étapes,
  les fichiers concernés, les tests à ajouter.

Claude répondra avec un plan numéroté : créer la route dans src/api/clients.ts, ajouter le repository dans src/infra/clientsRepo.ts, écrire les tests dans src/api/clients.test.ts, etc. Vous lisez ce plan, vous le critiquez, vous corrigez si quelque chose vous gêne. Une fois le plan validé, vous donnez le feu vert : « OK, exécute ». Claude écrit les fichiers, lance les tests, et boucle sur les erreurs.

Cette discipline du plan-puis-action est ce qui sépare un usage débutant d’un usage productif. Le plan vous fait gagner du temps en aval — vous évitez les refactors sauvages — et vous garde maître de l’architecture. C’est aussi ce qui protège un junior qui n’a pas encore le réflexe de critiquer une proposition d’agent.

Étape 6 — Troisième flux : refacto large avec sub-agents

Pour les refactos transverses — renommer un concept dans tout le code, migrer une lib, harmoniser un style — les sub-agents sont l’outil. Au lieu d’une session unique qui charge tout en mémoire, vous déclarez des agents spécialisés que Claude Code orchestre.

Créez un fichier .claude/agents/refactor.md :

---
name: refactor
description: Spécialiste des refactos sûrs. Lit, propose un plan, applique par étapes, lance les tests entre chaque étape.
tools: Read, Edit, Bash, Grep
---

Tu es un agent dédié aux refactos. Procède toujours en trois temps :
1. Lecture exhaustive de l'aire impactée
2. Plan détaillé soumis pour validation
3. Application étape par étape avec tests entre chaque étape
Ne fais jamais de modification sans avoir lu le contexte complet.

Une fois ce sub-agent en place, vous l’invoquez avec « lance le sub-agent refactor sur le module clients ». Le sub-agent ouvre un contexte propre — il ne pollue pas votre session principale — exécute son mandat, et rend un rapport. Vous gardez la conversation principale fraîche pour piloter l’ensemble. Cette architecture en sub-agents est ce qui permet de tenir des sessions de plusieurs heures sans saturer le contexte.

Étape 7 — Brancher un MCP utile : GitHub, Postgres, ou Linear

Les serveurs MCP étendent ce que Claude Code peut faire. Brancher le MCP GitHub vous permet de demander « lis l’issue #142 et propose un fix », sans copier-coller. Brancher le MCP Postgres vous laisse explorer votre base via Claude. Brancher Linear ou Jira aligne vos tickets avec votre code.

Pour brancher le MCP GitHub officiel, lancez :

claude mcp add github

Suivez l’authentification OAuth qui s’ouvre dans votre navigateur. Une fois validé, vérifiez :

claude mcp list

Le serveur GitHub doit apparaître avec le statut « connected ». Lancez ensuite une session Claude et tapez « liste les trois dernières issues ouvertes du dépôt courant ». Si Claude répond avec les issues réelles de votre dépôt, le MCP fonctionne. Pour le détail des MCP côté utilisateur, voir le tutoriel MCP avec Claude. Pour la fabrication de serveurs MCP côté développeur, voir MCP servers : tutoriel développeur 2026.

Étape 8 — Hooks : automatiser les tests et le lint

Les hooks sont des scripts shell que Claude Code exécute automatiquement à des moments précis du cycle — avant ou après une modification de fichier, à la fin d’une session, etc. Le cas d’usage le plus rentable est de faire passer le linter et les tests automatiquement après chaque édition.

Dans .claude/settings.json, ajoutez la section hooks :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint -- --fix && npm run typecheck"
          }
        ]
      }
    ]
  }
}

Avec ce hook, après chaque édition de fichier, Claude Code lance le linter et le typecheck. Si une erreur apparaît, elle est remontée dans la conversation et Claude la corrige souvent dans la foulée. Vous évitez le scénario classique où l’agent commit un code propre en apparence mais qui casse en CI.

Étape 9 — Mettre Claude Code en routine pour le travail de nuit

Anthropic a ouvert les Routines : configurer une tâche pour qu’elle s’exécute selon un planning, via un appel API, ou en réponse à un événement. Le cas d’usage qui change la vie : faire tourner un agent la nuit qui parcourt vos issues, propose des plans, prépare des draft de PR. Le matin, vous arrivez et vous avez du travail pré-mâché.

La création d’une routine se fait depuis l’application bureau Claude Code, dans la section dédiée. Vous donnez un nom, un prompt, un calendrier (par exemple « tous les jours à 6h00 GMT »), et un dépôt cible. Au déclenchement, Claude exécute la mission de manière autonome, dans une instance dédiée, et publie son résultat dans un Artifact ou un commit sur une branche dédiée. Vous récupérez ensuite le tout depuis votre poste.

Premier conseil : commencez par une routine en lecture seule. « Tous les matins, scanne les issues ouvertes de ce dépôt et propose un classement par priorité dans un commentaire. » C’est sans risque et vous mesurez la qualité avant de donner des permissions d’écriture. Deuxième conseil : auditez les premières exécutions à la main. Une routine mal cadrée tourne sur deux semaines avant qu’on s’aperçoive qu’elle déraille.

Étape 10 — Vérifier l’ensemble avec un cycle complet

Pour valider votre installation, déroulez le cycle complet sur une vraie tâche de votre semaine. Voici ce qui doit fonctionner sans accroc :

cd ~/dev/votre-projet
claude
> /clear
> [tâche réelle de votre semaine]

Au lancement, Claude doit avoir lu le CLAUDE.md (preuve : il connaît votre stack sans demander). Il doit pouvoir lancer npm test sans demander la permission (preuve : settings bien configurés). Il doit savoir reformuler la tâche en plan avant d’écrire (preuve : discipline acquise). Après chaque édition, le hook lint doit se déclencher (preuve : sortie du hook visible). Si vous mentionnez un MCP — « ouvre l’issue #X » — il doit répondre avec les vraies données.

Si tous ces points sont OK, votre Claude Code est prêt. Vous tenez désormais un poste de travail agentique stable, sur lequel vous pouvez compter pour les heures de production que vous lui confierez. La discipline dans ce flux fait toute la différence entre un Claude Code « gadget » et un Claude Code « collègue ».

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour un développeur sénégalais ou ivoirien qui code à distance, deux ajustements pratiques. Premièrement, configurez votre éditeur de fuseau horaire dans CLAUDE.md — « heure de Dakar / GMT » — pour que les routines et les logs s’alignent sur votre quotidien plutôt que sur le serveur Anthropic. Deuxièmement, sur une connexion 4G, le streaming token par token est très tolérant aux micro-coupures ; mais si vous travaillez en partage de connexion mobile, désactivez la prévisualisation des Artifacts intermédiaires dans les paramètres pour économiser la bande passante.

Côté économie, sur un compte Pro à 17 dollars annuel, vous pouvez tenir une session intensive de quatre à cinq heures par jour avant de toucher la limite. Au-delà, basculez sur Max 5x à 100 dollars — qui s’amortit immédiatement quand vous l’utilisez en production. Pour une équipe de quatre développeurs ou plus, Team Premium à 100 dollars par siège annuel revient moins cher que quatre Max 5x individuels et apporte la facturation centralisée.

Pour les clients de votre agence : Claude Code livre du code propre, mais il ne signe pas les commits avec votre nom — c’est vous le commiteur. Documentez dans vos contrats que l’IA est un outil de production, et conservez la responsabilité humaine. C’est la posture qui protège juridiquement et qui aligne avec les bonnes pratiques émergentes.

Tutoriels frères

• Claude Code tutoriel pratique : installation, workflows, sub-agents — angle plus orienté débutants et installation détaillée.
• Cursor vs Copilot vs Claude Code : comparatif honnête 2026 — pour choisir entre les outils.
• Continue.dev avec Claude Code : assistant IA dans VSCode — pour ceux qui veulent rester dans VS Code.

Pour aller plus loin

• 🔝 Retour au pilier : Claude AI : le guide pratique 2026
• Documentation officielle Claude Code : docs.claude.com/en/docs/claude-code/overview
• Page produit : claude.com/product/claude-code
• Suggestion : enchaînez avec le tutoriel MCP avec Claude pour étendre Claude Code à vos outils métier.

FAQ

Claude Code peut-il commit pour moi ?
Oui, si vous l’autorisez explicitement dans les permissions. La pratique recommandée reste de relire le diff avant le commit. Pour les routines de nuit, configurez Claude Code pour pousser sur une branche dédiée que vous mergez à la main le matin.

Est-ce que je peux utiliser Claude Code sur un projet privé d’entreprise ?
Oui sur tous les plans payants. Pour les exigences de conformité, passez sur Team ou Enterprise et activez la non-conservation pour entraînement dans les paramètres organisationnels.

Comment partager mon CLAUDE.md avec mon équipe ?
Il suffit de le committer dans Git. Tous les membres de l’équipe qui clonent le dépôt bénéficient automatiquement de la configuration. C’est la même logique qu’un .editorconfig ou un tsconfig.json.

Que faire quand Claude Code modifie un fichier sans demander ?
Vérifiez votre .claude/settings.json. Vous avez probablement Edit en allow. Soit c’est intentionnel (vous lui faites confiance sur les éditions), soit vous repassez en validation manuelle pour cette opération.

Combien de tokens consomme une session typique ?
Variable. Une session de débogage simple : 30 à 50 000 tokens. Un refacto large : 200 000 à 500 000 tokens. Une routine de nuit : potentiellement plusieurs millions. Surveillez la consommation via claude usage ou la console de votre compte.

Mots-clés secondaires : Claude Code workflows, sub-agents, hooks, MCP, CLAUDE.md, refactor, routines, agent IA développeur.