12 fonctionnalités Claude Code : explications et exemples

1. Aperçu

Claude Code est un agent de codage fonctionnant dans le terminal, capable de lire, modifier, exécuter des commandes et d’auto-vérifier le code dans votre projet. Le problème : l’agent est puissant, mais s’il est utilisé par défaut, il peut facilement « s’égarer » – modifier le mauvais fichier, épuiser la fenêtre de contexte, ou exécuter des commandes dangereuses. Cet article explique 12 fonctionnalités pour vous aider à contrôler cet agent de manière intentionnelle. À la fin, vous saurez configurer CLAUDE.md, les permissions, les hooks, MCP… pour que Claude Code fonctionne selon les conventions de votre équipe, sur un exemple de projet Spring Boot comprenant Order, Customer, PaymentService.

2. CLAUDE.md

CLAUDE.md est un fichier mémoire que Claude Code lit automatiquement au début de chaque session. C’est ici que vous déclarez les conventions de code, la structure des répertoires, les commandes de build, le style guide – afin que l’agent n’ait pas besoin de poser les mêmes questions à chaque fois.

# CLAUDE.md

## Architecture
- Package `com.nonladev.order`: domaine Order, Customer
- Package `com.nonladev.payment`: PaymentService, PaymentGateway (interface)

## Conventions
- Toujours écrire des tests JUnit 5 + AssertJ pour les nouvelles méthodes publiques
- Ne pas utiliser `@Autowired` field injection, seulement constructor injection
- Exécuter `mvn verify` avant de signaler « terminé »

## Commandes courantes
- Build: `mvn -q clean verify`
- Exécution locale: `mvn spring-boot:run`

Claude lit ce fichier avant d’exécuter une tâche quelconque dans la session. Si vous demandez « ajouter une méthode de remboursement pour PaymentService », l’agent saura d’lui-même utiliser l’injection de constructeur et écrire les tests associés – sans avoir besoin de le rappeler.

Remarque : N’entassez pas trop de détails dans CLAUDE.md. Un fichier volumineux consomme la fenêtre de contexte dès le début de la session, alors que la plupart du contenu n’est pas pertinent pour la tâche actuelle.

3. Permissions

Les permissions contrôlent quels outils Claude peut utiliser et lesquels sont bloqués – c’est important car l’agent a le droit d’exécuter de vraies commandes shell.

{
  "permissions": {
    "allow": [
      "Bash(mvn *)",
      "Edit(src/main/java/**)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Edit(src/main/resources/application-prod.properties)"
    ]
  }
}

Ce fichier settings.json se trouve dans le répertoire .claude/. La ligne allow autorise l’agent à exécuter mvn et à modifier les fichiers dans src/main/java, mais la ligne deny bloque absolument la commande de suppression récursive et empêche la modification du fichier de configuration de production. Lorsque Claude veut dépasser une permission, il vous demande une confirmation avant d’exécuter.

Erreur courante : définir des permissions trop larges (allow: ["*"]) permet à l’agent d’exécuter n’importe quelle commande sans demander – dangereux avec les fichiers de configuration sensibles ou les secrets.

4. Plan Mode

Plan Mode force Claude à présenter un plan avant de toucher au code. Vous examinez le plan, le modifiez si nécessaire, puis laissez-le s’exécuter.

> Ajouter la fonctionnalité de remboursement partiel pour PaymentService

[MODE PLAN]
1. Ajouter la méthode refundPartial(Order order, BigDecimal amount) à PaymentService
2. Valider que amount <= order.getTotalPaid()
3. Appeler PaymentGateway.refund(...)
4. Écrire PaymentServiceTest pour 2 cas : valide, montant dépasse la limite

Voulez-vous que j'exécute ce plan ? [y/n/edit]

Quand vous répondez edit, Claude modifie le plan selon vos suggestions (par exemple, ajouter une étape de journalisation d’audit) avant de toucher au vrai code source. Cette approche est particulièrement utile pour les tâches modifiant plusieurs fichiers, car vous détectez une mauvaise direction dès l’étape de planification, plutôt qu’après que le code ait été modifié de façon désordonnée.

5. Checkpoints

Les checkpoints sont des snapshots automatiques du projet à des moments clés de la session, vous permettant de « revenir en arrière » si l’agent a mal fait quelque chose.

# Voir l'historique des checkpoints dans la session
/rewind

# Sortie
Checkpoint 1 - 10:02 - avant modification de PaymentService
Checkpoint 2 - 10:05 - après ajout de refundPartial
Checkpoint 3 - 10:09 - après modification du test (actuellement en erreur)

# Revenir au checkpoint 2
/rewind 2

Contrairement aux commits git, les checkpoints ne nécessitent pas que vous les créiez – Claude Code les enregistre automatiquement avant chaque changement important. Si l’agent modifie les tests dans une mauvaise direction (par exemple, en commentant une assertion pour que le test « passe »), vous pouvez revenir à l’état précédent sans avoir besoin d’utiliser git reset manuellement.

