Pourquoi les CLI surpassent MCP pour les agents IA — Et comment créer votre propre arsenal CLI

Votre agent ne peut pas explorer un CLI par essai-erreur comme le ferait un humain. Il doit savoir à l'avance quelles commandes existent, quels flags sont disponibles, à quoi ressemble la sortie. C'est pourquoi chaque CLI de l'écosystème OpenClaw est livré avec un SKILL.md — une doc structurée qui fait office de manuel d'instruction pour l'agent.

Le pattern c'est : binaire CLI + doc de skill = capacité autonome.

Le CLI fait le boulot. La doc de skill apprend à l'agent comment l'utiliser. Ensemble, ils forment une unité autonome que n'importe quel agent peut récupérer et lancer. Steinberger appelle ça des "skills". Le concept est le même que vous appeliez ça un skill, un outil, ou "ce script bash que Dave a écrit mardi dernier."

Et vous n'avez pas besoin d'OpenClaw pour utiliser ce pattern. Vous le faites déjà, en fait — quand vous écrivez un CLAUDE.md qui documente vos CLI, c'est une doc de skill. La différence c'est que Steinberger a standardisé le format et construit une couche de distribution par-dessus : ClawHub, avec 3 000+ skills que vous pouvez parcourir et installer.

Le truc intéressant ? Vous pouvez piquer n'importe lequel de ces skills pour votre propre setup. Chaque skill sur ClawHub est juste un CLI que vous pouvez installer indépendamment (brew install steipete/tap/goplaces, npm install -g @steipete/oracle, etc.) et un SKILL.md que vous pouvez lire. Vous n'avez pas besoin du runtime OpenClaw. Installez le binaire, collez les commandes pertinentes dans votre CLAUDE.md, et Claude Code peut l'utiliser immédiatement.

# Dans votre CLAUDE.md — piqué direct de ClawHub

## goplaces (CLI Google Maps)
- `goplaces search "coffee near me" --open-now --json` - trouver des lieux
- `goplaces search "pizza" --lat 40.8 --lng -73.9 --radius-m 3000 --json` - recherche biaisée par localisation
- `goplaces details <place_id> --json` - détails complets du lieu avec avis
- `goplaces resolve "Soho, London" --json` - géocoder un nom de lieu
Requis: variable d'env GOOGLE_PLACES_API_KEY

## summarize (CLI de résumé Vidéo/Podcast/Web)
- `summarize --url "https://youtube.com/watch?v=xxx" --json` - résumer une vidéo
- `summarize --url "https://some-blog.com/post" --json` - résumer une page web
- `summarize --url "https://podcast.fm/ep42" --cli claude --json` - choisir quel modèle utiliser

Voilà goplaces et summarize — deux des propres outils de Steinberger — qui tournent dans Claude Code avec zéro dépendance OpenClaw. Juste un binaire et une doc.

C'est pourquoi l'approche CLI scale d'une façon que MCP ne fera jamais. Un serveur MCP est un processus qui tourne et qui a besoin de configuration, d'un handshake de protocole, et d'espace dans la fenêtre de contexte. Un skill CLI est un binaire statique et un fichier texte. L'un nécessite de l'infrastructure. L'autre nécessite un brew install et 10 lignes de markdown.

Brancher les CLI dans OpenClaw

Si vous faites déjà tourner OpenClaw, transformer un CLI en skill d'agent prend environ 5 minutes.

Le système fonctionne comme ça : chaque skill a un fichier SKILL.md qui décrit ce que fait le CLI, comment l'installer, et quelles commandes sont disponibles. L'agent lit ce fichier et sait comment utiliser l'outil.

---
name: check-mrr
description: Vérifier les métriques SaaS (MRR, inscriptions, churn) depuis Supabase.
metadata:
openclaw:
requires:
env:
- SUPABASE_URL
- SUPABASE_KEY
bins:
- node
primaryEnv: SUPABASE_URL
---

# check-mrr
Récupérer les métriques SaaS actuelles depuis Supabase de production.
## Install
npm install -g @yourhandle/check-mrr
## Commandes
- `check-mrr --json` - métriques complètes en JSON
- `check-mrr --period week` - métriques pour la semaine actuelle
- `check-mrr --period month` - aperçu mensuel
## Format de sortie (--json)
{
"mrr": 1247,
"active_subscriptions": 89,
"signups_today": 3,
"timestamp": "2026-02-17T10:30:00Z"
}

