Claude Code : l’IA qui code, débugue et livre depuis votre terminal

Demandez à Claude Code de refactorer un module JavaScript en TypeScript, d’écrire les tests unitaires, de les exécuter et de corriger les échecs — dans une seule instruction. Il navigue dans votre arborescence de fichiers, lit le code existant pour comprendre les conventions, produit des modifications cohérentes avec le style du projet, puis vérifie son propre travail. Ce n’est pas un gadget de démonstration : des équipes de développement l’utilisent comme collaborateur de production.

Cet article est le septième de la série « De zéro à machine de guerre avec Claude ». Après les fichiers bureautiques (article 6), on passe au terrain où Claude a construit une vraie avance : le code. Et si vous n’êtes pas développeur, restez : la section sur le « vibe coding » vous concerne directement.

Terminal, desktop, web, IDE : un même outil, plusieurs surfaces

Claude Code existe aujourd’hui sous plusieurs formes. Le CLI reste la base : vous tapez claude dans votre terminal, puis vous interagissez avec l’agent en ligne de commande. L’application desktop, repensée le 14 avril 2026, sert de dashboard pour piloter plusieurs sessions en parallèle. Claude Code existe aussi sur le web, dans les IDE comme VS Code et JetBrains, et dans certains environnements collaboratifs comme Slack.

La bonne surface dépend du travail. Le terminal reste idéal pour les tâches rapides, les scripts et les workflows techniques. Le desktop devient ensuite plus confortable pour les sessions longues et multi-projets. L’IDE est également utile quand vous voulez suivre les diffs dans votre éditeur. Le web et Slack servent surtout à lancer, suivre ou reprendre des tâches sans être devant votre terminal.

Installation en 5 minutes

Le desktop redesign du 14 avril 2026

Ce n’est plus une fenêtre de chat avec un terminal en arrière-plan : c’est un vrai dashboard d’agents. Le changement central est la barre latérale multi-sessions. Vous lancez un refactoring sur un dépôt, un fix de bug sur un autre, puis une passe de tests sur un troisième — ensuite vous passez de l’un à l’autre comme des onglets de navigateur.

Anthropic a intégré les outils qu’on allait chercher ailleurs : un terminal intégré, un éditeur de fichier in-app, un diff viewer reconstruit pour les gros changesets, et un layout réorganisable par glisser-déposer. Le but est clair : permettre à un humain de superviser plusieurs agents de code au lieu de rester bloqué dans une seule session linéaire.

Le redesign est disponible pour les utilisateurs Claude Code sur les plans Pro, Max, Team et Enterprise, ainsi que via l’API. Le CLI reste intact et continue de fonctionner — beaucoup de développeurs utilisent les deux : CLI pour les tâches rapides, desktop pour les sessions longues ou multi-projets.

CLAUDE.md : la fondation de tout le reste

Le fichier CLAUDE.md est l’équivalent des instructions de Project pour Claude Code. Il est lu au début de chaque session et donne à Claude le contexte permanent du projet. La différence avec les Projects de claude.ai : CLAUDE.md vit dans votre repository Git, versionné avec votre code. Quand vous changez de branche, les instructions peuvent changer aussi.

Un bon CLAUDE.md contient les règles qui s’appliquent à chaque tâche — pas les workflows ponctuels (ceux-là iront dans les skills). Voici la structure qui marche en pratique :

# CLAUDE.md — structure efficace
# Projet : Dashboard Analytics

## Stack et versions
- Backend : FastAPI 0.115 + Python 3.12
- Frontend : React 18 + TypeScript strict (noImplicitAny)
- Base de données : PostgreSQL 16
- Gestionnaire : pnpm (PAS npm, PAS yarn)

## Règles non-négociables
- Type hints obligatoires sur toutes les fonctions Python
- Composants React fonctionnels uniquement, pas de classes
- Imports absolus, jamais de ../../..
- Commits : feat:, fix:, chore:, docs: en préfixe
- Ne JAMAIS modifier les fichiers dans src/legacy/
- Ne JAMAIS commit sans avoir lancé `pnpm test`

## Commandes du projet
- Dev : `pnpm dev`
- Tests : `pnpm test` (backend) et `pnpm test:ui` (frontend)
- Build : `pnpm build`
- Lint : `pnpm lint --fix`

