Le 26 janvier 2026, le Model Context Protocol (MCP) a publié sa toute première extension passée en production (l'annonce officielle). Son nom : MCP Apps. Sa particularité : elle ne touche ni aux modèles, ni aux serveurs d'agents, mais à l'écran. Un outil MCP peut désormais renvoyer une interface interactive — formulaire, tableau de bord, visualisation — rendue directement dans le fil de conversation, sans navigateur et sans onglet.
Le mécanisme est sobre. Un outil déclare un resourceUri dans ses métadonnées ; l'hôte récupère la ressource servie en ui://, la rend dans une iframe sandboxée, et fait dialoguer les deux côtés en JSON-RPC via postMessage. Traduction : l'interface n'est plus une page que l'on visite, c'est un objet que l'outil fabrique et que le client affiche.
Pourquoi ça compte maintenant
Rien n'est né ex nihilo. Le protocole traînait une asymétrie depuis ses débuts : les modèles savaient se connecter à des données et déclencher des actions, mais l'utilisateur, lui, restait devant une colonne de bulles. Un graphique arrivait en base64 que le modèle devait décrire ; un formulaire de déploiement se réduisait à trente échanges de texte. La démo était propre, l'usage quotidien nettement moins.
C'est ce vide que trois initiatives ont attaqué en parallèle. OpenAI a lancé son Apps SDK au DevDay du 6 octobre 2025, avec des widgets HTML rendus dans ChatGPT. La communauté MCP-UI poussait la même architecture, mais neutre vis-à-vis des éditeurs. En novembre 2025, les deux lignées ont fusionné dans SEP-1865, ratifié début 2026 comme spécification datée. Aujourd'hui, ChatGPT, Claude, Goose et Visual Studio Code déclarent un support.
Une démo n'est pas un usage. Entre un widget qui s'affiche et un widget qui tient une journée de travail, il y a un fossé de robustesse.
Ce que ça change vraiment
Pour un éditeur de logiciel, la portée change. Le même serveur qui alimente ChatGPT peut, en théorie, alimenter Claude et VS Code sans réécriture — à condition de bâtir d'abord sur les champs ouverts de la spécification, puis de traiter les extensions propriétaires comme un bonus. Les praticiens le formulent autrement : considérer window.openai comme une amélioration progressive, jamais comme le seul chemin vers un résultat.
Pour les usages, le gain est plus discret qu'il n'y paraît. Trois familles reviennent :
- Explorer une donnée : filtrer un tableau, zoomer sur une période, ouvrir un enregistrement — sans relancer un prompt à chaque clic.
- Guider une configuration : un formulaire dont les champs dépendent des réponses précédentes, là où le chat impose un texte linéaire.
- Suivre un état : des métriques qui se rafraîchissent seules, sans réexécuter l'outil pour voir la situation présente.
Rien de spectaculaire, et c'est précisément l'intérêt : ce sont les gestes ordinaires d'une application, remis là où ils manquaient.
Le piège du récit marketing
La tentation est de lire l'annonce comme la fin de l'onglet, voire du site. C'est aller vite. MCP Apps décrit des affordances — des choix d'interface imposés par l'hôte — pas une plateforme de distribution aboutie. Le seul rail de paiement intégré aujourd'hui, requestCheckout(), appartient aux extensions ChatGPT et ne circule pas ailleurs. Un widget rendu dans un hôte n'a ni URL partageable, ni référencement, ni analytics comparables à ceux du web ouvert.
Autrement dit, la surface gagne en proximité ce qu'elle perd en contrôle. Le danger n'est pas que l'interface disparaisse de la conversation ; c'est qu'elle y devienne un format propriétaire de plus, capté par l'hôte qui l'affiche.
Gagner un iframe, c'est parfois perdre une adresse.
Pour un studio, une surface à designer
L'angle intéressant n'est pas technique, il est de métier. Concevoir un widget, c'est concevoir une interface sous contrainte : un cadre imposé, une hauteur variable, un thème qui ne vous appartient pas, aucune maîtrise de la navigation. Les réflexes d'un site — header, page d'accueil, parcours balisé — ne tiennent plus. Il faut penser en unités denses : un formulaire qui va droit au but, un tableau lisible en un écran, une étape qui tient debout toute seule.
Cela déplace la valeur. Le premium ne se jouera pas sur l'effet visuel, mais sur la clarté d'un parcours en trois champs et sur la robustesse d'un état qui survit au re-render. Un métier d'interface s'ouvre ; on ne sait pas encore quelle part du marché s'y engouffrera.
Reste l'incertitude de fond. Les clients expérimentaux sont là, la spécification est stable, mais l'usage réel commence à peine. Soit les hôtes adoptent la spec ouverte et MCP Apps devient la couche commune des interfaces embarquées ; soit chacun pousse son format et l'onglet reste, par défaut, la seule adresse que l'on puisse citer.