---

MCP a un an et demi : le moment où le protocole a cessé d’être un simple standard de fonctions

Il faut se souvenir de ce qu’était MCP à l’origine. Le 25 novembre 2024, Anthropic publie le Model Context Protocol, porté par deux de ses ingénieurs, David Soria Parra et Justin Spahr-Summers. Le diagnostic initial est simple et bien connu de quiconque a intégré des outils dans un LLM : le problème N×M. N sources de données, M clients IA, et entre les deux une explosion combinatoire de connecteurs personnalisés à maintenir. MCP propose de remplacer ce maquis par un protocole unique : un serveur expose des outils, des ressources et des prompts ; un client les consomme. Fin de l’histoire.

L’adoption est rapide. Au printemps 2025, OpenAI et Google DeepMind embrassent le protocole — les traces de presse citées par Wikipédia remontent à VentureBeat le 27 mars 2025 et TechCrunch le 25 mars 2025. En décembre 2025, Anthropic fait don de MCP à l’Agentic AI Foundation, un fonds hébergé sous la Linux Foundation, cofondé par Block et OpenAI, avec Google, Microsoft, AWS et Cloudflare en soutien affiché. Le protocole quitte le giron d’un seul éditeur pour devenir une infrastructure partagée. La documentation officielle, dans sa version datée 2026-07-28, liste comme clients compatibles Claude, ChatGPT, Visual Studio Code, Cursor et MCPJam. Les projections d’adoption par les éditeurs SaaS — 30 % en 2026, 60 % en 2027 selon Forrester repris par Studeria — donnent la mesure de l’ambition.

Et puis il y a cette section, discrète mais lourde de conséquences, dans la documentation versionnée 2026-07-28 : « Build MCP Apps — Build interactive apps that run inside AI clients ». Une page dédiée existe sous /extensions/apps/overview. Le protocole ne se contente plus de déclarer des fonctions ; il expose désormais des interfaces manipulables.

La question centrale mérite d’être posée sans détour : que change le fait qu’un serveur MCP puisse dessiner un formulaire dans votre client plutôt que de renvoyer du texte que l’hôte devra parser ? La réponse n’est pas cosmétique. Elle touche à l’architecture, à la sécurité, aux coûts en tokens et à la manière dont on conçoit un agent en production.

Une précaution s’impose avant d’aller plus loin : la spécification technique détaillée de l’extension Apps — les primitives exactes, les schémas de déclaration, le cycle de vie d’un rendu — n’est pas documentée dans les sources publiques accessibles à ce jour. Ce que nous savons avec certitude, c’est l’existence de la couche Apps dans la documentation officielle et son positionnement (« des applications interactives qui s’exécutent à l’intérieur des clients IA »). Le reste — noms de types de ressources, schémas JSON, sémantique des événements — relève de l’inférence raisonnée à partir de ce que MCP impose déjà et de ce qu’une couche UI exige structurellement. Nous le signalerons à chaque fois que nécessaire.

---

Du tool call au formulaire : ce qui bloque quand un agent ne peut que parler

Prenons un cas concret, celui qui revient dans toutes les équipes qui ont mis un agent en production. Un utilisateur demande à son assistant de « préparer une note de frais pour le déjeuner client d’hier ». L’agent dispose d’un outil create_expense_report. Que se passe-t-il ?

L’agent génère un appel d’outil avec des paramètres partiels. L’hôte exécute. Le serveur répond qu’il manque le montant, la devise, le client associé et le justificatif. L’agent reformule une question en langage naturel. L’utilisateur répond « 87 euros ». L’agent rappelle l’outil. Le serveur signale que le client n’est pas dans la liste. L’agent demande lequel. L’utilisateur répond. Etc.

