MCP, API ou CLI : que choisir, et pourquoi ?

Un commerce possède déjà une API de stock. Son application l’utilise pour afficher les quantités disponibles. L’équipe veut maintenant produire un rapport chaque soir et permettre à un assistant IA de répondre : « Reste-t-il cette veste à Lyon ? »

Trois pistes se présentent : appeler l’API existante, proposer une commande dans un terminal ou créer un serveur MCP. Toutes peuvent conduire à la même réponse : six vestes disponibles. Ce qui change, c’est le travail nécessaire pour obtenir cette réponse, réutiliser l’intégration et la maintenir.

Le problème : un même résultat, des contraintes différentes

Dire « API pour les logiciels, CLI pour les scripts, MCP pour les agents » est trop réducteur. Un script peut appeler une API. Un agent peut utiliser une CLI si son environnement autorise l’exécution de commandes. Une application d’IA peut appeler une API à travers des fonctions écrites par ses développeurs.

La décision dépend donc de trois questions : qui contrôle l’application qui appelle le service, dans quel environnement elle s’exécute et combien de clients devront réutiliser l’intégration ?

La solution : choisir le travail que l’on veut éviter

Dans cet article, API désigne l’API HTTP du service métier. CLI désigne un programme utilisable en ligne de commande. MCP est un protocole commun entre une application d’IA et un serveur qui lui expose notamment des outils. MCP définit lui aussi une interface programmable : ces trois termes ne désignent donc pas des alternatives au même niveau. Architecture MCP

Notre règle de choix est la suivante : privilégier l’API quand on maîtrise l’intégration, la CLI quand des commandes existantes simplifient le travail dans un terminal, et MCP quand on veut rendre les mêmes outils accessibles à plusieurs applications d’IA compatibles. Voici pourquoi.

Le fonctionnement : où se fait le travail ?

Prenons la consultation du stock de la veste. Les appels ci-dessous sont fictifs.

Interface	Appel	Travail pris en charge
API HTTP	GET /stores/lyon/stock?sku=VESTE-M	Le code de l’application prépare la requête et traite la réponse.
CLI	catalog stock --store lyon --sku VESTE-M --json	La commande prépare la requête ; le script récupère sa sortie et son code de retour.
MCP	Tool consulter_stock, avec magasin et article	Le client MCP transmet l’appel ; le serveur exécute l’opération métier.

Avec l’API, le développeur connaît la route et le contrat attendu. Une description OpenAPI peut documenter les paramètres et les réponses, et servir à générer un client. Pour un agent, l’application peut fournir une fonction consulter_stock qui encapsule cette requête : MCP n’est pas requis pour cela. Spécification OpenAPI

Avec la CLI, l’application lance un processus. Pour l’automatiser correctement, il faut une sortie exploitable, par exemple JSON, et un fonctionnement sans question interactive. Le script peut ensuite filtrer le résultat ou l’enregistrer dans un fichier. Guide de conception des CLI

Avec MCP, le client découvre les outils et leurs paramètres via tools/list, puis en appelle un via tools/call. Dans notre exemple, le serveur traduit cet appel en requête vers l’API de stock. Le modèle propose une action ; l’application d’IA en gère l’exécution. Spécification des outils MCP

Pourquoi les combiner ?

Le schéma montre une architecture possible : l’API centralise l’accès au stock, tandis que la CLI et MCP adaptent cet accès à des utilisateurs différents.

Cette complémentarité a un intérêt concret : une correction du calcul du stock se fait dans le service métier et profite aux trois accès. On conserve une seule règle de calcul, tout en proposant plusieurs façons de l’utiliser. Les adaptateurs restent responsables de leurs paramètres et de leurs erreurs.

Cette architecture devient utile si les trois usages existent. Un simple rapport quotidien ne justifie pas, à lui seul, de construire une CLI et un serveur MCP. Un serveur MCP peut aussi appeler directement une bibliothèque : l’API HTTP intermédiaire est un choix d’architecture, pas une obligation du protocole.

Les avantages : ce que chaque interface fait gagner

