Agent · alternative à Codex

Bien débuter avec Claude & Claude Code

Claude Code est l’agent de code d’Anthropic, principalement dans le terminal — un concurrent direct de Codex, pas un complément. Sa particularité : il se configure très finement, avec des modes de permission, un CLAUDE.md, des règles modulaires, des commandes, des skills, des sous-agents et des hooks.

Utile même si tu restes sur Codex : les concepts de cette page (mémoire projet, permissions, plan mode, skills, garde-fous) existent des deux côtés. Ici ils sont juste expliqués avec les noms et les fichiers de Claude Code — la page Agents donne la table de traduction.

1 · Le chat

Claude côté conversation

Avant l’agent, il y a le chat (web, desktop, mobile). Trois features valent le détour pour un projet de dev.

Projects

Des espaces avec leurs propres instructions et documents de référence. Un projet par produit ou par sujet : Claude a toujours le bon contexte sans que tu le recolles à chaque fois.

Artifacts

Le code, les documents et les petites apps générés s’affichent dans un panneau dédié, éditable et parfois exécutable directement. Pratique pour itérer sur une maquette ou un script.

Mémoire & connecteurs

Claude retient des choses d’une conversation à l’autre (désactivable), va chercher des infos à jour sur le web, et se branche à Notion, Drive ou GitHub via les connecteurs MCP.

Trois réflexes de prompting : donne le contexte + l’objectif + les contraintes + le format attendu (pas juste la question) ; itère plutôt que viser le prompt parfait du premier coup ; montre des exemples de ce que tu veux — et de ce que tu ne veux pas.

2 · Modes de permission

Qui décide quoi, et quand on te demande

Chaque session tourne dans un mode qui décide à quelle fréquence Claude te demande confirmation. À savoir d’entrée : lire le code ne demande jamais rien, quel que soit le mode. Les confirmations portent sur les modifications de fichiers et les commandes.

Schéma des modes de permission de Claude Code et du cycle Shift+Tab
Le cycle des modes : Shift+Tab fait tourner le mode actif, affiché dans la barre de statut.
ModeNom techniqueCe que ça fait
Ask / Manuel défaut default Confirme chaque édition de fichier et chaque commande. Le plus sûr, le plus lent.
Accept edits acceptEdits Éditions de fichiers auto-acceptées, plus les commandes de fichiers basiques dans le dossier de travail. Bash, git push et installs demandent encore.
Plan mode plan Lecture seule : Claude explore, réfléchit, et te présente un plan à valider avant de toucher à quoi que ce soit. Indispensable pour les refactos et grosses features.
Auto mode auto Claude enchaîne sans demander, avec des garde-fous : les actions vraiment destructrices déclenchent quand même une confirmation, et il respecte les limites posées en conversation.
Bypass risqué bypassPermissions Zéro confirmation, zéro filet, aucune protection contre les prompt injections. À réserver aux environnements isolés (container, VM, CI jetable). Doit être activé au lancement.
Le point à retenir : les règles deny et ask de tes settings s’appliquent dans tous les modes, bypass compris. Le mode change ce qui est auto-approuvé ; les interdictions restent au-dessus.

3 · Le fichier le plus important

CLAUDE.md, la mémoire du projet

Son contenu est injecté au début de chaque session. C’est là que tu écris ce que Claude devrait savoir sans que tu le répètes.

Ce qu’on y met

Les commandes du projet, les conventions qui diffèrent des défauts, les pièges connus, les décisions d’archi non évidentes, et ce qu’il ne doit pas faire.

Ce qu’on n’y met pas

L’arborescence du repo, la liste des dépendances, la description de l’archi standard : Claude retrouve tout ça seul, et ça gaspille du contexte.

!

Court = mieux suivi

Au-delà de ~200 lignes, ça mange du contexte et les consignes sont moins bien respectées. /init génère un premier jet à élaguer, puis on découpe dans rules/. /memory liste les fichiers mémoire chargés.

Squelette minimal

# Mon Projet