Chaque aller-retour coûte des tokens, ajoute de la latence et dégrade l’expérience. Les chiffres du magazine sont éloquents : un agent local en boucle agentique prend 800 ms par appel d’outil, ce qui porte à plus de 6 secondes le délai avant réponse pour huit appels séquentiels. Une boucle d’erreur mal gérée peut consommer 4 000 tokens à elle seule. Un agent non optimisé coûte environ 200 dollars par mois, contre 29 à 50 dollars pour un agent correctement architecturé — un facteur de 4 à 7. Et le seuil de casse en production est brutal : le passage de 12 à 13 outils déclarés suffit à faire dérailler un agent.

Le problème n’est pas seulement le coût. C’est l’UX. Demander à un utilisateur de décrire en langage naturel un tableau de 15 lignes de dépenses qu’il veut corriger est une absurdité. Lui demander de sélectionner trois éléments dans une liste de 200 fournisseurs, encore plus. Les cas bloquants sont bien identifiés : saisie de dépenses multi-champs, configuration de déploiement avec paramètres interdépendants, édition de règles métier avec conditions et exceptions. Dans tous ces cas, l’agent ne peut que parler, et l’utilisateur ne peut que taper.

Les alternatives écartées méritent d’être rappelées, car elles expliquent les choix de conception. Le HTML générique — l’agent produit une page web que l’hôte affiche — pose un problème d’exécution : qui rend le HTML ? Avec quel accès au DOM ? Comment garantir qu’un serveur MCP malveillant ne dépose pas un script qui lit les cookies de session de l’hôte ? Les iframes non sandboxées aggravent le problème. Les protocoles UI tiers, apparus dans l’écosystème MCP avant la standardisation, n’offraient aucune garantie de portabilité entre clients. La couche Apps répond à ces trois échecs en proposant un modèle déclaratif, sandboxé et négocié au handshake.

---

Anatomie de l’extension Apps : ressources, schémas de déclaration et cycle de vie d’un rendu

Faute de spécification publique détaillée, il faut raisonner par ce que MCP impose déjà. Le protocole repose sur trois primitives : les outils (actions), les ressources (données) et les prompts (gabarits). Une extension UI ne peut s’insérer que dans le second registre — les ressources — ou introduire un quatrième type. La documentation officielle parle d’« applications interactives qui s’exécutent à l’intérieur des clients IA », ce qui suggère fortement un nouveau type de ressource, distinct des ressources textuelles actuelles.

L’hypothèse la plus cohérente avec l’architecture MCP existante est celle d’une ressource de type « vue » ou « app », déclarée par le serveur avec un schéma qui décrit les composants à afficher. Un formulaire, un tableau, une visualisation. Le serveur ne dit pas « dessine un bouton rouge à telle coordonnée » — ce serait impératif et non portable. Il dit « voici un formulaire à trois champs, le premier est une liste déroulante alimentée par cet outil, le deuxième est un montant en euros, le troisième est une date ». L’hôte décide comment rendre cela dans son propre langage visuel.

Le cycle de vie, lui, suit nécessairement le modèle de négociation de capacités qui existe déjà dans MCP. Au handshake, le client annonce les extensions qu’il supporte. Un serveur MCP App ne peut pas supposer que son interlocuteur sait rendre des formulaires ; il doit vérifier. Si le client ne supporte pas l’extension Apps, le serveur doit proposer un fallback — typiquement, un outil classique qui renvoie du texte structuré. C’est cette négociation qui rend le multi-hôtes possible.

Le choix déclaratif vs impératif est le point de conception le plus lourd. Un modèle déclaratif — le serveur décrit ce qu’il veut montrer, l’hôte décide comment — garantit la portabilité entre Claude Desktop, ChatGPT, VS Code, Cursor et les agents custom. Un modèle impératif — le serveur envoie du code à exécuter — garantit la flexibilité mais casse la portabilité et ouvre la porte à tous les abus. La documentation officielle, en listant cinq clients hétérogènes, rend le choix déclaratif presque obligatoire.

Les exemples canoniques fournis par l’extension — dont on sait qu’ils existent sans en connaître le détail — relèvent probablement des patterns classiques : tableau de bord de métriques, formulaire de configuration, sélecteur dans une liste. Ce qu’ils révèlent, c’est que la couche Apps n’est pas un moteur de rendu généraliste. C’est un vocabulaire borné de composants, chacun avec une sémantique précise et des contraintes de sécurité associées.

