Agent IA : choisir entre MCP et CLI

Agent IA : faut-il choisir MCP ou une CLI ?

Pour un développeur qui travaille dans un dépôt, commencez par la CLI. Une interface en ligne de commande est un programme que l’on pilote avec des commandes. Si l’agent dispose déjà d’un exécuteur de commandes autorisé et que l’outil couvre le besoin, une intégration supplémentaire risque d’ajouter de la maintenance sans améliorer le résultat.

Pour un assistant hébergé au service de plusieurs utilisateurs, préférez un service MCP aux permissions limitées à un shell partagé doté de privilèges élevés. Model Context Protocol est un standard qui permet à une application d’IA de découvrir et d’appeler des outils. Un serveur distant peut accepter l’autorisation de chaque utilisateur et exposer les opérations nécessaires à l’assistant. Il reste à faire respecter ces permissions.

Dans une équipe d’ingénierie, utilisez les deux si leurs responsabilités sont distinctes. Gardez le travail sur le dépôt dans l’exécuteur de commandes. Confiez les opérations métier partagées à un service qui vérifie l’identité de l’appelant et ses droits.

Les critères décisifs sont les accès de l’environnement d’exécution, le propriétaire des identifiants, les opérations disponibles et la quantité d’informations transmise au modèle. Le nom du protocole vient ensuite.

La documentation des éditeurs sur laquelle repose cette comparaison a été vérifiée le 11 novembre 2026. Il s’agit de workflows documentés et d’analyses d’architecture, pas d’un benchmark ni d’un compte rendu de tests pratiques.

CLI et protocole MCP : comment le modèle accède-t-il aux outils ?

MCP fournit à l’agent une description d’outil ; une CLI lui fournit une commande à exécuter. Aucun des deux ne permet au modèle d’effectuer lui-même une opération. L’application qui l’entoure reçoit l’appel proposé, applique ses contrôles, l’exécute et renvoie le résultat.

Avec MCP, le client demande au serveur quels outils sont disponibles. Chaque outil indique son nom, sa fonction et son schéma d’entrée, c’est-à-dire les champs acceptés. L’application peut présenter ces définitions au modèle, qui choisit un outil et fournit des arguments structurés. La spécification des outils MCP définit leur découverte et leur invocation, tout en laissant à l’application le choix du mode d’interaction avec l’utilisateur.

Avec une CLI, l’agent passe par un outil d’exécution de commandes pour lancer un programme installé. Il peut déjà connaître une commande courante, mais aussi consulter --help pour vérifier la syntaxe de la version installée. La réponse peut être du texte, du JSON structuré ou le chemin d’un fichier. Une sortie de CLI n’est donc pas forcément du texte non structuré.

Par exemple, « liste mes pull requests ouvertes » peut devenir un appel d’outil GitHub avec des arguments ou une commande gh pr list. Dans les deux cas, le compte utilisé doit avoir le droit de lire ces pull requests. Changer d’interface n’accorde aucun accès supplémentaire.

Pour comprendre le rôle plus général du protocole, consultez notre présentation de MCP.

Coût en contexte : la CLI l’emporte pour les tâches locales simples

Une CLI peut éviter de charger dans le contexte du modèle des détails d’outils inutiles, mais elle ne supprime pas la consommation de contexte. Le contexte désigne les informations que reçoit le modèle pour décider de la suite. Les descriptions d’outils et les schémas de leurs paramètres occupent des tokens lorsque l’application hôte les inclut, tout comme l’aide et les sorties de commandes.

Un serveur MCP qui propose un vaste catalogue d’outils peut donc mobiliser beaucoup de contexte avant même le début du travail utile. La nuance essentielle tient au moment où l’application hôte inclut ce catalogue. Rien ne permet de supposer que toutes les applications chargent toutes les définitions disponibles dans chaque requête au modèle. Sélectionner moins d’outils ou les découvrir à la demande change la comparaison.

Avec une CLI, on peut commencer par la définition de l’exécuteur de commandes et ne charger l’aide propre à un outil qu’en cas de besoin. On peut aussi filtrer les données avant de les renvoyer au modèle. Demander uniquement les titres et les URL des pull requests vaut mieux que transmettre les fiches complètes en demandant au modèle d’en ignorer l’essentiel.

