MCP un an après : registries, confiance et commerce agentique

Anthropic a rendu public Model Context Protocol en novembre 2024. Un an plus tard, MCP revendique 97 millions de téléchargements mensuels de SDK, plus de 10 000 serveurs publics et un support de première classe dans ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot et VS Code. En décembre 2025, Anthropic a donné la spécification à l’Agentic AI Foundation, fonds dirigé sous la Linux Foundation, co-fondé avec Block et OpenAI [Source : Anthropic].

La question intéressante n’est plus « est-ce que MCP va tenir ». Elle est devenue : comment un service non-géant fait-il pour être trouvé, consulté, fiabilisé et — pour le e-commerce — acheté par un agent LLM ?

Cet article regarde ce qui bouge vraiment début 2026 : les registries, les mécanismes de confiance, les protocoles de commerce agentique (ACP, UCP) qui utilisent MCP comme transport, et ce qui est concrètement disponible pour une PME qui veut apparaître dans ChatGPT Instant Checkout ou dans Gemini AI Mode.

1. Rappel : ce qu’est un serveur MCP

Un serveur MCP expose des outils, des ressources et des prompts à un client LLM via JSON-RPC. Le client découvre les capacités à la connexion (tools/list, resources/list), puis appelle à la demande. MCP normalise la conversation agent ↔ service pour que n’importe quel client (Claude, ChatGPT, Cursor…) puisse parler à n’importe quel serveur sans adaptateur propriétaire.

Deux transports sont officiels : stdio (process local) et Streamable HTTP (distant, production). Le premier fait fonctionner les serveurs locaux d’outil dev ; le second est ce qui rend MCP viable pour les services publics multi-tenants — c’est sur celui-ci que porte la quasi-totalité de cet article.

Le principe : plus besoin d’écrire N×M intégrations entre N clients LLM et M services. Un serveur MCP par service suffit.

2. L’état de l’écosystème début 2026

Trois catégories dominent, selon une analyse de Context Studios et confirmée par les chiffres publics :

Catégorie	Volume	Exemples	Enjeu
Serveurs internes	Majoritaire, non-comptabilisé	CRM, datawarehouse, RH, runbooks	ROI rapide, hors radar public
Serveurs vendor officiels	~quelques centaines	GitHub, Stripe, PayPal, Atlassian, Salesforce, Shopify	Qualité, auth, support
Serveurs communautaires	10 000+	Outils devs, scrapers, adaptateurs	Qualité hétérogène, sécurité

Shopify a déployé des endpoints MCP par défaut sur ses 5,6 millions de boutiques, Stripe a publié son serveur officiel, PayPal a sorti le premier serveur MCP distant d’un acteur paiement grand public [Source : Shopify Engineering — Winter ‘26].

Prédiction Gartner reprise par plusieurs analyses : 40 % des applications d’entreprise embarqueront des agents spécifiques fin 2026, contre moins de 5 % en 2025 [Source : CData — 2026: The Year for Enterprise-Ready MCP Adoption].

3. Registries : comment on trouve un serveur MCP

3.1 Le Registry officiel : une métaregistry, pas un app store

Le Registry officiel (registry.modelcontextprotocol.io) est en API freeze v0.1 depuis octobre 2025. Il est délibérément minimal : pas de moteur de recherche, pas de catégories, pas d’UI de navigation. C’est une métaregistry — une source canonique de métadonnées pour les serveurs MCP, backée par Anthropic, GitHub, PulseMCP et Microsoft [Source : MCP Registry Preview].

Concrètement :

Elle stocke des métadonnées auto-déclarées : nom, description, URL, transport, auteur, version.
Elle ne contient pas le code ni les binaires — ceux-ci restent sur npm, PyPI, Docker Hub.
Les sous-registres sont encouragés à consommer cette source via une OpenAPI publique pour construire leurs UIs propres.
Modération communautaire pour le spam, malware, usurpation d’identité.

┌──────────────────────────────┐
│  Registry officiel (métadata) │
│  registry.modelcontextprotocol.io │
└──────────────┬───────────────┘
               │ consomme
     ┌─────────┼──────────┬──────────┐
     ▼         ▼          ▼          ▼
 Smithery   Glama    MCPMarket   Sub-registry
 (UI)      (preview) (web dir)   privée d'entreprise

3.2 Les sub-registries : UI, curation, marketplaces

L’UI, la curation, les catégories, les flux d’installation se font dans les sub-registries. Les principaux :

