Quel modèle pour coder ? Les LLM locaux pour développeurs

Un modèle local qui écrit, explique et refactore votre code — sans que rien ne quitte votre machine — est l'une des choses les plus utiles à auto-héberger. Mais « quel modèle exécuter ? » n'a pas de réponse unique : cela dépend de votre matériel et de ce que vous voulez en faire. Ce guide vous donne une méthode de choix durable, plutôt qu'un classement périmé le mois prochain.

Les quatre critères qui comptent vraiment

Ignorez le battage et jugez un modèle de code sur ces quatre axes. Ils évoluent bien plus lentement que les noms de modèles.

1. La taille par rapport à votre mémoire

C'est la contrainte dure. Un modèle doit tenir dans votre VRAM (ou votre RAM système) pour tourner à une vitesse utilisable. Un modèle de code qui déborde dans la RAM système va ramer.

À titre indicatif — la même règle que dans notre guide complet d'Ollama :

Votre mémoire	Modèle de code confortable
8 Go	un modèle 7B en q4
16 Go	un modèle 13B–14B en q4, ou 7B en q8
24 Go+	modèles 30B+, ou un modèle plus petit avec une grande fenêtre de contexte

Associez cela aux tags de quantization GGUF pour faire rentrer un modèle dans votre budget. Se tromper ici est la première raison pour laquelle les gens concluent que « les modèles locaux sont trop lents » — ils faisaient simplement tourner un modèle trop gros pour leur carte.

2. Le fill-in-the-middle (FIM)

C'est le critère que la plupart des débutants ratent, et c'est la différence entre un chatbot et un vrai assistant de code.

Les modèles de chat ordinaires ne font que continuer le texte à la fin. Les modèles fill-in-the-middle sont entraînés à insérer du code entre des lignes existantes — exactement ce dont l'autocomplétion en ligne de votre éditeur a besoin. Si vous voulez la complétion au clavier à l'intérieur d'une fonction, il vous faut un modèle compatible FIM. La plupart des modèles dédiés au code le prennent en charge ; les modèles de chat généralistes, en général non.

3. La fenêtre de contexte

Les tâches de code dévorent du contexte. Comprendre un fichier suppose de lire ses imports ; comprendre une modification suppose de lire le module alentour. Un modèle à petite fenêtre de contexte oublie le haut du fichier une fois arrivé en bas.

Pour du travail sérieux, privilégiez les modèles annonçant un grand contexte (32K tokens et plus). Rappelez-vous le compromis du guide Ollama : un num_ctx plus grand coûte de la mémoire, il y a donc une vraie tension entre les critères 1 et 3 sur une petite machine.

4. La licence

Si vous écrivez du code pour le travail, la licence du modèle compte autant que sa compétence. « Open weight » ne veut pas dire « libre d'usage commercial » — un point que nous traitons dans open-source vs open-weight. Vérifiez la licence avant de bâtir un workflow autour d'un modèle, surtout en entreprise.

Les familles à connaître

Plutôt que de courir après des numéros de version qui changent chaque mois, apprenez les familles — chacune a un caractère constant d'une version à l'autre :

• Qwen Coder — une solide famille polyvalente, déclinée dans un large éventail de tailles, il y en a donc généralement une qui tient sur votre carte. Un premier choix raisonnable.
• DeepSeek-Coder — bien considérée pour raisonner sur des problèmes plus vastes, multi-fichiers.
• Codestral (Mistral) — conçue spécifiquement pour le code avec le FIM en tête ; vérifiez ses conditions de licence pour un usage commercial.
• Code Llama — la référence plus ancienne, largement prise en charge. Pas la plus forte aujourd'hui, mais éprouvée et présente partout.

Quelle que soit la famille choisie, cherchez la variante dont la taille correspond au critère 1, et confirmez la prise en charge du FIM si vous voulez la complétion en ligne.

Le mettre au travail

Une fois votre choix fait, récupérez-le avec Ollama et pointez votre éditeur dessus. La tuyauterie — connecter un modèle local à votre IDE et lui donner accès à vos fichiers — c'est précisément à cela que servent les extensions d'éditeur et MCP.

Le gain, c'est toute la raison de passer en local : un assistant de code qui lit votre dépôt privé, tourne hors ligne dans un avion, et n'envoie jamais une ligne de code propriétaire sur le serveur de quelqu'un d'autre. C'est l'argument que nous défendons dans pourquoi nous quittons les LLM cloud — et le code est là où il paie en premier.

Pour aller plus loin

• Pas sûr qu'un modèle tienne sur votre carte ? Commencez par le tableau mémoire du guide complet d'Ollama.
• Envie de donner des outils et un accès fichiers au modèle ? Voir MCP pour l'IA locale.
• Vous travaillez en entreprise ? Lisez open-source vs open-weight avant de vous engager sur la licence d'un modèle.