Mais une CLI qui affiche un journal volumineux, ou une skill qui charge un long manuel, peut annuler cet avantage. À l’inverse, un outil MCP qui renvoie une réponse concise peut être plus efficace qu’une succession d’explorations dans le shell. Mesurez la tâche complète : définitions, aide, sorties, nouvelles tentatives et justesse du résultat. La brièveté d’une commande ne prouve pas grand-chose à elle seule.

Verdict sur le contexte : la CLI pour les tâches locales courantes avec des sorties ciblées. MCP reste compétitif si le nombre d’outils et le volume des résultats restent limités. Rien ne justifie ici un multiplicateur universel du nombre de tokens.

Authentification et permissions : MCP l’emporte si le service fait respecter les droits

L’autorisation propre à chaque utilisateur compte davantage que le format envoyé par l’agent, JSON ou chaîne de commande. OAuth est un mécanisme de connexion déléguée : un utilisateur autorise un client sans lui communiquer son mot de passe. Un déploiement MCP distant peut s’appuyer sur cette identité pour déterminer les comptes, les données et les actions auxquels le client a accès.

Prenons un assistant de support utilisé par plusieurs entreprises clientes. Il doit récupérer les données du client connecté sans recevoir les identifiants d’un ingénieur capables de lire tous les comptes. Entre un service MCP distant au périmètre correctement limité et un shell administrateur partagé, choisissez le service. Dans ce cas, MCP peut être la seule option acceptable parmi ces deux implémentations.

Ce n’est pas la seule architecture sûre possible. Une intégration directe à une API peut faire respecter les mêmes limites. Ajouter MCP ne les crée pas non plus automatiquement : la spécification d’autorisation MCP rend l’autorisation facultative, définit le flux d’autorisation HTTP et distingue les serveurs STDIO locaux qui récupèrent leurs identifiants dans leur environnement.

Une CLI peut elle aussi utiliser une connexion par navigateur et des identifiants aux droits limités. Le risque dépend de ce à quoi son processus peut accéder : identifiants, fichiers, destinations réseau et autres exécutables. Un exécuteur de commandes isolé dans un bac à sable avec des identifiants strictement limités n’a pas les mêmes implications qu’un accès sans restriction à la machine d’un développeur.

Verdict sur les permissions : MCP distant aux droits limités pour déléguer des accès à plusieurs utilisateurs. Dans les deux cas, faites respecter les autorisations sur les comptes et les objets dans le code, gardez les identifiants hors des sorties visibles par le modèle et consignez quel utilisateur a autorisé chaque action.

GitHub CLI ou GitHub MCP : travail sur le dépôt ou accès à un service partagé ?

GitHub CLI, le client en ligne de commande gh, est le choix le plus direct pour un agent de développement qui travaille déjà dans une copie locale du dépôt. Imaginons que vous souhaitiez une synthèse de vos pull requests ouvertes. Dans le dépôt, une fois authentifié, cette commande utilise des options documentées :

gh pr list --author "@me" --json number,title,url

Elle ne demande que les champs nécessaires à la synthèse. La CLI accepte aussi --jq pour filtrer le JSON avant qu’il atteigne le modèle. C’est une technique concrète pour économiser du contexte, sans avancer de benchmark en tokens.

Les limites de la CLI sont celles de l’environnement qui l’exécute. Une commande qui fonctionne sur votre ordinateur n’est pas automatiquement une interface adaptée à tous les employés ou clients. D’après le manuel de connexion de GitHub CLI, la connexion par navigateur stocke normalement un token dans le gestionnaire d’identifiants du système, avec un repli en texte brut si ce gestionnaire n’est pas disponible. Examinez le stockage réel des identifiants au lieu de supposer que « local » signifie « isolé ».

GitHub MCP Server, le serveur d’outils officiel de GitHub, convient à un assistant qui doit effectuer des opérations sur les dépôts via MCP. Pour produire la même synthèse, exposez les outils de pull requests pertinents, utilisez l’autorisation de l’utilisateur concerné et demandez ses requêtes ouvertes. GitHub héberge un serveur distant et propose aussi une option locale.

GitHub documente les ensembles d’outils et la sélection individuelle, ainsi qu’un mode lecture seule qui omet les outils d’écriture. La prise en charge d’OAuth sur le serveur distant dépend aussi de la configuration de l’application GitHub ou OAuth appropriée par l’application hôte ; la compatibilité du transport ne règle pas à elle seule l’authentification.

Verdict de cette comparaison : utilisez gh pour la synthèse du développeur et les scripts du dépôt. Préférez MCP pour un assistant partagé dont le client prend en charge le flux d’authentification requis. Aucun des deux ne remplace les permissions du dépôt, et limiter les outils MCP peut améliorer à la fois la clarté et l’utilisation du contexte.

