Un assistant de code open-source en local dans ton IDE ?

Depuis peu et en se démocratisant, les modèles de langage comme ChatGPT, Claude ou Mistral, transforment profondément notre manière de coder. Il ne s’agit plus de simples gadgets à tester par curiosité : ce sont de véritables compagnons de développement. Ils expliquent du code, génèrent des fonctions, rédigent des tests, identifient des bugs, documentent les projets… et bien plus encore.

Cette évolution s’inscrit dans un mouvement plus large, au cœur même des pratiques DevOps modernes : automatisation, accélération des boucles de feedback, réduction de la charge cognitive. Les assistants IA s’intègrent de plus en plus naturellement aux outils que vous utilisez au quotidien et rendent vos workflows plus fluides, plus efficaces.

Dès lors, une question se pose : Et si votre éditeur de code évoluait lui aussi ?

GitHub Copilot a ouvert la voie. Mais aujourd’hui, des alternatives open-source émergent, avec une attention particulière portée à la confidentialité, au contrôle local et à la personnalisation — des critères devenus essentiels lorsqu’on souhaite garder la main sur son environnement de travail.

Dans cet article, je vous propose de faire un tour d’horizon de trois technologies open-source : Éditeur de code, IA, assistant de code… Nous allons tenter de faire fonctionner tout ce petit monde en local et voir ce que ça donne.

Et quitte à partir sur des technos open-source, pourquoi ne pas opter pour un éditeur léger, rapide et minimaliste, parfaitement adapté à une utilisation locale avec des agents IA potentiellement gourmands en ressources ?

Oui, je vous le donne en mille, je pense bien à Vim !

Neovim, ou l’art de moderniser un dinosaure

J’entends déjà les foules s’indigner :

“Quoi ? Vim ? Sérieusement ? Qui utilise encore ça en 2025 ?”
“C’est pas un truc d’anciens gourous obscurs, dans un terminal noir et blanc ?”
“Et pourquoi pas Emacs pendant qu’on y est ?”

Franchement ? Vous n’avez pas tort. Vim, c’est certes puissant, mais c’est surtout rustique et décourageant : une courbe d’apprentissage bien raide, une config obscure en VimScript, une gestion des plugins capricieuse… En termes de fonctionnalités et d’ergonomie — et même si le concept de l’édition modale est une excellente idée en soi — on est vraiment loin derrière les outils récents.

Mais Neovim, c’est autre chose. C’est l’héritier de Vim, oui, mais réécrit pour le monde moderne : une API propre et des plugins en Lua qui le rendent facile à configurer, un support LSP natif, un débogueur intégré, et une communauté open-source hyperactive qui pousse l’écosystème et l’expérience utilisateur à fond.

💡 Le Language Server Protocol (ou LSP) est un standard qui permet à un éditeur de texte — comme Neovim ou VSCode — de communiquer avec un serveur de langage. Il fournit des fonctionnalités avancées : auto-complétion, navigation dans le code, affichage des erreurs, refactoring, documentation contextuelle…

En bref, on garde ce qui fait la force de Vim (interface modale, vitesse, contrôle total au clavier), mais sans les galères de l’ancien temps. Et avec les bons outils, Neovim devient un vrai environnement de développement complet, léger, rapide, et taillé pour l’automatisation comme pour l’IA.

Les bases de Neovim

L’objectif ici n’est pas de faire une revue exhaustive de toutes les fonctionnalités possibles (le sujet mériterait un article à part entière).

Rappelons juste que tout comme pour vim, l’outil s’utilise en activant différents modes ayant des fonctions précises, comme par exemple le Mode Normal qui permet de se déplacer dans le texte (avec entre autres les fameux bindings : h ⟶ ←, j ⟶ ↓, k ⟶ ↑, l ⟶ →), le Mode Édition (activable avec i) qui permet, comme son nom l’indique d’éditer le buffer courant et le Mode Visuel (activable avec v) qui permet de sélectionner du texte.

La touche : permet d’activer le Mode Command pour accéder aux fonctionnalités de NeoVim (par exemple :w pour sauvegarder le buffer dans un fichier, ou :q pour le fermer).

“Une minute… Et… mon IA là-dedans ?”

Tout juste ! On a fait la moitié du chemin. Maintenant, parlons de LLM (Large Language Model) !

Ollama, ou l’art de ne pas se faire facturer à la virgule

Utiliser un LLM en ligne comme ChatGPT ou Claude, c’est pratique… jusqu’à un certain point. Chaque échange vous coûte des tokens, ces unités de texte consommées et générées. Et quand il s’agit de code, la consommation peut vite grimper et les tarifications portent à débat...

