Mon IA ne pouvait pas voir mes fichiers

Mon IA ne voyait pas mes fichiers — J'ai construit un serveur MCP sans dépendance

Mon IA ne voyait pas mes fichiers — J'ai construit un serveur MCP sans dépendance

Pendant des mois, mon grand modèle de langage local ressemblait à un collègue brillant enfermé dans une chambre insonorisée. J'avais une instance rapide basée sur Mistral fonctionnant via Ollama sur ma station de travail, et une collection croissante de scripts et de notebooks éparpillés dans mon répertoire personnel. Le modèle pouvait raisonner, écrire du code et déboguer des extraits que je collais dans la fenêtre de chat, mais il n'avait aucune idée de ce qui se trouvait à deux répertoires de là. Si je voulais qu'il examine un fichier de configuration, résume les logs de la veille ou vérifie si une fonction était déjà implémentée dans un autre module, je devais copier, coller et espérer que la fenêtre de contexte ne déborde pas. La friction était subtile au début, puis exaspérante. Je faisais tourner l'IA localement pour garder mes données privées et mes flux de travail rapides, et pourtant je jouais encore le rôle de pont manuel copier-coller entre mon système de fichiers et mon modèle.

J'avais besoin de quelque chose qui puisse s'interposer entre mon disque et mon LLM : un traducteur léger qui parlerait à la fois le langage du système de fichiers et celui de l'IA. Le Model Context Protocol (MCP) gagnait en popularité comme moyen d'exposer des outils et des ressources aux assistants de manière standardisée, mais la plupart des implémentations de référence que j'ai trouvées reposait sur de lourdes chaînes de dépendances — des serveurs Node.js avec des centaines de paquets npm, ou des environnements Python qui exigeaient Conda juste pour lire un fichier texte. Cela me semblait contraire à la philosophie local-first et de confiance minimale qui m'avait attiré vers Ollama et les modèles à poids ouverts en premier lieu. J'ai donc décidé de construire mon propre serveur MCP à partir de zéro, sans aucune dépendance externe, et d'apprendre à mon IA à voir.

L'angle mort des LLM locaux

Faire tourner des modèles localement résout deux gros problèmes : la confidentialité et la latence. Quand vos poids résident sur votre propre GPU et que vos prompts ne quittent jamais la machine, vous éliminez les allers-retours réseau et les préoccupations de gouvernance des données tierces. Les communautés autour des modèles ouverts, notamment celles publiant sur Hugging Face et optimisant les piles d'inférence locale, ont rendu trivial de télécharger un modèle Mistral, Llama ou Qwen et de commencer à discuter. Ollama, en particulier, a transformé l'inférence locale en une expérience à une seule commande. Le modèle est là, désireux d'aider, et totalement ignorant du monde extérieur à sa frontière de processus.

Le problème est architectural. Un processus LLM local lit depuis l'entrée standard ou une charge utile API, calcule une réponse, et écrit vers la sortie standard. Il ne parcourt pas les répertoires, n'ouvre pas de tableurs, ni ne suit les logs à moins que l'application hôte n'alimente explicitement ces données dans le prompt. Cette conception est une fonctionnalité pour la sécurité — elle empêche un modèle de supprimer accidentellement vos fichiers — mais elle devient un bug pour la productivité. Vous vous retrouvez avec un moteur de raisonnement puissant qui n'a aucune mémoire persistante de votre projet et aucun organe sensoriel pour votre environnement. Vous êtes le capteur. Chaque lecture de fichier, chaque listing de répertoire, chaque opération grep doit être effectuée par vous, distillée en un prompt, et compressée à travers une fenêtre de contexte qui, bien que croissante, reste finie.

Je voulais que le modèle puisse demander des informations à la demande. Si je demandais « Pourquoi le build a-t-il échoué ? », l'IA devrait pouvoir consulter le Makefile, vérifier le fichier d'environnement et scanner le log d'erreur elle-même. Cela nécessite un protocole.

Entre en scène le Model Context Protocol