## Commandes
- `bun dev` — lance le serveur de dev
- `bun test` — tests (toujours lancer avant de dire que c'est fini)
- `bun lint:fix` — lint + format

## Conventions
- Gestionnaire de paquets : bun uniquement (jamais npm/yarn)
- Composants UI : uniquement via `shadcn add`, ne jamais modifier les internals
- Commits : conventional commits en anglais (`feat:`, `fix:`, …)

## Interdits
- Ne jamais toucher aux fichiers de migration existants
- Ne jamais commit sans que les tests passent

Exemple réel

Un CLAUDE.md de vrai projet

Celui de Queuecraft (un dashboard de job queues rendu dans un monde Minecraft). Il montre bien l’esprit : des règles non négociables, numérotées, qui renvoient aux décisions d’architecture — pas une description du repo.

CLAUDE.md · Queuecraft

# Queuecraft — CLAUDE.md

Dashboard de job queues rendu DANS un monde Minecraft (objet culte fonctionnel,
pas un outil de prod).
Monorepo pnpm : `packages/core` (modèle pivot + interface Adapter),
`packages/adapter-*`, `spikes/*`, `apps/demo`.
Toutes les décisions structurantes sont dans `docs/ADR-001-fondations-queuecraft.md`
— le lire avant tout travail d'architecture. Ne jamais contredire un ADR sans en
écrire un nouveau qui le remplace.

## Commandes
- `pnpm -r typecheck` — typecheck de tous les packages (doit passer avant tout commit)
- `pnpm bench` (dans `spikes/rcon-benchmark`) — benchmark RCON
- Serveur MC jetable : `docker compose up -d` dans `spikes/rcon-benchmark`

## Règles non négociables
1. **Vanilla-stable only** (ADR D4) : uniquement des commandes Minecraft stables
   depuis des années. Toute nouvelle commande → vérifier qu'elle existe telle
   quelle dans les deux versions visées.
2. **Budget RCON** (ADR D7) : ≤ 40 cmd/s en régime de croisière. Diffing
   obligatoire, agrégation obligatoire. Jamais de rendu 1:1 des jobs.
3. **Runtime** (ADR D8) : Node ≥ 22.12, zéro API spécifique Bun. TypeScript strict.
4. **`packages/core` n'importe JAMAIS une techno de queue.** Les adapters
   dépendent de core, jamais l'inverse.
5. **Interface `Adapter` gelée seulement après 2 implémentations.**
6. Sécurité : le port RCON n'est JAMAIS exposé publiquement. Mot de passe via
   variable d'env, jamais en dur.
7. Un seul CLAUDE.md (celui-ci). Pas de CLAUDE.md par sous-dossier.
8. **Zéro entité mobile ou à IA dans le renderer** : uniquement des primitives
   inertes. Animation par `data merge`, jamais par recréation.
9. **Profiling obligatoire avant toute optimisation perf** : on optimise ce qui
   est mesuré, pas ce qu'on suppose.

## Workflow
- Modèle : Opus planifie (plan mode), Sonnet exécute. Quand une carte de roadmap
  commence par un slash command, l'invoquer tel quel en première ligne.
- Après chaque carte : `pnpm -r typecheck`, mettre à jour le README du package
  touché si le comportement public a changé.
Ce qui rend celui-ci bon : il pointe vers un ADR au lieu de le recopier, chaque règle est vérifiable, les interdits sont explicites (« jamais », « zéro »), et le workflow dit quel modèle fait quoi.

4 · Arborescence

Où vivent les fichiers Claude Code

Deux emplacements, même logique. ~/.claude/ te suit dans tous tes projets ; .claude/ à la racine d’un repo est spécifique au projet et commitable pour l’équipe.

Schéma comparant le dossier global ~/.claude et le dossier .claude d’un projet
Global et projet se cumulent : le projet précise, le global suit partout.
Modulaire

rules/

Le CLAUDE.md découpé en modules markdown. Sans frontmatter, la règle est chargée partout. Avec paths:, elle n’est chargée que quand Claude touche aux fichiers concernés — les règles API ne polluent plus le contexte quand tu bosses sur le front.

Tu invoques

commands/

Chaque fichier .md devient une slash command (review.md/review), et $ARGUMENTS récupère ce que tu tapes après. Parfait pour les routines répétées.

Claude invoque

skills/

Un dossier avec un SKILL.md. La différence clé : c’est Claude qui décide de l’utiliser quand la description matche la tâche. Seule la description reste chargée en permanence → très économe en contexte.

Contexte isolé

agents/

Un fichier par sous-agent, dont le contenu est son system prompt. Chacun a son propre contexte (il n’encombre pas ta session, mais repart de zéro et consomme des tokens). On peut restreindre ses outils et choisir son modèle.

Déterministe

hooks/

Les scripts vivent là par convention, mais c’est settings.json qui les active (événement + matcher + action). Un script qui sort en code 2 bloque l’action. Contrairement à une consigne, un hook s’exécute à chaque fois, sans exception.

Garde-fous

settings.json

Permissions et mode par défaut, sur trois niveaux qui se cumulent (global, projet, projet-perso non commité). allow auto-approuve, deny interdit partout, ask demande toujours.

.claude/settings.json — base saine

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(bun test:*)",
      "Bash(bun lint:*)",
      "Bash(git commit:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force:*)",
      "Bash(rm -rf:*)"
    ],
    "ask": [
      "Bash(git push:*)"
    ]
  }
}

