MCP ou API : comment connecter un agent IA sans perdre le contrôle

MCP ne remplace pas une API. Une API expose les capacités d’un système selon un contrat conçu pour des logiciels. Un serveur MCP présente certaines de ces capacités à une application d’intelligence artificielle sous une forme standardisée, découvrable et accompagnée de métadonnées. Dans beaucoup de projets, l’architecture solide combine donc les deux : l’API reste la frontière métier, tandis que MCP sert d’adaptateur pour un ou plusieurs clients IA.

Le choix devient concret lorsque l’on nomme le consommateur. Une application interne déterministe qui appelle trois opérations stables a rarement besoin d’un serveur MCP. À l’inverse, plusieurs assistants qui doivent découvrir les mêmes outils, ressources et descriptions peuvent justifier cet adaptateur. La question n’est pas « quelle technologie est la plus moderne ? », mais « quel contrat doit rester stable, pour qui, et avec quel niveau de contrôle ? ».

Réponse en bref

Gardez une API directe lorsque vous contrôlez un seul client, que les appels sont connus à l’avance et que le code doit gérer précisément les erreurs, les reprises et les performances.

Ajoutez MCP lorsque plusieurs applications IA doivent découvrir un catalogue cohérent d’outils ou de ressources, lorsque vous voulez séparer le client conversationnel du système métier, ou lorsque la portabilité entre plusieurs hôtes IA a une valeur réelle.

Choisissez une architecture hybride pour une action importante : l’agent appelle un outil MCP étroit, le serveur valide les arguments et transmet une commande à l’API métier. L’API applique encore les droits, les règles, l’idempotence et le journal d’audit. Le modèle ne reçoit ni un accès général au système ni la responsabilité de décider seul si l’action est autorisée.

Situation	Choix de départ
un service, un client, opérations fixes	API directe
plusieurs assistants, outils partagés	MCP devant les API
lecture de documentation ou de schémas	ressource MCP ou API de lecture
écriture sensible ou irréversible	API métier contrôlée, éventuellement appelée par un outil MCP
prototype local limité	MCP local possible, avec permissions minimales
intégration publique pour développeurs	API documentée d’abord, adaptateur MCP ensuite si le besoin est prouvé

La prochaine action utile consiste à remplir une fiche par capacité : consommateur, entrée, sortie, droits, effet externe, erreur, reprise et trace. Cette fiche indique généralement si MCP apporte une couche utile ou seulement une nouvelle dépendance.

Deux contrats qui ne répondent pas à la même question

Une API HTTP décrit des chemins, des opérations, des paramètres, des réponses et des mécanismes de sécurité. OpenAPI permet de formaliser ce contrat. HTTP fournit les méthodes, les statuts et les règles de base. Le producteur décide comment représenter un client, une commande, un refus ou une erreur.

MCP définit un échange entre un hôte IA, un client MCP et un serveur MCP. La documentation officielle distingue notamment :

• les tools, fonctions que l’application IA peut proposer au modèle ;
• les resources, informations que l’application peut lire et ajouter au contexte ;
• les prompts, modèles d’interaction explicitement proposés à l’utilisateur ;
• le transport local par entrée-sortie standard et le transport distant par HTTP ;
• la découverte des capacités et leur négociation selon la version du protocole.

Cette standardisation répond à une question précise : comment présenter du contexte et des actions à plusieurs applications IA sans inventer un connecteur différent pour chaque hôte ?

Elle ne définit pas votre modèle de données, votre règle de remise commerciale, votre calcul de stock, votre procédure de suppression ni votre droit interne. Ces décisions restent dans le système métier.

L’API reste la source de vérité opérationnelle

Supposons qu’un logiciel de gestion possède une opération create_invoice. L’API doit encore contrôler :

• l’identité de l’appelant ;
• le périmètre de son organisation ;
• les champs obligatoires ;
• les taux et règles applicables ;
• l’unicité de la commande ;
• les statuts autorisés ;
• la réponse en cas de doublon ;
• la trace qui permettra une réconciliation.

Présenter cette opération comme outil MCP ne supprime aucun de ces contrôles. La description de l’outil aide le modèle à choisir et à remplir un appel. Elle ne constitue pas une autorisation.

MCP est une façade orientée vers les applications IA

