MCP vs CLI : le débat agite la communauté tech depuis l’explosion des agents IA. Faut-il adopter le Model Context Protocol pour piloter nos outils ou continuer à utiliser le bon vieux terminal ? Derrière la hype, une question simple : a-t-on vraiment besoin d’un nouveau protocole quand le CLI fait déjà parfaitement le travail ?

Spoiler : ce débat est moins technique qu’il n’y paraît.
Et un peu plus philosophique aussi.

🔥 Le contexte : MCP, la nouvelle promesse des agents IA

Le Model Context Protocol (MCP) a été proposé par Anthropic comme un standard permettant aux modèles de langage d’interagir proprement avec des outils externes : bases de données, API, systèmes, services cloud.

L’idée est séduisante :

• Décrire des capacités sous forme structurée
• Exposer des “tools” aux modèles
• Encadrer les appels et les retours
• Formaliser la sécurité et l’authentification

En théorie, c’est élégant.
En pratique ? C’est une couche supplémentaire.

Et comme toujours en informatique, une couche supplémentaire, c’est :

• plus de complexité
• plus de surface d’attaque
• plus de choses à débugger à 23h42 un vendredi

🧠 La réalité : les LLM comprennent déjà le CLI

Les grands modèles ont été entraînés sur :

• des millions de README GitHub
• des pages man
• des scripts Bash
• des pipelines CI/CD
• des discussions StackOverflow
• des commits crasseux écrits à 2h du matin

En clair : les LLM parlent couramment CLI.

Donnez-leur :

gh issue list
aws s3 ls
kubectl get pods
jq '.users[] | select(.active == true)'

Et ils comprennent.

Ils savent chaîner.
Ils savent parser.
Ils savent expliquer.
Ils savent corriger.

Alors poser la question devient légitime :

Pourquoi créer un protocole pour expliquer à un modèle ce qu’il sait déjà faire ?

🛠️ CLI : brutal, lisible, universel

Le CLI a des qualités que les architectes aiment parfois oublier :

1️⃣ Il est observable

Quand une commande échoue, tu vois :

• le code retour
• la sortie d’erreur
• le log brut
• la commande exacte exécutée

Avec un protocole abstrait, tu vois :

« Tool call failed. »

Merci.

2️⃣ Il est composable

Le CLI, c’est Unix.
Unix, c’est :

tool | grep | awk | jq | sort | uniq

C’est simple.
C’est puissant.
C’est transparent.

Les protocoles formalisés tentent souvent de recréer cette capacité… en moins lisible.

3️⃣ Il est universel

Mac ? Linux ? Windows ?
Cloud ? On-prem ?
Docker ? VM ?

Le terminal est là.

Le CLI est la lingua franca de l’infrastructure moderne.

🤖 MCP : utile… mais dans quels cas ?

Soyons sérieux. MCP n’est pas inutile.

Il devient pertinent quand :

• Il n’existe pas de CLI natif pour un outil
• On veut encapsuler proprement des capacités complexes
• On développe un environnement agent-first
• On veut gérer finement permissions et sandboxing

Dans des architectures multi-agents sophistiquées, un protocole structuré peut simplifier l’orchestration.

Mais dans 80 % des usages dev / ops ?

Le CLI suffit.

🔐 Sécurité : paradoxe intéressant

Le CLI a déjà :

• des systèmes d’auth solides (aws sso, gh auth login)
• des politiques RBAC
• des journaux d’audit
• des permissions OS natives

Créer un protocole supplémentaire, c’est :

• redéfinir un modèle d’auth
• redéfinir des scopes
• redéfinir des flux

On ajoute une couche.

Or en cybersécurité, on sait une chose :

Chaque couche mal maîtrisée devient une future CVE.

🧩 Le vrai débat : abstraction vs maîtrise

Le débat MCP vs CLI n’est pas technique.
Il est culturel.

Il oppose deux visions :

🧙 La vision abstraction totale

« Le modèle doit tout piloter proprement via un protocole standardisé. »

🧑‍🔧 La vision artisanale maîtrisée

« Donne-moi le terminal, je sais ce que je fais. »

L’histoire de l’informatique est une alternance entre :

• abstraction
• simplification
• perte de contrôle
• retour aux fondamentaux

On a eu :

• les GUI qui remplaçaient le terminal
• puis DevOps
• puis Infrastructure as Code
• puis Kubernetes YAML
• puis GitOps
• puis agents IA

Et à chaque fois ?

Le terminal ne meurt jamais.

📈 Performance & efficacité

Un point rarement évoqué : la latence cognitive.

Avec un CLI :

• tu écris
• tu vois
• tu ajustes

