Vous utilisez Claude Code depuis six modules, et vous tapez peut-être encore les mêmes instructions en boucle. « Relis mon code. » « Explique-moi ce fichier. » « Fais un commit propre. » Bonne nouvelle : tout cela peut devenir une commande de quelques caractères. Dans ce module, vous allez transformer Claude Code, outil générique, en un outil taillé exactement pour vous — et pour toute votre équipe.

Ce que vous allez apprendre

• Manier les commandes slash intégrées qui font gagner du temps chaque jour
• Choisir entre /compact et /clear pour gérer votre contexte intelligemment
• Créer vos propres commandes slash en trois minutes, arguments compris
• Comprendre la hiérarchie des trois fichiers settings.json
• Écrire des règles de permissions claires avec allow, deny et ask

Le tour du propriétaire : huit commandes intégrées

Petit rappel. Une commande slash, c’est un ordre que vous tapez directement dans la session, précédé d’une barre oblique. Pas besoin de phrase complète : la commande agit immédiatement. Voici les huit plus utiles au quotidien.

/model change de modèle en cours de session. Trois gammes existent : Haiku, le rapide et économe ; Sonnet, l’équilibre entre vitesse et qualité ; Opus, le plus puissant. À la date de cette formation, la génération actuelle est la famille Claude 5, avec notamment Sonnet 5 et Fable 5, aux côtés d’Opus 4.8 et de Haiku 4.5. Pour situer ces modèles dans le paysage, notre dossier IA et son comparatif des IA vous donneront des repères.

/cost affiche votre consommation. Si vous passez par une clé API, c’est votre compteur de dépenses. Consultez-le régulièrement, comme le tableau de bord d’une voiture.

/compact résume la conversation en cours pour libérer de la place. Nous y revenons dans un instant, car c’est une commande stratégique.

/config ouvre les réglages de Claude Code : thème, comportement, options diverses.

/doctor vérifie la santé de votre installation. Un comportement étrange, une mise à jour qui coince ? Commencez toujours par /doctor.

/add-dir ajoute un autre dossier à la session en cours. Pratique quand votre travail touche deux projets à la fois : le site dans un dossier, l’API dans un autre.

/statusline personnalise la ligne d’état, cette petite ligne d’information affichée dans le terminal pendant la session.

/output-style ajuste la manière dont Claude formule ses réponses, par exemple pour adopter un ton plus pédagogique.

💡 Astuce — Vous ne retiendrez pas tout, et c’est normal. Tapez /help dans une session : la liste complète des commandes disponibles s’affiche, avec leur description. C’est votre antisèche intégrée.

/compact ou /clear : le contexte est une ressource rare

Parlons du contexte, car tout se joue là. Tout ce que vous échangez avec Claude — vos messages, ses réponses, les fichiers qu’il lit — s’accumule dans sa fenêtre de contexte. C’est sa mémoire de travail. Imaginez un plan de travail de cuisine : au début, tout est dégagé. Au fil de la préparation, les ustensiles s’entassent. À un moment, il n’y a plus de place pour cuisiner.

Deux commandes gèrent ce plan de travail.

/clear débarrasse tout. La conversation repart de zéro, comme si vous veniez de lancer Claude Code. Utilisez-le quand vous changez complètement de sujet : l’historique du bug précédent n’aide en rien pour la nouvelle fonctionnalité. Il encombre, il coûte, il peut même embrouiller le modèle.

/compact fait le tri. Claude résume la conversation : il garde l’essentiel — les décisions prises, les fichiers concernés, l’état du travail — et jette le verbiage. Utilisez-le quand la suite dépend de ce qui précède : au milieu d’une refonte, ou après un long débogage dont les conclusions comptent encore.

La règle tient en une phrase. Nouvelle tâche sans lien avec la précédente : /clear. Même chantier qui continue : /compact.

Sachez enfin que Claude Code compacte automatiquement la conversation quand elle approche de la limite. C’est un filet de sécurité, pas une stratégie.

⚠️ Piège courant — Attendre le compactage automatique. Il se déclenche au pire moment : en plein milieu d’une tâche délicate, sans égard pour votre travail en cours. Prenez l’habitude de compacter vous-même aux moments charnières, après un commit ou avant une nouvelle étape. C’est vous qui choisissez ce qui mérite d’être retenu.

Votre première commande personnalisée en trois minutes

Passons à la partie la plus satisfaisante du module. Une commande personnalisée, c’est tout simplement un fichier markdown placé au bon endroit. Pas de programmation, pas d’enregistrement : un fichier texte suffit.

Le principe : créez un fichier dans le dossier .claude/commands/ de votre projet. Le nom du fichier devient le nom de la commande. Le contenu du fichier devient l’instruction envoyée à Claude quand vous tapez la commande.

Regardez comme c’est simple :

# À la racine de votre projet
mkdir -p .claude/commands

Puis créez le fichier revue.md dans ce dossier :

Relis les modifications en cours dans ce projet
et signale-moi tout ce qui te semble fragile.

