Développer avec un LLM local : Claude Code en senior, mon Mac en apprenti

Développer avec un LLM local est aujourd’hui réaliste sur un Mac récent : mon MacBook Pro M4 avec 48 Go de RAM fait tourner des modèles de 35 milliards de paramètres quantisés en 6 bits, assez vite pour générer un jeu fonctionnel en 24 secondes. À une condition : ne pas tout demander au modèle local.

La méthode qui fonctionne chez moi tient en une image : un binôme apprenti / développeur senior. Le senior, c’est Claude Code : il conçoit l’architecture et les tests unitaires. L’apprenti, c’est le modèle local (Qwen, Ornith) : il implémente, fonctionnalité par fonctionnalité, et itère jusqu’à ce que tous les tests passent.

Sur le papier, l’idée de cet article est simple : tester pour de vrai la délégation de tâches de développement à un modèle local. On est d’accord, Claude Code est une référence pour développer, en tout cas aujourd’hui. Il existe des équivalents, parfois moins bons, parfois un peu meilleurs, mais dans l’ensemble, le code produit est fonctionnel et marche plutôt bien. Mon vrai point de départ, c’est une question de budget (oui oui, encore une autre façon d’optimiser mes c’est le nerf de la guerre) : comment ne pas rester bloqué avec l’abonnement Claude Pro à environ 20 € par mois, quand la marche d’après est brutale – l’offre Max démarre autour de 100 € par mois (grille tarifaire Anthropic, 2026) ? Pas le même budget, pas le même coût d’investissement.

Du coup, je me suis posé la question : avec ma machine, un MacBook Pro M4 avec 48 Go de RAM, est-ce envisageable, réaliste, de faire tourner un modèle local pour développer ? Ou est-ce encore de l’ordre du rêve vu les machines d’aujourd’hui ? Ce retour d’expérience, mené en juillet 2026, documente ce qui a marché, ce qui a échoué, et la méthode à laquelle j’ai abouti.

• Quelle machine pour faire tourner un LLM local ?
• Quel modèle local choisir pour développer ?
• Développer from scratch en local : la douche froide
• Méthode n°1 : Claude Code prépare tout, le local exécute
• Méthode n°2 : les fondations et les tests d’abord
• La délégation one-shot pour les micro-tâches
• Noter ses modèles pour sortir du « ça marche bien »
• Le test grandeur nature : un Snake en 24 secondes
• Température et réglages : le nerf de la guerre
• Là où je me suis foiré : interface de chat et faux correctifs
• La boucle de tests unitaires, la vraie bonne idée
• Aiguiller son apprenti local
• Développer avec un LLM local : pour qui ?
• La suite : deux projets confiés aux agents locaux

Quelle machine pour faire tourner un LLM local ?

Un MacBook Pro M4 avec 48 Go de RAM fait tourner confortablement des modèles de 35 milliards de paramètres quantisés en 4 à 6 bits ; au-delà, ça coince. Concrètement, mon Mac fait tourner des modèles assez bien, je dois dire, mais je reste limité à certaines caractéristiques, certains types de modèles. Première étape, donc : cartographier ce qui tourne sans trop de latence.

• Les modèles 35B en 4 et 5 bits passent bien – notamment les MoE (mixture d’experts) de type « A3B », qui n’activent que 3 milliards de paramètres par token sur les 35 milliards au total (Qwen, Alibaba Cloud, 2026).
• Le 8 bits, c’est la limite : difficile à faire tourner, mon Mac n’aime pas du tout et la vitesse devient bien lente.
• Pour ma config, le bon plafond, c’est du 6 bits.

Une fois cette cartographie posée, c’est déjà plus simple d’imaginer la suite. De mon côté, j’utilise des modèles MLX, le framework open source d’Apple optimisé pour les puces Apple Silicon, et LM Studio pour l’interfaçage, on va dire ça comme ça. Le gros intérêt de LM Studio : il détecte votre configuration et, directement dans la liste des modèles à télécharger, il vous indique ce qui est possible, envisageable, ou pas du tout imaginable sur votre machine.

Quel modèle local choisir pour développer ?