Avec un protocole :

• tu structures
• tu déclares
• tu encapsules
• tu testes
• tu relies au modèle

Le coût mental n’est pas nul.

Quand tu veux juste lister des buckets S3,
tu n’as pas besoin d’un framework philosophique.

🧨 Le piège de la hype

Chaque génération tech pense avoir inventé la solution définitive.

Le MCP est séduisant car :

• il sonne moderne
• il parle d’agents
• il parle de standardisation
• il parle d’interopérabilité

Mais le CLI a un avantage terrible :

Il fonctionne déjà.

🧑‍💻 Et pour les agents IA alors ?

C’est là que le débat devient intéressant.

Les agents IA n’ont pas besoin que le monde soit abstrait.
Ils ont besoin que le monde soit prévisible.

Un CLI bien documenté est :

• déterministe
• scriptable
• traçable
• testable

En réalité, un agent bien conçu peut très bien :

• générer une commande
• la valider
• la sandboxer
• analyser le retour

Sans protocole supplémentaire.

📚 Une leçon historique

Les protocoles gagnent quand :

• ils remplacent un chaos
• ils simplifient l’intégration
• ils standardisent un marché fragmenté

Mais le CLI n’est pas un chaos.

C’est une interface déjà standardisée depuis 40 ans.

Vouloir l’abstraire, c’est parfois résoudre un problème qui n’existe pas.

🛡️ Sécurité offensive : surface d’attaque MCP vs CLI

Maintenant on enlève le costume de philosophe tech.
On met la casquette Red Team.

Parce que le débat MCP vs CLI n’est pas seulement une question d’élégance architecturale.

C’est une question de surface d’attaque.

🎯 1️⃣ Le CLI : surface maîtrisée, périmètre connu

Un CLI classique repose sur :

• un binaire local
• des permissions OS
• des variables d’environnement
• un modèle d’auth déjà intégré (SSO, token, clé API)
• un audit log côté système

Les vecteurs d’attaque sont connus :

• injection de commande
• élévation de privilèges
• vol de token
• mauvaise gestion des variables d’environnement

Ce sont des problèmes vieux comme Unix.
Et donc — relativement — maîtrisés.

Un RSSI sait :

• où regarder les logs
• comment restreindre les permissions
• comment sandboxer l’exécution
• comment tracer l’activité

Le périmètre est clair :
le système d’exploitation.

🧨 2️⃣ MCP : nouvelle couche = nouvelle surface

Un protocole comme MCP introduit :

• un serveur MCP
• un schéma de déclaration des tools
• un mécanisme d’appel distant
• un modèle de permissions applicatif
• une couche d’abstraction entre modèle et système réel

Chaque élément est un point d’entrée potentiel.

Concrètement, on ajoute :

• 🔹 une API exposée
• 🔹 un format d’appel structuré
• 🔹 un parseur côté serveur
• 🔹 une logique d’autorisation custom
• 🔹 un système de sérialisation/désérialisation

Et donc :

• plus de parsing
• plus de validation
• plus d’interfaces réseau
• plus de logique métier

Chaque ligne de code supplémentaire est une opportunité pour :

• une injection
• un bypass d’autorisation
• une mauvaise configuration
• un bug logique

En cybersécurité, ce n’est pas un jugement moral.

C’est une loi statistique.

🔥 3️⃣ Attaque par confusion de contexte

Un scénario intéressant en offensive :

Avec un CLI, l’agent exécute une commande visible :

aws s3 ls

Avec un protocole, l’agent appelle :

{
  "tool": "list_buckets",
  "context": {...}
}

Si le contrôle de contexte est mal implémenté :

• un agent peut hériter de permissions inattendues
• un tool peut exposer plus que prévu
• un modèle peut déclencher une action hors périmètre

On entre dans une zone plus floue :

la sécurité applicative dépend de la qualité de l’implémentation MCP.

Avec un CLI, la sécurité dépend :

• du système
• des droits utilisateur
• du binaire

La responsabilité est plus concentrée.

🕳️ 4️⃣ Surface réseau vs surface locale

CLI local :

• exécution locale
• contrôlée par l’OS
• audit système
• pas forcément exposé en réseau

Serveur MCP :

• souvent exposé en local TCP
• parfois exposé en réseau interne
• parfois interconnecté à plusieurs services

On vient d’ajouter :

• un port ouvert
• un service écoutant
• une logique d’auth à protéger
• un canal de communication supplémentaire

Et chaque service exposé est :

• scannable
• attaquable
• exploitable si mal configuré

Même en interne.

Surtout en interne.

🧠 5️⃣ Le facteur humain