Playwright CLI ou Playwright MCP : développement ou exploration du navigateur ?

Playwright CLI, l’interface de Microsoft pour piloter le navigateur par commandes, est le choix par défaut pour un agent de développement qui vérifie une modification web. Ses auteurs recommandent d’associer CLI et skills pour les agents de développement, car les commandes peuvent éviter de charger de vastes schémas et données de page dans le contexte. Il s’agit de leur recommandation de conception, pas d’une mesure de vitesse réalisée pour cet article.

Pour un développeur qui vérifie un formulaire, le workflow consiste à ouvrir la page, examiner les éléments pertinents, interagir, puis observer le résultat. L’agent n’a pas besoin de relire tous les détails de la page après chaque action.

Installer playwright-cli : commencer par les commandes de l’éditeur

Voici les commandes documentées pour l’installation et l’inspection d’une page en lecture seule :

npm install -g @playwright/cli@latest
playwright-cli --help
playwright-cli open https://playwright.dev
playwright-cli snapshot
playwright-cli close

Ces commandes inspectent une page publique ; elles ne constituent pas une suite de tests. Utilisez l’instantané obtenu pour repérer les cibles avant d’ajouter des interactions avec votre propre application.

Skill Playwright CLI : ajouter les instructions du workflow

Une fois la CLI installée, la commande documentée pour les skills est :

playwright-cli install --skills

La limite importante tient à ce que vous devez mettre en place autour : un environnement d’exécution, une session de navigateur adaptée et des instructions qui définissent la réussite. Une skill aide à suivre la procédure ; elle ne peut pas décider si une transaction réelle pour un client est autorisée.

Playwright MCP, le serveur d’outils de navigateur de Microsoft, convient mieux lorsque votre client MCP tire parti d’une inspection structurée de la page au fil d’une exploration. Il utilise des instantanés d’accessibilité, descriptions structurées des éléments de la page, pour permettre les interactions dans le navigateur.

Deux limites sont à retenir. D’abord, la persistance de l’état du navigateur n’est pas réservée à MCP : Playwright CLI conserve les cookies et le stockage entre les appels d’une même session et propose des profils persistants entre les redémarrages du navigateur. Ensuite, le dépôt MCP précise explicitement que le serveur ne constitue pas une barrière de sécurité. Les avertissements sur ses contrôles d’origine indiquent aussi qu’ils n’offrent pas cette protection et n’agissent pas sur les redirections.

Verdict de cette comparaison : CLI et skills pour les vérifications courantes dans un workflow de développement ; MCP pour un client et une tâche qui tirent parti de son mode d’interaction avec les outils de navigateur. Ne changez pas d’interface dans le seul but de conserver l’état de session. Le guide de configuration de Playwright MCP et de test dans le navigateur détaille cette approche.

Stripe CLI ou Stripe MCP : développement des webhooks ou opérations sur un compte ?

Stripe CLI, l’outil de terminal de Stripe, l’emporte pour développer et déboguer une intégration de paiement. Un besoin courant consiste à recevoir dans une application locale des événements webhook, les notifications envoyées par Stripe lorsqu’un événement survient. La CLI documente stripe listen pour recevoir et transmettre ces événements, et stripe trigger pour générer des événements d’exemple.

Gardez ce workflow dans un bac à sable. Déclencher des événements crée des objets API et peut produire d’autres événements ; ce n’est pas simplement afficher un exemple de données. La CLI permet aussi d’effectuer des opérations API et d’inspecter les journaux de requêtes : son utilité dépasse donc la transmission des webhooks.

La distinction sur l’authentification est plus subtile que « CLI égale clé API copiée ». Stripe documente la connexion individuelle par navigateur, le stockage local sécurisé des identifiants lorsqu’il est disponible, le renouvellement des sessions et la révocation. Cela peut convenir à des développeurs. Pour un assistant hébergé, si vous retenez la CLI, il vous faut toujours un moyen d’isoler l’environnement d’exécution et les identifiants de chaque utilisateur.

Stripe MCP, l’interface de service de Stripe destinée aux agents, l’emporte pour les opérations sur un compte depuis un assistant compatible sans exécuteur de commandes local. Par exemple, un opérateur autorisé peut demander à l’assistant de rechercher et de lire les données pertinentes de l’API Stripe. Le serveur fournit des outils de recherche dans l’API, de découverte des paramètres, de lecture et d’écriture, au lieu d’exiger une définition d’outil distincte pour chaque opération.

