J'ai créé mon IA en local sur mon MAC (partie 3) — Le virage MCP

Le jour où mon Mac a cessé de simplement "réfléchir" pour commencer à "travailler"

On est à la mi-janvier 2026. Mes deux premiers articles (partie 1 et partie 2) viennent de sortir et, honnêtement, je pensais avoir trouvé mon équilibre avec mon MacBook Pro M3 Max et ses 48 Go de mémoire. Je faisais rouler Qwen 14B à une vitesse fulgurante de 127 tokens par seconde. C'était grisant, presque hypnotique de voir le texte défiler plus vite que mon cerveau ne pouvait le lire. Mais après quelques semaines d'utilisation intensive pour du développement complexe, j'ai frappé un mur invisible.

Le constat était là : dès que je demandais à l'IA de jongler avec des architectures logicielles entières ou de déboguer des intégrations asynchrones, le modèle 14B commençait à « halluciner » ou à perdre le fil de la logique. J'avais besoin de plus de neurones, de modèles plus denses comme le 32B ou le 70B, mais ma machine de l'époque s'essoufflait. Charger un modèle de 32B sur 48 Go de RAM, c'est comme essayer de faire entrer un divan trois places dans une Mini Cooper : ça rentre, mais tu ne peux plus conduire.

L'envie de passer à la vitesse supérieure est devenue une obsession technique. Je voulais tester les limites de l'inférence locale sans compromis sur la précision. C'est là, au début de février 2026, que j'ai pris la décision qui allait redéfinir mon environnement de travail pour les prochaines années : j'ai craqué pour le nouveau MacBook Pro M4 Max avec 128 Go de mémoire unifiée.

Le cimetière des solutions : 47 configurations plus tard

On ne passe pas d'un simple chat à un système de production sans casser quelques œufs. Pour arriver à la stabilité actuelle de mon projet ANNY, j'ai dû traverser un véritable champ de mines technique. J'ai testé plus de 12 modèles différents, allant des petits modèles de 3 milliards de paramètres (trop limités pour de la logique complexe) jusqu'aux géants de 70 milliards (trop lents pour un flux de travail fluide, même sur un M3 Max avec 48 Go de mémoire unifiée). J'ai vu des modèles "halluciner" des fonctions entières ou se perdre dans des boucles infinies de politesses inutiles.

Le plus grand sacrifice ? Ollama. Je sais, c'est l'outil chouchou de la communauté, et la version 0.19 avec l'intégration MLX est prometteuse en 2026. Mais pour mes besoins de production, Ollama était trop gourmand en ressources persistantes, même au repos. Quatre-vingt-seize gigaoctets de modèles pour quarante-huit de RAM disponible : le calcul ne fonctionnait pas. J'ai aussi abandonné LM Studio, qui est superbe visuellement, mais trop fermé pour une automatisation poussée.

Mon chemin m'a mené vers une implémentation MLX native — le framework open source d'Apple conçu spécifiquement pour ses puces M. C'est la différence entre traduire un livre avec Google Translate et le lire dans sa langue d'origine.

Le tableau des survivants

Le virage matériel : j'ai fini par craquer pour 128 Go

Pourquoi ne pas avoir attendu un Mac Studio ? La question est légitime. Pour mon usage, la portabilité reste non négociable. Je veux pouvoir raffiner mes modèles dans un café du Vieux-Québec ou sur la terrasse d'un chalet dans Charlevoix, sans sacrifier la puissance brute. En passant au MacBook Pro M4 Max au début de février 2026, je ne cherchais pas seulement un processeur plus rapide, je cherchais de l'espace de manœuvre. Avec 128 Go de mémoire unifiée, le terrain de jeu change complètement de dimension. On ne parle plus de « faire rouler » une IA, on parle de l'intégrer nativement dans son flux de production sans aucune friction.

Ce qui fait la force de cette machine, au-delà du nombre de cœurs, c'est sa bande passante mémoire phénoménale de 546 Go/s. En IA locale, c'est souvent le goulot d'étranglement principal. Plus les données circulent vite entre la mémoire et les unités de calcul, plus les réponses générées par le modèle sont fluides. Avec cette configuration, j'ai pu enfin charger des modèles massifs comme Llama 3.3 70B ou Qwen 2.5 72B en 6-bit, tout en gardant assez de ressources pour mes outils de développement, mon navigateur et mes conteneurs Docker.

