MCP Apps et A2UI placent tous deux des interfaces interactives au cœur des conversations avec les agents, mais ils fonctionnent de manière opposée. Cet article compare le rendu, la sécurité, la prise en charge par les hôtes et le coût, puis propose un tableau de décision qui associe chaque standard aux tâches qu’il gère le mieux.
Votre agent a fourni la bonne réponse, mais elle apparaît sous la forme d’un bloc de texte compact. Deux standards ouverts résolvent ce problème, et ils divergent sur presque tout le reste. MCP Apps livre une petite application web qui s’exécute dans un iframe isolé. A2UI envoie un plan au format JSON et laisse l’hôte le dessiner avec ses propres composants natifs. L’un donne au serveur le contrôle des pixels. L’autre confie ce contrôle au client.
Cette comparaison examine le rendu, la sécurité, la prise en charge par les hôtes et le coût au quotidien, puis se termine par un tableau de décision que vous pouvez appliquer dès aujourd’hui à votre propre agent. Toutes les affirmations sur les deux spécifications proviennent de la documentation officielle de MCP, du site du projet A2UI et du blog pour développeurs de Google, vérifiées en octobre 2026.
La différence se résume facilement. MCP Apps traite une interface comme une ressource qu’un serveur transmet. A2UI traite une interface comme des données qu’un agent décrit. Tout le reste de cet article découle de cette seule différence.
MCP Apps a commencé comme la proposition SEP-1865 en novembre 2025. Anthropic, OpenAI et les responsables du projet communautaire MCP-UI l’ont rédigée ensemble, en s’appuyant sur MCP-UI et sur l’Apps SDK d’OpenAI. En janvier 2026, elle est devenue la première extension officielle du Model Context Protocol, avec sa propre spécification datée du 2026-01-26 dans le dépôt ext-apps.
Le mécanisme réutilise deux primitives ordinaires de MCP, un outil et une ressource :
_meta.ui.resourceUri, qui pointe vers une ressource ui://.text/html;profile=mcp-app.postMessage, à l’aide d’un dialecte JSON-RPC avec les méthodes ui/, comme ui/initialize.
Comme la charge utile est du code web ordinaire, vous choisissez le framework. Le dépôt ext-apps fournit des modèles de départ pour React, Vue, Svelte, Preact, Solid et JavaScript pur. La classe App de @modelcontextprotocol/ext-apps est un wrapper pratique, pas une obligation. Vous pouvez implémenter vous-même le protocole postMessage si vous voulez moins de dépendances.
A2UI, abréviation d’Agent-to-User Interface, est le standard ouvert de Google, publié sous licence Apache 2.0 en décembre 2025. L’agent n’envoie pas de HTML. Il diffuse un JSON déclaratif qui nomme des composants et leurs données. Le client conserve un catalogue de composants en qui il a confiance, valide chaque message par rapport à ce catalogue, puis transpose le résultat dans un arbre d’interface natif.
Le slogan de Google résume bien l’idée : sûr comme des données, expressif comme du code. La spécification en est à v0.9.1, la v1.0 étant à l’état de version candidate en octobre 2026. Des moteurs de rendu existent pour Angular, Flutter et Lit, et Google utilise déjà A2UI dans Opal, Gemini Enterprise et le SDK Flutter GenUI. Les charges utiles circulent sous le type MIME application/a2ui+json.
💡 Modèle mental : MCP Apps, c’est « livrer un site web miniature ». A2UI, c’est « envoyer un plan et laisser l’hôte le construire avec des pièces approuvées ».
Avec MCP Apps, le serveur décide de l’apparence. L’hôte fournit seulement le cadre, le bac à sable et le pont de messages. Vous disposez alors de toute la plateforme web : graphiques D3, scènes WebGL, lecteurs PDF, cartes, globe CesiumJS ou scène Three.js. Ce sont de vrais exemples du dépôt ext-apps, aux côtés d’un allocateur de budget, d’une carte de chaleur de cohortes et d’un moniteur système.
Le prix à payer est la dérive visuelle. Un iframe n’hérite pas gratuitement du système de design de l’hôte, si bien que votre application peut ressembler à un corps étranger dans le chat. Elle porte aussi le poids d’une page de navigateur : ses propres scripts, sa propre mémoire, son propre temps de chargement.
Avec A2UI, c’est le client qui décide de l’apparence. L’agent dit « une carte avec un titre, un graphique et deux boutons », et le client dessine sa propre carte, son propre graphique et ses propres boutons. Le thème vient de l’hôte, donc le résultat s’accorde à l’application qui l’entoure, sur le web, le mobile ou le bureau, sans webview.
Le format est aussi adapté aux modèles de langage. Il est petit, structuré et conçu pour le streaming, si bien qu’un modèle peut émettre une interface étape par étape pendant que l’utilisateur la voit se construire. La limite tient au catalogue : si le client n’a pas de composant correspondant à ce que vous voulez, vous ne pouvez pas en inventer un dans la charge utile.
Voici la comparaison en un coup d’œil :
| Critère | MCP Apps | A2UI |
|---|---|---|
| Charge utile | Paquet HTML à une URI ui:// | Messages JSON |
| Qui effectue le rendu | L’hôte IA, dans un iframe isolé | Le client, à partir d’un catalogue approuvé |
| Qui contrôle l’apparence | Le développeur de l’application | L’application hôte |
| Flux d’actions | L’application demande des appels d’outils médiés par l’hôte | Le client valide et achemine les actions déclarées |
| Streaming | Les entrées d’outils peuvent alimenter une application préchargée | Conçu pour la génération incrémentale |
| Plateformes | Web d’abord | Web, mobile, bureau |
| Statut | Extension officielle de MCP | Piloté par Google, Apache 2.0, spécification v0.9.1 |
Deux modèles de menace très différents sous-tendent les deux conceptions. L’une isole le code. L’autre refuse d’accepter du code du tout.
L’application s’exécute dans un iframe isolé, elle ne peut donc pas atteindre le DOM de la page parente, lire les cookies ou le stockage local de l’hôte, ni rediriger la page parente. Tout le trafic traverse la frontière postMessage, et l’hôte décide de ce qui passe. La défense comporte plusieurs couches :
ui://, l’hôte peut précharger et examiner un modèle avant l’exécution de tout outil._meta.ui.csp répertorie les origines externes à partir desquelles une application peut charger du contenu._meta.ui.permissions.
A2UI élude la question du bac à sable en n’exécutant jamais rien. Le moteur de rendu n’accepte que du JSON validé et uniquement des composants présents dans le catalogue. Google appelle cela la sécurité par capacités : le client affiche des composants de confiance et rien d’autre.
Cela ne rend pas A2UI automatiquement sûr. Un bouton du catalogue peut tout de même déclencher une action, donc le client doit autoriser chaque action déclarée et valider chaque charge utile. La liste blanche protège l’interface. Elle ne protège pas votre logique métier.
Les deux standards font passer du contenu d’un agent vers un écran, et ils héritent donc tous deux des faiblesses de l’agent. Un modèle qui lit une page web hostile peut être amené à afficher un faux formulaire convaincant, qu’il se trouve dans un iframe ou sur une carte du catalogue. Traitez les appels d’outils déclenchés depuis toute interface générée comme une entrée non fiable : vérifiez les autorisations côté serveur, limitez strictement la portée des jetons et exigez une confirmation pour tout ce qui dépense de l’argent ou modifie des données.
La prise en charge par les hôtes est l’argument le plus solide en faveur de MCP Apps aujourd’hui. La documentation officielle cite Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam et Archestra.AI, et ChatGPT les affiche aussi. Le projet MCP tient une matrice des clients, et elle compte : la prise en charge de l’interface des applications est plus restreinte que celle des outils MCP de base. Un client qui appelle vos outils peut malgré tout ignorer votre ressource ui://.
Si vous construisez vous-même un hôte, vous avez deux options. Le paquet @mcp-ui/client fournit des composants React, et le module App Bridge du SDK prend en charge le rendu en bac à sable, le passage de messages, le relais des appels d’outils et l’application des politiques.
La prise en charge d’A2UI dépend du moteur de rendu livré avec votre client, et non d’une liste de produits de chat. Vous choisissez Angular, Flutter ou Lit, définissez votre catalogue et branchez un transport. Le protocole A2A transporte A2UI entre agents, et AG-UI, le protocole de CopilotKit, annonce une compatibilité dès le premier jour. A2UI peut aussi circuler sur MCP : les charges utiles arrivent via resources/read pour les écrans statiques ou tools/call pour les écrans dynamiques, sous un schéma d’URI a2ui://.
Choisissez selon la tâche, et non selon la marque. Ce tableau montre comment les équipes répartissent généralement le travail :
| Scénario | Meilleur choix | Pourquoi |
|---|---|---|
| Intégration produit avec authentification et état du compte | MCP Apps | Le serveur gère les autorisations et l’état |
| Flux d’approbation pour des dépenses ou des modifications de données | MCP Apps | Vous livrez une surface stable et testée |
| Médias riches, cartes, 3D, lecteurs PDF | MCP Apps | Plateforme web complète dans l’iframe |
| Exploration de données aux mises en page changeantes | A2UI | L’agent choisit le graphique, le tableau ou la carte |
| Rapports générés | A2UI | Mises en page flexibles, données changeantes |
| Une seule interface pour le web et le mobile | A2UI | Même charge utile, rendu natif |
| Forte cohérence avec un système de design | A2UI | Le thème de l’hôte s’applique |
Optez-y lorsque vous possédez déjà un produit web et voulez l’intégrer au chat. Votre serveur porte la logique, vous contrôlez chaque pixel et vous pouvez réutiliser les composants React que vous avez déjà. Optez-y aussi lorsque la rapidité du prototypage compte : un seul fichier HTML suffit pour livrer.
Optez-y lorsque l’écran n’est pas connu à l’avance. Un agent qui répond « montre-moi le dernier trimestre » par un tableau aujourd’hui et par un graphique demain se prête bien mieux à un catalogue qu’à une page construite à la main pour chaque cas. Optez-y également lorsque votre client est natif, ou lorsque votre équipe sécurité n’acceptera pas de scripts tiers dans le chat.
Le choix n’est pas exclusif. Le blog pour développeurs de Google, publié le 17 juin 2026, décrit trois schémas d’intégration, et ils changent le sens de « choisir l’un ou l’autre ».
a2ui://. Aucun iframe n’est nécessaire.Pour la plupart des équipes, une répartition par tâche fonctionne. Placez les surfaces stables et à fort enjeu, comme les approbations, les réglages et les vues de compte, dans MCP Apps. Placez les surfaces flexibles et générées, comme les rapports et les synthèses, dans A2UI. Servez les deux depuis le même serveur MCP afin que votre agent garde une seule connexion. Le schéma 3 est votre solution de repli lorsqu’un hôte ne dispose pas de moteur de rendu.
Revoyez la répartition tous les trimestres. Si une surface générée commence à avoir besoin de graphiques personnalisés que le catalogue ne sait pas dessiner, cet écran a dépassé A2UI et doit devenir une application MCP. Si une application MCP est reconstruite à chaque nouvelle forme de données, elle devient plutôt candidate pour un catalogue.
Écrire les charges utiles A2UI à la main devient vite fastidieux, et un modèle de langage qui renvoie du JSON strict est un partenaire de rédaction idéal. GPT 5 Structured sur PicassoIA est conçu précisément pour cela : vous définissez un schéma JSON, et chaque réponse s’y conforme.
model : gpt-5, gpt-5-mini ou gpt-5-nano.instructions. Listez les composants acceptés par votre client, avec leurs propriétés.prompt, par exemple « un récapitulatif de commande avec un tableau des articles et un bouton de confirmation ».json_schema sur le schéma de message de la spécification A2UI. Utilisez json_schema plutôt que simple_schema, car la version simple ne prend pas en charge les objets imbriqués.reasoning_effort sur minimal pour les brouillons rapides. Pour les mises en page denses, augmentez-le et relevez max_output_tokens, car un raisonnement poussé peut épuiser le budget et renvoyer une réponse vide.💡 Considérez la sortie du modèle comme un brouillon. Le validateur de votre moteur de rendu est le dernier filtre, exactement comme le prévoit le modèle de sécurité d’A2UI.
Vous voulez comparer des brouillons issus d’autres modèles ? Claude Sonnet 5 et Gemini 3.5 Flash sont aussi disponibles sur PicassoIA, si bien que vous pouvez lancer le même catalogue et le même prompt sur chacun et garder le résultat le plus propre.
Quel que soit le standard retenu, les écrans de votre agent ont besoin d’images : vignettes de produits, bannières d’accueil, photos d’en-tête pour les rapports. MCP Apps affiche les images en HTML simple. A2UI les affiche via le composant image que définit votre catalogue. Dans les deux cas, il faut d’abord disposer des images.
PicassoIA réunit les générateurs au même endroit. Seedream 5 Pro, Flux 2 Pro, Imagen 4 et PicassoIA Image figurent tous dans la collection texte vers image, si bien que vous pouvez lancer un même prompt sur plusieurs modèles et garder la version qui correspond à votre mise en page. PicassoIA expose aussi ses générateurs via des connexions MCP, de sorte qu’un agent qui parle le protocole décrit plus haut peut demander directement des images.
Ouvrez la collection, rédigez un prompt pour votre prochaine carte ou bannière et générez quelques variantes. Choisissez un écran de votre propre agent, donnez-lui une vraie image et voyez à quelle vitesse la partie visuelle rattrape la logique.
Choisissez votre langue
