Qu'est-ce que le MCP (Model Context Protocol) ?

Le MCP est un standard ouvert qui permet aux apps d’IA de se connecter à des outils et données externes via un seul protocole, sans intégrations sur mesure. Présenté par Anthropic en novembre 2024 et devenu standard de l’industrie en moins d’un an, il fait pour les agents d’IA à peu près ce qu’un port commun a fait pour les périphériques — la formule « l’USB-C de l’IA » que tous les articles d’explication finissent par sortir. Le cadrage plus précis pour un développeur backend : un serveur MCP est un adaptateur d’API. Votre backend sait déjà répondre aux requêtes ; le MCP est la façon de le rendre découvrable et appelable par un modèle d’IA plutôt que par du code client écrit à la main.

Points clés

Un serveur MCP qui enveloppe le backend que vous avez déjà

// JavaScript / Node.js — an MCP server wrapping an existing backend API
import { McpServer } from '@modelcontextprotocol/server';
import { z } from 'zod';

const server = new McpServer({ name: 'tasks', version: '1.0.0' });

// A tool is a described, discoverable wrapper over the API you already have
server.registerTool(
  'query_tasks',
  { description: 'List tasks by status', inputSchema: z.object({ status: z.string() }) },
  async ({ status }) => {
    const res = await fetch(`${BASE}/classes/Task?where=${q({ status })}`, {
      headers: { 'X-Parse-Application-Id': APP_ID, 'X-Parse-REST-API-Key': KEY },
    });
    return { content: [{ type: 'text', text: await res.text() }] };
  }
);
// The agent discovers this tool at runtime and decides when to call it —
// same backend, same ACLs and rate limits; just a new kind of client.

// Flutter / Dart — Back4app Flutter SDK
// One backend, two kinds of consumers: your app via the SDK…
final tasks =
    await QueryBuilder<ParseObject>(ParseObject('Task')).query();
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// iOS / Swift — Back4app Swift SDK
// One backend, two kinds of consumers: your app via the SDK…
let tasks = try await Task_.query().find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// Android / Kotlin — Back4app Android SDK
// One backend, two kinds of consumers: your app via the SDK…
val tasks = ParseQuery.getQuery<ParseObject>("Task").find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

L’onglet JavaScript contient toute l’idée en quinze lignes : un outil query_tasks est un wrapper décrit et découvrable autour d’un appel REST que le backend sert déjà. L’agent lit la description au runtime, décide quand l’outil convient, et l’appelle — en appelant les mêmes endpoints, les mêmes ACL et les mêmes limites de débit (rate limits) que votre app. Un nouveau type de client, pas un nouveau backend.

Comment le MCP résout le problème d’intégration N×M

Avant le MCP, relier N clients d’IA à M outils impliquait jusqu’à N × M intégrations sur mesure. Un protocole partagé ramène cela à N + M : chaque client et chaque serveur implémente le MCP une seule fois. L’architecture officielle nomme trois rôles — le host est l’application d’IA ; il crée un client par connexion ; chaque server fournit une capacité — sur JSON-RPC, avec stdio pour les serveurs locaux sur la même machine et Streamable HTTP pour les serveurs distants (le transport HTTP+SSE d’origine est désormais déprécié).

Les trois primitives

Un serveur de base de données expose généralement les trois : un outil query, une ressource schema et un prompt few-shot pour les demandes courantes — « voici ce que je sais faire, ce que je sais, et comment me le demander ».

MCP vs. API vs. function calling

Les deux comparaisons se tranchent nettement. Face à une API : le MCP ne la remplace pas — il l’enveloppe, en ajoutant une découverte au runtime pour que ce soit le modèle qui choisisse l’appel plutôt que le code de votre application. Face au function calling (appel de fonctions) : le function calling, c’est le modèle qui émet une requête structurée ; le MCP standardise la façon dont cette requête est découverte et exécutée à travers les apps et les fournisseurs. Le MCP apporte standardisation et portabilité, pas de nouvelle capacité — tout ce que fait le MCP, un function calling sur mesure pourrait le faire pour une intégration ; le MCP le fait fonctionner partout sans réécriture.

La surface de sécurité, en toute honnêteté