Sur ma configuration, deux familles ressortent pour le code : les Qwen 3.5 et 3.6 d’Alibaba Cloud, et surtout les Ornith, des modèles basés sur Qwen. Grosso modo, pour le moment, j’utilise beaucoup les Ornith pour développer, et j’arrive à des résultats pas trop mal. Le code est généré, et je n’ai pas de boucle infinie qui se répète sur des questions ou du développement, ce qui m’arrive assez régulièrement avec d’autres modèles. Mais là encore, la configuration, le contexte, la température peuvent énormément faire la différence.

Avec le modèle Fable 5 d’Anthropic, je me suis dit que ce serait intéressant d’avoir un petit outil pour changer facilement de modèle, modifier les températures et comprendre vraiment ce que je fais. En parallèle, je me suis donc fait un outil assez simple : je précise les modèles que j’utilise, et j’ai 4, 5, 6 questions à poser pour paramétrer les réglages en amont. Ça me donne des réglages par modèle, de quoi comparer les résultats attendus et démarrer sur deux bonnes bases.

Développer from scratch en local : la douche froide

Premier enseignement : développer une application from scratch avec un seul LLM local, sur ma configuration, ne fonctionne pas. Un MCP ? Pas très fonctionnel. Un plugin WordPress avec un bloc Gutenberg des plus simples ? Pas une grande réussite non plus. C’était pas fou.

Beaucoup d’erreurs, et surtout, à un moment donné, le modèle tournait en boucle quelles que soient mes configurations. Tout simplement parce que lui-même n’avait plus aucune idée de comment solutionner. Là, je me suis dit que mon idée de développer en local était quand même pas mal compromise.

Vous me connaissez, je n’ai pas lâché l’affaire. Je me suis posé pas mal de questions, et une idée a émergé : et si je faisais toute la structure principale de mon idée, mon application, ma fonctionnalité, avec un modèle payant, Claude, pour ensuite déléguer la tâche à un modèle local ? Concrètement, on pourrait l’imaginer en mode apprenti et développeur senior.

L’apprenti, c’est le modèle local.

Le senior, c’est Claude Code.

Je suis parti sur cette idée en m’aidant du modèle Fable 5, tous les curseurs de réflexion au maximum. On ne va pas se le cacher : en cinq minutes d’échange, mon quota de cinq heures était mangé. Mais ces cinq minutes m’ont permis de le pousser au maximum de la réflexion sur la délégation aux modèles locaux, de concevoir plusieurs styles de délégation, et d’avoir une vraie réflexion sur le développement.

Méthode n°1 : Claude Code prépare tout, le local exécute

Première méthode testée : Claude Code génère l’architecture complète – fondations, classes attendues, timeline, tests unitaires – puis un livrable contraint que le modèle local n’a plus qu’à suivre. Ça fonctionne, mais ce n’est pas efficient.

Le cas concret : repartir sur la conception de mon MCP en guise de second cerveau. Claude Code a généré la base de l’application, toute la structure, les fondations, les classes utiles, puis une timeline à suivre, les tests unitaires à lancer après conception, les étapes à réaliser. Tout un cahier des charges à remplir pour que, quand je termine avec le modèle local et que je retrouve ma session Claude, je puisse repartir de là où on s’était arrêté et contrôler.

Résultat : le modèle local a suivi les directives de Claude Code, tout a été généré sans erreur, ou avec des erreurs assumées. Les erreurs que Claude m’avait annoncées en amont comme probables côté modèle local ? Le modèle local les a faites. Rien d’inconnu. Cette passation s’est vraiment bien passée, je trouve.

Restait la question qui fâche : entre la conception de la doc pour le modèle local, tous les tests à réaliser, puis la relecture par Claude Code une fois la session disponible, est-ce que demander directement à Claude de tout réaliser ne serait pas revenu au même ?

Verdict : ça fonctionne, mais ce n’est pas très efficient. Le travail du modèle local est tellement mâché par le modèle payant que ce dernier aurait pu le réaliser lui-même, sans consommer tellement plus de tokens que la génération des livrables et la relecture derrière pour reprendre le travail. Cette façon de faire marche, mais elle fonctionnerait encore mieux avec beaucoup plus à réaliser côté local, et un modèle payant qui en fait moins.

