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.
Agent · alternative à Codex
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
Avant l’agent, il y a le chat (web, desktop, mobile). Trois features valent le détour pour un projet de dev.
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.
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.
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.
2 · Modes de permission
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.
Shift+Tab fait tourner le mode actif, affiché dans la barre de statut.| Mode | Nom technique | Ce 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. |
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
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.
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.
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.
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
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é.
4 · Arborescence
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.
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.
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.
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.
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.
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.
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
| Commande | Ce que ça fait |
|---|---|
/init | Génère un CLAUDE.md en analysant le repo |
/clear | Vide le contexte — le réflexe entre deux tâches sans rapport |
/compact | Résume la conversation pour libérer du contexte sans perdre le fil |
/context | Montre ce qui occupe la fenêtre de contexte |
/model | Change de modèle (Opus, Sonnet, Haiku) |
/memory | Liste et édite les fichiers mémoire chargés |
/permissions | Gère les règles allow / deny / ask |
/agents /hooks /mcp | Gèrent sous-agents, hooks et serveurs MCP |
/rewind | Revient à un checkpoint précédent |
/doctor | Diagnostique l’installation et la config |
| Raccourci | Effet |
|---|---|
Shift+Tab | Cycle entre les modes de permission |
Échap | Interrompt Claude en pleine action — ton meilleur outil |
Échap ×2 | Remonte dans l’historique pour reformuler (checkpoints) |
@fichier | Référence un fichier précis dans ton message |
!commande | Exécute une commande bash toi-même, sans passer par Claude |
↑ | Historique de tes messages |
/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
La fenêtre de contexte est la ressource rare. Quand elle sature, la qualité chute avant même le compactage automatique.
/clear dès que tu changes de tâche : nouvelle feature = contexte propre./compact si la session est longue mais que tu as besoin de la suite logique./context pour voir qui consomme quoi (MCP bavards, gros fichiers).paths:, skills plutôt qu’un gros CLAUDE.md.7 · Le workflow qui marche
Demande à Claude de lire le code concerné et de poser des questions, sans rien écrire.
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.
Valide le plan, laisse tourner en acceptEdits. Surveille, et appuie sur
Échap dès que ça dévie.
Petits commits fréquents. Claude écrit de bons messages si tes conventions sont
dans CLAUDE.md ou rules/git.md.
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
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.