Vous connaissez la scène : vous bricolez un docker-compose.yml, vous jonglez entre l’éditeur, un terminal, la doc dans le navigateur, et un chat IA dans un cinquième onglet où vous recollez pour la dixième fois le même bout de config en réexpliquant votre stack. Ça marche, mais ça fuit de partout : du copier-coller, du contexte perdu, et un assistant qui ne voit jamais vraiment votre projet.

L’extension Claude Code pour VS Code s’attaque exactement à ça : elle fait entrer l’assistant dans votre éditeur, avec accès à vos fichiers, à vos diffs et à votre terminal. On va voir ce qu’elle apporte concrètement, comment l’installer proprement, les bonnes pratiques qui font toute la différence, et — parce que c’est un blog honnête — la vraie limite pour qui vise le privacy-first.

Claude Code, l’extension : c’est quoi au juste ?

Première chose à clarifier, parce que le nom prête à confusion : Claude Code existe sous deux formes qui partagent le même moteur.

• Un CLI, à lancer dans un terminal avec la commande claude.
• Une extension VS Code, un panneau graphique intégré à l’éditeur. C’est la façon recommandée d’utiliser Claude Code dans VS Code.

Et ce n’est pas de l’autocomplétion à la Copilot qui complète vos lignes au fil de la frappe. C’est un outil agentique : vous décrivez une tâche (« ajoute une route Express pour lister les utilisateurs », « corrige ce bug de permissions sur le volume »), il lit le code concerné, planifie, édite plusieurs fichiers, lance des commandes, et vous rend un diff à relire avant que quoi que ce soit ne touche le disque.

Bon à savoir : l’extension embarque sa propre copie du CLI pour son panneau de chat. Vous n’avez donc rien à installer d’autre pour commencer à discuter avec elle.

Ce qu’il vous faut

• VS Code 1.98.0 ou plus récent (Aide → À propos pour vérifier).
• Un abonnement Claude payant (Pro, Max, Team ou Enterprise) ou un compte Claude Console. Le plan gratuit ne donne pas accès à Claude Code. Bonne nouvelle : pas besoin de clé API, vous vous connectez avec votre compte via le navigateur.
• L’extension s’installe aussi dans Cursor et les forks de VS Code (Devin Desktop, Kiro…), depuis le registre Open VSX si besoin.

Installation en deux minutes

Ouvrez la vue Extensions (Ctrl+Maj+X sous Windows/Linux, Cmd+Maj+X sous Mac), tapez « Claude Code », installez l’extension officielle d’Anthropic. Au premier lancement, cliquez sur l’icône Spark (l’étoile) dans la barre d’outils de l’éditeur, puis connectez-vous : un onglet de navigateur s’ouvre pour l’authentification, et c’est plié.

Piège — l’icône Spark n’apparaît pas. L’icône dans la barre d’outils de l’éditeur ne s’affiche que si un fichier est ouvert (un dossier seul ne suffit pas). Si elle manque toujours : vérifiez que vous êtes bien en VS Code 1.98+, puis lancez « Developer: Reload Window » depuis la palette de commandes (Ctrl+Maj+P). En dernier recours, l’entrée « ✱ Claude Code » en bas à droite dans la barre d’état fonctionne même sans fichier ouvert.

Piège — il vous redemande de vous connecter alors que ANTHROPIC_API_KEY est défini. Message typique : Not logged in · Please run /login. Cause classique : VS Code lancé depuis une icône n’a pas hérité de l’environnement de votre shell, donc il ne voit pas votre variable. La parade : fermez VS Code et relancez-le depuis un terminal avec code . (il hérite alors des variables). Ou, plus simple, connectez-vous directement avec votre compte Claude.

Si vous voulez aussi la commande claude dans le terminal intégré, sachez que l’extension n’ajoute pas claude au PATH : elle garde sa copie du CLI privée pour son panneau. Il faut alors installer le CLI en standalone.

Piège — claude: command not found dans le terminal. Normal : l’extension ne pose pas le binaire sur votre PATH. Installez le CLI standalone une bonne fois. Et si l’installation via npm renvoie une erreur de permissions, ne mettez pas de sudo : reconfigurez plutôt le préfixe npm vers un dossier qui vous appartient, avec npm config set prefix ~/.npm-global, puis ajoutez ~/.npm-global/bin à votre PATH.

Les bienfaits concrets (ce que ça change vraiment)

Au-delà de l’effet « waouh », voici ce qui fait gagner du temps au quotidien.

