Sommaire

Faire écrire du code par un modèle qui tourne sur votre propre PC. En soi, c'était déjà possible il y a quelques années, mais cela se limitait à la complétion : terminer la ligne en cours d'écriture. L'usage agentique, celui où l'on « lit le dépôt, corrige plusieurs fichiers et lance les tests », restait bien trop lourd pour une machine locale.

C'est là que les choses ont bougé, entre la fin 2025 et 2026. Cet article fait le point sur ce qui est réellement faisable aujourd'hui et sur ce qui coince, uniquement à partir de sources primaires. La conclusion d'abord : ça fonctionne. Mais il y a un passage obligé — si vous ne changez pas un réglage, tout casse en silence.

📌 À propos des chiffres de cet article : les benchmarks et les spécifications des modèles proviennent tous des annonces des éditeurs (site officiel de Mistral AI, fiches de modèle officielles de Qwen, documentation officielle d'Ollama, documentation officielle de Cline, publications officielles d'Anthropic). Aucune reprise de seconde main depuis des articles de synthèse : en menant l'enquête, je suis tombé à plusieurs reprises sur des synthèses qui attribuaient à un modèle le score d'un modèle d'une autre taille.

1. Ce qui a changé — les modèles ouverts ont atteint l'agentique

Le signe le plus net de ce basculement, c'est que les éditeurs de modèles eux-mêmes se sont mis à vendre leurs produits sur le « codage agentique ».

La fiche de modèle officielle de Qwen indique que le modèle prend en charge la plupart des plateformes comme Qwen Code ou CLINE, avec un format d'appel de fonction conçu spécialement pour cela : le nom d'une extension d'éditeur y est cité explicitement (Qwen3-Coder-30B-A3B-Instruct model card). Autrement dit, le modèle est conçu en visant un agent de codage précis.

Mistral AI va dans la même direction. Devstral 2, annoncé le 9 décembre 2025, est un modèle dédié qui revendique explicitement le « codage agentique », et la plus petite variante, Devstral Small 2 (24B), a été publiée sous licence Apache 2.0 (Introducing: Devstral 2 and Mistral Vibe CLI).

À l'époque de la simple complétion

Terminer la ligne en cours d'écriture. Un petit modèle suffit et le contexte peut rester court. Cela tournait sans effort en local

Ce que l'agentique exige

Il faut émettre des appels d'outils exacts et tenir un contexte long. Des modèles ouverts atteignent désormais ce niveau

2. Il existe deux familles d'outils — Continue et Cline n'ont rien à voir

Commencer en confondant les deux, c'est se préparer un décalage entre l'attente et le résultat. Ce sont deux extensions VS Code, toutes deux se branchent sur Ollama, mais leur philosophie de conception est radicalement différente.

　 Continue Cline
Nature Un assortiment complétion, chat et édition Un agent de codage autonome
Répartition des rôles Un modèle différent par rôle — chat / edit / apply / rerank / autocomplete Un seul modèle, de la planification à l'exécution
Configuration requise Basse. Quelques Go suffisent pour la complétion Élevée. Il faut un contexte long et des appels d'outils exacts
Usage adapté Aller plus vite pendant qu'on écrit Déléguer une tâche entière

La conception « un modèle par rôle » de Continue s'accorde bien avec le local. On peut en effet réserver un modèle petit et rapide à la complétion, et un modèle plus gros au chat. Le guide Ollama officiel cite d'ailleurs nommément des modèles légers pour la complétion, comme qwen2.5-coder:1.5b ou starcoder2:3b (Continue — Ollama guide).

⚠️ Attention toutefois : les modèles recommandés par la documentation officielle sont parfois datés. Le guide ci-dessus propose pour le chat llama3.1:8b ou deepseek-r1:32b, soit plusieurs générations avant ce qui est disponible aujourd'hui. La procédure reste valable, mais mieux vaut ne pas reprendre les noms de modèles tels quels et refaire son choix avec la section « 4. Choisir un modèle » ci-dessous.

3. Le premier piège — la longueur de contexte dépend de la VRAM

C'est le chapitre le plus important de cet article. Sans cela, on se retrouve dans la situation où « l'installation a réussi, mais l'agent se met à faire n'importe quoi en cours de route ». Et, pire encore, aucune erreur ne s'affiche.

La cause tient à la longueur de contexte par défaut d'Ollama. Ce n'est pas une valeur fixe : elle est déterminée automatiquement selon la quantité de VRAM (Ollama — Context length).

VRAM Longueur de contexte par défaut
Moins de 24 GiB 4k
24 à 48 GiB 32k
48 GiB et plus 256k