C’est terminé. Dans votre prochaine session, tapez /revue : Claude exécute cette instruction. Le fichier revue.md a donné la commande /revue. Un fichier optimisation.md donnerait /optimisation.

Deux emplacements existent, selon la portée souhaitée :

• .claude/commands/ dans un projet : la commande n’existe que dans ce projet. Versionnez ce dossier avec git, et toute l’équipe en profite.
• ~/.claude/commands/ dans votre dossier personnel : la commande vous suit dans tous vos projets.

Et si vous rangez vos fichiers dans des sous-dossiers, ceux-ci deviennent des espaces de noms : un moyen de grouper les commandes par thème pour organiser une grosse collection.

💡 Astuce — Versionnez .claude/commands/ avec le projet. Une bonne commande de revue de code écrite par un développeur senior devient instantanément disponible pour toute l’équipe, nouveaux arrivants compris. C’est du savoir-faire distribué par git.

La puissance des arguments

Une commande figée, c’est bien. Une commande qui accepte des paramètres, c’est beaucoup mieux. Claude Code offre deux mécanismes.

$ARGUMENTS récupère tout ce que vous tapez après le nom de la commande. Si votre fichier explique.md contient « Explique le fichier $ARGUMENTS », alors taper /explique src/utils.js remplace $ARGUMENTS par src/utils.js.

$1, $2 et ainsi de suite ciblent les arguments un par un, comme dans un script shell. C’est utile quand votre commande attend plusieurs informations distinctes : un fichier et une langue, ou un numéro de ticket et une priorité.

Vous pouvez aussi ajouter un en-tête au fichier, ce qu’on appelle un frontmatter : quelques lignes placées tout en haut, entre deux barrières de trois tirets. Quatre champs sont particulièrement utiles :

• description : le texte affiché à côté de la commande dans l’autocomplétion.
• argument-hint : un indice sur les arguments attendus, affiché pendant la frappe.
• allowed-tools : les outils que Claude peut utiliser sans demander confirmation pendant cette commande.
• model : impose un modèle pour cette commande — Haiku pour une tâche simple et répétitive, par exemple.

Voici un exemple qui combine le tout :

---
description: Traduit un fichier dans la langue demandée
argument-hint: [fichier] [langue]
model: haiku
---

Traduis le contenu du fichier $1 en $2.
Conserve la mise en forme d'origine.

Trois commandes prêtes à copier

Assez de théorie. Voici trois commandes complètes, à copier telles quelles dans votre dossier .claude/commands/.

/revue : la relecture exigeante

Fichier revue.md :

---
description: Relecture exigeante des modifications en cours
allowed-tools: Bash(git diff:*), Bash(git status:*)
---

Fais une revue de code exigeante des modifications en cours.

1. Regarde le diff courant avec git diff.
2. Pour chaque fichier modifié, cherche : bugs potentiels,
   cas limites oubliés, failles de sécurité, code dupliqué.
3. Classe tes remarques par gravité : bloquant, important, mineur.
4. Conclus : prêt à committer, ou pas, et pourquoi.

Sois direct. Mieux vaut une critique franche maintenant
qu'un bug en production demain.

Le diff, c’est la liste des différences entre votre code actuel et la dernière version enregistrée dans git. Grâce au champ allowed-tools, Claude peut consulter ce diff sans vous demander la permission à chaque exécution.

/explique : le professeur particulier

Fichier explique.md :

---
description: Explication pédagogique d'un fichier du projet
argument-hint: [chemin-du-fichier]
---

Explique le fichier $ARGUMENTS comme à un développeur
qui découvre ce projet.

1. Donne le rôle du fichier en une phrase.
2. Parcours les fonctions ou blocs principaux, un par un.
3. Montre ses liens avec le reste du projet.
4. Signale ce qui mérite une attention particulière.

Utilise des mots simples et des analogies quand c'est utile.

À l’usage : /explique src/services/paiement.js. C’est idéal pour monter en compétence sur un projet que vous découvrez.

/commit-propre : le commit conventionnel

Fichier commit-propre.md :

---
description: Commit au format conventionnel des changements en cours
allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(git status:*), Bash(git diff:*)
---

Prépare un commit propre des changements en cours.

1. Vérifie l'état du projet avec git status et git diff.
2. Rédige un message au format conventionnel :
   type(portée): description courte à l'impératif.
3. Le message doit expliquer le pourquoi du changement,
   pas seulement le quoi.
4. Montre-moi le message proposé avant de committer.

Un commit conventionnel suit une norme d’écriture : un type comme feat pour une fonctionnalité ou fix pour une correction, une portée entre parenthèses, puis une description. Résultat : un historique lisible par toute l’équipe. Et si certains termes vous échappent encore, leur définition vous attend dans notre glossaire.

settings.json : trois étages de réglages

Changeons d’échelle. Les commandes personnalisent ce que vous demandez à Claude ; les fichiers settings.json personnalisent comment il se comporte. Ce sont des fichiers au format JSON, un format texte structuré fait de paires clé-valeur entre accolades.

Il en existe trois, du plus général au plus spécifique :