Méthode n°2 : les fondations et les tests d’abord

La méthode la plus rentable que j’ai trouvée : faire réaliser par Claude Code uniquement ce qui ne doit pas bouger – les tables en base de données, les environnements, la partie sécurité – et l’intégralité des tests unitaires, puis laisser le modèle local développer fonctionnalité par fonctionnalité.

Tous les tests, pour toute l’application, nouvelles fonctionnalités comprises. Avec, encore une fois, une documentation tenue à jour. Le modèle local peut alors avancer, puis dérouler les tests unitaires pour s’assurer que rien ne casse. On développe, on corrige avec le modèle local, on lance les tests, on obtient des retours positifs ou négatifs, et on itère.

Après plusieurs tests, cette base de réflexion s’est avérée vraiment positive. Elle m’a permis de travailler quasiment toute une après-midi avec le modèle local sans trop me poser de questions, sans me dire « tiens, je vais retourner sur Claude ». Mes tests unitaires étaient déjà prêts, je n’avais qu’à suivre et dérouler. Une fonctionnalité finalisée ? On la teste. Une erreur ? On corrige, jusqu’à obtenir quelque chose de plutôt pas mal.

La délégation one-shot pour les micro-tâches

Pour déléguer une micro-tâche à n’importe quel moment, un seul fichier suffit : la fonctionnalité attendue, ce qui doit se passer, les specs. Le modèle local le lit et déroule. Après pas mal d’échanges avec le modèle Fable, j’ai conçu ce script de délégation one-shot : je demande à Claude de ne donner que l’essentiel, et j’obtiens un fichier de délégation de la fonctionnalité, prêt à passer au modèle local. Beaucoup plus rapide que la délégation complète, avec ses multiples livrables à créer, remplir et relire. Et comme toujours, tout développement s’accompagne de tests unitaires pour cadrer et valider tout de suite ce qui a été réalisé.

Cette façon de faire, je la trouve plutôt intéressante, parce qu’elle me permet aussi de tester plusieurs modèles en local en me fiant aux tests unitaires, au rendu, aux fonctionnalités.

À cette étape, j’ai une vraie petite symbiose : un modèle senior payant, Claude Code, qui délègue des fonctionnalités à un modèle junior, un apprenti local. Ce fonctionnement tourne bien avec ma machine, et j’ai de la rapidité sans souci avec les modèles que j’utilise.

Noter ses modèles pour sortir du « ça marche bien »

« Bien fonctionner », c’est quand même pas mal subjectif. Du coup, avec Fable, j’ai voulu encore booster la chose : noter les modèles que j’utilise selon plusieurs critères, pour me générer par la suite un petit arbre de décision des modèles à utiliser en fonction de ce que je veux faire.

J’ai donc conçu un outil où je renseigne le modèle, la quantisation utilisée, le poids, vraiment tout ce qui le concerne, avec des questions à poser et la possibilité de noter les réponses. À terme, ça me fait ma petite base de connaissances des modèles utilisables en local sur ma machine, pour développer ou raisonner en fonction des tâches dont j’ai besoin.

La boucle est bouclée : un outil pour poser des questions au modèle et le calibrer, un outil pour le noter au fil des différents développements, et un dernier outil côté skills de Claude pour lui déléguer des choses. De quoi vraiment travailler avec un modèle local.

Je trouve ça très intéressant, parce que tout ce que je fais avec le modèle local reste en local, pour cette partie-là bien évidemment. Et surtout : c’est possible. De nouveaux modèles arrivent tous les jours, toujours plus optimisés.

Déjà aujourd’hui, avec les modèles que j’utilise, du 6 bits maximum, les réponses arrivent vite.

Le test grandeur nature : un Snake

Le modèle qwen3.6-35b-a3b-mlx en 6 bits m’a généré un jeu Snake fonctionnel en quelques secondes, à partir d’un brief one-shot.

Je lui ai donné toutes les specs dont j’avais besoin et envie, pour voir si, en one-shot avec les specs, il peut le réaliser. Claude ou OpenAI le font sans aucun souci, ce n’est pas la question : là, je veux voir si des problèmes apparaissent.

