La machine reste la même, je le précise pour ceux qui voudraient avoir un point de comparaison avec leur configuration : un Mac mini M4 Pro, CPU 14 cœurs, GPU 20 cœurs et 48 Go de mémoire unifiée. Pour ces essais, j’ai retenu OpenCode 2 comme outil de codage et oMLX comme moteur d’inférence pour les modèles locaux. Ce choix a notamment été guidé par leur excellente gestion du cache LLM : éviter de retraiter du contexte déjà envoyé au modèle est un élément clé dans la performance finale. Quand une tâche enchaîne les lectures de fichiers et les appels d’outils, un problème de cache peut rendre un modèle inutilisable. L’utilisation de Pi ou Claude Code comme harnais et d’Ollama ou LM Studio côté moteur d’inférence donnerait des résultats nettement différents.¹

Les modèles retenus pour le test

Je suis parti de Qwen3.8 27B, la star du moment, puis j’ai élargi la sélection en cherchant un meilleur compromis entre qualité et durée. Les attentes étaient les suivantes :

• Qwen3.8 27B, en effort medium : la référence du LLM local constitue mon point de départ. Je sais déjà qu’il peut être assez bavard (donc lent), c’est pourquoi j’utilise le niveau d’effort « medium ».
• Swift 1.5 27B, en efforts medium et low : j’ai repéré cette variante de Qwen pour son fil de pensée annoncé plus court. L’idée est de voir combien de temps cela fait gagner, et à quel point cela affecte la qualité du résultat.
• Bonsai 2 27B, en version ternaire : sa plus petite empreinte mémoire me faisait espérer une exécution plus rapide. Je voulais aussi voir si cette variante conservait les capacités du Qwen dont elle est dérivée, selon ma compréhension du modèle. Malheureusement, les options d’optimisation disponibles pour les modèles précédents ne sont pas possibles avec ce modèle.
• Ornith 1.5 35B-A3B et LFM2.5 24B-A2B : après les premiers résultats encourageants de Qwen, j’ai voulu essayer des modèles que je supposais moins capables, mais beaucoup plus rapides. Si ces modèles sont capables d’atteindre un niveau de qualité suffisant, leur performance sera un atout certain.

J’ai ajouté GPT-6.1 Sol en effort medium comme point de comparaison non local. Il ne tourne évidemment pas sur le Mac ni dans oMLX. Au total, cela donne cinq modèles locaux, dont Swift essayé avec deux niveaux d’effort différents.

Le test : deux tâches à réaliser sur un projet que je connais bien

Afin d’évaluer la qualité de raisonnement des différents modèles, je les confronte à un projet web que j’ai développé sans IA avec une architecture et des design patterns assez classiques mais n’utilisant pas un framework connu existant. L’accès aux données se fait également par une API plutôt originale que les modèles n’auront probablement pas directement dans leurs connaissances (l’API FileMaker Server est très peu répandue et spécifique à ce projet).

Première tâche : comprendre le projet

La première demande consiste donc à explorer le dépôt puis à rédiger un fichier AGENTS.md, destiné à guider les prochaines interventions sur le code. Le document doit expliquer le rôle de l’application, son organisation, ses mécanismes internes et ses données, en renvoyant aux fichiers et aux symboles concernés. J’ai donné une consigne de longueur entre 800 et 1 200 mots.

Quand j’ai utilisé pour la première fois Claude Code, en juillet 2025, la première tâche que je lui avais confié était la même et il m’avait épaté : il avait tout compris au projet en une dizaine de minutes… est-ce que les modèles locaux seront au niveau ?

Pour évaluer le résultat, je me suis fixé d’avance un barème un peu arbitraire : Exactitude technique (30 points), compréhension et couverture (25), utilité pour intervenir (20), références au code et distinction entre faits et incertitudes (15), concision et respect des consignes (10)

Deuxième tâche : implémenter une fonctionnalité

