LSP pour les agents IA : une promesse solide, un setup qui coince encore

LSP est une de ces technologies qui a si bien réussi qu’elle est devenue invisible. La plupart des développeurs l’utilisent quotidiennement sans jamais en avoir entendu parler. C’est le signe d’une infrastructure qui fonctionne, et c’est aussi la raison pour laquelle la question de son recyclage dans un monde agentique mérite d’être étudiée sérieusement.

Une infrastructure devenue transparente

Microsoft annonce LSP à Build 2016 avec un objectif précis : résoudre le problème M×N. Avant LSP, chaque éditeur devait intégrer chaque langage séparément. M langages, N éditeurs : M×N intégrations à maintenir. LSP ramène ça à M+N. Un serveur par langage, un client par éditeur, un protocole commun.

graph LR
    subgraph Avant LSP
        A1[VS Code] --> L1[Python]
        A1 --> L2[Rust]
        A1 --> L3[Go]
        A2[Neovim] --> L1
        A2 --> L2
        A2 --> L3
        A3[Emacs] --> L1
        A3 --> L2
        A3 --> L3
    end
    subgraph Avec LSP
        B1[VS Code] --> P[Protocole LSP]
        B2[Neovim] --> P
        B3[Emacs] --> P
        P --> S1[pyright]
        P --> S2[rust-analyzer]
        P --> S3[gopls]
    end

Concrètement, LSP est un protocole qui permet à notre IDE de communiquer avec un serveur qui analyse le code en direct. Cela permet d’en remonter les erreurs de syntaxe, de rechercher tous les appels à une référence, etc.

L’adoption a été rapide. Aujourd’hui, plus de 100 serveurs LSP open source sont répertoriés sur langserver.org. rust-analyzer, gopls, pyright, clangd : chacun est devenu la référence de son écosystème.

LSP a atteint le stade où on ne le remarque plus. C’est là que la question suivante devient intéressante.

Le lien avec le monde agentique

Mais alors pourquoi parler de LSP aujourd’hui ?

Depuis quelques années, les LLMs ont franchi un cap. On n’attend plus d’eux seulement qu’ils raisonnent ou génèrent du code, on attend d’eux des actions plus complexes. Avec l’usage de tools notamment, on entre dans l’ère de l’IA agentique.

Et un des premiers réflexes dans la conception de ces tools pour agents est de réutiliser ce qui, pour nous humains, était performant. Le LSP en fait partie.

Avec cet outil, quand un agent cherche toutes les utilisations d’une fonction dans une codebase, il a deux options. La première : grep, ripgrep, ou lire les fichiers un par un. La seconde : requêter le serveur via LSP.

La différence n’est pas qu’une question de vitesse.

grep "authenticate" trouve le mot. textDocument/references trouve toutes les invocations de cette fonction précise : celles aliasées auth dans un autre module, celles passées comme callback, celles redéfinies dans un sous-type. LSP comprend la sémantique du code. Grep manipule du texte.

De plus, l’agent peut interroger le serveur pour savoir si le code est correct. Si une erreur remonte, il peut la corriger instantanément, sans qu’on ait besoin de le lui indiquer manuellement.

Il y a aussi un argument économique. Interroger un serveur LSP coûte une fraction de ce que coûterait demander à un LLM de lire dix fichiers pour la même information : moins de tokens, réponse plus précise.

Ces gains s’amplifient avec la taille de la codebase. C’est là que LSP devient intéressant pour les agents.

Les frictions qui bloquent l’adoption agentique

Bien que LSP soit adopté nativement dans tous les IDE aujourd’hui, le développeur de demain ne code plus dans un IDE. Les agents tournent dans un terminal, outil qui devient le seul nécessaire au kit du développeur du futur.

Claude Code en mode terminal, Codex CLI, les agents qui tournent dans un pipeline CI : aucun n’a accès à un client LSP par défaut. Et intégrer un client LSP dans un agent CLI n’est pas une petite tâche. Un serveur par langage, chacun dans son propre processus. Cycle de vie à gérer, capabilities qui varient d’une implémentation à l’autre, timeouts, erreurs. Pour chaque nouveau langage dans le projet, il faut installer et configurer le serveur correspondant.

C’est loin d’être impossible. Mais c’est un overhead de setup et de maintenance que la plupart des équipes ne sont pas prêtes à absorber pour un gain encore perçu comme optionnel.

Anthropic et OpenAI poussent activement leurs CLI agents. L’usage en terminal est en forte croissance chez les développeurs qui poussent ces outils à fond. L’agent se découple de l’IDE. LSP ne suit pas.

À cela s’ajoute un problème souvent sous-estimé : la mémoire. Chaque serveur LSP tourne dans son propre processus et maintient une représentation en mémoire de l’ensemble du projet. rust-analyzer peut facilement consommer plusieurs centaines de mégaoctets sur un projet Rust de taille moyenne, et dépasser le gigaoctet en pic d’indexation. Multipliez ça par le nombre de langages dans un projet, et le footprint devient significatif.

Il y a un autre problème, moins documenté. Même quand un client LSP est disponible, les agents ont tendance à ne pas s’en servir. Ils ont été entraînés sur des patterns de navigation textuelle : grep, lecture de fichiers, recherche par mot-clé. Ces réflexes sont profondément ancrés. Mettre un client LSP à disposition ne suffit pas à changer le comportement du modèle. Ce n’est pas un problème de configuration, c’est un problème d’entraînement. Tout cela induit une couche de configuration supplémentaire, au travers des instructions que l’on donne à l’agent (CLAUDE.md, AGENTS.md, etc.).

Alors, ça vaut le coup ou pas ?

Comme on pourrait s’y attendre, ça dépend du contexte. Et le point de bascule n’est pas encore atteint pour la majorité des usages.

Les freins sont réels : un coût d’installation et de maintenance certain, un protocole qui n’a pas été conçu pour des modèles de langage, une consommation de ressources non négligeable. Le tout pour que les LLMs ne l’utilisent parfois même pas, par manque d’habitude.

Malgré tout, l’intérêt d’un outil comme LSP reste fort dans le monde agentique. La navigation se fait bien mieux qu’avec des commandes bash, et la remontée d’erreurs purement déterministes est une vraie valeur ajoutée pour l’avenir de l’IA agentique. Un tel standard entre les différents langages ne sera peut-être jamais atteint par un autre outil que LSP.

Aujourd’hui, LSP est un outil très pratique et tous ses avantages sont bien réels. Cependant, la configuration qu’il nécessite est décourageante, surtout lorsqu’il s’agit de le mettre à disposition d’une équipe entière. Pour ce type d’usage, je conseillerais de passer son tour et d’attendre une solution plus simple et mieux adaptable. Pour un usage personnel en revanche, c’est bien plus envisageable, surtout si vous avez l’habitude de travailler régulièrement avec les mêmes langages.