En février 2026, Eric Holmes, ingénieur infrastructure, a publié un article qui a secoué l'écosystème de l'intelligence artificielle. Son constat est sans appel : le Model Context Protocol (MCP), lancé en grande pompe par Anthropic, serait déjà en train de mourir. Une affirmation audacieuse qui mérite qu'on s'y attarde, car elle révèle une vérité dérangeante sur notre tendance à complexifier ce qui pourrait rester simple.
Lorsqu'Anthropic a annoncé le MCP, l'industrie technologique a réagi avec un enthousiasme débordant. Chaque entreprise s'est empressée de développer ses propres serveurs MCP pour prouver son engagement envers l'IA. Pourtant, des acteurs majeurs comme OpenClaw et Pi ont choisi de ne pas l'adopter. Cette résistance soulève une question fondamentale : avions-nous vraiment besoin d'un nouveau protocole pour que les assistants IA comme Claude interagissent avec nos outils ?
Les modèles de langage excellent avec les CLI traditionnels
Les grands modèles de langage possèdent une capacité remarquable : ils savent utiliser les outils en ligne de commande de manière intuitive. Entraînés sur des millions de pages de documentation, de réponses Stack Overflow et de dépôts GitHub remplis de scripts shell, ils maîtrisent naturellement la syntaxe CLI.
Quand un développeur demande à Claude d'exécuter gh pr view 123, l'outil fonctionne immédiatement. Le MCP promettait une interface plus propre, mais dans la pratique, les développeurs se retrouvent à rédiger la même documentation : description de chaque outil, paramètres acceptés, et surtout, contexte d'utilisation. L'IA n'avait pas besoin d'un protocole spécifique pour comprendre ces commandes.
Cette observation rejoint les principes fondamentaux évoqués dans notre guide sur l'intégration de l'IA en entreprise, où la simplicité des outils existants reste un atout majeur.
L'avantage décisif de la transparence
L'un des arguments les plus convaincants en faveur des CLI concerne la transparence. Lorsque Claude effectue une action inattendue avec Jira, n'importe quel développeur peut exécuter la même commande jira issue view et observer exactement ce que l'IA a vu. Même entrée, même sortie, aucun mystère.
Avec le MCP, l'outil n'existe que dans la conversation avec le modèle de langage. En cas de problème, le développeur doit fouiller dans des journaux de transport JSON au lieu de simplement relancer la commande. Le débogage ne devrait pas nécessiter un décodeur de protocole propriétaire.
Un écosystème déjà mature
Les outils CLI bénéficient de décennies d'évolution. Ils s'intègrent parfaitement dans les flux de travail existants, fonctionnent aussi bien pour les humains que pour les machines, et s'appuient sur des systèmes d'authentification éprouvés. Pourquoi réinventer la roue ?
La composabilité : l'atout majeur des CLI
C'est ici que l'écart entre MCP et CLI devient flagrant. Les interfaces en ligne de commande se composent naturellement. On peut les enchaîner avec des pipes, les filtrer avec grep, rediriger les sorties vers des fichiers. Cette flexibilité n'est pas qu'une commodité : c'est souvent la seule approche pratique.
Prenons l'exemple de l'analyse d'un plan Terraform volumineux :
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
Avec le MCP, deux options s'offrent au développeur : déverser l'intégralité du plan dans la fenêtre de contexte (coûteux et souvent impossible) ou créer un filtrage personnalisé dans le serveur MCP lui-même. Dans les deux cas, plus de travail pour un résultat inférieur.
| Critère | CLI | MCP |
|---|---|---|
| Composabilité | Pipes, redirections, chaînage natif | Limitée au serveur MCP |
| Débogage | Commandes reproductibles manuellement | Analyse de logs JSON |
| Authentification | Systèmes existants (SSO, OAuth) | Protocole propriétaire |
| Maintenance | Binaires statiques | Processus en arrière-plan |
| Courbe d'apprentissage | Documentation mature | Nouvelle spécification |
L'approche CLI utilise des outils qui existent déjà, sont parfaitement documentés, et que les humains comme les agents comprennent intuitivement.
L'authentification : un problème déjà résolu
Le MCP adopte une position inutilement dogmatique sur l'authentification. Pourquoi un protocole destiné à fournir des outils à une IA devrait-il se préoccuper de l'authentification ?
Les outils CLI s'en moquent. aws utilise des profils et SSO. gh s'appuie sur gh auth login. kubectl exploite kubeconfig. Ce sont des flux d'authentification éprouvés qui fonctionnent de la même manière, qu'un humain soit au clavier ou que Claude pilote l'opération.
Résolution des problèmes d'authentification
Quand l'authentification échoue, la correction suit un processus familier : aws sso login, gh auth refresh. Aucun dépannage spécifique au MCP requis. Cette simplicité rappelle l'importance de maîtriser les concepts fondamentaux plutôt que d'accumuler les couches d'abstraction.
La simplicité architecturale des CLI
Les serveurs MCP locaux sont des processus. Ils doivent démarrer, rester actifs, et ne pas se bloquer silencieusement. Dans Claude Code, ils sont lancés comme processus enfants, ce qui fonctionne jusqu'à ce que ça ne fonctionne plus.
Les outils CLI sont simplement des binaires sur le disque. Pas de processus en arrière-plan, pas d'état à gérer, pas de danse d'initialisation. Ils sont là quand on en a besoin et invisibles quand ce n'est pas le cas.
Les frictions quotidiennes du MCP
Au-delà de la philosophie de conception, le MCP présente des frictions concrètes au quotidien :
- Initialisation capricieuse : Les redémarrages de Claude Code à cause d'un serveur MCP qui ne démarre pas se comptent par dizaines. Parfois ça fonctionne au second essai, parfois il faut effacer l'état et tout recommencer.
- Authentification répétitive : Utiliser plusieurs outils MCP ? Préparez-vous à authentifier chacun d'eux. Les CLI avec SSO ou identifiants longue durée n'ont tout simplement pas ce problème.
- Permissions binaires : Claude Code permet de mettre en liste blanche les outils MCP par nom, c'est tout. Impossible de limiter aux opérations en lecture seule ou de restreindre les paramètres. Avec les CLI, on peut autoriser gh pr view mais exiger une approbation pour gh pr merge. Cette granularité compte.
Ces limitations pratiques font écho aux défis rencontrés lors de la création d'interfaces utilisateur efficaces : la simplicité technique facilite l'adoption.
Quand le MCP garde sa pertinence
Il serait malhonnête de prétendre que le MCP est complètement inutile. Si un outil n'a vraiment aucun équivalent CLI, le MCP peut représenter la bonne solution. De nombreux développeurs l'utilisent encore quotidiennement, quand c'est la seule option disponible.
On pourrait même argumenter qu'il existe une certaine valeur dans une interface standardisée, et que certains cas d'usage justifient le MCP plutôt qu'une CLI. Mais pour l'immense majorité du travail, l'interface en ligne de commande reste plus simple, plus rapide à déboguer et plus fiable.
Cas d'usage légitimes du MCP
Le MCP peut se justifier pour :
- Les services web sans API publique documentée
- Les intégrations nécessitant une gestion d'état complexe
- Les environnements où l'installation de binaires est impossible
- Les workflows nécessitant une validation en temps réel côté serveur
Ces scénarios restent toutefois minoritaires comparés aux usages quotidiens des développeurs.
La leçon fondamentale pour l'écosystème IA
Les meilleurs outils sont ceux qui fonctionnent aussi bien pour les humains que pour les machines. Les CLI ont bénéficié de décennies d'itération de conception. Elles sont composables, débogables, et s'appuient sur des systèmes d'authentification qui existent déjà.
Le MCP a tenté de construire une meilleure abstraction. Il s'avère que nous en avions déjà une plutôt efficace. Cette observation rejoint les réflexions sur la façon dont notre cerveau interagit avec l'IA : la simplicité cognitive prime sur la complexité technique.
Recommandations pour les entreprises
Si votre entreprise investit dans un serveur MCP mais ne dispose pas de CLI officielle, il est temps de reconsidérer votre approche. Privilégiez cette stratégie :
- Développez une API solide et bien documentée
- Créez une CLI de qualité qui exploite cette API
- Laissez les agents IA découvrir et utiliser ces outils naturellement
Cette approche pragmatique s'aligne avec les principes de communication efficace : clarté et accessibilité avant tout.
L'avenir des interactions homme-machine-IA
L'évolution technologique nous enseigne que les solutions durables sont rarement les plus sophistiquées, mais les plus adaptées. Les interfaces en ligne de commande ont survécu à des décennies de révolutions technologiques parce qu'elles résolvent des problèmes réels avec une élégance minimaliste.
Le débat MCP vs CLI illustre une tendance plus large dans l'industrie : notre propension à créer de nouvelles couches d'abstraction avant de maîtriser celles qui existent. Comme le souligne l'évolution des relations entre IA et institutions, la standardisation doit servir l'utilisateur final, pas compliquer son quotidien.
Les développeurs qui construisent les outils de demain feraient bien de se rappeler cette leçon : avant d'inventer un nouveau protocole, demandez-vous si les outils existants ne font pas déjà le travail. La plupart du temps, la réponse sera oui.
Pour aller plus loin dans votre utilisation de l'IA et découvrir comment simplifier vos workflows de développement, créez votre compte gratuit sur Roboto et explorez nos outils de génération de contenu optimisés pour les développeurs.
