Récapitulation et examen final

Seize modules pour passer d'un usage occasionnel de Claude Code à une pratique d'ingénieur : Kiosque a désormais son CLAUDE.md, ses règles, six skills, deux sous-agents, trois hooks, deux serveurs MCP, un plugin, une CI qui répond à @claude et un budget maîtrisé. Voici le cours condensé, les fils qui le traversent et la liste de contrôle d'un dépôt qui a intégré Claude Code.

Le cours d'un coup d'œil

Module	L'essentiel à retenir
1. Installation	Claude Code est un agent en terminal ; /init, /doctor, /model et /effort posent le décor.
2. Boucle et contexte	La boucle appelle des outils intégrés ; /context révèle ce qui remplit la fenêtre, /compact la dégraisse, /clear repart à zéro.
3. CLAUDE.md et mémoire	Précédence managée > user > projet > local ; les règles ciblées vivent dans .claude/rules/, la mémoire automatique se relit avec /memory.
4. Commandes (1/2)	Aide, session, contexte, configuration, modèle, mémoire, permissions, compte : la référence en huit familles.
5. Commandes (2/2)	Qualité, parallélisme, automatisation, extensions, intégrations, skills fournies, diagnostic, prompts MCP.
6. Skills	Dossier .claude/skills/<nom>/SKILL.md ; frontmatter, $ARGUMENTS, !`cmd`, context: fork, allowed-tools limités.
7. Permissions et settings	Règles Outil(motif), six modes, sandbox du Bash, précédence des settings, /config clé=valeur.
8. Plan, checkpoints, sessions	Shift+Tab pour changer de mode ; Esc Esc pour rembobiner ; /branch, /fork, /subtask pour bifurquer ; worktrees pour paralléliser.
9. Hooks	PreToolUse, PostToolUse, Stop, UserPromptSubmit, SessionStart… ; codes de retour 0/2, JSON decision.
10. Sous-agents	.claude/agents/<nom>.md avec tools, model, skills, hooks ; profondeur et concurrence sous CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH.
11. MCP	claude mcp add, portées, .mcp.json commité ; prompts en /mcp__serveur__prompt, permissions mcp__serveur__outil.
12. Plugins	.claude-plugin/plugin.json empaquette skills, agents, hooks, MCP, LSP ; marketplaces publiques, communautaires ou privées.
13. Flux quotidien	Déléguer plutôt que dicter ; /plan, /code-review, /verify, PR, /autofix-pr.
14. Headless et CI	claude -p avec --allowedTools, --permission-mode, --output-format json ; @claude dans GitHub Actions ; Agent SDK.
15. Coûts et sécurité	Cache, /usage, injection via données lues, moindre privilège, settings gérés, ZDR.
16. Projet Kiosque	Arbre du dépôt final, sept étapes, démo de dix minutes, grille d'évaluation, variantes.

Les fils qui traversent le cours

Claude Code se configure comme un compilateur, pas comme un chatbot. Le pouvoir de l'outil vient de fichiers commités : CLAUDE.md, .claude/settings.json, .claude/skills/, .claude/agents/, .mcp.json, hooks, plugin, workflow. Toute décision prise en session sans être écrite dans un de ces fichiers sera perdue au prochain /clear — ou pire, appliquée par un coéquipier de manière incohérente. Le module 1 pose le décor, le module 16 assemble la palette ; entre les deux, chaque module ajoute un fichier.

Le prompt ne suffit jamais. Une injection dans une page lue passe à côté du meilleur prompt système du monde ; seul un PreToolUse déterministe la bloque. Une skill qui « n'oublie jamais » n'existe qu'à travers allowed-tools restrictif et disallowed-tools explicite. Un sous-agent qui « ne modifie pas les tests » n'existe qu'à travers un frontmatter sans Edit ni Write. Chaque garantie doit être imposée par le code de la configuration, pas par une phrase.

