Publication de Claude Code pour VSCode

• Extension qui intègre Claude Code d’Anthropic à VSCode afin d’améliorer l’expérience de développement des programmeurs
• Fonctionne uniquement si Claude Code est installé séparément

Fonctionnalités principales

• Installation automatique : si vous exécutez Claude Code dans le terminal de VSCode, l’extension est automatiquement détectée et installée
• Prise en compte du contexte de la sélection : le texte sélectionné dans l’éditeur est automatiquement inclus dans le contexte d’entrée de Claude
• Prise en charge de la vue Diff : il est possible de consulter directement les modifications de code (diff) dans la visionneuse intégrée de VSCode
• Raccourcis clavier : des raccourcis comme Alt+Cmd+K permettent d’envoyer facilement le code sélectionné au prompt de Claude
• Fonction de reconnaissance des onglets : Claude identifie les informations des fichiers ouverts dans VSCode, ce qui permet une assistance au code adaptée au contexte
• Options de configuration : dans /config, définir le diff tool sur auto permet d’activer facilement les fonctions liées à l’intégration IDE

• Il s’agit d’une version de publication initiale (early release), qui peut présenter des bugs ou certaines fonctions incomplètes pendant l’utilisation

[digitect38]

Une différence nette avec Cursor

1. Cursor est lié à VSCode. En revanche, Claude Code fonctionne en CLI (command line interface), donc il peut être utilisé avec n’importe quel outil.

2. Cursor exploite en pratique d’autres LLM, alors que Claude Code est spécialisé pour Claude. Mais si l’on compare les performances, il est clairement supérieur. C’est aussi vrai face à Gemini 2.5 Pro (sur la base de .NET, cela peut varier selon le langage).

[bluekai17]

Dans ce cas, quelle différence avec Cursor ?

[iolothebard]

Non mais pourquoi ils ne sortent pas une version pour Windows (sans passer par WSL) et continuent à faire autre chose… -_ -;;;

[wahihi]

WSL fait aussi partie de l’OS Windows, mais visiblement il ne sait pas s’en servir… À force de ne développer qu’avec une interface graphique, il ne connaît peut-être tout simplement pas du tout la CLI…

[yeorinhieut]

Avec WSL, il y a aussi le problème d’une très forte baisse des performances du système de fichiers (WSL2), ainsi que l’inconvénient de dépendre de Hyper-V pour la virtualisation. Il existe également de nombreux cas où l’on ne peut pas utiliser WSL.

[namojo]

Je suis d’accord aussi. De mon côté, l’utilisation de WSL est interdite en entreprise, donc… j’ai fini par abandonner.
Après avoir contourné le certificat SSL pour réussir malgré tout, je me suis aperçu que WSL ne fonctionnait pas.

[ng0301]

MDRRR, tellement d'accord

[melong0124]

Quelle différence avec Git Copilot ?

[digitect38]

Copilot est spécialisé pour les IDE de Microsoft et reste franchement d’un niveau débutant, tandis que Claude fonctionne dans le CLI / Git Bash, ce qui le rend utilisable dans plusieurs environnements, avec un niveau globalement plus élevé pour le code.

[kimjoin2]

Il existe aussi un plugin IntelliJ.
La différence avec un simple CLI, c’est qu’il reconnaît directement les fichiers ou les lignes que vous êtes en train de consulter ou de sélectionner dans l’IDE.
Bien sûr, vous pouvez aussi l’exécuter dans un terminal classique et démarrer l’intégration avec la commande /ide.

[GN⁺]

Avis Hacker News

