Twinny : l'autocomplétion de code 100 % locale

#Ce que fait Twinny

Deux fonctions cohabitent historiquement dans l'extension : la complétion en ligne, qui affiche une suggestion grisée pendant la frappe, et une barre latérale de discussion pour poser des questions sur le code sélectionné. Les deux s'appuient sur un modèle local, servi par Ollama, LM Studio ou llama.cpp, et rien ne quitte la machine par défaut.

L'intérêt est évident dans un contexte où le code ne doit pas sortir : cabinet, administration, code client sous accord de confidentialité. L'argument n'est pas le coût — il est que la question « où part mon code » a une réponse vérifiable. Le projet se présente lui-même comme l'assistant IA pour VS Code qui reste à l'intérieur de votre réseau.

#Le détail qui change tout : le remplissage au milieu

Compléter du code n'est pas continuer un texte. Quand vous écrivez au milieu d'une fonction, le modèle doit tenir compte de ce qui précède ET de ce qui suit. Cette capacité porte un nom — le remplissage au milieu, ou FIM (fill-in-the-middle) — et tous les modèles ne l'ont pas : la documentation officielle est explicite sur ce point, le fournisseur de complétion doit utiliser un modèle entraîné pour le FIM, chaque famille de modèle utilisant des jetons distincts pour marquer le préfixe, le suffixe et la zone à compléter.

C'est la source numéro un des déceptions. Un excellent modèle de discussion orienté code, sans cette capacité, produira des suggestions qui ignorent la suite du fichier et referment des accolades déjà présentes. Autre point que beaucoup ignorent : la documentation recommande un modèle de base plutôt qu'une variante instruite, car un modèle de base poursuit un texte brut de façon plus fiable qu'il ne gère un suffixe vide, en particulier quand il n'y a rien après le curseur.

#Les réglages qui rendent l'expérience fluide

Quatre réglages, documentés par le projet, concentrent l'essentiel du gain de latence perçue. Ils vivent dans les paramètres de l'extension (préfixe twinny.) et peuvent tous être ajustés sans redémarrer Ollama.

1. 01
   Limiter le nombre de jetons générés

   Une complétion utile fait une ligne ou deux. La documentation le confirme : si les suggestions arrivent en retard, la première chose à baisser est numPredictFim, pas le modèle.
2. 02
   Ajuster le délai de déclenchement

   Déclencher à chaque frappe sature le serveur ; le délai par défaut de 300 ms (debounceWait) suffit dans la plupart des cas et divise le nombre d'appels.
3. 03
   Garder le modèle chargé côté Ollama

   Si le serveur décharge le modèle après quelques minutes d'inactivité, la première suggestion après une pause arrive trop tard. On allonge la durée de maintien en mémoire côté Ollama (keep_alive).
4. 04
   Réduire la fenêtre de contexte envoyée

   La documentation le dit explicitement : si les suggestions semblent en retard, baisser contextLength (100 lignes par défaut avant/après le curseur) ou laisser fileContextEnabled désactivé, son réglage par défaut. Ce paramètre n'ajoute des extraits d'autres fichiers ouverts que si on l'active soi-même.

#Ce que le modèle voit vraiment

Une suggestion ne part pas seulement du préfixe et du suffixe autour du curseur. La documentation détaille les sources que Twinny assemble avant de construire le prompt : les lignes environnantes (contextLength), les dernières modifications faites dans le fichier sous forme de petits diffs (recentEditsEnabled, activé par défaut, jusqu'à 6 changements), les symboles et la signature de l'appel en cours fournis par le serveur de langage (lspContextEnabled, activé par défaut), et en option des extraits d'autres fichiers ouverts liés (fileContextEnabled, désactivé par défaut).

Modifications récentes

Un renommage à moitié fait ou un motif appliqué à la main sur un fichier se propage dans les suggestions suivantes, comme s'il comprenait ce que vous êtes en train de faire.

Contexte IntelliSense

Le modèle reçoit les noms et la signature de l'appel dans lequel se trouve le curseur, fournis par le serveur de langage de l'éditeur.

Fichiers voisins

Désactivé par défaut : ne l'activer que sur un gros projet, car il coûte de la latence pour un gain variable.

Autre détail utile en pratique : écrire d'abord un commentaire d'une ligne décrivant ce qui vient ensuite, puis marquer une pause, donne à la suggestion multi-lignes un objectif clair — c'est le conseil que donne la documentation elle-même pour obtenir de meilleures suggestions. Nommer clairement ses variables et fonctions reste, avant tout réglage, le levier qui a le plus d'effet sur la pertinence.

#Quels modèles, et pourquoi si petits

Cette asymétrie surprend toujours : on est habitué à ce que plus gros soit mieux. Pour la complétion, un modèle de 1,5 milliard de paramètres, entraîné au remplissage au milieu et servi en version de base, bat en pratique un modèle généraliste de 14 milliards, parce qu'il répond avant que vous ayez fini de réfléchir. L'extension permet de configurer un modèle par fonction — un pour le FIM, un autre pour la discussion — et c'est le bon réglage : les deux n'ont ni la même taille ni le même entraînement.

#Au-delà de la complétion : ce que fait Twinny en 2026

L'extension a beaucoup grossi depuis ses débuts en simple plugin de complétion. Sa page officielle liste aujourd'hui l'édition en ligne (décrire un changement et le relire sous forme de diff dans l'éditeur), un index du poste de travail combinant recherche par mots-clés et recherche vectorielle, une revue de code portant sur l'arbre de travail, une branche ou une pull request GitHub, la génération de messages de commit à partir des modifications indexées, et la génération de commandes de terminal avec correction automatique des erreurs.

Toutes ces fonctions restent rattachées à des commandes VS Code réaffectables et à des modèles de prompt personnalisables. Côté fournisseurs, la liste s'est élargie aux API hébergées (OpenAI, Anthropic, Mistral, DeepSeek, OpenRouter, Gemini, Groq, Cohere, Perplexity) en plus des moteurs locaux (Ollama, LM Studio, llama.cpp, Oobabooga, LiteLLM, Open WebUI) — mais rien n'oblige à en utiliser une : l'usage 100 % local reste la configuration par défaut.

#Gratuit en solo, payant en équipe

En usage individuel, Twinny reste ce qu'il a toujours été : une extension sous licence MIT, sans télémétrie ni connexion obligatoire. La facturation n'apparaît qu'au-delà de cinq développeurs partageant une passerelle d'équipe (twinny-server), qui centralise l'accès aux fournisseurs pour toute l'organisation : gratuite jusqu'à cinq comptes, elle passe ensuite à un tarif par poste et par mois, avec un essai de 30 jours sans carte bancaire. Pour un développeur seul avec Ollama en local, aucune de ces conditions ne s'applique et l'extension reste entièrement utilisable sans jamais créer de compte.

#Twinny ou un agent d'édition

Les deux usages ne s'excluent pas. Beaucoup de développeurs gardent Twinny actif en permanence pour la complétion en ligne — invisible, rapide, avec un petit modèle dédié — et basculent vers un agent d'édition comme Roo Code ou Cline pour une tâche qui touche plusieurs fichiers, avec un modèle plus grand qu'ils acceptent d'attendre quelques secondes.

• Roo Code : l'agent de code local dans l'éditeur
• Cline + Ollama : agent de code 100 % local dans VS Code
• Relire et réviser du code avec un LLM local
• Meilleur LLM local pour coder : comparatif
• Source : dépôt GitHub officiel de Twinny
• Source : documentation de la complétion FIM
• Source : fiche Visual Studio Marketplace

#FAQ