Défis et limites du Model Context Protocol pour les IA génératives

Défis et limites du Model Context Protocol (MCP) pour l’IA générative : ce qui coince vraiment en production

Le point faible central : le contexte n’est pas une “mémoire”, c’est une fenêtre de travail

Quand on parle d’IA générative, l’un des écueils majeurs vient d’un malentendu : le modèle ne “se souvient” pas au sens humain. Il opère sur une fenêtre de contexte (tokens) et calcule une réponse à partir de ce qui est présent dans cette fenêtre, plus des paramètres appris. Le Model Context Protocol (MCP), qui standardise la façon de connecter un modèle à des outils et à des sources de données externes, améliore l’accès à l’information, mais ne transforme pas la fenêtre de contexte en mémoire persistante fiable. En pratique, cela crée un risque structurel : si une information utile n’est pas injectée au bon moment, dans le bon format, avec la bonne granularité, le modèle ne l’exploitera pas, ou l’exploitera mal.

Autre limite : même quand l’information est bien fournie via MCP, elle reste “du texte” ou une représentation sérialisée (résultats d’outils, extraits, JSON). Le modèle doit interpréter ce contexte, et cette interprétation n’est pas déterministe ni garantie. Autrement dit, MCP facilite la plomberie, pas la compréhension. Vous gagnez en connectivité, pas en vérité.

Inconvénients spécifiques du MCP : standardisation utile, mais surface d’échec plus grande

Le MCP introduit une couche d’orchestration : serveurs MCP, outils déclarés, schémas d’entrées/sorties, politique d’appel, gestion des permissions, et parfois routage vers plusieurs sources. Cette standardisation apporte de la portabilité, mais elle ajoute aussi des points de rupture. Le premier inconvénient concret est la dépendance à la qualité des “tools” : un outil qui renvoie des données partielles, ambiguës ou trop volumineuses dégrade immédiatement la génération. Le second est l’effet “boîte noire” : quand la sortie est mauvaise, vous devez diagnostiquer si l’erreur vient du modèle, du prompt, du mapping MCP, du serveur d’outils, d’un timeout, d’un schéma mal respecté, ou d’une donnée source incohérente.

Un autre inconvénient fréquent est la rigidité des schémas. MCP pousse à formaliser les entrées/sorties, ce qui est sain, mais la réalité métier est souvent plus floue que le schéma. Résultat : soit vous simplifiez trop (perte d’information), soit vous complexifiez (plus de tokens, plus d’erreurs d’interprétation, plus de cas limites). Dans les deux cas, la qualité peut chuter sans que ce soit visible immédiatement.

Pourquoi MCP pose problème en pratique : mécanismes qui coincent côté contexte

Le premier mécanisme bloquant est la compétition dans la fenêtre de contexte. Une application MCP typique injecte de multiples éléments : historique de conversation, consignes système, politique de sécurité, résultats d’outils, extraits RAG, métadonnées, et parfois traces d’exécution. Tout cela consomme des tokens. Plus vous “outillez” le modèle, plus vous grignotez l’espace disponible pour le contenu réellement utile. À partir d’un certain seuil, vous observez des symptômes classiques : réponses qui ignorent des contraintes, confusion entre versions d’une même donnée, ou raisonnement qui se base sur un extrait secondaire parce qu’il apparaît plus près de la fin du contexte.

Le deuxième mécanisme est l’ordre et la priorité implicites. MCP n’impose pas une sémantique universelle de priorité entre sources. Si vous injectez un extrait de base documentaire et une réponse d’API, le modèle peut arbitrer de manière inattendue. Il peut surpondérer un texte plus “narratif” même s’il est moins fiable, ou prendre pour vérité un champ JSON mal nommé. Le troisième mécanisme est la sérialisation : des données structurées (JSON) sont converties en tokens et deviennent sensibles aux erreurs de format, aux champs vides, aux unités, aux arrondis, et aux conventions locales. Une simple ambiguïté sur un fuseau horaire, une devise, ou une virgule décimale peut contaminer la réponse finale.

Enfin, MCP encourage l’appel à des outils à la volée. Si l’outil renvoie une information contradictoire avec le contexte déjà présent, le modèle peut mélanger les deux au lieu de choisir. Cela produit des sorties “hybrides” : plausibles, mais factuellement incohérentes.

Risques et contraintes sur la qualité des contenus générés

Le risque le plus visible est l’hallucination “assistée”. Avec MCP, le modèle a accès à des sources, mais il peut quand même combler les trous. Si une API renvoie un champ manquant, ou si une recherche documentaire ne trouve rien, le modèle peut produire une réponse complète malgré tout. Cela donne une illusion de couverture. Dans un contexte éditorial ou technique, cela peut créer des contenus qui semblent précis (ton assuré, chiffres, références), mais dont la traçabilité est faible.

Un autre risque est la dérive de style et de conformité. Plus vous ajoutez de contexte (guidelines, exemples, extraits), plus le modèle peut “moyenner” ces signaux et perdre la voix attendue. En SEO, cela se traduit par des pages qui ne respectent pas la structure attendue, qui diluent l’intention de recherche, ou qui répètent des éléments parce que des extraits similaires ont été injectés plusieurs fois via différents outils.