---

Qui rend quoi : client, hôte, serveur — la répartition des rôles qui change tout

C’est ici que les praticiens se perdent. Trois acteurs, trois rôles, et une confusion fréquente entre « client » et « hôte ».

Le serveur MCP App détient la logique métier et l’état persistant. Il déclare des outils et des vues. Il ne sait pas comment son formulaire sera rendu, ni même s’il sera rendu.

Le client est l’application qui se connecte au serveur — Claude Desktop, ChatGPT, VS Code, Cursor, un agent custom. Il gère la connexion, l’authentification, l’exécution des outils.

L’hôte est la couche qui, à l’intérieur du client, décide du rendu. C’est lui qui interprète le schéma de vue, choisit les composants natifs ou sandboxés, applique les politiques de sécurité. Dans Claude Desktop, l’hôte est l’application elle-même. Dans un agent custom, c’est le framework qui pilote le LLM.

Où vit l’état ? C’est la question qui détermine tout. Si l’état vit côté serveur — l’utilisateur remplit un formulaire, chaque modification déclenche un événement vers le serveur, le serveur renvoie l’état mis à jour — la latence devient rédhibitoire pour une saisie fluide. Si l’état vit côté hôte — le formulaire est rendu localement, l’état reste dans le client jusqu’à validation — la réactivité est bonne mais le serveur perd la main sur la validation en temps réel. La troisième option, un état partagé synchronisé par événements, offre le meilleur des deux mondes au prix d’une complexité de protocole.

Le pattern recommandé, dans la logique de MCP, est vraisemblablement un état local côté hôte avec des événements de synchronisation ponctuels : à l’ouverture, à la validation, à la fermeture. Pas à chaque frappe. C’est le seul moyen de tenir la latence tout en gardant le serveur comme source de vérité métier.

Pour une équipe qui veut écrire un serveur MCP App une fois et le voir fonctionner partout, la conséquence est claire : il faut accepter que le rendu ne sera jamais identique d’un hôte à l’autre. Un tableau de 20 colonnes s’affichera confortablement dans un IDE, mal dans un chat. Un formulaire à dix champs sera naturel dans une app desktop, pénible dans une interface mobile. Le serveur doit déclarer des vues qui tolèrent cette variabilité — des vues minimales, avec des contraintes souples, et un fallback texte systématique.

Les anti-patterns documentés, dans l’écosystème MCP plus largement, sont connus : ignorer la négociation de capacités et supposer que l’hôte sait tout rendre ; dupliquer la logique métier entre l’outil et la vue, ce qui garantit la divergence à la première évolution ; exposer des données sensibles dans le rendu sans contrôle d’accès côté hôte ; surcharger la vue au point qu’elle devient plus coûteuse à maintenir que le texte qu’elle remplace.

---

La surface d’attaque s’élargit : sécurité, sandboxing et confiance dans un serveur qui vous dessine une interface

C’est le chapitre que les équipes produit sautent trop souvent. Un serveur MCP qui ne faisait qu’exposer des outils présentait déjà un risque : exécution d’actions non désirées. Un serveur MCP App ajoute trois couches.

Première couche : le rendu lui-même. Si l’hôte rend le schéma sans sandboxing strict, un serveur malveillant peut présenter une interface qui ressemble à celle du client légitime — un formulaire de connexion, une demande de confirmation de mot de passe, un bouton « autoriser l’accès ». C’est du phishing par interface légitime, et c’est redoutablement efficace parce que l’utilisateur fait confiance à son client.

Deuxième couche : l’injection de contenu dans les visualisations. Un tableau qui affiche des données provenant d’une source externe peut contenir du texte formaté pour ressembler à une instruction. Si l’hôte ne distingue pas le contenu de données du contenu d’interface, il peut exécuter des actions que l’utilisateur n’a jamais demandées.

