MCP-first — pourquoi mon agent IA ne devine plus rien

L'un des moments où j'ai senti que ma façon de coder avec un agent IA avait basculé, c'est le jour où j'ai arrêté de corriger les fonctions inventées. Pas progressivement. D'un coup. La règle qui a permis ça tient en cinq mots : MCP first, ne jamais inventer. Cet article décrit ce qu'est MCP, pourquoi cette règle change tout, et comment elle s'applique au quotidien.

C'est probablement l'article le plus important de ce blog pour qui essaie de mettre un agent en production sur sa propre stack.

Le problème

Tout assistant LLM, aussi bon soit-il, est entraîné sur un corpus du passé. Il connaît des patterns, des bibliothèques, des conventions. Bien sûr, quand tu travailles dans VS Code avec un agent, il a accès à ton code — n'importe quel développeur te le dira, l'agent est dedans, il peut le lire. Le vrai problème est ailleurs : la lecture coûte cher. Il ne va pas faire un Ctrl-F sur chaque fichier pour vérifier le nom exact d'une méthode avant de l'utiliser ; il va, par défaut, deviner à partir du contexte qu'il a déjà en tête. Quand tu lui demandes d'écrire une fonction qui appelle services.cache.get(key), il va peut-être inventer un objet cache avec une méthode get, alors que ta vraie API est cache.fetch_or_compute(key). Le code compile, les tests passent éventuellement, et la divergence ne se révèle qu'à l'exécution.

J'ai vécu ce cycle pendant des mois. Le LLM proposait, je corrigeais, je précisais, je donnais plus de contexte au prompt, et on recommençait. Le ratio de phrases utiles diminuait au fil de la session parce que je passais mon temps à expliquer ce que mon code faisait en réalité.

C'est exactement le problème que MCP vient résoudre.

Ce qu'est MCP

MCP — Model Context Protocol — est un protocole standard initialement publié par Anthropic en 2024, qui permet à un agent LLM d'appeler des outils et de lire des ressources via un mécanisme uniforme. Pas un format propriétaire à un éditeur. Un standard ouvert, implémentable par n'importe qui.

Un serveur MCP expose deux choses :

Des tools : des fonctions appelables avec des paramètres typés, qui retournent une réponse structurée. Exemple : search(query, org_slug, limit) qui interroge une base de connaissances.
Des resources : des documents adressables par URI, dont le contenu peut être chargé à la demande.