Publiez-le sur ClawHub (clawhub publish) et n'importe qui qui fait tourner OpenClaw peut installer votre skill. Mais la vraie valeur est locale : combinez-le avec un cron job, et votre agent vérifie vos métriques chaque matin et vous ping sur WhatsApp si quelque chose cloche.

// Dans openclaw.json
{
"cron": [
{
"schedule": "0 8 * * *",
"message": "Lance check-mrr --json. Si signups_today est 0 ou que le mrr a chuté de plus de 5% par rapport à hier, alerte-moi sur WhatsApp avec un résumé. Sinon log juste ça.",
"channel": "whatsapp"
}
]
}

C'est la boucle complète. Cron déclenche l'agent, l'agent lit le skill, appelle le CLI, interprète le résultat, décide quoi faire. Pas de dashboard à vérifier. Pas de fatigue de notification d'alertes dont vous n'avez pas besoin. L'agent utilise son jugement — même pattern que Steinberger fait tourner sur tout son setup.

Le répertoire ClawHub a déjà 3 000+ skills tiers, la plupart suivant exactement cette structure. goplaces pour la recherche de lieux, himalaya pour l'email via IMAP, bird (😭) pour X/Twitter, sonoscli pour le contrôle d'enceintes - toute l'armée. Vous les installez, l'agent les apprend, terminé.

Construire Votre Propre Agent (Le Pattern OpenClaw, Sans OpenClaw)

OK alors et si vous ne voulez pas faire tourner OpenClaw ?

Peut-être que vous voulez quelque chose de plus léger, plus custom, ou vous aimez juste construire des trucs from scratch. (Je comprends. J'auto-héberge tout. C'est une maladie.)

Le pattern de base est mort simple : un script qui appelle l'API Anthropic avec tool_use, mappe les appels d'outils aux exécutions CLI, et boucle jusqu'à ce que l'agent ait fini.

import Anthropic from '@anthropic-ai/sdk'
import { execSync } from 'child_process'