Troisième couche : la captation de saisie. Un formulaire qui demande plus que ce qu’il prétend demander — un champ « nom » qui capture en réalité l’email professionnel pour l’exfiltrer — est trivial à construire. La validation côté hôte des schémas déclarés devient critique.

Ce que la spec impose, dans la logique MCP : sandboxing des rendus, isolation des origines, validation des schémas côté hôte, permissions granulaires par vue. Ce qu’elle laisse à la charge de l’hôte : la politique de confiance vis-à-vis des serveurs tiers, l’affichage des avertissements, la révocation des permissions. Ce qui reste ouvert : comment un utilisateur distingue une interface rendue par son client d’une interface rendue par un serveur MCP ? Comment un hôte signale-t-il qu’une vue provient d’un serveur non vérifié ? Comment gérer la révocation d’une permission accordée il y a six mois ?

Les chiffres du magazine sur la sécurité des agents donnent le vertige. L’agence britannique AISI a documenté 19 actions non autorisées exécutées par des agents lors de tests en août 2026. Un article de septembre 2026 sur les pipelines LLM et MCP parle de « la surface d’attaque que personne ne surveille ». Un agent de support client non surveillé échoue sur plus de 30 % des tâches après trois semaines d’exploitation. Ajouter une couche UI à ce tableau ne rend pas les choses plus sûres — cela déplace le risque vers l’utilisateur final, qui voit une interface et croit ce qu’elle dit.

La règle pratique : un serveur MCP App doit être traité avec le même niveau de méfiance qu’un site web tiers. L’hôte doit afficher sa provenance, sandboxer son rendu, valider ses schémas, et permettre à l’utilisateur de voir ce qui se passe sous le capot. Ce n’est pas un détail d’implémentation, c’est la condition de possibilité de la confiance.

---

Quand ça vaut le coup : arbre de décision entre tool call + texte et MCP App

Le cœur pratique. Toutes les interactions ne méritent pas une interface. Voici les critères qui permettent de trancher.

Critère 1 — Complexité de la saisie. Un champ unique, une valeur simple, un choix binaire : le tool call avec génération de texte est optimal. Trois champs interdépendants, une sélection dans une liste de plus de dix éléments, une saisie avec validation immédiate : l’interface se justifie.

Critère 2 — Besoin de validation immédiate. Si l’utilisateur doit voir le résultat de sa saisie avant de valider — un aperçu de configuration, un calcul de coût, une vérification de format — l’interface est indispensable. Un aller-retour texte prend 800 ms minimum par appel, et souvent plusieurs.

Critère 3 — Fréquence d’usage. Une action faite une fois par mois ne justifie pas une interface à maintenir. Une action faite dix fois par jour, oui.

Critère 4 — Nombre d’hôtes ciblés. Un serveur destiné à un seul client (votre propre agent custom) peut se permettre des raccourcis. Un serveur destiné à Claude, ChatGPT, VS Code et Cursor doit accepter la variabilité du rendu et prévoir un fallback systématique.

Critère 5 — Budget tokens. Un formulaire rendu consomme zéro token de génération. Un aller-retour texte en consomme plusieurs centaines, voire milliers en cas d’erreur. Sur un usage fréquent, l’économie est massive.

Critère 6 — Coût de maintenance. Une vue déclarative se maintient comme un schéma. Un outil texte se maintient comme une fonction. Si votre vue est plus complexe que votre outil, vous avez probablement surdimensionné.

L’arbre de décision, en pratique :

• L’action est-elle unique et la réponse courte ? → Tool call + texte.
• La saisie fait-elle moins de trois champs sans validation croisée ? → Tool call + texte, éventuellement avec une ressource statique pour le contexte.
• La saisie est-elle multi-champs avec validation immédiate ? → MCP App.
• L’utilisateur doit-il sélectionner dans un tableau ou visualiser des données ? → MCP App.
• L’action est-elle rare (moins d’une fois par semaine) ? → Tool call + texte, sauf si l’UX est critique.
• Le serveur cible-t-il plusieurs hôtes hétérogènes ? → MCP App avec fallback texte obligatoire.
• Le budget tokens est-il contraint ? → MCP App si l’usage est fréquent, sinon tool call.