• API — maîtriser une intégration précise. Pour notre application de vente, nous pouvons programmer exactement les données demandées, les délais et le traitement des erreurs. Si nous développons aussi l’assistant et ses quelques actions, réutiliser cette intégration évite un serveur supplémentaire. Le gain est le contrôle du parcours et la réutilisation du service existant.

• CLI — réutiliser des opérations déjà prêtes. Imaginons une commande qui exporte les ruptures de stock de tous les magasins et gère déjà la pagination. Le rapport nocturne peut la réutiliser au lieu de réécrire cette logique d’accès. Sa sortie peut alimenter d’autres programmes. Ce gain dépend de ce que la CLI fournit réellement ; une commande qui enveloppe une seule requête peut apporter peu à un script déjà fonctionnel.

• MCP — réutiliser l’intégration entre applications d’IA. Si les vendeurs, le support et les partenaires utilisent différents clients compatibles, un même serveur peut leur proposer consulter_stock. Chaque client utilise les mêmes mécanismes de découverte et d’appel. Le gain augmente lorsque cela évite de développer un connecteur spécifique pour chaque application ; il est plus faible pour un unique assistant dont on maîtrise déjà le code.

Les limites : ce que l’on doit encore construire

• API — l’adaptation à l’agent reste à faire. Il faut sélectionner les opérations utiles, les décrire et relier les appels du modèle à leur exécution. OpenAPI peut aider à générer cette couche, mais une route bien documentée ne suffit pas à résoudre une demande ambiguë comme « retire cette veste ».

• CLI — l’environnement devient une dépendance. Il faut pouvoir installer et lancer le programme, gérer ses versions, ses droits et ses formats de sortie. Un assistant hébergé sans accès aux processus ne peut pas utiliser directement cette CLI. Une sortie conçue uniquement pour un humain peut aussi être difficile à exploiter automatiquement.

• MCP — la standardisation a un coût d’exploitation. Il faut maintenir le serveur, vérifier les capacités des clients visés et configurer les accès. Le protocole prévoit un cadre d’autorisation pour HTTP ; les droits métier, par exemple l’accès au seul magasin de Lyon, restent à appliquer dans le service. Autorisation MCP

• Aucune interface ne garantit à elle seule un meilleur agent. Un outil MCP mal décrit peut être moins utile qu’une CLI claire. Une API directe peut être plus simple à exploiter qu’un adaptateur supplémentaire. La fiabilité, la latence et la quantité de contexte dépendent de l’implémentation : elles se mesurent sur les tâches réelles, pas à partir du nom du protocole.

Notre choix pour ce commerce

Nous partirions de l’API existante, puis ajouterions une interface seulement lorsqu’elle retire un travail identifié.

Situation	Choix conseillé	Pourquoi
Notre propre assistant, avec quelques actions connues	Fonctions qui appellent l’API	Nous maîtrisons le code et pouvons réutiliser l’intégration.
Rapport nocturne fondé sur quelques requêtes	Script appelant l’API	Une commande supplémentaire n’apporte pas encore de gain.
Exports récurrents, CLI mature et terminal disponible	CLI	Les opérations prêtes à l’emploi évitent de réécrire le traitement.
Mêmes outils à proposer dans plusieurs clients d’IA compatibles	MCP au-dessus du service existant	Le contrat de découverte et d’appel est réutilisable entre clients.

L’existant peut changer cet arbitrage. Si le fournisseur propose déjà un serveur MCP maintenu et que notre assistant le prend en charge, MCP peut être le chemin le plus simple même pour un seul client. À l’inverse, construire ce serveur pour remplacer trois appels API déjà fiables peut ajouter du travail sans bénéfice immédiat.

Un arbre de décision pour choisir

Pour une équipe qui peut intégrer le service dans son code, cet arbre propose une première option à tester. Si plusieurs options conviennent, comparez le travail qu’elles évitent et leur coût de maintenance.

Avant de retenir ce choix, nous testerions une consultation réussie, un magasin interdit et une panne du service. Nous comparerions le code à maintenir, la qualité des erreurs et le temps de réponse. Le bon choix est celui qui simplifie les usages visés avec les interfaces déjà disponibles.

Pour poursuivre : comprendre MCP et bien écrire ses tools.