MCP vs Agent Skills : lequel choisir pour vos intégrations ?

Je préconise une solution hybride : MCP pour la plomberie infra et Agent Skills pour les tâches comportementales et ponctuelles. Cet article compare architecture, invocation, runtime et cas d’usage, puis propose une matrice pratique pour choisir ou combiner les deux.

MCP résout-il le problème N×M et à quoi servent les Skills ?

MCP résout le problème N×M en fournissant un pont standardisé entre agents et backends ; les Agent Skills sont des playbooks locaux déclenchés à la demande pour gérer le comportement et les tâches ponctuelles.

MCP (Managed Connector Protocol) est un protocole client‑serveur qui normalise la façon dont un agent contacte des systèmes externes. L’expression N×M signifie N agents × M systèmes externes. Sans pont standardisé, chaque couple agent/backend nécessite un adaptateur dédié, ce qui crée N×M intégrations distinctes et multiplie la dette technique.

Agent Skills désigne un dossier SKILL.md accompagné de scripts et de templates embarqués dans l’agent. La philosophie est la légèreté : des playbooks réutilisables, faciles à modifier et à exécuter localement pour des tâches ponctuelles ou spécifiques.

Exemple chiffré et imagé :

• Scénario simple : 5 agents et 8 backends donnent 5×8 = 40 intégrations si on développe chaque connexion séparément.
• Avec MCP : on implémente 5 adaptateurs clients + 8 adaptateurs backends = 13 composants, soit N+M connexions.
• Avec Skills : chaque agent conserve ses 8 playbooks locaux → 5×8 = 40 playbooks à maintenir, mais déploiement très rapide localement.

Voici les avantages et inconvénients comparés :

• MCP — Avantage : Centralisation de la gouvernance et réduction du nombre d’adaptateurs. Inconvénient : Point central pouvant devenir un goulet d’étranglement et nécessité d’une versionning stricte.
• Skills — Avantage : Rapidité de déploiement et isolation par agent. Inconvénient : Risque de duplication, migration et scalabilité limitées pour de grands parcs.
• Maintenance et scalabilité : MCP facilite les mises à jour globales, Skills facilite les corrections locales rapides.

Mini‑guide décisionnel en 4 points :

• Si les intégrations sont nombreuses et stables, privilégier MCP pour réduire la complexité.
• Si les tâches changent fréquemment et nécessitent des itérations rapides, préférer Skills pour l’agilité.
• Si l’isolation et la sécurité sont critiques, utiliser Skills ou un hybride pour compartimenter les risques.
• Si vous avez des contraintes opérationnelles mixtes, adopter une approche hybride : MCP pour le socle, Skills pour les exceptions.

Cas d’usage	Points forts	Limites	Recommandation
Intégrations nombreuses et stables	Réduction des adaptateurs, gouvernance centralisée	Complexité initiale, dépendance au pont	MCP
Tâches locales fréquentes et changeantes	Déploiement rapide, isolation	Duplication, maintenance dispersée	Skills
Haute criticité et isolation	Contrôle granulaire par agent	Scalabilité limitée	Skills ou Hybride
Environnement mixte	Best of both : central pour stable, local pour exceptions	Nécessite orchestration et politiques claires	Hybride

Quelle architecture pour MCP et pour les Skills ?

MCP s’exécute comme un service indépendant (process/containeur) avec runtime dédié ; les Skills vivent dans le filesystem local sous forme de dossiers versionnables.

MCP est conçu comme un backend autonome. Il peut être écrit en Python, Go ou Rust selon les besoins de performance et d’écosystème. Le point d’interface recommandé est une API JSON‑RPC typée : JSON‑RPC est un protocole d’appel de procédures distantes (RPC) qui transporte des objets JSON. Le typage implique des schémas JSON (ex. JSON Schema) pour définir les inputs/outputs et valider les messages. Les points d’extension sont gérés par des adapters modulaires (par exemple GitHub pour SCM, Postgres pour stockage relationnel, Slack pour messaging, Stripe pour paiements). Le déploiement se fait en conteneurs, orchestrés par Kubernetes ou docker‑compose pour les environnements plus simples.