5 · Au quotidien

Commandes et raccourcis à connaître

CommandeCe que ça fait
/initGénère un CLAUDE.md en analysant le repo
/clearVide le contexte — le réflexe entre deux tâches sans rapport
/compactRésume la conversation pour libérer du contexte sans perdre le fil
/contextMontre ce qui occupe la fenêtre de contexte
/modelChange de modèle (Opus, Sonnet, Haiku)
/memoryListe et édite les fichiers mémoire chargés
/permissionsGère les règles allow / deny / ask
/agents /hooks /mcpGèrent sous-agents, hooks et serveurs MCP
/rewindRevient à un checkpoint précédent
/doctorDiagnostique l’installation et la config
RaccourciEffet
Shift+TabCycle entre les modes de permission
ÉchapInterrompt Claude en pleine action — ton meilleur outil
Échap ×2Remonte dans l’historique pour reformuler (checkpoints)
@fichierRéférence un fichier précis dans ton message
!commandeExécute une commande bash toi-même, sans passer par Claude
Historique de tes messages
Checkpoints : Claude crée un point de restauration avant chaque modification de fichier, et /rewind permet de restaurer le code, la conversation, ou les deux. Attention : ça ne couvre que les éditions faites par Claude — un rm, une migration ou un push ne sont pas annulés. Git reste le vrai filet de sécurité.

6 · Contexte

Le nerf de la guerre

La fenêtre de contexte est la ressource rare. Quand elle sature, la qualité chute avant même le compactage automatique.

7 · Le workflow qui marche

Explorer → Planifier → Coder → Committer

1

Explorer

Demande à Claude de lire le code concerné et de poser des questions, sans rien écrire.

2

Planifier

Passe en plan mode pour tout ce qui est non trivial. Lis le plan, corrige le plan : c’est dix fois moins cher de corriger un plan qu’un diff de 400 lignes.

3

Coder

Valide le plan, laisse tourner en acceptEdits. Surveille, et appuie sur Échap dès que ça dévie.

4

Committer

Petits commits fréquents. Claude écrit de bons messages si tes conventions sont dans CLAUDE.md ou rules/git.md.

La règle des deux fois : une consigne que tu répètes deux fois → elle va dans CLAUDE.md. Une routine que tu tapes deux fois → elle devient une commande. Un interdit absolu → un hook ou une règle deny.

Par où commencer

Trois pas, puis le reste s’ajoute

Lance claude dans un projet, fais /init et élague le CLAUDE.md généré, puis fais ta première vraie tâche en plan mode. Les règles, commandes, skills, agents et hooks s’ajoutent au fur et à mesure que tu identifies tes répétitions — pas avant.

Voir les skills et outils →