1. ~/.claude/settings.json : vos réglages personnels, valables dans tous vos projets.
2. .claude/settings.json : les réglages du projet. Ce fichier est versionné avec git : c’est le règlement intérieur de l’équipe.
3. .claude/settings.local.json : vos réglages personnels pour ce projet uniquement. Il est ignoré par git : vos collègues ne le voient jamais.

Pensez à une maison partagée. Le fichier utilisateur, ce sont vos habitudes générales, valables où que vous soyez. Le fichier projet, c’est le règlement de la colocation, affiché dans la cuisine et valable pour tous. Le fichier local, ce sont vos arrangements personnels dans votre propre chambre.

Quand deux fichiers règlent la même chose, le plus spécifique gagne. L’ordre complet de priorité : les réglages d’entreprise d’abord, puis les options passées en ligne de commande, puis le fichier local, puis le fichier projet, puis le fichier utilisateur.

Le bloc permissions : allow, deny, ask

Le réglage le plus important de ces fichiers, c’est le bloc permissions. Il répond à une question simple : qu’est-ce que Claude a le droit de faire sans vous demander confirmation ?

Trois listes le composent :

• allow : autorisé sans confirmation.
• deny : interdit, point final.
• ask : toujours demander confirmation.

Chaque règle suit le format Outil(motif). Le motif précise à quoi la règle s’applique, avec l’étoile comme joker. Quelques exemples parlants :

• Bash(npm run test:*) : toutes les commandes npm run test, avec ou sans options.
• Edit(src/**) : la modification de n’importe quel fichier du dossier src.
• Read(~/.zshrc) : la lecture de ce fichier de configuration précis.
• WebFetch(domain:github.com) : la consultation de pages web, mais uniquement sur github.com.

Voici un exemple complet de .claude/settings.json pour une équipe :

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(npm run lint:*)",
      "Edit(src/**)",
      "WebFetch(domain:github.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(git push:*)"
    ]
  }
}

Lisons-le ensemble. Dans allow : les tests et le vérificateur de code tournent librement, les fichiers du dossier src se modifient sans friction, et la consultation de GitHub est permise. Dans deny : les fichiers .env et le dossier secrets, qui contiennent mots de passe et clés d’accès, sont interdits de lecture — même pour Claude. Dans ask : pousser du code vers le serveur git reste soumis à votre accord explicite, à chaque fois.

Retenez la règle d’or : deny gagne toujours. Si une règle allow et une règle deny se recouvrent, l’interdiction l’emporte, quel que soit le fichier où chacune se trouve. Une interdiction ne peut jamais être contournée par une autorisation.

⚠️ Piège courant — Une commande pourtant présente dans allow déclenche quand même un refus ou une demande de confirmation ? Ne cherchez pas l’erreur dans la règle allow : cherchez la règle deny qui la recouvre, peut-être dans un autre fichier de la hiérarchie. Tapez /permissions pour afficher l’ensemble des règles actives, tous fichiers confondus.

💡 Astuce — Vous hésitez sur la syntaxe d’une règle ? La commande /permissions permet de consulter et de gérer les règles sans éditer le JSON à la main. Et en cas de doute, la documentation officielle sur https://code.claude.com/docs reste la référence.

À vous de jouer

Créons ensemble votre première commande et votre première règle de permission.

1. Dans un de vos projets, créez le dossier .claude/commands s’il n’existe pas encore.
2. Créez-y le fichier revue.md et collez le contenu de la commande /revue présentée dans ce module.
3. Lancez claude, modifiez un fichier quelconque, puis tapez /revue. Vérifiez que la commande apparaît dans l’autocomplétion et observez la relecture.
4. Créez maintenant le fichier .claude/settings.local.json avec un bloc permissions dont la liste allow contient une seule règle : Bash(npm test:*). Inspirez-vous de l’exemple d’équipe montré plus tôt.
5. Tapez /permissions dans la session pour vérifier que votre règle est bien active.
6. Demandez à Claude de lancer les tests : ils s’exécutent désormais sans demande de confirmation.

En résumé

• Les commandes intégrées structurent votre quotidien : /model, /cost, /config, /doctor, /add-dir, /statusline, /output-style — et /help pour tout retrouver.
• /compact résume quand la suite dépend de ce qui précède ; /clear efface quand vous changez de sujet. Le contexte est une ressource rare : gérez-le activement.
• Un fichier markdown dans .claude/commands/ devient une commande slash ; le même fichier dans ~/.claude/commands/ vous suit dans tous vos projets.
• $ARGUMENTS capte tout ce qui suit la commande, $1 et $2 ciblent un argument précis ; le frontmatter ajoute description, argument-hint, allowed-tools et model.
• settings.json existe en trois étages — utilisateur, projet, local — et le bloc permissions distribue les droits avec allow, deny et ask.
• Deny gagne toujours : aucune autorisation ne peut contourner une interdiction.

Votre Claude Code est désormais réglé à votre main. Dans le prochain module, nous allons lui ouvrir les portes du monde extérieur avec MCP, le protocole qui le connecte à vos bases de données, vos navigateurs et vos services en ligne — et vos commandes personnalisées vont trouver de nouveaux terrains de jeu.