Premier constat, assez intéressant : quelques secondes après mon brief, il m’a signalé qu’il manquait quelques informations pour le jeu, mais l’a réalisé quand même avec ses recommandations (Canvas API). Le jeu est fonctionnel 🧙.

Premier point que je note sur ce premier jet : il consomme un peu de ressources côté navigateur. Je lui demande donc, tout simplement, s’il est possible d’optimiser. Après plusieurs secondes de réflexion et de recherche sur Internet, il me propose un nouveau jeu, lui aussi fonctionnel, avec d’autres éléments pour optimiser.

Personnellement, je trouve cette version un petit peu moins bien visuellement, mais c’était justement une de ses préconisations : il a changé quelques configurations côté jeu. Le jeu fonctionne toujours => je le trouve juste un peu moins fini. Je vais donc lui demander de pousser un peu plus la réflexion, pour un jeu vraiment sympa à jouer et qui ne consomme pas beaucoup. Le jeu est disponible en fin d’article : vous pourrez le tester et voir un peu qui est le meilleur au Snake. 🙂

Température et réglages : le nerf de la guerre

Un LLM local mal configuré finit par tourner en boucle – et qui dit tourner en boucle dit consommer de la ressource sans fin. Et ça, c’est pas bon. En m’attaquant à l’ajustement du jeu, j’ai eu quelques difficultés avec mon modèle.

Petit état des lieux => je ne l’avais pas trop configuré, en fait. Au fur et à mesure, il a commencé à tourner en boucle, sans jamais arriver au bout.

Concrètement : le modèle n’était pas configuré au niveau de la température et des éléments de configuration dans LM Studio. Une fois que j’ai pris le temps d’ajuster avec l’outil que j’ai mis en place, la correction est devenue possible.

J’ai perdu un petit peu de temps, mais c’est tout à fait normal avec un modèle local : le moindre petit réglage peut faire la différence, et pour un modèle qui tournerait en rond pour rien, le réglage en question peut tout changer.

De votre côté, il faut tester, comparer. Et pour vraiment tester et avoir de bons résultats, reposez les mêmes questions pour voir ce que le llm répond. Dans mon cas, j’ai posé plein de fois la même question, sans rien changer, pour repérer à partir de quel réglage il arrête de tourner en rond et me propose quelque chose.

Autre point intéressant : je lui ai mis un prompt système pour mieux gérer les cas de figure et éviter de tourner en boucle.

Un truc à garder en tête aussi : pour tout le jeu, je lui ai demandé à chaque fois de me redonner l’entièreté du code. C’est aussi pour ça qu’il pouvait prendre un chouille de temps en plus – rien d’énorme, environ 20 à 30 secondes à chaque fois, grand max. Et c’est peut-être aussi pour ça qu’il a pu tourner en boucle à des moments. J’ai donc testé de lui demander uniquement les bouts de code à modifier et à corriger.

En faisant ça, il est beaucoup plus rapide, et il peut me dire facilement ce que je dois modifier. Vraiment intéressant de le gérer de cette façon-là aussi.

Là où je me suis foiré : interface de chat et faux correctifs

Deux erreurs à retenir de cette phase, qui a été un peu laborieuse : développer dans l’interface de chat de LM Studio au lieu d’opencode, et croire un modèle local sur parole quand il « commente » ses corrections. Je vous explique sur quoi je me suis complètement foiré, et comment j’ai ajusté.

Très simplement, je n’ai même pas fait attention : au lieu d’utiliser opencode – un agent de code open source en ligne de commande, capable de modifier des fichiers – pour développer le jeu, j’étais sur l’interface de chat de LM Studio.

Ce qui se passe, c’est qu’on y est limité au niveau du contexte, et l’interface ne permet pas de modifier des fichiers. Du coup, c’est un peu laborieux, et le modèle peut tourner en boucle plus vite.

Oui oui, moi même je ne sais pas comment j’ai fait cette erreur et que je ne m’en suis pas rendu compte tout de suite ….

