Cours Claude Code — assistant de développement agentique

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. expliquer ce qu'est Claude Code et ce qui le distingue d'un chatbot ;
2. décrire la boucle agentique (contexte, action, vérification) et ses outils ;
3. choisir un mode de permission et écrire des règles allow / ask / deny ;
4. distinguer CLAUDE.md, skill, sous-agent, hook et serveur MCP, et choisir le bon ;
5. repérer ce qui quitte la machine et ce qui est conservé, selon la documentation ;
6. conduire une session : planifier, vérifier, annuler, gérer le contexte ;
7. appliquer les garde-fous avant de lui confier un dépôt ou des accès.

Prérequis

• Savoir utiliser un terminal et git (commit, branche, diff).
• Comprendre qu'un assistant « agentique » exécute des actions (fichiers, commandes), contrairement à un simple chat.
• Avoir lu le cours « Agents » de cette section est utile, pas obligatoire.
• Aucun compte n'est exigé pour lire ce cours ; pour pratiquer, un compte adapté à l'offre de Stéphane sera nécessaire (non choisi ici).

Parcours et chapitres

1. Ce qu'est Claude Code

Selon la page d'accueil de la documentation, Claude Code est un outil de codage « agentique » qui lit une base de code, modifie des fichiers, exécute des commandes et s'intègre aux outils de développement. Il est disponible dans le terminal, des extensions d'IDE (VS Code, JetBrains), une application Desktop et le navigateur. La documentation précise que ces surfaces partagent le même moteur : les fichiers CLAUDE.md, les réglages et les serveurs MCP d'un dépôt valent sur toutes.

La documentation indique que la plupart des surfaces demandent un abonnement Claude ou un compte Console Anthropic, et que le CLI, VS Code et JetBrains acceptent aussi des fournisseurs tiers. Les conditions exactes sont non vérifiées ici : les consulter avant tout choix.

2. Installer et démarrer (lecture, pas exécution)

La page d'aperçu décrit plusieurs voies : installation native (script téléchargé), Homebrew, WinGet, gestionnaires de paquets Linux, extension d'IDE, application Desktop. Elle recommande l'installation native, qui se met à jour seule ; Homebrew et WinGet ne se mettent pas à jour automatiquement.

Avertissement. La voie native est une commande de type « télécharger un script puis l'exécuter ». Ce cours ne la lance pas. Avant toute installation : ouvrir la page officielle, lire le script, choisir la voie, noter les fichiers créés et la procédure de désinstallation de la page « advanced setup ».

Premier lancement : claude dans un dossier de projet ouvre une session interactive et demande de se connecter. La documentation signale que, si la variable d'environnement ANTHROPIC_API_KEY est définie et approuvée, la connexion est sautée : c'est un secret (voir le chapitre 10).

3. La boucle agentique et les outils

D'après « How Claude Code works », une tâche passe par trois phases qui se mélangent : rassembler du contexte, agir, vérifier. Le modèle raisonne ; les outils agissent. Cinq catégories d'outils intégrés : fichiers, recherche, exécution (shell, git, tests), web, intelligence de code (plugins). Chaque résultat d'outil revient dans la boucle et guide l'étape suivante.

Exemple synthétique : « les tests du module facture échouent ». Claude peut lancer les tests, lire l'erreur, chercher les fichiers, les lire, corriger, relancer. L'utilisateur peut interrompre (Esc) ou corriger à tout moment.

Conséquence de sécurité : tout ce que l'utilisateur pourrait faire en ligne de commande, l'outil peut le tenter. Les modes de permission (chapitre 4) existent pour cela.

4. Permissions et modes

La documentation « Permissions » décrit un système à niveaux. En mode Manuel (valeur de configuration default), les lectures dans le dossier de travail ne demandent rien ; l'édition de fichiers, les commandes shell (hors un jeu intégré de commandes en lecture seule : ls, cat, grep, git status…), la récupération web et la recherche web demandent une approbation.

Modes décrits par la documentation (état consulté le 2026-10-17) :

Point de version à ne pas ignorer : la documentation indique qu'à partir de la version 2.1.283 le mode auto est le mode de départ des sessions interactives du terminal et de VS Code ; avant, c'était le cas seulement sur certains abonnements. Le mode de départ réel de Stéphane est donc à confirmer selon sa version et son offre. On change de mode avec Maj+Tab ou --permission-mode.