• J’ai l’impression qu’intégrer du code agentique dans les IDE existants va dans la mauvaise direction. Une meilleure approche serait de gérer plusieurs Git worktree et de faire tourner chaque agent en parallèle. Pas besoin d’attendre plus de 20 minutes que Claude Code termine sa tâche. C’est pour ça que j’ai créé moi-même une UI pour gérer ça, et ça évolue progressivement vers un nouveau type d’IDE centré sur la gestion et la revue de plusieurs agents. Contrairement au modèle habituel, on ne travaille plus sur une seule chose à la fois. https://github.com/stravu/crystal
  • Personnellement, je ne suis pas d’accord. J’utilise Cursor tous les jours sur des projets commerciaux. Les background agents peuvent être utiles dans certains cas, mais la plupart du temps ils ne font qu’ajouter de la distraction. Ma façon préférée de coder consiste à me concentrer sur un objectif unique et à itérer progressivement vers la solution. Pendant que j’attends la fin d’une tâche, j’explore la documentation ou des informations connexes pour réfléchir à l’étape suivante. Il est aussi très important d’examiner le code existant ou les changements en cours pour comprendre précisément où on en est. L’idée de gérer plusieurs agents pour chaque tâche ne correspond pas du tout à ma manière de travailler. Il y a trop de changements de contexte et de multitâche.
  • Ce que je me demande toujours avec ce type de workflow, c’est comment gérer mon contexte personnel. Même en revue de code entre collègues, au lieu de tout comprendre et de tout valider parfaitement, je me contente le plus souvent de vérifier rapidement les grosses erreurs, comme le style de code ou les bonnes pratiques. C’est ce qui me permet de passer rapidement sur beaucoup de PR dans la journée. Pour les tâches plus importantes, quand j’en suis responsable, je teste la branche et je vérifie l’implémentation en détail. Comme je dois répéter ce travail à chaque mise à jour de PR, ça prend déjà énormément de temps. Donc si plusieurs agents proposent des diff en parallèle, je me demande comment gérer les changements de contexte, surtout quand il faut valider tout ça, et aussi comment gérer les dépendances entre modules lorsqu’une mise à jour a un impact subtil sur un autre travail.
  • On peut très bien construire la même chose sous forme de plugin d’IDE.
  • Super outil ! Je me demande pourquoi tu n’as pas utilisé le SDK TS de Claude Code. J’ai installé le package, mais on dirait que l’architecture lance séparément la commande claude en direct. Au passage, je te recommande aussi de jeter un œil à electron-trpc. Ça simplifie énormément la gestion de l’IPC.
  • L’outil est excellent lui aussi, mais il ne résout pas le même problème. Les background agents ont deux gros problèmes. 1) Il existe une vraie barrière à l’entrée pour mettre en place correctement un environnement isolé. La difficulté varie énormément selon les projets : ça va du simple choix d’un conteneur à l’enfer complet pour configurer toutes les dépendances. À l’inverse, dans l’IDE, tout est généralement déjà prêt. 2) Les gens doivent apprendre comment l’agent construit le code. Si l’agent fonctionne dans l’IDE et que je peux le guider ou le corriger en temps réel, ce sera beaucoup plus utile à long terme qu’un background agent.
• Voici ce que j’aimerais : un environnement qui prenne en charge de façon solide les changements de contexte basés sur git worktree dans une seule fenêtre d’IDE, un framework permettant d’attacher un agent en terminal à chaque branche worktree, puis à terme un meilleur protocole open source pour les diff, les notifications de demande d’autorisation et les notifications de progression, une barre latérale pour surveiller l’état et les alertes des agents par branche worktree, et une interface qui permette de réagir rapidement aux messages des agents sur plusieurs branches, comme à des notifications. Ce genre de fonctionnalités existe dans des outils autonomes de gestion d’agents, mais quand on veut intervenir directement en tant qu’ingénieur, ces outils deviennent difficiles à utiliser correctement. Il faudrait aussi une intégration, branche par branche, avec des fenêtres de test navigateur ou des instances d’émulateur/simulateur mobile. Il faut également de la complétion de code rapide basée sur des modèles, la prise en charge de divers language servers, et un écosystème d’extensions à la hauteur d’un IDE de qualité. Aujourd’hui, je gère séparément Windsurf, Claude agent, le navigateur web et les simulateurs mobiles sur plusieurs bureaux macOS. C’est extrêmement fastidieux.
  • Ce que je veux, c’est un agent de code avec des fonctions de débogage. Je veux qu’il remonte la stack, inspecte les variables locales et les arguments, et voie ce qui se passe réellement à l’intérieur au lieu d’ajouter des print ou des assert.
  • À propos de la capacité à réagir rapidement aux messages des agents sur plusieurs branches comme à des notifications, j’avais moi aussi essayé de créer un plugin pour VSCode. L’idée était de permettre à Claude de sauter directement à un fichier et une ligne. Ça fonctionnait à peu près, mais il y avait un problème récurrent : tout finissait par se bloquer.