## Pièges connus
- La table `users` a une colonne `status` qui accepte
  null — toujours filtrer `WHERE status IS NOT NULL`
- Les tests d'intégration nécessitent Redis local port 6379
- L'API auth renvoie 401 au lieu de 403 sur les permissions
  manquantes (legacy, à ne pas corriger)

## Architecture en bref
- `/src/api` : endpoints FastAPI (1 fichier par resource)
- `/src/core` : logique métier pure, pas de dépendances web
- `/src/db` : modèles SQLAlchemy et migrations Alembic
- `/web` : frontend React (Vite + Tailwind)

Trois règles pour garder un CLAUDE.md efficace. Court et lisible : visez un fichier humainement parcourable. Si le fichier grossit trop, Claude risque alors de rater les règles importantes. Actionnable : chaque ligne doit permettre à Claude de prendre une décision. « Notre code est propre » n’est pas actionnable. « Pas de fonctions de plus de 40 lignes » l’est. Maintenu : quand Claude se trompe systématiquement sur un point, ajoutez la règle. Quand une règle n’est plus vraie, retirez-la.

Règles modulaires pour les gros projets

Pour les monorepos, Claude Code supporte les fichiers CLAUDE.md à plusieurs niveaux et les règles dans .claude/rules/. Vous pouvez ainsi garder le CLAUDE.md principal court et placer les règles spécifiques dans des fichiers séparés :

# Arborescence pour monorepo
.claude/
├── rules/
│   ├── python-backend.md       (règles backend)
│   ├── react-frontend.md       (règles frontend)
│   ├── sql-migrations.md       (règles DB)
│   └── security.md             (règles sécurité transverses)
CLAUDE.md                       (vision générale + pointeurs)

Cette granularité évite les conflits de merge sur le CLAUDE.md principal et permet à chaque équipe de maintenir ses propres règles sans toucher à celles des autres. Vous pouvez aussi importer du contexte avec la syntaxe @path/to/file, pratique pour pointer vers un README, une documentation interne ou un fichier de conventions.

Prompter Claude Code : ce qui marche vraiment

Le plus gros levier de performance avec Claude Code, ce n’est pas seulement la puissance du modèle. C’est votre façon de lui confier le travail. Un prompt bâclé donne un résultat bâclé, même avec un très bon modèle. Voici les cinq réflexes qui transforment les résultats.

1. Commencer par un plan, pas par du code

Pour toute tâche non-triviale, demandez d’abord un plan. Pas une exécution. « Avant d’écrire quoi que ce soit, lis les fichiers concernés et fais-moi un plan de ce que tu vas modifier. Je valide avant que tu touches au code. » Claude produit un plan, vous le corrigez ou validez, puis il exécute. Cette étape prend deux minutes et évite trente minutes de rollback sur une mauvaise direction.

Le mode plan est intégré : utilisez /plan ou basculez avec Shift+Tab. Dans ce mode, Claude utilise des outils en lecture seule, analyse, puis propose. Vous passez ensuite en mode exécution quand le plan est bon.

2. Donner le scope et les contraintes explicites

Claude Code prend les instructions au premier degré. Si vous dites « ajoute un endpoint », il peut en profiter pour refactorer trois autres fichiers qu’il juge sales. Soyez explicite sur ce qu’il doit modifier et sur ce qu’il ne doit pas toucher.

# Prompt bâclé (résultat imprévisible)
Ajoute un endpoint pour récupérer les utilisateurs.

# Prompt efficace (résultat contrôlé)
Ajoute un endpoint GET /api/users qui retourne la liste
des utilisateurs actifs (status='active').

Contraintes :
- Ne modifie QUE src/api/users.py
- Suis le pattern des endpoints existants dans ce fichier
- Ajoute les tests correspondants dans tests/api/test_users.py
- Ne touche pas aux autres endpoints ni aux modèles
- Lance `pnpm test tests/api/test_users.py` pour valider

3. Demander des critères d’acceptation

À la place de « corrige ce bug », formulez « corrige ce bug. Le test qui doit passer : quand un utilisateur sans email se connecte, l’app affiche la page de saisie d’email au lieu de crasher. Écris ce test d’abord, puis corrige. » Vous transformez une instruction floue en spécification vérifiable. Claude écrit le test, le voit échouer, corrige, le voit passer — et vous avez un test de régression en prime.

