Comprendre Claude Code et l’utiliser efficacement

On ne pilote bien que ce qu’on comprend. Avant de parler méthode, ouvrons le capot : ce que Claude Code est vraiment, ce qu’il voit, ce qu’il retient, et qui tient le volant. Deux images nous y aideront, et nous suivront jusqu’à la fin de l’article : un nouveau collègue, pour sa façon de travailler, et une voiture, pour la façon dont il est construit et conduit.

Un harnais, pas une autocomplétion

Un nouveau collègue, chaque matin

Conséquence directe de la boucle : Claude Code ne « connaît » pas votre projet. Il le découvre à chaque session, en lisant. Imaginez un nouveau collègue, brillant et très rapide, qui arriverait chaque matin sans aucun souvenir de la veille. Pour bien travailler avec lui, il faut savoir ce qu’il a dans la tête, ce qu’il peut faire de ses mains, ce qu’il pose sur son bureau, et ce qu’il note dans son carnet.

Avant de commencer, il ne sait donc que trois choses : ce que vous lui avez écrit, ce qu’il a noté lui-même, et ce qu’il trouve en cherchant. Tout le reste, il le devine. Voyons chaque trait de plus près.

Les outils intégrés

Un outil, c’est une action que le modèle peut demander. Claude Code en fournit une dizaine, et vous pouvez en ajouter d’autres (on y vient en partie 4). Vous les verrez défiler dans le terminal sous leur nom anglais.

Le contexte, sa mémoire de travail

L’article « Comprendre l’IA et maîtriser son jargon » comparait le contexte à un bureau : tout ce que le modèle doit avoir sous les yeux pour travailler y est posé, et sa taille est limitée. Sur les modèles récents, Claude Code dispose d’un bureau immense, un million de tokens, de quoi poser plusieurs milliers de pages.

Ce qui est déjà posé quand vous tapez votre premier message : les instructions du harnais, vos fichiers CLAUDE.md, l’index de sa mémoire automatique, une ligne de description par skill, la définition des outils (pour les serveurs MCP, seuls les noms sont chargés au départ, le détail vient à la demande). Ensuite, tout s’accumule : vos messages, chaque fichier lu, chaque sortie de commande, chaque réponse.

Proportions illustratives. Pour voir les vôtres, tapez /context.

Quand le bureau approche de la limite, Claude Code le compacte : il remplace l’historique par un résumé, puis recharge vos CLAUDE.md, sa mémoire et le plan en cours. C’est pratique, et c’est une perte.

Surtout, un grand bureau n’est pas un bureau rangé. Anthropic le reconnaît elle-même dans ses publications sur le context engineering : plus le contexte est chargé, moins l’attention du modèle est précise. Les spécialistes parlent de context rot, le contexte qui « pourrit ». Une consigne donnée au début d’une longue session pèse moins lourd que les 300 lignes de logs qui ont suivi. D’où la règle la plus rentable de cet article :

Ce dont il se souvient

Puisque le bureau est vidé chaque soir, tout ce qui doit durer passe par des fichiers. Claude Code en connaît quatre sortes, et les confondre est une source classique de déception.

Un moteur, une voiture, plusieurs carrosseries

Le collègue dit comment Claude Code travaille. Pour comprendre comment il est construit, et qui le conduit, changeons d’image. L’article « Comprendre l’IA et maîtriser son jargon » distinguait le modèle et le produit comme on distingue le moteur et la voiture. Claude Code est une voiture construite autour d’un moteur d’Anthropic. Chaque pièce correspond à un réglage que vous allez croiser.

Les surfaces : terminal, éditeur, web…

Le même harnais existe sous plusieurs formes. Elles partagent vos réglages et vos fichiers de configuration ; ce qui change, c’est l’endroit où tourne la boucle et la façon dont vous la regardez.

$ curl -fsSL https://claude.ai/install.sh | bash   # Windows : irm https://claude.ai/install.ps1 | iex
$ cd ~/mon-projet && claude                       # et claude doctor si quelque chose coince

Il faut un abonnement Claude payant (Pro, Max, Team ou Enterprise) ou un compte API. Les tarifs changent souvent : la page officielle fait foi, et /usage vous dit où vous en êtes.