Un Skill est organisé sur disque de façon simple et portable. Structure recommandée : fichier SKILL.md pour la documentation, dossier scripts/ pour les actions exécutable, examples/ pour cas d’usage, templates/ pour assets réutilisables et éventuellement un manifest.json pour métadonnées (nom, version, dépendances, permissions). Le versionnement se fait naturellement via git, ce qui facilite la revue, les branches et les rollbacks. La portabilité tient au fait qu’un Skill est un ensemble de fichiers statiques/exécutables et dépendances listées dans son manifest.

Exemple d’arborescence d’un repo Skill :

my-skill/
  SKILL.md
  manifest.json
  scripts/
    run.sh
    handler.py
  templates/
    email.html
  examples/
    example-request.json
  tests/
    test_handler.py

Schéma d’API MCP (exemples de méthodes) : listSkills(), installSkill(params), executeSkill(params), healthCheck(). Schéma d’input/output court et typé :

{
  "jsonrpc": "2.0",
  "method": "executeSkill",
  "params": {
    "skill_id": "invoice-generator",
    "version": "1.2.0",
    "input": {"customer_id": 42, "items": [{"sku":"A1","qty":2}]}
  },
  "id": 1
}

{
  "jsonrpc": "2.0",
  "result": {"status":"ok","invoice_id":12345},
  "id": 1
}

Sur le plan opérationnel, MCP exige CI/CD complet, tests unitaires et d’intégration, stratégies de rollback et monitoring applicatif (logs, traces, métriques). Les Skills bénéficient surtout de tests d’acceptance, de linting de code et de checks de sécurité/permissions dans le manifest avant déploiement.

Aspect	MCP	Skills
Maintenance	Maintenance continue d’un service central et de ses adapters	Maintenance légère par Skill, isolée et ciblée
Versioning	Versionnement du service + déploiements coordonnés	Git friendly, versions par dossier/manifest
Monitoring	Logs, métriques, traces centralisées	Monitoring minimal ; focus sur erreurs et performances locales
Temps de mise en production	Plus long (CI/CD, review, déploiement conteneur)	Rapide (push git, review légère, activation)

Comment invoquer MCP et comment fonctionnent les Skills ?

MCP s’invoque via appels JSON‑RPC typés permettant chaînage et validation ; les Skills s’exécutent par scripts shell/commande déclenchés localement.

Le format JSON‑RPC standard contient au minimum les champs jsonrpc, id, method et params. Id permet d’associer la réponse, method désigne l’opération, params transporte les paramètres structurés.

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "github.createIssue",
  "params": {
    "owner": "acme",
    "repo": "prod",
    "title": "Bug critical",
    "body": "Détails du bug..."
  }
}

{
  "jsonrpc": "2.0",
  "id": 43,
  "method": "sql.execute",
  "params": {
    "connection": "postgres://user:pass@db:5432/app",
    "query": "INSERT INTO events(type,data) VALUES($1,$2)",
    "values": ["webhook_received", {"raw": "..."}]
  }
}

Exemple de fichier SKILL.md et script Python associé. Le fichier décrit le skill, son trigger et des exemples d’inputs.

TITLE: Notify Slack
DESCRIPTION: Envoie un message sur un canal Slack avec le payload.
TRIGGER: manual|http
INPUT_EXAMPLES:
- {"channel":"#ops","text":"Déploiement terminé"}

#!/usr/bin/env python3
# skill_notify.py - lit JSON sur stdin et envoie sur Slack (démonstration)
import sys, json, subprocess
payload = json.load(sys.stdin)  # {"channel": "...", "text": "..."}
channel = payload.get("channel")
text = payload.get("text", "")
# Exemple simple: appel de curl (remplacer WEBHOOK_URL)
subprocess.run(["curl","-X","POST","-H","Content-type: application/json",
                "--data", json.dumps({"text": f"{text}"}), "https://hooks.slack.com/services/WEBHOOK_URL"])
print(json.dumps({"ok": True}))

Châînage côté MCP signifie qu’une même méthode peut orchestrer plusieurs adaptateurs typés (ex. http, sql, notification).

Scénario concret : réception d’un webhook → validation du schema JSON → écriture en base (adapter SQL) → envoi d’une notification Slack (adapter webhook).

