MCP vs API REST : quelle architecture choisir pour des agents IA ?
MCP ou API REST pour un agent IA ? Choisissez selon qui décide de l’opération : le code, le modèle, ou les deux dans une architecture hybride.
10 min de lecture
MCP change les outils de code IA en leur donnant un moyen standard de découvrir du contexte et des outils hors de l’éditeur, puis d’appeler ces outils au travers d’un protocole défini.
Un assistant de code peut alors devenir un agent qui lit une issue, consulte des erreurs de production, retrouve des décisions projet, met à jour le delivery et renvoie des preuves, sans intégration spécifique pour chaque client.
MCP ne rend pas tous les clients équivalents. Il ne sécurise pas un serveur non fiable. Et il ne remplace ni les permissions, ni les approbations, ni l’observabilité, ni une API produit bien conçue.
Ce guide a été révisé le 27 juillet 2026 à partir des documentations officielles de MCP, Cursor, Anthropic, Visual Studio Code et GitHub.
Ce que MCP standardise
L’architecture officielle de MCP repose sur un modèle client-serveur :
- l’hôte est l’application IA, par exemple un IDE ou un agent de code ;
- le client maintient une connexion entre cet hôte et un serveur MCP ;
- le serveur expose les capacités et les données d’un système externe.
Le protocole définit l’initialisation de la connexion, la négociation des capacités, la découverte des primitives, les requêtes et le retour de résultats structurés. Il s’articule actuellement autour de trois primitives serveur :
| Primitive MCP | Ce qu’elle expose | Exemple pour le code |
|---|---|---|
| Tools | Fonctions que le modèle peut appeler | Interroger Sentry, créer une carte projet ou lancer une mission gouvernée |
| Resources | Contexte que le client peut lire | Charger un brief technique, un schéma, un runbook ou une décision projet |
| Prompts | Modèles d’interaction réutilisables | Démarrer une revue de release ou un triage d’incident |
MCP définit aussi les transports. Les serveurs locaux utilisent souvent stdio, tandis que les services distants utilisent généralement Streamable HTTP. La négociation des capacités évite qu’un client tente d’utiliser une fonction absente d’un serveur.
Premier changement concret : un outil IA découvre les capacités du serveur au lieu de dépendre d’un long prompt qui décrit informellement une intégration.
Comment MCP transforme un workflow de code
Prenons la demande : « Corrige la régression de checkout signalée dans notre board de delivery. »
Sans systèmes connectés, le développeur ou l’agent doit réunir manuellement l’issue, la release concernée, les logs, les décisions d’architecture et les critères d’acceptation. L’outil peut produire un patch plausible tout en ignorant le contexte opérationnel.
Avec des serveurs MCP bien conçus, le workflow peut devenir :
- Lire la carte projet et ses critères d’acceptation.
- Retrouver la décision d’architecture et le runbook pertinents.
- Interroger le suivi d’erreurs pour la release et la stack trace.
- Inspecter et modifier le dépôt avec les outils natifs du client de code.
- Exécuter les tests et collecter le résultat.
- Proposer une mise à jour du statut pour approbation humaine.
- Attacher les preuves à la source de vérité.
Toutes les étapes n’ont pas besoin de MCP. L’édition du dépôt et le terminal peuvent rester des capacités natives du client. MCP sert de couche de connexion vers le contexte et les actions externes.
Clients MCP pour le code IA en 2026
Le support est assez large pour faire de MCP un vrai critère d’achat, mais les implémentations diffèrent.
| Client | Rôle MCP documenté | À vérifier avant déploiement |
|---|---|---|
| Cursor | Connecte outils et données externes par des serveurs locaux ou distants | Primitives, transport, authentification et configuration du workspace |
| Claude Code | Connecte les sessions de code aux outils et données externes | Portée de configuration, permissions, limites de sortie et confiance du serveur |
| Visual Studio Code | Ajoute tools, resources, prompts et interactions aux workflows agentiques | Demandes de confiance, politiques d’organisation, sandbox et outils activés |
| GitHub Copilot | Rend les serveurs configurés accessibles aux surfaces Copilot compatibles | Politiques du dépôt, accès cloud, secrets et listes d’outils autorisés |
| Stellary | Expose contexte projet, actions de board, signaux cockpit, missions d’agents et outils de plugins via Streamable HTTP | Identité humaine ou agent, autonomie, approbations et périmètre du workspace |
« Compatible MCP » ne signifie pas que tous les clients proposent les mêmes primitives, transports, flux d’authentification ou expériences d’approbation.
Ce que MCP améliore réellement
Un contexte vivant et adressable
Un prompt contient un instantané. Une resource ou un tool MCP peut récupérer l’état actuel d’un projet, incident, document ou service au moment où l’agent en a besoin.
Cela réduit le copier-coller et aide à ancrer le modèle dans la source de vérité. Le serveur doit toutefois rester ciblé : trop de contexte non filtré peut dégrader le résultat.
Des outils réutilisables entre plusieurs clients
Un serveur peut exposer la même surface protocolaire à plusieurs hôtes compatibles. Il devient moins nécessaire de reconstruire une intégration par éditeur ou agent.
La portabilité reste relative. Les clients diffèrent sur la configuration, les fonctions prises en charge, les confirmations, le sampling et la présentation des résultats.
Des workflows qui traversent les systèmes
Le travail de code ne s’arrête pas à un fichier modifié. Il faut aussi lire des tickets, inspecter des déploiements, mettre à jour la documentation, demander une revue et communiquer le statut.
MCP fournit une manière standard de franchir ces frontières. Dans Stellary, un agent externe peut par exemple réclamer une mission en attente via le serveur MCP, lire le contexte des cartes et documents, exécuter les outils permis, puis terminer ou faire échouer la mission tout en synchronisant le board.
Une gouvernance plus proche de l’action
Un serveur peut exposer des outils plus étroits qu’un token API généraliste ou qu’un shell sans limite. Le produit peut appliquer identité, périmètre du workspace, politique d’autonomie et règles d’approbation avant qu’une écriture atteigne la source de vérité.
Cette protection est plus robuste qu’une consigne de sécurité cachée dans un prompt système. L’application doit être faite par le serveur et la couche de politique produit.
Ce que MCP ne résout pas
MCP ne fournit pas automatiquement :
- un raisonnement exact ou une sélection fiable des outils ;
- des permissions au moindre privilège ;
- une protection contre le contenu non fiable ;
- une approbation humaine pour les actions importantes ;
- l’idempotence, les retries ou les transactions ;
- une piste d’audit complète ;
- une logique métier propre ;
- une mémoire projet durable ;
- un comportement identique entre clients.
Le protocole définit l’échange des capacités. Le serveur décide ce qu’un outil peut faire, le client décide comment le présenter et l’appeler, et le produit sous-jacent reste responsable de l’autorisation et de l’intégrité des données.
Questions de sécurité avant de connecter un serveur
La documentation officielle propose un modèle d’autorisation MCP pour les serveurs distants protégés et recommande HTTPS, des scopes minimaux, un stockage sûr des tokens et l’absence de credentials dans les logs.
Vérifiez :
- Qui opère le serveur ? N’installez que des serveurs de confiance.
- Quelle identité est utilisée ? Préférez un utilisateur nommé ou une identité d’agent dédiée à un secret partagé.
- Quel est le périmètre ? Limitez workspace, projet, dépôt et capacités.
- Quels outils écrivent ? Séparez lectures, écritures réversibles, communication externe et actions destructives.
- Où les approbations sont-elles appliquées ? Une confirmation client est utile ; une politique côté serveur est plus forte.
- Du contenu non fiable atteint-il le modèle ? Issues, pages web, logs et documents peuvent contenir des injections de prompt.
- Qu’est-ce qui est enregistré ? Conservez outil, acteur, entrées, résultat, erreur et décision d’approbation.
- Comment les credentials sont-ils traités ? Aucun secret durable ne doit entrer dans un fichier versionné ou la sortie d’un outil.
Comment évaluer une intégration MCP
Ne notez pas un produit sur un simple « MCP : oui ou non ». Rejouez un vrai workflow et contrôlez le chemin complet.
1. Contexte utile
Le client retrouve-t-il le vrai brief, l’état actuel des cartes, les décisions et la documentation pertinente sans saturer le contexte ?
2. Contrats d’outils clairs
Les noms et descriptions rendent-ils l’usage évident ? Les entrées sont-elles typées et bornées ? Une écriture renvoie-t-elle un identifiant stable et un résultat clair ?
3. Identité et permissions
Pouvez-vous distinguer un humain d’un agent de service et limiter ce dernier à un projet et quelques outils ?
4. Approbations
Les lectures peuvent-elles s’exécuter directement tandis que les écritures importantes deviennent des propositions ? L’approbation est-elle appliquée dans le produit ?
5. Gestion des échecs
Que se passe-t-il lors d’un timeout, d’un token expiré, d’une ressource absente ou d’un retry ? Une intégration crédible renvoie une erreur exploitable plutôt qu’un succès partiel silencieux.
6. Preuves et observabilité
Un reviewer voit-il les outils exécutés, les enregistrements modifiés et les tests qui soutiennent le résultat ?
7. Portabilité entre clients
Testez configuration, authentification, découverte et approbations dans chaque client visé. Ne supposez pas un comportement identique.
MCP ou API REST ?
Utilisez MCP lorsqu’un client IA doit découvrir du contexte et choisir dynamiquement ses outils. Utilisez une API REST lorsqu’un logiciel a besoin d’un endpoint déterministe et d’un flux explicite.
De nombreux produits sérieux ont besoin des deux :
- REST pour le provisioning, le CRUD prévisible, les webhooks et les intégrations backend ;
- MCP pour la découverte par le modèle, la récupération de contexte et l’exécution d’outils.
Les deux surfaces doivent partager les mêmes règles d’autorisation et la même source de vérité. Stellary documente cette séparation dans ses références MCP et API REST.
Verdict
MCP est passé d’un pattern d’intégration intéressant à une composante pratique de la stack de code IA.
Sa vraie valeur n’est pas « plus d’outils », mais un contrat plus clair entre un client IA et les systèmes qui contiennent le contexte projet et les actions opérationnelles.
Les meilleures intégrations MCP en 2026 ont cinq qualités :
- un contexte ciblé ;
- des outils étroits et bien décrits ;
- une identité et un périmètre explicites ;
- des permissions et approbations appliquées côté serveur ;
- des preuves qui permettent à un humain de vérifier le résultat.
Si ces fondations manquent, MCP ne fait que standardiser une intégration faible. Si elles sont présentes, il aide les agents de code à travailler entre dépôt, système projet, documentation et delivery sans perdre le contrôle.
FAQ
Qu’est-ce que MCP dans un outil de code IA ?
Model Context Protocol est un protocole ouvert qui permet à un hôte de code IA de se connecter à des serveurs externes, de découvrir leurs capacités, de lire des ressources contextuelles et d’appeler des outils dans un échange client-serveur standard.
MCP permet-il à un agent IA de modifier du code ?
Oui, si un serveur connecté expose un outil d’édition. En pratique, de nombreux clients modifient le dépôt avec leurs outils natifs et utilisent MCP pour les systèmes externes : boards projet, documentation, suivi d’erreurs, bases de données ou déploiements.
MCP est-il sécurisé par défaut ?
Non. Une équipe doit toujours utiliser des serveurs de confiance, des identités fortes, des scopes minimaux, des credentials protégés, des règles d’approbation, des défenses contre l’injection de prompt et des résultats auditables.
Un produit doit-il proposer MCP ou une API REST ?
Souvent les deux. REST convient aux intégrations logicielles déterministes et au provisioning ; MCP aux clients IA qui découvrent dynamiquement du contexte et des outils. Les deux doivent appliquer les mêmes permissions et règles produit.
