Les agents IA sont puissants. Et coincés dehors.
Un agent comme ZCode ou Claude sait raisonner, écrire, planifier. Mais dès qu'il s'agit de vos données métier, il n'a que deux options : copier-coller ce que vous lui montrez, ou passer par des intégrations bricolées une à une. Chaque client IA a son dialecte, chaque application ses endpoints — le coût d'intégration tue la plupart des cas d'usage avant qu'ils ne naissent.
Le Model Context Protocol (MCP) répond exactement à ça : un protocole ouvert qui standardise la façon dont un client IA découvre et appelle les capacités d'une application. Une fois votre serveur MCP écrit, tous les clients compatibles peuvent l'utiliser — sans travail d'intégration supplémentaire. L'analogie habituelle est juste : MCP, c'est l'USB-C des outils IA.
MCP en deux minutes
Le protocole est un client-serveur simple :
- Votre application expose des tools (actions avec entrées/sorties typées) via un endpoint JSON-RPC.
- Un client MCP (ZCode, Claude, VS Code, n'importe quel agent qui parle le protocole) découvre la liste des outils et les appelle en cours de conversation.
- L'authentification, les permissions et la validation restent chez vous — le protocole transporte des requêtes, pas des décisions de sécurité.
Le point clé : le client ne code rien de spécifique à votre application. Il découvre create-lead, list-leads, create-project au runtime, avec leurs schémas, et les utilise comme n'importe quelle capacité native.
Ce que j'ai exposé — et pourquoi
Mon portfolio est aussi un outil de gestion : CRM, catalogue de services, gestion de projets, contenus. Plutôt que de refaire chaque intégration à la main, j'ai exposé les opérations qui ont du sens pour un agent :
- CRM : créer et qualifier un lead, gérer le catalogue de services, préparer des devis.
- Projets : créer un projet (avec sa roadmap générée), construire le modèle de données entité par entité (ERD), documenter des routes API, rédiger des règles de gestion, publier des artefacts.
- Tâches : manipuler le kanban (créer, prioriser, assigner, ordonner).
Un exemple de flux réel : je demande à mon agent « crée la cas d'étude EventFlow sur momoledev : entités, routes API documentées, règles de gestion ». L'agent va chercher le gabarit obligatoire du type d'artefact (get-artifact-template), crée le projet, ajoute les entités et les champs de l'ERD un à un, documente les routes avec leurs schémas de requête/réponse, rédige les règles de gestion numérotées — et je relis le tout dans l'admin avant publication. Ce qui prenait une soirée de copier-coller devient une conversation supervisée.
Autre flux, plus court : un échange WhatsApp avec un prospect → « crée le lead X, budget 1-5M FCFA, besoin site vitrine, relance dans 3 jours » → le lead existe, dans le pipeline, avec sa relance programmée.
L'architecture côté serveur
Côté implémentation, quelques choix qui payent :
- Un fichier par outil, zod partout. Chaque outil déclare son entrée et sa sortie avec les mêmes schémas zod que l'API REST — la documentation OpenAPI est dérivée des mêmes sources. Pas de divergence entre ce que l'agent voit et ce que l'API valide.
- JSON-RPC + Bearer token. L'endpoint MCP est protégé comme n'importe quelle API : un token, des scopes.
- Des scopes granulaires.
leads:read,leads:write,projects:write,analytics:read... Chaque token porte le minimum de permissions dont il a besoin. Un token de lecture analytics n'a rien à faire près du CRM. - Les écritures ne sont pas des citoyens silencieux. Chaque mutation passe la validation zod, est journalisée (qui, quoi, quand, avec quel acteur) et resynchronise l'index de recherche. Un agent qui écrit laisse la même trace qu'un admin.
Les garde-fous qui font la différence
MCP abaisse la barrière technique pour brancher des agents ; il n'abaisse pas la barrière de sécurité. Trois règles que je ne saute jamais :
- Un outil MCP est une porte permanente. Ne l'exposez que si vous l'assumeriez comme endpoint REST public pour qui détient le token. C'est exactement le même risque, avec un client différent.
- Les erreurs doivent éduquer l'agent. Une validation zod qui répond « champ budget : valeur invalide » (422, erreur champ par champ) permet à l'agent de se corriger seul au tour suivant. Une erreur opaque provoque des tentatives en boucle.
- Les gabarits d'abord, la création ensuite. Pour les contenus structurés (cas d'étude, cahier des charges), l'outil de création exige que le gabarit ait été récupéré avant. La qualité de sortie reste constante, quel que soit l'agent qui écrit.
Brancher un client, concrètement
Côté client, la configuration tient en quelques lignes (exemple VS Code / ZCode) :
{
"servers": {
"momoledev": {
"type": "http",
"url": "https://votre-app.com/mcp",
"headers": { "Authorization": "Bearer <token>" }
}
}
}À partir de là, « liste mes leads à relancer aujourd'hui » fonctionne depuis l'éditeur. Le token porte les scopes ; l'application valide ; le journal trace.
Quand ne PAS le faire
Le MCP n'est pas une fin en soi :
- Données déjà publiques : si votre API REST suffit, un outil MCP duplique la surface sans valeur ajoutée.
- Outils à fort impact sans validation humaine : paiement, suppression en masse, envoi d'emails clients — à réserver aux flux internes, ou à derrières une file d'approbation comme dans mon assistant.
- Multi-tenant sans isolation stricte : un outil MCP lit ce que le token lui permet de lire. Si l'isolation par tenant n'est pas hermétique, ne branchez pas le protocole.
En résumé
MCP transforme votre application d'une simple destination en participant de l'écosystème des agents. Commencez petit : trois outils de lecture, un outil d'écriture journalisé, un token à scopes étroits. Vous mesurerez vite si vos agents gagnent du temps — et vous aurez construit l'infrastructure pour la suite.