Claude Code est bien plus que ce que vous imaginez

Lorsque j'ai commencé à utiliser Claude Code, je le traitais comme une conversation.

Je demandais quelque chose, il répondait, et c'était tout.

Ça fonctionnait, mais avec le temps, j'ai commencé à remarquer que je n'en tirais pas tout le potentiel.

Je répétais les mêmes prompts. J'exécutais les mêmes commandes. Je n'étais pas clair sur la façon d'en profiter pleinement.

Alors je me suis arrêté et je me suis posé une question :

Comment Claude Code fonctionne-t-il réellement à l'intérieur ?

J'ai commencé à lire la documentation, à expérimenter et à tester.

Et voici ce que j'ai découvert :

Il ne fait pas de magie. Il est construit sur des éléments concrets, chacun avec un rôle clair. Et quand vous les comprenez, tout le reste commence à avoir du sens.

→ Si vous répétez toujours les mêmes instructions, vous les transformez en Skill.

→ S'il perd le fil dans une tâche longue, vous déléguez à un SubAgent.

→ S'il y a des étapes manuelles que vous répétez, vous les automatisez avec des Hooks.

Comprendre les fondamentaux est ce qui vous permet de savoir quoi utiliser, quand et pourquoi.

Aujourd'hui, j'ai plus de 100 Skills, des processus automatisés qui me prenaient des heures, et des agents pour effectuer des revues de code et étudier des sujets qui m'intéressent.

J'ai écrit cet article pour partager tout ce que j'ai appris avec vous.

C'est parti.

Agent Loop : le cœur de Claude Code

Claude Code est un agent.

Un système à qui vous donnez un objectif et qui travaille jusqu'à l'atteindre.

C'est différent d'une conversation. Dans une conversation, vous demandez « Comment ajouter l'authentification à mon application ? » et il vous explique les étapes.

Mais vous devez aller dans le projet, modifier le code et tester si ça marche.

C'est vous qui faites le travail.

Avec Claude Code, vous lui dites « Ajoute l'authentification à mon application » et il s'en occupe.

Il lit le code, choisit la librairie, écrit les modifications et vous prévient quand c'est fini.

Il a un objectif : ajouter l'authentification.

Et il travaille jusqu'à l'atteindre.

Mais comment sait-il quoi faire après chaque étape ? Comment sait-il si quelque chose a fonctionné ? Il a besoin de quelque chose pour coordonner ces décisions.

C'est la boucle.

Un cycle qui se répète.

Claude Code exécute une action, observe le résultat, décide quoi faire ensuite et recommence. Il ne s'arrête pas tant que l'objectif n'est pas atteint.

Si quelque chose échoue, il revient en arrière, corrige et continue.

La boucle a 3 phases :

Recueillir le contexte → Comprend ce qu'il doit faire. Lit les fichiers, analyse le code, explore la structure du projet.

Agir → Exécute les modifications. Édite les fichiers, lance des commandes, installe les dépendances.

Vérifier les résultats → Vérifie que ce qu'il a fait fonctionne. Lance les tests, examine les erreurs, corrige si ça échoue.

La boucle s'adapte à ce que vous demandez.

Une question simple peut simplement nécessiter de recueillir le contexte. Corriger un bug peut passer par les trois phases plusieurs fois.

Claude Code décide ce que chaque étape nécessite en fonction de ce qu'il a appris de la précédente. Et vous faites également partie de cette boucle.

Vous pouvez interrompre à tout moment pour le rediriger, ajouter du contexte, ou lui demander d'essayer une autre approche.

C'est le cœur de Claude Code.

Tout ce qui suit existe pour rendre cette boucle plus puissante.

Outils : comment Claude Code agit dans le monde

Un LLM, par conception, ne fait que traiter du texte.

Il reçoit du texte et génère du texte. Il n'a pas accès à votre système de fichiers, il ne peut pas exécuter de commandes, il ne sait pas ce qu'il y a dans votre projet.

Il est isolé.

Alors, comment Claude Code ouvre-t-il un fichier ou le modifie-t-il ?

Il utilise des outils.

Les outils sont des fonctions que Claude Code peut invoquer pour interagir avec le monde réel.