Registry	Scale	Spécificité	URL
Smithery	7 000+	CLI locale + hébergement remote, OAuth	smithery.ai
Glama	Preview	Metaregistry miroir, base pour sub-registries privées	glama.ai
MCP Market	10 000+ sur 23+ catégories	Directory web, filtrage, featured	mcpmarket.com
MCP.so	19 000+	Plus gros volume, peu de vérification	mcp.so
PulseMCP	—	Co-mainteneur du Registry officiel, focus qualité	pulsemcp.com
TrueFoundry	—	Enterprise : RBAC, audit, virtual MCP servers	truefoundry.com

Source : TrueFoundry — Best MCP Registries in 2026.

3.3 Auto-découvrabilité par HTTP : `.well-known`

Le Registry est pull-based : un client doit savoir où chercher. Le pendant push-based est en cours de standardisation : MCP Server Cards via une URL .well-known, tracés dans SEP-1649 et SEP-2127 [Source : SEP-1649].

L’idée est simple. Un serveur expose, à une URL canonique, un document JSON décrivant ses capacités, ses transports, son authentification, sa version de protocole — sans qu’un client ait besoin d’établir de connexion. Des crawlers, des registries et des navigateurs peuvent indexer.

Deux propositions concurrentes cohabitent début 2026 :

GET /.well-known/mcp/server-card.json     # SEP-1649
GET /.well-known/mcp                       # SEP-1960 (manifest)

La roadmap officielle MCP met les Server Cards en priorité 1 pour 2026, sous la responsabilité du Server Card Working Group [Source : Roadmap MCP].

Côté IETF, un draft draft-serra-mcp-discovery-uri propose un schéma d’URI mcp:// et un mécanisme DNS pour la découverte au-delà du HTTP [Source : IETF draft].

Exemple : `/.well-known/mcp/server-card.json` (SEP-1649)

Document statique servi en HTTPS, CORS ouvert obligatoire pour permettre l’indexation cross-origin :

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/mcp-server-card/v1.json",
  "version": "1.0",
  "protocolVersion": "2025-06-18",
  "serverInfo": {
    "name": "example-mcp-server",
    "title": "Example MCP Server",
    "version": "1.2.0"
  },
  "description": "Serveur MCP d'exemple pour la documentation",
  "iconUrl": "https://example.com/icon.png",
  "documentationUrl": "https://example.com/docs",
  "transport": {
    "type": "streamable-http",
    "endpoint": "/mcp"
  },
  "capabilities": {
    "tools": { "listChanged": true },
    "prompts": { "listChanged": true },
    "resources": { "subscribe": true, "listChanged": true }
  },
  "authentication": {
    "required": true,
    "schemes": ["bearer", "oauth2"]
  },
  "tools": "dynamic",
  "resources": "dynamic",
  "prompts": "dynamic"
}

Champs notables :

transport.type : streamable-http (production) ou stdio (local).
capabilities.*.listChanged : le serveur émet des notifications quand sa liste change — utile pour les clients qui veulent éviter le re-polling.
tools / resources / prompts : la valeur "dynamic" indique que la liste change selon le contexte et doit être obtenue par l’appel tools/list à chaud. Une PME qui expose un catalogue figé peut au contraire mettre un tableau statique pour permettre l’indexation sans connexion.
authentication.schemes : bearer, oauth2, ou les deux. Couplé à la spec d’autorisation (section 5.3), un client compatible négocie automatiquement.

Source : SEP-1649 — MCP Server Cards.

Exemple : `/.well-known/ucp` (commerce)

Le commerce a sa propre version : UCP expose /.well-known/ucp pour publier les capacités d’un marchand. Structure différente — on déclare des services (le contrat global) et des capabilities (les fonctions activées) [Source : Google — UCP Profile] :

{
  "ucp": {
    "version": "2026-01-23",
    "services": {
      "dev.ucp.shopping": [
        {
          "version": "2026-01-23",
          "spec": "https://ucp.dev/specification/overview",
          "transport": "rest",
          "endpoint": "https://boutique.example.fr/ucp/v1",
          "schema": "https://ucp.dev/2026-01-23/services/shopping/openapi.json"
        }
      ]
    },
    "capabilities": {
      "dev.ucp.shopping.checkout": [
        {
          "version": "2026-01-23",
          "spec": "https://ucp.dev/specification/checkout",
          "schema": "https://ucp.dev/2026-01-23/schemas/shopping/checkout.json"
        }
      ],
      "dev.ucp.shopping.fulfillment": [
        {
          "version": "2026-01-23",
          "spec": "https://ucp.dev/specification/fulfillment",
          "schema": "https://ucp.dev/2026-01-23/schemas/shopping/fulfillment.json",
          "extends": "dev.ucp.shopping.checkout"
        }
      ]
    }
  }
}

Points clés :