4. Laisser Claude poser des questions

Pour une tâche ambiguë, ajoutez : « Avant de commencer, pose-moi les questions dont tu as besoin pour éviter les hypothèses. » Claude peut alors vous demander des précisions avant de modifier quoi que ce soit. Deux minutes de questions valent mieux qu’une heure de réimplémentation.

5. Challenger le résultat

Après une modification non-triviale : « Prouve-moi que ça marche. Montre-moi le diff entre main et ta branche, lance les tests, puis explique pourquoi tu es confiant que rien n’est cassé. » Ou encore : « Grille-moi sur ces changements comme si tu étais un staff engineer en code review. Ne merge pas tant que tu n’as pas trouvé au moins trois faiblesses. » Claude est capable d’auto-critique sévère si on le lui demande.

Cinq workflows concrets, étape par étape

Workflow 1 : débugger un crash en production

Vous avez un stack trace. Vous ne savez pas d’où ça vient. Prompt à coller dans Claude Code :

# Prompt debug
J'ai ce crash en prod. Avant de corriger :

1. Lis le stack trace ci-dessous et identifie le fichier
   et la ligne où ça casse
2. Lis ce fichier pour comprendre la fonction concernée
3. Cherche dans le code où cette fonction est appelée
4. Formule 3 hypothèses sur la cause racine
5. Pour chaque hypothèse, dis-moi comment la vérifier
6. ATTENDS ma validation avant de modifier quoi que ce soit

Stack trace :
[coller ici]

Claude lit, analyse, et vous propose plusieurs pistes. Vous choisissez la plus plausible, il vérifie sur le code, confirme, et propose le fix. Cette structure évite le « je corrige au petit bonheur » qui masque le vrai bug et en crée d’autres.

Workflow 2 : migrer un module JavaScript vers TypeScript

Pour une migration, la clé est de procéder par vagues et de garder les tests verts à chaque étape.

# Prompt migration JS -> TS
On migre src/utils/ de JavaScript vers TypeScript.

Procède par vagues d'UN fichier à la fois :
1. Convertis le fichier .js en .ts avec types stricts
2. Remplace les `any` par les vrais types dès que possible
3. Mets à jour les imports dans les fichiers qui l'utilisent
4. Lance `pnpm test` et `pnpm tsc --noEmit`
5. Si tout est vert, commit avec message `chore: migrate
    to TypeScript`
6. Passe au fichier suivant

Commence par les fichiers sans dépendances internes.
Arrête-toi si un test casse et demande-moi quoi faire.

Claude ordonne les fichiers par dépendances, traite le premier, teste, commit, et passe au suivant. Vous obtenez ainsi une série de commits atomiques et réversibles, pas une grosse PR monolithique.

Workflow 3 : refactorer un gros module

Pour un refactoring de 500+ lignes, la tentation est de tout réécrire d’un coup. Mauvaise idée. Le bon pattern : caractériser avant de toucher.

# Prompt refactoring sûr
On va refactorer src/core/billing.py.

Phase 1 — Caractérisation (PAS de modif) :
- Lis le fichier entier
- Identifie les fonctions publiques et leurs signatures
- Pour chaque fonction publique, écris un test qui
  capture son comportement actuel dans tests/core/
  test_billing_characterization.py
- Lance les tests, tous doivent passer sur le code actuel

ATTENDS ma validation avant la phase 2.

Phase 2 — Refactoring :
- Propose un plan avant de toucher au code
- Applique le plan fonction par fonction
- Les tests de caractérisation DOIVENT rester verts
  à chaque étape

Les tests de caractérisation sont votre filet. Si Claude casse un comportement pendant le refactoring, le test vire au rouge et vous l’arrêtez.

Workflow 4 : ajouter une feature de A à Z

Une vraie feature implique modèles, API, frontend, tests. Le prompt qui marche découpe en phases avec validation entre chaque :

# Prompt feature complète
Feature : export CSV de la liste des commandes.

Plan d'exécution en 4 phases, validation à chaque étape :

Phase 1 — Modèle + endpoint backend
- Fonction `export_orders_csv(filters)` dans core/orders.py
- Endpoint GET /api/orders/export dans api/orders.py
- Tests unitaires du core, tests d'intégration de l'API
- STOP, je valide