Remarque : les checkpoints ne vivent que dans le cadre de la session actuelle, ils ne remplacent pas git. Vous devriez toujours faire un vrai commit quand vous atteignez une étape importante.

6. Skills

Les skills sont des fichiers de guide réutilisables que Claude applique automatiquement quand il détecte une tâche appropriée – sans que vous ayez besoin de mentionner le nom à chaque fois.

---
name: spring-boot-test-writer
description: À utiliser lorsque vous devez écrire des tests pour la couche service dans un projet Spring Boot
---

Lors de l'écriture de tests pour une classe Service :
1. Utiliser JUnit 5 + AssertJ, ne pas utiliser Hamcrest
2. Mocker les dépendances avec Mockito, nommer les variables `mock<Dependency>`
3. Nommer les méthodes de test selon le format `should_<expected>_when_<condition>`

Ce fichier se trouve dans .claude/skills/spring-boot-test-writer.md. Lorsque vous demandez « écrire des tests pour PaymentService », Claude reconnaît automatiquement le skill approprié et applique la convention qu’il contient, ce qui donne :

class PaymentServiceTest {

    private final PaymentGateway mockGateway = mock(PaymentGateway.class);
    private final PaymentService paymentService = new PaymentService(mockGateway);

    @Test
    void should_refundAmount_when_amountIsWithinPaidTotal() {
        Order order = new Order("ORD-1", BigDecimal.valueOf(200));

        paymentService.refundPartial(order, BigDecimal.valueOf(50));

        verify(mockGateway).refund(order.getId(), BigDecimal.valueOf(50));
    }

    @Test
    void should_throwException_when_amountExceedsPaidTotal() {
        Order order = new Order("ORD-2", BigDecimal.valueOf(100));

        assertThatThrownBy(() -> paymentService.refundPartial(order, BigDecimal.valueOf(150)))
            .isInstanceOf(IllegalArgumentException.class);
    }
}

Les skills diffèrent de CLAUDE.md en ce sens : CLAUDE.md est toujours chargé, tandis que les skills ne sont chargés que lorsque le contexte le nécessite – économisant la fenêtre de contexte pour les projets ayant de nombreuses conventions spécialisées.

7. Hooks

Les hooks exécutent votre script shell à des points spécifiques du cycle de vie de l’agent, par exemple PreToolUse (avant d’appeler un outil) ou PostToolUse (après avoir appelé un outil).

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "mvn -q -pl . checkstyle:check"
      }
    ]
  }
}

Chaque fois que Claude termine la modification d’un fichier (outil Edit), le hook exécute automatiquement checkstyle:check. Si la commande échoue, la sortie est retournée à Claude, et l’agent modifie automatiquement le code en fonction de l’erreur de style avant de signaler que la tâche est terminée – vous n’avez pas besoin d’exécuter la vérification manuellement.

[PostToolUse] mvn checkstyle:check
ERROR: PaymentService.java:42: La ligne dépasse 120 caractères
→ Claude raccourcit automatiquement la ligne 42 et réexécute la vérification

Quand ne pas l’utiliser : les hooks s’exécutent chaque fois qu’un outil est appelé, donc si le script est lourd (build du projet complet), la session sera considérablement ralentie. N’attachez les hooks qu’aux événements du cycle de vie nécessitant une vérification rapide.

8. MCP

MCP (Model Context Protocol) connecte Claude aux systèmes externes – base de données, API internes, suivi des problèmes – comme un outil standardisé.

{
  "mcpServers": {
    "postgres-orders": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://localhost:5432/orders_db"]
    }
  }
}

Après avoir enregistré ce serveur dans .claude/settings.json, vous pouvez demander directement :

> Combien d'Orders sont en statut PENDING dans la table orders ?

[MCP: postgres-orders] SELECT COUNT(*) FROM orders WHERE status = 'PENDING';
→ 37 orders en attente

Claude génère automatiquement la requête SQL, l’appelle via le serveur MCP, et retourne le résultat réel de la base de données – sans avoir besoin que vous copiiez manuellement la requête dans un autre terminal.

9. Plugins

Un plugin est un bundle contenant des skills, des serveurs MCP et des hooks liés, vous permettant de les installer une seule fois au lieu de configurer chaque partie séparément.

/plugin install spring-boot-toolkit

Cette commande installe un plugin hypothétique contenant : un skill pour écrire des tests Spring Boot, un hook qui exécute mvn verify après chaque modification, et un serveur MCP se connectant à l’endpoint Spring Boot Actuator pour que l’agent puisse vérifier automatiquement la santé du service. Au lieu que vous ayez à écrire 3 fichiers de configuration séparés (skill, hook, mcp) comme aux sections 6–8, le plugin les rassemble en un package qui peut être partagé avec toute l’équipe via une seule ligne de commande.

10. Context

Le contexte est la fenêtre de contexte actuelle de la session — tous les fichiers lus, l’historique de la conversation, la sortie des commandes. La commande /context vous montre combien elle utilise.