const client = new Anthropic()
// Vos CLI, déclarés comme outils
const tools = [
{
name: "check_mrr",
description: "Récupérer les métriques SaaS actuelles (MRR, abonnements actifs, inscriptions aujourd'hui)",
input_schema: {
type: "object",
properties: {
period: { type: "string", enum: ["today", "week", "month"], default: "today" }
}
}
},
{
name: "deploy_production",
description: "Déployer le dernier commit sur Vercel production. Retourne l'URL de déploiement.",
input_schema: {
type: "object",
properties: {}
}
},
{
name: "send_slack",
description: "Envoyer un message à un canal Slack",
input_schema: {
type: "object",
properties: {
channel: { type: "string" },
message: { type: "string" }
},
required: ["channel", "message"]
}
}
]
// Mapper les noms d'outils aux commandes CLI
function executeTool(name, input) {
const commands = {
check_mrr: `node ./scripts/check-mrr.js --json --period ${input.period || 'today'}`,
deploy_production: `vercel deploy --prod --yes 2>&1`,
send_slack: `curl -X POST -H 'Authorization: Bearer ${process.env.SLACK_TOKEN}' \
-H 'Content-Type: application/json' \
-d '{"channel":"${input.channel}","text":"${input.message}"}' \
https://slack.com/api/chat.postMessage\`
}

try {
const result = execSync(commands[name], { encoding: 'utf-8', timeout: 30000 })
return result
} catch (err) {
return JSON.stringify({ error: err.message, exitCode: err.status })
}
}
// La boucle d'agent
async function runAgent(task) {
let messages = [{ role: "user", content: task }]

while (true) {
const response = await client.messages.create({
model: "claude-sonnet-4-5-20250514",
max_tokens: 4096,
system: "Tu es un agent autonome. Utilise les outils disponibles pour accomplir les tâches. Sois concis dans ton raisonnement.",
tools,
messages
})
// Si Claude a fini de parler, on a fini
if (response.stop_reason === "end_turn") {
const text = response.content.find(b => b.type === 'text')
return text?.text || 'Terminé.'
}
// Si Claude veut utiliser des outils, les exécuter
const toolBlocks = response.content.filter(b => b.type === 'tool_use')
if (toolBlocks.length === 0) break
messages.push({ role: "assistant", content: response.content })
const toolResults = toolBlocks.map(block => ({
type: "tool_result",
tool_use_id: block.id,
content: executeTool(block.name, block.input)
}))
messages.push({ role: "user", content: toolResults })
}
}
// Le lancer
const result = await runAgent(
"Vérifie notre MRR. Si c'est au-dessus de 1000$, déploie en production et notifie #team sur Slack avec les métriques. Si c'est en-dessous, envoie juste un warning sur Slack."
)
console.log(result)

~80 lignes. Voilà votre mini-OpenClaw. L'agent décide quels outils appeler et dans quel ordre basé sur la tâche que vous lui donnez. Ajouter un nouveau CLI prend 30 secondes — ajoutez une définition d'outil, ajoutez une ligne dans la map commands, terminé.

Pour la partie autonome, wrappez-le dans un cron :

# crontab -e
0 8 * * * cd /home/deploy/my-agent && node agent.js "Check matinal: métriques, déploie si stable, notifie l'équipe"
0 20 * * * cd /home/deploy/my-agent && node agent.js "Fin de journée: résume les inscriptions, signale toute anomalie sur Slack"

Vous pouvez aussi lancer ça comme un service systemd avec un timer, ou le balancer dans un container Docker sur votre serveur. Même résultat, différentes saveurs de devops.

GitHub Actions est une autre option si vous voulez zéro infrastructure. Un workflow programmé qui installe vos CLI dans le runner et appelle l'API Anthropic :

name: Daily Agent Run
on:
schedule:
- cron: '0 8 * * *'

jobs:
agent:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm install @anthropic-ai/sdk
- run: node agent.js "Routine matinale"
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
SUPABASE_URL: ${{ secrets.SUPABASE_URL }}
SUPABASE_KEY: ${{ secrets.SUPABASE_KEY }}

Gratuit pour les repos publics, 2 000 minutes/mois sur les privés. Pas mal pour un agent quotidien qui tourne en 30 secondes.

Et n8n ?

Vous pouvez techniquement orchestrer des CLI via n8n en utilisant le nœud Execute Command ou en les wrappant dans des containers FastAPI.

Mais honnêtement, c'est plus de friction que l'approche script pour ce cas d'usage. n8n brille quand vous avez besoin de workflows visuels avec 15 étapes et des branchements complexes — pas pour "appeler un CLI et laisser le LLM décider."

Si vous voulez creuser plus sur l'exécution de code custom dans n8n, j'ai écrit un guide complet sur appeler des scripts Python depuis n8n qui couvre le setup Docker + FastAPI.

Ce Que Ça Signifie Pour Vous

La tendance est claire.

Les builders les plus productifs dans l'espace des agents IA ne stackent pas des serveurs MCP et ne configurent pas d'adaptateurs de protocole. Ils écrivent des CLI petits et tranchants et laissent leurs agents les appeler.

Peter Steinberger l'a prouvé à l'échelle avec OpenClaw. OpenAI l'a validé avec une offre d'emploi. Et vous pouvez commencer aujourd'hui avec un fichier CLAUDE.md et un script Node de 20 lignes.

La stack n'a pas d'importance. OpenClaw, Claude Code, Codex, une boucle d'agent custom — le pattern est le même. Wrappez vos outils dans des CLI. Documentez-les pour votre agent. Laissez le LLM gérer l'orchestration.

Votre terminal était une interface IA depuis le début. La plupart des gens ne s'en sont juste pas encore rendu compte.

Si ça vous a parlé, suivez-moi pour plus de contenu d'automatisation IA testé au combat. La suite : je construis un agent autonome complet qui gère mon SaaS — déploie, monitore, et gère les tickets de support — entièrement via des CLI. Pas de dashboard. Pas de GUI. Juste un homard et un cron job. 🦞

Dans le monde des agents IA, les CLI sont le couteau suisse que chaque développeur devrait avoir. Découvrez comment construire votre propre arsenal de lignes de commande puissantes.

→ Rejoindre la newsletter