MCP n’est pas mort, mais ce n’est plus la réponse par défaut. Cet article compare les serveurs MCP aux CLI, aux fichiers de compétences et aux API directes, montre où les serveurs distants restent les plus efficaces pour l’authentification, les longs traitements et les pistes d’audit, et se termine par une liste de contrôle de cinq minutes que vous pouvez utiliser dès aujourd’hui.
Tous les quelques mois, quelqu’un affirme que MCP est mort, et tous les quelques mois, une équipe met en production un nouveau serveur MCP. Les deux affirmations sont vraies en même temps. Les modèles sont devenus bien meilleurs pour exécuter des commandes shell, lire la documentation et écrire de petits scripts, si bien que beaucoup des premières raisons d’envelopper chaque outil dans un protocole ont perdu de leur force. Pourtant, certaines tâches ont encore besoin d’une interface standard, authentifiée et distante, à laquelle tout agent peut se connecter sans code d’adaptation sur mesure. Cet article répartit ces deux groupes. Vous verrez où une simple CLI ou un fichier de compétences l’emporte sur un serveur MCP, où le serveur reste le meilleur choix, et comment décider en cinq minutes environ.
Le Model Context Protocol, ou MCP, est un standard ouvert qu’Anthropic a publié en novembre 2024. Il définit la manière dont une application d’IA (le client) demande à un programme séparé (le serveur) trois choses : des outils qu’elle peut appeler, des ressources qu’elle peut lire et des prompts qu’elle peut réutiliser. Les messages circulent en JSON-RPC, via l’entrée et la sortie standard pour les serveurs locaux, ou via Streamable HTTP pour les serveurs distants. OpenAI et Google l’ont adopté en 2025, et le protocole a ensuite été transféré à l’Agentic AI Foundation de la Linux Foundation, si bien qu’aucun fournisseur unique ne le contrôle.
Pensez-y comme à un adaptateur de voyage. La prise murale (le service) et la fiche (l’agent) n’ont jamais besoin de se connaître. L’adaptateur au milieu gère l’incompatibilité.
Avant MCP, connecter M assistants à N services impliquait M fois N intégrations sur mesure. Chaque paire avait son propre flux de connexion, ses propres particularités de schéma et ses propres bogues. MCP a ramené cela à M plus N : un serveur par service, un client par assistant, et toutes les combinaisons fonctionnent. Ce gain est réel, et il explique pourquoi des milliers de serveurs publics sont apparus en un an environ après son lancement.
💡 À retenir : MCP est de la plomberie, pas de l’intelligence. Jugez-le selon le fait que la plomberie coûte moins cher que l’alternative pour votre tâche précise, pas selon sa popularité du moment.
Les critiques ne sont pas infondées. Trois reproches reviennent sans cesse, et chacun résiste à la mesure.
Chaque outil exposé par un serveur arrive avec un nom, une description et un schéma JSON. La plupart des clients chargent tous ces outils dans la fenêtre de contexte du modèle au début d’une session. Voici un calcul approximatif, à titre d’illustration : un serveur de 40 outils, à environ 400 tokens par schéma, ajoute 16 000 tokens. Connectez cinq serveurs de cette taille et vous aurez consommé 80 000 tokens avant que l’utilisateur ne tape le moindre mot.
Cette facture a trois composantes : l’argent, la latence et l’attention. Les tokens coûtent de l’argent à chaque requête, des prompts plus longs répondent plus lentement, et un contexte encombré laisse moins de place aux éléments dont le modèle a réellement besoin. La qualité de sélection tend aussi à baisser lorsque deux serveurs exposent chacun un outil nommé search et que le modèle doit deviner lequel vous visiez.
Les agents de programmation maîtrisent git, gh, curl, jq, docker et psql. Ces outils apparaissent des milliers de fois dans les données d’entraînement, ils disposent d’un indicateur --help, et leur sortie est en texte brut. Quand un modèle peut exécuter gh pr list --json title,author et analyser le résultat, un serveur MCP GitHub ajoute une couche sans ajouter beaucoup de capacités.
Une CLI se compose aussi. Le modèle enchaîne une commande sur une autre, écrit la sortie dans un fichier et ne lit que les lignes dont il a besoin. Un appel d’outil MCP renvoie l’intégralité de son résultat dans le contexte, sauf si l’auteur du serveur a prévu une pagination, ce que beaucoup n’ont pas fait.
Les fichiers de skills suivent une autre voie. Un skill est un dossier contenant une courte description en markdown et, facultativement, des scripts. Seuls le nom et un résumé d’une ligne figurent dans le contexte jusqu’à ce que l’agent juge qu’il a besoin du skill, et ce n’est qu’alors qu’il lit les instructions complètes. Vous payez au moment où le travail a lieu, pas à chaque requête.
Pour les workflows internes comme « comment nous déployons », « comment nous rédigeons les notes de version » ou « comment nous interrogeons l’entrepôt de données », un skill accompagné d’un script est souvent le chemin le plus court. Il n’y a aucun serveur à héberger, aucun transport à déboguer, et tout se trouve dans le dépôt, à côté du code qu’il décrit.
Voyons maintenant l’autre côté. Ce sont les situations où remplacer MCP par des scripts crée plus de travail, et non moins.
Un script sur un ordinateur portable peut lire un jeton d’API depuis une variable d’environnement. Cela fonctionne pour un seul développeur. Cela ne tient plus lorsque cinquante personnes ont besoin d’accéder à un CRM, chacune avec des droits différents, et que l’équipe sécurité veut des jetons qui expirent. Le flux d’autorisation de MCP repose sur OAuth 2.1 : un serveur distant peut demander à chaque utilisateur de se connecter, émettre des jetons limités à un périmètre précis et les révoquer depuis un point central. L’agent ne détient jamais un secret durable collé dans l’historique du shell.
Les serveurs hébergés continuent aussi de fonctionner là où il n’existe aucun shell : une application de chat, un client mobile, une barre latérale de navigateur. Une CLI nécessite un terminal. Un serveur MCP distant nécessite une connexion réseau.
Certaines tâches prennent des minutes, et non des millisecondes. La génération d’images et de vidéos en est l’exemple le plus clair. Une requête lance un travail, un GPU quelque part le prend en charge, et l’appelant doit revenir vérifier plus tard. Une commande shell qui bloque pendant quatre-vingt-dix secondes est peu pratique. Un outil doté d’un contrat défini de démarrage, d’interrogation et de résultat est plus facile à mettre en œuvre correctement.
Le connecteur propre à PicassoIA suit ce modèle. Son API est de type Replicate : créer une prédiction, l’interroger, récupérer la sortie. Grâce à la connexion MCP, un agent peut accéder à quatre modèles, PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video et Seedance 2.5 Lite pour la vidéo avec son, sans que personne ait à écrire les points de terminaison à la main. La plateforme autorise cinq prédictions simultanées par compte, partagées entre les identifiants d’API et les connexions MCP, si bien qu’un agent qui envoie dix requêtes d’un coup doit respecter cette limite. Un serveur bien conçu masque cette comptabilité derrière des résultats d’outils clairs, un peu comme un passe de cuisine maintient les commandes dans l’ordre pendant que les cuisiniers travaillent en parallèle.
Imaginez une équipe de contenu demandant à un agent un article de lancement, cinq images phares et un court clip animé. La rédaction se fait à l’intérieur du modèle. Les images et le clip sont distants, lents et soumis à des limites de débit, ce qui correspond exactement au cas que MCP gère bien.
Dès qu’un agent touche aux données de production, quelqu’un demande qui a fait quoi. Une passerelle MCP centrale peut journaliser chaque appel d’outil, appliquer des listes d’autorisation par équipe et bloquer les actions risquées avant qu’elles n’atteignent le service. Faire la même chose avec des scripts ad hoc oblige à courir après les journaux sur plusieurs ordinateurs portables.
Les relecteurs apprécient cela. Ils peuvent lire un seul journal et un seul fichier de politique pour voir ce que l’agent était autorisé à faire, au lieu d’auditer cinquante historiques de shell différents.
Voici la même comparaison sous forme de tableau de référence rapide.
| Situation | Meilleur choix | Pourquoi ce choix |
|---|---|---|
| Git local, fichiers, outils de build | CLI | Les modèles connaissent déjà les commandes, aucune configuration |
| Workflow d’équipe comme les notes de version | Skill accompagné d’un script | Chargé à la demande, vit dans le dépôt |
| Produit SaaS avec permissions par utilisateur | Serveur MCP distant | Connexion OAuth, révocation, journaux centralisés |
| Génération d’images ou de vidéos | MCP ou API directe | Tâches asynchrones, limites de concurrence partagées |
| Extraction ponctuelle de données dans un script | Appel d’API directe | Le moins de pièces mobiles |
| Agent dans une application de chat sans shell | Serveur MCP distant | Aucun terminal disponible |
| Outil nécessaire dans 1 session sur 100 | Skill ou MCP à chargement différé | Évite de payer le coût du schéma à chaque fois |
Remarquez que la réponse est rarement tout MCP ou pas de MCP. Le bon choix dépend de qui appelle l’outil, de la durée de son exécution et de la fréquence à laquelle il est nécessaire.
Les critiques ont porté, et l’écosystème a réagi. Deux évolutions comptent surtout.
L’équipe d’ingénierie d’Anthropic a décrit fin 2025 un schéma dans lequel l’agent écrit du code qui appelle les outils MCP, au lieu de faire passer chaque appel par la fenêtre de contexte. Les définitions d’outils apparaissent sous forme de fichiers que l’agent peut parcourir, les résultats intermédiaires restent dans un bac à sable, et seule la réponse finale revient au modèle. Dans leur exemple détaillé, la consommation de tokens est passée d’environ 150 000 à environ 2 000, soit une réduction de 98,7 %.
Plusieurs clients chargent désormais les définitions d’outils à la demande. Le modèle interroge un catalogue, récupère les deux ou trois outils dont il a besoin et ignore le reste. C’est l’approche du catalogue de bibliothèque : la bibliothèque compte des milliers de fiches, mais vous n’ouvrez qu’un tiroir. Cela supprime le principal reproche de la section précédente sans renoncer au standard.
Les auteurs de serveurs se sont aussi adaptés. Un serveur avec six outils de haut niveau bien décrits fait mieux qu’un serveur qui reproduit ligne par ligne une API REST de 300 points de terminaison, car le modèle a moins de choix et chaque choix a un sens.
Parcourez cette liste avant de construire ou d’installer quoi que ce soit.
La plupart des ensembles d’outils matures utilisent les trois. Un agent de programmation exécute le shell pour git et les tests, lit un skill pour les conventions d’équipe, et se connecte à deux ou trois serveurs MCP distants pour le gestionnaire de tickets, la base de données et la génération de médias. Vous pouvez tester les mêmes idées d’appel d’outils avec les LLM disponibles sur PicassoIA, comme Claude Sonnet 5, GPT 5.6 Sol, Kimi K2.6 et Gemini 3.5 Flash. Le choix du modèle compte moins que le fait de garder une surface d’outils réduite et honnête.
ls ou cat ajoute un processus, un transport et un schéma en échange de rien que le shell ne fournisse déjà.Alors, avons-nous encore besoin de MCP ? Pour les outils locaux et bien connus, en général non. Pour les services distants, authentifiés, lents et partagés, en général oui. Cette répartition est toute la réponse, et elle continuera d’évoluer à mesure que les clients deviendront plus efficaces pour charger les outils.
Si vous voulez voir un workflow distant et asynchrone en action sans lire de spécification, générez quelque chose. Ouvrez Picasso IA, choisissez PicassoIA Image pour une image fixe rapide, affinez-la avec PicassoIA Image Editor Pro, puis animez le résultat avec PicassoIA Video. Chaque image de cet article est née d’un prompt en langage courant, et le même workflow est accessible à un agent via la connexion MCP. Parcourez tout le catalogue sur picassoia.com/en/all-models, saisissez une idée et voyez jusqu’où une seule phrase peut mener.
Choisissez votre langue