Le diff en ligne, relu avant d’écrire. Quand Claude veut modifier un fichier, il affiche une comparaison côte à côte et attend votre feu vert. Vous acceptez, refusez, ou lui dites de reprendre autrement. Sur un refactor qui touche quinze fichiers, relire chaque diff dans son onglet plutôt que de faire défiler du texte coloré dans un terminal, c’est la différence entre attraper une erreur et tamponner une modif que vous étiez trop fatigué pour lire.

Les @-mentions ciblées. Tapez @ suivi d’un nom de fichier (avec du fuzzy matching : @auth retrouve authService.js), ou sélectionnez des lignes et faites Alt+K (Option+K sur Mac) pour insérer une référence précise du type @app.js#5-10. Fini le copier-coller de pavés : vous pointez, il lit.

Le terminal comme contexte. Référencez la sortie d’un terminal avec @terminal:nom pour que Claude voie vos logs ou votre message d’erreur sans que vous ayez à les recopier. Idéal quand un conteneur crache une stack trace.

Les checkpoints. L’extension trace les éditions de Claude et permet de rembobiner. Survolez un message, cliquez sur « rewind », et revenez à un état antérieur du code — un filet de sécurité appréciable quand une piste part de travers.

Plusieurs conversations en parallèle. Ouvrez des sessions dans des onglets distincts, chacune avec son propre contexte, pour mener deux tâches de front.

L’intégration git. Demandez-lui de committer avec un message descriptif, de préparer une pull request, de résumer vos changements sur un module. Les descriptions de PR sont générées à partir des vraies modifs.

Le navigateur, pour tester vos apps web. Avec @browser, Claude pilote Chrome pour tester votre front, lire la console, repérer les erreurs — pratique pour un front Vue en dev sur localhost. Ça nécessite l’extension Claude in Chrome en version 1.0.36 ou plus.

Les bonnes pratiques (le vrai cœur du sujet)

L’extension bien utilisée, ce n’est pas une histoire de prompts malins : ce sont les rails que vous posez autour de l’agent.

CLAUDE.md : le fichier qui change tout

CLAUDE.md est un fichier spécial que Claude lit au début de chaque conversation. Vous y mettez le contexte qu’il ne peut pas deviner du code seul : les commandes du projet, les conventions, le workflow. Lancez /init dans le panneau pour qu’il en génère une première version en analysant votre dépôt, puis affinez.

La règle d’or, contre-intuitive : plus c’est court, mieux c’est. Un CLAUDE.md obèse fait que Claude finit par ignorer vos instructions, noyées dans le bruit. Visez le concret et l’utile, et pour chaque ligne demandez-vous : « est-ce que la retirer ferait faire une erreur à Claude ? » Si non, elle dégage. Un exemple taillé pour une stack maison typique :

# Projet : mon-app

Stack : Vue 3 + Vite (front), Node/Express (back), MariaDB, Docker, Traefik.
Pas de TypeScript. Commentaires en français.

## Commandes
- Dev front : npm run dev
- Build     : npm run build
- Lint      : npm run lint
- Tests     : npm test

## Conventions
- MariaDB : accès UNIQUEMENT via procédures stockées, jamais de SQL inline.
- Le moins de dépendances possible.
- Déploiement : image Docker poussée sur le NAS via Gitea Actions.

Astuce. La section la plus rentable, de loin, c’est celle des commandes. Sans elle, Claude tentera un npm test là où vous utilisez autre chose, et gaspillera trois tours à déboguer une commande qui n’avait aucune chance de marcher. Ne mettez pas non plus vos règles de formatage ici : laissez ce boulot à ESLint/Prettier, qui le font instantanément et sans faillir.

Piège — Claude ignore une de vos règles. Neuf fois sur dix, le fichier est trop long et la règle se perd dans le contexte. Élaguez sans pitié. Traitez CLAUDE.md comme du code : relisez-le quand ça déraille, versionnez-le dans Git pour que toute l’équipe (ou le futur vous) parte sur les mêmes bases.

Le mode Plan avant de laisser écrire

Pour toute tâche qui touche plus de deux ou trois fichiers, passez en mode Plan : Claude décrit ce qu’il compte faire et attend votre validation avant de modifier quoi que ce soit. VS Code ouvre même le plan comme un document Markdown où vous pouvez annoter en ligne pour le corriger avant qu’il ne se lance. C’est le garde-fou qui empêche l’agent de résoudre le mauvais problème à pleine vitesse.

