On peut le faire en combinant MCP avec Qwen3.6-35B-A3B. MCP standardise l’accès aux outils, Qwen apporte le raisonnement agentique local. Le vrai sujet, c’est le montage propre entre modèle, outils, dépôt de code et matériel.
À quoi sert MCP ?
MCP sert à connecter un modèle IA à des outils externes avec un protocole standard, au lieu de recoder une intégration différente pour chaque modèle ou chaque application. C’est vraiment l’idée centrale. On arrête de bricoler des ponts sur mesure partout, et on donne au modèle une façon propre de demander des actions.
Un modèle local, comme Qwen, sait très bien raisonner sur du texte. Il peut lire une consigne, comprendre un bout de code, résumer un document, proposer une réponse. Mais naturellement, il ne sait pas appeler votre API interne, parcourir un dépôt Git, lire un fichier sur votre machine, lancer un script, interroger une base ou préparer une action métier.
Sans couche standard, chaque outil devient une intégration spécifique. Une intégration pour tel modèle. Une autre pour telle interface. Une autre pour tel script maison. Et là, je l’ai vu chez des clients, ça marche deux semaines puis ça casse dès qu’on change un chemin, une version, un format de réponse ou un modèle. C’est fragile, pénible à maintenir, et surtout ça ne scale pas.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
MCP, pour Model Context Protocol, est un protocole ouvert proposé par Anthropic. Le principe est simple : on définit un outil une fois sous forme de serveur MCP, puis n’importe quel client compatible peut le découvrir et l’appeler. Un client, ici, ça peut être votre assistant local, votre IDE, votre interface de chat ou une app interne.
Ce côté pluggable change pas mal de choses pour les systèmes locaux. On peut brancher des capacités autour du modèle sans lui demander de tout faire lui-même.
- Un serveur MCP peut exposer une fonction pour parcourir un dépôt.
- Un serveur MCP peut chercher du code dans les fichiers.
- Un serveur MCP peut lire un fichier précis.
- Un serveur MCP peut proposer une modification.
- Un serveur MCP peut préparer une pull request, c’est-à-dire une demande de fusion de code.
Comment bâtir un agent infrastructure stack fiable ?
Dans un assistant développeur, le modèle ne va pas manipuler tout le projet directement au hasard. Il demande aux outils ce dont il a besoin. Il peut dire, en gros : “Cherche où cette fonction est utilisée”, puis “Lis ce fichier”, puis “Prépare une modification”. MCP sert à cadrer ces échanges.
Il faut rester lucide. MCP ne rend pas le modèle intelligent par magie. Il ne corrige pas un mauvais raisonnement. Il lui donne surtout une interface propre vers le monde réel. Et pour un assistant IA local, c’est souvent ce qui manque pour passer d’un chatbot sympa à un vrai outil de travail.
Pourquoi choisir Qwen3.6-35B-A3B ?
Qwen3.6-35B-A3B est intéressant pour ce type d’assistant local parce qu’il est conçu pour des tâches agentiques, notamment le raisonnement multi-fichiers et le travail de code. C’est exactement le genre de modèle que je regarde quand je veux un assistant capable de lire un projet, comprendre une erreur, suivre une logique métier et proposer une correction sans perdre le fil au bout de trois fichiers.
Son architecture est assez maligne. Qwen3.6-35B-A3B est un modèle MoE, pour Mixture of Experts. L’idée est simple : au lieu d’utiliser tout le modèle à chaque réponse, il choisit seulement les parties utiles. Il a 35 milliards de paramètres au total, mais environ 3 milliards seulement sont activés par passage. Il s’appuie sur 256 experts par couche, avec un routage qui sélectionne les bons experts selon la tâche. En local, c’est important, parce qu’on garde une grosse capacité sans payer le coût complet à chaque génération.
| Élément | Ce que ça change concrètement |
| MoE 35B avec 3B actifs | Plus de capacité, mais une exécution plus légère qu’un 35B dense classique. |
| 256 experts par couche | Le modèle spécialise certaines parties selon le type de problème. |
| 262 144 tokens de contexte | On peut charger beaucoup plus de code, de logs et de documentation dans la même session. |
La pile interne compte 40 couches, avec une alternance entre Gated DeltaNet et Gated Attention. Dit simplement, Gated DeltaNet aide sur les longs contextes grâce à une forme d’attention linéaire plus efficace. Gated Attention garde une bonne capacité de raisonnement relationnel, utile quand le modèle doit relier une fonction, une classe, une configuration et une erreur qui apparaît ailleurs. C’est souvent ça, le vrai sujet dans un dépôt logiciel.
Le gros point pratique, et clairement le point SEO à retenir, c’est sa fenêtre de contexte native de 262 144 tokens. Ça change la manière de travailler. Je peux donner à l’assistant un morceau beaucoup plus large du dépôt, plusieurs fichiers liés, des logs, un README, parfois même une partie de la doc interne. On évite de tout découper en mini-prompts. On garde le fil d’une erreur. On comprend mieux l’architecture. Chez un client, c’est typiquement ce qui fait la différence entre “il m’a répondu un truc plausible” et “il a vraiment compris le projet”.
Comment l’AIoT transforme les données en valeur ?
Qwen3.6-35B-A3B est aussi entraîné pour des usages agentiques. Agentic Coding vise justement le raisonnement multi-fichiers et les tâches de code en plusieurs étapes. Preserve_thinking aide à conserver une continuité entre les tours via le cache KV, c’est-à-dire la mémoire technique des éléments déjà calculés dans la conversation. Ça ne garantit pas une réponse parfaite, évidemment. Mais pour un assistant local qui travaille dans la durée, ça aide vraiment à ne pas repartir de zéro à chaque message.
Quel matériel faut-il prévoir ?
Il faut idéalement un GPU solide, mais on peut adapter le déploiement selon le niveau de performance attendu et le budget matériel. C’est vraiment le point à clarifier dès le départ, parce qu’un assistant IA local peut vite passer de “ça marche” à “c’est inutilisable au quotidien” si la machine ne suit pas.
L’option que je recommande, si vous voulez faire tourner Qwen3.6-35B-A3B sérieusement, c’est l’exécution GPU. En bfloat16, c’est-à-dire avec une précision numérique assez confortable pour garder une bonne qualité de génération, le modèle demande environ 70 GB de VRAM. Une A100 80 GB permet de viser ce mode complet, avec une marge correcte.
Si le budget ou le matériel est plus limité, la quantification Q4 devient intéressante. La quantification réduit la précision des poids du modèle pour consommer moins de mémoire. On descend alors autour de 20 à 24 GB de VRAM, ce qui rend l’usage envisageable sur une RTX 4090 24 GB. J’ai déjà vu ce compromis chez des clients qui voulaient surtout un assistant interne réactif, sans louer une grosse machine cloud en continu. Deux RTX 3090 peuvent aussi être utilisées avec du parallélisme tensoriel, c’est-à-dire en répartissant certaines opérations du modèle entre plusieurs GPU.
Il y a aussi l’option CPU ou hybride avec KTransformers. Une partie du travail peut être répartie entre GPU et CPU. Avec environ 64 GB de RAM, c’est utilisable, mais il faut être lucide. On parle plutôt de 30 à 120 secondes de latence par tour. Ça peut suffire pour tester, valider une démo, comprendre le comportement du modèle. Ce n’est pas le confort d’un vrai assistant développeur qu’on utilise toute la journée.
Pour apprendre et valider l’architecture MCP, je partirais parfois sur plus petit. Un Qwen2.5-7B via Ollama, par exemple. L’objectif n’est pas d’avoir les mêmes performances, mais de tester les serveurs MCP, le flux d’outils, les appels locaux, les permissions, et toute la mécanique autour du modèle.
| Usage | Configuration | Avantage | Limite |
| Bfloat16 GPU | A100 80 GB, environ 70 GB de VRAM | Meilleure qualité et confort d’exécution | Matériel cher et moins accessible |
| Quantification Q4 | RTX 4090 24 GB, environ 20 à 24 GB de VRAM | Bon compromis coût, mémoire et performance | Qualité légèrement dégradée selon les cas |
| Hybride KTransformers | GPU plus CPU, environ 64 GB de RAM | Permet de tester sans très gros GPU | Latence élevée, 30 à 120 secondes par tour |
| Petit modèle de test | Qwen2.5-7B via Ollama | Idéal pour valider MCP et le flux d’outils | Performances très inférieures au grand modèle |
Comment assembler l’assistant local ?
L’assistant local se construit en reliant un modèle Qwen exécuté localement à des serveurs MCP qui exposent les outils utiles au travail de développement.
Dans les faits, le flux est assez simple. Vous posez une demande, par exemple “corrige ce bug dans l’authentification”. Le modèle Qwen reçoit la demande, raisonne dessus, puis comprend qu’il lui manque du contexte. Il ne peut pas deviner votre code. Il doit aller lire le dépôt.
C’est là que MCP entre en jeu. MCP, pour Model Context Protocol, sert de couche standard entre le modèle et les outils. Au lieu de brancher Qwen directement à Git, à votre système de fichiers, à votre outil de ticketing ou à GitHub, on passe par des serveurs MCP. Chaque serveur expose des capacités propres, comme lire un fichier, chercher une fonction, lister les branches, ou préparer une pull request.
Le déroulé ressemble souvent à ça. Le modèle identifie les fichiers à inspecter, appelle un outil MCP pour explorer le dépôt, lit les fichiers pertinents, recherche le code concerné, propose un correctif, puis prépare une action si l’environnement l’autorise. Une modification locale. Un patch. Une pull request. Ou juste une explication claire si vous préférez garder la main.
La séparation des rôles est vraiment le point clé.
- Le modèle raisonne. Il comprend la demande, formule une hypothèse, choisit les actions utiles.
- MCP standardise les appels d’outils. Il évite de coller votre assistant à une API spécifique.
- Les serveurs MCP exécutent les actions concrètes. Ils lisent, cherchent, écrivent, ouvrent une PR, selon les droits donnés.
J’ai souvent vu chez des clients des automatisations IA trop couplées à un seul outil. Ça marche très bien pendant trois semaines, puis une API change, un token expire, un format de réponse bouge, et tout casse. Ici, l’idée est de réduire ce risque. Le modèle reste interchangeable. Les outils aussi. Le contrat entre les deux est plus propre.
Il faut quand même poser des garde-fous dès le départ. Je ne laisserais jamais un assistant local écrire partout sans contrôle.
- Limiter les droits des outils MCP. Lecture seule au début, puis écriture sur des dossiers précis.
- Journaliser les actions. Il faut savoir quel outil a été appelé, quand, et avec quels paramètres.
- Demander une validation humaine. Surtout avant une écriture, un commit ou une pull request.
- Tester sur des dépôts non critiques. Ça évite les mauvaises surprises.
- Surveiller les temps de réponse. Un modèle local dépend beaucoup du CPU, du GPU et de la RAM disponibles.
L’objectif n’est pas de remplacer un développeur. L’objectif est d’avoir un copilote local capable d’aller chercher le bon contexte, de préparer le travail plus vite, et de limiter la dépendance à un modèle cloud pour chaque interaction.
Alors, est-ce que ça vaut le coup de monter tout ça ?
Pour moi, l’intérêt est clair si vous voulez garder la main sur votre stack IA. MCP règle le problème de connexion aux outils avec une approche standard. Qwen3.6-35B-A3B apporte une base locale sérieuse pour le code, les longs contextes et les tâches agentiques. Le point dur reste le matériel : en GPU, c’est confortable mais exigeant, en hybride c’est possible mais plus lent. Le bon réflexe, c’est de tester l’architecture avec un modèle plus petit, puis de monter en puissance. Le bénéfice pour vous : un assistant développeur plus contrôlable, plus intégré à vos outils, et moins dépendant du cloud.
FAQ
- MCP sert à quoi dans un assistant IA local ?
MCP sert à donner au modèle une façon standard d’appeler des outils. Au lieu de créer une intégration différente pour chaque API ou chaque modèle, on expose les fonctions utiles via des serveurs MCP. Le modèle peut ensuite découvrir et utiliser ces outils depuis un client compatible. - Qwen3.6-35B-A3B peut-il tourner sans cloud ?
Oui, l’intérêt est justement de pouvoir l’exécuter localement, si le matériel suit. En bfloat16, il faut environ 70 GB de VRAM. En quantification Q4, on descend autour de 20 à 24 GB, ce qui rend l’usage possible sur une RTX 4090 24 GB, avec des compromis. - Pourquoi le long contexte est important pour le code ?
Parce qu’un vrai problème de code dépasse rarement un seul fichier. Avec une fenêtre native de 262 144 tokens, Qwen3.6-35B-A3B peut garder beaucoup plus de contexte : fichiers liés, architecture, dépendances, erreurs, conventions. Ça aide l’assistant à proposer des corrections moins isolées. - Peut-on tester MCP avec un modèle plus petit ?
Oui, et c’est souvent le plus malin pour commencer. Un modèle plus léger comme Qwen2.5-7B via Ollama permet de valider le pattern MCP, les outils, les permissions et les flux de travail. Vous ne testez pas la performance maximale, vous testez l’architecture. - Un assistant IA local peut-il créer des pull requests ?
Il peut préparer les modifications et déclencher une action de pull request si un outil MCP expose cette capacité et si les droits sont configurés. Je recommande quand même une validation humaine avant écriture ou soumission. C’est plus sain, surtout sur des dépôts importants.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les process métier et le SEO/GEO. J’ai travaillé avec des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez construire un système IA utile, connecté à vos outils et pas juste une démo sympa, vous pouvez me contacter.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.