Un PC de jeu classique (8 à 16 Go de VRAM) tombe dans la première ligne. Autrement dit, 4k. Entre le prompt système, le contenu des fichiers et les allers-retours d'appels d'outils, un agent franchit cette limite sans le moindre effort, et le début de la conversation est alors tronqué en silence. Il oublie les consignes, répète la même opération, perd son objectif en chemin — la cause n'est pas la bêtise du modèle, c'est que le contexte est jeté dès l'entrée.

Pour ce type d'usage, la documentation officielle d'Ollama est explicite : il faut régler le contexte sur au moins 64000 jetons pour les travaux exigeants comme la recherche web ou les outils de codage. Le réglage se fait par une variable d'environnement au démarrage du serveur.

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Si vous utilisez la version application, le curseur des réglages permet de changer la même valeur.

⚠️ Mais il ne suffit pas d'augmenter la valeur. La documentation officielle prévient elle-même qu'augmenter la longueur de contexte augmente la quantité de mémoire nécessaire à l'exécution du modèle.

Dès que cela ne tient plus dans la VRAM, une partie du modèle est repoussée du côté du CPU et tout devient dramatiquement lent. Pour vérifier que le réglage est réellement effectif, utilisez ollama ps — c'est ce que recommande la documentation officielle. Vous y verrez si l'ensemble tient bien sur le GPU.

Cline propose de son côté des parades au même problème. Sa documentation officielle recommande d'activer Use Compact Prompt et de restreindre la tâche (plus le contexte est petit, plus la réponse est rapide) (Cline — Running models locally). Le prompt système de l'agent étant lui-même long, un réglage est prévu pour le raccourcir.

4. Choisir un modèle — les options réalistes selon la VRAM

Mieux vaut se méfier des recommandations que l'on trouve dans les articles de synthèse. Dans ce que j'ai pu consulter, certains citaient des modèles du milieu de 2025 comme « recommandations 2026 », d'autres plaçaient le score d'un modèle 480B dans la colonne d'un modèle 30B. Ici, on s'en tient aux annonces des éditeurs.

Modèle Taille Contexte Licence SWE-bench Verified
Qwen3.6-35B-A3B 35B (3B actifs) 262,144 (max. 1,010,000) Apache 2.0 73.4
Devstral Small 2 24B 256K Apache 2.0 68.0%
Devstral 2 (pour référence, trop gros) 123B 256K Modified MIT 72.2%

Sources : fiche de modèle Qwen3.6-35B-A3B (Terminal-Bench 2.0 : 51.5, QwenClawBench : 52.6) / annonce officielle de Mistral AI (9 décembre 2025). Les scores ont été mesurés par chaque éditeur lui-même et ne proviennent pas d'une évaluation comparative menée par un tiers.

Le point remarquable, c'est le « 3B actifs » de Qwen3.6-35B-A3B. Sur les 35B, seuls 3B travaillent réellement à chaque passe, et c'est là que joue le MoE (Mixture of Experts). Une structure qui vise à la fois l'intelligence d'un gros modèle et la vitesse d'un petit, donc une conception taillée pour le local.

Taille de téléchargement et configuration nécessaire

Dans la bibliothèque Ollama, qwen3.6 propose côte à côte les tailles 27b (18 Go) et 35b (23 Go). Il existe aussi des étiquettes en -mlx pour Mac.

Voici les repères mémoire donnés par la documentation officielle de Cline : 16 à 32 Go pour un petit modèle, 32 à 64 Go pour un modèle de codage de taille moyenne, 64 Go ou plus pour un gros modèle assorti d'un contexte étendu.

VRAM de 8 à 12 Go

S'en tenir à la complétion avec Continue. Renoncer à l'agentique, ou la combiner avec le cloud

VRAM de 16 à 24 Go

Devstral Small 2 (24B) est à portée. Il faut de la marge pour allonger le contexte, donc la quantification est indispensable

VRAM de 24 Go et plus / mémoire unifiée de 32 Go et plus

Qwen3.6 en 27b/35b devient réaliste. Le contexte par défaut monte aussi à 32k

Mistral écrit à propos de Devstral Small 2 qu'il fonctionne sur des GPU grand public, et même sur des configurations uniquement CPU. Mais il vaut mieux garder en tête que « fonctionner » et « fonctionner assez vite pour servir d'agent » sont deux choses différentes.

5. Installation — la marche à suivre la plus courte

① Installer Ollama et régler le contexte

L'ordre compte. Fixez la longueur de contexte avant d'installer le modèle.

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

La procédure d'installation proprement dite est traitée dans le guide complet d'Ollama ; reportez-vous-y.

② Récupérer le modèle

ollama pull qwen3.6:27b