Phase 2 — Frontend
- Bouton "Exporter CSV" dans la page OrdersList
- Appel API, gestion loading + erreur
- Téléchargement du fichier côté navigateur
- STOP, je valide

Phase 3 — Tests end-to-end
- Scénario Playwright : clic bouton -> fichier téléchargé
- STOP, je valide

Phase 4 — Doc
- Ajoute la feature dans docs/features.md
- Message de commit propre par phase

Commence par la phase 1.

Workflow 5 : onboarding sur un codebase inconnu

Nouveau poste, nouveau projet, 50 000 lignes de code que vous ne connaissez pas. Claude Code est imbattable sur ce cas d’usage.

# Prompt onboarding
Je suis nouveau sur ce codebase. Fais-moi :

1. Un diagramme d'architecture en ASCII ou mermaid,
   niveau "macro" (3-5 blocs principaux et leurs relations)
2. La liste des 10 fichiers les plus critiques à comprendre
   en premier, avec 2 lignes d'explication chacun
3. Les patterns récurrents du projet (naming, organisation,
   conventions implicites qui ne sont pas dans le README)
4. Les 5 "zones suspectes" que tu sens fragiles, datées,
   ou qui mériteraient un refactoring
5. Un quiz de 10 questions que je devrais savoir répondre
   après avoir bien assimilé le projet

Ne modifie rien. Produis le tout dans un fichier
docs/ONBOARDING.md.

Vous passez d’une journée perdue à lire du code sans fil directeur à une carte utilisable en vingt minutes.

Skills, hooks, plugins : la couche automation

Une fois les bases acquises, vous allez vous rendre compte que vous tapez les mêmes instructions en boucle. C’est le signal : il est temps de passer aux skills.

Les skills : vos workflows réutilisables

Un skill est un fichier markdown SKILL.md qui encode un workflow, une checklist ou une connaissance spécialisée. Claude peut le charger automatiquement quand la demande matche sa description, ou vous pouvez l’appeler directement avec /nom-du-skill. Contrairement au CLAUDE.md, le corps du skill ne charge pas à chaque session : il reste disponible à la demande, sans alourdir tout le contexte.

# Exemple : .claude/skills/pr-review/SKILL.md
---
name: pr-review
description: >
  Lance une revue de PR complète : lit le diff,
  vérifie les conventions du projet, cherche les
  bugs potentiels et les régressions, produit un
  commentaire structuré. Utilise quand l'utilisateur
  demande "review cette PR" ou fournit un numéro de PR.
---

# Revue de PR

Pour chaque PR à reviewer :

1. Lis le diff complet avec `gh pr diff `
2. Vérifie les points suivants dans l'ordre :
   - Conventions de code (cf CLAUDE.md)
   - Tests ajoutés pour les nouveaux comportements
   - Pas de régression potentielle sur les zones touchées
   - Pas de secret hardcodé (cherche 'key', 'token', 'password')
   - Messages de commit conformes (feat:/fix:/chore:)

3. Produis un commentaire structuré :
   ## Ce qui est bien
   ## À corriger avant merge
   ## Suggestions (non bloquantes)

4. Poste via `gh pr review  --comment -F -`

À l’usage, vous tapez « review la PR #142 », Claude active le skill pr-review, et déroule le workflow. Chaque équipe construit sa propre bibliothèque : release notes, scaffolding de tests, post-mortem, génération de migrations SQL. Les skills sont versionnés avec le code, partagés via le repo, améliorés au fil du temps. Les anciennes custom commands ont d’ailleurs été rapprochées du mécanisme de skills : un workflow réutilisable a désormais vocation à vivre là.

La règle : écrivez trois skills avant de toucher aux plugins. Prenez trois workflows que votre équipe répète chaque semaine, capturez-les en markdown. Vous apprendrez plus sur Claude Code en faisant ça qu’en lisant toute la documentation.

Les hooks : l’automation déterministe

Les hooks sont des commandes shell qui se déclenchent à des moments précis du cycle de vie de Claude : avant un outil, après un outil, au démarrage d’une session, quand Claude s’arrête, quand vous postez un message, quand un fichier d’instructions est chargé, ou quand un subagent démarre. Leur intérêt : ils sont déterministes. Ils tournent parce que l’événement arrive, pas parce que Claude y pense.

