Ajout de la prise en charge native de LSP dans Claude Code

 (github.com/anthropics)
18 points par GN⁺ 2025-12-23 | 2 commentaires | Partager sur WhatsApp
  • Claude Code, un outil de programmation basé sur l’IA exécuté dans le terminal, ajoute dans sa dernière version des outils LSP (Language Server Protocol)
  • Cela apporte des fonctionnalités d’intelligence de code de niveau IDE comme aller à la définition (go-to-definition), trouver les références (find references) et afficher la documentation au survol
  • La commande /terminal-setup prend officiellement en charge les terminaux Kitty, Alacritty, Zed et Warp
  • Dans l’écran /theme, il est désormais possible d’activer ou désactiver la coloration syntaxique avec Ctrl+T
  • Ajout d’un guide de configuration du terminal pour les cas où les raccourcis Alt ne fonctionnent pas sur macOS, et uniformisation de l’affichage des raccourcis macOS en opt au lieu de alt, afin de correspondre aux libellés réels des touches
  • La sortie de la commande /context a été améliorée : skills et agents sont regroupés par source, les éléments sont réorganisés selon les commandes slash, et un tri par consommation de tokens est proposé

À lire aussi

2 commentaires

 
aqqnucs 2025-12-23

J'utilisais Serena, mais au final, rien ne vaut l'intégré.
 
