Choisir le bon modèle local pour coder avec Ollama

Le même agent Cline donnera des résultats médiocres ou excellents selon le modèle qui l’alimente. Choisir le bon modèle local pour coder n’est pas un détail : c’est le facteur qui décide si l’expérience est frustrante ou réellement productive. Le bon choix dépend de trois variables — votre matériel, la difficulté de vos tâches, et votre tolérance à la lenteur. Ce tutoriel vous donne une méthode pour trancher, plutôt qu’une liste qui sera périmée demain.

📍 Guide principal de la série : Coder avec une IA en local : Cline, Ollama et les assistants souverains.

Ce que vous allez apprendre

• Faire correspondre la taille d’un modèle à votre mémoire disponible ;
• Distinguer modèles spécialisés code et modèles de raisonnement ;
• Lire les indicateurs utiles (paramètres, quantization, contexte, vitesse) ;
• Comparer deux modèles objectivement sur votre propre machine ;
• Constituer une petite panoplie adaptée à vos usages.

Ce que vous allez construire

Une décision éclairée : à la fin, vous aurez choisi un (ou deux) modèles adaptés à votre machine et à votre travail, testés sur une tâche réelle du projet « carnet », plutôt que d’avoir téléchargé au hasard le modèle le plus à la mode.

Prérequis

• Ollama installé (voir Installer Ollama et un modèle de code en local) ;
• Connaître la quantité de RAM et, si vous en avez, de VRAM de votre machine ;
• Niveau : intermédiaire débutant.

⏱️ Temps estimé : environ 30 minutes (téléchargements compris).

Étape 1 — Partir de votre mémoire, pas de la hype

La première question n’est pas « quel est le meilleur modèle ? » mais « que peut faire tourner ma machine confortablement ? ». Un modèle qui déborde de la mémoire fonctionne au ralenti et gâche l’expérience. Raisonnez en paliers, pour un modèle de code en quantization Q4.

• 8 Go de RAM/VRAM : visez un modèle 7B. C’est la base utile pour la complétion, le refactoring et l’explication ;
• 16 Go : 7B très à l’aise, 14B accessible pour plus de finesse ;
• 24 Go de VRAM (RTX 3090/4090 ou équivalent) : un 32B devient jouable et se rapproche nettement des modèles cloud sur le code courant.

Sans GPU dédié, tout passe par le processeur et la RAM : c’est plus lent, mais un 7B reste exploitable. L’objectif réaliste du local n’est pas de battre les plus gros modèles distants sur les problèmes les plus durs, mais de couvrir l’essentiel du travail quotidien gratuitement et en privé — ce qu’un 7B bien choisi fait déjà très bien.

✅ Point d’étape — Vous avez identifié le palier de taille adapté à votre machine. Dans le doute, commencez petit (7B) : un modèle réactif vaut mieux qu’un gros modèle qui rame.

Étape 2 — Spécialisé code ou modèle de raisonnement ?

Tous les modèles ne jouent pas le même rôle. Deux grandes familles sont utiles en programmation, et les confondre mène à de mauvais choix.

Les modèles spécialisés code, comme la famille Qwen2.5-Coder, sont entraînés spécifiquement sur du code. Ils excellent pour écrire des fonctions, compléter, refactorer, documenter — le pain quotidien d’un agent comme Cline. C’est votre cheval de bataille par défaut.

Les modèles de raisonnement, comme la famille DeepSeek-R1, « réfléchissent » à voix haute avant de répondre. Ils brillent sur les problèmes logiques retors, le débogage difficile, l’algorithmique. En contrepartie, ils sont plus lents (ils génèrent une longue réflexion) et parfois excessifs pour une tâche simple. Gardez-en un sous la main pour les passages où vous êtes vraiment coincé.

Étape 3 — Lire les bons indicateurs

Face à un modèle, quatre chiffres comptent vraiment, bien plus que les classements changeants. Le nombre de paramètres (7B, 14B, 32B) : plus il est élevé, meilleure est la qualité, mais plus la mémoire requise grimpe. La quantization (Q4, Q5, Q8) : plus elle est agressive, moins le modèle pèse, au prix d’un peu de précision ; Q4 est un excellent compromis par défaut.

