Exposer votre app à des agents : API, CLI ou MCP ?

Il y a un an, la réponse allait de soi. Pour ouvrir un produit aux agents, on développait un MCP.

Depuis, le discours a changé. Les équipes qui travaillent avec des agents de code font un constat : dans un terminal, un agent préfère souvent une bonne CLI à quinze tools MCP. D'autres répondent qu'une API bien documentée suffit, puisque l'agent écrit lui-même le code qui l'appelle. Chaque camp a ses benchmarks et ses chiffres spectaculaires.

Nos clients nous posent la question telle quelle : « on fait quoi, nous ? »

La réponse est qu'on ne choisit pas un protocole : on choisit en fonction de l'endroit où vit l'agent. Un agent qui dispose d'un shell n'a pas les besoins d'un agent dans une fenêtre de chat. Le second est souvent piloté par une comptable qui n'a jamais ouvert un terminal. Dans les deux cas, chaque surface reste une traduction mince de la même couche métier.

Trois surfaces, trois contrats

Chaque surface apporte des garanties différentes. Il faut les poser avant d'arbitrer.

L'API est le contrat programmatique de base : des routes REST, un schéma OpenAPI, une clé ou un jeton OAuth. Elle est universelle et déterministe. En revanche, elle ne dit rien de l'intention. Elle liste ce que l'agent peut appeler, pas quand ni dans quel ordre.

La CLI est une interface en ligne de commande. Les agents la connaissent bien : ils ont vu des millions d'exemples de git, gh ou kubectl pendant leur entraînement. Une bonne CLI se documente avec --help et se compose avec des pipes. Tant que l'agent ne l'appelle pas, elle ne coûte presque rien en contexte. Elle exige en revanche deux choses : un environnement d'exécution et des identifiants présents sur la machine.

Le MCP (Model Context Protocol) expose un catalogue de tools décrits. L'agent découvre ces tools, puis les appelle avec des arguments typés. Le protocole standardise ce que les deux autres surfaces laissent à chacun :

• l'authentification de chaque utilisateur, par OAuth ;
• la découverte des capacités ;
• le transport à distance.

Il vise les clients sans shell : Claude, ChatGPT, les assistants intégrés aux outils métier.

Où vit l'agent ?

Un produit B2B a rarement un seul type d'agent en face de lui. Prenons une plateforme de facturation, un cas que nous rencontrons souvent.

• Les développeurs font tourner des agents de code en local et en CI. Ces agents créent des données de test, rejouent un webhook, vérifient une synchronisation. Ils ont un shell : une CLI suffit.
• L'équipe finance du client travaille dans Claude ou ChatGPT. Elle demande : « relance les factures impayées de plus de 60 jours ». L'action doit partir avec les droits de la personne, pas avec ceux d'un compte technique. Seul un MCP distant convient.
• L'ERP d'un partenaire synchronise les écritures chaque nuit. Il n'y a ni raisonnement ni ambiguïté. L'API suffit, à condition de rester stable.

Pour choisir, nous posons trois questions :

1. Où tourne l'agent ? Dans un environnement avec un shell (poste de développement, conteneur, CI) ou dans un client hébergé ?
2. Au nom de qui agit-il ? D'un compte technique, ou d'un utilisateur dont il hérite les droits ?
3. Qui l'installe ? Un développeur qui gère un jeton dans un fichier, ou un utilisateur métier qui clique sur « connecter » ?

Anthropic défend la même lecture dans un article publié en avril. Selon l'éditeur, les intégrations matures livrent les trois surfaces : l'API comme socle, la CLI en local, le MCP pour les agents dans le cloud.

Le coût en contexte, un problème largement réglé

Historiquement, le principal reproche fait au MCP portait sur le contexte. Chaque serveur déclarait tout son catalogue au démarrage. Branché sur cinq ou six serveurs, un agent perdait une bonne part de son contexte avant de commencer. Les chiffres qui circulent viennent surtout d'éditeurs qui vendent l'alternative : quatre à trente fois plus de tokens qu'une CLI, jusqu'à 70 % du contexte. Le phénomène était tout de même réel.

Les clients l'ont corrigé, sans toucher au protocole. Les agents cherchent désormais un tool dans le catalogue au moment où ils en ont besoin. Anthropic annonce une baisse de plus de 85 % des tokens consacrés aux définitions.

L'approche décrite dans Code execution with MCP va plus loin. L'agent écrit un script qui appelle les tools et filtre les résultats dans un environnement isolé. Seul l'essentiel remonte au modèle. Sur l'exemple d'Anthropic, la tâche passe de 150 000 à 2 000 tokens.

Un tool n'est pas une route d'API

Le vrai défaut est ailleurs : beaucoup de MCP sont mal conçus. Ils recopient l'API route par route, avec des descriptions génériques et des réponses verbeuses.

Imaginons un MCP de soixante tools : get_invoice, list_invoices, update_invoice_status, et ainsi de suite. L'agent doit recomposer lui-même le parcours métier. Il choisit l'ordre des appels et pense seul aux vérifications. Un bon MCP lui épargne justement ce travail.

Cloudflare a pris le parti inverse, à l'extrême. Son API compte environ 2 500 routes, mais son MCP n'expose que deux tools. Le premier cherche la bonne route dans la documentation de l'API. Le second exécute le code que l'agent écrit pour l'appeler. Tout le catalogue tient en un millier de tokens.

Sans aller jusque-là, la règle tient : peu de tools, alignés sur des intentions métier, décrits pour un modèle.

Ce que la CLI ne règle pas