• Je ne vois pas très bien la différence concrète entre Cursor et Claude Code. J’ai essayé les deux, et comme mon entreprise les prend en charge, je suis simplement passé à Cursor. Mis à part CLI contre UI, les deux savent faire des modifications multi-fichiers, donc je n’ai pas vraiment vu de différence. J’espère que cette période de transition un peu pénible, où il faut jongler entre plusieurs éditeurs ou alterner entre JetBrains et Cursor, prendra bientôt fin.
  • En termes de qualité et d’utilité, il y a une énorme différence entre les deux. Claude Code est pleinement agentique. On lui confie une tâche et il implémente lui-même l’ensemble, en produisant du code très correct et qui fonctionne bien. Il peut tester, commit, exécuter des commandes, accéder à des systèmes distants, déboguer, etc. Il n’optimise pas l’usage des tokens, donc il produit généralement un code de meilleure qualité dès la première tentative que Cursor, mais à un coût plus élevé. Le mode agent de Cursor en est encore à ses débuts. Cursor ressemble surtout à un outil d’édition de fichiers, alors que Claude Code se comporte plutôt comme un développeur junior.
  • J’utilise souvent les deux ensemble. Cursor sert d’IDE, et Claude Code tourne dans le terminal de l’IDE. Le mode agent diffère aussi en matière de performance, et même lorsqu’ils utilisent le même modèle de base, il y a des écarts dans l’analyse de la base de code, l’usage de sous-modèles, l’intégration avec les outils, etc.
  • Je trouve surprenant que tu ne sentes pas vraiment de différence. Pour moi, Claude est largement supérieur sur tous les plans. J’utilise surtout scala, python, js et dart. Avec Claude, j’ai un assistant incroyablement productif. C’est particulièrement utile pour les petits et moyens changements. Quand on planifie bien les choses, ça donne presque une impression de magie. Il y a un peu de duplication de code, mais rien de dramatique. Cursor, lui, me demandait tellement de retouches qu’au final il me ralentissait.
  • Claude Code est vraiment impressionnant. C’est comme avoir un autre programmeur assis à côté de moi dans mon terminal. Ce n’est pas parfait, et il faut l’aider jusqu’à ce qu’il comprenne correctement ce qu’on veut faire. Mais quand le contexte est bien posé, c’est réellement bluffant. Dans mon cas, je ne lui ai même pas fait comprendre l’intégralité du projet, et je ne l’utilise ni pour TypeScript ni pour le développement web.
  • Cursor impose de basculer vers un IDE séparé, sauf si on utilise déjà VSCode, tandis que Claude Code, ou Aider, modifie directement les fichiers du projet depuis le terminal tout en restant dans l’IDE actuel. Dans mon cas, j’utilise une combinaison vim+tmux+bash, donc je préfère les assistants CLI, mais cet avantage vaut aussi pour les gens qui utilisent un autre IDE GUI que VSCode.
• J’ai même été choqué qu’il n’y ait pas eu plus de réactions la semaine dernière quand GitHub a introduit des limites sur les requêtes premium de Copilot. Je m’attends à un retour de bâton plus important quand davantage de gens commenceront vraiment à se heurter à ces limites. Heureusement qu’il existe des produits concurrents.
  • Avec Claude Code, 10 dollars peuvent partir en fumée très vite en une seule exécution.
• Je me demande s’il y a un avantage particulier par rapport à VSCode Copilot utilisé en mode Agent avec Claude Sonnet 3.7 ou 4. J’aimerais comprendre ce qui m’échappe.
  • Il faut essayer Claude Code soi-même pour pouvoir répondre à cette question. En débattre ici ne sert pas à grand-chose. Si tu travailles surtout dans un terminal Linux, tu vas l’adopter très vite. Il faut aussi absolument lire la documentation. Utilise CLAUDE.md, crée pour les gros travaux des documents de plan au format balisé, puis alterne entre planification, correction et implémentation. Quand tu approches de la limite de contexte, il est bien plus efficace d’écrire la mémoire dans un fichier, de faire /clear, puis de la relire ensuite.
  • J’ai essayé de connecter Playwright MCP au mode agent de Copilot, mais sans succès. L’installation se fait bien, l’outil apparaît dans la sélection, mais au final Copilot ne lui autorise jamais l’accès aux fonctionnalités.