Pensez-y comme aux applications mobiles. Le téléphone seul ne fait rien : ce sont les applications qui lui donnent des capacités spécifiques : prendre des photos, envoyer des messages, naviguer.

Les outils sont la même chose pour Claude Code.

Chaque fois qu'il utilise un outil, il envoie une requête au système avec ce dont il a besoin. Le système l'exécute et renvoie le résultat.

Claude Code utilise ce résultat pour décider quoi faire ensuite.

1Votre demande
2    ↓
3Claude Code décide quel outil utiliser
4    ↓
5┌─────────────────────────────────┐
6│  Lire · Modifier · Écrire · Bash│
7│  Grep · Glob · WebFetch · WebSearch │
8└─────────────────────────────────┘
9    ↓
10Le système exécute l'outil
11    ↓
12Le résultat revient à Claude Code
13    ↓
14Fini ? → Non → utiliser un autre outil
15             Oui → répondre

Claude Code est livré avec des outils natifs pour les opérations les plus courantes :

Lire / Modifier / Écrire → Lire, modifier et créer des fichiers. Les plus utilisés. Chaque fois que Claude Code « comprend votre code » ou « fait une modification », il utilise ces trois-là.

Bash → Accès complet au terminal. Si vous pouvez le faire depuis la ligne de commande, Claude Code le peut aussi : installer des dépendances, exécuter des tests, faire des commits.

Grep et Glob → Rechercher dans le projet. Glob trouve des fichiers par nom ou motif. Grep recherche un contenu spécifique dans les fichiers.

WebFetch et WebSearch → Accès à Internet. Consulter la documentation, lire une API, étudier une erreur qu'il n'a jamais vue.

Revenons à l'exemple du bug dans le bouton de connexion.

Lorsque Claude Code travaille là-dessus, il utilise plusieurs outils ensemble :

→ Il utilise Glob pour trouver le fichier du composant

→ Il utilise Lire pour lire le code et comprendre ce qui se passe

→ Il utilise Modifier pour corriger l'erreur

→ Il utilise Bash pour exécuter les tests et vérifier que ça a fonctionné

Tout cela sans que vous interveniez. C'est la différence entre une conversation et un agent.

Contexte et Mémoire : ce dont Claude Code se souvient

Claude Code travaille, exécute des actions, obtient des résultats et décide quoi faire ensuite.

Mais comment sait-il ce qu'il a fait au fur et à mesure ?

Tout est grâce au contexte.

Le contexte est l'information dont Claude Code dispose à ce moment-là. Chaque fois qu'il exécute une action, le résultat s'accumule dedans.

Non seulement votre prompt initial, mais tout ce qu'il trouve : les fichiers qu'il a ouverts, ce qu'il a découvert dans le code, les actions qu'il a exécutées et leurs résultats.

C'est pourquoi il peut enchaîner les étapes, se corriger et terminer la tâche tout seul.

Ce contexte a 2 problèmes.

1. Il a une capacité limitée. Si la session est très longue, le contexte se remplit et Claude Code commence à oublier ce qui s'est passé avant. Plus tard, vous verrez comment les SubAgents résolvent ce problème.

2. Il est vidé à chaque nouvelle conversation. Claude Code ne sait pas dans quel projet vous êtes, comment votre équipe travaille, ni quelles décisions ont déjà été prises. Si vous ne le lui dites pas, il le déduit ou vous le demande.

La Mémoire résout le deuxième problème.

C'est un système de fichiers markdown dans lequel vous enregistrez tout ce que Claude Code doit savoir : votre stack, les conventions de l'équipe, la structure des projets.

Claude Code les lit au début de chaque session et injecte ces informations dans le contexte avant que vous écriviez la première ligne.

Sans Mémoire : Vous lui dites « ajoute un endpoint pour créer des utilisateurs » et Claude Code vous demande : « Quel framework utilises-tu ? As-tu une base de données configurée ? Comment sont structurées les routes ? »

Avec Mémoire : Vous lui dites la même chose et il sait déjà que vous utilisez Express avec Prisma, que les routes se trouvent dans /src/routes et que les erreurs sont gérées avec un middleware centralisé. Il commence à travailler sans rien demander.