Un outil MCP utile porte un nom précis, une description limitée, un schéma d’entrée et, lorsque c’est pertinent, un schéma de sortie. Des annotations peuvent indiquer qu’une opération est en lecture seule, destructive ou idempotente. Ces indications améliorent l’expérience du client, mais la spécification rappelle qu’elles ne doivent pas remplacer les protections du serveur.

Un bon serveur MCP ne publie donc pas une copie brute de toutes les routes internes. Il expose un petit ensemble de capacités compréhensibles, stables et compatibles avec les permissions de l’utilisateur.

La matrice de décision en sept critères

Attribuez à chaque critère la valeur API, MCP ou hybride. Le but n’est pas de calculer un score universel, mais de rendre le choix explicable.

1. Nombre et nature des consommateurs

Si un seul programme maîtrisé appelle le service, un client API typé est souvent plus simple. Il connaît déjà les opérations et n’a pas besoin de les découvrir pendant une conversation.

MCP devient intéressant lorsque plusieurs hôtes IA doivent accéder à la même capacité : assistant interne, environnement de développement, interface conversationnelle ou agent spécialisé. L’adaptateur évite de réécrire la description et le schéma pour chaque client compatible.

Comptez les consommateurs réels, pas les intégrations imaginées. Une possibilité future sans calendrier ne justifie pas à elle seule une couche supplémentaire.

2. Stabilité du parcours

Une chaîne déterministe connue à l’avance se code bien avec une API :

1. lire la commande ;
2. valider ;
3. appeler le service ;
4. traiter la réponse ;
5. enregistrer le résultat.

MCP aide lorsque l’application IA doit choisir parmi plusieurs outils selon la demande. Cette souplesse a un coût : le choix de l’outil et la construction des arguments deviennent des éléments à évaluer.

Si le parcours ne doit jamais varier, ne demandez pas au modèle de le recomposer à chaque exécution.

3. Portée du catalogue

Une API publique peut contenir des dizaines ou des centaines d’opérations. Les exposer toutes à un modèle augmente le contexte, les ambiguïtés et la surface d’action.

Préférez un catalogue MCP réduit par rôle ou par mission. Un assistant de support peut obtenir find_order et prepare_refund_request, sans recevoir delete_customer ni une route administrative générique.

La réduction doit être appliquée côté serveur. Cacher un outil dans l’interface ne suffit pas si l’appel reste accepté.

4. Permissions et identité

Pour un serveur MCP distant, la spécification d’autorisation stable s’appuie sur des mécanismes OAuth et sur la découverte des serveurs d’autorisation. Les jetons doivent être destinés à la bonne ressource et les portées vérifiées.

Le point important pour le projet est plus simple : le serveur doit connaître l’utilisateur ou le service à l’origine de la demande et recalculer les droits à chaque appel sensible.

Le protocole sur l’identité et l’autorisation d’un agent IA détaille ensuite comment séparer l’identité de l’agent, celle de l’utilisateur et celle du service, puis organiser délégation, durée des droits et révocation.

Évitez le transfert aveugle d’un jeton reçu vers une API tierce. Les recommandations de sécurité MCP décrivent notamment les risques de confusion de rôles, de vol de jeton et de consentement mal lié au client. Une façade ne doit pas devenir un tunnel qui contourne le modèle d’autorisation du service final.

5. Effet externe et réversibilité

La lecture d’un article public et l’envoi d’un email n’ont pas le même risque. Classez les outils :

Classe	Exemple	Contrôle minimal
lecture publique	consulter une documentation	validation des entrées et limite de volume
lecture privée	lire un dossier autorisé	identité, périmètre et journal
préparation	créer un brouillon non envoyé	stockage séparé et statut explicite
écriture réversible	ajouter une étiquette	droits, idempotence et annulation
action externe	envoyer, publier, payer	approbation, destinataire visible et preuve d’exécution
destruction	supprimer définitivement	procédure dédiée, garde forte et solution de récupération si possible

MCP peut transmettre l’intention. L’exécution doit encore passer par les contrôles adaptés à sa classe.

6. Erreurs, délais et reprises

Une API mature possède des statuts, des erreurs structurées, des délais maximaux et parfois une clé d’idempotence. Le RFC 9457 propose un format de problèmes HTTP lisible par les machines pour décrire une occurrence d’erreur sans demander au client d’analyser une phrase libre.