Et bien sûr, vous êtes bloqué avec un modèle unique, souvent sans contrôle ni personnalisation.

Ajoutez à cela que vos requêtes partent dans le cloud, parfois pour y être analysées… ou pire, recyclées dans d’autres réponses. Difficile de s’en servir dans un cadre confidentiel…

“Ouch ! C’est plutôt dissuasif !”

Et c’est justement là qu’Ollama entre en jeu.

Pour les fans de conteneurisation, Ollama, dans l’idée, ça fonctionne un peu comme docker. Mais en lieu et place des conteneurs, vous faites tourner des LLMs !

Concrètement, l’outil vous permet de télécharger un modèle une bonne fois pour toutes depuis une registry (qui en contient des centaines !), et de le faire tourner chez vous, en local. Plus de tokens à surveiller, plus de données qui s’envolent on ne sait où, et vous choisissez le modèle qui correspond à votre besoin !

"Attends… Une minute… Une IA qui tourne en local ? C’est possible ça ?”

Oui, ça parait un peu fou ! Regardons ce que ça donne !

Installation

Pour l’installation, je ne recommande pas d’utiliser votre gestionnaire de paquets : Ollama nécessite de configurer certains outils pour exploiter au mieux votre carte graphique et vos processeurs.

Un script est fourni pour l’installation. Utilisez la commande suivante :

curl -fsSL https://ollama.com/install.sh | sh 

L’installation va configurer un daemon. Vous pouvez vérifier que le service tourne correctement en exécutant :

