Le MCP a été déclaré mort après une vague de publications affirmant que les CLI coûtent moins cher aux agents d’IA. Cet article décortique les vrais chiffres de tokens, les compromis de sécurité et les cas où chaque approche l’emporte, pour vous aider à choisir la bonne pour votre projet.
En mars 2026, Denis Yarats, CTO de Perplexity, a déclaré que son entreprise s’éloignait du MCP en interne pour s’appuyer davantage sur des API classiques et des outils en ligne de commande. Une publication à ce sujet s’est propagée à grande vitesse, et en quelques jours le verdict était partout : MCP est mort. Des développeurs ont partagé des captures d’écran de listes d’outils qui grignotaient leur fenêtre de contexte, et les réponses regorgeaient de commandes shell d’une seule ligne accomplissant la même tâche dans une fraction de l’espace.
Puis quelque chose d’étrange s’est produit. Le protocole n’est pas mort. Il a continué à voir arriver de nouveaux serveurs, à gagner le soutien des plus grands noms de l’IA et il est aujourd’hui placé sous la tutelle de la Linux Foundation. Alors, laquelle des deux affirmations est la bonne ?
Cet article sépare le bruit des chiffres. Vous verrez ce que fait réellement le MCP, où les critiques sur les tokens sont fondées, pourquoi les CLI paraissent si naturelles aux agents de programmation, et où un terminal ne peut tout simplement pas faire le travail. Vous trouverez aussi un tableau de décision utilisable dès aujourd’hui, ainsi qu’une courte section pour essayer les deux approches avec le connecteur MCP et l’API REST de PicassoIA.
💡 Réponse courte : le MCP n’est pas mort, mais la façon paresseuse de l’utiliser, si. Charger cent définitions d’outils dès le départ relève d’un problème de conception, et non d’un problème de protocole.
L’étincelle était une courte déclaration aux répercussions durables. Le CTO de Perplexity a affirmé que l’entreprise quittait le MCP pour ses outils internes et revenait aux API directes et aux CLI. Des articles de blog intitulés « MCP is dead » et « MCP vs CLI » ont suivi en quelques semaines, et le débat s’est figé en deux camps.
Aucune de ces publications n’était un verdict officiel. C’étaient des opinions, et plusieurs s’appuyaient sur de vrais benchmarks montrant d’importantes économies de tokens lorsqu’un agent exécute une commande au lieu de charger un serveur de protocole. Les critiques étaient fondées. En revanche, affirmer que le protocole entier est terminé dépassait largement les preuves disponibles.
Les chiffres qui ont circulé étaient frappants. Une comparaison d’automatisation de navigateur indiquait qu’il fallait environ 52 000 tokens pour lire une page produit via un instantané MCP, contre environ 1 200 tokens pour quelques requêtes ciblées en ligne de commande. Un autre benchmark, qui listait des appareils dans un outil d’administration Microsoft, faisait état d’environ 35 fois moins de tokens avec une CLI. Il faut considérer ces chiffres comme indicatifs, car ils dépendent du serveur, de la tâche et du client. Mais la tendance est difficile à contester : un serveur trop lourd coûte cher.
Une fois les avis tranchés écartés, quatre reproches demeurent :
git, curl, grep et docker dans d’innombrables exemples, si bien qu’ils les appellent correctement sans instructions supplémentaires.Chaque point est vrai dans certaines configurations. Aucun ne constitue un défaut de l’idée même d’un protocole partagé.
Le contexte n’est pas gratuit. Chaque token consacré aux descriptions d’outils est un token qui n’est pas consacré à votre code, à vos documents ou à la conversation elle-même. Les prompts longs coûtent aussi de l’argent à chaque appel, et les modèles ont tendance à perdre le fil des détails enfouis au milieu d’un contexte immense. C’est pourquoi l’argument des tokens touche si fort les personnes qui font tourner des agents toute la journée.
Anthropic a présenté le Model Context Protocol en novembre 2024 comme une manière commune pour les applications d’IA d’accéder à des outils et à des données externes. Voyez-le comme l’USB-C des agents. Sans standard, chaque application d’IA a besoin d’un plugin sur mesure pour chaque service, et le nombre d’intégrations se multiplie très vite.
Un client (l’application d’IA) communique avec un serveur (l’intégration) via un canal local ou via HTTP. Le serveur annonce des outils, des ressources et des prompts, et le client permet au modèle de les appeler. Toute l’idée tient là : une seule forme de prise, de nombreux appareils.
Les trois briques répondent à des besoins du quotidien. Un outil exécute une action, comme créer un ticket ou générer une image. Une ressource expose des données à lire, comme un fichier ou une ligne de base de données. Un prompt est un modèle réutilisable que l’utilisateur peut déclencher, comme « examinez cette pull request ». La plupart des serveurs réels reposent presque entièrement sur les outils, et c’est aussi là que les coûts en tokens s’accumulent.
Le 9 décembre 2025, Anthropic a confié le MCP à la Linux Foundation, en tant que projet fondateur de la nouvelle Agentic AI Foundation, cofondée avec Block et OpenAI et soutenue par Google, Microsoft, Amazon Web Services, Cloudflare et Bloomberg. Un protocole achevé ne reçoit pas, en général, un foyer neutre et ne réunit pas autour d’une même table autant de concurrents.
La question utile n’est donc pas de savoir si le MCP va survivre. Il s’agit plutôt de savoir comment les gens doivent l’appeler.
Sur ce point, les critiques ont un argument solide. Selon les rapports, le serveur MCP officiel de GitHub représente environ 50 000 tokens de descriptions d’outils avant même que l’agent n’ait fait quoi que ce soit. Un court fichier de compétences qui enseigne le même workflow via la ligne de commande affiche, selon les rapports, environ 200 tokens. L’écart est de deux ordres de grandeur, et il est prélevé sur l’espace dont votre modèle a besoin pour la tâche réelle.
Le second coût se cache au cœur d’un flux de travail. Si un agent récupère une longue transcription dans un système pour la coller dans un autre, chaque mot traverse le modèle deux fois. Une transcription de réunion d’une heure peut atteindre dix mille tokens ou plus : la faire passer deux fois revient donc à la payer deux fois, alors que le modèle n’avait jamais besoin de la lire.
Dans son billet d’ingénierie du 4 novembre 2025 consacré à l’exécution de code avec le MCP, Anthropic décrit un workflow allant de Google Drive à Salesforce qui est passé d’environ 150 000 tokens à environ 2 000, soit une économie d’environ 98,7 %. L’agent déplaçait le texte dans du code, si bien que le modèle ne voyait qu’une courte confirmation.
Lisez attentivement. La solution reposait toujours sur le MCP. Simplement, l’agent l’appelait via du code, au lieu d’un appel d’outil à la fois.
| Approche | Contexte initial | Points forts | Point faible |
|---|---|---|---|
| Appels directs d’outils MCP | Élevé avec de nombreux outils | Petits ensembles d’outils sélectionnés | Surcharge et détours par les données |
| MCP avec exécution de code | Faible | Grands jeux de données, nombreuses étapes | Nécessite un bac à sable |
| CLI dans un shell | Presque nul | Outils pour développeurs | Nécessite un terminal |
| CLI avec un fichier de compétences | Très faible | Workflows répétables | Demande une maintenance |
Les outils en ligne de commande traînent derrière eux des décennies de documentation, de réponses sur les forums et d’historique de shell. Un modèle à qui l’on demande de lister les pull requests ouvertes par un auteur donné écrira la bonne ligne du premier coup :
gh pr list --state open --json number,title,author \
| jq '.[] | select(.author.login == "maria") | .title'
Une seule ligne, et seuls les titres finaux parviennent au modèle. Le JSON brut n’entre jamais dans le contexte. Les tubes, les filtres et les redirections offrent aux agents une capacité de composition sans effort supplémentaire.
Une CLI n’annonce pas toute sa surface d’emblée. L’agent exécute --help pour la seule sous-commande dont il a besoin, lit quelques lignes et passe à la suite. C’est la divulgation progressive, précisément ce qui manque aux grands schémas d’outils.
Il y a aussi un bénéfice pour l’humain. Tout ce que l’agent exécute, vous pouvez le lancer vous-même dans un terminal pour reproduire un bug. Pas de protocole caché, pas d’inspecteur spécial.
💡 Règle empirique : si une CLI mature existe déjà pour la tâche (git, gh, aws, kubectl, docker), laissez l’agent l’utiliser.
Un ingénieur de Google DeepMind a formulé le contre-argument le plus net : si votre agent vit dans une application de notes sur téléphone, « utilisez simplement la CLI » n’est pas une option. Il en va de même pour les applications de chat dans le navigateur, les assistants d’entreprise verrouillés et tout bac à sable sans accès aux processus. La plupart des personnes qui utilisent l’IA au quotidien ne sont pas assises devant un terminal.
Un shell est un outil sans finesse. Un agent doté d’un terminal hérite du système de fichiers, des variables d’environnement et de toutes les sessions ouvertes sur cette machine. Vous pouvez le cloisonner, mais par défaut, tout est grand ouvert.
Pour être honnête, aucune des deux voies n’est sûre par défaut. Une page web, un courriel ou un ticket peut contenir des instructions cachées destinées au modèle, et ce risque existe aussi bien si le texte arrive par un appel d’outil que par la sortie de curl. Les bacs à sable, les identifiants en lecture seule et l’approbation humaine des actions risquées comptent dans les deux cas. La différence tient à ceci : le MCP vous offre un endroit naturel pour appliquer ces limites, alors qu’un shell brut vous laisse tout gérer vous-même.
Un serveur MCP ne peut exposer que les outils que vous choisissez. Un serveur distant peut utiliser OAuth, si bien que chaque personne agit sous sa propre identité, et une passerelle centrale peut journaliser chaque appel. Pour une équipe de cinquante personnes, c’est nettement préférable à cinquante ordinateurs portables stockant chacun un jeton de longue durée dans un fichier de configuration.
Le protocole répond aux mêmes critiques que celles formulées par ses détracteurs, et rapidement :
Voici un résumé pratique de l’ambiance actuelle : utilisez une CLI lorsque vous disposez d’un terminal, un serveur MCP sélectionné lorsque vous avez besoin d’un protocole, et ne convertissez jamais automatiquement une API entière en des dizaines d’outils.
| Situation | Meilleur choix | Pourquoi |
|---|---|---|
| Agent de programmation local avec un terminal | CLI | Surcharge minimale, les modèles connaissent les outils |
| L’outil dispose déjà d’une excellente CLI | CLI | Les tubes gardent les données hors du contexte |
| Application de chat dans le navigateur ou sur téléphone | MCP | Aucun shell disponible |
| Nombreux utilisateurs, outils partagés, besoins d’audit | MCP | OAuth, outils à périmètre défini, journaux centralisés |
| SaaS sans CLI et avec OAuth uniquement | MCP | Connexion standard et schéma d’outils |
| Long flux de travail déplaçant de gros fichiers | Exécution de code | Les données restent hors du modèle |
La plupart des équipes finissent par utiliser les deux. Le MCP gère les quelques systèmes qui exigent une connexion et une gouvernance, et la CLI couvre tout ce que les développeurs font déjà dans un terminal.
Voici à quoi cela ressemble en pratique. Un développeur seul qui travaille avec un agent dans un terminal utilisera git, gh et docker toute la journée, et ajoutera un ou deux serveurs MCP pour les services qui n’ont pas de CLI, comme un outil de design ou un gestionnaire de tickets. Une équipe de support qui utilise un assistant de discussion dans le navigateur n’a aucun shell, si bien qu’un serveur MCP hébergé avec connexion est la seule voie possible. Une équipe plateforme qui fait tourner des dizaines d’agents veut des journaux centralisés et des outils à périmètre défini : elle place donc une passerelle devant quelques serveurs sélectionnés.
Les deux voies dépendent d’un modèle qui appelle les outils de façon fiable. Sur PicassoIA, vous pouvez comparer plusieurs grands modèles de langage au même endroit : Claude Sonnet 5 pour automatiser les tâches de programmation, GPT 5.6 Sol pour le travail de programmation complexe, Kimi K2.6 pour construire des agents, et Gemini 3.5 Flash pour le chat et le code rapides. Confiez la même tâche d’outil à deux d’entre eux et observez comment chacun gère un appel raté.
La génération d’images et de vidéos est un excellent banc d’essai pour ce débat. Les sorties sont volumineuses, les tâches prennent du temps et l’outil doit rendre compte de sa progression. PicassoIA expose les mêmes quatre modèles via un connecteur MCP et une API REST : PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video et Seedance 2.5 Lite pour la vidéo avec son.
Jusqu’à cinq tâches peuvent tourner simultanément par compte, partagées entre toutes les connexions.
Remarquez ce que le protocole fait bien ici. L’assistant n’a pas besoin de connaître une URL, un en-tête ou un intervalle d’interrogation. Les descriptions d’outils lui indiquent comment lancer une tâche et comment en suivre l’avancement, et le résultat revient dans la conversation. Cette commodité est exactement ce que promet le MCP, et pour un utilisateur non technique dans un navigateur, c’est la différence entre « ça marche » et « impossible ».
Les mêmes modèles sont disponibles à https://api.picassoia.com/v1, avec un jeton Bearer qui commence par pia_sk_. La structure suit le style de Replicate : créer une prédiction, l’interroger, récupérer le résultat.
curl -s https://api.picassoia.com/v1/models/picassoia/picassoia-image/predictions \
-H "Authorization: Bearer $PICASSOIA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"input": {"prompt": "A lighthouse at dawn, natural light, 16:9"}}'
La réponse contient un identifiant de prédiction. Interrogez GET /v1/predictions/{id} jusqu’à ce que le statut indique succeeded, puis téléchargez le fichier. Consultez les pages de l’API sur picassoia.com pour connaître les champs de saisie exacts de chaque modèle.
💡 À essayer vous-même : lancez le même prompt une fois via le connecteur MCP, puis une fois via curl. Chronométrez les deux, comptez les étapes et décidez laquelle correspond à votre flux de travail.
Le MCP n’est pas mort, et la CLI n’est pas une mode passagère. Ce sont deux outils aux rôles différents, et la bonne décision consiste à associer chacun à l’endroit où votre agent travaille réellement. Ouvrez picassoia.com, choisissez un modèle, rédigez votre premier prompt et voyez les deux voies à l’œuvre avec vos propres images.
Choisissez votre langue