GN⁺ 2025-12-23
Réactions sur Hacker News

  • Je ne comprends pas pourquoi JetBrains n’a pas intégré ses outils de refactorisation dans les systèmes d’IA
    Même une tâche simple comme renommer une fonction aurait pu être traitée avec un contexte bien plus réduit au lieu d’éditer des centaines de fichiers, ce qui est regrettable
    Le support LSP est un bon début, mais sans capacités de transformation du code, ça reste insuffisant
    La qualité du LSP de JetBrains n’est pas non plus meilleure que la moyenne

    • En ce moment, JetBrains donne un peu l’impression d’avoir perdu le cap
      Depuis la suppression de la fenêtre modale de commit et la hausse des tarifs, je me demande si je ne vais pas quitter un outil que j’utilise depuis plus de 10 ans
      On peut aussi voir un exemple récent d’erreur dans cet article de blog
    • Cela ressemble au dilemme de l’innovateur classique
      JetBrains possède le moteur PSI, sans doute le meilleur pour comprendre la sémantique du code, mais reste enfermé dans un paradigme où l’humain manipule directement l’IDE
      Claude Code ou Cursor voient l’éditeur comme une toile que l’IA peut manipuler librement, tandis que JetBrains traite l’IA comme un simple plugin de barre latérale
      S’ils n’ouvrent pas leurs outils internes de refactorisation aux agents, la friction du passage vers VS Code disparaîtra
    • JetBrains devrait cesser de s’obséder sur sa propre IA, Junie, et se concentrer sur l’intégration avec des outils déjà bien établis
      Sinon, VS Code va avaler le marché
    • Le problème, c’était l’arrogance
      Ils avaient autrefois une forte barrière à l’entrée, mais VS Code l’a fait tomber
      Ils n’ont absolument pas anticipé ce changement, et semblent maintenant désorientés
    • Microsoft fait une erreur similaire
      Ils n’ont pas réussi à vraiment combiner Roslyn et Copilot
      Un analyzer Roslyn n’est pas un simple linter, c’est un outil puissant capable d’aller jusqu’à la transformation de code, donc voir l’IA continuer à tout faire avec de simples find/replace est frustrant
      Dès qu’un agent basé sur Roslyn arrivera, l’efficacité sur les gros codebases explosera

  • Je suis très positif sur la combinaison Claude Code / Codex CLI + LSP
    J’ai testé Codex ce week-end, et comme c’était pénible de manquer des références lors d’un renommage de fonction ou d’un déplacement de symbole, j’ai moi-même créé une compétence qui le relie à Rope, un outil de refactorisation pour Python
    J’en suis assez satisfait

    • En gros, l’ingénieur d’OpenAI a appuyé sur le bouton Copilot au lieu de la touche F2, et a donc raté le renommage des références
      L’absence de support LSP est vraiment étrange
    • La version 5.1 de Codex ne m’avait pas convaincu, donc je me demande si c’est devenu meilleur que Claude Code aujourd’hui
    • Il est surprenant qu’OpenAI doive construire ce type de fonctionnalité en interne
      Cela montre qu’il reste encore beaucoup à faire dans ce domaine

  • Comme la documentation officielle manque de clarté, je partage ce que j’ai trouvé moi-même
    Il faut ouvrir le gestionnaire de plugins de Claude Code avec la commande /plugin, chercher lsp dans l’onglet Discover, l’activer avec la barre d’espace, puis l’installer avec i

    • Moi aussi, j’ai été surpris quand Claude m’a demandé s’il fallait installer le LSP Go
      En cherchant dans le changelog récent, j’ai vu que la fonctionnalité avait été ajoutée il y a 3 jours
      Comme c’est encore expérimental, je l’ai laissée désactivée
    • Même dans la dernière version, une recherche sur mcp ne renvoie rien
      La fonctionnalité semble encore inachevée
      J’espère qu’à terme Claude détectera automatiquement les LSP
    • Pour ajouter un LSP personnalisé, il faut l’envelopper avec le wrapper de plugin de Claude Code
      La documentation correspondante est ici

  • L’UX de Claude Code d’Anthropic est la pire parmi les grands produits d’IA
    Même copier-coller du texte est pénible, et les retours des utilisateurs sont ignorés
    Dans ces conditions, je ne vois pas pourquoi il faudrait utiliser ça plutôt que ChatGPT

  • J’utilise l’open source OpenCode depuis 6 mois, et il proposait déjà ce type de fonctionnalité
    La lenteur des progrès côté logiciel fermé est surprenante
    Je le recommande, car on peut l’utiliser avec un abonnement Claude ou Copilot

    • J’avais envie d’aimer OpenCode parce que je préfère l’open source et l’indépendance vis-à-vis des providers, mais en pratique Claude Code était plus stable
      OpenCode avait des problèmes de performance, comme un CPU bloqué à 100 % en attente d’approbation ou des dysfonctionnements causés par des popovers
      Cela dit, Claude Code a aussi des bugs, comme des scintillements au scroll
    • Je n’arrive pas vraiment à bien exploiter OpenCode
      Claude Code donne de bons résultats immédiatement, alors qu’OpenCode rend même la connexion aux modèles difficile et reste moins efficace
      C’est probablement grâce au prompt tuning plus ancien de Claude Code
    • L’open source peut avancer vite parce que sa structure de décision est simple
      On ne perd pas de temps à convaincre plusieurs parties prenantes ni à réorganiser des sprints
    • L’expérience de configuration d’OpenCode est la plus simple et intuitive que j’aie vue parmi les autres outils CLI
      En revanche, il y a régulièrement de petits bugs et des crashes
    • La vitesse de développement d’OpenCode est extrêmement rapide
      Si quelqu’un annonce l’AGI le matin, ce sera déjà intégré le soir
      Moi aussi je teste en passant d’un outil à l’autre, mais OpenCode progresse de façon constante

  • Je trouve étrange l’enthousiasme autour des outils en CLI
    Les agents intégrés aux IDE offrent déjà nativement ce genre de fonctions, donc je me demande si recréer diff ou LSP dans un terminal est vraiment efficace
    Cursor prend déjà cela en charge depuis longtemps

    • Le LSP a justement été conçu pour qu’un serveur soit partagé par plusieurs clients
      Côté CLI, il suffit donc de créer un petit client qui se connecte au serveur LSP
      Il n’y a aucune raison pour que seuls les IDE monopolisent les bénéfices du LSP
    • Même des non-développeurs trouvent apparemment le CLI de Claude Code plus naturel
      Le terminal n’est pas seulement un espace d’édition de code, c’est aussi un lieu pour orchestrer l’ensemble de l’ordinateur
      C’est un peu la même raison pour laquelle kubectl n’a pas évolué vers une GUI
      Article lié : It's on your computer
    • Je me demande si les agents dans les IDE peuvent vraiment accéder au LSP
      Par exemple, Zed ne semble pas pouvoir exploiter les informations LSP sans serveur MCP
    • Mon éditeur et mon chatbot sont tous les deux dans le terminal, donc je n’ai pas envie de migrer vers un IDE
      Je préfère le CLI à l’UI incomplète des applications desktop
    • L’avantage du CLI, c’est la liberté de ne pas être dépendant d’un IDE en particulier

  • Comme je l’ai dit récemment dans mon billet, on gaspille énormément de tokens et d’énergie en faisant tourner les LLM de manière inefficace
    Le point crucial, c’est de rendre l’usage des outils plus simple pour les LLM
    C’est un principe valable non seulement pour le code, mais pour tous les domaines

    • Dans quelques années, on regardera probablement avec honte l’écosystème d’outils inefficace d’aujourd’hui
      Il faut prendre en compte les dégâts environnementaux liés au gaspillage d’énergie, d’eau et de ressources
    • Il y a déjà eu des tentatives pour résoudre ce problème
      Par exemple, il existe des projets comme Serena

  • Mon agent préféré, Crush, prend déjà en charge le LSP
    En revanche, dans la pratique, l’agent n’utilise pas si souvent cette fonctionnalité
    Lien GitHub de Crush

    • Je me demande si préciser les serveurs LSP installés dans AGENT.md changeait vraiment quelque chose

  • Je n’ai pas encore vu de cas où le LSP est réellement utilisé
    Opus 4.5 est stable dans son timing QA, et les vérifications de lint fonctionnent aussi très bien hors IDE
    Le LSP peut être utile quand les définitions sont enfouies profondément
    Voici la liste des fonctionnalités LSP proposées par Claude

    • goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy, incomingCalls, outgoingCalls, etc.

  • Le LSP devrait fournir une API sous forme de commandes shell
    Cela faciliterait l’intégration avec les LLM, tout en restant utile aux humains

    • Il existe déjà des frontends CLI comme lsp-cli
      Mais pour un LLM, utiliser le LSP via un outil dédié est plus efficace que de simples commandes shell