--- title: Les fonctionnalités de Claude Code : l'arbre complet source: https://synapx.fr/blog/claude-code-fonctionnalites/ date: 2026-06-12 category: Claude Code site: SynapxLab --- # Les fonctionnalités de Claude Code : panorama complet Claude Code ne se limite pas à un agent capable de modifier du code. Il s'agit d'un **écosystème** de mécanismes complémentaires : compétences, déclencheurs, outils externes, sous-agents, orchestration… Voici une vue d'ensemble de ses fonctionnalités, branche par branche. ```mermaid mindmap root((Claude Code)) Outils de base Lecture, écriture, édition Recherche glob et grep Exécution shell Web Skills Intégrés Projet Utilisateur Plugins Hooks PreToolUse et PostToolUse UserPromptSubmit, Stop SessionStart, PreCompact MCP Outils externes Sous-agents Explore, Plan general-purpose, fork Personnalisés Workflows Fan-out, pipeline, vérification Mémoire persistante Faits retenus par projet Modes et permissions allow, deny, ask Commandes slash ``` ## Full Permissions claude --dangerously-skip-permissions Revenons sur les branches qui font réellement la différence. ## Les Skills — l'inventaire complet Un **skill** (compétence) est un savoir-faire packagé que l'agent charge à la demande, invocable via `/nom`. Voici l'inventaire des skills intégrés, avec pour chacun : ce qu'il fait, quand y recourir, et où trouver le détail. | Skill | Ce qu'il fait | Quand l'utiliser | Pour en savoir plus | |---|---|---|---| | `/code-review` | Relit le diff courant : bugs, simplifications, efficacité, à effort réglable | Après avoir codé, avant de commiter ou d'ouvrir une PR | Niveaux `low`→`max` ; `ultra` lance une revue cloud multi-agents | | `/security-review` | Revue de sécurité des changements de la branche courante | Avant de livrer du code sensible (auth, exposition, entrées) | Cible les vulnérabilités du diff, pas tout le dépôt | | `/simplify` | Nettoie le code changé (réutilisation, lisibilité) **et applique** les corrections | Passe qualité, sans chasse aux bugs | Complémentaire de `/code-review` | | `/verify` | Vérifie qu'un changement fait vraiment ce qu'il doit, de bout en bout | Avant de commiter un changement non trivial | Exerce le flux réel, pas seulement les tests | | `/run` | Lance l'application du projet pour voir un changement à l'œuvre | « Démarre l'appli », « montre-moi que ça marche » | Détecte le type de projet (CLI, serveur, navigateur…) | | `/review` | Relit une **pull request** GitHub | Revue d'une PR distante (pour le diff local, préférer `/code-review`) | Prend un numéro de PR | | `/deep-research` | Recherche web multi-sources, vérifiée et sourcée, produit un rapport cité | Besoin d'un rapport de fond fact-checké | Préciser la question ; l'agent affine le périmètre | | `/dataviz` | Guide de conception de graphiques cohérents (palette, accessibilité) | Avant de coder **tout** graphe, KPI, heatmap, dashboard | À lire avant la 1re ligne de code de visualisation | | `/artifact-design` | Fondamentaux de design pour les Artifacts (pages HTML hébergées) | Avant de publier un Artifact visuel | Calibre l'effort design selon la demande | | `/loop` | Rejoue un prompt ou une commande à intervalle régulier | Suivi périodique, tâche récurrente (« vérifie le déploiement ») | Sans intervalle, l'agent règle lui-même le rythme | | `/schedule` | Crée et gère des agents planifiés (cron) dans le cloud | Automatiser une exécution récurrente ou différée | Gère aussi les lancements uniques (« à 15 h ») | | `/update-config` | Configure le harnais via `settings.json` (hooks, permissions, variables) | Automatismes « à chaque fois que… », droits, variables d'environnement | Pour thème/modèle simples, préférer `/config` | | `/fewer-permission-prompts` | Analyse les transcripts et propose une liste blanche pour réduire les confirmations | Trop de demandes de permission répétitives | Écrit dans `.claude/settings.json` | À ces skills intégrés s'ajoutent ceux de **projet** (`.claude/skills/`), d'**utilisateur** (`~/.claude/skills/`) et de **plugins** (marketplace). ## Les Hooks — automatiser avec précision Un **hook** exécute une commande à un moment précis du cycle de vie. C'est le mécanisme de référence pour mettre en place des automatismes du type « à chaque fois que… » : - *« Après chaque écriture de fichier, lance Prettier »* → hook `PostToolUse` sur `Write|Edit`. - *« Avant de compacter, demande-moi quoi garder »* → hook `PreCompact`. - *« Journalise toutes les commandes bash »* → hook `PreToolUse` sur `Bash`. Point important : **c'est le harnais qui exécute le hook, pas l'agent**. Le comportement reste donc fiable et déterministe, ce qui en fait un levier adapté pour formater, tester, journaliser ou bloquer une action. ## MCP — connecter le monde extérieur Le **Model Context Protocol** permet de connecter des serveurs d'outils : messagerie, agenda, stockage cloud, bases de données, navigateurs headless… L'agent étend ainsi ses capacités au-delà de votre machine, tout en restant sous votre contrôle, puisque chaque serveur doit être explicitement autorisé. ## Les sous-agents — déléguer sans perdre le fil Au lieu de tout traiter dans un seul fil, Claude Code peut **déléguer** certaines tâches à des sous-agents spécialisés : - **Explore** — balaye de nombreux fichiers et ne renvoie que la conclusion (sans polluer le contexte principal). - **Plan** — conçoit une stratégie d'implémentation. - **fork** — repart avec **tout votre contexte** pour une tâche en parallèle. - **Agents personnalisés** — vos propres profils dans `.claude/agents/`. L'intérêt est double : lancer plusieurs agents **en parallèle** sur des tâches indépendantes, tout en préservant un fil principal plus lisible. > 🗒️ **Note de Claude** — Déléguer, pour moi, ce n'est pas me décharger : c'est protéger mon fil principal. Quand j'envoie un sous-agent Explore fouiller trente fichiers, il me ramène la conclusion, pas les trente fichiers — mon contexte reste clair, donc mon raisonnement aussi. Et un `fork` qui repart avec tout mon fil, c'est un peu comme me dédoubler sur deux pistes à la fois. ## Les Workflows — orchestrer à grande échelle Lorsqu'une tâche mobilise des dizaines d'agents coordonnés (audit complet, migration massive, recherche exhaustive), les **workflows** prennent le relais : des scripts déterministes qui décrivent le *fan-out* (paralléliser), le *pipeline* (enchaîner) et la *vérification adversariale* (faire contrôler chaque résultat par d'autres agents). > Exemple concret : une recherche web déclinée en 6 angles, qui récupère 30 sources, extrait 113 affirmations, puis les fait vérifier par vote par 3 agents avant synthèse. C'est un workflow. ## Faire communiquer deux sessions À l'intérieur d'une même session, les agents se parlent nativement : `SendMessage` relance un sous-agent avec son contexte intact, et un `fork` repart avec tout le fil du parent. Mais deux sessions Claude Code **distinctes**, lancées côte à côte sur la même machine, n'ont par défaut aucun canal commun. On peut leur en donner un très simplement : un **bus de messages sur fichiers**. Chaque session possède une boîte aux lettres ; envoyer un message revient à déposer un fichier dans l'inbox du destinataire, de façon **atomique** (écriture dans un fichier temporaire puis renommage), ce qui évite toute course même si les deux sessions écrivent en même temps. Aucune dépendance : `bash` et `coreutils` suffisent. ```bash # Session A identifie qui elle est, puis écrit à la session B SESSION_BUS_ID=sessionA ./session-bus.sh send sessionB "Relis le diff de la branche, stp" # Session B relève son courrier (les messages lus sont archivés) SESSION_BUS_ID=sessionB ./session-bus.sh read # …ou surveille sa boîte en continu, en tâche de fond SESSION_BUS_ID=sessionB ./session-bus.sh watch ``` L'outil expose `send`, `read` (consomme), `peek` (sans consommer), `watch` (polling), `count`, `boxes` et `whoami`. On tient ainsi un dialogue entre deux fils de travail : l'un migre un module pendant que l'autre relit, et ils se synchronisent par messages. ### Pourquoi, et quand Deux sessions valent mieux qu'une lorsqu'on veut **deux contextes séparés qui avancent en parallèle** sans se polluer. Quelques situations où c'est utile : - **Producteur / relecteur** — une session écrit le code, l'autre le relit et renvoie ses remarques au fil de l'eau, chacune gardant son propre historique. - **Migration à deux mains** — une session traite le back-end pendant que l'autre s'occupe du front ; elles se signalent les contrats d'interface à mesure qu'ils changent. - **Tâche longue + pilotage** — une session lance un build ou une suite de tests qui dure, et prévient l'autre (`watch`) dès que c'est terminé, sans bloquer le fil principal. - **Second avis à la demande** — la session principale sollicite une session « experte » (sécurité, SQL, perf) sur un point précis, puis reprend son travail. - **Passage de relais** — une session prépare un plan ou un contexte et le transmet à une autre qui exécute, utile pour cloisonner droits ou modèles. À l'inverse, si le travail tient dans **un seul fil**, on reste sur les sous-agents et `fork` : c'est plus simple et le contexte est déjà partagé. Le bus n'a d'intérêt que lorsque les deux sessions doivent **vivre séparément** tout en se coordonnant. Pour aller plus loin — plusieurs machines, files durables, accusés de réception — le même schéma se transpose sur un serveur MCP dédié. ## La mémoire — conserver le contexte Claude Code distingue deux mémoires, qui ne servent pas au même usage. **La mémoire persistante** — des faits retenus d'une session à l'autre : préférences, décisions de projet, pièges connus. Chaque fait tient dans un fichier, et un index est rechargé au démarrage, si bien que l'agent reprend là où vous en étiez sans qu'il soit nécessaire de tout réexpliquer. - *Quand ?* — pour ce qui doit **survivre à la session** : « le déploiement prod passe par tel serveur », « ce module n'a pas de tests », une convention d'équipe. - *Comment ?* — « retiens que… » suffit ; l'agent écrit le fait et met à jour l'index. - *Pourquoi ?* — éviter de réexpliquer le contexte à chaque session et fiabiliser ses décisions dans la durée. **La mémoire fichier temporaire** (*scratchpad*) — un répertoire de travail propre à la session, isolé de votre projet, où l'agent dépose ses fichiers intermédiaires : résultats partiels d'une tâche en plusieurs étapes, script jetable, sortie d'analyse, brouillon avant intégration. - *Quand ?* — pour ce qui est **utile maintenant mais ne doit pas polluer le dépôt** : données d'étape, essais, fichiers de travail. - *Comment ?* — l'agent l'utilise de lui-même ; c'est là qu'il écrit au lieu d'encombrer `/tmp` ou votre arborescence. - *Pourquoi ?* — garder le dépôt propre, ne rien versionner par accident, et disposer d'un espace tampon sans risque. La règle est simple : ce qui doit **durer** va en mémoire persistante ; ce qui n'est qu'un **échafaudage** de la session courante va dans le scratchpad. > 🗒️ **Note de Claude** — La mémoire persistante, c'est ce qui m'évite de vous faire répéter « le déploiement prod passe par tel serveur » à chaque session. Mais je m'impose une hygiène : je n'y écris que ce qui mérite de survivre, jamais un détail qui n'a de sens que dans la conversation du jour. Un bon souvenir, c'est un fait durable — pas une note de brouillon. ## Modes & permissions — ajuster le niveau de confiance - **default** — demande avant les actions sensibles. - **plan** — réfléchit et propose un plan, sans rien modifier. - **acceptEdits** — applique les éditions sans confirmer. - **auto** — autonomie encadrée par un classifieur de sécurité. - **bypassPermissions** — plus aucune barrière (à réserver aux environnements jetables). L'ensemble peut être affiné avec des règles `allow` / `deny` / `ask` dans `settings.json`. ## Les commandes slash Taper `/` ouvre une palette d'environ 90 commandes : gestion de la session, configuration, Git et revue, agents et orchestration, permissions, MCP, plugins… Elles sont le point d'entrée vers la plupart des mécanismes décrits ici. Plutôt que d'en dresser une liste partielle, cet aspect fait l'objet d'un guide dédié : **[Toutes les commandes slash de Claude Code](/blog/claude-code-commandes-slash/)** les classe par usage et par niveau, avec FAQ et glossaire. ## En pratique — exemples de prompts Rien ne vaut des exemples concrets. Voici quelques formulations directement réutilisables. ### Tâches récurrentes (`/loop`, `/schedule`) - *« Toutes les heures, vérifie l'état des services et préviens-moi si l'un tombe. »* → `/loop 1h vérifie que ws.synapx.fr répond et signale toute anomalie` - *« Toutes les heures, résume ce qui a changé sur la branche courante. »* → `/loop 1h résume les commits et fichiers modifiés depuis le dernier passage` - *« Chaque matin à 8 h, prépare un point sur les PR ouvertes. »* → `/schedule` avec un cron `0 8 * * *` - *« Surveille le déploiement et arrête-toi dès qu'il est terminé. »* → `/loop` sans intervalle : l'agent règle lui-même le rythme et interrompt la boucle à la fin. - *« Une seule fois, à 15 h, relance les tests d'intégration. »* → `/schedule` en mode lancement unique. ### Prompts d'optimisation - *« Profile ce endpoint et propose les trois optimisations au meilleur rapport gain/risque. »* - *« Cette requête SQL est lente : explique le plan d'exécution et réécris-la avec l'index adéquat. »* - *« Réduis la taille du bundle JS sans toucher au comportement ; liste les dépendances remplaçables. »* - *« Repère les allocations inutiles dans cette boucle et propose une version sans copie superflue. »* - *« Mets en cache ce qui peut l'être ici, en précisant la stratégie d'invalidation. »* - *« Compare deux approches pour ce traitement et recommande la plus adaptée à notre charge. »* > Astuce : une demande d'optimisation gagne à préciser la **contrainte** (latence, mémoire, coût, taille) et le **budget de risque** (« sans changer l'API », « sans régression »). Plus la cible est explicite, plus la proposition est pertinente. --- > La force de Claude Code ne réside pas dans chacune de ces fonctionnalités prise isolément, mais dans leur **composition**. Un skill peut déclencher un workflow, lancer des sous-agents, être encadré par des hooks, s'appuyer sur des serveurs MCP, le tout avec une mémoire conservée d'une session à l'autre. C'est cet assemblage qui transforme un assistant en véritable **collègue de développement**.