MCP en production : ce que les docs ne disent pas

MCP, c'est l'acronyme qui a saturé tous les feeds dev ces six derniers mois. Et comme souvent avec les standards qui explosent vite, la documentation est propre, les tutos sont optimistes, et la production est une autre affaire.

On a commencé à câbler des serveurs MCP chez Annei fin 2024. Aujourd'hui, une dizaine tournent en production sur des workflows clients réels. Ce qu'on a appris, personne ne le met dans les guides officiels.

Ce que MCP change vraiment

Avant MCP, connecter un agent IA à un outil externe, c'était du spaghetti : un wrapper custom par outil, chaque client gérait ses intégrations différemment, zéro portabilité. Un agent Claude n'utilisait pas les mêmes intégrations qu'un assistant dans Cursor.

MCP résout ça avec un protocole unique. L'agent joue le rôle de client, les outils deviennent des serveurs, et tout le monde parle le même langage. En théorie, tu branches une fois, ça marche partout.

L'écosystème a explosé : 10 000+ serveurs MCP actifs début 2026, 97 millions de téléchargements SDK par mois. Pour chaque outil qu'on utilise en agence (GitHub, Slack, PostgreSQL, Stripe, Notion), il existe un serveur open-source. C'est réel et utile. Mais cette croissance rapide a aussi produit une quantité de code fragile en circulation.

Ce que tu vas vraiment rencontrer en prod

La sécurité, c'est une bombe à retardement si tu ne l'adresses pas dès le départ

53% des serveurs MCP déployés utilisent des secrets statiques. Une API key dans un .env, stockée dans un pipeline CI/CD ou committée par accident. C'est la situation par défaut, et c'est un risque concret.

En juin 2025, Asana a déployé une intégration MCP. Bug : un client pouvait accéder aux données d'un autre. Cause : infrastructure partagée sans isolation des tokens par tenant. Patch d'urgence, incident public.

492 serveurs MCP sont aujourd'hui exposés publiquement sans authentification ni chiffrement. Certains ouvrent un accès direct à des APIs internes ou des bases propriétaires.

La CVE-2025-49596 sur le MCP Inspector, l'outil de debug officiel d'Anthropic, illustre le problème : le serveur écoutait sur 0.0.0.0 sans auth, sans protection CSRF. Un site malveillant suffisait pour déclencher une exécution de code à distance sur la machine de l'utilisateur. Corrigé depuis la version 0.14.1, mais ça montre que même les implémentations de référence peuvent rater ce point.

L'injection de prompt via les données

L'implémentation SQLite du serveur MCP de référence concaténait des requêtes SQL sans les nettoyer. L'agent traitait les données retournées comme des instructions. Résultat : un attaquant peut écrire une instruction dans une base que l'agent lit, l'agent la suit.

Cette version a été forkée plus de 5 000 fois avant d'être archivée. Ce code tourne probablement encore quelque part en production.

C'est le risque qu'on sous-estime le plus quand on construit des agents IA sur mesure : les agents traitent les données internes comme fiables. Dès qu'une entrée externe peut y atterrir, cette hypothèse s'effondre.

La scalabilité horizontale n'est pas native

MCP repose sur des sessions stateful. Chaque connexion maintient un état sur le serveur. Quand tu veux passer à plusieurs instances, le problème est classique : comment mapper un session ID client au bon flux sur le bon serveur ?

Le SDK ne résout pas ça. Tu dois builder une couche dédiée (Redis, sticky sessions, architecture event-driven) ou attendre que le protocole évolue. La roadmap 2026 en fait une priorité. En attendant, c'est à toi d'y penser avant d'être sous charge.

Les descriptions d'outils, c'est un contrat

Un déploiement documenté avec 87 outils connectés a mesuré 40% d'appels erronés sur les outils avec des descriptions vagues. L'agent appelle le mauvais outil, interprète mal ce qu'il fait, produit des résultats faux. Ce n'est pas un bug LLM, c'est un bug de spécification.

Les descriptions d'outils MCP se comportent exactement comme une documentation d'API : floue, c'est un client qui se plante.

Ce qu'on applique maintenant

Quelques règles qu'on a installées chez Annei après avoir tâtonné sur nos premiers workflows d'automatisation en production :

OAuth 2.1, pas de secrets statiques. Si un serveur MCP ne supporte pas OAuth 2.1 avec validation de l'audience du token, c'est une dette technique qu'on documente et qu'on traite. Pas une exception acceptée.

Localhost par défaut, toujours. Aucun serveur MCP exposé sur 0.0.0.0 sans authentification forcée. Le debug reste en local.

Isolation par tenant. Si plusieurs clients partagent un serveur, les tokens sont strictement cloisonnés. Pas de pool partagé, pas d'exception pour gagner du temps.

Validation avant qu'une donnée atteigne l'agent. Les données issues de sources externes (formulaires, bases, APIs tierces) sont traitées comme non fiables, même quand l'agent les lit depuis un outil interne. La chaîne de confiance doit être explicite.

Approbation humaine sur les actions sensibles. Suppression, envoi d'email, dépense. L'agent propose, un humain valide. On applique cette règle sur tous nos workflows automatisés où une erreur coûte cher.

Descriptions d'outils rédigées comme des contrats. Format : verbe + ressource + contraintes clés. Testées avec des prompts ambigus avant de passer en production.

Logging exhaustif. Chaque appel outil : timestamp, nom, paramètres, résultat, identifiant session. Si tu n'as pas les logs, tu ne peux pas diagnostiquer. Et dans les environnements IA complexes, tu ne peux pas non plus faire confiance à ta mémoire de ce qui s'est passé.

Questions fréquentes

MCP est-il stable en production ?

Le protocole lui-même est stable. L'écosystème des serveurs open-source l'est moins. Avant d'adopter un serveur, on vérifie : date du dernier commit, nombre de mainteneurs actifs, issues ouvertes sans réponse. Comme pour toute dépendance critique.

Serveur MCP open-source ou fait maison ?

Si le serveur couvre 80%+ du besoin et est activement maintenu, on le prend. Si on doit le forker pour la moitié des fonctionnalités, mieux vaut partir d'un wrapper propre dès le départ. On a appris à faire cette évaluation avant de s'engager, pas après six semaines de travail perdu.

MCP vaut-il le coup si on n'a qu'un seul outil à connecter ?

Non. MCP a du sens à partir de plusieurs outils, surtout si différents agents doivent les partager. Pour un seul outil, un wrapper direct reste plus simple et plus lisible.

Comment gérer les mises à jour du protocole sans casser la prod ?

Le versioning MCP suit semver. On pin les versions, on teste en staging avant de migrer, et on surveille le changelog Anthropic. La stabilité du protocole de base est un point fort de MCP, les breaking changes sur les fondamentaux sont rares.

MCP est une brique solide. Mais comme toute brique, c'est la façon dont tu construis autour qui détermine si ça tient. Les problèmes qu'on a rencontrés ne sont pas des problèmes MCP, ce sont des problèmes d'implémentation. La différence, c'est de le savoir avant de déployer.