Qui conduit : les modes de permission

C’est le réglage le plus important, et le moins regardé. Il décide de ce que Claude peut faire sans vous demander, autrement dit de qui tient le volant. Maj+Tab fait défiler les modes en cours de session, et le mode actif s’affiche sous la zone de saisie.

Les permissions ne sont pas la seule barrière. /sandbox active une isolation au niveau du système d’exploitation pour les commandes shell : écriture limitée au dossier du projet, réseau filtré par une liste de domaines. Ce sont les glissières de notre voiture : la permission décide si une commande peut partir, le bac à sable limite ce qu’elle peut abîmer.

Modèles, effort, réflexion

/model choisit le moteur (Option+P sur Mac, Alt+P ailleurs). Les alias opus, sonnet, haiku et fable pointent toujours vers la dernière version de chaque famille, et opusplan utilise Opus pour planifier puis Sonnet pour exécuter.

/effort règle le régime, c’est-à-dire l’intensité de la réflexion, de low à max : plus d’effort, c’est une meilleure réponse sur un problème difficile, et plus de temps et de tokens sur un problème facile. Le mot ultrathink dans un message pousse la réflexion pour ce tour seulement. /fast active un mode rapide sur Opus, plus cher, en préversion.

Dans l’article « L’IA va-t-elle remplacer les développeurs ? », je classais les outils d’IA pour développeurs sur une échelle d’autonomie, de N0 (sans IA) à N5 (de la phrase à l’application). Claude Code y figurait en N4, parmi les agents. C’était vrai, et incomplet : selon la façon dont on s’en sert, il couvre presque toute l’échelle. Voici les sept usages que je rencontre, classés selon qui tient le volant. Aucun n’est le bon dans l’absolu.

Chaque fiche suit le même format : le principe, un exemple de demande, les réglages qui vont avec, et le piège. Lisez en diagonale celles qui ne vous concernent pas encore, et faites le test de l’aiguilleur à la fin.

> Explique-moi comment une commande passe de « panier »
  à « payée ». Trace le chemin dans le code, avec
  fichier:ligne à chaque étape. Ne modifie rien.

> Pourquoi ce test est-il désactivé ? Cherche dans
  l’historique Git qui l’a fait, quand, et pourquoi.

> Dans src/pricing/discount.ts, la remise fidélité
  s’applique avant la TVA. Elle doit s’appliquer après.
  Écris d’abord le test qui le prouve, montre-le-moi,
  puis propose la correction.

> /plan Ajoute la pagination à l’API /orders, par
  curseur et pas par offset. Regarde d’abord comment
  /products le fait. Propose un plan, et pose-moi
  tes questions avant de coder.

> J’ai décrit le besoin dans docs/chantier-export-csv/
  BESOIN.md. Interroge-moi sur ce qui manque, puis écris
  PLAN.md : critères, hors sujet, étapes, suivi.

  … (quelques échanges plus tard, nouvelle session)

> step 2 du fichier docs/chantier-export-csv/PLAN.md

> Fais trois maquettes très différentes de la page
  d’accueil, dans jetable/accueil-a.html, -b et -c.
  Code jetable : vise l’effet, pas la qualité.

