MCP Apps et Tasks : gouverner les nouvelles extensions MCP de premier ordre

La même version 2026-07-28 de MCP qui a rendu le protocole sans état a également promu deux extensions au rang de composants de premier ordre : MCP Apps, qui permet à un outil de renvoyer une UI interactive affichée dans une iframe isolée (sandboxed), et Tasks, qui modélise le travail à longue durée d'exécution sous la forme d'une machine à états durable pilotée par le client via tasks/get, tasks/update et tasks/cancel. Elles sont véritablement utiles — et constituent de toutes nouvelles surfaces de gouvernance et de sécurité. Cet article explique le fonctionnement de chacune, l'origine de ces nouveaux risques, et pourquoi la passerelle est l'endroit idéal pour les gouverner.

Hana, ingénieure produit, a déployé un outil MCP « générer un rapport trimestriel » et a utilisé les deux nouvelles extensions pour l'améliorer. Elle a renvoyé une MCP App — un aperçu interactif que l'utilisateur pouvait ajuster dans un panneau isolé — et, comme la génération prenait deux minutes, elle l'a modélisée sous forme de Task afin que l'appel ne soit pas bloquant. La démonstration était excellente. Les problèmes sont apparus la semaine suivante. L'aperçu affiché par l'App inclvait le nom d'un fournisseur tiré directement d'un enregistrement non approuvé, et un coéquipier a fait remarquer que rien ne filtrait ce qui était affiché dans cette surface — ce même contenu que le modèle allait relire. De plus, une Task de rapport a tourné pendant dix-huit minutes, brûlant silencieusement des tokens, sans qu'aucune progression ni aucun coût ne soient visibles jusqu'à son terme.

Aucun de ces problèmes n'était dû à un bug dans le code d'Hana. Il s'agissait simplement des nouvelles surfaces fonctionnant exactement comme la spécification l'autorise, dans un système disposant d'une gouvernance pour les appels d'outils, mais pas pour les UI affichées ni pour les tâches à longue durée d'exécution. La version 2026-07-28 n'a pas seulement simplifié le transport ; elle a ajouté deux endroits où résident désormais la valeur — et le risque. Cet article explique comment vous appuyer sur ces extensions sans subir les déboires d'Hana.

1. Ce que sont les MCP Apps et Tasks, et pourquoi elles sont désormais de premier ordre

Cette version a réorganisé les extensions en un véritable framework : chaque extension obtient un identifiant reverse-DNS, son propre dépôt et ses propres mainteneurs, ainsi qu'une version qui évolue indépendamment de la spécification centrale. Les clients et les serveurs négocient la prise en charge via une carte d'extensions dans leurs capacités — un serveur annonce qu'il gère les MCP Apps ou une version donnée de Tasks, le client annonce la même chose, et si les deux sont d'accord, ils l'utilisent ; sinon, la connexion continue de fonctionner sans elle. Les MCP Apps et Tasks en sont les deux premiers exemples de premier ordre.

Élément crucial, aucune des deux ne remplace la primitive d'outil. Un outil prend toujours des arguments JSON et renvoie des résultats JSON. Une App ajoute une surface d'affichage optionnelle par-dessus un outil ; une Task modifie la façon dont le résultat de l'appel d'un outil est livré lorsque le travail est long. C'est pourquoi il convient de les considérer comme des augmentations — et pourquoi la gouvernance que vous appliquez déjà aux outils doit s'étendre pour les couvrir plutôt que de les remplacer.

2. MCP Apps : l'UI affichée par le serveur comme nouvelle surface

Une MCP App permet à un outil de renvoyer une ressource UI interactive que l'hôte affiche dans une iframe isolée. L'analogie issue des discussions sur la spécification est très pertinente : elle enrichit un outil de la même manière qu'un tableau de bord hébergé enrichit une API. Le contrat JSON de l'outil reste inchangé ; l'App est l'enveloppe interactive qu'un hôte peut présenter à l'utilisateur. Pour l'outil de rapport d'Hana, l'App correspond au panneau d'aperçu.