L’outil MCP doit traduire les erreurs sans les masquer. Distinguez au minimum :

• argument invalide ;
• non autorisé ;
• ressource absente ;
• conflit ou doublon ;
• limite atteinte ;
• dépendance indisponible ;
• résultat incertain après interruption.

« L’outil a échoué » ne permet ni reprise sûre ni diagnostic. À l’inverse, exposer une trace interne complète peut divulguer des informations inutiles. Le contrat doit fournir ce que le client peut corriger et conserver le détail technique dans les journaux protégés.

7. Coût de maintenance

Une façade MCP ajoute une version de protocole, un serveur, des schémas, des descriptions, des tests de compatibilité et une surface de sécurité. Elle peut réduire le coût de plusieurs connecteurs, mais elle n’est jamais gratuite.

Listez les propriétaires :

• équipe de l’API métier ;
• équipe de l’adaptateur MCP ;
• équipe du client IA ;
• responsable des permissions ;
• personne qui traite les incidents ;
• personne qui revalide les descriptions après une évolution.

Si aucune équipe ne possède la couche MCP, l’intégration risque de dériver alors que l’API continue d’évoluer.

Trois architectures de référence

Architecture 1 : client direct vers l’API

Le programme construit une requête, appelle l’API puis interprète la réponse. Cette architecture convient aux automatisations déterministes, aux traitements en volume et aux parcours dont les étapes sont connues.

Ses avantages sont la simplicité, la visibilité du flux et le contrôle précis des reprises. Sa limite apparaît lorsque chaque nouvel assistant demande son propre adaptateur ou lorsque la découverte dynamique des capacités devient utile.

Architecture 2 : serveur MCP autonome

Le serveur implémente directement une capacité locale ou très étroite, par exemple lire un répertoire explicitement autorisé ou interroger une base dédiée en lecture seule.

Cette option convient à un prototype borné ou à un service construit spécifiquement pour MCP. Elle devient risquée si le serveur réimplémente progressivement toute la logique métier déjà présente ailleurs. Deux sources de vérité finissent alors par diverger.

Architecture 3 : MCP devant une API métier

Le serveur MCP traduit une intention IA en appel d’API :

1. le client découvre l’outil ;
2. le modèle propose un appel ;
3. l’hôte applique sa politique d’approbation ;
4. le serveur MCP valide le schéma et l’identité ;
5. l’API métier applique les règles et exécute ;
6. le serveur reformate la réponse ;
7. le client présente le résultat et sa trace.

Cette architecture sépare correctement les responsabilités. Elle permet aussi à une application non IA de continuer à appeler l’API sans passer par MCP.

Le contrat de frontière à remplir avant de coder

Créez une fiche pour chaque outil envisagé.

Champ	Question
mission	quelle tâche unique l’outil accomplit-il ?
consommateur	quels hôtes et quels rôles peuvent le voir ?
entrée	quels champs sont requis, bornés et validés ?
sortie	quel résultat structuré le client peut-il contrôler ?
droits	quelle permission est recalculée côté serveur ?
effet	lecture, brouillon, écriture, envoi ou destruction ?
approbation	qui doit confirmer quoi, et à quel moment ?
idempotence	que se passe-t-il si le même appel revient ?
erreur	quels états le client peut-il distinguer ?
délai	quand l’appel expire-t-il ?
trace	quel identifiant relie demande, décision et résultat ?
propriétaire	qui met à jour et qui répond en cas d’incident ?

Si la fiche ne peut pas être remplie, la description de l’outil est prématurée. Commencez par stabiliser l’API ou le processus.

Construire l’adaptateur sans dupliquer la logique métier

Le serveur MCP doit rester mince. Il peut :

• convertir le schéma MCP vers le contrat de l’API ;
• ajouter l’identité issue du contexte autorisé ;
• refuser des valeurs hors bornes ;
• appliquer une liste stricte d’opérations ;
• transmettre une clé d’idempotence ;
• transformer les erreurs en états compréhensibles ;
• retirer des champs techniques inutiles de la réponse ;
• produire un identifiant de corrélation.

Il ne devrait pas recalculer une règle métier déjà détenue par l’API. Par exemple, le plafond d’un remboursement appartient au service qui connaît le contrat, le rôle et l’état de la commande. Le prompt ou la description de l’outil peut expliquer le plafond, mais le serveur final doit encore l’imposer.