La validation s’effectue idéalement via JSON Schema côté MCP pour rejeter tôt les requests (ex. types, champs obligatoires).

Les retours MCP sont structurés (ex. {jsonrpc, id, result: {status, data}, error}) facilitant le retry et le monitoring.

Les Skills locaux restent souvent ad hoc : exit codes, logs textuels et absence de schéma rendent la gestion d’erreur plus fragile et nécessitent wrappers pour fiabiliser.

Exemple d’invocation	{« method »: »github.createIssue »}
Latence typique attendue	50–300 ms pour MCP interne ; 10–2000 ms pour Skills locaux selon I/O
Complexité d’implémentation	Moyenne à élevée pour MCP (schémas, adaptateurs) ; faible pour Skill simple
Points de vigilance sécurité	Valider et signer les payloads, secrets hors code, gestion des permissions par méthode

Quel runtime privilégier pour MCP ou pour les Skills ?

MCP tourne idéalement en conteneurs isolés pour contrôle et sécurité ; Skills s’exécutent dans l’environnement de l’agent avec accès direct aux outils locaux.

Les conteneurs offrent une isolation processuelle et réseau qui réduit la surface d’attaque et permet de séparer les permissions entre services.

• Isolation des permissions : Les conteneurs limitent les capacités système (capabilities) et peuvent fonctionner avec un utilisateur non-root pour éviter l’escalade.
• Limitation réseau : Les policies réseau (CNI, firewall) permettent d’empêcher les connexions sortantes non autorisées.
• Gestion des secrets : Les conteneurs consultent un secrets manager plutôt que d’exposer des credentials dans l’image.

# Exemple simple docker run pour un service MCP
docker run -d --name mcp-service \
  --rm \
  --network none \
  --read-only \
  --cap-drop ALL \
  -e CONFIG=/etc/mcp/config.yml \
  -v /etc/mcp:/etc/mcp:ro \
  myorg/mcp:latest

Les Skills exécutés dans l’environnement partagé présentent des risques élevés : accès direct aux fichiers locaux, lecture des variables d’environnement et possibilité d’escalade si un Skill est compromis.

• Risques concrets : Exfiltration de secrets, altération de binaires locaux, exécution de commandes shell non prévues.
• Bonnes pratiques : Appliquer le principe de moindre privilège, sandboxer (p.ex. gVisor, Firecracker) si possible, valider/sanitiser tous les inputs et auditer les scripts régulièrement.

Pour le stockage des credentials, privilégier un secrets manager pour MCP : HashiCorp Vault (gestion centralisée, rotation), KMS cloud (Key Management Service) ou Kubernetes Secrets chiffrés en transit et au repos.

Pour les Skills, limiter l’exposition : stocker les credentials chiffrés (gpg/age), injecter des variables d’environnement temporaires au runtime et utiliser des mécanismes d’expiration et rotation.

• Opérationnel : Mettre en place monitoring et logging structuré (JSON, trace IDs) pour MCP.
• Qualité : Auditer et reviewer les Skills, versionner les scripts, et tester en environnement prod-sim avant déploiement.

Critère	MCP (conteneur)	Skills (agent)
Isolation	Élevée	Faible
Sécurité	Contrôlable via policies et secrets manager	Dépend du host et des pratiques
Performance	Overhead léger lié au conteneur	Accès natif, plus rapide
Coût d’exploitation	Plus élevé (orchestration, secrets)	Moindre mais risque technique plus grand

Quand utiliser MCP et quand choisir des Skills ?

Pour des intégrations, il faut choisir l’outil selon la fréquence, la criticité et l’isolement. Utilisez MCP pour opérations à haute fréquence et infra critique ; utilisez Skills pour tâches légères, guides comportementaux et exécutions ad hoc.

Cas d’usage typiques

• MCP (Management/Model Control Plane) : APIs 24/7, intégrations base de données, systèmes de paiement, backends critiques, routage d’événements et authentification centralisée.
• Skills (agents/modèles spécialisés) : extraction PDF ponctuelle, templates CLI, recettes opérationnelles, guides de brand voice, automatisations ad hoc et prototypage rapide.