Le namespace reverse-DNS (dev.ucp.shopping.checkout, com.loyaltyprovider.points) permet d’étendre sans comité central — n’importe qui peut publier une capability sous son propre domaine.
transport peut valoir rest, mcp, a2a ou embedded — le marchand choisit selon son infra. Un serveur MCP existant peut être déclaré comme transport UCP en changeant uniquement cette ligne.
extends exprime une dépendance entre capabilities : fulfillment n’a de sens que si checkout est également supporté.
Les couples version + schema sont versionnés indépendamment par capability — un marchand peut adopter une nouvelle version de checkout sans toucher à fulfillment.

L’agent qui consomme ce manifeste calcule l’intersection entre ce qu’il sait faire et ce que le marchand déclare, puis routes ses appels en conséquence. C’est ce qui rend UCP extensible sans casser les agents anciens.

4. Comment se faire connaître

4.1 Publier sur le Registry officiel

C’est la première brique. Le Registry officiel accepte via GitHub Actions ou CLI, avec validation de la propriété du domaine et attestation d’identité. La publication alimente automatiquement toutes les sub-registries qui consomment l’OpenAPI amont.

4.2 Exposer un Server Card

Tant que les SEPs ne sont pas merged, c’est un pari stratégique : implémenter les deux. Le coût est faible (un endpoint JSON statique), le bénéfice est que les clients compatibles et les crawlers (Replicate a activé l’auto-discovery en février 2026 — changelog) n’ont plus besoin de configuration manuelle.

4.3 Être indexé dans les sub-registries qui comptent

Smithery, MCPMarket et MCP.so font la distribution visible aux développeurs ; PulseMCP fait la curation qualité ; les marketplaces de clients (Claude Desktop, ChatGPT Apps, VS Code extensions) font la distribution aux utilisateurs finaux. Chaque canal a son process d’inscription.

4.4 SEO agentique

Concept émergent, label incertain — on voit passer « AEO », « ASO », « agentic SEO ». La thèse : la découvrabilité par agent dépend moins du PageRank et plus de la structure des données exposées.

Une étude Data.world citée par Nudge indique que la précision de réponse de GPT-4 passe de 16 % à 54 % sur des contenus structurés versus non-structurés, et que les contenus correctement balisés sont sélectionnés 73 % plus souvent [Source : Nudge — Product Data Enrichment for AI Discoverability].

En pratique, pour un service qui veut être appelé par un agent :

Descriptions d’outils en langage naturel (pas juste des noms abrégés).
Schémas d’entrée typés, strictement validés.
Exemples concrets dans la description de l’outil.
Métadonnées de capabilities complètes (catégorie, tags, version).

5. Le problème de confiance

5.1 Les attaques propres à MCP

Le Cloud Security Alliance a publié fin mars 2026 une analyse frontale : « every single server permitted unauthenticated access to internal tool listings » sur les instances exposées auditées par Knostic [Source : CSA — The Agentic Trust Deficit].

Trois classes d’attaques sont documentées :

Tool poisoning : instructions malicieuses dans la description d’un outil — invisibles pour l’humain, lues par le LLM.
Rug pull : un serveur modifie ses définitions après vetting initial. Ce qui était approuvé devient vecteur d’attaque.
Cross-server contamination : avec plusieurs serveurs branchés simultanément, un malveillant peut rediriger des credentials vers un autre serveur légitime.

Deux CVE de référence :

EchoLeak (CVE-2025-32711) : zero-click, instructions malveillantes cachées dans métadonnées de documents, exfiltration lors du traitement par l’agent.
mcp-remote (CVE-2025-6514) : command injection côté client.

Qualys rajoute l’angle shadow-IT : 53 % des serveurs s’appuient sur des secrets statiques, difficiles à rotate et souvent sur-scopés [Source : Qualys — MCP Servers: The New Shadow IT].

5.2 Les réponses : signer et attester

L’approche qui émerge repose sur de la crypto, pas sur de la réputation :

Sigstore : signatures courte durée liées à une identité (GitHub, etc.), sans gestion de clés longue durée.
GitHub Attestations : provenance build — quel code source, quel workflow, quand, où. Format sujet (artefact) + prédicat (claims).
SBOM pour tout le code serveur, vérifié avant déploiement.

ToolHive propose un modèle à trois niveaux : disabled (dev), warn (default), enabled (prod, échec si signature invalide). La validation matche container ↔ repo ↔ workflow ↔ signataire attendu [Source : Stacklok — Solving the MCP Server Trust Problem].

L’idée clé : la crypto remplace la promesse. Un « rug pull » devient détectable parce qu’une mutation de schéma produit un hash différent, qui invalide l’attestation précédente et force une re-authorisation.

5.3 La spec d’autorisation 2026 : OAuth 2.1 + DCR + PRM