La fenêtre de contexte : combien de code le modèle peut considérer d’un coup. Les modèles locaux ont un contexte plus court que les modèles cloud, d’où l’importance de cibler les fichiers avec Cline. La vitesse, enfin, se mesure en jetons par seconde : en dessous d’un certain seuil, l’attente devient pénible. Ces quatre repères suffisent à comparer deux modèles sans se perdre dans les benchmarks marketing.

Étape 4 — Comparer deux modèles sur votre machine

Le seul juge fiable, c’est votre propre matériel sur vos propres tâches. Plutôt que de croire un classement, testez. Téléchargez deux candidats — par exemple un spécialisé code de taille moyenne et un plus petit :

ollama pull qwen2.5-coder:7b
ollama pull qwen2.5-coder:14b

Donnez-leur, tour à tour, une vraie tâche de « carnet » dans Cline — par exemple « ajoute une commande d’export des notes en CSV ». Observez trois choses : la qualité du code (fait-il ce qu’il faut du premier coup ?), la vitesse (l’attente est-elle supportable ?), et la fiabilité (se trompe-t-il souvent ?). Le meilleur modèle pour vous est celui qui offre le bon équilibre, pas celui qui domine un tableau abstrait.

✅ Point d’étape — Vous avez comparé deux modèles sur une tâche réelle et choisi celui qui équilibre qualité et vitesse sur votre machine. Supprimez l’autre avec ollama rm si vous manquez d’espace.

Étape 5 — Se constituer une petite panoplie

Plutôt qu’un modèle unique, beaucoup de développeurs gardent deux ou trois modèles complémentaires et basculent selon la tâche. Un schéma efficace : un petit modèle rapide (3B ou 7B) pour les retouches et la complétion, un spécialisé code de taille moyenne (14B si la mémoire le permet) pour le gros du travail, et éventuellement un modèle de raisonnement pour les bugs coriaces.

Changer de modèle dans Cline prend deux secondes via le menu déroulant, sans perdre la tâche. Cette souplesse vous évite le compromis impossible du modèle « bon en tout » : vous prenez le bon outil pour chaque moment. Sur une machine modeste, contentez-vous d’un 7B polyvalent ; sur une machine costaude, la panoplie complète déploie tout son intérêt.

Gagner en vitesse sans changer de machine

Avant de conclure qu’un modèle est trop lent, quelques réglages peuvent transformer l’expérience sur le même matériel. Le premier levier est la taille du contexte : un modèle configuré pour considérer beaucoup de texte consomme plus de mémoire et répond plus lentement. En gardant des tâches ciblées et des fichiers précis (via les mentions dans Cline), vous réduisez la charge sans rien perdre d’utile.

Le deuxième levier est le maintien en mémoire. Par défaut, Ollama décharge un modèle après un moment d’inactivité, ce qui rend la requête suivante plus lente le temps du rechargement. Si vous enchaînez les tâches, laisser le modèle chargé évite ces temps morts ; ollama ps vous montre ce qui est actuellement en mémoire. Enfin, sur une machine avec carte graphique, vérifiez qu’Ollama exploite bien le GPU : l’écart de vitesse entre CPU et GPU est considérable, souvent d’un ordre de grandeur. Ces ajustements simples suffisent souvent à rendre confortable un modèle qu’on croyait trop lourd.

Quand le local atteint ses limites

Soyons honnêtes : le local n’est pas magique, et connaître ses limites évite la déception. Sur les tâches les plus difficiles — architecture complexe d’un gros projet, bugs subtils enfouis dans des milliers de lignes, raisonnement très poussé — les meilleurs modèles cloud gardent une avance réelle. Un modèle 7B local n’égalera pas un modèle frontière distant sur ces cas extrêmes.