Il existe aussi une contrainte de cohérence multi-tours. MCP peut alimenter le modèle avec des résultats d’outils différents à chaque tour. Si vous n’implémentez pas une stratégie de persistance et de résumé, le modèle peut se contredire entre deux réponses, simplement parce qu’un résultat d’outil a changé, ou parce qu’un ancien résultat n’est plus présent dans la fenêtre de contexte.

Impact sur les ressources : tokens, latence, coûts, et complexité opérationnelle

Oui, les limitations liées au MCP ont un impact direct sur les ressources nécessaires pour obtenir de bons résultats. D’abord, l’augmentation du contexte augmente les coûts et la latence. Chaque appel qui inclut des extraits longs, des JSON détaillés ou un historique complet consomme des tokens en entrée. Si vous compensez la perte de qualité par “plus de contexte”, vous augmentez mécaniquement la facture et le temps de réponse, sans garantie de gain proportionnel.

Ensuite, MCP favorise les architectures à appels multiples : un LLM décide d’appeler un outil, récupère un résultat, puis reformule. Chaque étape ajoute de la latence réseau, des risques de timeout, et des coûts d’exécution côté outil (requêtes DB, recherche vectorielle, scraping, etc.). En production, ces micro-latences s’additionnent, et la variabilité (p95/p99) devient un vrai sujet.

Enfin, la complexité de monitoring augmente. Vous devez tracer les prompts, les contextes injectés, les appels d’outils, les versions de schémas, et la provenance des données. Sans cela, vous ne pouvez pas expliquer pourquoi une page générée est fausse ou incohérente, ni corriger durablement.

Où MCP crée des maux de tête lors d’une implémentation : points précis de friction

Premier point : la gouvernance des sources. MCP facilite l’accès à des outils, mais ne résout pas la question “quelle source fait autorité ?”. Si votre IA génère un contenu produit et que deux systèmes retournent des caractéristiques différentes (PIM vs ERP), le modèle peut fusionner. Cela crée des fiches produits incohérentes, des comparatifs erronés, ou des mentions légales incorrectes.

Deuxième point : la granularité du retrieval. Si vous injectez des documents trop longs, le modèle perd les détails. Si vous découpez trop fin, vous perdez le contexte global. MCP n’impose pas la bonne stratégie de chunking, ni la bonne politique de citation. Résultat : des réponses qui paraphrasent sans preuve, ou qui reprennent un passage hors contexte.

Troisième point : la robustesse des schémas et des conversions. Les outils MCP retournent souvent des structures. Si un champ change de nom, si une valeur passe de chaîne à nombre, ou si l’outil renvoie “N/A”, le modèle peut interpréter cela comme une valeur réelle. Dans des contenus techniques, cela se traduit par des spécifications inventées, des prérequis erronés, ou des étapes de procédure dangereuses.

Quatrième point : la sécurité et l’injection de prompt via données. Si un outil renvoie du texte non maîtrisé (extrait web, ticket support, commentaire), ce texte peut contenir des instructions qui perturbent le modèle. MCP ne supprime pas ce risque : il le déplace vers la validation et la sanitation des retours d’outils.

Exemples concrets où MCP montre ses limites (et comment ça “rate”)

Cas typique en génération d’articles SEO : vous connectez le modèle à un outil de recherche interne (base documentaire) et à un outil d’analyse SERP. L’outil SERP renvoie des titres et snippets, l’outil interne renvoie des extraits techniques. Le modèle produit un article “moyen” qui mélange des généralités issues des snippets et quelques détails techniques, mais il rate l’intention de recherche principale parce que les extraits internes sont trop spécialisés et prennent trop de place dans le contexte. Le résultat est un contenu long, crédible, mais mal aligné, donc moins performant.

Cas en support client : le modèle appelle un outil MCP “profil client” et un outil “statut commande”. Un timeout sur le statut commande renvoie un message d’erreur sérialisé. Le modèle interprète cet artefact comme une information (“commande introuvable”) et répond au client que la commande n’existe pas, alors qu’elle est simplement indisponible à l’instant T. Ici, l’échec vient de l’ambiguïté de la réponse outil et de l’absence de garde-fous sur la sémantique des erreurs.

Cas en rédaction technique : un outil renvoie une configuration au format JSON avec des unités implicites. Le modèle génère une procédure d’installation en mélangeant MB et MiB, ou en inversant des paramètres parce que deux champs se ressemblent. Le contenu final est lisible, mais faux, et peut conduire à une configuration cassée.

Cas en génération de contrats : MCP connecte le modèle à une base de clauses. Une clause est récupérée dans une version obsolète, car le retrieval a privilégié un document plus “proche” vectoriellement mais moins récent. Le modèle assemble un contrat avec une clause non conforme. Sans mécanisme explicite de priorité (versioning, date, statut), MCP ne protège pas contre ce type d’erreur.

Tableau synthétique : limites MCP, effets sur la qualité, et impacts opérationnels

Ce qu’il faut retenir côté “gestion du contexte” par le modèle, même avec MCP

Les gros points faibles ne disparaissent pas avec un protocole : la fenêtre de contexte reste limitée, l’interprétation reste probabiliste, et la qualité dépend de la sélection, de l’ordre et de la fiabilité des informations injectées. MCP rend l’intégration plus standard, mais il augmente la surface d’échec et déplace les difficultés vers l’orchestration, la gouvernance des sources, la validation des schémas, et le contrôle de la dérive. En clair, MCP aide à brancher l’IA au réel, mais il n’empêche ni l’oubli, ni la confusion, ni la surconfiance dans des données incomplètes.