La spécification d’autorisation MCP 2026 est une réponse directe au vide initial. Elle est construite sur :

OAuth 2.1 avec PKCE obligatoire pour tous les clients.
Resource Indicators (RFC 8707) : tokens audience-restreints, inutilisables ailleurs que sur le serveur cible.
Protected Resource Metadata (RFC 9728) : découverte automatique des métadonnées d’autorisation côté serveur.
Dynamic Client Registration (DCR) obligatoire côté serveur d’autorisation — un client MCP peut s’enregistrer automatiquement en envoyant nom et redirect URI.
Scopes incrémentaux : demande uniquement du scope nécessaire pour l’opération en cours.

Source : dasroot — The New MCP Authorization Specification.

Deux SEPs en cours vont plus loin : SEP-1932 (DPoP) pour lier les tokens au client, SEP-1933 (Workload Identity Federation) pour des environnements serveur-à-serveur sans secret statique [Source : Roadmap].

5.4 Gateway et proxy comme couche de sécurité

Plutôt que de faire confiance au serveur lui-même, un pattern qui monte : un gateway entre le client et le serveur, avec :

Authentification gérée à l’extérieur.
Audit complet des appels.
Rate-limiting et validation de schéma.
Isolation réseau (le serveur ne reçoit pas d’internet direct).

C’est la position de Kong, Moesif, Zuplo, TrueFoundry et ToolHive. L’Enterprise WG de MCP doit produire une spec de comportement pour gateway en 2026 — jusque-là, chaque éditeur fait à sa sauce [Source : Roadmap].

6. MCP restera-t-il cantonné aux outils devs ?

Non, la bascule a déjà eu lieu. Trois indices :

6.1 La diversité des secteurs d’adoption

Au-delà du dev, on voit en 2026 :

Commerce : Shopify (5,6M boutiques), Stripe, PayPal, Etsy, Target, Walmart, Wayfair via UCP.
CRM / Productivité : Salesforce, HubSpot, Atlassian, Microsoft 365, Notion.
Données / Analytics : Snowflake, Databricks, BigQuery.
Santé, finance, manufacturing : cités par CData comme moteurs du marché, avec estimation $1,8 Md en 2025 [Source : CData].
Juridique FR : OpenLegi expose Légifrance et jurisprudence en MCP.
Admin ERP PME : Microsoft Dynamics 365 Business Central a un serveur MCP sur son centre d’administration [Source : Microsoft Learn].

6.2 MCP Apps : au-delà des appels d’outil

En janvier 2026, l’extension MCP Apps a introduit des composants UI interactifs — tableaux de bord, formulaires, graphiques — qui s’affichent dans la conversation elle-même. MCP sort du cadre « exécute une commande, réponds un JSON » pour aller vers des interactions riches [Source : Medium — The Rise of MCP].

6.3 Les chiffres

11× de croissance des commandes pilotées par agent entre janvier 2025 et mars 2026, versus 7× pour le trafic de référencement AI [Source : Nudge].
97M de téléchargements SDK/mois, 10k+ serveurs publics.
Moins de 5 % des 11 000+ serveurs existants sont monétisés [Source : Medium — MCP Servers Are the New SaaS] — la fenêtre reste ouverte pour les nouveaux entrants.

La réponse opérationnelle à la question : MCP est sorti du dev-tool, mais la distribution économique reste à inventer. On verra pourquoi dans les sections suivantes.

7. Commerce agentique : ACP, UCP, x402

7.1 ACP — Agentic Commerce Protocol

Qui : OpenAI + Stripe. Standard ouvert, en bêta début 2026. Quoi : protocole REST pour checkout initié par un agent, avec partage sécurisé de credentials de paiement. Comment ça marche :

┌────────┐  sélection  ┌──────────┐  checkout  ┌──────────┐
│ Acheteur│──────────▶│ Agent IA │──────────▶│ Marchand │
└────────┘            └──────────┘            └────┬─────┘
                                                    │
                                       ┌────────────▼────────────┐
                                       │  Payment Provider       │
                                       │  (tokenisation credentials)│
                                       └─────────────────────────┘

Le marchand reste le merchant of record : il choisit d’accepter ou refuser, il traite la transaction, il livre.

Intégration : « update as little as one line of code » pour un marchand déjà sur Stripe. ACP peut être implémenté comme API REST ou comme serveur MCP [Source : Stripe — Developing an open standard for agentic commerce].

Déjà live : ChatGPT Instant Checkout pour les vendeurs Etsy et Shopify [Source : Stripe Newsroom].

7.2 UCP — Universal Commerce Protocol