Un autre point rarement évoqué :

Le CLI est rustique.

Donc il pousse naturellement à :

• tester
• comprendre
• lire la doc
• maîtriser la commande

Un protocole “intelligent” peut créer un faux sentiment de sécurité :

“C’est structuré, donc c’est sécurisé.”

C’est exactement le type de biais cognitif que les attaquants adorent.

⚔️ 6️⃣ Exploitabilité comparative

En Red Team, on raisonne ainsi :

La variable clé ici n’est pas la technologie.

C’est la complexité.

Or la complexité est l’alliée naturelle de la vulnérabilité.

💀 7️⃣ Prompt injection & tool abuse

Autre angle intéressant :

Avec des agents IA, les attaques par prompt injection sont déjà un sujet critique.

Si un agent a accès à des tools MCP mal cloisonnés :

• il peut appeler des capacités sensibles
• il peut contourner des contrôles
• il peut enchaîner des actions inattendues

Plus les tools sont abstraits, plus il faut :

• une validation stricte
• un contrôle de permission robuste
• un monitoring fin

Sinon on transforme un agent “assistant” en opérateur privilégié.
 MCP d’Anthropic : Et si votre IA vous trahissait ?

Avec un CLI bien sandboxé, l’agent agit dans un cadre plus prévisible.

🎯 Conclusion offensive

MCP n’est pas une mauvaise idée.

Mais du point de vue sécurité offensive :

Ajouter une couche abstraite ne réduit jamais mécaniquement le risque.

Elle peut :

• structurer
• standardiser
• clarifier

Mais elle augmente toujours :

• la surface d’attaque
• la complexité
• les points de défaillance

Et en cybersécurité, nous avons appris une chose simple :

La complexité est l’ennemi silencieux de la sécurité.

🏁 Bref : le CLI ne mourra pas (désolé)

Non, MCP n’est pas mort.
Mais non, il ne remplacera pas le terminal.

Dans les architectures complexes, il aura sa place.
Dans la majorité des workflows dev / ops, le CLI restera roi.

Parce que :

• il est simple
• il est universel
• il est observable
• il est robuste
• il est déjà compris par les LLM

Et surtout :

Il ne cherche pas à être sexy.

Il cherche à fonctionner.

Et en 2026, c’est peut-être la chose la plus révolutionnaire qui soit.

🧠 Vision stratégique : que doivent décider les DSI et RSSI ?

Sortons du terminal.
Entrons en salle de comité.

Parce qu’au fond, la question MCP vs CLI n’est pas une guerre d’ingénieurs.
C’est une décision d’architecture, de gouvernance et de maîtrise du risque.

Et ça, c’est du ressort DSI / RSSI.

🏗️ 1️⃣ Standardiser ou capitaliser ?

Un DSI doit se poser une question simple :

Avons-nous un problème que MCP résout réellement ?

Si votre SI repose déjà sur :

• des CLI robustes (aws, az, kubectl, gh, terraform)
• des pipelines CI/CD
• une traçabilité centralisée
• une gouvernance IAM mature

Alors MCP ne remplace rien.
Il s’ajoute.

Et toute technologie qui s’ajoute doit justifier :

• son coût
• son risque
• sa valeur métier
• sa charge opérationnelle

Le rôle stratégique ici n’est pas de suivre la hype IA.

C’est d’arbitrer la complexité.

🛡️ 2️⃣ Gouvernance des agents IA : le vrai sujet

Le débat n’est pas MCP.

Le débat est :

Qui contrôle les agents ?
Qui valide leurs permissions ?
Qui audite leurs actions ?

Un RSSI mature ne demandera pas :

“Utilise-t-on MCP ?”

Il demandera :

• 🔹 Les agents sont-ils sandboxés ?
• 🔹 Les permissions sont-elles minimales ?
• 🔹 L’audit est-il centralisé ?
• 🔹 Le logging est-il corrélé au SIEM ?
• 🔹 Le principe du moindre privilège est-il respecté ?

MCP peut aider à structurer cela.
Mais il ne le garantit pas.

La sécurité ne vient jamais d’un protocole.

Elle vient d’une gouvernance.

📊 3️⃣ Cartographie des risques

Un RSSI doit intégrer dans son analyse :

Risque d’ajout de couche :

• augmentation de la surface d’attaque
• nouvelles dépendances techniques
• maintenance spécifique
• dette technique future

Risque de ne rien changer :

• perte d’agilité IA
• incapacité à orchestrer des agents complexes
• fragmentation des pratiques

La vraie question n’est pas “CLI ou MCP”.

C’est :