La section que les pages neutres sautent et que les éditeurs de solutions de sécurité survendent. Le protocole n’est pas la menace ; le modèle de confiance, si. La prompt injection arrive par les sorties des outils — un document renvoyé par un outil peut contenir des instructions que le modèle suit ensuite. Le tool poisoning cache des instructions malveillantes dans la description d’un outil, que le modèle lit avant qu’aucun humain ne la voie — désormais répertorié par l’OWASP. Les rug pulls : un serveur approuvé une fois peut modifier ses définitions d’outils plus tard. Et le risque discret : la chaîne d’approvisionnement des serveurs communautaires — il en existe des milliers, et en installer un lui donne un pied dans le contexte de votre agent. Les parades relèvent de la discipline de sécurité ordinaire appliquée à une nouvelle surface : des portées au moindre privilège par serveur, une validation humaine pour les appels d’outils qui agissent, l’épinglage des versions et une allow-list des serveurs de confiance, une vraie authentification sur les serveurs distants, et ne jamais confier à un serveur MCP des identifiants plus larges que ce que la tâche exige.

La spécification aujourd’hui

Le MCP évolue vite, et la plupart des articles d’explication se sont figés à la mi-2025 — une note de fraîcheur qui mérite d’être tenue à jour. Le transport s’est consolidé sur Streamable HTTP (HTTP+SSE déprécié) ; les serveurs distants se sont standardisés sur une authentification de type OAuth ; la révision 2026-07-28 a rendu le protocole sans état — ni handshake ni sessions, des métadonnées par requête et un appel server/discover — et a déprécié Roots, Sampling et Logging. La gouvernance est le signal le plus fort : fin 2025, le protocole a été confié à une fondation open-source neutre — le marqueur structurel d’un vrai standard plutôt que de la convention d’un seul fournisseur. La leçon pratique pour qui construit : épinglez une version de la spec, lisez le changelog avant de mettre à jour, et traitez « MCP » comme une cible mouvante au noyau stable.

Cas d’usage courants

• Agents de code — des assistants d’IDE qui atteignent votre dépôt, votre base de données et votre gestionnaire de tickets via des serveurs plutôt que des plugins sur mesure.
• Chat sur les données de l’entreprise — un assistant qui interroge les systèmes internes, chacun enveloppé dans un serveur MCP doté de permissions.
• Exposition du backend — transformer une API REST/GraphQL existante en outils appelables par des agents, sans la reconstruire.
• Automatisation du poste de travail et des workflows — des serveurs stdio locaux qui relient le modèle aux fichiers et aux applications d’une machine.
• Portabilité multi-fournisseurs — un serveur qui sert tous les hosts parlant MCP, pour qu’une intégration survive à n’importe quel choix de modèle.

Devriez-vous utiliser le MCP ? Matrice de décision

Limites et trade-offs

• C’est un standard en mouvement. L’évolution rapide de la spec impose d’épingler les versions et de surveiller le changelog ; « compatible MCP » est une affirmation datée.
• Le modèle de confiance est nouveau. Les descriptions et les sorties des outils sont une surface d’attaque ; des agents qui agissent via des serveurs non vérifiés, c’est le curl \| bash de l’époque actuelle.
• Un surcoût sous le point de bascule. Pour une seule intégration, le MCP ajoute un protocole et un processus serveur là où un appel de fonction suffirait.
• La découverte transfère le contrôle au modèle. La sélection des outils au runtime est puissante et moins prévisible que des appels codés en dur — l’audit et l’approbation comptent davantage, pas moins.
• Il enveloppe, il ne répare pas. Un serveur MCP posé sur une API mal sécurisée expose simplement cette API aux agents plus vite ; les permissions sous-jacentes font toujours le vrai travail.

Le MCP sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Le cadrage « adaptateur d’API » s’applique ici naturellement : une app Back4app expose déjà la surface qu’un serveur MCP enveloppe — REST et GraphQL sur chaque classe, plus les fonctions Cloud Code — si bien que la rendre accessible aux agents revient à mapper find objects, run function et read schema vers des définitions d’outils, comme l’esquissent les onglets de code. La section sécurité devient une consigne concrète : donnez au serveur MCP une clé à portée limitée, jamais la master key ; laissez les ACL et les permissions au niveau de la classe de la plateforme restreindre ce que les appels d’un agent peuvent toucher, exactement comme elles restreignent ceux de votre app ; et placez les actions irréversibles derrière des Cloud Functions dotées de leurs propres contrôles plutôt qu’un accès brut aux tables. L’agent devient un client de plus d’un backend qui sait déjà dire non.