> [Image #1] La B, mais avec le titre de la A et
  moins de couleurs.

$ claude -w migration-auth     # terminal 1
$ claude -w tests-paiement     # terminal 2

> Lance trois sous-agents en parallèle pour auditer
  orders/, billing/ et shipping/ : dépendances mortes,
  code dupliqué. Puis fais-moi une synthèse classée.

$ claude -p "Corrige les avertissements de lint sans
  changer le comportement, puis résume tes changements." \
    --permission-mode dontAsk \
    --allowedTools "Read,Edit,Bash(npm run lint *)" \
    --max-turns 20 \
    --output-format json

Laquelle choisir ?

Le choix dépend moins de la taille du projet que de trois questions : ce que vous cherchez à obtenir, ce que deviendra le code, et le prix d’une erreur. L’aiguilleur ci-dessous les pose dans l’ordre.

Et pour garder une vue d’ensemble, voici les sept côte à côte :

Les sept façons de travailler ont toutes leur place, et j’utilise chacune à un moment ou à un autre. Mais pour tout ce qui part en production, j’en ai une, et une seule. Elle découle directement de ce que je défendais dans l’article « L’IA va-t-elle remplacer les développeurs ? ».

De l’éditeur au cahier des charges

J’y écrivais que le développeur passe du rôle d’auteur à celui d’éditeur, et que le cahier des charges redevient le vrai code. À l’usage, je vais un cran plus loin, et c’est le cœur de cet article. Pas une image : une organisation concrète du dépôt et des journées.

L’histoire du métier a déjà connu ce glissement. Quand les développeurs sont passés de l’assembleur à des langages comme Java, le code source a changé de langue. Le code compilé n’a pas disparu : il est devenu un produit dérivé, régénéré à chaque compilation, que plus personne n’écrit à la main. Avec Claude Code, je vis un glissement du même ordre. La source, c’est la spécification, écrite en français dans un fichier du dépôt. Le code en est dérivé.

La même intention, à trois époques. Le tableau reprend les colonnes du schéma, avec une ligne de code à chaque fois :

Coder à deux : qui fait quoi

Je n’ai pas arrêté de coder. Je code à deux, et chacun a ses lignes. La répartition n’a rien de théorique : c’est celle que je retrouve dans chaque chantier.

Le cycle d’un chantier

Voici à quoi ressemble le fichier, sur l’export CSV de notre mardi matin :

# Chantier : export CSV des commandes

> Dossier provisoire. Les décisions durables iront dans docs/ARCHITECTURE.md,
> puis ce dossier sera supprimé.

## Besoin
La compta rapproche chaque fin de mois les commandes payées et les virements.
Aujourd’hui, elle copie-colle depuis l’admin, page par page.

## Critères d’acceptation
- Bouton « Exporter » sur /admin/commandes ; les filtres de la liste s’appliquent.
- Colonnes : n°, date (AAAA-MM-JJ), client, total TTC, statut.
- Séparateur point-virgule, UTF-8 avec BOM (sinon Excel casse les accents).
- 50 000 lignes sans saturer la mémoire : écriture en flux.
- Réservé au rôle `compta` ; chaque export est journalisé.

## Hors sujet
- Pas d’export générique pour les autres entités. Pas de PDF.

## Règles communes
- Suivre docs/ARCHITECTURE.md § Admin. Aucune nouvelle dépendance.
- Tests d’abord. `npm test` et `npm run lint` au vert avant chaque commit.
- Ne jamais modifier une migration existante.

## Suivi
| Étape | Contenu                                      | État |
|-------|----------------------------------------------|------|
| 1     | Tests du format (en-têtes, dates, BOM)       | ✅   |
| 2     | Service d’export en flux + droits `compta`   | ⬜   |
| 3     | Bouton dans l’admin + journalisation         | ⬜   |
| 4     | Essai sur 50 000 lignes, documentation       | ⬜   |

Avec ce fichier, le service générique du mardi n’aurait jamais existé : il est écrit noir sur blanc dans « Hors sujet ». Pour que Claude sache quoi faire du fichier, une seule règle suffit dans le CLAUDE.md du projet :

Quand l’utilisateur écrit « step X du fichier … », exécuter exactement cette
étape en suivant les « Règles communes » du fichier, puis mettre à jour
son tableau « Suivi ».

Et la séance de travail tient alors en une ligne :

> step 2 du fichier docs/chantier-export-csv/PLAN.md

● Read docs/chantier-export-csv/PLAN.md · Read docs/ARCHITECTURE.md
● Étape 2 : service d’export en flux et droits « compta ».
● Update src/admin/orders/export.ts · Update src/auth/roles.ts
● Bash npm test       48 réussis, 0 échec
● Bash npm run lint   ok
● Update docs/chantier-export-csv/PLAN.md  étape 2 : ✅

✓ Étape 2 commitée en local, prête pour ta revue.
  Point d’attention : les filtres de date sont en heure locale,
  la spec ne dit rien du fuseau. On tranche avant l’étape 3 ?

La dernière ligne est ma préférée. Un bon binôme ne se contente pas d’exécuter : il remonte les trous de la spec. Et la réponse, quelle qu’elle soit, ira dans le fichier, pas dans la conversation.

La revue, le plus gros du travail

Relire un diff, ce n’est pas chercher les fautes de frappe. C’est là que l’expérience du développeur pèse le plus, et c’est là que je passe le plus de temps. Elle se fait dans un ordre précis.

Chaque question suit le même chemin. Ce qui compte, c’est l’avant-dernière étape : une modification approuvée qui ne rejoint pas la spec sera oubliée à la session suivante.

> Pourquoi csv-stringify ? Les règles communes disent
  « aucune nouvelle dépendance ».

● Exact. Je l’ai ajoutée pour l’échappement des champs. Je peux
  écrire un générateur en flux d’une trentaine de lignes, testé.

> Fais-le. Et renomme exportOrders en streamOrdersCsv : dans ce
  projet, les fonctions de flux commencent par stream. Ajoute
  cette convention aux règles communes du plan.

● Update src/admin/orders/export.ts · Update package.json
● Update docs/chantier-export-csv/PLAN.md  règle ajoutée
● Bash npm test       51 réussis, 0 échec

✓ Dépendance retirée, fonction renommée, convention dans le plan.

Ce n’est pas une méthode de laboratoire. Je l’ai expérimentée.

Les cinq règles que je ne négocie pas

Pourquoi ça marche

Cette méthode n’a rien de magique. Elle répond point par point aux limites du collègue décrites en partie 1 :

Je ne suis pas seul à converger vers cette forme. Anthropic décrit, pour ses agents qui travaillent sur de longues durées, un dispositif voisin : une liste de fonctionnalités et un fichier de progression que l’agent relit à chaque nouvelle session, et un travail mené une fonctionnalité à la fois. Les outils de développement piloté par les spécifications cités dans l’article « L’IA va-t-elle remplacer les développeurs ? », comme Spec Kit chez GitHub ou Kiro chez AWS, vont dans le même sens. Le nom changera. Le principe, lui, tient :

Quand je m’écarte de ma méthode

Une méthode qu’on applique partout devient un dogme. Voici quand je fais autrement.

Une bonne méthode s’appuie sur un atelier bien rangé. Claude Code offre une demi-douzaine de briques de configuration, qui se ressemblent assez pour qu’on les confonde. Reprenons notre collègue : en partie 1, on a vu sa tête, ses mains, son bureau et son carnet. Il est temps de l’équiper. Cette partie dit où va quoi, à quoi sert chaque brique, et donne des fichiers prêts à adapter.

Équiper le collègue

Chaque brique de configuration correspond à un objet qu’on remettrait à un nouveau collègue pour qu’il travaille bien, et longtemps. Les couleurs de ce portrait sont celles des étiquettes de toute la partie.

Le plan de l’atelier

Voici où ranger tout cela, dans l’arborescence d’un projet bien équipé. Tout n’est pas nécessaire le premier jour : un CLAUDE.md et un fichier de réglages suffisent pour commencer. Le reste s’ajoute quand un besoin revient.

mon-projet/
├── CLAUDE.md                  la fiche d’accueil du projet, versionnée
├── CLAUDE.local.md            vos notes perso, hors Git
├── .mcp.json                  les serveurs MCP de l’équipe
├── .worktreeinclude           les fichiers à copier dans chaque worktree (.env)
├── .claude/
│   ├── settings.json          permissions et hooks de l’équipe, versionnés
│   ├── settings.local.json    vos réglages pour ce projet, hors Git
│   ├── rules/                 règles ciblées : tests.md, api.md…
│   ├── hooks/                 les scripts appelés par les hooks
│   ├── skills/                un dossier par savoir-faire
│   │   └── release/SKILL.md
│   └── agents/                un fichier par spécialiste
│       └── relecteur.md
├── docs/
│   ├── ARCHITECTURE.md        la carte : le quoi et le comment
│   ├── CONCEPTION.md          les décisions : le pourquoi
│   └── chantier-export-csv/   provisoire : PLAN.md
└── src/ …

~/.claude/                     vos réglages, valables dans tous vos projets
├── CLAUDE.md                  vos préférences : langue, style, habitudes
├── settings.json
├── skills/  agents/  rules/
└── keybindings.json

Quand utiliser quoi

Toutes ces briques modifient le comportement de Claude, mais pas de la même manière. La distinction la plus importante tient en deux mots :

CLAUDE.md : court, précis, vivant

/init écrit un premier jet de CLAUDE.md en lisant votre projet. C’est un bon point de départ, et un mauvais point d’arrivée : il décrit souvent ce que Claude pourrait trouver seul. Un bon CLAUDE.md dit ce que le code ne dit pas. La documentation conseille de rester sous les 200 lignes ; un bon fichier tient souvent en bien moins.

# Mon projet

Ce projet est une application web moderne
et performante.

Écris du code propre et maintenable.
Respecte les bonnes pratiques.
Fais attention à la sécurité.

Le code est dans src/. Les composants sont
dans src/components/. Les tests sont dans
tests/.

[suivent 400 lignes copiées du wiki]

# Boutique : API et admin
Node 24, Fastify, PostgreSQL.

## Commandes
- `npm test` : unitaires, rapides
- `npm run test:e2e` : lents, seulement si demandé
- `npm run check` : types + lint, après chaque modif

## Règles
- SQL uniquement dans src/db/queries/.
- Montants en centimes (entiers), jamais en float.
- Nouvelle table = nouvelle migration. Ne jamais
  modifier une migration existante.
- Ne jamais lancer `npm run deploy`.

## Repères
- Architecture : @docs/ARCHITECTURE.md
- « step X du fichier … » : exécuter cette étape,
  suivre ses règles communes, cocher le suivi.

Traitez-le comme du code : il se relit en pull request, et il s’enrichit d’une ligne chaque fois que Claude refait la même erreur. C’est la règle 1 de la partie 3 appliquée à la configuration.

Les permissions : écrire les droits une fois pour toutes

Plutôt que de répondre cinquante fois « oui » à npm test, écrivez-le dans les permissions. Chaque règle vise un outil, et éventuellement un motif : Bash(npm run check) pour une commande exacte, Bash(git diff *) pour toutes celles qui commencent ainsi, Read(./.env) pour un fichier. Les interdictions (deny) passent avant les questions (ask), qui passent avant les autorisations (allow).

{
  "permissions": {
    "allow": [
      "Bash(npm test)", "Bash(npm run check)",
      "Bash(git status)", "Bash(git diff *)", "Bash(git log *)"
    ],
    "ask": [ "Bash(git push *)" ],
    "deny": [
      "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)",
      "Bash(npm run deploy *)"
    ]
  }
}

Les réglages s’empilent : les vôtres (~/.claude/settings.json), ceux de l’équipe (.claude/settings.json), les vôtres pour ce projet (.claude/settings.local.json), et, en entreprise, des réglages gérés par l’administrateur, qui priment sur tout. /permissions montre le résultat, /status d’où vient chaque réglage. Une limite à connaître : une interdiction sur une commande shell est un filet, pas un mur, car il existe mille façons d’écrire la même commande. Pour les fichiers vraiment sensibles, ajoutez le bac à sable (/sandbox), qui filtre au niveau du système.

Les hooks : la loi

Un hook est une commande que Claude Code lance à un événement précis : avant ou après l’usage d’un outil, à l’envoi d’un message, à la fin d’un tour, au démarrage d’une session, quand Claude attend votre réponse. Il en existe une trentaine. Le hook reçoit les détails de l’événement en JSON sur son entrée standard. S’il se termine avec le code 2, l’action est bloquée, et son message d’erreur est renvoyé à Claude comme explication.

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command",
        "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write" }]
    }],
    "PreToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command",
        "command": ".claude/hooks/protege.sh" }]
    }]
  }
}

