Applications MCP : Quand le Chat IA Livre sa Propre Interface

Sur un chat d'IA générative, il est parfois possible de générer de petites interfaces utilisateur dynamiques. Par exemple, sur un sujet financier complexe, vous pouvez obtenir des diagrammes circulaires dynamiques ou des graphiques linéaires dans le cadre de la réponse.

C'est une fonctionnalité très intéressante, et j'ai été curieux de savoir comment elle est implémentée. Au début, je pensais que l'IA générative elle-même générait ces petites interfaces. En réalité, derrière ces interfaces se trouvent des serveurs MCP et, pour être plus précis, dans la plupart des cas, l'interface générée est une Application MCP (MCP App).

Pour expérimenter avec cela, j'ai créé une preuve de concept (PoC) en direct que vous pouvez essayer sur genui.iheb.pro.

Les Applications MCP, en bref

Les Applications MCP sont étroitement liées au protocole MCP classique, qui communique via stdio (serveurs locaux) et Streamable HTTP (serveurs distants, l'ancien transport HTTP+SSE étant désormais obsolète). La différence est que ces serveurs MCP sont également capables de fournir des interfaces front-end (frontends). En utilisant leurs outils, l'agent IA obtient des résultats en retour, et ces résultats atterrissent dans un magnifique graphique ou une autre figure selon la nature des données renvoyées. Le concept s'est maintenant étendu à la livraison de JavaScript et CSS dynamiques, ce qui permet d'avoir de petites applications entières à l'intérieur de la réponse du chat, d'où le nom d'Application MCP.

Un petit aperçu de la façon dont un serveur en déclare une :

// Les métadonnées de l'outil lient sa ressource UI officielle.
registerAppTool(server, "getForecast", {
  description: "Prévisions sur 6 jours pour une ville",
  _meta: { ui: { resourceUri: "ui://weather/dashboard" } },
}, handler);

Ces interfaces fonctionnent selon un flux très efficace. Dès que vous saisissez un prompt qui nécessite l'Application MCP, l'hôte précharge l'interface à partir d'une ressource comme ui://weather/dashboard, sans données au départ, et l'emballe dans une iframe bac à sable (sandboxed). L'agent appelle ensuite les outils du serveur pour répondre à la demande, le serveur MCP répond, et l'information est chargée dans l'application. L'utilisateur peut également interagir avec l'application, et par conséquent, l'application elle-même peut renvoyer des messages à l'agent IA, qui peut appeler à nouveau les outils MCP pour répondre à la nouvelle demande et rafraîchir les informations affichées.

Vous pouvez trouver plus d'informations sur les Applications MCP dans cette documentation, qui dispose même d'un assistant chat sympa pour explorer les docs.

J'ai vu divers exemples et cas d'utilisation. Il existe une Application MCP Excalidraw où vous pouvez créer des graphiques modifiables via des prompts IA, ou même lui demander d'expliquer un concept compliqué sous forme de diagramme Excalidraw. Il y a aujourd'hui une grande liste d'Applications MCP disponibles, et vous pouvez trouver une définition encore meilleure sur pulseMCP.

Création d'une preuve de concept (PoC) et la question du BYOK

Je voulais faire un PoC de cette génération d'Applications MCP : un serveur MCP plus un chat qui rend ces interfaces, en utilisant des technologies SSR comme Next.js. Vercel fournit également un SDK IA pour gérer de telles implémentations. Mais pour faire cette démo, j'aurais besoin d'exposer un modèle avec l'agent... ou pas ?

BYOK (Bring Your Own Key - Apportez votre propre clé) est également disponible sur les applications web. Dans ce modèle, l'utilisateur apporte la clé API de son IA choisie pour faire fonctionner l'application. Ce modèle existe pour plusieurs raisons :

• Tarification : vous payez pour votre utilisation exacte, au lieu que l'application ne maintienne un abonnement pour supporter les coûts des modèles pour tout le monde.
• Utilisation personnalisable : vous pouvez choisir n'importe lequel de vos modèles.
• Confidentialité : les requêtes vont au fournisseur de modèle via vos propres identifiants.

Le modèle BYOK gagne en popularité grâce à ces avantages. Étant donné que presque tous les services modernes intègrent des fonctionnalités IA, il est logique que les utilisateurs commencent à utiliser leurs propres clés, et que la tarification devienne plus faible et concentrée sur le service lui-même.

J'ai décidé d'utiliser ce modèle pour un chatbot PoC capable de livrer des Applications MCP.

Fournir des identifiants API est très sensible, et la clé API est saisie dans le navigateur. Dans le PoC, elle est stockée dans sessionStorage uniquement si vous acceptez, les requêtes vont au fournisseur d'IA via une fine route API de relais (pass-through), et la clé n'est jamais stockée ailleurs, jamais journalisée, et reste dans la portée de l'onglet :

// Tout le cycle de vie de la clé en trois lignes (par requête, puis abandonné) :
const apiKey = req.headers.get("authorization")?.slice("Bearer ".length);
const model = createProviderModel(provider, modelId, apiKey); // portée de la requête uniquement

// La persistance optionnelle se fait dans le sessionStorage de l'onglet — jamais dans le localStorage :
remember && sessionStorage.setItem("genui.byok.v1", JSON.stringify({ provider, model, apiKey }));

Important : Si vous souhaitez essayer le PoC sur genui.iheb.pro, veuillez noter qu'une connexion à un serveur MCP est obligatoire. Comme le PoC repose sur des serveurs gratuits, la connexion initiale peut prendre jusqu'à 30 à 40 secondes pour démarrer. Si le chat se bloque, ou si vous recevez une réponse dans le chat indiquant que le serveur est inaccessible, il suffit de rafraîchir la connexion (se déconnecter et se reconnecter) pour le réveiller.

Deux types de widgets

J'ai "vibecodé" l'application. Elle peut afficher et épingler deux types de widgets :

• Widget Météo : basé sur la spécification des Applications MCP, un serveur offrant des outils et exposant une ressource UI sur ui://weather/dashboard.
• Widget de parts de marché : un serveur MCP simple servant des résultats JSON simples, où le modèle connecté génère de petites interfaces pour lui en utilisant des schémas de composants validés par Zod, s'écartant de la spécification des Applications MCP, mais offrant plus de personnalisation sur l'interface.

// Le modèle n'écrit jamais de markup. Il choisit un composant enregistré + ses props :
render_widget({
  component: "MarketTable",
  props: { title: "Parts GI-5", rows: [...] }, // Validé par Zod, strict
});

En fait, avec les Applications MCP, les interfaces utilisateur ne sont pas générées par l'agent, elles sont pré-développées et testées, comme expliqué dans la spécification officielle. Pour les serveurs simples ne fournissant pas d'interface, nous pouvons toujours livrer des widgets React personnalisables côté UI ; les Applications MCP, en revanche, sont personnalisables côté données. Le choix est évidemment meilleur pour les Applications MCP pour le moment :

• pour encadrer l'interface, la valider et tester l'application ;
• pour être sécurisé contre les injections et les violations.

Ce que j'ai appris, et où cela pourrait aller

Sur le PoC, j'ai pu générer des widgets météo en utilisant les données MCP et mettre à jour leur contenu avec succès, et je peux choisir d'épingler ceux qui ont réussi. Du côté des parts de marché, j'avais plus de contrôle sur l'affichage, mais aussi plus de bugs, ce qui justifie à nouveau le modèle actuel des Applications MCP.

Le modèle MCP me rappelle le concept de service SOAP des premiers jours : un marché de services documentés et orientés usage que JEE consommait avec des applications frontales prédéfinies. Avec l'évolution de la livraison d'interfaces, les cas d'utilisation sont vastes mais nécessiteront un grand effort de développement. Aujourd'hui, il est encore très compliqué pour l'IA de déduire des outils (même s'ils sont documentés et exécutables) quelle interface générer, et encore moins de la générer correctement fonctionnelle du premier coup. La question intéressante est donc : existe-t-il un compromis entre ces deux solutions, faisant évoluer le concept des Applications MCP ?

Je pense qu'à court terme, la couche d'interface prête à l'emploi sera lentement complétée par des instructions et des frameworks IA légers qui composeront l'interface au goût de l'utilisateur, offrant plus de contrôle, tandis que l'Application MCP bac à sable pré-développée restera le défaut sûr. Les Applications MCP offrent des possibilités illimitées aux éditeurs ; si elles se démocratisent sur les chats agentiques, nous pourrions avoir beaucoup moins besoin du navigateur internet classique.