J'ai testé les LLMs locaux et mon MacBook à presque pris feu.

Introduction

Je ne suis pas un grand fan des solutions d’IA mainstream. D’abord parce que je suis un hipster qui refuse de faire comme tout le monde. Mais surtout parce que ça coûte très cher.

Du coup, une bonne partie de mon temps de veille technique a dernièrement été orientée vers le test de solutions d’IA agentique alternatives, et plus particulièrement vers les solutions locales.

Des choses ont fonctionné… D’autres un peu moins.

Voici le récit de mes aventures aux cotés des LLMs locaux.

Préambule configuration

Je suis l’heureux propriétaire d’un MacBook Pro M3 Max avec 64 Go de RAM. Dans mon monde d’avant l’IA, j’avais tendance à l’exhiber fièrement, me targuant de posséder une machine d’exception. Trois ans plus tard, cette brave bête s’avère être tout juste suffisante pour faire ce que j’aimerais faire avec des LLMs en local.

Je fais tourner mes LLMs sur LM Studio et j’utilise principalement OpenCode pour la partie agentique.

Le moment de bascule

Tout a basculé avec Gemma 4. Plus précisément avec sa version 26b-4b-thinking (À vos souhaits !). Pour la première fois, j’ai entrevu la possibilité de faire du Spec Driven Development en local sur mon Mac.

Il s’agit d’un modèle de Google à 26 milliards de paramètres, de type Mixture of Experts (MoE) à 4 milliards de paramètres actifs.

Si vous vous posez la question, un modèle Mixture of Experts est un modèle de langage dont tous les paramètres ne sont pas actifs en permanence. Cela permet d’exécuter des modèles de grande taille sur des machines aux ressources limitées, sans trop sacrifier la qualité.

Pour la première fois, j’ai pu commencer à confier des tâches agentiques à un modèle local sans attendre 3 heures pour obtenir un résultat… et avec un résultat à peu près convenable.

Un peu de pratique

Par « résultat convenable », j’entends :

Comprendre un besoin localisé sur 2-3 fichiers.
Ne pas ignorer le contexte autour du prompt.
Raisonner sur la tâche.
Et surtout : produire du code qui compile.

Pour vous donner un exemple concret : sans skill particulier, Gemma 4 était en mesure de découper un gros composant Angular en plusieurs composants plus petits et modulaires, tout en conservant la logique et les dépendances correctes…

Mais…

Angular est un framework relativement complexe, qui a connu des évolutions importantes lors de ses dernières mises à jour.

Les plus flagrantes sont, évidemment, l’entrée en activité des signals entre les composants, ainsi que l’arrivée d’une nouvelle syntaxe dans les templates :

@for (block of blocks(); track block.id) {
  <mon-joli-component [input]="block"/>
}

Et c’est là que les choses se corsent un petit peu.

Le LLM avait bien réussi à produire un résultat qui passe la compilation… mais en utilisant la vieille syntaxe d’Angular (celle avec *ngFor et des observables), alors que le projet utilisait la nouvelle syntaxe @for et les signals. Un mélange disgracieux des deux époques.

Les skills à la rescousse

C’est donc à partir de ce moment que j’ai commencé à implémenter des skills particuliers (ce n’est pas totalement vrai, je les avais juste désactivées pour avoir un avis sur le modèle bare metal).

Solution : un joli fichier AGENTS.md à la racine du projet. J’y décris mes bonnes pratiques générales + des skills Angular (templates, composants, services…). (Oui, mon jeu de règles est un peu plus complexe que ça, mais passons.) Résultat : le code généré est devenu bien plus cohérent.

Petit conseil à propos de la rédaction de skills : écrivez les vôtres, surtout quand il s’agit de décrire votre manière de travailler le code. Ces skills représentent votre pâte personnelle en tant qu’ingénieur logiciel et c’est le meilleur moyen d’obtenir des résultats qui vous conviennent.

Mais… (encore)

Vous serez peut-être tenté de me dire que de splitter un gros composant en 3 ou 4 petits, si cela peut être sympa, ce n’est pas vraiment la grande promesse du grand remplacement agentique que nous vendent les pontes de l’IA… et vous avez raison.

J’ai donc tenté d’aller un peu plus loin en préparant un gros fichier de brief qui comprenait une US rédigée par mon PO suivie d’une analyse technique précise de ce que j’attendais du LLM pour la réaliser. C’est une pratique que je fais assez régulièrement quand je veux attaquer le travail d’une nouvelle US, et cela donne de très bons résultats sur des LLMs cloud plus puissants.