Le contexte est un budget mesurable, pas une ressource illimitée. /context, /compact, context: fork et les sous-agents servent tous à isoler ce qui est cher. Le cache de prompt est cassé par le moindre changement du prompt système, du CLAUDE.md ou du modèle : en avoir conscience change les décisions de conception d'un jour à l'autre. Le module 15 formalise ce que les modules 2 et 10 avaient déjà rendu visible.

La délégation exige des interfaces. Les skills sont des interfaces vers des workflows nommés, les sous-agents vers des rôles nommés, MCP vers des systèmes externes nommés, les plugins vers des équipes nommées. Concevoir un usage industriel de Claude Code revient à concevoir ces quatre types d'interfaces bien avant de peaufiner un prompt clever.

Liste de contrôle d'un dépôt qui a intégré Claude Code

• Un CLAUDE.md de moins de cent lignes, complété par des .claude/rules/*.md ciblés (paths: glob) et des skills invocables.
• Un .claude/settings.json avec permissions.deny explicite (.env, migrations/, Bash(rm -rf *), Bash(git push --force *)), permissions.allow pour les commandes de build, defaultMode non bypassPermissions.
• Au moins trois skills « boutons » (/commit, /revue, /tests-cibles ou équivalents) avec allowed-tools étroit ; les skills bavardes déléguées via context: fork.
• Deux sous-agents typés : un revieweur en lecture seule, un testeur avec droit d'exécuter la suite courte ; frontmatter cohérent avec leur rôle.
• Trois hooks minimum : PostToolUse de formatage, PreToolUse de protection des chemins critiques, Stop qui exige un test vert avant de rendre la main.
• Un .mcp.json commité qui déclare les serveurs stables (GitHub, base de données en lecture seule) ; les serveurs personnels restent en portée utilisateur.
• Un plugin qui empaquette skills, agents, hooks et MCP quand plusieurs dépôts partagent la même palette.
• Un workflow .github/workflows/claude.yml qui répond à @claude, avec --allowedTools et --permission-mode dontAsk ; jamais --dangerously-skip-permissions sur un runner non isolé.
• Un budget mensuel connu, alerté via /usage ou l'API, et un rituel de revue trimestrielle du CLAUDE.md, des règles et des skills.
• Un README interne qui explique en dix lignes comment démarrer : git clone, claude, /plugin install kiosque-tools, /init si le dépôt est neuf.

L'examen final

L'examen comporte 40 questions couvrant les seize modules : installation et surfaces, boucle et contexte, CLAUDE.md et mémoire, référence des commandes slash, création de skills, permissions et sandbox, plan et checkpoints, hooks, sous-agents et parallélisme, MCP, plugins, flux de travail, headless et Agent SDK, coûts et sécurité, projet d'équipe.

Plusieurs questions présentent des situations à diagnostiquer : quelle commande taper pour repartir d'une conversation propre sans perdre le projet ; quel frontmatter donne à une skill un contexte isolé ; quelle règle de permission bloque un git push --force sans casser un git push normal ; pourquoi un hook PostToolUse ne se déclenche pas ; pourquoi un sous-agent renvoie du texte sans avoir écrit de fichier. C'est le jugement qui est évalué — nommer le fichier de configuration à corriger, choisir la commande adaptée — pas la récitation d'un vocabulaire.

En cas de réussite, votre attestation d'achèvement est délivrée immédiatement ; son numéro est vérifiable par tout tiers sur la plateforme.

Avant de commencer

Reprenez la liste de contrôle ci-dessus. Pour chaque ligne, demandez-vous « saurais-je écrire le fichier qui garantit cette propriété ? ». Si vous savez rédiger un SKILL.md avec allowed-tools étroit, un sous-agent en lecture seule, un hook PreToolUse de protection et un .mcp.json de projet, vous êtes prêt. Bonne chance !

Examen final

Prêt à valider ce cours ?

40 questions tirées au hasard dans la banque du cours · seuil de réussite 70 % · certificat PDF vérifiable délivré immédiatement en cas de réussite.

Commencer l'examen

Connexion à votre compte InSkillML et abonnement actif requis. Vous pouvez aussi lancer l'examen depuis Mes cours.