Critères décisionnels mesurables

• Fréquence d’appel : Mesurer en opérations/jour (ops/jour). Règle pratique : >1 000 ops/jour → préférence MCP.
• Criticité : SLA attendu (Service Level Agreement). Si SLA ≥ 99,9% ou impact financier/ légal, privilégier MCP.
• Besoins d’isolation : Données sensibles (PII = données personnelles, PCI = données de paiement) → MCP pour isolation et conformité.
• Latence tolérée : Si latence cible
• Équipe et compétence : Présence d’une équipe SRE/DevOps → MCP viable ; équipe produit seule → Skills pour itération rapide.

Critère	Indicateur mesurable	Recommandation
Fréquence	> 1 000 ops/jour	MCP
Criticité	SLA ≥ 99,9% / Impact financier/légal	MCP
Sensibilité des données	PII/PCI impliqués	MCP
Latence		MCP
Itération & prototypage	Besoin de changements fréquents rapides	Skills
Mix	Charge modérée + comportements variables	Hybride

Exemples concrets

• Migration d’un webhook GitHub vers MCP : Choisir MCP si le webhook déclenche des déploiements, affecte la production et demande authentification centralisée.
• Automatisation ponctuelle de nettoyage de fichiers : Créer une Skill pour script rapide, exécution manuelle ou déclencheur faible fréquence.

Bonnes pratiques pour combiner

• Utiliser MCP comme système nerveux : Sécurité, routage, authentification et monitoring centralisés.
• Utiliser Skills comme playbooks : Comportements, templates et exécutions rapides facilement remplaçables.
• Mettre des garde-fous : Limiter les temps d’exécution des Skills, appliquer quotas via MCP et journaliser toutes les actions pour audit.

Prêt à combiner MCP et Agent Skills pour optimiser vos intégrations ?

MCP et Agent Skills servent des objectifs complémentaires : MCP centralise et industrialise les intégrations (réduction du problème N×M, schémas typés, isolation via conteneurs), tandis que les Skills offrent rapidité, flexibilité et comportement local (SKILL.md, scripts, templates). En pratique, je recommande de déployer MCP pour la plomberie infra critique (APIs, DB, paiements) et de garder des Skills pour les tâches ponctuelles ou comportementales. Ce design hybride accélère les développements, réduit les risques et améliore la maintenance : bénéfice direct pour votre projet = moins de dette technique et plus d’agilité opérationnelle.

FAQ

• Qu’est-ce que MCP et à quoi sert-il ?
  MCP est un protocole client‑serveur et un service intermédiaire qui standardise les intégrations entre agents et systèmes externes, réduisant le problème N×M en centralisant adaptateurs, authentification et routage via appels typés (ex. JSON‑RPC).
• Que sont les Agent Skills ?
  Les Agent Skills sont des playbooks locaux (SKILL.md, scripts, examples, templates) déclenchés à la demande. Ils définissent le comportement de l’agent pour des tâches légères, rapides et spécifiques.
• Quelle est la différence clé entre MCP et les Skills ?
  MCP gère l’intégration système et l’orchestration typée (sécurité, scalabilité, chaînage), tandis que les Skills définissent l’exécution et le comportement local de l’agent via scripts flexibles.
• Quand devrais-je utiliser MCP plutôt qu’un Skill ?
  Privilégiez MCP pour les opérations à haute fréquence, critiques et nécessitant isolation/secrets (APIs, DB, paiements). Utilisez Skills pour tâches ponctuelles, templates, extraction de documents ou workflows rapides.
• Puis-je combiner MCP et les Agent Skills ?
  Oui. Le meilleur design est hybride : MCP comme système nerveux pour la plomberie infra et les Skills comme playbooks comportementaux. MCP expose des points d’appel sécurisés que les Skills peuvent consommer ou déclencher selon le besoin.

 

 

A propos de l’auteur

Franck Scandolera — expert & formateur en Tracking avancé server-side, Analytics Engineering, Automatisation No/Low Code (n8n), intégration de l’IA en entreprise et SEO/GEO. Responsable de l’agence webAnalyste et de l’organisme de formation Formations Analytics. Références : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider votre entreprise => contactez moi.