C’était une US modérément complexe mais qui faisait appel à l’ensemble des couches de notre app :

Appel d’une nouvelle route à exposer dans un service HTTP existant (que j’appelle un repository)
Mapping des données récupérées pour en faire un nouvel objet métier
Enrichissement d’un store global
Exploitation de ces nouvelles données dans de nouveaux composants en se connectant au store (via des signals si possible)

Aucun calcul sur les données, mais une nécessité de respecter scrupuleusement mes guidelines de développement à travers plusieurs fichiers.

Petit conseil : pour préparer au mieux mon brief, j’aime beaucoup écrire l’ensemble du brief dans un fichier .md que je range dans un dossier .scratch de mon projet. Je le donne ensuite en référence à OpenCode et je le laisse s’exécuter. Ça permet d’avoir un peu plus de contrôle sur la qualité et la cohérence des informations fournies, et c’est plus simple à rédiger que dans la fenêtre de prompt de mon agent.

Une première passe en mode plan et Gemma a été en mesure d’effectuer une analyse relativement satisfaisante de ce qu’il allait devoir implémenter. C’est lors de la partie implémentation que les choses se sont un peu corsées…

10 minutes plus tard, mes ventilateurs hurlaient à plein régime, mes GPUs flirtaient avec les 100 °C… Et, soudain, Gemma m’annonce fièrement : “J’ai fini !

Problème : Il n’a même pas tenté de compiler le code. Pourtant, mes skills décrivent noir sur blanc la procédure de validation : linter, compilation, tests unitaires…

Et à la relecture du code, j’ai rapidement remarqué des grosses lignes rouges un peu partout dans les nouveaux fichiers générés.

Dans les grandes lignes, oui, il avait compris. Dans les détails, le code était truffé d’erreurs et d’incohérences.

Bilan : Reprendre tout à la main pour faire fonctionner son code ? Non, je n’aurais pas gagné de temps.

Petite déception donc.

Ma conclusion à ce stade est que le développement agentique est encore trop complexe pour être délégué à un LLM local de 26 milliards de paramètres.

Mais ! (et oui !)

Par curiosité, j’ai jeté un œil chez les voisins. Les LLMs chinois, surtout ceux d’Alibaba, montent en puissance à vitesse grand V.

Et pour le coup, sur le segment des LLMs capables de tourner sur un ordinateur personnel (avec beaucoup de RAM et un GPU correct), les résultats sont supérieurs à ce que proposent les sociétés américaines.

Faites donc place à Qwen

Qwen est le nom des modèles de langage développés par la société chinoise Alibaba. Ils sont open source (jusqu’à leur version 3.7, il semblerait). Leurs performances sont au rendez-vous, et ce sur une large gamme de tailles : de quelques milliards à plusieurs dizaines de milliards de paramètres.

J’ai donc recommencé mes expérimentations sur leur modèle 3.6-35b-A3b, lui aussi Mixture of Experts.

Même cas de figure : US + brief technique précis, plan + exécution.

Résultats : meilleurs, mais toujours imparfaits.

J’aurais dû m’arrêter là.

J’aurais certainement dû faire ce que tout le monde fait : prendre un abonnement Claude Code à 200 $ par mois et passer le reste de mes jours à écrire en boucle Develop the feature : [10000 lignes de contexte], don't do mistakes, be awesome. Mais l’arrogant anticonformiste qui sommeillait en moi refusait de s’avouer vaincu et avait une dernière carte dans sa manche

OpenSpec mon amour

Si vous ne connaissez pas Openspec, c’est un framework à destination de votre outil agentique (Claude Code, OpenCode, Mistral Vibe…) qui permet de faire du Spec Driven Development. J’en parlerai sûrement dans un prochain article de blog, mais en gros, c’est un outil qui permet de découper votre projet (User story ou feature) en spécifications détaillées que votre agent peut suivre pour générer du code de manière plus fiable et cohérente. L’agent va passer par 3 phases :

Une phase exploratoire basée sur le brief que vous lui avez donné.
Une phase de rédaction des spécifications et des tâches à réaliser pour arriver au résultat souhaité.
Une phase de génération du code en suivant les spécifications établies.

Résultat : Moins d’hallucinations, beaucoup plus de contrôle sur la trajectoire du modèle. La phase exploratoire étant un moment crucial où vous pouvez orienter avec précision l’agent sur son travail futur.

