MCP ou API pour un agent métier : où placer la frontière d’autorisation ?

Le catalogue de l’assistant contient « préparer un devis ». Le gestionnaire voit le bon nom, le modèle propose une demande et l’outil répond. Mais le compte technique derrière cette capacité peut accéder à plusieurs sociétés alors que le gestionnaire n’en traite qu’une. Le symptôme apparaît au premier objet hors périmètre : un branchement réussi laisse passer une opération que l’utilisateur ne devrait pas pouvoir obtenir.

En pratique, le choix entre MCP et une API ne résout pas cette frontière. MCP peut organiser l’exposition d’une capacité à l’agent, tandis qu’une API existante fournit l’opération métier en aval. Pour une intégration IA dans le système d’information, il faut identifier le service qui vérifie l’identité, l’objet et les droits avant l’effet, puis éprouver les refus par les deux entrées envisagées.

Nous comparons ici deux routes HTTP locales, une enveloppe API et une enveloppe JSON-RPC d’appel d’outil MCP. Elles utilisent la même politique sur des demandes fictives. Seize essais ont été exécutés, sans modèle, ERP ni serveur OAuth complet. Pour intégrer une IA sur mesure à vos interfaces, prenez une même demande autorisée et sa variante hors périmètre : les deux entrées doivent conserver la décision d’accès, même si leurs statuts HTTP et enveloppes d’erreur diffèrent.

Pour qui comparer les interfaces à mission constante

Partir de la capacité que le métier veut ouvrir

La comparaison concerne une DSI qui expose des opérations à plusieurs assistants, un éditeur qui souhaite brancher son application ou une équipe qui hésite entre un adaptateur dédié et un serveur d’outils partagé. Le point de départ est une tâche délimitée : préparer un brouillon à partir d’une demande accessible. Lire le catalogue complet, créer une commande et envoyer une offre au client constituent d’autres capacités, avec d’autres conséquences.

Définissez utilisateur, société, objet et résultat avant de choisir une interface. Un assistant peut avoir besoin de chercher une demande sans être autorisé à l’exporter, puis de préparer un brouillon sans pouvoir le transmettre. Réunir ces opérations sous une permission globale « accès ERP » empêche de comparer ce que chaque architecture ouvre effectivement. Le nom de la connexion ne donne aucune information suffisante sur sa portée.

Différer MCP quand l’interopérabilité n’apporte pas encore de valeur

Pour un seul écran interne et une opération déjà appelée par le backend, une API maîtrisée peut fournir le premier chemin utile. Ajouter un protocole, un catalogue et un cycle de compatibilité sans consommateur distinct crée du travail de maintenance. À l’inverse, plusieurs clients d’agents peuvent justifier une interface commune, si chacun prend en charge les capacités, l’autorisation et la version de protocole retenues.

La décision dépend donc des consommateurs et des contrats, pas d’une opposition universelle entre ancien et nouveau. Évaluez ce que le serveur d’outils réutilise réellement : description, schéma, transport et restitution. Les règles commerciales devront rester maintenues dans les deux cas. Un besoin de découverte d’outils ne justifie pas de déplacer les permissions métier dans une description libre destinée au modèle.

Distinguer protocole, adaptateur et service métier

Dessiner les responsabilités plutôt que les logos

Le client de l’agent reçoit des définitions d’outils et émet des propositions d’appel. L’entrée du service reçoit une requête par MCP ou API, vérifie l’accès et transforme les paramètres. Le contrat métier précise la responsabilité de l’autorisation sur l’objet ; l’adaptateur aval applique ensuite l’opération permise. La sortie doit distinguer refus, préparation et résultat inconnu. Plusieurs rôles peuvent vivre dans le même déploiement sans devenir la même autorité.

Un ERP peut fournir une API native, un module partenaire ou une autre interface contrôlée. La présence d’un serveur MCP ne crée aucune capacité manquante dans ce logiciel. L’intégrateur vérifie comment lire les demandes, créer les brouillons, retrouver un résultat et limiter les droits. Une opération rendue visible à l’agent reste une adaptation de ces capacités ; elle ne doit pas être présentée comme un connecteur natif sans preuve.

Placer la règle avant le premier effet qu’elle protège

