Coder avec l'IA sur modèle local : harness, vLLM et LiteLLM

Un assistant de code utile ne se résume pas à un modèle. Il assemble un harness qui agit sur le dépôt, des modèles ouverts servis en local par vLLM, une passerelle LiteLLM qui expose une API unique et un cache clé-valeur qui rend les sessions longues abordables.

Par QDNA · Publié le 16 juillet 2026 · 9 min de lecture

Pourquoi un harness change la donne

Un modèle de langage seul produit du texte. Un assistant de code utile agit sur le dépôt : il lit les fichiers, propose un correctif, lance les tests, vérifie la compilation et itère. Cette boucle d'exécution prend le nom de harness.

OpenCode et Hermes remplissent ce rôle. OpenCode orchestre les appels d'outils sur le système de fichiers, applique les règles d'approbation sur les actions sensibles et délègue à des sous-agents pour paralléliser les tâches de recherche, d'analyse ou de test. Hermes ajoute une couche d'orchestration par rôles : un modèle raisonne, un autre code, un autre vérifie. Sans harness, le modèle reste un générateur de texte : avec lui, il devient un collaborateur technique.

L'architecture derrière l'assistant de code

Une architecture locale typique assemble cinq briques. Le harness OpenCode présente les outils au modèle et exécute la boucle d'édition. Hermes joue le rôle d'orchestrateur par rôles lorsque l'équipe a besoin de spécialisation. LiteLLM expose une API unique compatible OpenAI face au harness, attribue une clé virtuelle à chaque développeur et applique des quotas par personne ou par équipe. Le moteur d'inférence vLLM sert les modèles ouverts sur le matériel de l'organisation avec une gestion fine de la mémoire GPU. Le choix du modèle dépend du profil de tâche : raisonnement long, appels d'outils stables, ou compromis qualité-coût pour le quotidien. Côté matériel, une RTX PRO 6000 équipe une équipe complète, tandis qu'une DGX Spark suffit pour un développeur isolé.

Le code source ne quitte jamais l'infrastructure

L'argument tient en une phrase : le code ne sort pas du réseau interne. Le harness appelle LiteLLM sur une adresse privée, LiteLLM route vers vLLM sur la même machine ou un poste voisin, et le modèle traite la requête sans qu'aucun octet ne traverse Internet.

Cette propriété règle plusieurs problèmes à la fois. Le secret industriel reste dans le périmètre certifié. Les exigences de conformité NIS2 trouvent une réponse technique simple. Les auditeurs vérifient que le code de production n'apparaît dans aucun journal d'un fournisseur tiers. Les équipes juridiques n'ont plus à négocier de clause sur les données envoyées à un service externe. La souveraineté devient une propriété du système, et non une promesse contractuelle.

Le cache clé-valeur local rend les sessions longues économiques

Une session de développement productive dure plusieurs heures. Le modèle relit le même module, retrouve les mêmes définitions, parcourt les mêmes dépendances. Recalculer l'attention sur ce préfixe partagé à chaque tour coûte cher en temps et en énergie.

vLLM conserve un cache clé-valeur en mémoire GPU entre les tours d'une même session. Le préfixe commun du contexte n'est recomputé qu'une seule fois, et chaque tour suivant ne porte que sur le nouveau fragment. Sur une session de quatre heures avec un contexte de plusieurs dizaines de milliers de tokens, ce mécanisme divise le coût total par un facteur qui dépasse couramment dix. Le modèle reste longtemps utile sans que la facture s'envole, et le développeur peut laisser l'assistant itérer sans surveiller la dépense.

Le tableau ci-dessous résume le gain observé sur une session type de cinq heures avec un contexte utile de 50 000 tokens.

Quel modèle pour quelle tâche de code

Le paysage des modèles ouverts pour le code s'étoffe vite. Le bon réflexe consiste à choisir le modèle selon le profil de la tâche, et non l'inverse.

GLM 5.2 sert les refactorisations lourdes et les raisonnements de longue portée : 744 milliards de paramètres en mélange d'experts, dont une fraction active par token, pour absorber une base de code entière sans perte de fil. Kimi K2.7 Code se distingue sur les sessions longues qui multiplient les appels d'outils successifs : il garde la cohérence du raisonnement sur des enchaînements de cent actions et plus. DeepSeek V4 occupe deux postes : la variante Pro pour les investigations profondes, la variante Flash pour le quotidien de l'équipe, qui combine vitesse et coût contenu. Qwen 3.6 27B tient sur une carte unique et convient à un développeur isolé qui veut une réponse immédiate sans mobiliser un cluster. Gemma 4 entre dans la même catégorie, avec un profil différent sur les langages de niche.

Le passage à l'échelle se fait ensuite en sélectionnant le modèle selon la tâche, sans toucher au harness ni à LiteLLM.

Une API unique, des clés virtuelles et des quotas par développeur

LiteLLM joue le rôle de point d'entrée unique. Le harness parle à LiteLLM comme il parlerait à OpenAI. LiteLLM route vers vLLM, applique les garde-fous et inscrit chaque appel dans un journal d'audit. Les développeurs ne manipulent qu'une seule clé, qu'ils échangent contre une clé virtuelle à leur nom.

Cette clé virtuelle porte un quota par personne et par jour, parfois par projet. L'administrateur plafonne la dépense d'un stagiaire, ouvre un quota large pour un lead technique et coupe l'accès à un modèle précis pour un sous-traitant. Le provisionnement se fait en un fichier de configuration, et le redémarrage du service prend une dizaine de secondes. Les développeurs changent de modèle sans changer d'outil.

Le matériel suit la même logique. Un développeur isolé travaille sur une DGX Spark et un seul modèle. Une équipe de cinq à dix développeurs s'appuie sur une RTX PRO 6000 et sert plusieurs modèles en parallèle, le tout routé par LiteLLM. Le point de bascule financier entre auto-hébergement et API externe dépend du volume mensuel et du profil de tâches : l'analyse détaillée figure dans notre étude sur les coûts du LLM en local ou via API.

Un assistant de code utile reste local par construction : le code ne quitte pas l'infrastructure, le cache clé-valeur rend les sessions longues abordables, et LiteLLM impose une seule API, des clés virtuelles et des quotas par développeur.

Passer du POC à l'usage quotidien

Trois conditions réunies font basculer un prototype en pratique d'équipe. Premièrement, un harness configuré pour le dépôt, avec des règles d'approbation explicites sur les fichiers sensibles et un sous-agent de test dédié. Deuxièmement, un moteur vLLM dimensionné pour le modèle de référence et un cache clé-valeur calibré sur la taille de contexte typique. Troisièmement, une politique LiteLLM qui attribue à chaque développeur une clé virtuelle, plafonne les quotas et journalise les appels pour l'audit.

Une fois ces trois briques en place, l'assistant de code passe du statut d'outil de curiosité à celui d'infrastructure de production. Le code reste dans l'organisation, les sessions longues restent abordables, et chaque développeur consomme sa juste part.