Cas d’usage concrets : formater automatiquement les fichiers après édition, bloquer l’écriture de fichiers sensibles, envoyer une notification desktop quand Claude a besoin de votre validation, logger chaque changement pour audit, ou bloquer une commande destructrice avant exécution.

# Exemple simplifié : hook de sécurité
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(rm *)",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh"
          }
        ]
      }
    ]
  }
}

Quand une règle doit absolument être appliquée (linting, checks de sécurité, audit), c’est un hook qu’il faut, pas seulement une instruction dans CLAUDE.md.

Les plugins : packager et distribuer

Un plugin est un bundle qui peut contenir des skills, des hooks, des subagents, des slash commands et éventuellement des serveurs MCP. C’est la façon de distribuer des capacités complètes à votre équipe ou à la communauté. Depuis mai 2026, Claude Code peut aussi charger des plugins depuis des archives .zip ou des URLs, ce qui facilite le test de plugins internes sans les publier dans un marketplace.

Conseil de sagesse : installez le moins de plugins possible. Chaque plugin ajoute du contexte, des commandes et des comportements potentiels. Les meilleurs utilisateurs de Claude Code tournent souvent avec peu de plugins, un CLAUDE.md précis et des skills locaux bien choisis.

Auto memory et checkpoints : coder sans perdre le fil

En plus du CLAUDE.md que vous écrivez, Claude Code maintient sa propre auto memory. Pendant qu’il travaille, il peut noter ce qu’il apprend : commandes de build qui ont marché, patterns de debug découverts, décisions d’architecture, préférences de workflow. Cette mémoire est locale à la machine et stockée dans ~/.claude/projects/<projet>/memory/.

Vous pouvez aussi dicter explicitement : « Retiens qu’on utilise pnpm, pas npm ». Tapez /memory en session pour voir les fichiers chargés, gérer la mémoire et ouvrir le dossier d’auto memory. Tout est en markdown : vous pouvez lire, modifier ou supprimer ce que Claude a retenu.

Les checkpoints sont l’autre filet de sécurité. Quand Claude Code modifie votre code, il suit les changements de fichiers et crée des points de retour. Double Esc dans le CLI, ou commande /rewind : vous revenez en arrière. Trois options : revenir au code uniquement (en gardant la conversation), à la conversation uniquement (en gardant le code), ou aux deux. C’est ce qui permet de lancer Claude sur des tâches ambitieuses sans peur — mais cela ne remplace pas Git, et cela ne couvre pas les effets externes comme une base de données ou une API appelée pendant un script.

Les routines : Claude Code qui tourne pendant que vous dormez

Depuis avril 2026, Claude Code peut exécuter des tâches sur l’infrastructure cloud d’Anthropic, même quand votre machine est fermée. C’est le concept des routines : une configuration sauvegardée — prompt, dépôt, connecteurs — qui s’exécute automatiquement selon un déclencheur.

Trois types de déclencheurs

• Planification — la routine s’exécute selon un calendrier : horaire, nuit, semaine, ou exécution ponctuelle à une date précise.
• API — chaque routine reçoit son propre endpoint HTTP et un token d’authentification. Un appel POST depuis un outil interne, un pipeline ou un monitoring déclenche une session.
• GitHub — la routine réagit à des événements sur un dépôt connecté, par exemple une pull request ou une release.

Une même routine peut combiner plusieurs déclencheurs. Elle tourne en autonomie : pas de validation manuelle pendant l’exécution. Le prompt doit donc être autonome, explicite et vérifiable, avec une définition claire du succès.

Six cas d’usage qui font gagner des heures

• Gestion du backlog — chaque soir, identifier les nouveaux tickets, attribuer un responsable et poster un résumé dans Slack.
• Mise à jour de documentation — chaque semaine, repérer les pages qui référencent des API modifiées et ouvrir des PR de correction.
• Vérification post-déploiement — le pipeline appelle l’endpoint, Claude teste le build et poste un go/no-go dans le canal de release.
• Triage des alertes — l’outil de monitoring appelle l’endpoint, Claude corrèle la stack trace avec les commits récents et propose un correctif.
• Portage de librairie — chaque PR fusionnée sur un SDK Python déclenche le portage vers le SDK Go et ouvre la PR correspondante.
• Code review sur mesure — à l’ouverture d’une PR, Claude applique la checklist interne et laisse des commentaires avant la relecture humaine.