La frontière utile est l’endroit où une règle peut encore empêcher l’opération. Un contrôle effectué après la création distante peut constater une erreur, mais il ne protège plus cette création. Une restriction de société doit intervenir avant la lecture sensible ou l’écriture concernée. Quand le logiciel aval possède lui-même un contrôle adapté, conservez-le ; une vérification de façade ne doit pas devenir une raison d’élargir le compte distant.

La chaîne contexte, proposition et action ERP/CRM précise les objets et les autorités à relier. Notre comparaison conserve cette chaîne et change seulement son entrée. Cette discipline permet de demander si une migration de protocole maintient les mêmes refus, au lieu de conclure que l’architecture est sûre parce qu’elle possède davantage de composants.

Deux chemins vers la même préparation de devis

Garder opération et population identiques

Le système fictif connaît Alice, rattachée à la société A, et deux demandes : REQ-A dans A, REQ-B dans B. Alice possède initialement le droit de préparer un brouillon. L’entrée API reçoit request_id ; l’entrée MCP reçoit le même argument dans tools/call pour l’outil prepare_quote. Aucune des deux ne reçoit une société faisant autorité ni une identité choisie par le modèle.

Les deux entrées rejoignent la même fonction de préparation. Celle-ci charge la demande, consulte l’habilitation actuelle et compare la société. Le seul effet admis est un brouillon dans un enregistreur local en mémoire. Il n’existe ni tarification, ni réservation de stock, ni envoi client. Le choix de cette opération réduit la comparaison à une frontière inspectable et évite d’attribuer au protocole un comportement provenant d’un ERP que nous n’avons pas testé.

Nommer ce que le banc ne vérifie pas

Les requêtes traversent réellement un serveur HTTP sur la boucle locale. Les jetons synthétiques sont signés HMAC et vérifiés avec une horloge fixe. Le banc ne réalise pas de découverte, d’initialisation MCP complète, de consentement OAuth, de renouvellement de jeton ou de transport TLS. Il ne certifie donc ni une implémentation MCP conforme ni une infrastructure d’identité. Il vérifie les chemins et les refus explicitement présentés.

Les deux adaptateurs utilisent aussi le même processus et le même enregistreur. Aucun appel réseau ERP, secret de production, SDK fournisseur ou modèle n’est impliqué. Une recette d’intégration réelle doit ajouter les frontières réseau, les droits aval et les erreurs du logiciel choisi. Notre preuve reste utile pour examiner où l’application place l’autorité, mais elle ne remplace pas cette recette de bout en bout.

Vérifier le destinataire avant d’examiner la demande

Refuser un accès valide pour une autre ressource

Cas concret : un jeton correctement signé pour l’entrée API est présenté à l’entrée MCP. Le banc renvoie 401 et ne prépare rien. Sa signature ne suffit pas : son audience désigne l’autre ressource. Les deux audiences fictives sont distinctes, même si les routes rejoignent ensuite la même fonction. Accepter tout jeton du même émetteur ferait disparaître cette séparation avant le contrôle métier.

La spécification MCP d’autorisation, version 2026-07-28, décrit le cadre des transports HTTP protégés et la validation du destinataire. Elle distingue ce cadre des serveurs stdio locaux. Un déploiement choisit et teste son mécanisme d’accès ; il ne déduit pas l’autorisation de la simple présence de MCP. Les JWT du banc sont un support d’essai, pas un format obligatoire pour tout serveur.

Séparer les accès entrant et aval

Un jeton destiné au serveur d’outils ne devient pas automatiquement le jeton de l’ERP. Les bonnes pratiques de sécurité MCP interdisent le token passthrough décrit par la spécification. L’adaptateur aval doit utiliser un accès réellement destiné à sa ressource, selon un mécanisme pris en charge. Une délégation ou un échange de jeton reste à vérifier auprès du système d’identité et de l’interface concernés.

Dans notre démonstration, l’aval est un enregistreur sans jeton : aucune délégation n’est éprouvée. Dans votre SI, inscrivez les deux destinataires et les deux contrôles dans le dossier d’architecture. Le modèle reçoit les résultats utiles et les réserves, sans prendre possession des secrets. Une capacité technique étendue doit rester bornée par l’opération autorisée pour l’utilisateur au moment où le service l’exécute.

