Meilleur LLM open source pour le codage : un écart de coût de 48x dans notre test

Réponse courte : GLM-5.2 est actuellement le LLM open source le plus performant pour le code — en utilisation prolongée, la qualité de ses résultats se rapproche du niveau de Claude Sonnet, et c’est le modèle que nous confierions aux problèmes les plus difficiles. Il est aussi lent et gourmand en tokens, donc pour des agents de codage API rapides, choisissez Kimi K2.7 Code, pour le coût le plus bas DeepSeek V4 Flash, et pour votre propre GPU 24GB Qwen3.6-27B.

C’est la conclusion tirée du fait d’avoir soumis les deux mêmes tâches de codage à cinq modèles open source phares, avec Claude Opus 4.8 comme référence fermée. Tous ont produit un code correct. Ce qui les distinguait, c’était le nombre de tokens consommés pour y parvenir, et cette différence atteignait jusqu’à 48 fois en coût.

Une remarque sur la formulation : presque tous ceux-ci sont techniquement des modèles à poids ouverts : les poids sont libres, pas les données d’entraînement. Nous disons « open source » parce que c’est le terme que les gens recherchent. La distinction n’a d’importance que pour une réponse de la FAQ ci-dessous.

Comment nous avons testé

Deux tâches, même prompt pour chaque modèle, envoyées le 17 juillet 2026 avec les paramètres par défaut :

• Tâche 1: écrire une fonction d'analyse de durée avec des cas limites délicats (12 cas de test)
• Tâche 2: corriger une fonction de fusion d'intervalles boguée (6 cas de test)

Nous avons évalué le code localement et enregistré trois chiffres par exécution : le taux de réussite, le nombre de tokens de sortie et le temps écoulé. Le coût correspond au nombre de tokens multiplié par le prix public de chaque fournisseur, que nous avons vérifié le même jour. Deux tâches constituent une sonde, pas un benchmark, mais c’est le genre de demande courante que vous enverrez des centaines de fois.

Les résultats

Chaque modèle a réussi chaque cas de test. Le tableau ci-dessous ne concerne donc qu’une seule chose : l’efficacité :

La colonne des tokens raconte l’histoire. GLM-5.2 et MiniMax M3 sont des modèles « thinking » : par défaut, ils raisonnent longuement avant de répondre. Ce raisonnement est facturé comme output. Pour la même fonction correcte, GLM-5.2 a écrit 3x plus de tokens que Kimi K2.7 Code.

La situation empire avec un plafond de tokens. Lorsque nous avons limité les réponses à 2 048 tokens, les deux modèles de raisonnement ont consommé l’intégralité du budget à raisonner et ont renvoyé aucun code du tout. Vous payez, vous n’obtenez rien. GLM-5.2 avait besoin d’un plafond de 16 384 tokens avant de terminer, et ses deux tentatives infructueuses ont coûté à elles seules environ 0,045 $. Si vous utilisez un modèle de raisonnement dans un agent de codage, augmentez max_tokens ou désactivez le raisonnement pour les modifications courantes.

À titre de comparaison, Claude Opus 4.8 a résolu les deux tâches en 539 tokens. Les modèles ouverts ont rattrapé leur retard en termes de justesse ; en termes de brièveté, la référence fermée garde encore une avance de 4x.

Les meilleurs modèles de codage open source par niveau de déploiement

Choisissez en fonction de l’endroit où le modèle s’exécutera. Les prix sont par 1M de tokens, vérifiés le 2026-07-17.

Modèle le plus puissant, si vous pouvez attendre sa sortie : GLM-5.2

Pour les tâches de codage difficiles et en plusieurs étapes, la qualité de sortie de GLM-5.2 est ce qui se rapproche le plus, parmi les modèles ouverts actuels, du niveau de Claude — il est en tête des benchmarks agentiques (SWE-Bench Pro, Terminal-Bench 2.1), et dans notre propre utilisation prolongée, c’est celui auquel nous faisons confiance pour les problèmes que les autres ratent. Plus d’informations dans notre guide API de GLM-5.2.

Le prix de cette qualité est la patience. C’était le modèle le plus lent et le plus gourmand de notre test (99,3 s et 5 695 tokens sur la tâche 1), et la lenteur du service reflète davantage une capacité GPU contrainte du côté du fournisseur que le modèle lui-même. 1,40 $ en entrée / 4,40 $ en sortie, contexte de 1 M, MIT simple. Réservez-lui les problèmes difficiles et un gros budget de tokens ; orientez les modifications rapides ailleurs.

Idéal pour les agents de codage API rapides : Kimi K2.7 Code

