vim-ai : brancher un modèle de langage sur le buffer Vim, sans quitter l'éditeur

Ce que le plugin remplace, et pour qui

Le geste visé est précis. On sélectionne un bloc de texte, on tape une instruction, et le résultat remplace la sélection. La documentation donne l'exemple d'une correction grammaticale appliquée à tout le tampon avec :%AIE fix grammar. Le plugin couvre aussi la génération simple avec :AI, la conversation avec :AIChat, et la génération d'images avec :AIImage. Le public est donc celui qui a déjà adopté le modèle modal de Vim et ne veut pas copier du code dans un navigateur pour le faire réécrire. C'est un outil de flux de travail, pas un moteur d'analyse statique : il ne connaît pas votre projet, il connaît le texte que vous lui envoyez. La documentation insiste sur ce point : le plugin n'envoie rien en arrière-plan, seuls le prompt et le contenu sélectionné partent vers l'API, et la facturation suit ce volume. Cette contrainte est aussi une garantie de lisibilité sur ce qui sort de la machine.

Le trajet d'une requête, du buffer à la réponse

Le plugin est écrit en Python et s'exécute dans le processus Vim via l'interface python3. C'est la raison de la prérequis le plus contraignant : Vim ou Neovim doit être compilé avec le support python3. Une fois la commande lancée, la sélection ou la plage concernée est extraite, jointe à l'instruction et à la configuration du rôle actif, puis envoyée à l'API. La réponse revient et, pour :AIEdit, écrase le texte d'origine. Pour :AIChat, elle s'affiche dans une fenêtre dédiée, avec un flux de génération que :AIStopChat peut interrompre, et que Ctrl-c annule également pour :AI et :AIEdit. La documentation mentionne une option de flux par commande, options.stream, mise à 0 dans l'exemple de rôle o1-mini.chat, ce qui indique que le mode streaming est activé par défaut pour le chat et désactivable. Le point d'architecture à retenir est qu'il n'y a pas de démon : chaque commande est un aller-retour synchrone ou en flux, et le plugin ne conserve pas d'état de projet entre deux appels. Les rôles, eux, sont relus depuis un fichier .ini, dont le chemin est fixé par g:vim_ai_roles_config_file.

Installation et clé API : les deux chemins possibles

Deux méthodes sont documentées. Avec vim-plug, une ligne suffit : Plug 'madox2/vim-ai'. En installation manuelle, la documentation s'appuie sur les paquets natifs de Vim et donne les commandes : git clone https://github.com/madox2/vim-ai.git ~/.vim/pack/plugins/start/vim-ai pour Vim, et le même clone vers ~/.local/share/nvim/site/pack/plugins/start/vim-ai pour Neovim. La clé se place dans un fichier, par défaut ~/.config/openai.token, écrit avec echo "YOUR_OPENAI_API_KEY" > ~/.config/openai.token, ou dans la variable d'environnement OPENAI_API_KEY. Les deux formats acceptent une organisation : la documentation montre la forme "YOUR_OPENAI_API_KEY,YOUR_OPENAI_ORG_ID", séparée par une virgule, pour le fichier comme pour la variable. Le chemin du fichier est déplaçable avec let g:vim_ai_token_file_path = '~/.config/openai.token'. Ce double mécanisme est pratique en environnement partagé, mais il faut noter que la variable d'environnement et le fichier ne sont pas hiérarchisés dans la documentation : rien n'indique lequel gagne en cas de conflit, et c'est un point à trancher vous-même avant de déployer sur plusieurs machines.

Les rôles : la vraie couche de configuration

Un rôle est une instruction réutilisable et un jeu d'options, déclarés dans un fichier .ini. L'exemple de la documentation définit une section [grammar] avec prompt = fix spelling and grammar et options.temperature = 0.4, puis une section [o1-mini] qui fixe options.model, options.max_completion_tokens à 25000, options.temperature à 1 et options.initial_prompt. Une sous-section [o1-mini.chat] ajoute options.stream = 0 et ui.populate_all_options = 1, ce qui montre que les options peuvent être posées globalement puis surchargées pour une commande donnée. L'usage suit : on sélectionne, puis :AIEdit /grammar. Les rôles se combinent, la documentation donne :AI /o1-mini /grammar helo world!. C'est le mécanisme le plus intéressant du plugin, parce qu'il déplace la configuration hors du .vimrc et la rend partageable. Il y a aussi des rôles prédéfinis pour le placement de la fenêtre de chat, /right, /below et /tab, et /populate ou /populate-all pour remplir l'en-tête de configuration, par exemple :AIC /populate /gemini. La syntaxe exacte de l'imbrication par commande est le point à vérifier en premier : une faute de nom de section produit un rôle silencieusement ignoré plutôt qu'une erreur visible.