Cette capacité est négociée, non présumée. Un serveur déclare l'augmentation App dans ses capacités, et un hôte qui ne prend pas en charge les Apps reçoit simplement le résultat JSON sans rien afficher de plus. Cette dégradation progressive est une excellente conception — mais cela signifie aussi que la surface App est optionnelle et facile à déployer sans réfléchir aux éléments qu'elle introduit, ce qui fait l'objet de la section suivante.

3. La surface de sécurité des Apps : l'utilisateur et le modèle la lisent tous les deux

Le nouveau risque lié à une App réside dans le fait que son contenu affiché s'adresse à deux publics. L'utilisateur le voit, donc tout contenu non approuvé affiché dans le panneau relève de la sécurité du contenu côté client — l'iframe isolée limite le rayon d'impact, ce qui explique pourquoi l'hôte l'affiche de manière isolée, mais cet isolement borne ce que le balisage peut faire à l'hôte, et non ce que le contenu peut dire. Selon le comportement de l'hôte, le contenu de l'App, ses données sous-jacentes ou les actions déclenchées depuis l'UI peuvent réalimenter le contexte du modèle. Ainsi, un texte non approuvé affiché dans une App constitue un autre vecteur pour l'injection indirecte de prompt traitée dans notre article sur l'injection de prompt : des instructions dissimulées dans un champ qui se retrouve sous les yeux du modèle.

La posture pratique consiste à traiter le contenu d'une App comme une sortie non approuvée nécessitant le même filtrage que tout autre contenu adjacent au modèle : analyser et assainir ce qui est affiché, ne jamais interpoler de données brutes non approuvées dans la surface sans les échapper, et maintenir un isolement strict pour l'App. Le champ du nom de fournisseur dans le cas d'Hana est l'erreur classique — une donnée non approuvée interpolée dans une surface affichée que l'utilisateur et le modèle consomment tous deux, sans aucun garde-fou intermédiaire.

4. Tasks : le travail à longue durée d'exécution dans un protocole désormais sans état

