MCP vs API REST : quand choisir quoi ?

Depuis fin 2024, les serveurs MCP fleurissent. Anthropic a lancé le protocole, OpenAI et Google l’ont adopté, les éditeurs d’IDE ont suivi. La question revient à chaque comité technique : faut-il rebasculer toutes nos APIs REST en MCP ? Non. Les deux coexistent, et c’est tant mieux. La vraie question, ce n’est pas « qui gagne », c’est « quel protocole pour quel appelant ».

REST est un standard d’accès programmatique pensé pour des développeurs et des backends applicatifs. MCP est un canal d’exposition pensé pour des agents IA qui découvrent dynamiquement les outils à leur disposition. Les deux ne résolvent pas le même problème, ils ne ciblent pas les mêmes consommateurs, et dans la pratique un même service gagne souvent à exposer les deux. Chez Datacampus, c’est exactement ce qu’on fait.

REST en 2026 : toujours le standard par défaut

REST (Representational State Transfer) a été formalisé par Roy Fielding dans sa thèse en 2000. Ce n’est pas un protocole, c’est un style architectural basé sur HTTP : ressources identifiées par URI, manipulation via verbes HTTP (GET, POST, PUT, PATCH, DELETE), représentations JSON, stateless, cacheable. Le modèle de maturité de Richardson décrit les niveaux 0 à 3 ; la majorité des APIs du marché vivent au niveau 2 (ressources + verbes), peu atteignent le niveau 3 (HATEOAS).

REST s’est imposé parce qu’il est pragmatique. Il s’appuie sur HTTP, donc il hérite du cache navigateur, des CDN, des reverse proxies, des codes d’erreur standard, de toute l’observabilité existante. N’importe quelle app web ou mobile sait l’appeler, n’importe quelle plateforme (Kong, APIGee, AWS API Gateway) sait l’exposer, la limiter, la monitorer.

$ curl -H "Authorization: Bearer $TOKEN" \
    https://api.datacampus.fr/v1/offerings?category=vps

Forces typiques : cache HTTP natif, CDN friendly, outillage mature (Postman, Insomnia, OpenAPI/Swagger), observabilité triviale, authentification bien connue (OAuth2, Bearer, API key, mTLS). Côté usage : frontends web et mobiles, intégrations B2B, webhooks événementiels, APIs publiques à fort volume.

MCP : l’interface pensée pour les agents IA

Model Context Protocol est un protocole ouvert initié par Anthropic en novembre 2024. La version largement déployée en production est la spec du 18 juin 2025 (protocolVersion: "2025-06-18"), avec la révision du 25 novembre 2025 qui a consolidé l’auth OAuth2 et l’élicitation. Le transport Streamable HTTP, introduit en mars 2025, est aujourd’hui le transport recommandé pour les serveurs remote ; il remplace l’ancien SSE bidirectionnel et cohabite avec stdio pour les serveurs locaux.

Sous le capot, c’est du JSON-RPC 2.0 avec trois primitives métier : tools (fonctions appelables), resources (documents lisibles), prompts (modèles paramétrés). Chaque tool déclare un schéma JSON Schema et une description en langage naturel. Au handshake, le client fait un tools/list, le serveur répond avec le catalogue, le LLM choisit quoi appeler en fonction de la description. C’est un protocole pensé pour qu’une IA découvre et raisonne seule sur ce qu’un système sait faire.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "list_offerings",
    "arguments": { "category": "vps" }
  }
}

Forces spécifiques : découverte dynamique (tools/list), schémas paramètres obligatoires (pas de deviner), description sémantique lue par le LLM, streaming natif via Streamable HTTP, notifications et batching hérités de JSON-RPC, sampling (le serveur peut demander au client une inférence), prompts réutilisables côté client. Côté usage : exposer son métier à Claude, ChatGPT, Cursor, Continue, Cline, Zed, Windsurf, ou à un agent interne maison.

Cas d’usage → protocole conseillé

Plutôt qu’un match de boxe entre les deux, voici les situations qu’on rencontre en vrai et le protocole qui répond le mieux.

Le pattern d’architecture qui marche

Dans les projets qu’on voit passer en 2026, un schéma s’est imposé : REST reste la source de vérité, MCP vient par-dessus comme façade pour les agents IA. Le serveur MCP ne duplique pas la logique métier, il wrappe l’API REST existante en exposant des tools orientés intention.

MCP ne remplace pas REST, MCP s’ajoute à REST quand tu veux être consommable par des agents IA. Le jour où tu retires MCP, ton API REST tourne toujours. Le jour où tu ajoutes MCP, tes clients REST ne changent pas une ligne.

Concrètement, un tool MCP find_invoices_by_client peut être 20 lignes de code qui appellent GET /v1/invoices?client_id=...&status=... en interne et reformatent la réponse pour un LLM. L’auth est partagée (OAuth2 des deux côtés), le cache REST profite indirectement au MCP, l’observabilité reste centralisée sur l’API.

Quand NE PAS faire du MCP

Toutes les APIs ne gagnent pas à avoir leur pendant MCP. Avant de coder un serveur, vérifiez qu’un agent IA aura un intérêt réel à l’appeler.