/context

Context usage: 48,200 / 200,000 tokens (24%)
- CLAUDE.md: 1,200 tokens
- Fichiers lus : PaymentService.java, Order.java, PaymentServiceTest.java (6 400 tokens)
- Historique de la conversation : 38 000 tokens
- Sorties des outils : 2 600 tokens

Lorsque vous constatez que l’historique de la conversation occupe la majeure partie, vous savez que vous devriez compacter ou commencer une nouvelle session, pour éviter que Claude « oublie » les détails importants mentionnés au début de la session en raison de la troncature du contexte plein.

11. Slash Commands

Les slash commands sont des raccourcis pour les tâches que vous répétez – tapez / puis le nom, sans avoir à réécrire le long prompt à chaque fois.

---
name: review-pr
description: Examiner le diff actuel selon une liste de contrôle standard
---

Examiner le code diff actuel avec une liste de contrôle :
1. Y a-t-il des tests pour la nouvelle logique ?
2. Y a-t-il des logs contenant des informations sensibles (numéro de carte, mot de passe) ?
3. Y a-t-il violation de la convention d'injection de constructeur ?

Répondre au format : PASS/FAIL pour chaque point, avec une justification.

Enregistrez ce fichier dans .claude/commands/review-pr.md, puis appelez :

/review-pr

1. PASS - il existe PaymentServiceTest pour refundPartial
2. FAIL - log.info contient order.getCardNumber() à la ligne 58
3. PASS - utilise l'injection de constructeur

Les slash commands diffèrent des skills en ce que : les skills s’activent automatiquement selon le contexte, tandis que les slash commands nécessitent que vous mentionniez explicitement le nom – approprié pour les listes de contrôle fixes comme l’examen des PR ou les notes de version.

12. Compaction

La compaction comprime l’historique de conversation long en un résumé, libérant les tokens sans perdre les informations essentielles.

/compact

Avant compaction : 182 000 / 200 000 tokens
Après compaction : 24 000 / 200 000 tokens

Le résumé conservé :
- En cours : ajouter refundPartial à PaymentService
- Terminé : PaymentServiceTest (2 cas de test réussis)
- Restant : mettre à jour la spécification OpenAPI pour l'endpoint /refund

Au lieu que l’agent oublie complètement l’historique quand le contexte est plein, la compaction conserve les jalons clés (tâche en cours, terminée, manquante) sous forme de résumé court, puis continue la session avec le contexte principalement vide. Vous devriez appeler proactivement /compact après avoir terminé une grosse sous-tâche, avant de passer à la tâche suivante.

13. Subagents

Les subagents permettent à Claude Code de générer plusieurs agents enfants s’exécutant en parallèle, chacun responsable d’une partie indépendante d’un grand flux de travail.

---
name: test-writer
description: Spécialisé dans l'écriture de tests unitaires pour la classe spécifiée
tools: Read, Edit, Bash
---

Vous écrivez seulement des tests, ne modifiez pas la logique métier. Utilisez JUnit 5 + AssertJ.

Avec ce fichier subagent dans .claude/agents/test-writer.md, vous pouvez confier une grande tâche à l’agent principal, qui la répartit alors lui-même :

> Terminer le module refund : ajouter la logique, écrire les tests, mettre à jour la documentation

[Agent principal] Répartition en 3 subagents parallèles :
  → subagent « code-writer » : ajouter refundPartial à PaymentService
  → subagent « test-writer » : écrire PaymentServiceTest
  → subagent « doc-writer » : mettre à jour README.md

[3 subagents exécutés en parallèle] ... terminé en 42s

Au lieu que l’agent principal traite séquentiellement chaque étape (code → test → docs, ce qui peut prendre 3 fois plus de temps), les subagents traitent simultanément des parties indépendantes – utile pour les flux de travail à plusieurs étapes qui ne dépendent pas étroitement l’une de l’autre.

Quand ne pas l’utiliser : si les étapes dépendent séquentiellement (par exemple, l’écriture de tests nécessite que le code soit terminé pour connaître l’interface), l’exécution parallèle causera des erreurs car le subagent de test s’exécute avant que le code n’existe. N’utilisez les subagents que pour les tâches qui peuvent être vraiment séparées indépendamment.

14. Conclusion

Les 12 fonctionnalités ci-dessus se divisent en trois groupes distincts : le groupe de direction d’agent (CLAUDE.md, Skills, Plan Mode), le groupe de contrôle de sécurité (Permissions, Checkpoints, Hooks), et le groupe d’extension des capacités (MCP, Plugins, Subagents). Le contexte, les slash commands et la compaction sont la couche d’infrastructure qui aide l’agent à fonctionner efficacement dans une longue session. Vous n’avez pas besoin d’utiliser les 12 à la fois – commencez par CLAUDE.md et Permissions pour votre projet actuel, puis ajoutez Hooks ou MCP quand votre flux de travail en a vraiment besoin.