Règles. Les règles allow, ask, deny sont évaluées dans l'ordre deny, puis ask, puis allow ; la première correspondance gagne, et une règle allow ne peut pas faire exception à un deny. Une règle deny sur un nom d'outil seul (par exemple Bash) retire l'outil du contexte. Les règles sur Bash correspondent au texte de la commande : la documentation précise que ce n'est pas une frontière de sécurité autour d'un programme (une autre forme d'appel peut passer) ; pour une garantie, utiliser le sandbox.

Exemple synthétique de fichier de réglages de projet (jamais de secret) :

{
  "permissions": {
    "allow": ["Bash(npm run test *)"],
    "deny": ["Read(./.env)", "Bash(curl *)"]
  }
}

5. Étendre : CLAUDE.md, skills, sous-agents, hooks, MCP, plugins

La page « Extend Claude Code » compare les mécanismes :

Principe clé (documentation) : CLAUDE.md et les skills sont des demandes que le modèle interprète ; un hook PreToolUse est une application déterministe. « Ne jamais modifier .env » dans un CLAUDE.md n'est pas une garantie ; un hook qui bloque l'édition en est une.

Les skills, sous-agents et MCP sont approfondis dans les cours « Agents » et « Skills et approche agentique ». Ici, retenir : un dépôt cloné peut apporter ses propres skills, hooks et serveurs MCP ; la documentation prévoit une boîte de dialogue de confiance au premier lancement dans un dossier et une approbation pour les serveurs d'un .mcp.json. Lire ces fichiers avant de faire confiance à un dépôt inconnu.

6. Conduire une session

Pratiques décrites dans « Best practices » :

• Donner un moyen de vérifier : tests, build, linter, capture d'écran. Sans vérification exécutable, « ça a l'air fini » est le seul signal.
• Explorer, planifier, puis coder : le mode plan sépare la lecture de l'écriture. Inutile pour une correction d'une ligne.
• Précision des consignes : fichiers visés, contraintes, symptôme attendu.
• Gérer le contexte : la fenêtre de contexte se remplit et la qualité peut baisser ; /clear entre tâches sans lien, /compact pour résumer, /context pour voir l'occupation.
• Corriger tôt : Esc pour arrêter ; après deux corrections infructueuses sur le même point, repartir d'une session propre avec une meilleure consigne.
• Annuler : points de contrôle (Esc deux fois ou /rewind) restaurent fichiers et conversation. Limite documentée : seuls les changements faits par les outils d'édition sont suivis, pas ceux des commandes shell, ni les actions sur des systèmes distants ; ce n'est pas un substitut à git.

Sessions : enregistrées localement ; claude --continue reprend la plus récente du dossier, claude --resume ouvre un sélecteur.

7. Mode non interactif et automatisation