L'avantage majeur de l'architecture d'Apple réside dans la gestion de la mémoire. Contrairement à un PC traditionnel où l'on doit copier les données de la RAM système vers la VRAM de la carte graphique, ici, tout le monde mange à la même table. Le CPU, le GPU et le Neural Engine puisent directement dans le même bassin de 128 Go. C'est ce qui permet de faire rouler des modèles qui demanderaient normalement deux ou trois cartes graphiques professionnelles très coûteuses sur une station de travail classique.

À l'époque, sur mon M3 Max de 48 Go, j'avais arrêté mon choix sur Qwen 2.5 Coder 14B en quantification 4 bits. C'était le « sweet spot » de ce matériel : assez intelligent pour comprendre une architecture logicielle, mais assez léger (8-9 Go en usage) pour laisser de la place à mes autres applications. Pour ceux qui ont suivi mon deuxième article sur l'optimisation des performances, vous savez que la vitesse est cruciale. Mais la précision l'est encore plus. J'ai configuré des "presets" de température très stricts : 0,3 pour le codage pur afin d'éviter toute fantaisie, 0,4 pour la revue de code, et jusqu'à 0,6 pour l'architecture, où j'ai besoin d'un peu plus de créativité de la part de la machine.

Depuis que j'ai migré sur le M4 Max, ma configuration de prédilection s'est stabilisée sur Qwen 2.5 Coder 32B 6-bit MLX, qui tourne entre 20 et 25 tokens par seconde avec environ 32 Go de mémoire en charge (24 Go pour le modèle, le reste pour le contexte et le runtime). C'est le point d'équilibre idéal : la quantification 6-bit préserve davantage de précision que le 4-bit standard — un gain de qualité qui se sent immédiatement sur du code complexe. Combiné au score de 74 % sur le benchmark aider (contre 69 % pour la version 14B), j'obtiens un modèle local solide pour le code du quotidien, qui me dépanne très bien sur la plupart des tâches sans avoir à sortir du Mac.

8 agents, 1 cerveau : l'orchestration par LangGraph

Avoir une IA puissante, c'est bien. Avoir une équipe d'IA qui collabore, c'est une révolution. Pour ANNY, j'ai structuré mon backend avec Laravel 12 Octane pour la rapidité, mais le véritable chef d'orchestre est un script Python utilisant LangGraph. Imaginez une salle de réunion où chaque siège est occupé par un expert spécialisé. Au lieu d'avoir une seule IA qui essaie de tout faire (et qui finit par tout rater), j'ai divisé le travail en 8 agents autonomes.

Il y a le Planner, qui décompose ma demande en étapes logiques. Le Coder écrit le code, mais il ne peut pas le soumettre directement : il doit passer par le Reviewer, qui vérifie la qualité et la sécurité. Le Tester écrit et lance les tests unitaires dans un environnement isolé, tandis que le Debugger intervient uniquement si une erreur est détectée. On a même un agent Multi-file capable de comprendre comment un changement dans un fichier CSS peut briser un composant React à l'autre bout du projet. Et un agent Browser qui peut naviguer sur le web pour vérifier une documentation d'API récente.

Ce qui rend ce système unique, c'est que ces agents ne sont pas juste des "prompts" différents envoyés au même modèle. Ce sont des entités qui ont accès à mes 8 serveurs MCP personnalisés. Mon IA locale peut maintenant "voir" mon historique Git, fouiller dans ma documentation via un système RAG (Retrieval-Augmented Generation) basé sur GraphRAG, et même naviguer sur le web pour vérifier une documentation d'API récente.

L'orchestrateur LangGraph s'assure que le flux de travail ne part pas en vrille. Si le Reviewer rejette le code, il le renvoie au Coder avec des instructions précises. Ce cycle se répète jusqu'à ce que le résultat soit acceptable. C'est une forme de raisonnement itératif que même les plus gros modèles cloud ont parfois du mal à maintenir sans coûter une fortune en jetons. Chez moi, ça coûte exactement zéro dollar par mois, et ça fonctionne même quand le Wi-Fi du chalet décide de prendre une pause.

