Faits rapides — LLM locaux pour coder en un coup d'œil
- Meilleur global : Qwen3.8 27B (Alibaba) — dense 27B, Apache 2.0, 18 Go sur Ollama, contexte 256K, 61,7 SWE-bench Pro, 90,3 LiveCodeBench v6 (selon Qwen).
- Génération Qwen précédente : Qwen 3.6 27B — 77,2 % SWE-bench Verified et 53,5 SWE-bench Pro (selon Qwen) ; reste une solution de repli solide, supplanté par Qwen3.8 27B.
- Meilleur pour le codage agentique à 24B : Devstral Small 2 (Mistral AI, France) — 15 Go, 65,8 % SWE-bench Verified, Apache 2.0, appel d'outils et modifications multi-fichiers. Nécessite Ollama 0.13.3 ou plus récent.
- Meilleur pour les longues sessions agentiques : Laguna XS 2.1 (Poolside) — MoE 33B total / 3B actifs, 20 Go, contexte 256K, SWE-bench Verified 70,9 %, SWE-bench Multilingual 63,1 %, licence OpenMDW-1.1.
- Grand MoE pour machines de 64 Go : Qwen3-Coder-Next — 80B total / 3B actifs, 52 Go (Q4), contexte 256K.
- Meilleur pour l'autocomplétion en IDE : Codestral 22B (Mistral) — optimisé FIM, intégration Continue.dev, 13 Go, contexte 32K.
- Meilleur pour 8 Go de RAM : Qwen3 8B — 5 Go de VRAM utilisés, meilleur compromis qualité-vitesse.
- Poids ouverts à l'échelle frontière : Kimi K2.6 et Kimi K2.7 Code (Moonshot AI) — MoE 1T total / 32B actifs, contexte 256K. Ollama ne propose que des tags `:cloud` ; les builds GGUF locaux demandent environ 310 à 470 Go selon la quantification.
- Changement de benchmark : SWE-bench Pro et Verified (vrais tickets GitHub) sont les métriques principales pour le code pratique. HumanEval (fonctions Python isolées) reste utile pour comparer de petits modèles.
- Configuration recommandée : GPU de 24 Go ou 32 Go de mémoire unifiée (Qwen3.8 27B ; macOS en réserve environ 8 Go sur un Mac) ; 16 Go suffisent pour Devstral Small 2.
🏆 Meilleurs LLM locaux pour coder (sélection rapide)
- Meilleur global : Qwen3.8 27B — dense 27B, 18 Go, contexte 256K, 61,7 SWE-bench Pro (selon Qwen). `ollama run qwen3.8`
- Meilleur codage agentique à 24B : Devstral Small 2 — modifications multi-fichiers, appel d'outils, 15 Go. `ollama run devstral-small-2`
- Meilleur pour les longues sessions agentiques : Laguna XS 2.1 — MoE 33B/3B actifs, 20 Go, contexte 256K. `ollama run laguna-xs-2.1`
- Grand MoE (machines de 64 Go) : Qwen3-Coder-Next — 80B/3B actifs, 52 Go. `ollama run qwen3-coder-next`
- Meilleur pour la complétion consciente du dépôt avec 24 Go : Qwen3-Coder 30B — MoE 30B/3,3B actifs, 19 Go, contexte 256K. `ollama run qwen3-coder:30b`
- Meilleur pour l'autocomplétion en IDE : Codestral 22B — optimisé FIM pour Continue.dev, 13 Go. `ollama run codestral:22b`
- Meilleur pour 8 Go de RAM : Qwen3 8B — 5 Go de VRAM. `ollama run qwen3:8b`
- 👉 En cas de doute : Qwen3 8B sur les portables de 8 à 16 Go, Qwen3.8 27B avec un GPU de 24 Go ou un Mac de 32 Go.
- 👉 Avec 16 Go : Devstral Small 2 convient le mieux au codage agentique ; Qwen3.8 27B (18 Go) demande une carte de 24 Go ou un Mac de 32 Go.
- 👉 Pour les longues sessions agentiques : essayez Laguna XS 2.1 ou Devstral Small 2.
- 👉 Pour la complétion en IDE : utilisez Codestral 22B avec Continue.dev.
🛠️Bonne pratique: Adaptez d'abord la taille du modèle à votre matériel. Avec 8 Go, utilisez Qwen3 8B ; avec 16 Go, Devstral Small 2 ; avec un GPU de 24 Go ou un Mac de 32 Go, Qwen3.8 27B. Kimi K2.6 et K2.7 Code ne sont pas des choix locaux pratiques : Ollama ne les propose qu'en tags cloud et les builds locaux demandent 300 Go ou plus.
En une phrase
Le meilleur LLM local pour coder en 2026 est Qwen3.8 27B (18 Go, 61,7 SWE-bench Pro selon Qwen), avec Devstral Small 2 pour le codage agentique à 16 Go, Laguna XS 2.1 pour les longues sessions, Codestral 22B pour l'autocomplétion en IDE et Qwen3 8B pour 8 Go de RAM.
En termes simples
Exécuter un modèle de programmation localement est comme installer un assistant de codage IA sur votre ordinateur portable — il garde votre code privé, fonctionne hors ligne, mais est plus lent que les API cloud comme GitHub Copilot.
Qu'est-ce qui fait un bon LLM local pour coder ?
En 2026, SWE-bench Pro et SWE-bench Verified ont largement remplacé HumanEval comme benchmarks pratiques de code. Ils testent la capacité d'un modèle à résoudre de vrais tickets GitHub — modifications multi-fichiers, compréhension de bases de code, écriture de tests — et pas seulement la génération de fonctions isolées. Qwen annonce 61,7 sur SWE-bench Pro pour Qwen3.8 27B et 77,2 % sur SWE-bench Verified pour le Qwen 3.6 27B précédent.
Les modèles spécialisés en code sont affinés sur de grands corpus de code (GitHub, Stack Overflow, documentation) et incluent souvent un entraînement fill-in-the-middle (FIM) -- la capacité de compléter du code à partir du contexte avant et après le curseur, indispensable pour l'autocomplétion en IDE.
Les modèles généralistes comme Llama 3.1 8B atteignent 72 % sur HumanEval, ce qui est compétitif. Mais les modèles de code dédiés de même taille obtiennent 5 à 15 % de plus, car leurs données d'entraînement et leur affinage privilégient la précision du code plutôt que les tâches de langage général.
📌Remarque: Les scores SWE-bench annoncés par les éditeurs utilisent des harnais d'agent, des jeux de tâches et des réglages différents (les 61,7 de Qwen sur SWE-bench Pro utilisent le harnais Claude Code avec des tâches corrigées) ; deux chiffres publiés sont donc des indications, pas une comparaison directe. HumanEval reste utile pour comparer la génération de fonctions isolées, mais SWE-bench prédit mieux les performances en développement réel.
#1 Qwen3.8 27B -- Meilleur LLM local global pour coder
Qwen3.8 27B (Alibaba, sorti en août 2026) est le meilleur LLM local pour coder sur un GPU de 24 Go ou un Mac de 32 Go. C'est un modèle dense de 27B (tous les paramètres actifs par token) sous licence Apache 2.0. Qwen annonce 61,7 sur SWE-bench Pro, 73,0 sur Terminal Bench 2.1 et 90,3 sur LiveCodeBench v6. Le téléchargement Ollama fait 18 Go avec une fenêtre de contexte de 256K.
`ollama run qwen3.8`. Il accepte le texte et les images, gère l'appel d'outils et le mode réflexion, et convient à l'analyse multi-fichiers, au débogage et au refactoring. Qwen a annoncé 53,5 sur SWE-bench Pro pour le Qwen 3.6 27B précédent (77,2 % sur SWE-bench Verified) ; `ollama run qwen3.6:27b` reste une solution de repli valable.
Spécification | Valeur |
|---|---|
| SWE-bench Pro | 61,7 (selon Qwen) |
| LiveCodeBench v6 | 90,3 (selon Qwen) |
| Architecture | Dense (27B actifs) |
| Taille Ollama (Q4_K_M) | 18 Go |
| Fenêtre de contexte | 256K tokens |
| Licence | Apache 2.0 |
| Commande Ollama | ollama run qwen3.8 |
🔍Point clé: Qwen exécute SWE-bench Pro avec le harnais Claude Code et un jeu de tâches affiné dont les tâches problématiques ont été corrigées ; les 61,7 ne sont donc pas directement comparables aux scores publiés par d'autres éditeurs. C'est un signal fort annoncé par l'éditeur, pas un test comparatif direct.
#2 Devstral Small 2 -- Meilleur pour le codage agentique à 24B
Devstral Small 2 (Mistral AI) est conçu pour les workflows de codage agentique — modifications multi-fichiers, génération de code avec appel d'outils et boucles de débogage. 24B de paramètres, 15 Go sur Ollama, 65,8 % sur SWE-bench Verified (selon Mistral), Apache 2.0. `ollama run devstral-small-2` (nécessite Ollama 0.13.3 ou plus récent).
Le meilleur choix pour les développeurs qui utilisent aider, des workflows de type Claude Code ou des modifications de code en plusieurs étapes sur une machine de 16 Go. Il lit les retours d'erreur, modifie le code sur plusieurs fichiers et accepte les images.
Spécification | Valeur |
|---|---|
| SWE-bench Verified | 65,8 % (selon Mistral) |
| Idéal pour | Workflows agentiques, multi-fichiers |
| Taille Ollama | 15 Go |
| Fenêtre de contexte | 384K tokens (Ollama) |
| Licence | Apache 2.0 |
| Commande Ollama | ollama run devstral-small-2 |
💡Astuce: Codage agentique = raisonner → écrire du code → exécuter → observer les erreurs → corriger → itérer. Devstral Small 2 gère cette boucle avec 15 Go d'empreinte, ce qui en fait le choix agentique pratique pour les machines de 16 Go où Qwen3.8 27B (18 Go) ne tient pas.
#3 Laguna XS 2.1 et Qwen3-Coder-Next -- Codage agentique longue durée
Laguna XS 2.1 (Poolside, 2 juillet 2026) vise le codage agentique longue durée. MoE 33B total / 3B actifs, contexte 256K, licence OpenMDW-1.1, SWE-bench Verified 70,9 % et SWE-bench Multilingual 63,1 %. Le tag Ollama par défaut pèse 20 Go (Q4_K_M). `ollama run laguna-xs-2.1`.
Qwen3-Coder-Next (Alibaba, février 2026) est l'option MoE plus grande pour les machines de 64 Go : 80B total / 3B actifs, 52 Go en Q4_K_M, contexte 256K. `ollama run qwen3-coder-next`. Pour un modèle de code plus petit et conscient du dépôt avec 24 Go, `ollama run qwen3-coder:30b` (30B total / 3,3B actifs, 19 Go, Apache 2.0) est l'alternative établie.
Si vous voulez la plus grande fenêtre de contexte pour des sessions agentiques de plusieurs heures, choisissez Laguna XS 2.1 ; si vous voulez un modèle d'origine européenne sous Apache 2.0 avec une empreinte plus petite, choisissez Devstral Small 2.
Spécification | Valeur |
|---|---|
| Taille Laguna XS 2.1 | 20 Go (33B total / 3B actifs) |
| SWE-bench Laguna XS 2.1 | 70,9 % Verified / 63,1 % Multilingual |
| Taille Qwen3-Coder-Next | 52 Go (80B total / 3B actifs) |
| Fenêtre de contexte | 256K tokens (les deux) |
| Commandes Ollama | laguna-xs-2.1 / qwen3-coder-next |
🔍Point clé: Les modèles MoE gardent tous leurs paramètres en mémoire mais ne calculent qu'avec quelques milliards par token : ils génèrent vite pour leur taille tout en exigeant la RAM pour l'ensemble des poids (20 Go pour Laguna XS 2.1, 52 Go pour Qwen3-Coder-Next).
#4 Codestral 22B -- Meilleur pour l'autocomplétion en IDE
Codestral 22B (Mistral AI) reste le modèle FIM dédié à l'autocomplétion en IDE. Conçu pour la complétion fill-in-the-middle avec Continue.dev dans VS Code et Cursor. C'est le modèle le plus ancien de cette page (le build Ollama a environ deux ans) et il reste l'option la plus axée sur le FIM.
`ollama run codestral:22b`. Entraîné pour la complétion de type IDE, où le contexte se trouve avant et après le curseur. Solide sur Python, JavaScript, TypeScript, Go et Rust. Le build Ollama a une fenêtre de contexte de 32K.
Pour une complétion consciente du dépôt, `ollama run qwen3-coder:30b` est la meilleure alternative à poids ouverts (Apache 2.0, 19 Go). Pour un petit modèle de code capable de raisonner sur 16 Go, `ollama run gpt-oss:20b` (poids ouverts d'OpenAI, MoE 21B total / 3,6B actifs, raisonnement réglable) est aussi un choix solide.
Spécification | Valeur |
|---|---|
| Idéal pour | FIM (autocomplétion en IDE) |
| Taille Ollama | 13 Go |
| Fenêtre de contexte | 32K tokens |
| Prise en charge FIM | Oui (usage principal) |
| Intégration IDE | Continue.dev, Cursor |
| Commande Ollama | ollama run codestral:22b |
🔍Point clé: Codestral 22B de Mistral AI est conçu spécifiquement pour la complétion FIM (fill-in-the-middle). Associé à Continue.dev, il offre une alternative locale à l'autocomplétion de GitHub Copilot.
#5 Qwen3 8B -- Meilleur modèle de code pour 8 Go de RAM
Qwen3 8B est la recommandation pour la tranche de 8 Go. Bonnes performances en code, multilingue, seulement 5 Go de VRAM. Qwen3.8 n'existe pour l'instant sur Ollama qu'en 27B : Qwen3 8B reste donc le plus petit choix Qwen actuel. Pour plus de détails sur la VRAM des autres modèles de code, voir le guide des besoins en VRAM →. `ollama run qwen3:8b`.
🔍Point clé: Qwen3 8B est le point de départ recommandé pour les machines de 8 Go : excellent support multilingue, inférence rapide et bonne qualité de code sur des tâches réelles.
Pourquoi Kimi K2.6 et K2.7 Code ne sont pas un choix local pratique
Kimi K2.6 et Kimi K2.7 Code (Moonshot AI) sont les plus grands modèles de code à poids ouverts de cette liste, mais pas un choix pour le matériel grand public. Ce sont deux modèles MoE de 1T de paramètres, 32B actifs et 256K de contexte. Moonshot AI a annoncé 58,6 sur SWE-bench Pro pour Kimi K2.6 ; Kimi K2.7 Code s'appuie sur K2.6 pour les longues sessions de code.
Sur Ollama, les deux ne sont listés qu'en tags cloud (`kimi-k2.6:cloud`, `kimi-k2.7-code:cloud`), qui envoient vos prompts au service hébergé d'Ollama. L'exécution locale passe par un build GGUF communautaire : Unsloth indique environ 310 Go en 1 bit et 325 à 350 Go en 2 bits pour K2.7 Code ; ils relèvent donc du matériel de station de travail ou de serveur, pas des portables.
⚠️Attention: Un tag `:cloud` n'est pas de l'inférence locale. Si la confidentialité est la raison d'un modèle local, utilisez plutôt Qwen3.8 27B, Devstral Small 2 ou Laguna XS 2.1.
Comment se comparent les modèles de code ? SWE-bench + HumanEval
Modèle | HumanEval | SWE-bench | RAM | FIM |
|---|---|---|---|---|
| Qwen3.8 27B | — | 61,7 (Pro) | 18 Go | — |
| Qwen 3.6 27B | — | 77,2 % (Verified) / 53,5 (Pro) | ~22 Go | — |
| Devstral Small 2 | — | 65,8 % (Verified) | 15 Go | — |
| Laguna XS 2.1 (MoE) | — | 70,9 % (Verified) | 20 Go (3B actifs) | — |
| Qwen3-Coder-Next (MoE) | — | varie selon le harnais | 52 Go (3B actifs) | — |
| Kimi K2.6 (MoE) | — | 58,6 (Pro) | 300+ Go (cloud sur Ollama) | — |
| Codestral 22B | — | — | 13 Go | Oui (principal) |
| Qwen2.5-Coder 32B | — | — | 20 Go | Oui |
| Qwen3 8B | — | — | 5 Go | Oui |
| DeepSeek-R1 14B | — | — | 10 Go | Non |
📌Remarque: HumanEval mesure la génération de fonctions Python isolées. SWE-bench mesure des modifications de code réelles sur plusieurs fichiers. « Pro » et « Verified » sont des variantes différentes de SWE-bench et ne sont pas interchangeables : un score de 77,2 % Verified et un score de 61,7 Pro ne se comparent pas directement. Tous les scores sont annoncés par les éditeurs. Les chiffres HumanEval des modèles plus anciens (Qwen2.5-Coder 32B, Qwen3 8B) proviennent de versions antérieures de cette page et n'ont pas été revérifiés.
Quel modèle convient à quelle tâche de code ?
- 1Débogage de fonctions Python et refactoring multi-fichiers -- Qwen3.8 27B est le premier choix : un modèle dense garde ses 27B paramètres actifs par token, ce qui convient au raisonnement multi-fichiers. Devstral Small 2 est l'alternative plus légère quand seuls 16 Go sont disponibles. Choix : Qwen3.8 27B.
- 2Boucles agentiques (planifier → modifier → lancer les tests → corriger) -- Devstral Small 2 et Laguna XS 2.1 sont conçus pour l'appel d'outils et les longues sessions. Laguna XS 2.1 offre 256K de contexte ; Devstral Small 2 consomme moins de mémoire. Choix : Laguna XS 2.1 pour les longues sessions, Devstral Small 2 pour les machines de 16 Go.
- 3FIM / autocomplétion en IDE (VS Code) -- Le fill-in-the-middle exige un modèle entraîné pour cela. Codestral 22B et Qwen3 8B fonctionnent via Continue.dev ; les modèles Kimi, Laguna et Devstral ne sont pas axés sur le FIM. Choix : Codestral 22B.
- 4Scripts rapides sur portables de 8 Go -- Qwen3 8B gère les scripts courants, le SQL et le code répétitif avec une faible latence. Attendez-vous à des résultats plus faibles sur les grands systèmes de types et les modifications multi-fichiers. Choix : Qwen3 8B.
🔍Point clé: Les grands modèles obtiennent de meilleurs scores que les modèles 8B sur les tâches de type SWE-bench (débogage et refactoring multi-fichiers) ; pour le scripting courant, l'écart se réduit. Choisissez le modèle d'abord selon la tâche, puis selon votre budget mémoire.
Quel modèle de code équilibre le mieux vitesse et qualité de sortie ?
Tâche | Qwen3.8 27B | Devstral Small 2 | Qwen3 8B | Codestral 22B |
|---|---|---|---|---|
| Refactoring et débogage multi-fichiers | Premier choix (dense, 18 Go) | Bon (15 Go) | Limité sur les grosses modifications | Pas son domaine |
| Boucles agentiques avec outils | Solide (outils, réflexion) | Conçu pour cela | Basique | Pas son domaine |
| Code répétitif, API REST, tests | Solide, plus lent | Solide | Rapide, vérifier la validation | Rapide, générique |
| Autocomplétion FIM (curseur en milieu de ligne) | Pas son domaine | Pas son domaine | Pris en charge | Meilleur choix (FIM) |
💡Astuce: À retenir : les modèles de 18 Go et 15 Go sont plus lents par token que les modèles 8B mais plus précis sur les tâches de raisonnement. Pour l'autocomplétion en IDE, n'utilisez que des modèles optimisés FIM (Codestral 22B, Qwen3 8B). Le débit dépend de votre GPU, de la quantification et de la longueur du contexte : testez sur votre propre machine.
🛠️Bonne pratique: Recommandation pratique : choisissez selon le type de tâche. Pour la génération de code par lots ou les revues de refactoring, utilisez Qwen3.8 27B. Pour les boucles agentiques à 16 Go, Devstral Small 2. Pour l'autocomplétion en IDE en temps réel, Codestral 22B ou Qwen3 8B, là où la latence compte le plus.
Quel LLM local pour coder choisir ?
Le modèle choisi compte, mais la manière de le solliciter compte encore plus pour la qualité du code. Les techniques de prompt structurées — préciser le langage, les contraintes, les cas de test et le format de sortie — améliorent fortement la précision de la génération de code. Le guide de prompt engineering couvre 80 techniques : fondamentaux, frameworks et méthodes d'évaluation.
Pour un workflow IDE complet autour de ces modèles, voir Remplacer GitHub Copilot par un LLM local — la pile open source (Continue.dev + Ollama + Qwen3-Coder) s'accorde bien avec les choix ci-dessus.
- 8 Go de RAM, orienté code : `ollama run qwen3:8b` -- 5 Go de VRAM, meilleur modèle de cette tranche.
- 16 Go de RAM : `ollama run devstral-small-2` -- meilleur pour le codage agentique à 24B (modifications multi-fichiers, boucles de débogage), 15 Go.
- GPU de 24 Go ou Mac de 32 Go (meilleure qualité) : `ollama run qwen3.8` -- Qwen3.8 27B, 18 Go, 61,7 SWE-bench Pro (selon Qwen).
- Longues sessions agentiques : `ollama run laguna-xs-2.1` -- 20 Go, contexte 256K, SWE-bench Verified 70,9 %.
- Machines de 64 Go : `ollama run qwen3-coder-next` -- MoE 80B avec 3B actifs, 52 Go.
- Autocomplétion en IDE dans VS Code : `ollama run codestral:22b` via Continue.dev -- optimisé FIM, meilleure alternative locale à Copilot.
🛠️Bonne pratique: Adaptez d'abord la taille du modèle à votre matériel, puis optimisez selon votre usage. Avec 8 Go, Qwen3 8B est le meilleur choix. Avec 16 Go, utilisez Devstral Small 2. Avec 24 Go ou plus, Qwen3.8 27B. Mieux vaut un modèle qui tourne bien que le modèle parfait qui peine.
Meilleurs LLMs de programmation pour 8 GB VRAM (RTX 3060 12GB / RTX 3070 8GB / RX 6800 16GB)
Sur les machines avec 8 GB RAM, Qwen3 8B est le meilleur choix pour la programmation — il n'utilise que 5 GB VRAM, laissant 3 GB pour votre IDE, navigateur et autres applications. Qwen3 8B inclut la prise en charge FIM (fill-in-the-middle) pour l'autocomplétion VS Code via Continue.dev.
- Qwen3 8B (recommandé) — 5 GB VRAM, 20–35 tok/sec, support FIM. `ollama run qwen3:8b`
- Phi-4 Mini 3.8B — 68% MMLU (raisonnement), 2,5 GB VRAM, meilleur pour l'inférence légère. `ollama run phi4-mini`
- Llama 3.2 3B — 40–60 tok/sec, 2,5 GB VRAM, bon recours pour les configurations très contraintes. `ollama run llama3.2:3b`
Meilleurs LLM de code pour 16 Go de VRAM (RTX 4070 Ti 16GB / RTX 5070 Ti 16GB / cartes de 24 Go)
Avec 16 Go, Devstral Small 2 (15 Go) convient le mieux au codage agentique. Qwen3.8 27B (téléchargement de 18 Go) demande un GPU de 24 Go ou un Mac de 32 Go de mémoire unifiée ; c'est le meilleur choix si vous avez cette marge.
- Devstral Small 2 — meilleur pour le codage agentique, l'appel d'outils, les modifications multi-fichiers, 15 Go. `ollama run devstral-small-2`
- Qwen3.8 27B — meilleur choix global, dense 27B, 18 Go, contexte 256K, tient sur une carte de 24 Go. `ollama run qwen3.8`
- Qwen3-Coder 30B — MoE 30B/3,3B actifs, 19 Go, complétion consciente du dépôt sur une carte de 24 Go. `ollama run qwen3-coder:30b`
Meilleurs LLMs de programmation pour 6 GB VRAM (GPUs budgétaires / Graphiques intégrés)
Pour les machines avec 4–6 GB VRAM (GPUs budgétaires, anciens ordinateurs portables, GPU intégré Intel), Phi-4 Mini 3.8B est le meilleur choix — il atteint une performance de raisonnement MMLU de 68% tout en utilisant seulement 2,5 GB VRAM. Cela laisse ~3,5 GB pour votre système.
- Phi-4 Mini 3.8B (recommandé) — 68% MMLU raisonnement, 2,5 GB VRAM, excellent pour la logique et le débogage. `ollama run phi4-mini`
- Qwen3 4B — variante plus petite, 4 GB VRAM, équilibre qualité-vitesse pour le matériel budgétaire. `ollama run qwen3:4b`
🧭 Qui doit utiliser quoi : profils et recommandations
- Débutant (aucune expérience des LLM locaux) : LM Studio + Qwen3 8B -- interface graphique, pas de terminal, FIM pour la complétion de code, 5 Go de VRAM.
- Développeur sur portable (8 à 16 Go de RAM, code au quotidien) : Ollama + Qwen3 8B (machines de 8 Go) ou Devstral Small 2 (machines de 16 Go) -- qualité et performances équilibrées, fluide pendant des heures.
- Développeur avancé (débogage, refactoring, raisonnement complexe, 24 Go et plus) : Ollama + Qwen3.8 27B (modèle dense, 18 Go) -- gère le contexte multi-fichiers et la conception d'algorithmes.
- Longues sessions agentiques (planifier → coder → tester → itérer) : Ollama + Laguna XS 2.1 (contexte 256K, SWE-bench Verified 70,9 %) ou Devstral Small 2 -- conçus pour l'appel d'outils et les exécutions en plusieurs étapes.
- Workflow centré IDE (VS Code, Cursor, JetBrains) : Continue.dev + Codestral 22B -- optimisé FIM pour la complétion à la position du curseur, meilleure alternative locale à Copilot.
- Environnements sensibles à la confidentialité (RGPD, HIPAA, code propriétaire) : n'importe quel modèle local ci-dessus via Ollama (pas un tag `:cloud`) -- aucun appel d'API externe pour l'inférence, donc votre code reste sur votre machine tant que vos plugins d'éditeur et autres outils n'utilisent pas non plus le réseau.
⚠️Attention: ❌ À éviter : exécuter Qwen3.8 27B (18 Go) sur des machines sans GPU de 24 Go ni Mac de 32 Go. Dès que le modèle déborde en RAM système, la vitesse chute fortement. Utilisez Qwen3 8B ou Devstral Small 2 sur les machines plus petites.
⚠️Attention: ❌ À éviter : utiliser des modèles généralistes (Llama 3.1 8B) quand vous avez besoin d'autocomplétion en IDE. Seuls les modèles spécialisés en code avec prise en charge FIM fonctionnent pour la complétion dans l'éditeur -- Codestral 22B, Qwen3 8B.
🔍Point clé: Débutant → intermédiaire → avancé est aussi une progression des besoins matériels. Commencez avec Qwen3 8B (8 Go), passez à Devstral Small 2 (16 Go) quand vous ajoutez des outils et des workflows, puis à Qwen3.8 27B (24 Go et plus) quand il vous faut la meilleure qualité de raisonnement.
❌ Quand NE PAS utiliser les LLMs locaux pour la programmation
- Vous avez besoin de connaissances récentes sur les frameworks (API 2025+) : les modèles locaux sont entraînés jusqu'à une date limite fixe et ne connaissent pas les API publiées après l'entraînement. Pour des versions récentes de frameworks, fournissez la documentation à jour dans le prompt ou utilisez un modèle cloud de pointe comme GPT-5.6 ou Claude Sonnet 5.
- Vous avez besoin de raisonnement multi-fichiers sur de grandes codebases (100k+ jetons) : Les modèles locaux se dégradent sur des contextes très longs. La latence devient prohibitive. Les modèles cloud (GPT-5.6, Claude) gèrent nativement les contextes 100k+ jetons. Pour la refactorisation architecturale de services entiers, utilisez les modèles cloud.
- La latence doit être <300ms (programmation interactive en temps réel) : Les modèles locaux s'exécutent à 15-25 jetons/sec sur CPU (ordinateurs portables typiques), produisant un délai de 5-10 secondes par réponse. GitHub Copilot et Claude dans l'IDE complètent les suggestions en <1 seconde. Pour l'autocomplétion au niveau des touches, les modèles locaux sont trop lents.
- Vous avez besoin de la meilleure précision de débogage : sur les tâches de débogage complexes (suivi de plusieurs piles d'appels, repérage d'erreurs de type subtiles), les modèles cloud de pointe comme GPT-5.6 et Claude Sonnet 5 restent généralement en tête sur les problèmes de code réels. Les modèles locaux sont solides en génération ; les modèles de pointe tendent à être meilleurs en diagnostic.
- Vous ne pouvez pas tolérer d'hallucination dans le code généré : les petits modèles locaux peuvent produire du code syntaxiquement valide mais logiquement faux sur des tâches complexes, et les modèles cloud plus grands sont généralement plus fiables. Pour le code critique (systèmes de paiement, sécurité), une relecture humaine de tout le code généré est indispensable.
🔍Point clé: 👉 Les LLMs locaux sont meilleurs pour : Confidentialité + travail hors ligne + contrôle des coûts — PAS pour la performance maximale. Si la précision maximale importe plus que ces trois facteurs, utilisez les APIs cloud.
📊 Meilleurs LLM locaux pour coder comparés (matrice de décision)
Vous hésitez entre plusieurs modèles de code ? PromptQuorum envoie un même prompt à plusieurs modèles simultanément (Qwen3.8, Devstral, GPT-5.6, Claude) et affiche côte à côte les sorties, les temps de réponse réels et la précision sur VOTRE code. Essayez PromptQuorum gratuitement — 5 minutes, sans inscription.
Modèle | Idéal pour | VRAM | Vitesse | Atout | Quand le choisir |
|---|---|---|---|---|---|
| Qwen3.8 27B | Meilleur global, raisonnement multi-fichiers | ~18 Go | selon le GPU | 61,7 SWE-bench Pro (selon Qwen), dense 27B, contexte 256K, Apache 2.0 | Vous avez un GPU de 24 Go ou un Mac de 32 Go et voulez la meilleure qualité locale |
| Devstral Small 2 | Codage agentique à 24B | ~15 Go | selon le GPU | 65,8 % SWE-bench Verified (selon Mistral), appel d'outils, multi-fichiers, Apache 2.0 | Vous utilisez aider ou des agents de type Claude Code avec 16 Go |
| Laguna XS 2.1 | Codage agentique longue durée | ~20 Go (3B actifs) | selon le GPU | SWE-bench Verified 70,9 %, contexte 256K, MoE 33B/3B actifs, OpenMDW-1.1 | Vous lancez des sessions agentiques de plusieurs heures avec 256K de contexte |
| Qwen3-Coder-Next | Grand MoE sur machines de 64 Go | ~52 Go (3B actifs) | selon le GPU | MoE 80B total/3B actifs, contexte 256K | Vous avez 64 Go de mémoire unifiée et voulez un modèle de code plus grand |
| Codestral 22B | Autocomplétion en IDE (VS Code, Cursor) | ~13 Go | selon le GPU | Optimisé FIM, meilleure alternative locale à Copilot, natif Continue.dev | Vous voulez l'autocomplétion à chaque frappe via Continue.dev |
| Qwen3 8B | Code sur portable, idéal pour 8 Go de RAM | ~5 Go | le plus rapide ici | Code amélioré, prise en charge FIM, multilingue | Vous avez 8 Go de RAM et voulez le meilleur modèle de code local de cette tranche |
| Kimi K2.6 / K2.7 Code | Poids ouverts à l'échelle frontière | 300+ Go (tag cloud sur Ollama) | classe serveur | MoE 1T total/32B actifs, contexte 256K | Vous avez du matériel de station ou de serveur, ou acceptez un tag cloud |
| GPT-5.6 (cloud) | API récentes, raisonnement complexe, performances maximales | S.O. (cloud) | <1 s | Meilleure précision, connaissances récentes, raisonnement multi-fichiers | Vous avez besoin de performances maximales, de latence temps réel ou de connaissances récentes |
| Claude Sonnet 5 (cloud) | Revue de code, décisions d'architecture, débogage | S.O. (cloud) | <1 s | Excellent pour comprendre le code, déboguer, gérer le contexte multi-fichiers | Vous privilégiez la précision du débogage et la revue de code plutôt que le coût ou la confidentialité |
Comment les exigences régionales affectent votre choix de modèle de programmation?
EU / RGPD
Pour les équipes de développement logiciel de l'UE travaillant sur des codebases propriétaires, la génération de code local signifie que le code source ne quitte jamais l'infrastructure de l'organisation. Le RGPD Article 32 exige des mesures de sécurité techniques appropriées — transmettre le code source aux APIs IA cloud crée une relation de responsable de traitement supplémentaire en vertu de l'Article 28. L'inférence locale l'élimine.
Qwen3.8 27B (Alibaba, Apache 2.0) et DeepSeek-Coder V2 (DeepSeek, MIT) tournent tous deux entièrement sur site. Pour les organisations de l'UE qui préfèrent un modèle d'origine européenne : les modèles de code de Mistral (Mistral Small 3.1, Codestral, Devstral Small 2) viennent de Mistral AI (France) ; Devstral Small 2 est sous Apache 2.0, tandis que les conditions de licence de Codestral diffèrent et doivent être vérifiées. Laguna XS 2.1 utilise OpenMDW-1.1 (permissive, usage commercial autorisé, non approuvée par l'OSI) -- confirmez toujours les conditions de licence avant un déploiement commercial. Le règlement européen sur l'IA classe potentiellement la génération de code assistée par IA pour les infrastructures critiques comme à haut risque -- l'inférence sur site garde le pipeline dans votre périmètre de sécurité existant.
Japon, Chine, régions à conformité élevée
Selon la loi chinoise sur la sécurité des données (数据安全法), le code source des infrastructures d'information critiques ne peut pas être traité par des services cloud étrangers. Qwen3.8 27B et Qwen3-Coder (Alibaba, Apache 2.0) sont le choix naturel pour les workflows de développement des entreprises chinoises -- développeur chinois, licence Apache 2.0, déploiement local complet via Ollama. Kimi K2.6 (Moonshot AI) est aussi d'origine chinoise mais demande du matériel de classe serveur en local. Ceci ne constitue pas un avis juridique ; vérifiez les exigences applicables à votre cas.
Quelles sont les erreurs courantes avec les modèles de programmation locaux?
- Utiliser un modèle polyvalent au lieu d'un modèle spécifique au code : Qwen3 8B et Llama 3.1 8B général sont proches sur le benchmark HumanEval — mais Qwen3-Coder inclut le support FIM (Fill-in-the-Middle) que Llama 3.1 8B général n'a pas. Pour l'autocomplétion IDE, utilisez toujours un modèle spécifique au code.
- Ne pas définir la longueur du contexte pour l'examen multi-fichiers : Ollama par défaut à 2048 jetons. La plupart des fichiers de code sont 1,000-3,000 jetons. Définissez `PARAMETER num_ctx 32768` minimum pour toute tâche de programmation impliquant des fichiers entiers ou plusieurs fonctions en contexte.
- Attendre que les modèles remplacent les IDEs complets : Les modèles de programmation locaux excellent à la génération au niveau des fonctions, l'explication des bugs et les suggestions de refactorisation. Ils ne remplacent pas LSP (Language Server Protocol) pour la détection d'erreurs en temps réel ou la vérification de type. Utilisez Continue.dev ou Cursor pour combiner la génération de modèle local avec l'outillage IDE complet.
- Utiliser Q3_K_S sur les modèles de programmation pour économiser RAM : La quantification en dessous de Q4_K_M dégrade notablement la précision de génération de code — les erreurs logiques et les erreurs de syntaxe augmentent. Pour les tâches de programmation, utilisez Q4_K_M minimum. Si la RAM est serrée, choisissez un modèle plus petit à Q4_K_M plutôt qu'un modèle plus grand à Q3_K_S.
- Extraire qwen2.5-coder sans spécifier la taille : `ollama pull qwen2.5-coder` par défaut à la plus petite variante disponible. Spécifiez explicitement : `ollama pull qwen2.5-coder:7b` pour les machines 8 GB, `ollama pull qwen2.5-coder:32b` pour 24+ GB. L'extraction par défaut peut vous donner un modèle qui ne correspond pas à votre matériel.
- Le prompt engineering détermine la qualité du code indépendamment du modèle : Spécifier le langage, les contraintes, les cas de test et la gestion des erreurs dans votre prompt réduit considérablement le code halluciné. Voir comment mieux écrire du code avec l'IA pour des patterns éprouvés en production.
⚠️Attention: N'utilisez jamais de quantification inférieure à Q4_K_M pour les modèles de programmation. Q3_K_S économise RAM mais introduit des erreurs de syntaxe et des bugs logiques. Ce n'est pas un compromis judicieux pour la génération de code — utilisez soit Q4_K_M soit choisissez un modèle plus petit à précision complète.
Questions fréquentes
Quel est le meilleur LLM local pour coder ?
Qwen3.8 27B (Alibaba, Apache 2.0) — dense 27B, 18 Go, contexte 256K, 61,7 SWE-bench Pro selon Qwen. `ollama run qwen3.8`. Pour le codage agentique avec 16 Go : Devstral Small 2. Pour les longues sessions : Laguna XS 2.1. Pour l'autocomplétion en IDE : Codestral 22B. Pour les machines de 8 Go : Qwen3 8B.
Quel modèle Qwen est le meilleur pour coder ?
Qwen3.8 27B est le meilleur choix Qwen généraliste pour coder sur un GPU de 24 Go ou un Mac de 32 Go (18 Go, 61,7 SWE-bench Pro, selon Qwen). Qwen3-Coder-Next (80B total / 3B actifs, 52 Go) convient aux machines de 64 Go, Qwen3-Coder 30B (19 Go) à la complétion consciente du dépôt, et Qwen3 8B (5 Go) aux 8 Go de RAM.
Qwen est-il le meilleur LLM local pour coder ?
Sur la plupart des machines grand public, Qwen3.8 27B affiche aujourd'hui les meilleurs scores de code annoncés parmi les modèles exécutables en local, mais aucun modèle ne gagne sur toutes les tâches. Devstral Small 2 tient sur 16 Go et est conçu pour les boucles agentiques, Laguna XS 2.1 vise les longues sessions, et Codestral 22B est plus spécialisé pour l'autocomplétion en IDE. Les scores sont annoncés par les éditeurs avec des harnais différents : testez sur votre propre code.
Puis-je exécuter Kimi K2.6 ou Kimi K2.7 Code en local ?
Seulement sur du matériel de classe serveur. Ce sont deux modèles MoE de 1T de paramètres (32B actifs). Ollama ne les liste qu'en tags cloud (`kimi-k2.6:cloud`, `kimi-k2.7-code:cloud`), qui ne sont pas de l'inférence locale. Les builds GGUF communautaires de K2.7 Code demandent environ 310 Go (1 bit) à 350 Go (2 bits). Pour coder en local sur du matériel grand public, utilisez Qwen3.8 27B, Devstral Small 2 ou Laguna XS 2.1.
Que sont Devstral Small 2 et Laguna XS 2.1 ?
Ce sont deux modèles de codage agentique. Devstral Small 2 (Mistral AI, Apache 2.0) est un modèle de 24B à 15 Go avec 65,8 % sur SWE-bench Verified selon Mistral -- `ollama run devstral-small-2`. Laguna XS 2.1 (Poolside, 2 juillet 2026) est un MoE de 33B total / 3B actifs à 20 Go avec une fenêtre de contexte de 256K ; il obtient 70,9 % sur SWE-bench Verified et 63,1 % sur SWE-bench Multilingual sous licence OpenMDW-1.1 -- `ollama run laguna-xs-2.1`.
Qu'est-ce que HumanEval et pourquoi est-ce important ?
HumanEval est un benchmark de 164 problèmes de programmation Python. Le modèle doit générer un corps de fonction correct pour chacun. Le pass@1 (pourcentage résolu du premier coup) est la métrique standard. Il sert encore à comparer de petits modèles de code, mais teste des fonctions isolées plutôt que de vrais projets.
Qu'est-ce que le fill-in-the-middle (FIM) et quels modèles le prennent en charge ?
Le FIM est la capacité de compléter du code à partir du code situé avant et après le curseur -- le schéma de l'autocomplétion en IDE. Codestral 22B, Qwen3-Coder, DeepSeek-Coder et Starcoder2 prennent en charge le FIM. Llama 3.1 8B (généraliste) non. Pour l'intégration IDE, utilisez un modèle compatible FIM.
Les modèles de code locaux peuvent-ils remplacer GitHub Copilot ?
Codestral 22B via Continue.dev peut couvrir la plupart des tâches d'autocomplétion. Pour le raisonnement complexe multi-fichiers, les modèles cloud gardent généralement l'avantage sur les tâches les plus difficiles. Compromis : les modèles locaux sont plus lents mais entièrement privés et tournent sur votre propre matériel.
De quelle RAM ai-je besoin pour les LLM de code locaux ?
Minimum 4 Go (petits modèles 3B), en pratique 8 Go et plus pour un code utilisable. 16 Go font tourner Devstral Small 2 (15 Go). 24 Go de mémoire GPU ou un Mac de 32 Go font tourner Qwen3.8 27B (18 Go) ; sur le Mac, il reste environ 6 Go pour le contexte après les 8 Go de macOS. Règle empirique : les poids Q4_K_M occupent environ 0,6 Go par milliard de paramètres, plus la mémoire de la fenêtre de contexte.
Combien de contexte utilise un fichier Python de 500 lignes ?
Environ 2 000 à 3 000 tokens pour un fichier Python de 500 lignes. Le contexte par défaut d'Ollama (adapté à la VRAM) peut être insuffisant. Définissez au minimum `PARAMETER num_ctx 16384` pour la revue d'un seul fichier. Pour l'analyse multi-fichiers, utilisez 32768 ou 65536.
Les modèles de code locaux sont-ils assez rapides pour le développement ?
Oui pour les workflows itératifs. La vitesse dépend du GPU, de la quantification et de la longueur du contexte. Les petits modèles comme Qwen3 8B répondent vite sur portable ; les grands modèles sont plus lents par token. Attendre quelques secondes par réponse est acceptable pour demander puis relire, mais pas pour l'autocomplétion à chaque frappe, où il faut un petit modèle FIM.
Les LLM locaux peuvent-ils remplacer GPT-5.6 pour coder ?
Pas entièrement. Les modèles locaux (Qwen3.8 27B, Devstral Small 2) restent derrière les modèles cloud de pointe sur les connaissances récentes des frameworks (API postérieures à la date limite d'entraînement), le raisonnement multi-fichiers très long (100k+ tokens) et la précision du débogage. Ils ont réduit l'écart sur les tâches multi-fichiers courantes et gardent votre code privé.
Quel langage Qwen3-Coder prend-il le mieux en charge ?
Python est le langage d'entraînement principal. JavaScript, TypeScript, Java, C++, Go, Rust et SQL sont tous bien pris en charge. Le modèle gère aussi PHP, Ruby, Swift et Kotlin. Pour les langages non Python, les scores HumanEval sont plus bas mais restent compétitifs.
DeepSeek-Coder est-il sûr pour du code propriétaire ?
En exécution locale via Ollama, DeepSeek-Coder n'établit aucune connexion externe. Votre code reste sur votre matériel. Le problème de données lié à DeepSeek concerne son API cloud (api.deepseek.com), pas l'inférence locale avec Ollama. L'inférence locale n'envoie aucun code aux serveurs de DeepSeek.
Puis-je utiliser des modèles de code locaux pour générer du SQL ?
Oui -- Qwen3.8 27B et Devstral Small 2 gèrent la génération de SQL. Fournissez le schéma des tables dans le contexte du prompt. Pour les requêtes complexes avec plusieurs jointures, utilisez 32K de contexte pour inclure le schéma complet. Définissez un prompt système : « Vous êtes un expert SQL. Générez uniquement du SQL valide. »
Qu'est-ce que SWE-bench et pourquoi remplace-t-il HumanEval ?
SWE-bench teste la capacité d'un modèle à résoudre de vrais tickets GitHub — lire des bases de code, faire des modifications multi-fichiers et écrire des tests. Contrairement à HumanEval (fonctions Python isolées), SWE-bench prédit les performances d'un modèle dans de vrais workflows de développement. SWE-bench Verified et SWE-bench Pro sont des variantes différentes dont les scores ne sont pas interchangeables. En 2026, SWE-bench est le benchmark principal pour évaluer les modèles de code en usage réel.
Comment connecter un modèle de code local à VS Code ?
Installez l'extension Continue.dev depuis le marketplace de VS Code. Dans les paramètres de Continue, choisissez Ollama comme fournisseur et indiquez votre modèle (par ex. `qwen3:8b`, `qwen3.8`, `codestral:22b`). L'extension se connecte automatiquement à Ollama sur localhost:11434. Utilisez Cmd+I (macOS) ou Ctrl+I (Windows) pour lancer la génération de code en ligne.
Sources
- Équipe Qwen. (2026). Fiche du modèle « Qwen3.8-27B ». huggingface.co -- Apache 2.0, contexte 256K, SWE-bench Pro 61,7, LiveCodeBench v6 90,3, Terminal Bench 2.1 73,0.
- Ollama. (2026). Page « qwen3.8 » de la bibliothèque. ollama.com -- tag de 18 Go (Q4_K_M), contexte 256K.
- Mistral AI. (2026). « devstral-small-2 » sur Ollama. ollama.com -- 15 Go, SWE-bench Verified 65,8 %, nécessite Ollama 0.13.3 ou plus récent.
- Poolside. (2026). « Introducing Laguna XS 2.1 ». poolside.ai -- modèle de codage agentique, MoE 33B/3B actifs, SWE-bench Verified 70,9 %, licence OpenMDW-1.1.
- Ollama. (2026). Page « laguna-xs-2.1 » de la bibliothèque. ollama.com -- tag par défaut de 20 Go, contexte 256K.
- Ollama. (2026). Page « qwen3-coder-next » de la bibliothèque. ollama.com -- 80B total / 3B actifs, 52 Go Q4_K_M.
- Ollama. (2026). Page « kimi-k2.6 » de la bibliothèque. ollama.com -- seul un tag `:cloud` est listé.
- Unsloth. (2026). Guide d'exécution locale « Kimi K2.7 Code ». unsloth.ai -- MoE 1T/32B actifs, 310 à 470 Go de mémoire une fois quantifié.
- Ollama. (2026). Page « codestral » de la bibliothèque. ollama.com -- 22B, 13 Go, contexte 32K.
- Équipe Qwen. (2026). « Qwen3-Coder-Next Technical Report ». arxiv.org -- architecture et résultats de codage agentique pour Qwen3-Coder-Next.
- DeepSeek AI. (2024). « DeepSeek-Coder-V2 Technical Report ». arxiv.org/abs/2406.11931 -- architecture MoE et résultats de benchmarks de code pour DeepSeek-Coder V2 Lite.