Séparer demande et exécution

Pour une action sensible, exposez deux capacités plutôt qu’un outil ambigu :

1. prepare_action, qui valide et retourne un résumé sans effet externe ;
2. execute_prepared_action, qui exige l’identifiant préparé, une autorisation encore valide et, si nécessaire, une approbation.

Cette séparation rend visibles les données qui vont être utilisées. Elle facilite aussi l’expiration et empêche qu’un brouillon ancien soit exécuté après un changement de contexte.

Tester le système complet

Un outil correct dans l’inspecteur MCP peut encore échouer dans l’application réelle. Testez cinq couches.

1. Contrat

Vérifiez les champs requis, les types, les longueurs, les formats, les valeurs inconnues et les sorties structurées. Les exemples heureux ne suffisent pas.

Le guide sur les sorties structurées IA avec JSON Schema sépare conformité syntaxique, validation du schéma, cohérence métier et autorisation de l’effet.

2. Autorisation

Essayez un rôle autorisé, un rôle refusé, une ressource d’une autre organisation, un jeton expiré et une portée insuffisante. Le refus doit venir du serveur, pas uniquement de l’interface.

3. Choix du modèle

Présentez des demandes proches et mesurez si le modèle choisit le bon outil, s’abstient lorsque l’outil ne convient pas et demande une précision lorsque l’entrée manque.

4. Effets et reprise

Rejouez un appel identique, coupez la réponse après l’exécution, simulez un délai et vérifiez l’état final. Une action ne doit pas être répétée simplement parce que le client n’a pas reçu la première réponse.

5. Compatibilité

Testez les hôtes réellement prévus et les versions effectivement supportées. MCP évolue par versions négociées. Épinglez les dépendances, consignez le protocole testé et prévoyez une stratégie de mise à niveau.

Pour une fonction exposée directement dans une page, l’analyse WebMCP et agents de navigateur traite un autre périmètre : formulaires annotés, outils JavaScript, état du document et permissions d’origine dans une expérimentation web encore évolutive.

Le rapport de test doit conserver les nombres bruts : cas joués, refus attendus, erreurs critiques, appels répétés et résultats incertains.

Arbre de décision

Posez les questions dans cet ordre :

1. Le processus et l’API sont-ils stables ? Si non, stabilisez-les avant d’ajouter une façade.
2. Le consommateur est-il une application IA ? Si non, utilisez l’API.
3. Plusieurs hôtes doivent-ils partager les mêmes capacités ? Si oui, MCP peut réduire les adaptateurs.
4. Le modèle doit-il découvrir ou choisir les capacités ? Si non, un appel direct reste souvent plus lisible.
5. L’action a-t-elle un effet sensible ? Si oui, conservez une API métier stricte et une approbation hors du modèle.
6. La portabilité compense-t-elle le coût d’exploitation ? Si non, gardez l’intégration la plus courte.

Le résultat peut être « API maintenant, MCP plus tard ». Cette décision est saine si elle repose sur des consommateurs réels et une frontière déjà documentée.

Limites

Cette méthode compare des responsabilités d’architecture. Elle ne remplace pas une revue de sécurité, un modèle de menace, un choix d’identité ou un test de charge. La compatibilité MCP varie selon les hôtes, les SDK et les versions qu’ils prennent en charge. Une annotation de sécurité ou une description de tool reste une indication ; le serveur doit imposer les droits.

Les exemples ne couvrent pas les exigences propres à un secteur réglementé ni les contrats des fournisseurs reliés. Les coûts, limites et fonctions des plateformes évoluent. Vérifiez la documentation de l’hôte, de l’API et du SDK choisis avant le déploiement.

Articles liés

• Prompt ou workflow : quand une instruction ne suffit plus
• Prompt injection et agents IA : tester les permissions avant le pilote
• Évaluer un assistant IA avant déploiement

Prochaine étape

Pour cadrer une connexion réelle, commencez par la fiche de frontière : listez trois capacités, leurs consommateurs, leurs effets, leurs droits et leurs erreurs. Si la logique métier est déjà stable, la page Automatisation IA et Python sur mesure présente le périmètre d’un accompagnement possible.