• Je me demande quel est l’avantage de cette solution par rapport à l’usage du backend Claude dans le mode agent de Copilot
  • Les autres explications de ce fil, en particulier https://news.ycombinator.com/item?id=44353972, s’appliquent aussi à VSCode Copilot
  • Après quelques jours d’utilisation, j’ai trouvé que cette intégration corrigeait l’inconvénient de devoir ouvrir les fichiers à la main pour voir les mises à jour. En mode terminal, tout se faisait en arrière-plan et on ne savait pas vraiment ce qui se passait, alors qu’avec l’IDE intégré, on voit tout en temps réel. En revanche, les noms donnés par l’agent, comme Pondering, Twerking, Juggling, etc., paraissent amusants au début, puis deviennent vite inutiles.
• Question un peu hors sujet, mais je me demande si certains utilisent Roo dans VSCode, et si la fonction navigateur de Roo s’intègre bien avec Claude fourni par GitHub Copilot
• Si j’ai bien compris, quand on lance Claude Code dans VSCode ou Cursor, ça s’installe automatiquement. Il n’y a même pas besoin d’aller l’installer séparément, c’est bien ça ?
  • Le fait que Claude Code s’installe automatiquement depuis VSCode, ça ne vous donne pas un peu l’impression d’être envahis ?
  • Oui. C’est indiqué explicitement sur la page de l’extension.

  Auto-installation: When you launch Claude Code from within VSCode’s terminal, it automatically detects and installs the extension
  

• J’ai commencé à sentir mon workflow changer en réalisant que Claude Code comprend plusieurs étapes d’un seul coup. Ma façon de travailler, autrefois centrée sur des fichiers individuels, bascule peu à peu vers des unités d’action uniques du type « séparer un module, écrire les tests, refactorer les appels ». Claude comprend aussi ce genre d’ensemble comme une seule unité, en mode effort maximal. Ce changement modifie progressivement ma manière de coder. Je me préoccupe moins de la syntaxe, j’écris plus de scaffolding, et je regroupe davantage de tâches. C’est subtil, mais l’impact à long terme est important. Je me demande à quel moment nous allons commencer à restructurer volontairement nos bases de code pour qu’elles soient plus faciles à explorer pour les agents LLM — plus plates, avec moins de détours, plus de métadonnées déclaratives, etc.
  • Avant même de parler du futur, c’est déjà en cours. Si Armin Ronacher écrit davantage en Go qu’en Python, c’est aussi parce que les LLM comprennent mieux Go. Un collègue a lui aussi déplacé une app desktop vers Rust, justement parce que le tooling et le système de types la rendent plus facile à explorer pour les agents. On réfléchit déjà à documenter les choses de manière plus lisible pour l’IA.
  • J’y pense aussi souvent quand j’entends que les LLM s’en sortent particulièrement bien avec des langages comme Go, qui ont un typage statique clair, une syntaxe concise et des conventions d’écriture cohérentes. Plus nous devons nous soucier de la complexité inutile introduite par les outils — langages, frameworks, bibliothèques, etc. — moins il nous reste de ressources mentales pour résoudre les vrais problèmes.
• Je suis ravi de voir Claude Code arriver aussi sur JetBrains ! https://plugins.jetbrains.com/plugin/27310-claude-code-beta-
  • Je ne comprends pas pourquoi ce commentaire reçoit autant de votes négatifs. Moi aussi, ça me réjouit. Merci pour le partage.

[namojo]

Quand on utilise Claude Code, j’ai l’impression qu’une approche proche du MSA serait la plus efficace : découper autant que possible par unités de microservices, puis confier chaque élément comme une unité autonome.