Les cas où l’UI ajoute de la valeur : tableau de bord de métriques, configuration de déploiement, édition de règles avec conditions, sélection dans un catalogue, prévisualisation de rendu. Les cas où elle ajoute de la friction : action unique (« envoie cet email »), réponse courte (« quel est le statut ? »), action rare et non critique.

---

Patterns concrets pour un serveur MCP App multi-hôtes : ce qui marche, ce qui casse

Voici ce que l’expérience des serveurs MCP en production enseigne, transposé à la couche Apps.

Ce qui marche :

Structurer le serveur en deux registres clairement séparés — les outils (logique métier) et les vues (présentation). Un outil create_deployment et une vue deployment_config_form qui appelle cet outil à la validation. Pas de duplication de la logique de validation entre les deux ; la vue valide le format, l’outil valide le métier.

Gérer les capacités hétérogènes par un fallback systématique. Si le client n’annonce pas le support de l’extension Apps au handshake, le serveur expose l’outil en mode texte. L’utilisateur ne voit pas de différence fonctionnelle, seulement une UX dégradée.

Versionner les schémas d’UI comme on versionne une API. Un changement de schéma de vue casse les hôtes qui l’ont implémenté. Déclarer une version, maintenir la précédente pendant une période de transition.

Tester avec plusieurs hôtes de référence. MCPJam est cité par la documentation officielle comme client de test. Claude Desktop, VS Code, Cursor sont les autres cibles. Un serveur qui ne fonctionne que dans un seul hôte n’est pas un serveur MCP App, c’est un serveur propriétaire déguisé.

Ce qui casse :

Surcharger la vue. Un formulaire à quinze champs avec des dépendances conditionnelles complexes sera pénible partout et impossible à maintenir. Découper en étapes.

Dupliquer la logique métier entre l’outil et l’interface. La première évolution métier fera diverger les deux, et l’utilisateur verra une validation côté interface qui ne correspond plus à celle côté serveur.

Ignorer la négociation de capacités. Supposer que l’hôte sait rendre un tableau, puis s’étonner que ChatGPT affiche du texte brut. Le handshake existe pour une raison.

Exposer des données sensibles dans le rendu. Un tableau qui affiche des données utilisateur sans contrôle d’accès côté hôte est une fuite en puissance. Le serveur doit filtrer ce qu’il envoie, l’hôte doit filtrer ce qu’il rend.

Négliger la latence. Un événement de synchronisation à chaque frappe dans un champ texte, c’est 800 ms de latence par caractère. Préférer une synchronisation à la validation.

Bonnes pratiques de cache. Les vues déclaratives sont des schémas, donc cachables. Un hôte qui a déjà rendu une vue peut la conserver en mémoire et ne recharger que les données. Le serveur doit exposer des vues stables et des données volatiles séparément.

---

Ce que MCP Apps change pour l’écosystème : vers des agents qui manipulent des artefacts, pas seulement des mots

Le déplacement est plus profond qu’il n’y paraît. MCP était un protocole de fonctions. Il devient un protocole d’interfaces. Ce n’est pas la même chose.

Pour les éditeurs de clients, la conséquence est immédiate : il faut implémenter le rendu des vues, avec toutes les garanties de sécurité que cela implique. Les clients qui ne le font pas resteront des clients de seconde classe, capables d’appeler des outils mais pas de les présenter. La fragmentation des capacités entre hôtes est le risque principal — un serveur qui fonctionne parfaitement dans Claude Desktop peut être inutilisable dans un agent custom qui n’a pas implémenté la couche Apps.