Mais c’est une frontière, pas un mur. Les classements et les retours de terrain convergent : les modèles locaux couvrent aujourd’hui la grande majorité du travail courant — complétion, refactoring, documentation, écriture de tests, débogage ordinaire — gratuitement et en toute confidentialité. La stratégie gagnante est hybride : faire l’essentiel en local, et ne basculer ponctuellement vers un modèle cloud, dans le même Cline, que pour les rares problèmes qui le justifient vraiment. Vous économisez l’écrasante majorité des coûts et protégez votre code, tout en gardant une porte de secours pour les cas durs. C’est ainsi qu’on tire le meilleur des deux mondes sans renoncer à la souveraineté.

Pièges fréquents

Réalités du terrain

L’écosystème des modèles évolue très vite : de nouveaux venus prétendent régulièrement au titre de « meilleur modèle de code local », et les noms d’aujourd’hui auront peut-être changé dans six mois. C’est précisément pourquoi ce tutoriel insiste sur une méthode plutôt que sur un palmarès. Les principes, eux, restent stables : adaptez la taille à votre mémoire, préférez un spécialisé code pour le quotidien, gardez un modèle de raisonnement pour les cas durs, et tranchez par un test réel. Avec une connexion limitée, téléchargez vos candidats quand le débit est bon, puis comparez tranquillement hors-ligne. Et rappelez-vous : un 7B gratuit qui couvre 80 % de vos besoins vaut bien mieux qu’un modèle de rêve que votre machine ne peut pas faire tourner.

Gérer l’espace disque de votre panoplie

Multiplier les modèles a un coût : l’espace disque. Chaque modèle pèse de un à plusieurs dizaines de gigaoctets, et il est facile de se retrouver avec un disque saturé sans s’en rendre compte. Prenez l’habitude de faire le point régulièrement avec ollama list, qui affiche chaque modèle et sa taille, puis de supprimer sans hésiter ceux que vous n’utilisez plus avec ollama rm.

Une règle de discipline simple maintient une panoplie saine : pour chaque nouveau modèle que vous adoptez après l’avoir testé, demandez-vous lequel des anciens il rend inutile, et retirez-le. Vous évitez ainsi l’accumulation de variantes à peine différentes — trois tailles du même modèle « au cas où » — qui grignotent votre disque sans vous servir. Un atelier local efficace, c’est deux ou trois modèles choisis et bien connus, pas une collection.

Récapitulatif

Vous savez maintenant choisir un modèle en partant de votre mémoire, distinguer spécialisés code et modèles de raisonnement, lire les quatre indicateurs qui comptent, comparer objectivement deux candidats sur votre machine, et composer une petite panoplie. Ce discernement vous rend indépendant des modes : quel que soit le modèle vedette du moment, vous saurez décider. Reste à démultiplier les pouvoirs de l’agent en lui branchant des outils — direction les serveurs MCP.

Aide-mémoire

À vous de jouer

Défi : téléchargez un modèle de raisonnement (par exemple ollama pull deepseek-r1:7b) et un spécialisé code, puis donnez-leur le même bug à corriger dans « carnet ». Lequel trouve la cause le plus efficacement ?

Tutoriels associés

• Installer Ollama et un modèle de code en local — pour télécharger et gérer les modèles.
• Étendre Cline avec des serveurs MCP — la suite.

Pour aller plus loin

• 🔝 Revenir au guide principal : Coder avec une IA en local : Cline, Ollama et les assistants souverains.
• Documentation officielle : la bibliothèque de modèles ollama.com/library.

FAQ

Quel est le meilleur modèle de code local ?
Il n’y a pas de réponse universelle : cela dépend de votre matériel et de vos tâches. Une famille spécialisée code de taille adaptée à votre mémoire, testée sur vos propres cas, est le bon point de départ.

Un modèle de raisonnement est-il meilleur ?
Pas en général : il est plus lent et parfois excessif. Il excelle sur les bugs et la logique difficile, mais un spécialisé code reste préférable pour le travail courant.

Faut-il toujours prendre le plus gros modèle possible ?
Non. Un modèle qui déborde de la mémoire devient inutilisable. Mieux vaut un modèle un peu plus petit, rapide et fiable.

Les classements de modèles sont-ils fiables ?
Ils donnent une tendance, mais évoluent vite et ne reflètent pas votre matériel. Le test sur votre machine reste le juge final.