Un client MCP (typiquement, le runtime d'un agent IA : Claude Desktop, Cursor, VS Code Copilot, etc.) découvre les tools disponibles auprès du serveur, les présente au LLM dans son contexte, et exécute les appels demandés par le modèle.

Du point de vue de l'agent, c'est une function calling généralisée. Du point de vue de l'humain qui configure, c'est un point d'entrée unique pour exposer son environnement à l'agent.

Le pattern MCP-first

Dans mon écosystème, le point d'entrée MCP de l'agent expose deux choses indissociables : la knowledge sémantique (règles, ADR, glossaire, prompts) et l'arbre technique hub-tree (la cartographie des projets et de leurs briques). Les deux sont nécessaires : la première dit ce qui est vrai par convention, le second dit ce qui existe par construction. Un agent a besoin des deux pour ne plus deviner.

Avant/après MCP : un LLM qui devine sans contexte versus un LLM qui interroge la knowledge sémantique et l'arbre technique avant de générer — Avant : le LLM invente. Après : il interroge MCP avant de générer. La règle « ne jamais inventer » ne tient debout que parce qu'il existe un endroit où chercher.

Au départ, tout vivait dans un seul serveur — semantic-hub, qui embarquait à la fois la knowledge et hub-tree. Plus tard, j'en ai extrait hub-tree comme service à part, et j'ai ajouté MCP-Unified par-dessus : une gateway qui agrège plusieurs sources MCP en un seul endpoint pour l'agent. L'architecture s'est étoffée au fil des besoins, mais le principe est le même qu'au premier jour : un point d'entrée unique côté agent, deux registres complémentaires côté serveur.

Chaque projet a un fichier .github/copilot-instructions.md qui contient cinq lignes en tête :

## Invariants
- Français. Sûr (tests/health-check). Refactor OK si justifié + validé.
- MCP semantic-hub = source de vérité. NE JAMAIS INVENTER.
- Économique de tokens (contexte sémantique à la demande).

Ce sont les lignes que l'agent lit en premier à chaque session. La règle est explicite, en majuscules pour l'emphase : « NE JAMAIS INVENTER ». Et elle est précédée de « MCP semantic-hub = source de vérité » qui dit clairement où aller chercher avant — l'ordre n'est pas neutre : on indique d'abord la source, puis on interdit l'invention. La règle ne se tient debout que parce qu'il existe un endroit où chercher.

Quand l'agent a besoin de savoir si une fonction cache.fetch_or_compute(key) existe, il appelle search("cache fetch_or_compute", org_slug). Si la fonction existe dans la knowledge, il la trouve. Si elle n'existe pas, le résultat est vide — et la règle dit : ne pas inventer.

L'effet concret

Le changement n'a pas été cosmétique. Trois choses ont changé immédiatement.

Le ratio de code corrigeable est tombé. Avant, je relisais chaque snippet avec la grille « est-ce que ces appels existent ? est-ce que ces noms sont bons ? ». Maintenant, l'agent appelle MCP avant de proposer du code. Si la knowledge dit que la méthode s'appelle fetch_or_compute, c'est fetch_or_compute qui apparaît. Le rework lié à l'invention a quasi disparu.

Le coût de l'onboarding d'un nouveau projet a baissé. Pour qu'un projet bénéficie de MCP-first, il suffit d'ajouter org_slug dans son copilot-instructions.md et de pousser au moins un document docs/README.md dans la knowledge. À partir de là, l'agent sait où chercher. Pas besoin de re-expliquer le projet à chaque session — la session précédente n'avait elle-même pas besoin.

Les règles sont devenues exécutables. Quand on écrit dans la knowledge « invariant : tout secret passe par env vars, jamais dans le code », l'agent applique cette règle à ce qu'il écrit. Pas parce qu'on l'a redit dans le prompt, mais parce que MCP a remonté la règle au moment où l'agent a généré le code. La knowledge devient une contrainte vivante.

La discipline qui rend ça vivable

Le pattern marche uniquement si la knowledge est entretenue. C'est la contrepartie de la magie.

Trois pratiques que j'ai stabilisées au fil des mois.

Un document par décision. Chaque ADR (Architecture Decision Record) vit comme un fichier docs/adr/000X-xxx.md dans le repo knowledge. Une décision = un PR = une revue. Le titre dit ce qui est décidé, le corps explique pourquoi. L'agent peut chercher « pourquoi pas Postgres pour ledger » et tomber sur la réponse.

Un glossaire qui évolue. Les concepts métiers — « hub-projects », « pilier », « org_slug » — sont définis une fois dans docs/glossary.md. Quand un nouveau terme apparaît dans le code, il est ajouté au glossaire avant d'être utilisé dans une autre partie du système.

Les conventions sont écrites. Le format des commits, la structure des chart Helm, le nommage des branches — tout est dans docs/conventions/. L'agent les applique automatiquement parce qu'il les lit avant de générer.

Ces trois pratiques coûtent du temps. Mais ce temps est ré-investissable : ce que j'écris une fois dans la knowledge, je ne le re-explique plus à chaque session.

Le revers — quand MCP ne suffit pas

MCP-first n'est pas une baguette magique. Il y a des cas où ça ne suffit pas et où l'agent doit quand même se débrouiller.

Les bibliothèques externes. Si j'utilise FastAPI ou Helm, la documentation officielle n'est pas dans ma knowledge. L'agent doit se reposer sur ce qu'il sait de ces librairies. Pour les cas tordus, je copie-colle des extraits de doc dans le prompt — mais c'est rare parce que les libs principales sont stables.

Les patterns nouveaux. Quand j'invente un nouveau pattern qui n'est pas encore documenté, l'agent n'a pas de référence à chercher. Solution : je lui dis explicitement « écris d'abord la doc dans docs/..., ensuite implémente ». Comme ça la prochaine session aura la référence.

Les choix de design ouverts. MCP donne des contraintes, pas des inspirations. Pour les choix de design (« comment structurer cette nouvelle feature ? »), l'agent doit raisonner sans support — et c'est là qu'il est le moins fiable. Je garde la décision pour moi sur ces cas-là.

Pourquoi peu de gens font ça

Le pattern MCP-first demande un investissement initial qui rebute. Il faut :

Avoir une knowledge structurée (ADR, glossaire, conventions). La plupart des projets n'en ont pas.
Avoir un serveur MCP qui expose cette knowledge. Ça implique de connaître MCP, d'en déployer un, de le maintenir.
Avoir un agent qui supporte MCP et qui est configuré pour s'en servir. Cursor, Claude Desktop, VS Code Copilot le font, mais ça demande une configuration explicite.

À l'addition, ça représente quelques jours de travail avant le premier bénéfice. Beaucoup de gens préfèrent rester au pattern « prompt précis à chaque session », qui marche immédiatement mais ne capitalise jamais.

Il y a aussi une raison plus sourde, qui se dit moins : la peur du coût en tokens. Beaucoup pensent qu'ajouter du contexte va exploser la facture, parce qu'ils ont l'habitude de balancer du code brut dans le prompt — toujours plus, toujours au cas où.

Avec MCP-first, c'est l'inverse qui se passe. Le contexte n'est pas dumpé, il est interrogé à la demande, sémantiquement. C'est l'agent lui-même qui décide ce qu'il va chercher et combien il va prendre. Rien de superflu : ce qui remonte est précisément ce qui sert au prompt courant — la règle « économique de tokens » dans le copilot-instructions.md le rappelle.

Sur la durée, ce pattern coûte moins cher que de laisser l'agent scanner ses propres fichiers à chaque session. La comparaison entre les agents — Copilot, Claude Code, Cursor — mériterait son article à part, et viendra dans un prochain.

Mon point, c'est que pour un écosystème de dizaines de services entretenus par une seule personne, le pattern MCP-first n'est pas un luxe. C'est ce qui rend la maintenance soutenable. Sans lui, je passerais l'essentiel de mes sessions à réexpliquer mon propre code à mon assistant.

Aller plus loin

Si tu veux tester le pattern, je conseille trois étapes.

Commencer par écrire la knowledge minimale d'un seul projet : un README.md qui contient la vision en cinq paragraphes, un architecture.md avec un schéma, un conventions.md qui dit comment commit. Pas besoin de serveur MCP encore — l'agent peut déjà s'en servir si tu pointes ces fichiers dans son contexte.

Ensuite, déployer un serveur MCP simple comme mcp-filesystem ou mcp-git qui exposent juste ton repo. L'agent peut maintenant lire à la demande sans que tu lui balances tout le repo dans le prompt.

Enfin, passer à un serveur MCP métier comme semantic-hub si tu veux indexer plusieurs projets ensemble. C'est l'étape qui demande l'investissement le plus lourd, mais c'est celle qui débloque le pattern à l'échelle.

À chaque marche, le ratio de réponses inventées baisse.

Voir aussi