systemctl status ollama 
● ollama.service - Ollama Service 
     Loaded: loaded (/etc/systemd/system/ollama.service; enabled; preset: dis> 
     Active: active (running) since Thu 2025-04-24 12:57:01 CEST; 19min ago 
     [...] 

Jouons un peu avec notre modèle

Ollama vous permet d’installer n’importe lequel des modèles présents dans leur bibliothèque.

Par exemple, l’un des modèles les plus plébiscités est llama3.

Pour l’installer, rien de plus simple. Lancez la commande suivante :

ollama pull llama3.2 
pulling manifest 
pulling dde5aa3fc5ff: 100% ▕████████████████▏ 2.0 GB                          
pulling 966de95ca8a6: 100% ▕████████████████▏ 1.4 KB                          
pulling fcc5a6bec9da: 100% ▕████████████████▏ 7.7 KB                          
pulling a70ff7e570d9: 100% ▕████████████████▏ 6.0 KB                          
pulling 56bb8bd477a5: 100% ▕████████████████▏   96 B                          
pulling 34bb5ab01051: 100% ▕████████████████▏  561 B                          
verifying sha256 digest 
writing manifest 
success 

⚠️ Certains modèles peuvent être très volumineux. Assurez-vous d’avoir assez d’espace disque avant de lancer l’installation. La taille est consultable sur le site web. Par exemple, pour llama3.2, la taille est de 2.0 GB.

💡Certains modèles proposent plusieurs déclinaisons, avec un nombre de paramètres différents. Plus un modèle contient de paramètres, plus il sera précis dans ses réponses.
Mais il occupera aussi davantage d’espace disque une fois installé, et nécessitera plus de mémoire vive pour fonctionner.
Par exemple, le modèle codellama — que nous utiliserons plus tard — est disponible en 7b, 13b, 34b et 70b.
Le modèle 7b contient 7 milliards de paramètres et nécessite 3.8 Go ; le 70b en contient 70 milliards et nécessite 39 Go.
Soyez sûr d’utiliser le bon compromis entre la fiabilité désirée et les performances acceptables pour votre machine.

On peut lancer le modèle et utiliser des prompts directement depuis le terminal :

ollama run llama3.2
>>> Qu'est ce qu'une année bissextile ? Definition courte.
Une année bissextile est une année qui compte 366 jours, soit 1 jour 
supplémentaire à compter l'an ordinaire.

Pour stopper le modèle, utilisez :

ollama stop llama3.2 

Parfait ! On a maintenant un IDE léger et une IA qui fonctionne en local !
Il ne reste plus qu’à faire travailler tout ce petit monde ensemble…
Et c’est à ce moment-là que CodeCompanion entre en scène !

CodeCompanion : la glue qui rend NeoVim intelligent

Un dernier effort, on entre dans le vif du sujet !

CodeCompanion, c’est un plugin Neovim capable d’intégrer des fonctionnalités d’IA pour vous aider à coder. Une ligne de code vous échappe ? Il peut vous l’expliquer. Un bug incompréhensible ? Il vous suggère une piste.

Concrètement, l’outil n’a rien d’“intelligent” en tant que tel. Il s’agit simplement d’un interfaçage qui vous permet d’interroger un LLM, intégré nativement dans Neovim. Le plugin est compatible avec la très grande majorité des LLMs du marché dont Ollama!

Le projet a beau être relativement récent (première release en août 2024), la solution se montre déjà mature — avec en prime une documentation de qualité.

Installation

Il existe une multitude de solutions pour installer des plugins sous NeoVim. La plus simple et la moins invasive consiste à utiliser un gestionnaire de plugin. On se servira ici de vim-plug. Exécutez cette commande pour l’installer : 

> sh -c 'curl -fLo "${XDG_DATA_HOME:-$HOME/.local/share}"/nvim/site/autoload/plug.vim --create-dirs \
       https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim'

Il ne vous reste plus qu’à importer le plugin et configurer CodeCompanion. Copiez le code suivant dans le fichier ~/.config/nvim/init.lua.

💡 La commande :e ~/.config/nvim/init.lua permet de créer et ouvrir le fichier. La touche p permet de coller le contenu du presse-papier.

local vim = vim
local Plug = vim.fn['plug#']

vim.call('plug#begin')

Plug 'nvim-lua/plenary.nvim'
Plug 'nvim-treesitter/nvim-treesitter'
Plug 'olimorris/codecompanion.nvim'

vim.call('plug#end')

require("codecompanion").setup {
  adapters = {
    codellama = function()
      return require("codecompanion.adapters").extend("ollama", {
  -- Défini un nom différent pour cet adapteur de 
        -- manière à le différencier de l'adapter ollama, 
        -- qui utilise le modèle llama3 par défaut 
        name = "codellama", 
        schema = {
          model = {
            default = "codellama:7b",
          },
        },
      })
    end,
  },
  -- Utilise l'adaptateur qu'on a défini ci-dessus pour les 
  -- différents scénarios d'utilisation de CodeCompanion.
  strategies = {
    chat = {
      adapter = "codellama",
    },
    inline = {
      adapter = "codellama",
    },
    cmd = {
      adapter = "codellama",
    },
  },
  opts = {
    log_level = "DEBUG",
  },
}

Sauvegardez le fichier (:w) puis exécutez la commande :PlugInstall. Vous devriez maintenant être capable d’utiliser CodeDeploy.

Pas d'erreurs ? Félicitations ! On va regarder quelques cas d’usages simples pour se faire la main avec l’outil.

Le ChatBuffer

Ce buffer vous permet de communiquer avec votre LLM. C’est la colonne vertébrale de CodeCompanion. Toutes les fonctionnalités impliquent une interaction avec ce buffer (dans certains cas, CodeCompanion le fait directement pour vous) !

Depuis le ChatBuffer, entrez en Mode Insert (touche i), écrivez un prompt et (toujours en Mode Insert) utilisez les touches ctrl+s pour envoyer votre requête au modèle. Après quelques instants, CodeCompanion va vous répondre !

“Ok, cool ! Je peux utiliser mon LLM directement depuis NeoVim ! Mais… En quoi c’est mieux que depuis mon terminal ?”

Justement ! Les fonctionnalités de CodeCompanion ne s’arrêtent pas là ! Le ChatBuffer vous donne la possibilité d'interagir avec les autres buffers ouverts dans NeoVim :

• Les Slash Commands (qui commencent par /) et les variables (qui commencent par #) permettent d’enrichir le contexte du LLM. Par exemple, utiliser /buffer dans votre prompt vous permet de partager le contenu d’un ou plusieurs buffers ouverts dans NeoVim.
• Les Agents (qui commencent par @) donnent la possibilité au LLM d’agir comme un agent pour automatiser des tâches. Par exemple, utiliser @editor dans votre prompt indique à CodeCompanion qu’il peut utiliser le résultat du LLM pour éditer le contenu d’un buffer NeoVim.

Essayons par exemple de faire un résumé du programme java suivant :

💡 Pour cet exemple, nous avons ajouté un thème à NeoVim pour avoir de la coloration syntaxique. L’aspect est donc différent mais le comportement de CodeCompanion reste le même.

On va utiliser le prompt #buffer What does this code stands for?

Super ! Le buffer nous indique qu’il a été capable de prendre en compte le contenu du buffer (à l’aide de la variable #buffer) en l’ajoutant dans la rubrique Sharing. Cette dernière fournit l’ensemble des éléments qui sont transmis à la LLM en plus de votre prompt !

Un assistant directement depuis votre buffer de code

Encore plus efficace : Vous pouvez directement demander à CodeCompanion d’effectuer des tâches liées à un bloc de code que vous avez sélectionné en Mode Visual directement dans votre buffer de code.

Par exemple, essayons de documenter notre fonction max.

Commençons par sélectionner notre fonction :

Une fois le code sélectionné, on peut utiliser la commande :'<, '>CodeCompanion Document the code. CodeCompanion vous proposera alors un diff.

Utilisez la séquence de touche ga pour appliquer le patch et la magie opère !

Pour aller plus loin

CodeCompanion est un outil puissant d’automatisation. En combinant l’utilisation des agents et des commandes, l’outil est capable d'exécuter des workflows complexes. Il peut par exemple fonctionner de manière autonome pour corriger itérativement du code jusqu’à ce que des tests passent.

Comme sa conception est modulaire, il est également possible de le rendre compatible avec des services de LLM non encore supportés en implémentant de nouveaux adaptateurs (La communauté fournit un effort régulier sur ce domaine).

Il est aussi possible d’étendre son comportement en lui ajoutant de nouveaux agents. 

Bref, cet outil a du potentiel !

Limites observées

NeoVim, Ollama, CodeCompanion… On a réussi à faire fonctionner ces trois technologies ensembles et ça fonctionne assez bien. On peut cependant noter quelques petits bémols.

Temps de chauffe

Le premier prompt transmis à CodeCompanion par le ChatBuffer prend un temps non négligeable (pouvant aller de quelques secondes à plusieurs minutes dépendamment du prompt) pour obtenir une réponse. Les appels suivants sont beaucoup plus réactifs.

Impact significatif sur les ressources

Dans l’état de l’art, les LLM sont très gourmandes en ressources pour pouvoir tourner !

À titre d’exemple :

• codellama:7b utilise en moyenne ~5Go de mémoire vive
• codellama:13b utilise en moyenne ~10Go de mémoire vive

Exécuter une version de ce modèle avec plus de paramètres devient très vite impossible, même sur une machine avec des specs décentes.

L'impact est qu’en local, puisque l’on est limité par les ressources matérielles de notre machine, on ne peut disposer que des modèles les moins bien entraînés, ce qui augmente beaucoup les chances que l’IA puisse halluciner.

C’est par exemple ce qu’il se produit lorsque l’on tente de trouver où sont les erreurs dans le code. Les réponses peuvent rapidement devenir illogique, ce qui rend l’usage même du LLM caduc : 

Le choix du bon modèle

On peut constater que codellama ne semble pas du tout entrainé pour être capable de répondre de manière adéquate à tout genre de prompt (par exemple : le calcul de la somme des n premiers digits de π donne quasi systématiquement des résultats incohérents), et c’est normal : C’est une IA spécialisée dans le traitement du code !

En faisant un essai avec le modèle qwen2-math:1.5b, et bien que ce dernier comporte moins de paramètres, Ollama parvient à donner la bonne réponse.

Il est donc essentiel de prendre en compte le choix du modèle pour s’assurer d’avoir des outils qui répondent aux bons usages.

Le mot de la fin

Au cours de ce tuto exploratoire, nous avons pu faire fonctionner NeoVim, Ollama, et CodeCompanion en synergie pour se doter d’un environnement de développement autonome et intelligent.

Le modèle comporte quelques limitations qui sont surtout dues à Ollama : Les modèles qu’il est possible de faire tourner sur nos PC, ont peu de paramètres et ont une fâcheuse tendance à halluciner : faire tourner une IA cohérente demande beaucoup de RAM et une très bonne carte graphique. Autant dire que l’usage de ces outils dépend fortement de l’architecture de votre machine !

La vraie limite à la démocratisation des IA en tant qu’outil local, c’est le rapport actuel entre leur fiabilité et les ressources qu’elles exploitent. Il est probable que ce rapport s'améliore au cours des prochaines années, mais en attendant, ces dernières s’avèrent peu efficaces.

Dans l’immédiat, un bon compromis pourrait en revanche être de mutualiser une instance d’Ollama sur des clouds d’entreprise. Cette solution permettrait de mutualiser les modèles de LLM les plus performants, adaptés aux usages précis de l’entreprise et en conservant le contrôle de ses données.

Si cette stratégie se montre suffisamment compétitive par rapport aux offres du marché, il y a fort à parier que les IA personnalisées puissent devenir une composante essentielle du Platform Engineering.