#!/usr/bin/env bash
# Refuse les modifications des fichiers sensibles.
fichier=$(jq -r '.tool_input.file_path // empty')

case "$fichier" in
  *.env|*.env.*|*package-lock.json)
    echo "Fichier protégé : $fichier" >&2
    exit 2 ;;
  */migrations/*)
    if [ -e "$fichier" ]; then
      echo "Migration existante : crée-en une nouvelle." >&2
      exit 2
    fi ;;
esac
exit 0

Le premier hook formate chaque fichier modifié : plus jamais de « pense à lancer Prettier » dans le CLAUDE.md. Le second transforme la règle « ne jamais modifier une migration existante » de conseil en loi. Autre usage que je recommande : un hook sur l’événement Stop, qui lance les tests quand Claude pense avoir fini, et le renvoie au travail s’ils échouent. /hooks liste ceux qui sont actifs. Et souvenez-vous qu’un hook est un programme qui tourne avec vos droits : celui d’un dépôt cloné se relit comme n’importe quel script.

Les skills : le savoir-faire

Un skill est un dossier qui contient un fichier SKILL.md : un nom, une description, puis des instructions, et éventuellement des scripts ou des modèles à côté. Seule la description est chargée au démarrage, une ligne par skill. Le contenu n’arrive dans le contexte que lorsque le skill sert, soit parce que vous tapez /release, soit parce que Claude reconnaît la situation dans la description. Comme le classeur dont on ne lit que les tranches, vous pouvez en avoir des dizaines sans encombrer le bureau. Les anciennes commandes personnalisées (.claude/commands/) fonctionnent toujours, mais les skills les remplacent.

---
name: release
description: Prépare une nouvelle version (changelog, numéro, tag).
  À utiliser quand on demande de publier, sortir ou livrer une version.
disable-model-invocation: true
---

# Publier une version

1. Vérifie qu’on est sur main, à jour, et que `npm test` passe.
2. Liste les commits depuis le dernier tag et classe-les
   (ajouts, corrections, changements cassants).
3. Propose le numéro de version (semver) et attends ma validation.
4. Mets à jour CHANGELOG.md, puis lance `npm version <numéro>`.
5. Ne pousse rien : affiche la commande `git push --follow-tags`.

La ligne disable-model-invocation: true réserve le déclenchement à vous seul : pour une procédure qui a des effets, je ne veux pas que Claude décide seul que c’est le moment. Les skills suivent un standard ouvert, Agent Skills, que d’autres outils lisent aussi. Anthropic publie des exemples dans le dépôt anthropics/skills (dont ceux qui manipulent les fichiers Word, Excel, PowerPoint et PDF), et un plugin officiel, skill-creator, aide à écrire les vôtres.

Les sous-agents : les spécialistes

Un sous-agent est une instance de Claude avec son propre prompt, ses propres outils, son propre modèle, et surtout son propre contexte. Claude Code en fournit trois : Explore (fouiller le code, en lecture seule), Plan (préparer un plan) et un agent généraliste. Ils servent à trois choses : protéger le bureau principal d’une recherche qui lirait cinquante fichiers (le spécialiste les lit sur son propre bureau et revient avec une page), porter un regard neuf sur un travail, et paralléliser. Les vôtres s’écrivent en Markdown :

---
name: relecteur
description: Relit un diff avec un regard neuf. À utiliser à la fin
  de chaque étape d’un chantier, avant le commit.
tools: Read, Grep, Glob, Bash
model: opus
---

Tu es un relecteur exigeant. On te donne une étape de PLAN.md et un diff.
Vérifie, dans cet ordre :
1. Le diff fait ce que dit l’étape, et rien de plus (lis « Hors sujet »).
2. Les cas limites : valeurs vides, gros volumes, fuseaux horaires.
3. La sécurité : droits, données personnelles, injections.
Réponds par une liste classée : bloquant, à corriger, suggestion.
Ne modifie aucun fichier.

Ce relecteur n’a pas vu la conversation qui a produit le code. C’est précisément ce qui le rend utile : il ne partage pas les angles morts de l’auteur. Il prépare votre revue, il ne la remplace pas. D’autres options existent, comme isolation: worktree pour qu’un sous-agent travaille sur sa propre copie du dépôt, ou background pour qu’il tourne pendant que vous continuez.

MCP : brancher l’atelier sur le reste de l’entreprise

Le Model Context Protocol, présenté dans l’article « Comprendre l’IA et maîtriser son jargon » comme une prise standard, permet de brancher Claude Code sur vos outils grâce aux serveurs MCP : tickets, erreurs de production, base de données, navigateur, documentation. Un serveur MCP s’ajoute en une commande :

$ claude mcp add --transport http github https://api.githubcopilot.com/mcp/
$ claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
$ claude mcp add --scope project playwright -- npx @playwright/mcp@latest

Trois portées : local (par défaut, vous seul, ce projet), project (dans .mcp.json, versionné, approuvé par chacun à la première utilisation) et user (vous, tous vos projets). /mcp affiche leur état et gère l’authentification. Depuis que Claude Code ne charge que le nom des outils au départ, brancher plusieurs serveurs coûte peu de contexte. Le vrai coût est ailleurs : chaque serveur est une porte. Traitez-le comme une dépendance : une source que vous connaissez, et des droits minimaux, par exemple un jeton en lecture seule.

Les plugins : la mallette toute prête

Un plugin regroupe des skills, des sous-agents, des hooks, des serveurs MCP ou des serveurs de langage (LSP) dans un paquet qu’on installe d’une commande. /plugin ouvre le catalogue. La place de marché officielle d’Anthropic, claude-plugins-official, est ajoutée automatiquement ; une place de marché communautaire existe à côté. Attention, « officielle » désigne le catalogue : la plupart des plugins qu’il contient viennent de partenaires, et Anthropic en maintient elle-même une sélection plus restreinte. Voici ceux de cette sélection que je trouve les plus utiles :

> /plugin install code-review@claude-plugins-official

Claude Code embarque aussi des skills prêts à l’emploi : /simplify pour nettoyer un diff, /verify pour vérifier un changement dans l’application réelle, /loop pour répéter une tâche à intervalle. Et la commande /code-review fait une revue locale à plusieurs niveaux d’exigence, jusqu’à ultra, une revue multi-agents dans le cloud. Pour le reste, une règle : un plugin peut contenir des hooks et des serveurs MCP, donc du code qui s’exécute chez vous. Installez-le comme vous installeriez une dépendance.

Quatre configurations types

Pour fixer les idées, voici quatre ateliers types, du plus léger au plus outillé. Prenez celui qui ressemble au vôtre et retirez ce qui ne sert pas.

Les commandes à connaître

Il en existe bien plus, et la liste s’allonge chaque mois. Voici celles que j’utilise vraiment, rangées par moment. Tapez / dans une session pour voir toutes celles qui sont disponibles chez vous, et consultez la liste officielle des commandes, celle des raccourcis clavier et celle des options de la ligne de commande.

Tout ce qui précède ne vaut que s’il passe dans vos journées. Cette dernière partie rassemble les erreurs que je vois le plus souvent (et que j’ai toutes faites), ce que les agents changent à la sécurité, et un programme d’une semaine pour démarrer sans se brûler.

Les dix erreurs que tout le monde fait

Sécurité : ce qu’un agent change

Un assistant qui suggère du code ne fait rien par lui-même. Un agent, si : il exécute des commandes avec vos droits, sur votre machine, et il lit beaucoup de texte qu’il n’a pas choisi. Le README d’une dépendance, une issue GitHub, une page web, un commentaire dans un fichier : chacun peut contenir des instructions écrites pour lui. C’est l’injection de prompt, et aucun modèle n’y est totalement immunisé. La documentation de Claude Code le dit sans détour.

Le développeur britannique Simon Willison a donné un nom au cas le plus dangereux : le lethal trifecta, le trio mortel. Un agent qui réunit les trois capacités ci-dessous peut être manipulé pour faire sortir vos données. La parade est simple à énoncer : retirez-lui toujours au moins une des trois.

En pratique, six habitudes couvrent l’essentiel :

Votre première semaine

Si vous débutez, ne lisez pas tout ceci comme une liste à cocher d’un coup. Voici la progression que je conseille, un jour par façon de travailler.

Le robot et l’orchestre attendront la deuxième semaine. On ne délègue bien que ce qu’on a d’abord fait soi-même avec l’outil.

À vous de jouer

Comme dans l’article « L’IA va-t-elle remplacer les développeurs ? », je termine par les questions que je me pose encore. Vos réponses m’intéressent.

$ git merge --no-ff ma-methode
Merge made by the 'ort' strategy.