Les Tasks étaient expérimentales dans le cœur 2025-11-25 ; la version 2026-07-28 les déplace dans une extension officielle dotée d'un cycle de vie conçu pour un monde sans état. Le modèle est piloté par le demandeur : un serveur peut répondre à un tools/call avec un identifiant de tâche (handle) plutôt qu'avec un résultat immédiat, et le client pilote ensuite le travail avec tasks/get, tasks/update et tasks/cancel. (La surface expérimentale précédente 2025-11-25 incluait également tasks/list et tasks/result ; la RC remanie le cycle de vie autour de get/update/cancel et supprime tasks/list, qui ne peut pas être sécurisée proprement une fois le protocole sans état. Considérez l'ensemble exact des méthodes comme propre à la RC et confirmez la livraison des résultats par rapport à la spécification finale.) Une Task est, en fait, une petite machine à états durable doublée d'un pointeur vers son résultat.

La prise en charge est négociée de manière granulaire — un pair ne se contente pas de dire « je gère les tâches », il spécifie quelles requêtes peuvent être augmentées par une tâche. La carte des capacités est explicite à ce sujet :

Négociation des Tasks dans la RC 2026-07-28 — à titre illustratif ; confirmez l'ID d'extension exact et le schéma par rapport à la spécification finale

La structure ci-dessus illustre le framework d'extensions de la RC et ne constitue pas un schéma littéral. L'ancienne forme capabilities.tasks avec tasks/list appartenait à l'API expérimentale Tasks de la version 2025-11-25 ; la RC déplace la négociation sous une carte d'extensions identifiées par reverse-DNS. Confirmez l'identifiant et les champs finaux par rapport à la spécification du 28 juillet avant toute implémentation.

Tout ce qui n'est pas répertorié sous requests reste synchrone ; un client ne doit pas tenter d'augmenter par une tâche une requête que le serveur n'a pas annoncée. C'est la méthode propre et native à MCP pour gérer la concurrence sans inventer de canaux secondaires — et elle s'articule parfaitement avec le cœur sans état car l'identifiant de tâche est un jeton explicite généré par le serveur et retransmis par le client, ce qui correspond exactement au modèle d'état explicite encouragé par l'architecture sans état.

5. Observer une Task : cycle de vie, progression et coût

L'angle mort de dix-huit minutes rencontré par Hana constitue le cœur opérationnel de Tasks. Une tâche à longue durée d'exécution qui ne renvoie rien tant qu'elle n'est pas terminée est une boîte noire : vous ne pouvez pas afficher la progression, vous ne voyez pas les coûts s'accumuler, et vous ne pouvez pas distinguer une tâche bloquée d'une tâche lente. Le cycle de vie offre les crochets nécessaires — le client interroge l'état et peut afficher la progression ainsi que des mises à jour intermédiaires — mais quelqu'un doit enregistrer ces transitions, sommer les tokens consommés par la tâche tout au long de son exécution et exposer ces données.

Mener une tâche à son terme avec une visibilité à chaque étape (boucle client illustrative)

Il s'agit de la même problématique d'observabilité que dans le reste de la série, appliquée à un nouvel objet. Le traçage qui capture une requête normale doit traiter une Task comme une étendue (span) qui reste ouverte tout au long de son cycle de vie, avec la comptabilisation des tokens et des coûts qui lui est attribuée. MCP Gateway de TrueFoundry trace déjà chaque appel de serveur MCP et attribue l'utilisation par utilisateur, outil et équipe ; pour une Task, cette même télémétrie s'étale dans le temps au lieu d'être capturée en un instant unique — ce qui est précisément la pièce manquante dans l'outil de rapport d'Hana.

6. Gouvernance : qui peut lancer des Apps et des Tasks, et avec quel budget

Le protocole définit le fonctionnement des Apps et des Tasks ; il vous laisse délibérément le soin de déterminer qui peut les utiliser et dans quelles limites. C'est un manque de gouvernance qui pose des questions concrètes. Quels agents ou utilisateurs sont autorisés à lancer une Task longue ? Quels sont le délai d'expiration et le budget de tokens avant qu'une Task ne soit interrompue de force — afin qu'une exécution de dix-huit minutes résulte d'une décision de gestion et non d'un accident ? Quels outils peuvent renvoyer une App, et quel contenu est autorisé à s'y afficher ?

Exemple de politique de passerelle pour les nouvelles surfaces (le schéma est propre à la passerelle)

Rien de tout cela n'est exotique ; il s'agit du même contrôle d'accès basé sur les rôles (RBAC), du même budget et des mêmes mécanismes de garde-fous déjà appliqués aux appels de modèles et d'outils, étendus à deux nouveaux objets. La raison de centraliser ces règles est que les Apps et les Tasks seront utilisées par de nombreux agents sur de nombreux serveurs. Réimplémenter ces contrôles au cas par cas par serveur ou par application est le meilleur moyen de laisser filer la tâche de dix-huit minutes et le panneau non filtré. Un point de politique unique permet d'apporter une réponse centralisée à la question : « qui peut lancer une Task, pour combien de temps, et que peut-on afficher dans une App ? »

C'est sur le terrain des garde-fous que cela devient concret, car la passerelle filtre déjà le contenu sur un ensemble de crochets (hooks) documentés. La passerelle de TrueFoundry en expose quatre — llm_input et llm_output sur le trafic des modèles, ainsi que mcp_pre_tool et mcp_post_tool sur le trafic des outils — et un nombre illimité de validateurs (détection de PII, analyse des secrets, classificateurs d'injection de prompt et de toxicité, assainisseurs SQL, vérifications de politiques via Cedar ou OPA) s'y rattachent. Ils s'exécutent en parallèle sur la même requête : ainsi, un garde-fou d'entrée s'exécute en même temps que l'appel au modèle et peut l'annuler avant que les tokens ne soient facturés s'il bloque la requête. La discipline opérationnelle qui garantit la sécurité en production repose sur un déploiement progressif — d'abord en audit (enregistrer les violations, laisser passer le trafic), puis en application (bloquer en cas d'échec, autoriser le passage en cas d'erreur du fournisseur), puis en mode strict — afin qu'une panne du fournisseur de garde-fous ne fasse jamais tomber l'ensemble du flux dès le premier jour.