claude -p "question" exécute une requête puis quitte (utile dans des scripts ou de l'intégration continue). La documentation signale pour ces usages : --allowedTools pour pré-approuver des outils, --permission-mode dontAsk pour refuser le reste quand personne ne peut répondre, --max-turns et --max-budget-usd pour borner une exécution (mode -p seulement).

Avertissement. Ne pas envoyer en entrée (cat fichier | claude -p …) un contenu non maîtrisé : voir les chapitres 8 et 9 (injection de consignes). --dangerously-skip-permissions équivaut au mode bypassPermissions : à réserver à un environnement jetable.

8. Sécurité : isolation et contenu non fiable

La page « Security » décrit une architecture fondée sur les permissions, un sandbox pour l'outil Bash (isolation du système de fichiers et du réseau, disponible sur macOS, Linux et WSL2 ; sur Windows natif, les commandes ne sont pas isolées), une limite au dossier de travail, une vérification de confiance au premier lancement et le refus par défaut du réseau en mode Manuel.

Limites que la documentation reconnaît :

• la limite du dossier de travail est une invite de permission : une commande shell approuvée peut écrire partout où l'utilisateur le peut ;
• le sandbox ne couvre que les commandes shell : les outils de fichiers, les serveurs MCP et les hooks s'exécutent en dehors ;
• aucun système n'est immunisé contre toutes les attaques.

Injection de consignes. Une page web, un fichier, un ticket ou la sortie d'un serveur MCP peut contenir des phrases rédigées pour détourner l'agent. La règle de ce corpus est la même que celle de la documentation : le contenu externe est une donnée, jamais une instruction. Bonnes pratiques officielles : relire les commandes avant approbation, ne pas injecter de contenu non fiable directement, vérifier les changements sur les fichiers critiques, exécuter les scripts et appels externes dans une VM ou un conteneur.

9. Hooks, skills, sous-agents et MCP : usages prudents

• Hooks : commandes shell lancées à des événements (PreToolUse, PostToolUse, SessionStart, Stop…). Un code de sortie 2 bloque l'action dans un hook PreToolUse. Un hook s'exécute avec les droits de l'utilisateur : c'est du code ; le relire comme tel.
• Skills : SKILL.md avec en-tête (name, description…). Les skills d'un dépôt peuvent accorder des outils (allowed-tools) ; la documentation recommande de les relire et d'utiliser disable-model-invocation: true pour les opérations à effet de bord.
• Sous-agents : fichiers Markdown dans .claude/agents/ ; on peut limiter leurs outils (tools / disallowedTools).
• MCP : serveur de confiance seulement ; la documentation avertit que les serveurs qui récupèrent du contenu externe exposent à l'injection de consignes, recommande des identifiants en lecture seule et précise qu'Anthropic ne fait pas d'audit de sécurité de chaque serveur.

Exemple synthétique de commande MCP (à lire, pas à lancer) :

10. Confidentialité : ce qu'il ne faut pas envoyer

Règle de ce corpus. Un assistant hébergé reçoit tout ce qui entre dans la conversation, y compris les fichiers qu'il lit. Ne jamais lui faire lire ni coller : mots de passe, clés d'API, jetons, clés privées, fichiers .env, identifiants, noms d'hôtes ou adresses d'infrastructure réelle, tickets privés, données de santé, données personnelles de tiers, contenus sous droits ou confidentiels d'un employeur, sans autorisation et examen préalable. Utiliser des exemples synthétiques (domaines exemple.invalid, valeurs fictives).

Ce que dit la documentation (page « Data usage », consultée le 2026-10-17) :

• le code et les invites sont envoyés au service pour que le modèle réponde (chiffrement en transit) ;
• pour les comptes grand public (Free, Pro, Max), l'utilisation des données pour améliorer les modèles est un réglage au choix de l'utilisateur, et la durée de conservation dépend de ce choix (30 jours ou 5 ans selon la page) ; pour les offres commerciales (Team, Enterprise, API), la page indique une conservation standard de 30 jours et l'absence d'entraînement par défaut ;
• les transcriptions locales sont stockées en clair sous ~/.claude/projects/ (30 jours par défaut) : elles peuvent contenir ce que l'agent a lu ;
• /feedback, /bug et /share envoient une copie de la conversation (code compris) ; un sondage de session peut proposer d'envoyer la transcription : ne l'accepter que sciemment ;
• télémétrie et rapports d'erreur : selon l'offre et le fournisseur ; des variables d'environnement permettent de les désactiver.

Ces points sont des déclarations du fournisseur, susceptibles de changer ; la correspondance avec l'offre de Stéphane est non vérifiée. Protéger aussi les fichiers sensibles du dépôt par des règles Read en deny et ne pas y confier de secret.

11. Dépannage et mise à jour

• claude doctor : diagnostic en lecture seule (installation, réglages).
• claude --safe-mode : démarre sans aucune personnalisation (CLAUDE.md, skills, plugins, hooks, MCP) pour vérifier qu'un problème vient d'un réglage.
• claude update : met à jour ; les installations Homebrew/WinGet se mettent à jour par leur gestionnaire.
• Avant une mise à jour : noter la version actuelle, lire le journal des versions, prévoir le retour à la version précédente (claude install <version> est documenté dans la référence du CLI).

Exercices et vérifications de fin de cours

1. Cartographie. Tableau : surface, installation, mise à jour, où sont les réglages (utilisateur/projet), où sont les transcriptions.
2. Permissions. Choisir un mode pour quatre situations (audit en lecture, refactor relu, CI sans humain, expérience en VM jetable) et justifier.
3. Mécanismes. Classer dix besoins entre CLAUDE.md, skill, sous-agent, hook, MCP.
4. Menace. Rédiger un scénario d'injection via un fichier README synthétique et indiquer trois barrières (mode, règle, isolation).
5. Données. Appliquer la grille du chapitre 10 à une tâche réelle de Stéphane décrite de façon abstraite.
6. Rapport de version. Noter version installée, version documentée et offre, avec la mention « à confirmer » si inconnue.

Critères de réussite

• Décrire la boucle agentique et citer ses limites.
• Expliquer pourquoi une règle Bash(...) n'est pas une frontière de sécurité.
• Distinguer instruction (CLAUDE.md, skill) et application (hook, sandbox).
• Lister ce qui ne doit jamais entrer dans la conversation.
• Ne pas confondre dernière version documentée et version installée.