Le modèle ouvert le plus économe en tokens que nous ayons testé : sa correction de bug n’a pris que 259 tokens, avec une concision à la Claude. Il domine également le benchmark d’achèvement des tâches de Kilo avec 60,7 %.

Tarification : 0,95 $ en entrée / 4,00 $ en sortie, 0,19 $ en cas de cache hit. La seule vraie limite est le contexte : 262K tokens, tandis que le reste de cette liste offre 1M. Pour voir comment il se compare à son rival le plus proche, consultez Kimi K2.7 Code vs GLM-5.2.

Meilleur rapport qualité-prix : DeepSeek V4 Flash

0,14 $ en entrée / 0,28 $ en sortie, de loin le modèle le moins cher ici, et il a quand même réussi à tout ce que nous lui avons soumis, le plus rapide parmi les modèles ouverts. Ses scores publiés (79,0 % SWE-Bench Verified, 91,6 % LiveCodeBench) se situent à deux points près de ceux de son grand frère. Le contexte est de 1 M de tokens, et la licence est un simple MIT.

Commencez ici. Passez à V4 Pro seulement lorsque le travail sur plusieurs fichiers commence à révéler l'écart.

Meilleur sur un GPU grand public de 24 Go : Qwen3.6-27B

Un dense 27B qui obtient 77.2 % sur SWE-Bench Verified, avec des scores proches d’un flagship pour un modèle qui tient sur une seule carte grand public, ce qui en fait la réponse récurrente dans les fils r/LocalLLaMA qui commencent par « I have 24GB of VRAM. »

Son frère plus rapide Qwen3-Coder-Next (80B au total, seulement 3B actifs par token, Apache 2.0) est le choix de la communauté pour la vitesse : un utilisateur l’a exécuté à ~20 tokens/s sur une seule RX 9070 XT avec un contexte complet de 262K. Si vous préférez l’utiliser via une API, il commence à $0.30/$1.50 via Alibaba Cloud.

Meilleur auto-hébergement sur une seule GPU : Gemma 4 31B

Selon la fiche modèle de Google, le 31B tient sur un seul H100 de 80 Go avec un contexte de 256K, sous licence Apache 2.0. La variante 12B fonctionne avec 16 Go de VRAM.

Un piège de dimensionnement : les modèles MoE annoncent de petits nombres de paramètres « actifs », mais vous devez quand même stocker l’ensemble des poids. DeepSeek V4 Flash active 13B par token mais pèse 284B au total, soit environ 142 Go même en 4 bits. C’est un projet multi-GPU, pas une seule carte.

Meilleur choix économique pour les longues exécutions autonomes : MiniMax M3

Contexte de 1M à 0,30 $/1,20 $, conçu pour des sessions d’agent de plusieurs heures — MiniMax a démontré une exécution de recherche sans surveillance de 12 heures. Il partage la verbosité du modèle de raisonnement que vous avez vue dans le tableau des résultats, alors prévoyez vos jetons en conséquence. Lorsque la qualité importe plus que le coût sur une exécution longue, GLM-5.2 ci-dessus est la mise à niveau.

Ce que les classements ne vous disent pas

Les chiffres des benchmarks sont désormais proches : l’AI Index de Stanford a constaté que l’écart entre le modèle n°1 et le modèle n°10 est passé de 11,9 % à 5,4 % en un an. Trois choses que les tableaux de scores cachent encore :

Le coût par tâche est plus avantageux que le coût par token. Le prix de sortie de 4,40 $ de GLM-5.2 semble proche des 4,00 $ de Kimi. Après le comptage réel des tokens, la même tâche coûte 3,5 fois plus cher. Les statistiques en direct de Kilo montrent le cas extrême : DeepSeek V4 Pro affiche en moyenne 15,91 $ par tentative de benchmark terminée pour un prix affiché de 0,87 $.

Même modèle, harnais différent, résultat différent. Un modèle intégré à une boucle d'agent bien conçue (outils structurés, nouvelles tentatives, limites de jetons raisonnables) ne se comporte pas du tout comme ce même modèle dans un simple appel de chat brut. Nos échecs sans code avec GLM relevaient d'une interaction de configuration, et non d'un manque de capacité.

Chaque benchmark mesure une tâche différente. LiveCodeBench concerne la génération algorithmique ; DeepSeek V4 Pro y obtient 93,5 %, au-dessus des scores publiés des modèles fermés. SWE-Bench Verified concerne la correction de bugs au niveau du dépôt ; Claude Mythos 5 reste en tête à 95,5 %, tandis que les modèles ouverts sont autour de 80 %. Faites correspondre le benchmark à votre travail réel avant de vous fier à un classement.