C'est ici que les 128 Go de mémoire montrent leur véritable utilité. Auparavant, avec 48 Go, la mémoire devenait vite un goulot d'étranglement dès que je lançais deux agents simultanément : le système basculait sur le swap et tout ralentissait. Aujourd'hui, je peux faire cohabiter un « cerveau » massif comme Qwen 72B (qui occupe environ 40 à 50 Go) avec des agents spécialisés plus légers comme Qwen 7B (4 Go) sans aucun ralentissement. Cette architecture multi-agents devient fluide : le gros modèle s'occupe de la stratégie globale tandis que les petits modèles exécutent les tâches de vérification ou de formatage en parallèle, le tout résidant confortablement dans la mémoire vive.

8 serveurs MCP faits maison : le système nerveux de mon IA

Le MCP, c'est le système nerveux qui relie le cerveau (Qwen) aux mains (les outils système). Sans lui, mon IA est un géant paralysé : elle peut penser, mais pas agir. J'ai codé 8 serveurs MCP personnalisés avec le SDK officiel @modelcontextprotocol/sdk, chacun gérant un domaine précis :

• Filesystem — lire, écrire et lister des fichiers de façon sécurisée, dans un périmètre restreint (sandboxé)
• Git — status, diff, commit, push. L'IA manipule le versionnage sans jamais toucher aux repos clients
• RAG / GraphRAG — rechercher, indexer et interroger ma base de connaissances techniques, vectorisée localement
• Security — audits de code, scans de vulnérabilités, chiffrement de fichiers sensibles
• Web — scraping léger et appels d'API publiques pour vérifier la documentation
• Data — traitement de CSV, JSON, calculs statistiques locaux
• Logs — monitoring des exécutions IA, debug en temps réel
• MacOS tools — intégration Calendar, Finder, notifications système

Le résultat ? Qwen peut maintenant agir comme un développeur senior : "Vérifie le diff Git du dernier commit, indexe ce PDF dans GraphRAG, génère les tests unitaires, commit et push sur la branche de dev." Tout local, zéro fuite, zéro facture cloud.

Le pont final : quand Claude Code appelle mon Mac

Voici la pièce maîtresse du puzzle. Mon serveur central anny-mcp, écrit en Node.js, expose l'IA locale comme un outil que les IA cloud peuvent appeler via le protocole MCP. Concrètement, quand je travaille dans Claude Code (l'outil CLI d'Anthropic), certaines tâches sont trop sensibles pour le cloud. Le code métier d'un client, une migration de base de données avec des identifiants réels, une analyse de logs contenant des informations personnelles.

Le flux est simple et élégant :

1. Je formule ma demande dans Claude Code : "Implémente ce module avec mes librairies locales"
2. Claude détecte que la tâche implique des données sensibles et délègue à anny-mcp
3. anny-mcp route la demande vers Qwen locale, qui s'appuie sur les 8 serveurs MCP pour lire les fichiers, consulter le Git et interroger la documentation
4. Qwen génère le code, le Filesystem l'écrit, Git le commit. Le résultat est renvoyé à Claude
5. Claude orchestre la suite : revue de code, tests d'intégration, merge

C'est une architecture hybride : on délègue au cloud (Claude, GPT) l'orchestration créative et les tâches complexes, tout en gardant en local (Qwen + MCP) tout ce qui touche aux données sensibles. Ça permet de profiter de la puissance des gros modèles sans sacrifier la confidentialité.

Mon tableau de bord dans la barre de menu

Pour que tout ça roule sans accroc au quotidien, j'ai développé une petite application macOS en Python (empaquetée avec py2app) qui vit dans ma barre de menu. Un simple coup d'œil me donne l'état de santé de mon infrastructure : utilisation CPU, mémoire RAM, vitesse de génération en jetons par seconde, et le statut de chacun des 9 serveurs (anny-mcp + les 8 serveurs MCP).

Le bijou de l'ensemble, c'est le Resource Guard. C'est un système d'auto-régulation qui surveille la charge globale du Mac. Un petit daemon scrute la machine toutes les deux secondes. Si la RAM dépasse 85 % ou le CPU atteint 90 %, il met en pause les inférences de Qwen dans la foulée — pas instantanément, mais en deux à trois secondes, le temps que le signal atteigne le processus et que la génération en cours s'interrompe proprement. La reprise suit la même logique inverse : dès que la RAM retombe sous 70 %, le traitement redémarre en une à deux secondes. Cette marge d'hystérésis évite le yo-yo entre pause et reprise quand les ressources oscillent. Zéro crash, même sous charge intense avec trois agents qui travaillent en parallèle.