Du coup, un nouveau test avec Gemma + OpenSpec et là !

Des specs assez détaillées, un planning précis et une exécution beaucoup plus fiable !

C’est donc avec joie que je peux vous annoncer que oui, il est possible de faire du développement agentique de manière assez fiable, en local, avec les bons outils et méthodologies.

Mais il reste encore du chemin

Réussir une US simple en quasi one-shot avec un LLM local, c’est possible. En revanche, ça ne signifie pas que vous pouvez résilier Copilot ou Claude.

Le temps de calcul

Le temps de calcul pour mon US moyennement complexe a été long. Exploration, rédaction, génération… Le compteur a tourné. Et pour être franc, en me concentrant un peu, je pense que j’aurais été un peu plus rapide à tout taper à la main ou en utilisant les modules d’autocomplétion assistés par IA dans mon IDE.

La chauffe

Mon MacBook a littéralement brûlé.

Plusieurs fois, j’ai vu des pics à 100°C pendant de courtes périodes sur mon GPU et, en moyenne, comptez 85 / 90° tout au long d’une session agentique. Franchement, c’est assez angoissant d’entendre les ventilateurs internes hurler de douleur pendant que qu’OpenCode crame des tokens, même si il semblerait que les processeurs M1+ d’Apple peuvent encaisser jusqu’à 105°C sans danger et qu’une température de 85° à 90° soit considérée comme “ok” si on lui laisse un peu de temps pour redescendre entre les sessions.

Je pense quand même que faire tourner mon MacBook au max de ses capacités pendant plusieurs heures tous les jours est risqué pour sa longévité. J’ai acheté un socle de refroidissement pour essayer de limiter, un peu, les dégâts (j’avais aussi vu celui-ci, mais je me suis dit qu’il ne fallait pas déconner non plus). Ça mitige effectivement bien la température, mais pas au point d’enchaîner des dizaines de sessions de LLM local pour autant. On peut imaginer que sur un gros PC fixe sous water cooling, ce problème serait beaucoup moins prononcé.

La qualité globale

Même si les résultats sont plus qu’encourageants, il est évident que vous n’allez pas pouvoir demander d’énormes tâches ultra-complexes à votre LLM comme vous pourriez le faire avec Claude ou GLM 5.

Le prix

Alors oui, c’est gratuit et illimité, mais le prix d’entrée pour pouvoir espérer avoir des résultats corrects est quand même bien salé ! Pour rappel, je tourne sur un MacBook M3 MAX avec 64 Go de RAM qui m’avait coûté autour des 5 000 euros à l’époque. C’est cher, et vu les prix délirants de la RAM depuis quelques mois, n’espérez pas pouvoir trouver une machine assez puissante pour faire tourner de bons modèles en dessous de ce prix.

Conclusion

Verdict, je suis quand même assez impressionné par l’outil.

Les LLMs locaux gèrent du simple au pas-trop-complexe sans sourciller.

Et le gros plus pour certains, pouvoir bosser dans l’avion… ce que je dois faire une fois par an donc pas vraiment d’intérêt de mon côté…

Mais attention, tout déléguer à sa machine locale, cela me semble encore prématuré.

La chauffe me donne des angoisses. La batterie fond comme neige au soleil (45 minutes max à pleine puissance).

In fine, je pense que je vais conserver mon setup LM Studio + Qwen 3.6 pour des cas précis de refactoring ou de tâches simples, car tous les cas de développement ne nécessitent pas un déluge de puissance. Les résultats sont satisfaisants dans de nombreux cas de figure et ça permet quand même d’économiser pas mal de tokens.

Modèles bonus

Ornith
- Nouvelle gamme de modèles basés sur un post-training de Gamma et de Qwen 3.5, ils semblent avoir de meilleures performances. Je teste un peu à l’heure où j’écris ces lignes, et les résultats sont bons, sans que je puisse vraiment dire si les résultats transcendent ce que fait Qwen 3.6.
GPT-OSS
- Testé sommairement, mais largement inférieur à tout ce qui est discuté ici.
Qwen 3.6-27b
- C’est une version dense du modèle 35b-A3b mentionné ici. Il donne de meilleurs résultats, mais est plus gourmand et donc plus lent… un peu trop pour mon usage. Si j’avais une meilleure machine avec 128 Go de RAM, j’utiliserais certainement celui-ci.