Fournisseurs : l'API compatible comme unique porte de sortie

Le plugin parle le protocole d'OpenAI, et c'est à la fois sa force et sa limite. Tout service exposant une API compatible peut être branché, et la documentation cite OpenRouter comme proxy simple, LiteLLM pour un proxy local, et renvoie vers un guide de configuration de rôles personnalisés pour OpenRouter. Trois greffons de fournisseurs tiers sont listés : un fournisseur Google pour les modèles Gemini, un fournisseur pour l'API Responses d'OpenAI, et un fournisseur OpenAI avec support MCP. La documentation signale elle-même que ces greffons sont peu nombreux et que leur développement est souhaité, ce qui est un aveu utile : l'écosystème de fournisseurs n'est pas mûr. Pour un modèle local, la voie documentée passe donc par un proxy compatible, pas par une intégration directe. Si votre besoin est d'appeler un serveur local sans couche intermédiaire, ce plugin n'est pas le bon outil, et un client qui parle nativement le protocole de votre serveur sera plus court à configurer.

Limites et cas où il faut passer son chemin

La documentation ne décrit aucune gestion de contexte de projet, aucun index de dépôt, aucune complétion en ligne pendant la frappe. C'est un assistant à la demande, déclenché par une commande, pas un moteur de suggestions contextuelles. La dépendance à python3 dans le build de l'éditeur est un filtre réel : un Vim système compilé sans cette option rend le plugin inutilisable, et le diagnostic n'est pas évident au premier abord. L'usage de :AIEdit mérite une précaution : la commande écrase la sélection, donc sur un fichier non versionné, une réponse mal cadrée détruit du texte sans filet. Le plugin n'a pas de version publiée dans les éléments fournis, aucune release n'est remontée, ce qui veut dire que le suivi se fait sur la branche main et que la stabilité dépend du rythme de commits plutôt que de versions taguées. Enfin, la documentation reste muette sur la gestion des erreurs réseau, sur les limites de débit et sur le comportement en cas de réponse tronquée. Ce sont des zones à tester soi-même avant de s'appuyer dessus dans un flux quotidien.

Coût de maintenance et licence

Le coût se répartit sur trois postes. Le premier est la facturation à l'usage de l'API, que la documentation décrit comme dépendante du nombre de jetons échangés, avec un lien vers la grille tarifaire du fournisseur ; le plugin lui-même n'ajoute pas de coût. Le deuxième est la maintenance de la configuration : chaque modèle ou fournisseur ajouté se traduit par une section .ini, et l'exemple [o1-mini] montre que les noms d'options suivent ceux de l'API, donc une évolution côté fournisseur peut demander une retouche du fichier de rôles. Le troisième est le suivi du code, puisque aucune release n'est remontée et que l'installation se fait par clone ou par gestionnaire de greffons sur la branche main. Côté licence, le dépôt est publié sous MIT, ce qui autorise la réutilisation et la modification avec conservation de l'avis de licence ; les greffons de fournisseurs tiers listés ont leurs propres licences, à vérifier séparément. Rien dans les éléments fournis ne permet de dire si le projet accepte des contributions externes au-delà des pull requests mentionnées pour la liste des fournisseurs.

Conclusion éditoriale

vim-ai convient à qui travaille déjà dans Vim ou Neovim compilé avec python3 et veut appliquer une instruction à une sélection sans changer d'outil. Il ne convient pas à qui refuse de dépendre d'une API distante ou veut un serveur de complétion local branché sur le protocole LSP. Avant d'adopter, vérifier trois points dans ce projet : la présence de python3 dans votre build, le chemin réel du fichier de jeton, et la syntaxe exacte de la section de rôle que vous comptez écrire.

Sources officielles

1. Issues
2. License: MIT
3. madox2/vim-ai on GitHub
4. README