La création se fait depuis claude.ai/code/routines ou depuis le CLI avec /schedule. Vous configurez le prompt, les dépôts GitHub, l’environnement cloud, les déclencheurs, et les connecteurs utiles. Les routines sont en research preview et disponibles sur les plans Pro, Max, Team et Enterprise lorsque Claude Code on the web est activé. Sur Team et Enterprise, un administrateur peut les désactiver.

Le mode Auto pour les sessions longues

Le mode Auto, arrivé en research preview, permet à Claude Code de réduire les validations manuelles. Au lieu de vous demander une approbation à chaque action, un classificateur examine les actions et bloque ce qui paraît risqué. C’est le compromis entre le mode par défaut, très prudent, et le contournement brutal des permissions.

Il est particulièrement utile pour les sessions longues où l’approbation répétée casse le rythme : un refactoring de nombreux fichiers, une migration de framework, une passe de tests exhaustive. Activation : Shift+Tab pour naviguer entre les modes de permission, ou menu permissions dans les surfaces graphiques. Pour les actions vraiment critiques, combinez Auto mode avec des deny rules, des hooks et des allowlists de commandes.

Le vibe coding : Claude Code pour les non-développeurs

En février 2025, Andrej Karpathy a popularisé le terme « vibe coding » : un style de programmation où l’on décrit ce qu’on veut en langage naturel, on laisse le modèle générer le code, on le teste, on le corrige — parfois sans lire en détail les lignes produites. Depuis, Claude Code est devenu l’un des outils phares de cette pratique, aussi bien chez les développeurs confirmés que chez un public inattendu : des non-programmeurs qui construisent applications, sites web et outils internes en décrivant simplement leur besoin.

Le principe : vous décrivez le résultat souhaité en français, Claude Code écrit le code, l’exécute, corrige les erreurs, puis vous livre un résultat fonctionnel. « Crée-moi une app web avec un formulaire de contact, une page d’accueil et un blog, design moderne. » Claude choisit la stack, génère les fichiers, lance le serveur de dev, et vous montre le résultat.

Les limites sont réelles : sans connaissances techniques, vous ne pouvez pas évaluer la qualité du code produit, ni le maintenir facilement. Mais pour des prototypes, des outils internes, ou des projets personnels, le vibe coding rend la programmation accessible à quiconque sait décrire clairement ce qu’il veut — et c’est exactement la compétence de prompting que vous avez développée dans les articles précédents de cette série.

Ce que cela change pour vous

Le vrai basculement avec Claude Code n’est pas technique, il est mental. Vous arrêtez de penser « je code avec un assistant » et vous commencez à penser « je dirige un collaborateur ». Le plus gros progrès vient quand vous passez trois heures à écrire un CLAUDE.md précis et trois skills adaptés à votre projet — pas quand vous installez un nouveau modèle.

Les développeurs qui tirent le maximum de Claude Code en 2026 ne sont pas ceux qui ont les meilleurs prompts ponctuels. Ce sont ceux qui ont systématiquement encodé leur expertise en règles, skills, hooks et routines réutilisables. Chaque heure investie dans la configuration se rembourse ensuite en semaines d’exécution.

Si vous êtes développeur, l’ordre d’attaque est simple. Pour la première semaine : installez Claude Code, créez un CLAUDE.md de 50 lignes pour votre projet principal, faites-vous la main sur les cinq workflows de cet article. Ensuite, identifiez vos trois tâches les plus répétitives et écrivez-les en skills. Enfin, mettez en place une routine sur le cas d’usage le plus évident : triage de backlog, review auto, documentation ou surveillance de régression.

Si vous n’êtes pas développeur mais que vous avez un projet en tête — un outil interne, un site, un prototype — lancez-vous en vibe coding, mais gardez une règle : ne déployez rien de sensible sans relecture technique. Le pire qui puisse arriver, c’est que ça ne marche pas du premier coup. Enfin, le meilleur : vous avez un prototype fonctionnel en quelques heures.