Si votre VRAM est juste, choisissez plutôt Devstral Small 2. Ce sont dans les deux cas des modèles conçus pour l'agentique, et c'est là leur différence avec un modèle de chat généraliste.

③ Vérifier que tout est chargé sur le GPU

ollama ps

Ne sautez pas cette vérification. Si une partie a été repoussée vers le CPU, le ressenti n'a plus rien à voir. Beaucoup d'avis du type « les LLM en local sont trop lents pour être utiles » viennent en réalité de là.

④ Brancher l'extension

Pour Cline comme pour Continue, choisissez Ollama comme fournisseur et indiquez http://localhost:11434. L'avertissement de la documentation officielle de Cline est d'une simplicité désarmante — vérifiez qu'Ollama est bien lancé avant d'envoyer un prompt — et aucun réglage particulier n'est nécessaire.

Si vous utilisez Cline, activez également Use Compact Prompt.

6. L'écart avec le cloud est devenu difficile à mesurer

Autant l'écrire honnêtement. Une comparaison du type « les modèles locaux sont arrivés à tel pourcentage du cloud », on ne peut plus la produire proprement aujourd'hui. La raison : les benchmarks ne coïncident plus.

Du côté des modèles ouverts, on publie SWE-bench Verified. Qwen3.6-35B-A3B à 73.4, Devstral Small 2 à 68.0%. Du côté des modèles de frontière, en revanche, on s'éloigne de cet indicateur.

De fait, l'annonce de Claude Opus 5 par Anthropic ne comporte aucun chiffre SWE-bench Verified. Ce qui y figure, ce sont Frontier-Bench v0.1, CursorBench 3.2, AA Coding Agent Index et FrontierCode 1.1, et le plus souvent sous une forme relative plutôt qu'en valeur absolue (« plus du double des performances d'Opus 4.8 », « à moins de 0.5 % du score de pointe de Fable 5 », etc.).

⚠️ Donc, méfiez-vous dès que vous voyez un chiffre du type « le local atteint tel pourcentage de Claude ». Il y a de fortes chances que la référence et la cible n'aient pas été mesurées avec le même indicateur, ou que la comparaison porte sur un Claude vieux de plusieurs générations. Aujourd'hui, SWE-bench Verified ne permet plus guère d'aligner que des modèles ouverts entre eux.

Les écarts que l'on peut malgré tout affirmer

Même sans chiffres comparables, les endroits où l'écart se creuse structurellement sont parfaitement identifiables.

Là où le local a l'avantage

Le code ne sort pas de la machine / pas de facturation à l'usage (on relance sans compter) / fonctionne hors ligne / aucune limite de débit

Là où le cloud a l'avantage

Le raisonnement qui traverse plusieurs fichiers / la stabilité sur de longues exécutions autonomes / aucun investissement initial / le modèle se renouvelle tout seul

Si l'écart se creuse justement sur « le raisonnement qui traverse plusieurs fichiers », c'est pour une raison précise. C'est l'étape qui consomme énormément de contexte et empile des dizaines de décisions successives. Un écart de précision sur une seule décision se multiplie à chaque aller-retour. Une différence imperceptible sur la retouche d'un fichier unique devient tangible à l'échelle d'un dépôt.

7. « Le local est gratuit » : est-ce bien vrai ?

Aucune facture d'API n'arrive, c'est un fait, mais ce n'est pas gratuit pour autant. C'est seulement la forme du coût qui change.

Poste En local Dans le cloud
Coût initial Un GPU doté de beaucoup de VRAM ou une grande mémoire unifiée Aucun
Coût qui croît avec l'usage L'électricité seulement Facturation aux jetons ou forfait
Coût peu visible Le temps de configuration et de maintenance, le suivi des mises à jour de modèles Aucun (assumé par le fournisseur)

La réponse à « lequel revient le moins cher » s'inverse donc selon les conditions de comparaison. Si vous possédez déjà un GPU de la classe 24 Go, le local tourne pour un surcoût quasi nul. Dans le cas contraire, le prix de ce GPU paie plusieurs années d'abonnement. Il est plus juste de considérer que la réponse dépend de deux points : « en lancez-vous beaucoup chaque jour ? » et « avez-vous déjà le matériel ? ».

8. Le verdict : quand choisir quoi

Ce qui justifie de choisir le local

Le code ne peut pas sortir (contrat, règlement interne) / le matériel est déjà là / vouloir tâtonner sans compter les essais / travailler hors ligne

Ce qui ne le justifie pas

« Parce que c'est gratuit » (le matériel n'est pas compté) / « parce que ça a l'air rapide » (le cloud est souvent plus rapide)