Stripe prend en charge OAuth pour agir au nom d’un utilisateur et les clés API d’agent pour les accès indépendants. Son outil général stripe_api_write peut couvrir de nombreuses opérations. Les exigences de confirmation humaine de Stripe dépendent de l’action et sont distinctes du réglage d’approbation des outils propre au client. Approuver une catégorie d’outils ne revient donc pas à approuver toutes les actions métier qu’elle permet.

Verdict de cette comparaison : CLI pour développer les webhooks en local ; MCP pour les opérations déléguées sur les comptes dans un assistant. Comparez l’opération dont vous avez besoin, pas le nombre de commandes ou d’outils. Une connexion MCP qui lit les données d’un compte ne remplace pas l’écouteur de webhooks local de votre workflow de développement.

MCP et skills : les instructions interviennent à un autre niveau

Une skill indique à l’agent comment travailler ; MCP et la CLI lui donnent les moyens d’agir. Dans le format Agent Skills, un fichier SKILL.md contient un nom, une description et des instructions pour la tâche, éventuellement accompagnés de scripts et de fichiers de référence. Les agents découvrent d’abord les métadonnées, puis chargent les instructions complètes lorsque c’est nécessaire.

Pour comparer « MCP vs CLI vs skills », la combinaison utile est souvent une CLI accompagnée d’une skill. La CLI exécute l’opération ; la skill précise les commandes à utiliser, l’environnement à sélectionner, les éléments à examiner et le moment où s’arrêter. Une skill peut tout aussi bien guider un agent qui utilise des outils MCP.

Pour une synthèse de pull requests, la skill peut imposer de ne retenir que les requêtes ouvertes, de sélectionner des champs concis et de ne publier aucun commentaire pendant la tâche de compte rendu. Les identifiants et l’environnement d’exécution doivent faire respecter les limites d’accès réelles. Les instructions écrites aident l’agent à se comporter correctement ; elles ne lui retirent aucune permission.

Verdict sur la procédure : les skills pour rendre le travail reproductible. Elles complètent les deux interfaces et consomment elles-mêmes du contexte lorsqu’elles sont chargées.

MCP, API et CLI : conserver la logique métier dans le service

Gardez les règles métier dans le service, puis exposez les interfaces dont les utilisateurs ont besoin. Une API est l’interface de programmation d’une application. Une CLI peut l’appeler, tout comme un serveur MCP, ainsi que le montrent les interfaces de Stripe.

Si vous maintenez les deux, réutilisez les mécanismes d’autorisation et de validation au lieu de créer des implémentations concurrentes de la règle « qui peut modifier cet enregistrement ? ». La comparaison MCP vs API explique quand l’ajout de la couche protocolaire est pertinent.

Une couche qui accepte n’importe quelle commande shell constitue une faible justification de migration. Elle peut rendre un exécuteur de commandes existant accessible via MCP, mais conserve les mêmes droits d’exécution. Un adaptateur utile expose une opération délimitée, valide ses entrées et ne renvoie que les éléments nécessaires à l’agent.

Tableau de décision : choisir selon le déploiement

Choisissez l’interface la plus limitée qui couvre la tâche sans élargir les droits. Ce sont des configurations de départ, pas des engagements définitifs.

Passer de MCP à la CLI, ou faire le chemin inverse

Migrez un workflow, pas tout votre catalogue d’outils. Le plus coûteux est souvent de préserver les permissions, les sorties et la gestion des échecs, plutôt que de convertir un nom d’outil en commande.

Passer à la CLI suppose de prévoir l’installation, les identifiants, un exécuteur de commandes, le filtrage des sorties et des instructions reproductibles. Passer à MCP suppose de choisir ou d’exploiter un serveur, de configurer l’authentification du client, de définir les outils exposés et de traiter les erreurs via cette interface. Pour les workflows de navigateur, il faut aussi décider explicitement à qui appartiennent les sessions et les profils.

Ne remplacez pas un workflow CLI qui fonctionne simplement pour ajouter la prise en charge d’un protocole. Ne supprimez pas une intégration MCP distante utile à des personnes sans shell au seul motif qu’une commande paraît plus courte.

Retrouvez d’autres guides pratiques pour choisir les workflows d’agents et en délimiter les droits dans la newsletter.

Questions fréquentes