Autoriser l’objet à partir d’une identité vérifiée

Retrouver la société côté service

Second exemple concret : Alice transmet REQ-B avec un jeton valide, la bonne audience et la portée de préparation. La fonction commune refuse object_denied avant l’enregistreur. La portée donne accès à une catégorie d’opérations ; elle n’affirme pas qu’Alice peut agir sur toutes les demandes. La société de REQ-B vient du registre de démonstration, et celle d’Alice de l’habilitation chargée par le service.

Un argument « société A » envoyé à côté de REQ-B ne doit pas redéfinir cette appartenance. Un identifiant d’objet est une cible à contrôler, pas une preuve de possession. Dans une intégration réelle, la résolution peut dépendre de plusieurs référentiels ; il faut alors documenter quel service fait autorité et ce qui arrive lorsqu’un rattachement manque. Une réponse ambiguë doit suspendre l’opération plutôt qu’élargir silencieusement le périmètre.

Revérifier l’habilitation avant la préparation

Le cas C07 retire le droit courant d’Alice tout en conservant un jeton valide. La préparation est refusée sous les deux enveloppes. L’essai montre le contrôle de cette habilitation applicative en mémoire ; il ne prouve pas une propagation de révocation dans un annuaire distant. Pour un service réel, la fraîcheur et la source du droit doivent être définies avec le responsable d’identité, ainsi que l’issue quand leur vérification est indisponible.

Une fenêtre de validité du jeton et une règle métier actuelle protègent des choses différentes. Le compte peut encore accéder au serveur alors qu’une mission ou une opération a été retirée. L’application garde cette distinction dans ses verdicts. La vérification des conditions ERP devenues périmées ajoute ensuite les versions et conditions commerciales qui doivent toujours correspondre à la proposition approuvée.

Exposer des outils étroits sans en faire des permissions

Réduire les paramètres qui peuvent déplacer l’autorité

L’opération du banc accepte exactement request_id. Un appel qui ajoute subject: bob est refusé pour arguments invalides. L’identité vient du jeton vérifié ; elle n’est pas reprise depuis une proposition de l’agent. Cette fermeture du schéma ne remplace pas l’autorisation d’objet, mais elle retire une voie de confusion entre paramètre métier et identité faisant autorité.

La spécification MCP des outils présente leur schéma, leurs résultats et les contrôles attendus côté serveur. Les descriptions et annotations ne constituent pas à elles seules une garantie de permission. Le refus applicatif des arguments d’outil invalides approfondit la validation de forme et de domaine ; ici nous contrôlons son maintien à travers les deux entrées.

Conserver le contrôle même si l’outil est masqué

Un client peut filtrer le catalogue affiché à Alice pour ne montrer que ses opérations utiles. Ce filtre améliore l’expérience et limite les propositions inappropriées. Il ne protège pas le service contre une requête directe, une définition conservée en cache ou un autre client. La validation de l’appel doit donc retrouver la permission applicable sans supposer que la découverte a déjà rendu la demande légitime.

La description de prepare_quote explique aussi sa sortie : un brouillon local, sans envoi ni commande créée. Le nom ne doit pas cacher des effets supplémentaires. Si le service ajoute plus tard une transmission, son contrat et sa recette changent. Une compatibilité de schéma JSON peut subsister alors que la conséquence métier devient différente ; c’est précisément le changement que le responsable produit doit rendre visible aux consommateurs.

Seize essais HTTP réellement exécutés

Écrire les refus avant de brancher les deux entrées

Huit situations manuscrites sont rejouées pour chacune des deux architectures. L’enregistreur est vidé et l’habilitation restaurée entre les cas. La priorité est de refuser avant effet les sept demandes inadmissibles : objet étranger, identité fournie en argument, audience incorrecte, expiration atteinte, portée manquante, droit retiré et signature altérée. Le cas nominal doit, lui, produire un seul brouillon de REQ-A, société A, attribué à Alice.

Le seuil de réussite de ce banc est zéro effet sur les refus et un seul effet sur chaque passage nominal. Ces valeurs définissent des assertions locales, pas un taux de sécurité en production. Deux brouillons sont constatés dans deux cas indépendants ; ils ne proviennent pas du rejeu d’une seule action. Le banc ne teste ni idempotence, ni concurrence, ni reprise après crash, qui demanderaient des scénarios et une persistance adaptés.