Claude Code a 2 systèmes de mémoire :

→ CLAUDE.md - Des fichiers markdown que vous écrivez avec tout ce que Claude Code doit savoir. Ils peuvent exister à différents niveaux :

→ ~/.claude/CLAUDE.md - S'applique à tous vos projets. Vos préférences personnelles y sont placées : comment vous voulez qu'il écrive le code, les conventions que vous utilisez toujours. Les instructions doivent être spécifiques : « utilise 2 espaces d'indentation » est plus clair que « formate bien le code ».

→ /votre-projet/CLAUDE.md - Spécifique au dépôt. L'architecture, les conventions de l'équipe et les commandes importantes y sont placées. Lorsque vous démarrez un nouveau projet, exécutez /init et Claude Code le génère automatiquement. Gardez-le en dessous de 200 lignes : s'il devient trop volumineux, Claude Code commence à ignorer les instructions. Et si vous le committez dans le repo, toute l'équipe partage le même contexte.

→ .claude/rules/ - Des règles modulaires qui s'activent selon le type de fichier. Utile lorsque le projet grandit et que vous ne voulez pas tout mettre dans un seul fichier.

Mémoire automatique - La mémoire que Claude Code construit tout seul. Au fur et à mesure que vous travaillez, il prend des notes de lui-même : les motifs qu'il détecte, les corrections que vous apportez, les décisions que vous avez prises ensemble. Elle est sauvegardée dans

~/.claude/projects/<project>/memory/ et chargée au début de chaque session.

Révisez-la souvent : Claude Code a peut-être enregistré de mauvaises pratiques sans que vous vous en rendiez compte.

Astuce : Vous pouvez voir et modifier tout ce dont Claude Code se souvient en exécutant /memory.

Hooks et Skills : Prenez le contrôle

1. Hooks

Claude Code travaille de manière autonome.

Il exécute des actions, prend des décisions, avance.

Mais cette autonomie a un aspect moins souvent évoqué : Claude Code fait ce qu'il considère correct à chaque étape.

Si quelque chose tourne mal, ou s'il fait quelque chose que vous ne vouliez pas, c'est déjà fait.

Comment le contrôler ? Avec des hooks.

Un hook est une commande qui s'exécute automatiquement à des moments précis du cycle. Avant que Claude Code n'utilise un outil, après qu'il l'a utilisé, lorsque la session se termine.

Vous définissez ce qui se passe à chaque moment.

Le point clé est que les hooks sont déterministes.

Ils ne dépendent pas du fait que Claude Code « se souvienne » de faire quelque chose. Ils sont toujours exécutés, sans exception.

Les quatre hooks principaux sont :

PreToolUse - S'exécute avant que Claude Code n'utilise un outil. C'est le seul hook qui peut bloquer une action. Exemple : Bloquer toute commande qui tente de modifier les fichiers .env.

PostToolUse - S'exécute après que Claude Code a utilisé un outil. Exemple : Exécuter Prettier automatiquement chaque fois que Claude Code édite un fichier.

Notification - S'exécute lorsque Claude Code a besoin de votre attention. Exemple : Recevoir une notification sur votre Mac lorsque Claude Code a terminé une longue tâche.

Stop - S'exécute lorsque Claude Code a fini de répondre. Exemple : Pusher automatiquement vers la staging lorsque l'agent a terminé.

Ils sont configurés dans .claude/settings.json :

1{
2  "hooks": {
3    "PostToolUse": [
4      {
5        "matcher": "Edit|Write",
6        "hooks": [
7          {
8            "type": "command",
9            "command": "npx prettier --write $file_path"
10          }
11        ]
12      }
13    ]
14  }
15}

Ce hook exécute Prettier automatiquement chaque fois que Claude Code édite ou crée un fichier.

Sans que vous le demandiez. Sans que Claude Code ait à s'en souvenir.

Sans Hook : Claude Code édite un fichier, le code reste non formaté, et vous vous en rendez compte au prochain commit.

Avec Hook : Claude Code édite un fichier, PostToolUse se déclenche automatiquement, Prettier formate le fichier, et le code reste toujours propre.