Qui : Google + Shopify, annoncé au NRF 2026. Soutenu par Etsy, Wayfair, Target, Walmart + 20 autres retailers. Quoi : standard ouvert, architecture en couches (Service & Capability, Discovery, Payment), négociation dynamique. Comment :

┌─ Service & Capability Layer ─┐
│   Checkout, Orders, Catalog  │  ← capacités versionnées indépendamment
│   + Extensions (com.loyalty.points)│
└──────────┬───────────────────┘
           │ publiées via
┌──────────▼───────────────────┐
│   /.well-known/ucp           │  ← manifest JSON
└──────────┬───────────────────┘
           │ consommé par
┌──────────▼───────────────────┐
│  Agent (Gemini, AI Mode...)  │
│  négocie intersection capability │
└──────────────────────────────┘

UCP supporte trois transports : REST, Agent2Agent (A2A), et MCP [Source : Google Developers].

Adoption PME : via Google Merchant Center pour les catalogues US dans un premier temps. Pas de backend custom : la donnée produit existante est réutilisée.

7.3 x402 — micropaiements HTTP-native

Qui : Coinbase Development Platform. Passé sous Linux Foundation le 2 avril 2026 avec Google, AWS, Microsoft, Stripe, Visa, Mastercard, KakaoPay et 20+ membres fondateurs. Quoi : renaissance du code HTTP 402 Payment Required. Si une requête arrive sans paiement, le serveur répond 402, le client (un agent) paie et rejoue. Chiffres : 75M transactions et $24M volume sur 30 jours début avril 2026 [Source : x402.org].

Positionnement : paiements machine-à-machine, en stablecoin, sans compte ni KYC. Pensé pour les agents qui doivent payer des APIs ou des serveurs MCP de façon autonome [Source : Zuplo — Autonomous API & MCP Server Payments with x402].

7.4 Comparatif

Aspect	ACP	UCP	x402
Parrains	OpenAI + Stripe	Google + Shopify	Coinbase + LF
Surface agent	ChatGPT	Gemini, AI Mode	N’importe quel client HTTP
Cible	Checkout merchant	Commerce end-to-end	APIs & serveurs MCP
Transport	REST ou MCP	REST, A2A, MCP	HTTP
Paiement	Cartes via Stripe tokens	Google Pay, Shop Pay, etc.	Stablecoins (USDC)
Statut	Beta, live Etsy/Shopify	Live US, listings Google	LF depuis avril 2026
KYC	Oui (classique)	Oui (classique)	Non

Lecture pragmatique début 2026 : ACP et UCP sont complémentaires plus que concurrents. ACP se branche côté ChatGPT pour conclure un panier ; UCP sert côté Google et laisse le choix du transport. MCP est le transport commun qui les rapproche. x402 vise un usage machine-à-machine distinct (paiement d’API, de crédits de scraping, de calls d’inférence).

8. Comment une PME peut exposer ses produits

Quatre chemins existent, par ordre croissant d’effort :

8.1 Chemin 1 : la plateforme fait tout

La PME qui est déjà sur Shopify, Etsy ou WooCommerce a sa vitrine MCP par défaut ou via plugin. Shopify a déployé son Storefront MCP à toutes les 5,6M boutiques — c’est le scénario majoritaire.

Coût : zéro, la plateforme s’en occupe. Limites : le marchand hérite des choix de la plateforme (catégories, métadonnées, transport, checkout). Quand l’utiliser : par défaut, toujours, si l’e-shop tourne sur une plateforme qui a un MCP natif.

8.2 Chemin 2 : via PSP/orchestrateur agentique

Le marchand qui a déjà Stripe active ACP en ajoutant une ligne de config. PayPal a un MCP remote officiel. Ça donne accès à ChatGPT Instant Checkout sans changer le backend.

Coût : quelques heures dev si la stack est déjà Stripe. Limites : ne marche que pour la partie paiement/checkout. Le catalogue et la découverte restent à gérer séparément.

8.3 Chemin 3 : le serveur MCP maison

Un marchand qui veut garder la maîtrise expose son propre serveur MCP avec ses outils métier : search_products, get_product, create_cart, complete_checkout. L’exemple de Shopify Storefront MCP est un patron standardisé : 5 outils — create_checkout, get_checkout, update_checkout, complete_checkout, cancel_checkout — compatibles UCP.

Coût : Presta, cité dans l’analyse Shopify, mentionne 2 à 4 semaines pour une intégration Storefront MCP de base. Limites : découvrabilité, confiance, authentification — toutes à gérer. Intuz chiffre $25k-$50k pour un MVP SMB, $60k-$120k pour multi-tenant SaaS [Source : Intuz]. À relativiser : un serveur MCP read-only sur un catalogue public tient en quelques centaines de lignes.