• Applications statiques ou purement frontend : pas d’agent dans la boucle, pas besoin de MCP. Un site e-commerce, une app mobile, un dashboard interne : REST suffit.
• Intégrations machine-to-machine classiques : un cron qui synchronise deux bases, un ETL, un job batch nocturne. Le contrat est fixe, l’appelant est scriptable, REST est fait pour ça.
• Besoins temps réel critiques : trading, IoT, telemetry haute fréquence. L’overhead d’un appel d’agent (3 à 10 secondes de réflexion LLM) est rédhibitoire. REST, gRPC ou WebSocket restent les bons choix.
• APIs publiques massivement consommées par des devs : Stripe, Twilio, GitHub. Ils exposent du REST parce que leurs utilisateurs codent des intégrations, pas des agents. Un MCP peut compléter, il ne remplace pas.
• Contrats réglementaires stricts : banques, santé, juridique. Le déterminisme REST (même requête, même réponse) est auditable ; un agent qui interprète et choisit, beaucoup moins.

Comment on fait chez Datacampus

On héberge notre propre catalogue d’offres sur trois canaux, chacun dimensionné pour son appelant.

• HTML : les pages /serveurs-vps, /hebergement-cloud, /ia pour les humains. SEO, mise en page, lecture linéaire, présentation commerciale.
• API REST : consommée par notre configurateur de devis, par notre back-office, par les scripts de génération de sitemap. Cachée en bordure, rapide, standard, versionnée en URI.
• Serveur MCP : https://datacampus.fr/mcp expose 5 tools (list_offerings, get_offering_details, recommend_offering, estimate_configuration, get_company_info) à Claude, ChatGPT et tout agent compatible. Découverte via /.well-known/mcp.json, transport Streamable HTTP, CORS géré en .htaccess.

$ # Canal REST (notre configurateur, nos scripts)
$ curl https://datacampus.fr/api/offerings?category=vps

$ # Canal MCP (Claude, ChatGPT, Cursor)
$ curl -X POST https://datacampus.fr/mcp \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_offerings","arguments":{"category":"vps"}}}'

Chaque canal sert sa cible. Le HTML convertit les humains. Le REST alimente notre propre outillage. Le MCP permet à un agent IA de recommander nos VPS quand un utilisateur demande à ChatGPT « trouve-moi un hébergeur souverain en France avec immersion cooling pour mon site Symfony ». Même domaine métier, trois interfaces pensées pour leurs appelants respectifs. Si on avait tout fait en REST, le LLM aurait dû deviner quels endpoints appeler. Si on avait tout fait en MCP, notre configurateur front aurait eu besoin d’un client JSON-RPC inutile.

Pièges à éviter quand on ajoute MCP à une API existante

Wrapper brutalement un Swagger en MCP

La tentation : prendre un OpenAPI, générer automatiquement un tool MCP par endpoint, déployer, c’est plié. Sauf que ça donne un serveur avec 80 tools aux noms cryptiques (getUserById, postInvoiceCreate), aux descriptions générées à partir de commentaires Javadoc, et des paramètres optionnels sans contexte. Le LLM s’y perd et appelle mal, quand il appelle.

Un bon serveur MCP expose entre 5 et 20 tools orientés intention : find_invoices_by_client plutôt que getInvoicesQuery. C’est un travail de conception, pas une génération auto.

Sous-estimer l’importance des descriptions

Une description de tool, c’est un prompt. Si vous écrivez « Récupère la liste », le LLM ne saura pas quelle liste. Si vous écrivez « Liste les factures d’un client donné, filtrables par date et par statut (payée, impayée, en retard). À utiliser pour répondre aux questions sur l’état financier d’un client ou sur un recouvrement », le LLM sait exactement quand l’appeler. Testez avec l’agent cible, pas dans votre tête.

Négliger l’auth et l’isolation multi-tenant

Un serveur MCP expose des actions métier à un agent qui agit pour un utilisateur. Question : comment l’agent prouve l’identité de l’utilisateur au serveur ? La spec MCP 2025-06-18 a intégré un flow OAuth2 natif ; la révision de novembre 2025 l’a consolidé. Utilisez-le. Ne bricolez pas une API key partagée entre tous les utilisateurs, vous perdez l’audit et la ségrégation.

Ce qu’il faut retenir

MCP ne remplace pas REST : il s’ajoute à REST quand vous voulez que des agents IA consomment vos outils. Si vous construisez une app web, une app mobile, une intégration entre deux SaaS, un webhook : REST reste le bon choix, 25 ans de maturité derrière lui. Si vous voulez que Claude, ChatGPT ou un agent interne interroge et agisse sur vos systèmes : exposez un serveur MCP, en façade de votre REST, avec 5 à 20 tools bien décrits et orientés intention.

Chez Datacampus, on héberge les deux : vos APIs REST sur nos VPS ou notre cloud, vos serveurs MCP sur la même infra, avec des serveurs d'inférence souverains si vous voulez du LLM local en plus. Pour en discuter, le formulaire est ici, ou notre serveur MCP est sur /mcp si vous préférez que votre agent nous appelle directement.

Pour aller plus loin : qu’est-ce que MCP, les bases, notre implémentation sur datacampus.fr, et faire tourner un LLM souverain sur vos propres serveurs.