Le Model Context Protocol est une norme ouverte conçue pour connecter les assistants IA aux systèmes externes de manière structurée et sécurisée. Plutôt que de fourrer une base de code entière dans un prompt et d'espérer le meilleur, MCP permet à un assistant d'appeler des outils, lire des ressources, et récupérer uniquement les données dont il a besoin, exactement quand il en a besoin. Il transforme un chat statique en une boucle d'agent interactive : l'utilisateur pose une question, le modèle raisonne sur les informations manquantes, le client exécute un appel d'outil, et le modèle intègre le résultat dans sa réponse finale.

Conceptuellement, MCP se situe au même niveau que les anciennes architectures de plugins, mais il est plus granulaire et standardisé. Un serveur expose des capacités — peut-être un lecteur de fichiers, une interface de requête de base de données, ou une calculatrice — et le client annonce ces capacités au modèle. Le modèle lui-même ne parle pas HTTP ou JSON-RPC ; il émet des requêtes en langage naturel que le client mappe vers des messages de protocole. Cette séparation des préoccupations signifie que le modèle reste portable tandis que la couche d'intégration reste explicite.

Pour une configuration locale, le transport le plus simple est l'entrée standard et la sortie standard. Un serveur MCP lancé par le client devient un sous-processus de longue durée. Le client écrit des messages JSON-RPC vers le stdin du serveur et lit les réponses depuis son stdout. Il n'y a pas de ports ouverts, pas de certificats TLS à gérer, et pas de règles de pare-feu à manipuler. C'est un ajustement élégant pour une machine où le modèle, le client et les données vivent tous sur la même boîte.

Pourquoi l'absence de dépendance compte

Quand j'ai commencé à rechercher les serveurs MCP existants, j'ai été frappé par la rapidité avec laquelle un « simple » lecteur de fichiers gonflait en une chaîne d'approvisionnement logicielle complète. Un serveur typique pouvait exiger une version spécifique de Node.js, une douzaine de paquets npm pour l'analyse d'arguments et la journalisation, et des dépendances transitives se comptant en centaines. Un équivalent Python tirait souvent FastAPI, Pydantic et un framework web juste pour exposer une seule fonction. Ces piles conviennent bien aux SaaS de production, mais elles me semblaient lourdes pour un utilitaire dont le seul travail était de lire des fichiers sur mon propre ordinateur portable.

L'absence de dépendance n'est pas du minimalisme pour le minimalisme ; c'est une stratégie de sécurité et de maintenance. Chaque paquet externe est un point potentiel de rupture ou de compromission. Une disparition de style left-pad, un compte de mainteneur compromis, ou une dépendance dormante avec une CVE fraîche peut rendre un outil inutilisable — ou pire, dangereux. Quand vous construisez un pont entre un agent IA et vos fichiers personnels, vous devriez pouvoir auditer l'intégralité du pont en lisant un seul fichier de code source.

En écrivant le serveur dans un langage système avec une bibliothèque standard robuste — pensez Go, Rust, ou Zig — je pouvais compiler un binaire statique unique. Ce binaire n'a pas d'interpréteur d'exécution à installer, pas de gestionnaire de paquets à invoquer, et pas d'environnement virtuel à activer. Je peux le copier sur la machine d'un collègue, le déposer sur un exécuteur CI, ou le stocker dans un dépôt git et m'attendre à ce qu'il se comporte de manière identique. Cette portabilité s'aligne parfaitement avec l'éthos des outils d'IA locale défendue par les communautés autour d'Ollama et des poids de modèles ouverts. Si le modèle est autonome, l'outil qui l'alimente devrait l'être aussi.

Architecture d'un serveur MCP pour système de fichiers

J'ai opté pour une conception avec trois parties mobiles : la couche de transport, le registre d'outils, et le bac à sable du système de fichiers. Le transport parle JSON-RPC 2.0 sur stdio. Au démarrage, le serveur imprime une poignée de main d'initialisation, puis entre dans une boucle lisant une ligne à la fois depuis stdin.