7. Migration : de la version expérimentale de Tasks au nouveau cycle de vie

Si vous avez adopté l'API expérimentale Tasks du cœur 2025-11-25, le passage à l'extension constitue une véritable migration, et non un simple changement de nom. Le cycle de vie et les méthodes sont réorganisés autour de tasks/get, tasks/update et tasks/cancel, et la négociation des capacités est désormais explicite et granulaire. La bonne nouvelle est que la politique d'obsolescence adoptée dans cette version garantit un chevauchement d'au moins douze mois entre la déclaration d'obsolescence et la suppression effective. L'ancienne surface continue donc de fonctionner pendant votre transition au lieu de s'arrêter brutalement à une date précise.

La voie à moindre risque est celle que la migration sans état encourage déjà : écrivez des outils qui génèrent et exigent des identifiants explicites, négociez l'extension Tasks plutôt que de la supposer acquise, et considérez la version candidate comme provisoire — elle a été figée le 21 mai 2026 et devrait être finalisée le 28 juillet, le texte de la spécification pouvant encore évoluer pendant la période de validation. Une passerelle capable de gérer à la fois la forme expérimentale et l'extension pendant cette phase de chevauchement s'avère particulièrement utile, tout comme elle vous protège lors de la transition vers le transport sans état.

8. Emplacement idéal : la passerelle comme point de gouvernance

Les Apps et les Tasks renforcent un schéma récurrent dans cette série : le protocole définit le mécanisme, et la passerelle fournit la gouvernance que le protocole laisse de côté. MCP Gateway se place déjà en amont de chaque serveur MCP enregistré en tant que point de découverte, d'authentification, de RBAC et de traçage au niveau des requêtes — ce qui constitue précisément la surface où le contenu des Apps peut être filtré et où le cycle de vie des Tasks peut être observé et limité.

Concrètement, cela signifie que le contenu affiché par une App passe par les mêmes garde-fous de sortie que n'importe quelle autre donnée adjacente au modèle. De son côté, une Task est tracée comme une étendue à longue durée de vie dont les tokens et les coûts sont attribués à l'agent qui l'a lancée — en utilisant la découverte, le RBAC et l'observabilité déjà fournis par MCP Gateway, plutôt qu'en greffant un second système de gouvernance sur chaque serveur. La répartition du travail reste classique : le serveur implémente l'App ou la Task ; la passerelle gouverne qui peut l'utiliser, ce qu'elle peut afficher, combien de temps elle peut s'exécuter et ce qu'elle a coûté.

9. FAQ

Les MCP Apps sont-elles simplement un moyen de renvoyer du HTML ?

Plus précisément, une App enrichit un outil avec une ressource UI interactive que l'hôte affiche dans une iframe isolée — l'outil accepte et renvoie toujours du JSON, et l'App est l'enveloppe optionnelle par-dessus. L'enjeu pour la gouvernance réside dans le fait que le contenu affiché est généré, souvent à partir d'entrées non approuvées, et peut réalimenter le contexte du modèle via le comportement de l'hôte, les sorties d'outils ou les actions initiées depuis l'UI. Cela le place directement dans le champ des garde-fous de sortie, au lieu d'être traité comme une simple présentation inerte.

Le protocole sans état rend-il les Tasks inutiles ?

Non — ils répondent à des problèmes différents. Le transport sans état signifie qu'aucune requête n'est rattachée à une instance particulière ; les Tasks modélisent un travail qui dépasse la durée d'un simple aller-retour requête-réponse, peu importe l'instance qui traite chaque demande d'état (poll). En réalité, l'identifiant de tâche illustre parfaitement le modèle d'état explicite encouragé par l'architecture sans état : un identifiant généré par le serveur et retransmis par le client, permettant à n'importe quelle instance de fournir l'état de la tâche.

Quel est le plus grand nouveau risque à anticiper ?

