Tech • IA • Robotique • Jeu
Claude Code : les 14 outils à maîtriser (cours complet)
7/10INTRO
Claude Code est le plus efficace lorsqu’il est utilisé comme un système de codage agentique avec des permissions strictes, un contexte maîtrisé, des étapes de vérification et des extensions spécialisées, plutôt que comme une simple interface de chat.
POINTS CLÉS
Du chat à la boucle agentique
Claude Code fonctionne via une boucle agentique: il rassemble le contexte, modifie des fichiers, exécute des contrôles et itère jusqu’à résoudre une tâche. En pratique, une demande comme corriger un bouton de connexion cassé ou des tests de panier en échec peut déclencher automatiquement des recherches de fichiers, des modifications de code et l’exécution de tests. Le modèle n’est qu’une partie du système; les performances dépendent aussi du harness qui l’entoure, notamment le contexte, les instructions, les outils, les permissions, la vérification et la boucle elle-même.
Les permissions sont la première couche de sécurité
Des restrictions durables doivent être définies dans .cloudsettings.json, et pas seulement dans CLAUDE.md. Une instruction écrite comme « ne jamais lire.env » peut être ignorée, mais une règle de permission peut bloquer l’accès de façon déterministe. La hiérarchie est importante: deny l’emporte sur allow et ask, tandis que ask peut encore imposer une confirmation avant des actions comme git commit.
Les modes d’exécution varient fortement en niveau de risque
Le mode Manual autorise la lecture, mais exige une validation pour la plupart des autres actions. Accepted edits permet de modifier des fichiers, plan explore sans changer les fichiers, et auto s’appuie sur un classificateur pour filtrer les actions. Même ainsi, environ 1 sur 6 actions dangereuses peuvent encore passer, ce qui rend le mode bypass particulièrement risqué hors d’environnements strictement contrôlés.
Git reste le véritable système de retour arrière
Les checkpoints intégrés peuvent annuler des modifications de fichiers dans une session via des commandes comme /rewind ou un double Escape, mais ils ne remplacent pas Git. Ils peuvent échouer à récupérer des commandes shell destructrices comme rm -rf ou du travail effectué par des sous-agents. Un historique permanent, nommé et partageable dépend toujours des commits et des branches.
Le contexte peut aider ou détériorer les résultats
Le contexte est la mémoire de travail du modèle, et lorsque celui-ci devient trop rempli, la précision peut baisser. Un seuil pratique se situe autour de 50 % à 70 % d’utilisation, bien avant des niveaux quasi saturés comme 95,5 % d’une fenêtre de 1 million de tokens. Des commandes comme /clear et /compact sont essentielles, car d’anciennes instructions peuvent déborder sur un nouveau travail, par exemple une demande précédente de « grandes cartes bleues » influençant la conception d’une page de factures sans rapport.
Les règles de session ont leur place dans CLAUDE.md ou AGENTS.md
Des fichiers comme CLAUDE.md ou AGENTS.md préchargent des consignes au début de chaque session, ce qui les rend utiles pour des habitudes comme toujours utiliser pnpm plutôt que npm. Mais ce ne sont pas des outils d’application déterministe, et les surcharger réduit leur utilité. L’approche recommandée est de les garder courts, idéalement sous 200 lignes, centrés sur des conventions stables du projet plutôt que sur des conseils vagues.
La vérification doit produire des preuves
Une compilation réussie ne suffit pas à prouver qu’une fonctionnalité fonctionne. Une vérification efficace inclut des tests automatisés, des contrôles dans le navigateur, des captures d’écran et des résultats visibles avant/après. Les flux de vérification intégrés peuvent lancer l’application, cliquer à travers les actions et repérer des échecs comme un bouton « add to cart » qui laisse le compteur inchangé.
Le choix du modèle et l’effort doivent correspondre à la tâche
Des modèles légers comme Haiku 5.5 conviennent à un travail répétitif ou simple, tandis que Sonnet couvre la plupart des tâches de codage quotidiennes. Opus et Fable 5.1 sont à réserver de préférence à l’architecture, au raisonnement en plusieurs étapes et aux problèmes longs ambigus, car ils sont plus lents et plus coûteux. La même logique s’applique à l’effort de raisonnement: corriger une faute de frappe ne justifie pas un effort maximal sur un modèle haut de gamme.
Skills, MCP et hooks étendent les capacités
Les Skills encapsulent un savoir-faire réutilisable, comme rédiger des pages produit ou exécuter un flux de vérification standard, et ne sont chargées que lorsqu’elles sont pertinentes. MCP agit comme un connecteur universel, reliant l’agent de codage à des outils comme GitHub, Slack, des bases de données ou Figma. Les hooks diffèrent des fichiers de consignes, car ils sont déterministes: si un formateur doit s’exécuter après chaque modification, un hook post-tool-use peut l’imposer à chaque fois.
Les sous-agents et les sessions parallèles aident à passer à l’échelle
Les sous-agents isolent une investigation lourde dans leur propre contexte et ne renvoient qu’un résumé, ce qui allège la session principale. Les sessions parallèles peuvent accélérer la livraison de tâches comme des pages contact, FAQ et mentions légales, mais elles augmentent aussi la consommation et le risque de conflits. L’utilisation de Git worktrees séparés donne à chaque session sa propre branche et évite que plusieurs agents n’écrasent les mêmes fichiers.
CONCLUSION
Le principal défi avec Claude Code n’est pas de rédiger de meilleurs prompts, mais de construire le bon cadre opérationnel autour de lui. Les équipes qui contrôlent les permissions, gèrent le contexte, vérifient les résultats et utilisent les extensions avec discernement peuvent gagner en vitesse sans sacrifier la sécurité.
Poser une question