Quand l’utiliser : quand la différentiation produit dépend du contrôle fin de la surface agent (ex : configurateurs, devis complexes, services sur-mesure).

8.4 Chemin 4 : les agrégateurs et sub-registries verticaux

Modèle émergent. Un agrégateur sectoriel (mode, brico, food) expose un serveur MCP agrégé qui consomme les catalogues de PMEs en backend. La PME fournit son flux produit, l’agrégateur gère la surface agent, la confiance, le checkout via ACP/UCP.

C’est économiquement le seul chemin viable pour les boutiques trop petites pour justifier un serveur dédié, mais trop spécifiques pour rentrer dans le moule Shopify. Les plateformes verticales et marketplaces verticales (type Ankorstore, Mirakl) sont les candidates naturelles, même si rien de concret n’a été annoncé côté français début 2026.

8.5 Catalogue structuré : la condition préalable commune

Indépendamment du chemin choisi, le pré-requis est un catalogue produit enrichi pour LLM :

Descriptions longues, en langage naturel, avec contexte d’usage.
Attributs typés et normalisés (matière, taille, origine, compatibilité).
Relations (variantes, accessoires, substituts).
Disponibilité et prix en temps réel, accessibles via API.

C’est la même logique que feeds Google Shopping historique, mais avec davantage d’attributs et un biais vers la lisibilité LLM [Source : Stellagent — Commerce MCP Explained].

9. Monétisation : facturer son serveur MCP

La question n’est jamais « combien coûte un serveur MCP » dans l’absolu. Elle est : qui facture quoi à qui ?. Trois choses peuvent être payantes, et il faut les distinguer avant de regarder les patterns.

Ce qui est facturé	Bénéficiaire du paiement	Exemple
L’API ou SaaS sous-jacent que le serveur expose	L’éditeur du SaaS	GitHub MCP : facturé via abonnement GitHub habituel
Le service propre rendu par le serveur MCP	L’auteur du serveur	Ref : index documentaire construit et entretenu
L’accès à l’invocation (transport, infra, billing)	La plateforme gateway	MCPize, Moesif, Apify

Les patterns ci-dessous se distinguent surtout par la combinaison de ces trois axes.

9.1 BYOK — Bring-Your-Own-API-Key (rien n’est facturé par le serveur MCP)

Le client fournit sa clé API du service sous-jacent (GitHub, Stripe, Slack, Linear). Le serveur MCP n’est qu’un adaptateur de protocole, pas un point de facturation. C’est le pattern par défaut des serveurs vendor officiels et de la plupart des serveurs communautaires. Il maximise l’adoption mais ne rapporte rien à l’auteur du serveur.

9.2 Service propre, payé directement par l’utilisateur

Quand le serveur MCP délivre une valeur que l’utilisateur ne pouvait pas se procurer ailleurs, il est facturable. L’étude de cas Ref publiée sur PulseMCP est le retour d’expérience le plus concret de la période :

Unité de facturation : 1 crédit = 1 recherche dans l’index documentaire.
Tier gratuit : 200 crédits, soit ~ 10 semaines d’usage individuel typique.
Plan payant minimum : $9/mois — ce minimum existe pour couvrir un coût fixe (le crawling continu et l’indexation), indépendant du volume d’appels.

Trois enseignements tirés par les auteurs [Source : PulseMCP — Pricing the Unknown] :

Tarification à l’usage plutôt qu’à la durée : un agent peut faire 10 000 appels/jour, un humain 5/semaine. Un trial 14 jours n’a pas de sens.
Facturer au moment de la valeur (résultat de recherche), pas au moment du coût (indexation).
Ne pas chercher à concurrencer le gratuit : l’écosystème MCP est saturé d’alternatives free. Positionnement premium assumé.

9.3 Service propre, payé via gateway

L’auteur du serveur ne veut pas construire une infra de billing. Il délègue à une plateforme qui encaisse et reverse. Trois modèles concrets observés :

MCPize : déploiement clé-en-main, billing pay-per-invocation, 85 % reversés à l’auteur du serveur [Source : krisying — MCP Servers Are the New SaaS].
Apify : l’auteur insère Actor.charge('eventName', count=N) dans son code, Apify encaisse et reverse selon la grille du créateur.
Moesif / Kong / Zuplo : gateway en frontal d’un serveur auto-hébergé. Metering d’appels, facturation hybride subscription + overage, ou outcome-based (on ne paie que les appels qui retournent un résultat utile).

Ces plateformes lèvent le frein principal pour un développeur indépendant : construire un Stripe + un système de quotas + une UI de facturation est plus de travail que le serveur MCP lui-même.

9.4 Service propre, payé par l’agent en micropaiement (x402)