Il y en a deux. Concernant les Apps : le contenu non approuvé affiché dans la surface — il doit être traité comme une sortie à filtrer pour détecter les injections et les PII, et non comme du balisage inoffensif. Concernant les Tasks : le travail à longue durée d'exécution non limité — définissez un délai d'expiration et un budget de tokens afin qu'une tâche dérivante soit interrompue de force par la politique, et tracez son cycle de vie pour qu'elle ne soit jamais une boîte noire. Ces deux points relèvent de la gouvernance que vous ajoutez autour de la spécification, et non de comportements fournis directement par celle-ci.

Dois-je migrer dès maintenant ?

Planifiez dès maintenant ; la version candidate a été figée le 21 mai 2026 et sa finalisation est prévue pour le 28 juillet, avec des changements majeurs si vous utilisiez l'API expérimentale Tasks. Le chevauchement d'obsolescence de douze mois garantit que rien ne se cassera du jour au lendemain, mais les nouveaux développements doivent cibler le cycle de vie de l'extension et négocier explicitement les capacités. Considérez la RC comme provisoire jusqu'à sa ratification.

Gouvernance des Apps ou des Tasks — passerelle ou application ?

La passerelle doit gérer les contrôles transversaux : quels agents peuvent lancer des Apps et des Tasks, les plafonds de délais d'expiration et de budget, les garde-fous de sortie sur le contenu affiché et le traçage du cycle de vie — appliqués de manière uniforme sur chaque serveur MCP. L'application conserve la logique métier de ce que l'App affiche et de ce que la Task accomplit, car cela nécessite des connaissances contextuelles dont la passerelle ne dispose pas.

On se souviendra de la version 2026-07-28 pour son passage au mode sans état, mais les Apps et les Tasks sont les éléments qui modifient concrètement ce que vous construisez. Elles ajoutent une surface d'affichage et une surface d'exécution longue ; la spécification vous fournit le mécanisme et vous laisse gérer la gouvernance. Comblez cet écart au niveau de la passerelle — filtrez ce qui s'affiche, limitez ce qui s'exécute, tracez les deux — et la démonstration réussie d'Hana deviendra un système de production fiable.

Si la passerelle est l'endroit où vous gouvernez ces surfaces, il est avantageux que ce même plan de contrôle soit également le lieu où s'exécutent les agents qui les utilisent. AI Gateway de TrueFoundry constitue le point d'entrée unifié pour le trafic des modèles, de MCP et des outils, et son Agent Harness est le moteur d'exécution qui orchestre la boucle planifier-agir-observer de l'agent, l'isolement, les approbations et le traçage. Ainsi, le contenu d'App qu'un agent affiche et les Tasks qu'il lance sont filtrés, limités et tracés par le plan même qui fait tourner l'agent, plutôt que par une couche de gouvernance ajoutée après coup.

Références

• Model Context Protocol — La version candidate 2026-07-28 (Extensions, MCP Apps, Tasks)
• MCP 2025-11-25 — API expérimentale Tasks (la surface précédente ; la RC 2026-07-28 la remanie sous forme d'extension)
• TrueFoundry — MCP Gateway (découverte, RBAC, observabilité)
• Nos articles sur l'injection de prompt et OpenTelemetry pour les LLM — garde-fous de sortie et traçage appliqués aux nouvelles surfaces.

Northwind et Hana sont des exemples illustratifs. Les détails sur les MCP Apps et Tasks sont issus des documents officiels de la version candidate 2026-07-28 du Model Context Protocol et des synthèses associées à la fin mai 2026 ; la RC a été figée le 21 mai et sa ratification est prévue pour le 28 juillet 2026. Le texte de la spécification pouvant encore évoluer, considérez les spécificités du protocole — noms de méthodes, structures de capacités et états du cycle de vie — comme provisoires et vérifiez-les par rapport à la spécification finale. Les exemples de code illustrent des schémas documentés et ne sont pas copiés d'une implémentation de référence. Les fonctionnalités de TrueFoundry sont résumées à partir de la documentation publique du produit et sont sujettes à évolution.

‍