Le plus réaliste, c'est de combiner les deux. Confiez la complétion de Continue à un petit modèle local et laissez-la tourner en permanence, puis passez les travaux d'ampleur à un agent dans le cloud. La complétion est fréquente et légère à chaque appel, donc adaptée au local ; l'agent est rare et lourd à chaque appel, donc adapté au cloud — les profils de charge sont exactement inverses.

Récapitulatif

  • Les modèles ouverts ont atteint le codage agentique. Qwen comme Mistral publient des modèles dédiés qui citent nommément les extensions d'éditeur
  • Le principal obstacle est la longueur de contexte par défaut d'Ollama. Sous 24 GiB de VRAM, c'est 4k, et l'agent casse en silence. La recommandation officielle est d'au moins 64000 pour un usage de codage
  • Une fois la valeur augmentée, vérifiez avec ollama ps que tout tient sur le GPU. Repoussé vers le CPU, c'est une tout autre lenteur
  • Continue et Cline n'ont rien à voir. Le premier assigne un modèle par rôle pour la complétion, le second est un agent autonome. Leurs exigences matérielles diffèrent
  • La comparaison « tel pourcentage du cloud » tient de moins en moins. Les modèles de frontière publient de moins en moins SWE-bench Verified
  • Ce n'est pas « gratuit », c'est « une autre forme de coût ». La réponse s'inverse selon que le matériel est déjà là ou non

FAQ

Q1. Peut-on faire de l'agentique avec un GPU de 8 Go de VRAM ?

C'est difficile. Même si le modèle lui-même tient, il ne reste plus de marge pour allonger le contexte. Le défaut d'Ollama tombe à 4k sous 24 GiB de VRAM, et le pousser à 64000 augmente la mémoire nécessaire — concilier les deux avec 8 Go est ardu. Le plus réaliste est de s'en tenir à la complétion avec Continue, ou de garder la complétion en local et l'agent dans le cloud.

Q2. Par lequel commencer, Cline ou Continue ?

Si c'est votre premier LLM en local, Continue. Ses exigences matérielles sont plus basses et il est plus facile d'isoler la cause quand rien ne fonctionne. En vérifiant d'abord que la complétion tourne confortablement avant de passer à l'agentique, vous saurez distinguer ce qui relève du modèle de ce qui relève du réglage.

Q3. Est-ce que cela fonctionne aussi sur Mac ?

Oui. La mémoire unifiée sert directement d'équivalent à la VRAM, donc il est même plus facile d'y charger de gros modèles. La bibliothèque Ollama propose d'ailleurs des étiquettes en -mlx (pour Apple Silicon) sur qwen3.6. Mais la règle qui fait dépendre la longueur de contexte par défaut de la quantité de mémoire s'applique exactement de la même façon, donc la vérification reste nécessaire.

Q4. Quel modèle est « le plus intelligent » ?

Si l'on s'en tient aux scores publiés, parmi ceux cités dans cet article, les 73.4 de Qwen3.6-35B-A3B sur SWE-bench Verified sont le meilleur résultat. Mais il s'agit de mesures faites par chaque éditeur lui-même, et non d'une comparaison alignée par un tiers. Dans la pratique, la licence (Devstral Small 2 et Qwen3.6 sont tous deux en Apache 2.0) et le fait que le modèle tienne dans votre VRAM pèsent bien davantage.

Q5. Pourquoi « ça casse sans afficher d'erreur » ?

Parce que ce qui dépasse la longueur de contexte est traité comme une troncature et non comme une erreur. Le modèle répond normalement, dans les limites de ce qu'on lui a transmis. Cela se manifeste par l'oubli des consignes, la répétition de la même opération, la perte de l'objectif, et l'on croit alors à un manque de capacité du modèle. Savoir que ce symptôme doit faire suspecter le réglage change complètement la vitesse du diagnostic.

Q6. Quelle quantification faut-il choisir ?

En cas de doute, partir de l'équivalent Q4_K_M est un choix sûr. Les différences entre formats (GGUF / GPTQ / AWQ) et la façon de choisir sont réunies dans le guide complet des formats de quantification. Pour le codage, « un modèle un peu plus petit avec une quantification plus douce » est en général plus stable qu'« un gros modèle fortement quantifié » — parce qu'il faut respecter à la lettre le format des appels d'outils.

Q7. Puis-je l'utiliser sur le code de mon entreprise ?

Tant que tout reste local, le code ne sort pas — c'est le plus grand avantage du LLM en local. Vérifiez toutefois les réglages de l'extension. Même en pointant le fournisseur vers Ollama, de la télémétrie ou une autre fonction peuvent communiquer vers l'extérieur. Et « est-ce autorisé par le règlement » est une question distincte de la technique, donc commencez par consulter les règles internes de votre entreprise.

Articles connexes