Après la rédaction du fichier AGENTS.md, je lui demande d’implémenter une fonctionnalité simple qui nécessite cependant d’éditer à la fois une vue, un contrôleur et la couche modèle de données, en s’adaptant à la structure existante et à l’API qu’il ne connait initialement pas.

Mon barème arbitraire pour cette tâche : Parcours fonctionnel (40 points), intégration des données (20), validation et gestion des erreurs (20), protections (10), intégration dans le code existant (10)

Je n’avais pas prévu une difficulté d’évaluation : certains modèles ont eu l’idée de me poser une question assez pertinente sur les droits d’accès souhaités, ça mériterait peut-être des points bonus (pour Qwen et Ornith).

Les résultats

Quelques remarques préliminaires : LFM2.5 n’a pas réalisé la seconde tâche. Dans l’association oMLX–LFM2.5–OpenCode que j’ai testée, le cache ne s’est jamais déclenché. Le problème pénalisait suffisamment les performances pour que j’abandonne le test pour ce modèle, sans avoir identifié sa cause. Comme la qualité du résultat pour la tâche 1 n’était pas au rendez-vous, je n’ai pas insisté.

En ce qui concerne le temps passé par les autres modèles locaux sur la tâche 2 : ils ont tous eu besoin de compacter le contexte une fois pendant la deuxième tâche (le contexte max. était de 120k tokens).

Une seule exécution a été évaluée par configuration et par tâche. La première tâche a été évaluée en cachant les noms des modèles et en les mélangeant ; la seconde tâche n’était pas anonymisée. Pour le code, il s’agit d’une revue et d’un contrôle syntaxique, sans validation fonctionnelle de l’application.

Ce que ces essais font ressortir

Swift en effort medium est clairement le gagnant. Il reste très proche de Qwen pour l’analyse du projet et obtient une meilleure note pour la modification du code, en prenant moins de temps sur les deux tâches. Pour bien interpréter les notes attribuées par mon barème, je dirais que la qualité obtenue dès le premier jet est tout à fait satisfaisante au delà de 65/100. Le réglage effort low n’a pas apporté le gain de temps attendu pour une qualité de résultat nettement inférieure…

Les statistiques d’oMLX donnent aussi un éclairage intéressant : Swift medium a produit environ 25 100 tokens sur les deux tâches, contre 42 100 pour Qwen. Leur débit moyen de génération est autour de 11,5 tokens par seconde (À taille de contexte égale, leur débit est identique : il atteint 25 tok/s quand le contexte est vide, puis diminue au fil de la génération). C’est la quantité de tokens nécessaire qui fait varier le temps d’attente quand on compare ces modèles ayant la même architecture. Il faudrait atteindre un débit d’au moins 50 tok/s pour utiliser confortablement un modèle.

Le test de Qwen sur la tâche 1 donne un exemple assez parlant du temps qui peut être perdu par un modèle trop bavard. Au bout d’environ trente minutes, il avait produit un résultat tout à fait satisfaisant. Mais il a ensuite passé vingt minutes à raccourcir le document, en plusieurs passes, de 1270 mots à moins de 1200 afin de bien respecter ma consigne de longueur.

Bonsai m’a déçu sur la vitesse : avec sa petite empreinte mémoire, j’espérais obtenir des résultats plus rapides. Malheureusement, son architecture un peu différente des modèles plus répandus ne peut pas profiter des mêmes optimisations (Lightning MTP indisponible, quantification du cache KV qui réduit trop la qualité du résultat). Il ne sera intéressant que si votre configuration dispose de moins de mémoire.

Seuls Swift 1.5 27B medium et Qwen3.8 27B medium ont livré un code ne nécessitant pas une seconde passe de correction. C’est impressionnant de leur part… il y a quelques mois, je n’aurais pas cru cela possible. Les modèles dérivés de Qwen3.8 ont aussi tenté de réaliser des tests de validation du résultat (mais le projet fourni ne pouvait malheureusement pas être testé sans son accès à FileMaker, indisponible ici). Cela relègue les modèles plus petits loin derrière.