Les hooks vous permettent d'ajouter un comportement garanti au cycle de l'agent. Pas des suggestions, pas des instructions que le modèle peut ignorer. Des règles qui sont toujours exécutées.

2. Skills

Il y a un autre problème : la cohérence.

Vous lui demandez la même tâche deux fois et vous obtenez des résultats différents. Chaque fois que vous ouvrez une nouvelle conversation, Claude Code commence sans savoir comment vous avez fait la dernière fois.

Comment résoudre ce problème ? Avec des Skills.

Un Skill est un fichier markdown dans lequel vous expliquez à Claude Code le processus exact pour une tâche : quoi vérifier, dans quel ordre, quel format utiliser, quoi ignorer.

Chaque fois que cette tâche apparaît, Claude Code suit ces instructions.

Sans Skill : Vous lui demandez de documenter une API et il génère quelque chose, mais chaque fois avec un format différent. Parfois avec des exemples, parfois sans.

Avec Skill : Vous lui demandez de documenter une API et il suit le processus exact que vous avez défini. Toujours avec les mêmes étapes, le même format, les mêmes critères. Chaque fois identique.

Pour créer un Skill, vous définissez un dossier avec cette structure :

1mon-skill/
2├── SKILL.md          # Instructions principales (obligatoire)
3├── template.md       # Modèle que Claude complète
4├── examples/
5│   └── exemple.md    # Exemple de résultat attendu
6└── scripts/
7    └── valider.sh    # Script que Claude peut exécuter

Le seul fichier obligatoire est SKILL.md. Le reste est optionnel et vous l'ajoutez selon les besoins de la tâche.

Le SKILL.md a 2 parties :

Le frontmatter - Un bloc YAML avec le nom et la description. Le nom est la commande pour l'invoquer manuellement. La description est ce que Claude Code lit pour décider quand l'activer automatiquement.

Le corps - Les instructions en markdown. Le flux de travail, les critères, le format de sortie.

1---
2name: api-docs
3description: Documente les endpoints d'une API. Utilise-le quand
4             l'utilisateur demande de documenter une API ou mentionne "swagger" ou "endpoints"
5---
6
7## Processus
81. Identifier tous les endpoints
92. Pour chacun : méthode, chemin, paramètres, réponse attendue
103. Inclure un exemple de requête et de réponse
114. Terminer par un tableau récapitulatif

Une fois créé, vous pouvez l'invoquer de deux façons.

En écrivant /api-docs directement dans le chat, ou simplement en demandant à Claude Code en langage naturel.

Si la description correspond à ce que vous demandez, il s'active tout seul.

Vous pouvez en créer pour toute tâche que vous répétez et qui a un processus clair derrière elle : documentation d'API, changelogs, comptes-rendus de réunions, migrations de code.

SubAgents : déléguez quand le problème s'agrandit

Nous avons déjà vu que le contexte a une capacité limitée.

Plus la session est longue, plus il se remplit. Et quand il se remplit, Claude Code commence à perdre des informations sur ce qui s'est passé avant.

Imaginez que vous lui demandiez de passer en revue tout votre projet à la recherche de problèmes de sécurité. Il lit des dizaines de fichiers, analyse le code, génère un rapport détaillé.

Tout cela remplit rapidement le contexte.

Et pendant ce temps, votre conversation principale est bloquée.

Comment résoudre ce problème ? Avec des SubAgents.

Un SubAgent est une instance séparée de Claude Code qui s'exécute avec son propre contexte.

L'agent principal lui délègue une tâche, le SubAgent l'exécute indépendamment, et lorsqu'il a terminé, il envoie un résumé des résultats.

Le contexte de l'agent principal ne se remplit pas de tout le processus, seulement de la conclusion.

1Agent principal
2    ↓
3"passe en revue le projet pour les problèmes de sécurité"
4    ↓
5┌─────────────────────────────┐
6│    SubAgent : réviseur-sécurité    │
7│                             │
8│  Lit les fichiers du projet  │
9│  Analyse le code             │
10│  Détecte les vulnérabilités  │
11│  Génère le rapport           │
12└─────────────────────────────┘
13    ↓
14Retourne un résumé à l'agent principal
15    ↓
16L'agent principal continue avec la boucle