Pour la correction, j’ai demandé à ChatGPT SOL et à Claude Fable de faire juste des audits.

Ils m’ont remonté pas mal de soucis :

• la sauvegarde,
• l’écriture,
• la falsification des scores,
• etc.

Plein de petits problèmes, pas très dramatiques, la sauvegarde de l’historique du jeu étant un vrai plus mais pas une nécessité. Sauf qu’au fil des itérations pour corriger, le modèle tournait assez vite en boucle.

Et ce que j’ai constaté assez rapidement : quand il doit corriger des problèmes de sécurité, d’architecture ou de logique, un modèle local peut insérer des commentaires affirmant que la correction a été faite, alors que rien n’a été modifié dans le code. Clairement, rien.

Après plusieurs tests, je finis par me rendre compte de mon erreur d’interface, et je migre sur opencode. Ce par quoi j’aurais dû commencer pour le jeu.

À ce moment-là, je change aussi de modèle : je prends l’Ornith (ornit-1.0-35b-xl-mlx-5bit), que j’aime beaucoup, et je commence à lui donner les retours remontés par ChatGPT SOL et Claude Fable.

Là, il se met à corriger les choses. Par contre, ses correctifs marchouillent : ça avance, mais ça ne va pas dans le détail.

Alors, pour éviter trop de perte de temps, j’ai fait ce que j’aurais dû faire depuis le début : concevoir d’abord les tests unitaires du jeu avec un modèle beaucoup plus performant, type ChatGPT ou Claude, puis confier au modèle local la conception intégrale du jeu.

L’avantage si j’avais fait ça ? Une version plus rapide, plus fonctionnelle et bien plus sécurisée dès le début. Ce qui n’a clairement pas été le cas.

La boucle de tests unitaires, la vraie bonne idée

La boucle qui fonctionne le mieux possible : un modèle puissant écrit les tests, le modèle local corrige et relance jusqu’à 100 % de réussite – sans jamais modifier les tests.

Typiquement, ce que je me suis amusé à faire : ChatGPT m’a généré des tests, ici surtout pour vérifier des en-têtes HTTP, sous forme d’un fichier de test en Python.

Le modèle local, lui, n’a plus qu’à lancer la commande, voir le résultat, repérer là où ça pêche, et corriger. Il corrige le fichier PHP, relance les tests, regarde ce qui est bon, et recommence, ainsi de suite, jusqu’à obtenir 100 % de tests qui passent. Avec une contrainte évidente : ne jamais modifier les tests pour faire passer un truc qui n’aurait pas dû passer.

En faisant ce type d’exercice, on se rend très vite compte que concevoir d’abord les tests unitaires est encore plus important qu’avant. Le modèle peut se baser sur les tests réalisés pour dire si ça passe ou non, au-delà de la régression. On s’assure au moins de l’attendu du résultat et du côté sécurité, et ça évite au modèle de sortir des cases.

Une fois tous les tests passés avec le modèle local, j’ai refait un check avec ChatGPT SOL, pour contrôler que tout passe bien et qu’on tient maintenant quelque chose de solide.

Quand je dis « solide », ça ne veut pas dire structurellement propre, beau et maintenable : ça veut dire sans faille de sécurité, avec quelque chose d’assez propre.

Il a retesté, confirmé les tests, et m’en a rajouté quatre pour s’assurer encore une fois que tout est ok. Partant de là, je n’ai plus qu’à redemander au modèle local de prendre en compte les nouveaux tests mis en place et de s’assurer que tout passe.

Aiguiller son apprenti local

Un modèle local, c’est un copilote en apprentissage : il conçoit du code, mais il ne sait pas trop ce qu’il fait.

C’est à vous de l’aiguiller, comme un mentor. Vous lui dites ce que vous voulez, vous lui donnez des structures, des règles à suivre : il les suivra. Une façon d’écrire, du typage d’objet : il y arrivera aussi. Par contre, pour de la réflexion sur de grosses problématiques, il faudra vraiment y aller étape par étape.

Mon meilleur conseil : générez à chaque fois des tests unitaires de ce que vous voulez. Comme ça, l’apprenti pourra constamment lancer les tests, voir les résultats et corriger en fonction, pour atteindre l’objectif fixé.