Ça tourne depuis quelque temps en production : stable, silencieux, et complètement autonome. Le matin, je jette un œil à la barre de menu, je vois 150 tok/s au repos, zéro dollar de cloud consommé, et je sais que mon "cerveau numérique" est prêt à travailler. Pour un développeur ou une petite équipe, c'est le genre d'outil qui permet enfin de dormir sur ses deux oreilles, en sachant que la logique métier reste bien à l'abri derrière le pare-feu. Pour les plus paranos, rien n'empêche de débrancher complètement internet pendant une session sensible : tout le pipeline — MLX, Qwen, les serveurs MCP locaux — continue de fonctionner sans broncher. Une fois le modèle téléchargé, il n'y a plus une seule requête qui part vers l'extérieur.

Ce que ça change concrètement

Récapitulons les gains mesurables de cette aventure :

• Coût mensuel : 0 $ (contre plusieurs centaines en API cloud)
• Confidentialité : conformité Loi 25, zéro donnée envoyée à l'extérieur
• Performance : 150 jetons/seconde en MLX natif, démarrage instantané
• Agents : 8 spécialistes qui collaborent via LangGraph
• Outils : 47 actions MCP disponibles (filesystem, Git, RAG, sécurité...)
• Architecture hybride : le cloud pour la stratégie, le local pour l'exécution sensible

Et 2026 s'annonce comme l'année de l'explosion de l'IA locale. Ollama 0.19 intègre enfin MLX nativement avec des gains de performance de 1,6x en pré-remplissage et 2x en décodage. Qwen3.5, le nouveau modèle d'Alibaba, repousse les limites du codage local. Et le MCP est en train de devenir le standard universel — Claude Code, Cursor, VS Code, tout le monde l'adopte.

L'IA locale n'est plus un simple terrain de jeu pour les curieux. C'est devenu une option viable, économique et surtout souveraine. Reprendre le contrôle de sa pile technologique demande un effort initial, mais la liberté que ça procure en vaut largement la peine. Ceux qui veulent franchir le pas mais qui n'ont pas envie de passer des semaines à tester des dizaines de configurations peuvent toujours m'écrire. J'aime bien échanger avec d'autres curieux de l'IA locale. Pour aller plus loin, explorez notre catégorie Intelligence artificielle ou la collection de nos outils gratuits pour développeurs.

— Stéphane Lapointe, développeur fullstack et passionné d'IA locale, Québec, avril 2026

Sources et références

Les chiffres et affirmations techniques de cet article sont tirés de sources officielles et de benchmarks communautaires vérifiés en avril 2026.

• Spécifications MacBook Pro M4 Max (128 Go, 546 Go/s, 16 CPU / 40 GPU / 16 Neural Engine) : apple.com/ca/fr — Mac
• Framework MLX (Apple Silicon, code ouvert) : github.com/ml-explore/mlx
• Modèles Qwen 2.5 Coder (14B, 32B, 6-bit MLX community) : huggingface.co/mlx-community
• Benchmark aider (scores code des modèles locaux vs cloud) : aider.chat/docs/leaderboards
• Model Context Protocol (standard ouvert d'Anthropic) : modelcontextprotocol.io
• LangGraph (orchestration multi-agents) : github.com/langchain-ai/langgraph
• Ollama 0.19 avec MLX (intégration native Apple Silicon) : ollama.com/blog
• Limites API GitHub (5 000 requêtes/heure pour comptes authentifiés) : docs.github.com — rate limits
• Loi 25 du Québec (protection des renseignements personnels) : Commission d'accès à l'information du Québec
• Qwen 3.5 (février 2026) : qwen.ai — Alibaba Cloud

Les benchmarks de tokens/seconde sont des extrapolations basées sur des rapports communautaires (Hugging Face, Reddit r/LocalLLaMA, blog Simon Willison) et peuvent varier selon la version de MLX, le contexte, la charge système et les paramètres de quantification. Pour des chiffres précis sur votre propre machine, testez directement avec mlx_lm.generate.

Questions fréquentes