Remplacer un abonnement Claude

Un déclencheur courant pour passer à l’open source : atteindre les limites d’abonnement de Claude en plein milieu de la journée de travail. Les calculs tiennent la route. Notre test à deux tâches a coûté $0.00066 sur DeepSeek V4 Flash ; quelques centaines d’appels de ce type par jour restent malgré tout sous un dollar.

Le changement demande aussi moins de plomberie qu’avant. DeepSeek publie un endpoint compatible Anthropic (api.deepseek.com/anthropic), donc Claude Code peut l’utiliser avec un simple changement de variable d’environnement ; la même configuration fonctionne pour GLM-5.2. Et si vous voulez garder Claude pour les problèmes difficiles tout en confiant les tâches routinières à des modèles ouverts, des plateformes comme AIReiter proposent Claude à 20 % du prix catalogue via la même interface compatible Anthropic.

Kimi K3 : celui à surveiller

Moonshot a lancé Kimi K3 le 16 juillet 2026, et pour le travail frontend, il a déjà dépassé le modèle fermé le plus performant : n°1 du classement Frontend Code avec 1 679 contre 1 631 pour Claude Fable 5, et les premiers retours d’expérience vont dans le même sens.

Il n’est pas classé ici pour une seule raison : les weights ouvrent le 27 juillet. D’ici là, il s’agit d’une API fermée à $3/$15. Une fois publiés, K3 devient le plus grand modèle open-weight sorti à ce jour, et les chiffres du frontend ci-dessus suggèrent qu’il pourra prétendre au sommet de cette liste. Nous suivons séparément la publication des open-weights de K3.

Comment choisir

1. Où cela s’exécutera-t-il ? Sous 16 Go de VRAM : utilisez une API (Gemma 4 12B tient en local, mais attendez-vous à une vraie baisse de qualité). 24 Go : Qwen3.6-27B. Un H100 : Gemma 4 31B. API : DeepSeek V4 Flash jusqu’à ce qu’il s’avère insuffisant. 2. Quel type de travail ? Les modifications rapides favorisent les modèles concis : Kimi K2.7 Code ou DeepSeek. Les problèmes difficiles et les longues exécutions d’agent favorisent GLM-5.2 (ou MiniMax M3 à moindre coût), avec de généreux budgets de jetons. 3. Contraintes de licence ? MIT (GLM, DeepSeek) et Apache 2.0 (Qwen, Gemma) n’imposent aucune restriction. Le MIT modifié de Kimi ajoute une règle d’attribution qui ne s’applique qu’à très grande échelle commerciale.

FAQ

Quel est le meilleur LLM open source pour le codage en 2026 ?

GLM-5.2 a le plafond le plus élevé — une qualité de sortie proche du niveau de Claude Sonnet sur les problèmes difficiles, au prix de la vitesse. Kimi K2.7 Code l’emporte en efficacité de tokens pour les agents API, Qwen3.6-27B pour le matériel local, DeepSeek V4 Flash sur le coût.

Puis-je exécuter ces modèles localement gratuitement ?

Les poids sont libres ; le matériel ne l'est pas. Un modèle 27B nécessite un GPU de 24 Go, Gemma 4 31B demande 80 Go, et les modèles phares à un trillion de paramètres sont réservés à l'API ou au cluster.

Quelle est la différence entre open source et open weight ?

Open-weight signifie des poids libres mais des données d'entraînement et du code privés, ce qui décrit presque tous les modèles ici. Les modèles entièrement open source (OpenCoder, StarCoder2, IBM Granite Code) publient tout mais restent en retrait en termes de capacités.

Existe-t-il un LLM open source aussi bon que Claude pour le codage ?

Sur les benchmarks algorithmiques, oui : le score de 93,5 % de DeepSeek V4 Pro sur LiveCodeBench dépasse les scores publiés des modèles fermés. Pour les correctifs au niveau du dépôt, Claude reste en tête (95,5 % contre ~80 % sur SWE-Bench Verified). Dans notre test, les modèles ouverts ont égalé Claude en termes de justesse, mais ont utilisé 4 à 13 fois plus de tokens.

Quel LLM open source est le meilleur pour C++ ou les langages de niche ?

La série K2 de Kimi a la meilleure réputation dans les langages de niche (Moonshot cite explicitement Zig). Pour C++, le consensus de la communauté pointe vers DeepSeek V4 Pro et Qwen3 Coder Next. Quel que soit votre choix, testez-le sur votre propre base de code ; la qualité pour les langages de niche varie bien davantage que ne le suggèrent les benchmarks Python.