C’est pour moi l’une des meilleures façons de développer avec un modèle local. Et surtout, comme vous êtes en local, vous n’êtes pas limité dans les interactions : ce n’est pas très grave d’avoir beaucoup de va-et-vient entre le LLM et vous.

Ça permet justement de garder la main du début à la fin. En comparaison, un Claude ou un ChatGPT peut vous concevoir énormément de choses d’une traite, mais parfois sans que vous ayez la main, sans que vous sachiez tout ce qui a été conçu. Là, au moins, on évite ce genre de cas.

Autre point très important : il faut aiguiller le modèle sur les limites de son environnement. Dans mon cas, à un moment donné, pour éviter des lectures de fichiers qui ne devraient pas être lus => il doit générer un .htaccess. Or, un environnement local en ligne de commande qui lance du PHP ne va pas lire de .htaccess. Du coup, le modèle tourne en boucle : il voudrait le mettre en place, mais le test le refusera. C’est à vous, à ce moment-là, de savoir ce que vous faites, et de lui préciser que ce n’est pas grave si ce test échoue, parce qu’on le testera en live directement. Ce qui nous donne au final 28 tests sur 29 qui passent, le 29e devant être réalisé sur le serveur de production.

Pour terminer, je fais évidemment une passe sur le fichier HTML, ma demande étant un fichier unique embarquant le CSS et le JS. Une dernière passe, et j’ai mon jeu suffisamment sécurisé pour la démo.

Développer avec un LLM local : pour qui ?

Développer avec un LLM local s’adresse à un développeur qui sait ce qu’il fait : un code généré en local peut être fonctionnel en apparence et embarquer des failles de sécurité.

La première version générée par le qwen3.6 fonctionnait. À première vue, tout était nickel, tout tournait comme il fallait, pas de problème. Quelqu’un qui se dit « je vais développer en local sans trop me poser de questions », le résultat est là : le jeu est fonctionnel.

=> Par contre, quand on ne sait pas ce qu’on fait, on crée des failles de sécurité qui peuvent poser problème par la suite. C’est pour ça que, pour moi, développer en local reste réservé à des développeurs qui savent ce qu’ils font, capables d’aiguiller, de voir les problèmes et de corriger.

La suite : deux projets confiés aux agents locaux

Pour continuer dans mes tests, deux choses vont être réalisées par des agents locaux, avec la méthode décrite ici : fondations et tests unitaires par Claude Code, implémentation par le modèle local.

La première : un site pour le sport, pour tracker correctement mon activité physique, simple et mobile first. L’idée, c’est le principe des applications de sport où vous rentrez vos séries, ce que vous réalisez, votre parcours. Sauf que là, tout sera totalement gratuit et open source. Et en plus, je vais rajouter des graphes, des stats, la possibilité d’exporter si besoin, et une connexion via des webhooks, donc du n8n ou des agents via une autre configuration. Dans mon cas, l’idée sera de connecter avec mon agent perso et quand je lui parle, il envoie les données au site pour le mettre à jour. Et quand je consulte, j’ai tout de suite mes graphes et mes stats comme il faut, je sais où j’en suis.

La seconde : un agenda numérique, mobile first lui aussi. L’idée sera de pouvoir générer des inscriptions via des liens, afin de restreindre les inscriptions, avec tout un agenda pour le planning d’une personne. Le tout connecté à Google Agenda pour que, en fonction de certaines règles, les clients puissent prendre. un rendez-vous, avec un ajout automatique dans Google Agenda. Et en plus de ça, un envoi de SMS automatisé.

Conclusion

Développer avec un LLM local est possible dès aujourd’hui, à condition de respecter des règles : le modèle payant conçoit, le modèle local exécute, et les tests unitaires arbitrent.

Cette façon de développer va me permettre de concevoir toute une architecture en amont, puis de tout réaliser avec un modèle local :

• j’optimise mon utilisation du modèle payant,
• je l’utilise uniquement là où je table sur ses avantages,
• et je laisse les modèles locaux faire le travail de la main-d’œuvre

Le lien vers le jeu => Snake