Pour les usages machine-à-machine où aucun utilisateur humain n’est présent au moment de l’appel, x402 court-circuite la création de compte et la gestion de clé. Le client agent possède un wallet stablecoin ; chaque appel coûte quelques centimes USDC ; le serveur répond 402 Payment Required avec le montant attendu et un nonce ; le client paie et rejoue.

Pour le serveur MCP, l’intérêt est immédiat : pas de table utilisateurs, pas de plan tarifaire, pas de billing récurrent. Pour l’agent, idem : pas de carte à enregistrer, pas d’onboarding [Source : Zuplo — Autonomous API & MCP Server Payments with x402].

C’est aujourd’hui le pattern le plus prometteur pour des serveurs MCP communautaires qui veulent facturer sans construire d’infra. Limite réelle : l’écosystème stablecoin est encore mal vu côté entreprises et reste mal couvert côté wallet pour les agents grand public.

9.5 Lead generation (le serveur MCP n’est pas le produit)

Pattern documenté par krisying : le serveur MCP est gratuit, distribué sur npm, et sert à attirer du trafic vers un produit payant adjacent — templates, services de consulting, SaaS premium. Le serveur n’est jamais facturé ; il joue le rôle d’aimant qualifié.

Citations chiffrées de l’auteur (à prendre comme un retour d’expérience individuel, pas une moyenne de marché) : 500 installs/mois par serveur, 2 % de conversion vers les produits payants, des revenus réalistes en portfolio de plusieurs serveurs, pas en mono-serveur.

9.6 État du marché

Donnée la plus citée fin 2025 / début 2026 : moins de 5 % des 11 000+ serveurs MCP publics génèrent un revenu direct [Source : krisying]. Le reste se répartit entre BYOK (l’éditeur du SaaS sous-jacent encaisse), bénévolat, et marketing produit.

Conséquence pratique : la maturité du modèle économique est très en retard sur la maturité technique du protocole. Pour un éditeur qui veut construire un serveur MCP rentable aujourd’hui, le chemin par défaut est le 9.3 (gateway type MCPize/Apify) si la cible est humaine, ou le 9.4 (x402) si la cible est agent-à-agent.

10. Les questions encore ouvertes

10.1 L’identité et la réputation d’un serveur

Les attestations cryptographiques prouvent la provenance ; elles ne disent pas si le service est digne de confiance. Il n’existe pas de PageRank des serveurs MCP. Le Registry officiel est délibérément plat, les sub-registries font de la curation sans méthodologie publique.

Un serveur MCP populaire aujourd’hui = un serveur qui apparaît dans une liste « officielle » d’un client (Claude Desktop, ChatGPT Apps). La dépendance aux clients majeurs est réelle.

10.2 Le référencement dans les agents

Si demain ChatGPT privilégie les serveurs OpenAI Apps SDK et Claude ceux de son registry interne, la neutralité MCP s’effrite. Pour l’instant, les deux clients consomment largement la même liste de serveurs publics, mais rien ne garantit la suite.

10.3 La gouvernance post-Linux Foundation

Le donation a réussi la partie symbolique. Reste à voir comment le Contributor Ladder et la délégation aux Working Groups annoncés dans la roadmap gèrent réellement les conflits — notamment entre besoins enterprise (gateway, audit, SSO) et besoins grand public (simplicité, découverte).

10.4 La France et l’Europe

Les annonces majeures (Instant Checkout, UCP listings Google) sont US-first. Peu de retour public sur des marchands français passés en ACP ou UCP. L’obligation de facturation électronique au 1er septembre 2026 pour les assujettis TVA va concentrer les budgets IT PME sur autre chose que l’agentique pendant plusieurs mois.

Côté souveraineté, rien de concret sur un registry européen ou une spec de trust compatible RGPD/DORA. Les PMEs françaises qui veulent tester sont aujourd’hui renvoyées vers les intégrations via Shopify/Stripe — c’est-à-dire des chaînes de valeur totalement US.

10.5 Le modèle économique du serveur open-source

5 % des 11 000 serveurs sont monétisés. Les 95 % restants dépendent de mainteneurs bénévoles, de « lead generation » vers du consulting, ou de budgets marketing d’éditeurs. La durabilité dans le temps, en cas de faille de sécurité critique, reste une question ouverte.

11. Ce qu’il faut retenir