Et ce n'est pas tout.

Les SubAgents peuvent s'exécuter en parallèle.

Au lieu d'analyser trois parties du code séquentiellement, Claude Code peut déléguer les trois en même temps.

Ce qui prenait des minutes peut prendre des secondes.

1Agent principal
2    ↓
3Divise le travail en tâches indépendantes
4    ↓
5┌──────────────┐  ┌──────────────┐  ┌──────────────┐
6│  SubAgent 1  │  │  SubAgent 2  │  │  SubAgent 3  │
7│              │  │              │  │              │
8│ Révise l'auth│  │ Révise la BD │  │ Révise les   │
9│              │  │              │  │ API externes │
10└──────────────┘  └──────────────┘  └──────────────┘
11        ↓                 ↓                 ↓
12        L'agent principal reçoit les trois résumés
13                          ↓
14                Continue avec la boucle

Claude Code dispose de 3 SubAgents natifs qu'il utilise automatiquement :

→ Explore - Un agent rapide en lecture seule spécialisé dans la recherche et l'analyse du projet. Les résultats restent dans le contexte du SubAgent, pas dans le vôtre.

→ Plan - S'active en mode plan. Avant de vous présenter un plan, Claude Code délègue l'investigation du projet à cet agent.

→ Usage général - Pour les tâches complexes nécessitant à la fois exploration et modifications.

Vous pouvez également créer les vôtres.

Les SubAgents sont définis dans des fichiers markdown avec un frontmatter YAML et sauvegardés dans .claude/agents/.

1---
2name: réviseur-sécurité
3description: Révise le code pour les vulnérabilités de sécurité.
4             Utilise-le quand l'utilisateur demande une revue de sécurité.
5tools: Lire, Grep, Glob
6---
7
8Tu es un expert en sécurité. Analyse le code pour :
9- Les injections SQL
10- L'exposition de données sensibles
11- Les vulnérabilités d'authentification
12
13Termine par un résumé des résultats classés par sévérité.

Remarquez que dans le frontmatter nous limitons les outils à Lire, Grep et Glob.

Cet agent peut analyser mais jamais rien modifier.

Lorsque vous avez besoin d'un contrôle fin sur ce que chaque agent peut faire, cette restriction d'outils est essentielle.

Une fois créé, Claude Code le détecte automatiquement par la description et l'invoque lorsque la tâche correspond. Ou vous pouvez l'appeler explicitement : « utilise l'agent réviseur-sécurité pour réviser cette PR. »

Quand utiliser les SubAgents et quand ne pas le faire ?

Cela a du sens lorsque la tâche est longue et générera beaucoup de sortie, lorsque vous pouvez diviser le travail en parties indépendantes qui s'exécutent en parallèle, ou lorsque vous avez besoin d'un agent spécialisé avec des outils limités.

Cela ne vaut pas la peine pour des tâches courtes qui ne remplissent pas le contexte. Coordonner des SubAgents ajoute une complexité qui n'a pas de sens si l'agent principal peut résoudre la tâche en deux minutes.

MCP : connecter l'agent avec le monde extérieur

Les outils donnent à Claude Code la capacité d'agir sur votre machine.

Mais il y a une limite : tout ce qui se passe se passe à l'intérieur.

Il ne peut pas ouvrir une PR sur GitHub, interroger une base de données en production, ou créer un ticket dans Jira. Pour cela, vous deviez auparavant quitter l'agent et le faire vous-même à la main.

Comment résoudre ce problème ? Avec MCP.

MCP (Model Context Protocol) est un protocole ouvert qui définit comment Claude Code se connecte aux services externes.

Il fonctionne avec une architecture client-serveur : Claude Code est le client, et chaque service externe a son propre serveur MCP qui expose ce qu'il peut faire.

Lorsque vous connectez un serveur MCP, Claude Code reçoit une liste d'outils disponibles avec leur nom et leur description.

À partir de là, il les utilise exactement comme des outils natifs. La seule différence est que l'action se produit dans le service externe, pas sur votre machine.