Quelle maturité avons-nous pour encadrer des agents autonomes ?

Si la réponse est :

“On ne sait déjà pas tracer proprement les accès admin…”

Alors le problème n’est pas MCP.

⚖️ 4️⃣ Décision pragmatique : matrice de maturité

Voici une lecture stratégique simple :

Autrement dit :

MCP est un outil de maturité élevée.

Ce n’est pas un point d’entrée.

💰 5️⃣ ROI & charge opérationnelle

Un DSI doit poser la question qui fâche :

• Qui maintient le serveur MCP ?
• Qui gère les mises à jour ?
• Qui écrit les spécifications tools ?
• Qui audite les flux ?
• Qui répondra lors d’un incident ?

La réponse ne doit jamais être :

“Le modèle va gérer.”

Un protocole supplémentaire implique :

• budget
• compétences
• monitoring
• documentation
• procédure incident

Et si la valeur métier n’est pas claire,
le ROI devient théorique.

🧩 6️⃣ Stratégie hybride : la voie intelligente

La vraie stratégie n’est pas binaire.

Une DSI mature peut :

• conserver les CLI existants
• encapsuler certains usages critiques
• introduire MCP uniquement sur périmètre maîtrisé
• isoler les agents dans un environnement contrôlé
• monitorer intensivement les premiers déploiements

On parle ici d’expérimentation gouvernée, pas d’enthousiasme naïf.

🚨 7️⃣ Message clair pour les RSSI

Si vous devez retenir une seule chose :

Les agents IA sont des comptes techniques avec un cerveau probabiliste.

Ils doivent être traités comme :

• des comptes de service
• avec rotation de clés
• contrôle d’accès strict
• monitoring comportemental
• corrélation SIEM

Peu importe qu’ils utilisent MCP ou CLI.

La priorité n’est pas l’interface.

La priorité est le contrôle.

🎯 Synthèse stratégique

Pour une DSI / RSSI :

• MCP n’est pas une révolution obligatoire.
• Le CLI n’est pas un archaïsme.
• La gouvernance est le vrai sujet.
• La complexité doit toujours être justifiée.
• L’agent IA doit être traité comme un acteur à privilèges.

Le danger n’est pas de choisir le CLI.

Le danger est d’introduire des agents autonomes sans cadre de maîtrise.

Et ça, aucune RFC ne le corrigera.

📉 Schéma comparatif : CLI vs MCP

🖥️ Architecture CLI (modèle direct)

[ Agent IA ]
       │
       ▼
[ Commande CLI ]
       │
       ▼
[ OS / Binaire ]
       │
       ▼
[ Ressource cible ]

🔎 Lecture :

• L’agent génère une commande
• Le système d’exploitation contrôle les permissions
• Le binaire exécute
• Les logs sont système-natifs
• Le périmètre est clair

Surface d’attaque :

• injection de commande
• vol de token
• mauvaise configuration OS

👉 Modèle simple, mature, auditable.

🔌 Architecture MCP (modèle abstrait)

[ Agent IA ]
       │
       ▼
[ Appel Tool MCP ]
       │
       ▼
[ Serveur MCP ]
       │
       ▼
[ Logique Tool ]
       │
       ▼
[ Ressource cible ]

🔎 Lecture :

• L’agent appelle un tool déclaré
• Le serveur MCP valide
• Le tool encapsule la logique
• La ressource est atteinte via couche applicative

Surface d’attaque supplémentaire :

• API MCP
• parsing JSON
• contrôle d’autorisation custom
• logique métier tool
• exposition réseau potentielle

👉 Modèle plus structuré… mais plus complexe.

⚖️ Comparatif synthétique

🧠 Lecture stratégique rapide (niveau COMEX)

CLI :

Simplicité, maturité, contrôle direct.

MCP :

Orchestration avancée, mais nouvelle dette technique potentielle.

🎯 Ce que montre réellement ce schéma

Le CLI repose sur :

• des briques éprouvées depuis 40 ans
• une responsabilité concentrée (OS + IAM)

MCP repose sur :

• une couche applicative supplémentaire
• une responsabilité distribuée (dev + infra + sécurité)

Et en cybersécurité, on sait que :

Plus la responsabilité est distribuée, plus la faille est probable.

📋 Encadré stratégique : Checklist DSI / RSSI avant d’adopter MCP (ou de rester en CLI)

🎯 Objectif : éviter que le débat technique ne devienne une dette stratégique.

🏗️ 1️⃣ Gouvernance & cadrage