MCP n’est plus un protocole de dev tools. Avec 97M de downloads/mois, 10k+ serveurs publics, et une gouvernance Linux Foundation, c’est devenu un standard d’intégration au sens industriel. Le commerce (ACP, UCP) et les paiements (x402) s’y branchent.
Le Registry officiel est volontairement limité. C’est une métaregistry, pas un app store. L’UX de découverte passe par Smithery, MCPMarket, MCP.so et les marketplaces des clients. Publier sur les trois grands + exposer un Server Card est la bonne stratégie.
L’auto-découvrabilité est en route via .well-known/mcp/server-card.json (SEP-1649) et /.well-known/ucp côté commerce. Implémentez les deux dès maintenant.
Le problème de confiance est pris en charge par de la crypto, pas de la réputation : Sigstore, GitHub Attestations, SBOMs, OAuth 2.1 + DCR + PRM + Resource Indicators. Un gateway en frontal est recommandé pour les déploiements sérieux.
Pour les PMEs, 4 chemins : via plateforme (Shopify, Etsy), via PSP (Stripe ACP), serveur MCP maison, ou agrégateur vertical. Le pré-requis commun est un catalogue structuré enrichi pour LLM.
La monétisation reste immature : BYOK domine, les gateways (MCPize, Moesif) ou x402 rendent les micropaiements viables, mais moins de 5 % des serveurs facturent — la fenêtre reste ouverte.
Les PMEs françaises héritent aujourd’hui d’une chaîne de valeur US. Aucune alternative européenne publique structurée au printemps 2026.

Le message pratique dépend du profil :

PME marchande (vend des produits physiques ou services classiques) : le chemin par défaut est la plateforme (Shopify, Etsy, WooCommerce + plugin) ou le PSP (Stripe ACP). Aucun serveur MCP à exposer, rien à publier dans un registry — la plateforme s’en occupe. La priorité est ailleurs : enrichir le catalogue produit pour la lisibilité LLM (descriptions, attributs, relations).
Éditeur de service / SaaS (le serveur MCP est le produit qu’on cherche à faire appeler) : commencer par un Server Card statique, publier dans le Registry officiel et un ou deux sub-registries (Smithery, MCPMarket), choisir un modèle de monétisation explicite (section 9), et instrumenter dès le début pour mesurer qui appelle quoi.
PME avec besoins spécifiques non couverts par plateforme (configurateurs, devis sur-mesure, métier vertical) : tester d’abord ce que la plateforme et le PSP couvrent — souvent plus que ce qu’on imagine. Construire un serveur MCP maison uniquement quand un cas d’usage différenciant ne rentre pas dans le moule, et le faire d’abord en interne avant de l’exposer publiquement.
Éditeur de marketplace sur mesure (vous êtes la plateforme — pas de Shopify ni WooCommerce dessous) : vous occupez la position de Shopify pour vos marchands. C’est à vous de construire la couche d’exposition aux agents, et c’est un travail structurant qui dépasse le simple Server Card. Concrètement :
- Calquer le découpage Shopify plutôt que réinventer : un Storefront MCP (recherche produit, panier), un Checkout MCP (création/complétion de session, conforme ACP côté Stripe ou UCP côté Google), un Customer Account MCP (suivi commande, retour). Quatre serveurs distincts plutôt qu’un monolithe — c’est le découpage qui s’est imposé en pratique et que les agents savent consommer.
- Publier deux manifestes côte à côte : /.well-known/mcp/server-card.json pour la découverte agent générique, et /.well-known/ucp pour entrer dans les surfaces commerce (Gemini AI Mode, listings Google). Le coût marginal est nul une fois la plomberie en place, et c’est ce qui décide de l’inclusion dans les surfaces majeures.
- Brancher ACP via le PSP, pas en réimplémentant : si vous routez les paiements via Stripe, l’activation ACP est essentiellement une ligne de configuration côté Stripe — c’est ce qui ouvre ChatGPT Instant Checkout à vos marchands d’un coup. PayPal joue un rôle symétrique avec son MCP remote.
- Multi-tenant côté trust : vos marchands ne peuvent pas auto-signer leurs serveurs ; c’est vous qui portez l’attestation de provenance (Sigstore, SBOM) au nom de la marketplace, et qui devez exposer un audit log par marchand. Sans cette couche, vous serez la première à être pointée du doigt en cas d’incident sur un marchand.
- Publier dans les sub-registries verticaux plutôt que dans les généralistes : MCP.so accepte tout, mais une marketplace mode/brico/food gagnera plus à apparaître dans une curation thématique (existante ou à promouvoir) qu’au milieu de 19 000 outils dev.
- Instrumenter dès le jour 1 : vous êtes en position d’observer le trafic agent réel sur tous vos marchands à la fois — c’est votre asset, et c’est ce qui vous permettra demain de proposer du « rang dans les réponses agent » comme produit publicitaire.

Dans tous les cas, la même règle : mesurer la demande réelle des agents avant d’investir. Un Server Card et quelques outils en lecture seule suffisent pour observer le trafic agent réel ; les décisions d’architecture sérieuses se prennent ensuite.