Claude Code : les 14 outils à maîtriser (cours complet)

La plupart des utilisateurs de Cloud Code se limitent à son utilisation en tant que simple chatbot, négligeant ainsi son potentiel réel. Cette vidéo vise à présenter 14 outils de Cloud Code qui font la différence, en commençant par les plus fondamentaux pour aller vers les plus avancés, dans le but de rendre ces concepts accessibles à tous, même aux novices en codage. Le créateur, Ben, fort de son expérience en développement pour startups, ESN, agences de communication, et en cybersécurité, ainsi que de sa formation de plus de 300 apprenants au développement et à des outils comme Cloud Code et Alia, propose un plan structuré : comprendre la machine, garder le contrôle, guider Cloud Code, étendre ses pouvoirs, et enfin, passer à l'échelle. L'ordre est crucial, privilégiant d'abord la protection, puis le guidage, et enfin l'extension des capacités. La première étape consiste à comprendre le concept de "boucle agentique" et le fonctionnement de Cloud Code. Il ne s'agit plus seulement du modèle d'IA seul, mais d'un ensemble plus large appelé "harnais" (harness). Ce harnais englobe le modèle (le moteur) et des éléments périphériques qui lui permettent d'agir (la voiture avec volant, pédales, etc., et même l'utilisateur avec ses yeux, mains, règles et méthode). Les benchmarks récents démontrent que la qualité du harnais améliore considérablement les performances. Contrairement à un simple chat où l'utilisateur doit identifier et corriger le code lui-même, Cloud Code, grâce à son harnais, peut chercher, lire, modifier et tester le code de manière autonome jusqu'à ce que la demande soit satisfaite. Les six composantes du harnais sont : 1. **Le Contexte :** Ce que Cloud Code "voit". 2. **Les Instructions :** Ce que Cloud Code doit savoir à chaque session. 3. **Les Outils :** Ce que Cloud Code est capable de faire. 4. **Les Permissions :** Ce que Cloud Code peut faire sans demander la permission. 5. **Les Vérifications :** Comment Cloud Code sait qu'il a terminé sa tâche. 6. **La Boucle :** Comment Cloud Code enchaîne les actions et gère les échecs. L'échec n'est plus seulement imputable au modèle, mais peut venir d'un dysfonctionnement du harnais. La boucle agentique est illustrée par un exemple : corriger les tests échoués du panier sur un site e-commerce. Cloud Code rassemble le contexte, identifie le problème (par exemple, un affichage des prix en centimes au lieu d'euros), modifie le code, puis lance des tests pour vérifier la correction. L'utilisateur fait partie intégrante de cette boucle, pouvant l'interrompre à tout moment. Le deuxième chapitre, "Garder le contrôle", aborde les permissions, les "guits" (probablement une référence aux commandes Git, bien que le terme ne soit pas explicitement défini dans ce contexte), et le contexte. **Les Permissions** sont fondamentales. Elles définissent ce que Cloud Code a le droit de faire sans intervention humaine. Il est crucial de comprendre que les règles définies dans `.cloud.md` ne sont pas toujours déterministes. Pour une sécurité absolue, il faut utiliser le fichier `.cloudsettings.json` où les permissions sont des règles contraignantes que Cloud Code est obligé d'appliquer. Les modes de fonctionnement de Cloud Code sont : * **Manual :** Seules les lectures sont autorisées ; tout le reste nécessite une validation. * **Accepted Edits :** Les modifications de fichiers sont autorisées après validation. * **Plan :** Cloud Code propose un plan d'action sans modifier le projet. * **Auto :** Un "classifier" examine chaque action avant son exécution, mais une action sur six peut encore être dangereuse. * **Bypass :** Tout est autorisé sans demande, ce mode est extrêmement dangereux et à n'utiliser que dans des environnements maîtrisés. Dans `.cloudsettings.json`, on peut définir des autorisations (`allow`), des interdictions (`deny`) et demander une confirmation (`ask`). L'ordre de priorité est : `deny` > `allow` > `ask`. Par exemple, interdire la lecture des fichiers `.env` est une mesure de sécurité essentielle. **Git et les Checkpoints** servent de filet de sécurité pour revenir en arrière. Git permet de prendre des "snapshots" du projet à différents instants. Si des modifications entraînent des problèmes, il est possible de revenir à un état antérieur. Cloud Code a introduit un système de "checkpoints" automatiques pour annuler rapidement des modifications dans une session, mais ceux-ci ne remplacent pas Git pour des actions destructrices comme la suppression de fichiers (`rm -rf`) ou la gestion de sous-agents multiples. Git est plus robuste pour les sauvegardes permanentes et partageables. **Le Contexte** est la mémoire de travail de Cloud Code. Au démarrage, un contexte est injecté, comprenant des analyses de fichiers et des sorties de commandes. Les modèles comme Opus 5.5 disposent d'un immense espace de tokens (1 million), mais il est souvent nécessaire de "compacter" ce contexte (idéalement entre 50% et 70%) pour éviter que le modèle ne devienne moins précis à cause du "bruit". Le slash `compact` permet de résumer le travail effectué, mais il est conseillé d'ajouter des précisions textuelles pour indiquer les éléments importants à conserver. Il est crucial de comprendre que ce qui n'est pas dans le contexte n'existe pas pour Cloud Code. Le slash `clear` est présenté comme une commande sous-estimée, permettant de réinitialiser le contexte pour une nouvelle tâche ou session, évitant ainsi la pollution par des informations antérieures. Le slash `clear new task new session` et `compact` sont des outils essentiels, ainsi que `context` pour visualiser la jauge de contexte. Le chapitre "Guider Cloud Code" aborde le fichier `.cloud.md` (ou `agents.md` dans les versions plus récentes) et la vérification du travail. **Le fichier `.cloud.md` (ou `agents.md`)** injecte des instructions et des informations au début de chaque session. Il est important de ne pas surcharger ce fichier (idéalement moins de 200 lignes) car il est lu en entier à chaque requête. Les instructions trop vagues comme "pense à bien tester" sont inutiles. Les interdictions de sécurité absolue ne devraient pas être placées dans `.cloud.md`, mais plutôt dans les permissions de `.cloudsettings.json`. **La vérification du travail** est essentielle car une compilation réussie ne garantit pas le bon fonctionnement. Le skill `verify` intégré à Cloud Code permet de lancer l'application et de simuler des interactions utilisateur pour détecter des problèmes. Il est recommandé d'exiger des preuves tangibles (sorties de tests, captures d'écran) plutôt que de simples affirmations de la part de Cloud Code. La section sur les **modèles** et l'**effort** compare différents modèles (Sonnet, Opus, Claude 3.5 Sonnet, Claude 3 Opus, Claude 3 Haiku) en fonction de leur puissance, vitesse et coût, et explique comment ajuster l'effort (niveau de réflexion) en fonction de la tâche pour optimiser les résultats et la consommation de tokens. Par exemple, utiliser un modèle puissant comme Opus pour une tâche simple est contre-productif. Le chapitre "Étendre ses pouvoirs" présente les **skills**, les **MCP** (Model, Context, Protocol), les **hooks** et les **sous-agents**. * Les **skills** sont des recettes de cuisine pour des tâches répétitives. Ils doivent être précis dans leur description pour que Cloud Code puisse les identifier et les utiliser. Un skill est chargé dans le contexte uniquement lorsqu'il est nécessaire. * Les **MCP** sont des standards ouverts permettant de connecter Cloud Code à des outils externes (Gmail, GitHub, Notion, etc.), un peu comme l'USB pour les appareils. MCP fournit l'accès, tandis que le skill fournit la méthode. * Les **hooks** sont des actions déterministes qui doivent se produire à chaque fois, contrairement aux instructions dans `.cloud.md` qui sont moins fiables. Ils peuvent être déclenchés à différents moments (démarrage, avant/après utilisation d'un outil, etc.) et sont cruciaux pour la sécurité, par exemple en filtrant les installations de paquets. * Les **sous-agents** sont des "collègues" spécialisés qui opèrent dans leur propre contexte. Leur principal avantage est de ne pas polluer le contexte de la session principale, le gardant ainsi léger. Ils renvoient uniquement un résumé de leur travail à la session principale. Enfin, le chapitre "Passer à l'échelle" introduit les **artifacts**, les **sessions parallèles** et les **plugins**. * Les **artifacts** permettent de présenter les résultats de manière visuelle et représentative, plutôt que sous forme textuelle. Ils sont privés jusqu'à leur partage et peuvent être utiles pour des plans ou des représentations graphiques. Cependant, la beauté visuelle ne garantit pas l'exactitude du contenu. * Les **sessions parallèles** permettent d'exécuter plusieurs tâches simultanément, ce qui accélère le travail global mais augmente la consommation de ressources. L'utilisation de "work trees" est recommandée pour éviter les conflits lorsque plusieurs sessions travaillent sur les mêmes fichiers, chaque session ayant sa propre branche Git. * Les **plugins** sont des paquets qui regroupent des compétences précédemment vues (skills, sous-agents, hooks, MCP). Ils permettent d'organiser et de déployer des ensembles de fonctionnalités. Il faut être prudent avec les plugins car ils s'exécutent avec les droits de l'utilisateur. La vidéo se conclut par une invitation à approfondir ces notions via une formation complète, incluant des leçons détaillées sur chaque outil, des projets pratiques, et un accompagnement personnalisé.