Rapprocher la réponse et l’absence d’effet

Le journal conserve architecture, cas, statut HTTP, motif et compteur d’effets. Un refus affiché serait insuffisant si le brouillon avait déjà été créé. Les assertions vérifient donc l’enregistreur après chaque requête. Le succès nominal rapproche aussi demande, société et sujet ; accepter un seul objet ne suffirait pas si celui-ci appartenait à REQ-B ou avait été attribué à une identité proposée dans les arguments.

La comparaison ne mesure aucune latence, aucun gain d’interopérabilité ni coût de déploiement. Elle démontre que ces deux entrées réduites gardent les mêmes décisions métier dans les cas présentés. Pour sélectionner un serveur réel, ajoutez les tests de son cycle de connexion, des mécanismes d’identité et des capacités annoncées. Le résultat d’une simulation correctement bornée ne doit pas devenir une promesse de compatibilité avec tout assistant.

Distinguer refus HTTP et erreur d’outil

Ne pas prendre HTTP 200 pour un succès métier

Paradoxalement, l’entrée MCP du banc répond HTTP 200 sur C02 alors que l’outil refuse l’objet. Le transport a pu livrer une réponse, mais la préparation est interdite. À l’inverse, C04 échoue avant l’appel métier avec HTTP 401. Le consommateur doit lire les deux niveaux. Compter toutes les réponses 200 comme des préparations réussies transformerait trois refus métier en succès fictifs dans chaque exécution de cette entrée.

{
  "jsonrpc": "2.0",
  "id": "C02",
  "result": {
    "resultType": "complete",
    "isError": true,
    "content": [
      { "type": "text", "text": "object_denied" }
    ]
  }
}

Le résultat ci-dessus est celui du cas exécuté. Il ne retourne aucun contenu de REQ-B. Dans le produit, le motif présenté à l’utilisateur peut être moins détaillé afin de ne pas révéler l’existence d’un objet inaccessible. Le support garde une référence de trace adaptée à ses propres droits. Le refus doit rester compréhensible sans fournir au modèle des données que l’autorisation vient précisément d’écarter.

Choisir une reprise proportionnée au motif

Les réponses d’accès invalide et de portée insuffisante sont distinguées dans la RFC 6750 sur les jetons Bearer. Dans notre contrat, un objet interdit ne justifie pas une nouvelle tentative avec un identifiant deviné. Une expiration demande un traitement d’identité approprié ; un argument invalide peut demander une correction ; un droit retiré impose d’arrêter l’opération ou de suivre un circuit métier autorisé.

Le contrat du workflow distingue correction d’argument et extension de droit. Une demande d’accès plus large doit correspondre à une mission explicite et rester soumise aux mécanismes d’autorisation prévus. Les reprises sont bornées et tracées. Si la situation reste interdite, la sortie de repli est une abstention opérationnelle ou une orientation vers le gestionnaire compétent. Une boucle de tentatives jusqu’à obtenir un effet contournerait précisément le refus que le service doit maintenir.

Maintenir les contrats et expliquer les refus

Versionner une capacité au-delà de son enveloppe

La version du protocole, le schéma de l’outil, la politique métier et l’interface aval peuvent évoluer indépendamment. Enregistrez leur correspondance dans le dossier de recette. Un nouveau client MCP doit garder les mêmes refus d’objet ; une API enrichie ne doit pas introduire un champ qui reprend l’identité du corps. La migration se juge sur les décisions et les effets, même quand les paramètres nominaux continuent de fonctionner.

Le coût caché apparaît quand deux adaptateurs recopient chacun les règles commerciales. Une correction sur un chemin peut laisser l’autre permissif, et le support doit reconstituer quelle version a traité le dossier. Une politique commune, lorsque l’architecture le permet, réduit ce risque de divergence. Elle ne dispense pas de tester chaque entrée : en-têtes, désérialisation et restitution peuvent introduire leurs propres défauts avant ou après la décision partagée.

Donner au support une preuve utilisable sans secret

