Les 4 concepts clés de Claude Code que personne n'explique clairement

Pourquoi ce guide existe

La plupart des tutoriels sur Claude Code couvrent les Skills et s’arrêtent là. Certains mentionnent les sub-agents. Presque aucun n’explique clairement la différence entre les 4 mécanismes fondamentaux, et surtout, comment ils s’articulent ensemble.

Le résultat : des développeurs qui utilisent Claude Code à 20% de son potentiel. Ils connaissent claude "fais ça" mais ignorent qu’ils pourraient orchestrer un écosystème complet d’agents spécialisés, de scripts automatiques et de commandes personnalisées.

Ce guide couvre les 4 concepts distincts :

Concept	Rôle	Déclenché par
Skills	Connaissance auto-invoquée	Claude lui-même
Sub-agents	Tâches isolées, contexte séparé	Claude ou l’utilisateur
Hooks	Réactions système automatiques	Événements (PreToolUse, etc.)
Commands	Prompts manuels personnalisés	L’utilisateur (slash commands)

Concept 1 : Skills, la connaissance embarquée

Ce que c’est

Une skill est un fichier Markdown que Claude Code charge automatiquement quand il détecte qu’il en a besoin. Pas besoin de l’appeler manuellement. Claude la trouve et l’utilise tout seul.

C’est de la connaissance contextuelle. Vous décrivez un processus, des conventions, un workflow, et Claude y accède quand la situation le demande.

Comment ça marche

Les skills vivent dans .claude/skills/ (local au projet) ou ~/.claude/skills/ (global). Chaque fichier a un frontmatter qui décrit quand l’invoquer :

---
name: infographie
description: Use when the user wants to create a visual infographic
---

## Process
1. Analyze the topic and identify key data points
2. Choose layout: vertical timeline, comparison grid, or flow diagram
3. Use brand colors: #E8915A (accent), #111113 (background)
4. Generate SVG with embedded data visualization
5. Export as PNG at 1080x1350 (Instagram) or 1200x628 (LinkedIn)

## Design constraints
- Maximum 6 data points per infographic
- Font: Inter for labels, JetBrains Mono for numbers
- Always include source attribution at the bottom

Cas d’usage concrets

• Design system : skill qui charge vos couleurs, typos, composants de référence
• Processus métier : skill qui décrit votre flow de déploiement ou votre convention de nommage
• Instructions récurrentes : skill qui rappelle les règles du projet (pas de console.log, toujours tester, etc.)

Ce que ce n’est PAS

Une skill ne fait rien par elle-même. Elle n’exécute pas de code, ne lance pas de process. Elle informe Claude. C’est un fichier de référence intelligent, pas un agent.

Concept 2 : Sub-agents, les travailleurs isolés

Ce que c’est

Un sub-agent est une tâche déléguée dans un contexte séparé. Claude lance un sous-processus qui travaille de son côté, avec ses propres instructions et potentiellement un modèle différent. Seul le résultat remonte dans la conversation principale.

Pourquoi c’est puissant

Le contexte principal reste propre. Si vous demandez à Claude d’analyser 50 fichiers, de scraper 10 URLs et de rédiger un rapport, tout ça dans la même conversation, le contexte explose. Avec des sub-agents, chaque tâche est isolée.

Et surtout : vous pouvez choisir le modèle par tâche.

---
name: veille-scraper
description: Scrape latest AI news from configured sources
model: haiku
---

Scrape the following sources for articles published in the last 24h:
- Hacker News (top 30)
- TechCrunch AI section
- Anthropic blog

For each article, extract: title, URL, date, 2-sentence summary.
Return as JSON array, sorted by relevance.

• Haiku pour le scraping et les tâches mécaniques (rapide, pas cher)
• Sonnet pour les tâches business courantes
• Opus pour le raisonnement complexe et les décisions architecturales

Exemple concret : agent veille

Un sub-agent veille-scraper qui tourne sur Haiku :

1. Scrape les sources configurées (Apify, RSS, APIs)
2. Filtre par pertinence
3. Formate les résultats
4. Push dans une page Notion via MCP