Pour les fournisseurs de serveurs, la valeur se déplace. Un serveur qui n’exposait que des outils exposera désormais des expériences. La qualité du rendu devient un critère de choix, au même titre que la qualité de l’API. Les serveurs qui offrent des vues soignées — formulaires clairs, tableaux lisibles, visualisations utiles — prendront l’avantage sur ceux qui renvoient du JSON brut.

Pour les équipes produit, la question n’est plus « faut-il adopter MCP ? » mais « quelles parties de notre produit méritent une interface dans l’agent ? ». La réponse n’est pas « toutes ». C’est un exercice de priorisation : quelles actions gagnent à être présentées visuellement, lesquelles gagnent à rester textuelles.

La comparaison avec les autres approches éclaire le choix. L’UI générative — l’agent produit du HTML à la volée — est flexible mais ingérable en sécurité. Les artefacts — des documents structurés que l’agent manipule — sont proches dans l’esprit mais moins interactifs. Les canvas — des espaces de travail partagés — sont plus lourds. MCP Apps occupe un créneau précis : l’interface déclarative, sandboxée, négociée, portable.

Les enjeux de standardisation au sein de l’Agentic AI Foundation sont considérables. La couche Apps est aujourd’hui documentée par une seule famille de sources — le site officiel. Aucune source tierce indépendante ne décrit son contenu technique. C’est un signe que la standardisation est récente, et que la prochaine version de la spec devra trancher des questions ouvertes : comment garantir la portabilité des vues entre hôtes ? Comment gérer les permissions granulaires ? Comment prévenir le phishing par interface ? Comment versionner les schémas sans casser les hôtes existants ?

Ce que les équipes doivent anticiper dès maintenant : considérer la couche Apps comme une option, pas une obligation. Construire des serveurs MCP qui fonctionnent en mode texte, avec une couche Apps optionnelle. Prévoir le fallback dès la conception. Tester avec plusieurs hôtes. Et surtout, ne pas confondre interface et sécurité — une belle vue n’est pas une vue sûre.

L’ironie de l’histoire, c’est que MCP a été créé pour résoudre le problème N×M des intégrations. La couche Apps risque de recréer un problème N×M au niveau du rendu : N schémas de vues, M hôtes qui les interprètent différemment. La standardisation devra être à la hauteur de l’ambition initiale, sinon nous aurons remplacé un maquis par un autre.

---

Sources

• What is the Model Context Protocol (MCP)? — documentation officielle, version 2026-07-28
• Model Context Protocol — Wikipédia (EN)
• Model Context Protocol (MCP) — GeeksforGeeks
• Grand modèle de langage — Wikipédia (FR)
• Dépôt GitHub modelcontextprotocol
• What Is MCP? The Model Context Protocol Explained (2026) — The AI Rankings, 4 octobre 2026
• MCP Events Complete the Agent Communication Model — Forkast, 29 septembre 2026
• Safari 27 Ships a Native MCP Server — Forkast, 20 septembre 2026
• LLM pipelines et MCP : la surface d’attaque que personne ne surveille — Ayinedjimi Consultants, 19 septembre 2026
• Meilleurs frameworks d’agents open source pour LLM locaux en 2026 — lefilia.fr, 18 septembre 2026
• Qu’est-ce que le tool calling, et en quoi diffère-t-il du function calling ? — bird.com, 8 septembre 2026
• MCP Webflow : comment les IA lisent et modifient un site — agence-synqro.fr, 7 septembre 2026
• Safari MCP : ce que l’accès du navigateur change pour les agents de développement — blog.pascal-mietlicki.fr, 4 septembre 2026
• Modèles IA 2026 : GPT-6, Claude Opus 5, Gemini, Grok — studeria.fr, 4 septembre 2026
• Maxon встроила MCP-сервер для ИИ-ассистентов в Cinema 4D — render.ru, 30 septembre 2026
• OpenAI Agents API 2026 : comment un agent IA appelle-t-il des outils ? — jsonsort.com, 20 septembre 2026
• IA : les meilleurs modèles pour le code et le développement web en octobre 2026 — blogdumoderateur.com, 5 octobre 2026