Claude Fable 5 vs Opus 5 : quel modèle choisir pour vos agents IA ?
Fable 5 ou Opus 5 ? Choisissez selon la difficulté de la mission et le coût par tâche réussie — pas le modèle le plus puissant partout.
11 min de lecture
Faut-il exposer ses services à un agent IA avec MCP, ou lui donner accès à une API REST ?
La mauvaise façon de poser la question serait : MCP est-il meilleur que REST ? Les deux ne répondent pas au même besoin.
Une API REST fournit un contrat HTTP explicite entre des systèmes. Avec OpenAPI, ce contrat peut être décrit de façon standardisée, pour des humains comme pour des machines.
MCP, ou Model Context Protocol, fournit une interface standardisée entre une application IA et les capacités qu’elle peut utiliser : outils, ressources, et autres éléments de contexte.
La différence pratique tient moins au transport HTTP qu’à qui doit comprendre et sélectionner l’opération.
Si votre logiciel sait déjà exactement quelle opération effectuer, une API est souvent suffisante. Si un agent doit inspecter les capacités disponibles puis décider lui-même quel outil utiliser, MCP devient beaucoup plus intéressant.
API REST
Le logiciel · Opération connue
Webhook → créer la facture
MCP
L’agent · Capacité à découvrir
Inspecter les tools, puis agir
Hybride
Les deux · Même domaine
MCP au-dessus de l’API produit
MCP vs API REST : la différence en une phrase
Une API REST répond surtout à : comment un système appelle-t-il une capacité précise ?
MCP répond davantage à : comment une application IA découvre-t-elle et utilise-t-elle des capacités mises à sa disposition ?
Dans un système de gestion de projet, une API peut exposer « créer une card ». L’appelant connaît déjà l’opération, les paramètres, le format, et le moment de l’appel.
Avec MCP, cette capacité peut être un tool : nom, description, schéma. L’agent décide s’il est pertinent pour son objectif.
Ce n’est pas REST contre JSON-RPC, ni HTTP contre MCP, ni « ancienne » contre « architecture IA ». Le vrai sujet :
appel déterministe d’une opération connue, ou sélection dynamique d’une capacité par un agent ?
REST
MCP
Le code connaît l’endpoint
L’agent inspecte les tools
Contrat figé, prévisible
Découverte native des capacités
Webhook, job, backend
Host IA, mission ouverte
OpenAPI décrit l’API
Tools, resources, prompts
Ce que REST, OpenAPI et MCP standardisent
REST, OpenAPI et MCP sont souvent mélangés. Ils interviennent à des niveaux différents.
REST structure les échanges
Ressources et opérations via HTTP. Une application, un worker ou un webhook appelle une opération précise sans demander à un modèle de choisir. Idéal pour synchroniser, déclencher, modifier, automatiser un traitement connu.
OpenAPI décrit le contrat
Opérations, paramètres, corps, réponses, schémas, sécurité. Documentation, SDK, validateurs, intégrations. MCP n’a pas inventé la description machine-readable d’une API.
MCP oriente l’application IA
Tools pour agir, resources pour le contexte, prompts réutilisables. Un client MCP demande ce qui est disponible, le présente au modèle, qui peut alors choisir l’outil.
Aucune n’est supérieure
Elles répondent à des besoins différents. La qualité vient du choix, pas du protocole à la mode.
| Critère | REST + OpenAPI | MCP |
|---|---|---|
| Objet | API HTTP | Capacités pour une app IA |
| Contrat | Endpoints, requêtes, réponses | Tools, resources, primitives MCP |
| Consommateur | Logiciel, worker, webhook | Host IA ou agent |
| Choix de l’opération | Le code | Souvent le modèle |
| Prévisibilité | Très forte | Dépend du host et du modèle |
Découverte d’outils ou contrat figé
Mission type : « L’import CSV plante depuis la dernière mise en production. Analyse le problème et crée une card si le bug est confirmé. »
Orchestration entièrement codée
Récupérer le bug, collecter des infos, analyser, vérifier, créer une card si besoin. Le processus est connu. REST ou des appels internes suffisent.
Outils MCP
L’agent inspecte les capacités (lire, chercher, agir) et sélectionne selon ce qu’il découvre. Utile quand plusieurs actions sont possibles et que le bon choix dépend de l’exécution.
Comment un agent découvre des outils
Un serveur MCP annonce les outils : nom, description, schéma d’entrée, éventuellement une structure de sortie. Le host IA récupère la liste et en présente une sélection au modèle.
La logique devient : objectif → compréhension → sélection d’un outil → appel → résultat → nouvelle décision éventuelle.
Avec une API appelée par une application : événement → code → endpoint connu → résultat.
Les deux modèles sont utiles. Ils ne servent pas au même type de problème.
Tools MCP vs endpoints REST
Un endpoint REST représente souvent une ressource ou une opération applicative. Un tool MCP devrait être une capacité compréhensible et actionnable par un agent.
Il est rarement judicieux de transformer automatiquement chaque endpoint en tool. L’agent a besoin d’une surface limitée, claire, cohérente, assez haut niveau, adaptée à ses missions.
Un tool n’a pas à être le miroir d’un endpoint. Il peut être une façade au-dessus de plusieurs services. L’API reste la fondation métier.
Streamable HTTP, latence, tokens
MCP n’est pas un remplacement d’HTTP. Pour les serveurs distants, il peut fonctionner en Streamable HTTP. La spécification MCP a rapproché ce modèle d’une infrastructure HTTP moderne : load balancing, scaling, serverless, reprise après défaillance d’instance. L’état métier, s’il existe, appartient à l’application, pas à une session protocolaire obligatoire.
MCP n’est pas « plus lent » par nature. Un chemin application → API → service est court. Un chemin utilisateur → modèle → sélection → host MCP → serveur → API → résultat → modèle contient plus d’étapes. La question n’est pas « MCP ajoute-t-il quelques millisecondes ? » mais la découverte et la décision dynamique sont-elles nécessaires ?
MCP ne consomme pas de tokens au transport. En revanche, noms, descriptions, schémas, résultats et resources occupent le contexte. Cinq tools simples : négligeable. Cinquante tools verbeux : coûteux. Exposez des outils différenciés, des descriptions courtes, des schémas simples, limités au contexte de l’agent.
Versioning, auth, sécurité, approvals, audit
REST n’empêche pas les breaking changes. MCP non plus. Un contrat utilisé en production mérite stabilité, dépréciations, tests de compatibilité — quel que soit le protocole.
MCP ne remplace pas l’identité. Il faut toujours savoir qui appelle, avec quelles ressources, quelles actions, dans quel workspace, avec quelles limites. OAuth, JWT, API keys, PAT, comptes de service : ce sont des mécanismes d’auth, pas des alternatives à MCP.
Comparer « sécurité MCP » et « sécurité API key » est trompeur. MCP est un protocole. Une API key est un mécanisme. Un token trop large est dangereux derrière REST comme derrière MCP. Appliquez le moindre privilège.
Quand REST, MCP, ou les deux
REST seul
Appelant classique, opération connue, workflow déterministe, débit élevé, transactionnel, API déjà consommée par plusieurs systèmes. Webhook, facturation, cron, CI/CD, batch.
MCP a du sens
Plusieurs clients IA, découverte d’outils, capacités selon le contexte, plusieurs tools pour une mission, resources à fournir, éviter une intégration propriétaire par host.
Les deux
Cas le plus fréquent pour un vrai produit. L’API reste le contrat métier. MCP est une façade vers la même logique : permissions, validation, transactions, domaine.
Même exemple, deux chemins
Bug CSV → card. REST : workflow codé, appel API si le résultat l’exige. MCP : l’agent choisit les tools ; l’API sous-jacente peut rester identique.
| Situation | REST | MCP | Hybride |
|---|---|---|---|
| Backend web | Oui | Non | Non |
| Webhook | Oui | Non | Non |
| Automatisation déterministe | Oui | Non | Non |
| Traitement batch | Oui | Non | Non |
| Agent, un seul appel connu | Oui | opt. | Non |
| Agent qui choisit parmi des capacités | Non | Oui | Oui |
| Plusieurs hosts IA | Non | Oui | Oui |
| API déjà stable + agents | Oui | Non | Oui |
| Outils agents + API publiques | Oui | Oui | Oui |
| Transactions métier critiques | Oui | Non | Oui |
Règle simple : REST si le logiciel sait exactement quoi appeler. MCP si le modèle doit découvrir ou sélectionner la capacité. Les deux si le produit a déjà une API et doit devenir exploitable par des agents.
Stellary
Stellary suit cette coexistence. La plateforme a une API produit et un serveur MCP natif en Streamable HTTP : https://api.stellary.co/mcp. GET pour la découverte ou la négociation, POST pour les requêtes MCP. L’identité passe par un PAT ou un token d’agent. Les permissions restent celles de Stellary.
Le serveur MCP ne remplace pas l’API produit. Il expose certaines capacités aux agents et clients MCP.
Pour brancher un client : connecter des agents via MCP. Pour le rôle de MCP dans les outils de code : ce que MCP change en 2026. Référence runtime : documentation MCP. Vue produit : serveur MCP Stellary. Pour le choix d’autonomie d’exécution : agent, workflow ou automatisation.
La question n’est pas « devons-nous migrer notre API vers MCP ? ». C’est : qui utilise cette capacité, et comment décide-t-il de l’appeler ?
REST et OpenAPI excellent pour un contrat explicite entre systèmes. MCP aide une application IA à découvrir et manipuler des capacités dans un cadre standardisé.
Pour un produit moderne avec utilisateurs, intégrations, automatisations et agents : API comme fondation. MCP comme interface destinée aux agents. Pas MCP à la place de REST — MCP au-dessus de REST, lorsque l’usage agentique le justifie.
FAQ
MCP remplace-t-il une API REST ?
Non. Ils peuvent coexister. Une API peut rester la fondation métier ; un serveur MCP expose certaines capacités aux agents IA.
Quand utiliser MCP plutôt qu’une API REST ?
Lorsque le modèle doit découvrir plusieurs capacités et choisir dynamiquement l’outil adapté à sa mission.
Quelle est la différence entre MCP et OpenAPI ?
OpenAPI décrit un contrat d’API HTTP. MCP définit des primitives pour les applications IA (tools, resources) et un protocole pour les découvrir et les utiliser.
Un agent IA peut-il utiliser directement une API REST ?
Oui. MCP n’est pas obligatoire. Une API REST peut être appelée directement, ou encapsulée comme outil dans une architecture agentique.
MCP est-il plus lent que REST ?
Pas nécessairement au niveau du protocole. Une architecture agentique ajoute souvent des étapes (modèle, sélection, exécution, analyse). Un appel API direct reste préférable sans décision dynamique.
MCP est-il plus sécurisé qu’une API avec API key ?
La comparaison n’est pas directe. MCP est un protocole ; une API key est un mécanisme d’authentification. Dans les deux cas : identité, permissions, moindre privilège.
MCP utilise-t-il obligatoirement Streamable HTTP ?
Pour les serveurs MCP distants, Streamable HTTP est le transport HTTP standard actuel. D’autres modes, notamment locaux, existent selon l’environnement.
Faut-il transformer tous ses endpoints REST en tools MCP ?
Non. Exposez uniquement les capacités utiles aux agents, avec des descriptions et schémas clairs, plutôt que de recopier toute l’API.