Vérifier, ne jamais faire confiance à l’aveugle

L’extension propose plusieurs modes de permission, réglables via l’indicateur en bas de la zone de saisie :

• Manual (par défaut) : il demande avant chaque action. Le bon réflexe pour découvrir.
• Edit automatically (acceptEdits) : il édite sans redemander à chaque fois. Confortable une fois que vous faites confiance à la direction prise.
• Bypass permissions : plus aucun garde-fou. À réserver strictement à un bac à sable coupé d’Internet.

Quel que soit le mode : relisez le diff, lancez le code. Une modif plausible mais jamais exécutée, c’est le meilleur moyen d’expédier un bug en production.

Cloisonner les permissions (surtout sur un dépôt sensible)

Sur un repo où traînent des identifiants ou des secrets, ne lâchez pas l’agent en liberté. Un fichier .claude/settings.json à la racine du projet vous laisse définir des règles d’autorisation et d’interdiction, partagées avec vos collaborateurs :

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

Une règle deny sur un .env empêche non seulement sa lecture, mais aussi que son contenu remonte via une sélection dans l’éditeur. Pour du code vraiment sensible, activez le mode restreint de VS Code et restez en validation manuelle.

Scoper le contexte

Ne demandez pas à l’agent « d’aller explorer » sans bornes : il lira des centaines de fichiers et saturera son contexte. Cadrez la tâche, pointez les bons fichiers avec les @-mentions. Et entre deux tâches sans rapport, faites /clear pour repartir propre — une session fraîche avec un prompt affûté bat presque toujours une longue session encombrée de tentatives ratées. Quand le contexte se remplit, /compact le condense en gardant l’essentiel.

MCP : brancher Claude sur vos vrais outils

Les serveurs MCP (Model Context Protocol) donnent à Claude accès à des outils, bases de données et API externes. On les ajoute depuis le terminal intégré avec claude mcp add, puis on les gère sans quitter VS Code en tapant /mcp dans le panneau. De quoi, par exemple, lui donner la main sur un dépôt distant ou un service de votre infra — à condition d’y aller avec la même prudence que pour les permissions.

La question qui fâche : et la vie privée dans tout ça ?

Soyons honnêtes, parce que c’est la ligne éditoriale de ce blog et que ça compte quand on est privacy-first : Claude Code n’est pas auto-hébergeable. C’est un service propriétaire qui envoie le code sur lequel il travaille vers les serveurs d’Anthropic. C’est une dépendance externe, assumez-la comme telle.

Ce que dit Anthropic, et qui est vérifiable dans sa doc : votre code sert à vous aider, pas à entraîner les modèles, et les comptes personnels peuvent désactiver la journalisation des données dans les réglages. C’est une garantie qui vaut ce que vaut la confiance qu’on accorde à un tiers — ni plus, ni moins.

La posture raisonnable pour un homelab soucieux de sa confidentialité : soyez délibéré. Ne pointez pas l’agent sur des dépôts truffés de secrets, verrouillez les .env avec des règles deny, gardez en tête ce qui quitte votre machine. L’outil est puissant et fait gagner un temps fou ; il ne dispense pas de réfléchir à ce qu’on lui expose.

Conclusion

L’extension Claude Code, ce n’est pas un gadget d’autocomplétion de plus : c’est un agent qui voit votre projet, propose des diffs relisables, et s’intègre à git et à votre terminal. Les bienfaits sont réels — moins de zapping entre fenêtres, moins de copier-coller, un vrai second regard sur vos modifs. Mais tout tient dans les rails que vous posez : un CLAUDE.md court et précis, le mode Plan avant d’écrire, des permissions cloisonnées, et le réflexe de toujours relire le diff. Le reste, c’est de l’expérience qui vient en l’utilisant.

Pour aller plus loin

• Faites-lui rédiger et déboguer vos stacks : un bon CLAUDE.md et un « écris-moi un docker-compose.yml pour tel service, réseau traefik-public, restart unless-stopped » donnent un résultat prêt à relire. Si vous voulez d’abord maîtriser le vocabulaire pour juger ce qu’il vous rend, (re)passez par le guide Docker de A à Z.
• Explorez les skills et les hooks pour automatiser vos conventions et déclencher des scripts à des moments clés d’une session.
• Testez les sous-agents pour faire relire un diff par une seconde instance qui ne signale que les vrais écarts de correctness — sans partir en sur-ingénierie.
• Branchez un serveur MCP sur les outils de votre infra pour sortir Claude du simple périmètre du code.