Si j’en reviens à ma découverte de Claude Code en juillet 2025, lorsque je lui avais confiée la même tâche d’analyse du projet… je dois avouer que je suis vraiment épaté par le résultat de Qwen3.8 et de Swift1.5 : ils me semblent qualitativement encore meilleurs. C’est une appréciation de mémoire, pas une comparaison contrôlée avec le modèle de l’époque (Sonnet 4 ou peut-être Opus 4), mais elle explique pourquoi ces essais restent encourageants malgré la lenteur.

Quarante minutes, c’est trop long ?

Pour mon travail quotidien, ces essais ne changent pas encore le constat que je faisais la dernière fois : GPT-6.1 fait mieux et beaucoup plus vite, et l’attente reste difficilement praticable sur M4 Pro (surtout que pendant que le LLM local travaille, je dois laisser le maximum de RAM disponible pour lui). Le modèle Swift1.5 medium est néanmoins une piste locale intéressante.

Malgré la qualité encourageante que j’ai observée aujourd’hui, je vais attendre de nouveaux modèles ou des optimisations du moteur d’inférence avant de poursuivre ce genre de tests. La donne changera certainement après la sortie de nouveaux processeurs également.

Prochaine étape : trouver des tâches plus simples ou avec plus d’autonomie pour profiter de cette “intelligence” lorsque je ne suis pas devant mon poste à attendre son résultat ?

1. Pour vous en convaincre, consultez l’excellente vidéo “10 harnais IA locale testés : la RÉDEMPTION d’OpenCode 2.0” réalisée par le développeur d’un harnais dédié à la bonne gestion du cache. Il rentre dans le détail très précis. Je pensais éviter OpenCode à cause de son précédent test mais les soucis de gestion du cache de la v1 sont largement résolus dans la v2 ︎

Un premier constat : l’IA locale fonctionne très bien pour la dictée vocale et donne des résultats très convaincants pour la voix, la génération et l’édition d’images. Pour les LLM, tout dépend de l’usage concret et de vos attentes en terme de performance. Pour un usage de programmation au quotidien en remplacement d’un Claude Code ou Codex, on est encore loin du compte selon moi¹, même si les modèles récents me donnent envie d’espérer.

La configuration de référence

Mes essais se font sur un Mac mini M4 Pro (CPU 14 cœurs, GPU 20 cœurs) et 48 Go de mémoire unifiée, acheté en décembre 2024. C’est aussi ma machine de travail de développeur. Si vous envisagez un achat pour l’IA locale, ces retours devraient vous aider à situer ce qu’on peut attendre de cette configuration. Pour simplifier, la quantité de RAM permet de savoir si on est en mesure de charger un modèle et la quantité de cœurs GPU ainsi que l’architecture (Mx Pro, Mx Max ou Mx Ultra) influencent ensuite la performance. Pouvoir charger un modèle en mémoire ne dit pas encore s’il sera agréable à utiliser.

La voix et les images : déjà convaincantes

Avant de parler des LLM, trois usages d’IA méritent un détour :

• La dictée vocale, avec Handy et le modèle Parakeet. 16 Go de RAM suffisent pour utiliser cet outil en complément de vos logiciels. La qualité de retranscription surpasse la reconnaissance vocale intégrée du Mac au point de trouver sa place dans mes usages quotidiens.
• La génération et l’édition d’images, avec Draw Things et des modèles FLUX, Z-Image et Qwen. Là aussi, mon bilan est très positif. La retouche d’une image existante par un prompt fait des merveilles. Je ne suis pas certain d’utiliser vraiment la génération d’image pure. L’illustration en haut de cette page est un exemple de génération d’une « illustration minimaliste représentant une boîte grise à la forme d’un Mac mini contenant un mécanisme d’horlogerie ». Pour utiliser confortablement ces outils, mieux vaut avoir au minimum 32 Go de RAM et plus de 10 cœurs GPU.
• La synthèse et le clonage de voix, avec Voicebox, notamment les modèles Qwen3-TTS. Je suis davantage dans l’expérimentation, mais les résultats m’ont beaucoup plu. Je n’ai actuellement aucun besoin d’un tel outil mais je pense expérimenter sur la création autonome de présentations résumées avec VoiceOver. À ma connaissance, il n’existe pas encore de modèles d’IA francophones permettant de contrôler finement l’intonation et l’émotion simulée.