La supervision relie requête, outil, identité vérifiée, cible, version de politique, verdict et effet confirmé. Elle conserve des références et motifs appropriés, sans journaliser un jeton complet. Les bonnes pratiques JWT de la RFC 8725 rappellent notamment l’importance des validations adaptées au contexte d’utilisation. Dans le banc, une signature, un émetteur ou une audience incorrects empêchent l’accès avant la politique métier.

Un runbook distingue défaut d’accès, paramètre refusé, objet interdit et résultat aval inconnu. Ce dernier cas n’est pas testé par l’enregistreur local : il exige un rapprochement avec le logiciel distant. L’automatisation de la réponse ne doit pas réécrire l’historique d’un effet incertain en « refus sans effet ». Avant de relancer une création, le service cherche la preuve nécessaire selon les capacités réelles du destinataire.

Erreurs fréquentes quand on ajoute MCP au SI

Déplacer une permission dans un élément descriptif

La première erreur consiste à écrire dans le prompt « ne travaille que dans la société A » alors que le serveur accepterait REQ-B. La deuxième consiste à retirer un outil du catalogue et à laisser son appel direct autorisé. La troisième consiste à accepter une identité envoyée dans les arguments pour compenser l’absence de contexte authentifié. Ces dispositifs peuvent orienter une proposition, mais ils ne ferment pas la frontière avant l’effet.

Un signal faible est la présence de sociétés et d’utilisateurs dans des paramètres censés faire autorité, sans résolution côté service. Un autre est l’impossibilité de montrer un refus avec zéro effet dans les traces. Ils invitent à examiner la chaîne plutôt qu’à améliorer seulement la description de l’outil. Une formulation plus précise peut réduire les appels inadéquats ; elle ne constitue pas la validation de sécurité qui leur manque.

Comparer deux architectures qui n’offrent pas les mêmes droits

Donner à l’entrée API un compte limité à A et au serveur MCP un compte administrateur rend la comparaison trompeuse. La différence observée provient alors de l’accès aval autant que du protocole. Fixez droits, objets et opération pour évaluer le maintien de la frontière. Si une architecture exige davantage de privilèges, cette exigence devient un arbitrage à documenter, pas un avantage de compatibilité à cacher.

Une autre erreur serait de considérer les seize essais comme un audit complet. Ils ne couvrent pas discovery malveillante, SSRF, stockage de secrets, client compromis ou autorisation déléguée distante. Ces risques demandent leurs contrôles et leurs preuves. La décision reste proportionnée au périmètre testé : deux enveloppes locales peuvent garder la même politique, tandis que l’industrialisation des serveurs ajoute d’autres frontières à vérifier.

Plan d’action pour choisir une première interface

Commencer par une opération inspectable

Sélectionnez une capacité dont les objets admissibles et les conséquences sont connus du métier. Le propriétaire nomme ce qui doit être refusé, l’IT décrit les interfaces disponibles et le produit identifie les consommateurs attendus. La comparaison conserve une référence de mission commune. Elle doit permettre une décision pratique : ouvrir une API dédiée, exposer une capacité MCP, maintenir les deux ou différer une option sans bénéfice identifié.

1. Documenter opération, utilisateurs, sociétés et effet autorisé. Écarter du premier périmètre les transmissions et créations irréversibles qui ne possèdent pas encore de recette ; préciser ce que le brouillon signifie pour le gestionnaire.
2. Associer chaque couche à son autorité : accès entrant, identité vérifiée, rattachement d’objet, droit métier, conditions d’exécution et interface aval. Inscrire les sources de ces décisions, leur fraîcheur et les réponses prévues lorsqu’elles manquent.
3. Rapprocher les deux chemins sur un même jeu de demandes et de droits. Vérifier un cas nominal puis les refus de cible, portée, expiration et identité proposée ; constater les effets réellement enregistrés, pas seulement les messages affichés.
4. Qualifier les consommateurs et versions supportées avant d’ajouter un catalogue partagé. Tester l’initialisation, le transport, l’autorisation et les résultats du serveur réel, puis distinguer ces preuves de celles d’un simple adaptateur local.
5. Décider avec le responsable métier et la DSI quelle interface ouvre la capacité. Conserver contrat, limites, traces, propriétaire de maintenance et critères de retrait ; refaire la comparaison quand une évolution modifie les droits ou les conséquences.