• ☐ Les agents IA sont-ils formellement identifiés comme comptes techniques ?
• ☐ Une cartographie des permissions des agents existe-t-elle ?
• ☐ Le principe du moindre privilège est-il appliqué ?
• ☐ Un RACI est-il défini pour la gestion des agents IA ?
• ☐ Une procédure d’arrêt d’urgence (kill switch) est-elle prévue ?

🔐 2️⃣ Sécurité & contrôle des accès

• ☐ Les agents utilisent-ils une authentification forte (SSO / rotation token) ?
• ☐ Les secrets sont-ils stockés dans un vault sécurisé ?
• ☐ Les permissions sont-elles isolées par environnement (dev / prod) ?
• ☐ Les appels tools sont-ils journalisés ?
• ☐ Une revue régulière des droits est-elle planifiée ?

🛡️ 3️⃣ Surface d’attaque & architecture

• ☐ Un serveur MCP expose-t-il un port réseau ?
• ☐ Ce port est-il restreint (firewall / segmentation) ?
• ☐ Le parsing JSON des tools est-il validé et filtré ?
• ☐ Des tests d’injection (prompt injection / tool abuse) ont-ils été réalisés ?
• ☐ Un pentest inclut-il les agents IA ?

📊 4️⃣ Audit & supervision

• ☐ Les actions des agents sont-elles corrélées dans le SIEM ?
• ☐ Les logs sont-ils exploitables juridiquement ?
• ☐ Un monitoring comportemental est-il en place ?
• ☐ Une alerte est-elle générée en cas d’action sensible automatisée ?
• ☐ La traçabilité distingue-t-elle action humaine vs action IA ?

💰 5️⃣ Charge opérationnelle & ROI

• ☐ Qui maintient le serveur MCP ?
• ☐ Qui maintient les spécifications des tools ?
• ☐ Qui gère les mises à jour de sécurité ?
• ☐ Le coût de maintenance est-il estimé ?
• ☐ Le gain métier est-il mesurable ?

⚖️ 6️⃣ Décision stratégique

• ☐ MCP apporte-t-il une capacité réellement impossible via CLI ?
• ☐ La complexité ajoutée est-elle justifiée ?
• ☐ L’organisation est-elle mature pour encadrer des agents autonomes ?
• ☐ Un plan de rollback existe-t-il ?
• ☐ La décision est-elle documentée (et assumée) ?

🎯 Lecture rapide RSSI

Si vous cochez moins de 70 % des cases :

👉 Le problème n’est pas MCP.
👉 Le problème est la maturité de gouvernance IA.

Si vous cochez 100 % :

👉 MCP peut devenir un levier stratégique.
👉 Mais sous contrôle.

🧠 Message final aux DSI / RSSI

Un agent IA n’est pas un assistant magique.

C’est un compte technique avec un cerveau probabiliste.

Que vous choisissiez CLI ou MCP,
le risque n’est pas l’outil.

Le risque, c’est l’absence de cadre.

🧠 Ce que les DSI et RSSI doivent vraiment retenir

La vraie révolution n’est pas MCP.

La vraie révolution, ce sont les agents autonomes capables d’agir sur votre SI.

Qu’ils utilisent un CLI ou un protocole structuré,
ils restent :

• des comptes techniques,
• avec des privilèges,
• opérant à grande vitesse,
• dans des environnements critiques.

Et dans ce contexte :

• la gouvernance prime sur la hype,
• la traçabilité prime sur l’élégance,
• la maîtrise prime sur la nouveauté.

⚖️ La leçon stratégique

Le CLI n’est pas archaïque.

Il est :

• mature,
• universel,
• auditable,
• compris par les humains et par les modèles.

MCP n’est pas inutile.

Il est :

• structurant,
• prometteur,
• mais plus complexe,
• et donc plus exigeant en gouvernance.

La bonne décision ne sera jamais idéologique.

Elle sera contextuelle.

💬 Et si on arrêtait d’opposer ?

Peut-être que la vraie maturité consiste à :

• garder le CLI là où il est pertinent,
• encapsuler intelligemment quand nécessaire,
• introduire MCP là où la complexité est réellement justifiée,
• ne jamais sacrifier la visibilité opérationnelle.

Parce qu’au final :

Un système que vous ne comprenez plus
est un système que vous ne maîtrisez plus.

🎯 Le mot de la fin

Le terminal n’est pas mort.

Il n’a juste jamais eu besoin de se réinventer pour survivre.

Et dans un monde où l’IA veut tout orchestrer,
il reste cette vérité simple :

La puissance n’a pas besoin d’être bavarde.

Elle a juste besoin de fonctionner.

A lire aussi :  Les Agents IA vont-ils tuer le SaaS ? Spoiler : pas comme vous l’imaginez.

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com