Le tout en 30 secondes, sans polluer le contexte principal. Vous récupérez juste : “12 articles trouvés, pushés dans Notion.”

Quand utiliser un sub-agent vs. faire directement

Situation	Faire directement	Sub-agent
Modifier un fichier	Oui	Non
Analyser 50 fichiers	Non	Oui
Tâche mécanique répétitive	Non	✅ (Haiku)
Décision qui nécessite le contexte actuel	Oui	Non
Recherche web approfondie	Non	Oui

FAQ

Quelle différence entre Skills, Sub-agents, Hooks et Commands ?

Quatre mécanismes distincts avec des rôles différents. Les Skills sont de la connaissance auto-invoquée que Claude charge tout seul quand il détecte qu’elle est pertinente. Les Sub-agents sont des tâches déléguées dans un contexte séparé, avec potentiellement un modèle différent. Les Hooks sont des réactions système automatiques déclenchées par des événements (PreToolUse, PostToolUse, Stop). Les Commands sont des prompts manuels personnalisés invoqués par l’utilisateur via un slash.

Qu’est-ce qu’une Skill Claude Code ?

Une skill est un fichier Markdown avec un frontmatter YAML qui décrit quand l’utiliser. Stockée dans .claude/skills/ (projet) ou ~/.claude/skills/ (global). Claude Code lit la description du frontmatter et charge automatiquement la skill quand le contexte correspond. C’est de la connaissance contextuelle (conventions, processus, règles) que Claude applique sans invocation explicite. Une skill n’exécute pas de code : elle informe Claude.

Quand utiliser un sub-agent plutôt que faire directement ?

Utilisez un sub-agent pour les tâches mécaniques répétitives (scraping, analyse de fichiers en masse), les recherches web approfondies qui pollueraient le contexte principal, ou les tâches qui peuvent tourner sur un modèle moins cher (Haiku pour le scraping, Opus uniquement pour le raisonnement complexe). Faites directement pour les modifications de fichiers, les décisions qui nécessitent le contexte actuel, ou les actions courtes et simples.

Les hooks peuvent-ils bloquer une action de Claude ?

Oui, c’est l’intérêt principal des hooks PreToolUse. Votre hook inspecte ce que Claude s’apprête à faire via les variables d’environnement (CLAUDE_FILE_PATH, CLAUDE_COMMAND), et s’il détecte un pattern interdit, il écrit un message sur stderr et sort avec le code 2. Claude Code voit le blocage et annule l’action. Utile pour protéger les fichiers sensibles (.env, fichiers lock) ou les commandes dangereuses (rm -rf, git push —force).

Comment créer une commande custom ?

Créez un fichier .md dans .claude/commands/ à la racine de votre projet. Le nom du fichier devient le nom de la commande : commit.md donne /commit. Le contenu du fichier est le prompt exécuté quand la commande est appelée. Utilisez $ARGUMENTS pour injecter les arguments passés après la commande. Les sous-dossiers créent des namespaces : .claude/commands/git/commit.md devient /git:commit.

Peut-on combiner les 4 mécanismes ?

Oui, c’est même la force de Claude Code. Un setup complet typique combine un CLAUDE.md avec les conventions projet, des skills globales pour votre style personnel, des commandes projet partagées pour les workflows récurrents (commit, review, deploy), des hooks pour la sécurité et l’auto-formatage, et des sub-agents pour les tâches mécaniques. Chaque mécanisme couvre un besoin différent et ils fonctionnent ensemble.

Où stocker quoi ?

Règle simple. Dans le projet (.claude/ versionné dans Git) : le CLAUDE.md, les commandes partagées, les hooks d’équipe. Dans votre home (~/.claude/ non versionné) : vos skills personnelles, vos hooks perso, votre CLAUDE.md global. En local non versionné (.claude/settings.local.json) : vos préférences personnelles pour ce projet spécifique. Ne mettez jamais de tokens ou secrets dans les fichiers versionnés.