Le dossier de sortie comprend une matrice d’accès, les parcours exécutés, les refus et leur absence d’effet. Il précise aussi les contrôles encore non réalisés. Si une opération requiert un privilège aval incompatible avec la mission, le premier résultat peut être une révision de l’adaptateur ou une limitation du service. Un raccordement rapide ne justifie pas de rendre disponible une capacité dont la frontière reste indéfinie.

Maintenir un propriétaire de la décision après l’ouverture

Le service métier garde le propriétaire de ses règles ; l’équipe d’intégration maintient transformations et interfaces ; l’équipe produit porte la restitution des refus. Cette répartition évite que chaque client invente une nouvelle manière d’autoriser la même demande. Les incidents doivent pouvoir revenir à une politique et à un objet, même lorsque le modèle, l’écran ou le protocole utilisé ne sont plus ceux de la première recette.

Pour la première ouverture, comparez les motifs de refus rencontrés aux attentes du pilote. Une hausse d’arguments invalides peut révéler une description confuse ; des refus d’objet peuvent signaler un mauvais rattachement ou une demande réellement interdite. Le responsable examine les preuves avant d’élargir les droits. Cette observation produit des décisions sur l’interface et la mission sans transformer le nombre de refus en score de performance du modèle.

Guides complémentaires sur contexte et exécution

Construire l’amont de l’outil connecté

Relier un agent IA à l’ERP et au CRM organise la provenance des demandes, les correspondances de comptes et les conditions commerciales. Cette préparation aide à choisir les lectures qui alimentent une proposition sans donner au middleware l’autorité de décider de la société ou du prix au seul motif qu’il transporte les données.

La comparaison API/MCP peut ensuite conserver ces autorités et tester ce qui traverse chacune de ses entrées. Une modification de protocole ne doit pas supprimer les réserves de source ou confondre un contexte consulté avec un accord actuel. Les refus de permission et les écarts de conditions conservent des motifs distincts pour orienter la reprise vers la personne compétente.

Définir ce que l’appel a réellement obtenu

Le contrat séparant proposition, autorisation et exécution précise les frontières après la réception d’un appel. Une requête correctement adressée et une cible accessible ne prouvent pas qu’un effet distant a réussi. Le dossier doit distinguer préparation, décision, transmission, résultat confirmé et résultat inconnu avant que l’assistant annonce une action terminée.

Cette séparation complète les essais d’accès présentés ici. Le protocole peut livrer une réponse d’erreur d’outil ou un résultat structuré ; le service doit encore expliquer la portée métier de cette réponse. La recette relie ainsi les permissions d’entrée à une restitution fidèle, au lieu de demander au modèle d’inférer le statut commercial à partir d’un code de transport.

Conclusion : le service garde l’autorité sur l’effet

MCP et une API peuvent appartenir à la même chaîne : l’un expose une capacité à l’agent, l’autre fournit une opération existante au service d’intégration. Le choix utile dépend des consommateurs et des contrats disponibles. La permission sur une société, une demande ou une création doit rester vérifiable avant l’effet, indépendamment du nom et de la visibilité de l’outil.

Seize requêtes ont traversé notre banc HTTP local : deux préparations nominales dans des cas indépendants et quatorze refus avec zéro effet. Le jeton, la portée, les arguments et l’objet sont distingués ; une réponse MCP HTTP 200 peut porter un refus métier. Cette preuve ne certifie ni OAuth complet, ni compatibilité MCP de bout en bout, ni comportement d’un ERP ou d’un modèle absent du banc.

L’intégration IA aux interfaces du SI qualifie ensuite les mécanismes réels : autorisation, délégation éventuelle, capacité aval et preuve de résultat. Une évolution d’outil doit conserver les refus et rendre visible tout changement de conséquence. La qualité de l’architecture se juge aussi à l’action qu’elle sait empêcher et expliquer.

Dawap vous accompagne dans le raccordement d’une IA sur mesure à une opération de votre logiciel en comparant son entrée API et son éventuelle exposition MCP. Avec la DSI et l’intégrateur, nous identifions l’utilisateur, l’objet accessible et le service qui peut refuser avant l’effet. Le pilote conserve les réponses aux mêmes demandes interdites sur les deux chemins, puis complète la recette locale par l’authentification et les interfaces réellement utilisées.