Dans un terminal, une bonne CLI reste difficile à battre. Elle laisse pourtant de côté trois sujets, ceux qui comptent dès que l'on sort de l'équipe technique.

L'identité. Une CLI s'authentifie avec un jeton posé sur la machine. Pour un développeur, c'est acceptable. Pour vingt opérateurs métier, il faut vingt jetons à distribuer, renouveler et révoquer. En pratique, on finit souvent avec un seul jeton administrateur, partagé dans un fichier .env. C'est une dette de sécurité.

La portée de l'agent. Un agent qui lance votre CLI peut lancer n'importe quelle autre commande sur la machine. Il peut aussi lire le jeton. Anthropic a dû traiter ce point dans sa propre infrastructure d'agents. Le code généré par le modèle n'accède jamais aux identifiants. Les jetons OAuth des tools MCP restent dans un coffre, derrière un proxy. Avec une CLI, il faut construire cette isolation soi-même.

La distribution. Aucune équipe finance n'installera un binaire pour configurer un profil. Un MCP distant se connecte en un clic depuis Claude ou ChatGPT. L'utilisateur s'authentifie ensuite avec son propre compte.

La skill, la pièce qui manque souvent

Le débat porte sur la manière de se connecter à un produit. Il oublie la moitié du problème : savoir s'en servir.

Avec une CLI ou un MCP, l'agent connaît les actions disponibles. Il ignore en revanche les règles du client. Par exemple :

• on ne relance jamais une facture contestée ;
• on vérifie l'échéancier avant d'émettre un avoir ;
• l'export comptable part par lots mensuels.

Ce savoir-faire tient dans une skill. Une skill est un court fichier d'instructions, parfois accompagné de scripts. L'agent la charge seulement quand la tâche l'exige.

Anthropic et OpenAI convergent sur ce point. Les plugins de ChatGPT et Codex assemblent des skills et des serveurs MCP. Les skills portent le savoir-faire. Les serveurs MCP portent la connexion, l'authentification et les actions. Les plugins de Claude suivent la même logique. Le format des skills a d'ailleurs rejoint MCP au sein de l'Agentic AI Foundation, hébergée par la Linux Foundation.

Dans quel ordre construire

Tout repose sur une condition : la logique métier ne vit pas dans les contrôleurs du back-office. Nous l'avons développé dans développer un MCP plutôt qu'un back-office. La première étape ne change donc jamais : isoler la couche service et stabiliser l'API. Tout le reste dépend de ce contrat.

Pour la suite, Anthropic recommande de construire d'abord un MCP distant, puis de le soigner. Le conseil vaut quand les premiers utilisateurs d'agents sont des opérateurs métier : support, finance, opérations, customer success. Sur nos projets, c'est de plus en plus fréquent.

Ce n'est pas systématique. Parfois, le produit sert d'abord des équipes techniques. Parfois, l'usage agentique commence dans l'équipe de développement elle-même. Dans ces cas, nous inversons l'ordre :

1. La CLI d'abord, souvent générée en grande partie depuis l'API. L'équipe l'utilise avec ses propres agents de code. C'est le meilleur banc d'essai : une commande peu fiable pour un agent l'est aussi pour l'équipe.
2. Le MCP ensuite, conçu à partir de ce que la CLI a appris. Quelles actions les agents enchaînent-ils ? Quelles erreurs reviennent ? Quels parcours méritent un tool dédié ? On évite ainsi le MCP généré depuis l'OpenAPI, avec ses soixante routes.
3. La skill tout au long. On l'enrichit chaque fois qu'un agent se trompe pour une raison métier.

Une fois la couche service en place, il faut compter quelques jours pour une CLI propre, un peu plus pour un MCP distant avec OAuth.

Les règles communes à toutes les surfaces

Les agents n'inventent pas ces exigences. Ils les rendent obligatoires.

• Une identité par appelant. L'agent n'est jamais super-administrateur. Il hérite des droits de l'utilisateur, ou d'un compte technique au périmètre limité.
• Des sorties lisibles par une machine. Chaque commande propose un --json, chaque tool un schéma strict. Les messages d'erreur disent quoi corriger. Un agent se trompe d'argument comme un humain : une erreur explicite lui permet de se rattraper.
• Des actions rejouables. L'idempotence s'applique partout. Les actions irréversibles passent par un mode --dry-run ou une confirmation. Un agent enchaîne vite les appels : il doit pouvoir réessayer sans dégât.
• Une journalisation complète. Le journal enregistre qui agit, quand, pour le compte de qui et avec quels arguments. Le jour où une opération tourne mal, il rend l'ensemble auditable.
• Une documentation écrite pour un agent. Elle contient des descriptions de tools précises, des exemples et les cas à exclure. C'est le travail d'une bonne documentation humaine, avec moins de tolérance pour le flou.

Choisir, concrètement

Le débat API, CLI ou MCP rappelle les guerres de frameworks. Il oppose des réponses conçues pour des situations différentes, avec des benchmarks choisis pour gagner.

La décision tient en trois questions : où tourne l'agent, au nom de qui agit-il, qui l'installe ? Les réponses désignent la surface à ouvrir en premier.

Pour la plupart des produits B2B que nous concevons ou modernisons, la combinaison finit par converger :

• une API comme socle ;
• une CLI pour les équipes techniques et leurs agents ;
• un MCP resserré pour les opérateurs ;
• une skill qui explique l'usage métier.

Ouvrir trois surfaces coûte peu. Ce qui coûte cher, c'est une logique métier enfermée derrière la première.