L’IA locale vaut donc déjà le coup sur cette machine et il y a tout un foisonnement de modèles à essayer. Mais le gros morceau arrive : les LLM, et le bilan est ici moins évident.

Les LLM : faire tourner un modèle ne suffit pas

Sur les “petits” Mac avec 24 Go de RAM ou moins, on peut charger et faire tourner des petites versions des modèles Gemma-4 (à 2, 4 ou 12 milliards de paramètres) ou Qwen à 9 milliards de paramètres. Ces modèles fonctionnent pour une petite discussion mais ont une capacité de raisonnement limitée et je n’en trouve aucun usage concret.

Avec 48 Go de RAM, j’ai pu essayer une plus grande variété de modèles, notamment les plus grosses versions des familles Gemma et Qwen (autour de 30 milliards de paramètres). Certains répondent assez vite (dans les 60 tokens par seconde pour les modèles MoE²) mais sont encore trop imités pour réaliser des tâches intéressantes ; d’autres donnent de très bons résultats mais sont excessivement lents (20 tokens par seconde en début de travail puis 10 tokens ou moins par seconde une fois que le contexte de travail s’étend). J’ai passé beaucoup de temps à essayer différentes combinaisons, sans trouver pour l’instant un usage assez utile pour s’installer dans mon quotidien.

En dehors d’une contrainte de confidentialité imposant le travail 100% local, les services par API distantes sont largement le choix le plus raisonnable. Si on souhaite éviter OpenAI et Anthropic pour des questions budgétaires, on peut se tourner vers des modèles peu chers par API comme l’excellent Deepseek 4.1 flash : plus rapide et plus qualitatif qu’un modèle local. Le meilleur modèle local qui fonctionne sur ma machine, Qwen3.8 27b, a passé plus de 40 minutes à répondre à une petite demande simple sur du code lors de mes premiers tests.

J’ai toutefois l’impression que les modèles sortis récemment pourraient faire évoluer ce bilan. L’actualité est brûlante et il y a de nouvelles choses à tester chaque semaine. Si une solution permet de faire un nouveau bon en qualité ou en vitesse d’inférence, on peut atteindre un niveau où il devient envisageable d’utiliser cela au quotidien sur un Mac milieu de gamme.

Ce que je vais explorer

Les prochains articles de la série « IA Locale » porteront principalement sur des tests de trois éléments :

• Les moteurs d’inférence : les logiciels qui exécutent les modèles, avec leurs différences de vitesse, de réglages et de facilité d’utilisation.
• Les modèles de langage : la qualité des réponses, la mémoire nécessaire et le temps d’attente pour une tâche donnée.
• Les outils de codage, ou « harness » : les logiciels qui entourent le modèle pour lui permettre de travailler sur un projet, modifier des fichiers et lancer des commandes.

Ma recommandation actuelle suite à mes tâtonnements va pour oMLX (pratique et performant) faisant tourner Qwen3.8 27b (très lent mais capable d’assez bons raisonnements) utilisés par OpenCode (choisi par défaut et qu’il me faut vite comparer à Pi ou d’autres).

La liste d’éléments à tester est longue !

1. Sur les Mac Studio avec puce Ultra et plus de 128 Go de RAM, la situation est différente, on doit pouvoir faire fonctionner Qwen 3.8 flash Next de façon confortable pour une utilisation bien réelle… mais on parle ici de machines à plus de 6000 € ︎
2. Les modèles MoE pour Mixture of Experts sont plus rapides car seulement une partie des paramètres chargés en mémoire sont utilisés à chaque instant. Le gain en rapidité semble se faire au prix d’une certaine capacité de raisonnement. ︎