1Claude Code
2    ↓
3Décide d'utiliser un outil du serveur MCP GitHub
4    ↓
5┌─────────────────────────────┐
6│      Serveur MCP GitHub      │
7│                             │
8│   Ouvre la PR               │
9│   Assigne les relecteurs    │
10│   Renvoie la confirmation   │
11└─────────────────────────────┘
12    ↓
13Claude Code reçoit le résultat et continue

Sans MCP : Vous lui dites « j'ai terminé les modifications, ouvre la PR » et Claude Code ne peut pas. Vous devez aller sur GitHub, remplir le formulaire, assigner les relecteurs et fusionner vous-même.

Avec MCP : Vous lui dites la même chose et Claude Code ouvre la PR, écrit la description, assigne les relecteurs et vous prévient quand c'est prêt. Le tout sans que vous quittiez l'agent.

Quelques serveurs MCP que vous pouvez connecter aujourd'hui :

→ GitHub - PRs, relectures, issues

→ Postgres / Supabase - Interroger et modifier des bases de données

→ Slack - Messages et canaux

→ Jira - Tickets et projets

Outils natifs pour votre environnement local. MCP pour le monde extérieur.

Comment tout s'assemble

Claude Code est un agent : un système qui prend un objectif et opère dans une boucle autonome jusqu'à l'atteindre.

Chaque élément que vous avez vu dans cet article existe pour rendre cette boucle plus puissante. Mais la meilleure façon de le comprendre est de les voir interagir ensemble.

Cas 1 : Réviser et fusionner une PR

Vous demandez à Claude Code : « Révise la PR #42 et si tout va bien, fusionne-la. »

→ Il utilise GitHub MCP pour lire les fichiers modifiés et comprendre les changements

→ Il délègue l'analyse de sécurité à un SubAgent spécialisé, pour ne pas remplir le contexte principal

→ Un Hook exécute les tests localement et vérifie que tout passe

→ Si les tests passent, il utilise GitHub MCP pour effectuer la fusion sans que vous touchiez à l'interface

Vous avez écrit une ligne. Claude Code a coordonné quatre systèmes.

Cas 2 : Documenter une API et notifier l'équipe

Vous demandez à Claude Code : « Documente les nouveaux endpoints et informe l'équipe. »

→ Il active un Skill de documentation qui définit le format exact : quoi inclure, comment structurer, quels exemples ajouter

→ Il utilise des Outils pour lire le code et extraire les endpoints

→ Un Hook formate la sortie avant de l'enregistrer

→ Il utilise Slack MCP pour envoyer le résumé au canal de l'équipe

Chaque fois que vous le faites, le résultat sera le même. Sans variations, sans que vous ayez à rien expliquer.

Tout tourne autour de la boucle.

La Mémoire pour démarrer chaque session informée. Les Outils pour agir. Les Hooks pour contrôler. Les Skills pour standardiser. Les SubAgents pour passer à l'échelle. MCP pour se connecter au monde extérieur.

Quand vous comprenez cela, vous comprenez Claude Code.

Et pas seulement Claude Code : Cursor, Copilot, et tout agent que vous utiliserez désormais fonctionne sur les mêmes bases.

Les noms changent, l'interface change, mais la boucle est la même.

L'IA progresse rapidement.

Chaque semaine, il y a du nouveau. Mais les fondamentaux ne changent pas si souvent. Les avoir bien compris est ce qui vous permettra de vous adapter plus vite et de tirer le meilleur parti de ce qui vient.

N'utilisez pas Claude Code uniquement pour du prompting. Faites attention à ce qui se passe en dessous. C'est là que se trouvent les opportunités.

Quelques points de départ pour commencer dès aujourd'hui :

→ Révisez votre Mémoire automatique et améliorez ce que Claude Code a sauvegardé

→ Créez un CLAUDE.md pour votre projet si vous n'en avez pas

→ Connectez le MCP GitHub

→ Construisez un SubAgent pour les tâches qui remplissent le contexte

→ Configurez un Hook qui exécute les tests après chaque modification

C'est tout, à demain.

Marcus