MCP vs Agent Skills : quel rôle dans mon architecture ?

MCP et Agent Skills se complètent : MCP gère la plomberie et les intégrations à grande échelle, Skills pilotent le comportement et les actions locales. Je détaille quand utiliser l’un, l’autre, et surtout comment les combiner pour scalabilité, sécurité et agilité.

Comment résoudre le problème N×M d’intégration

MCP centralise et standardise les intégrations N×M pour éviter la multiplication des connexions point à point, tandis que les Agent Skills ajoutent des capacités déclenchées à la demande.

Le problème N×M signifie que N agents différents doivent parler à M systèmes externes, ce qui génère N×M connecteurs distincts et donc complexité et dette technique. Avec 10 agents et 10 backends, on obtient 100 intégrations à maintenir. Centraliser via un protocole ou un service réduit ce quadrillage en un schéma N+M ou même N→M via une passerelle unique.

MCP agit comme une passerelle typée basée sur JSON-RPC. JSON-RPC est un protocole léger d’appel de procédures à distance utilisant JSON. La typage impose des schémas pour les params et réponses, ce qui améliore la robustesse (validation, erreurs claires) et permet de chaîner les appels (appel A renvoie un identifiant utilisé par l’appel B). La passerelle gère l’authentification, le throttling, la normalisation des payloads et les adaptateurs pour GitHub, Slack, Postgres, Stripe, etc.

Les Agent Skills complètent le modèle en fournissant des playbooks locaux — petits modules déclenchables pour des tâches spécifiques. Playbook veut dire ici une séquence réutilisable d’actions (exemples : extraction PDF, génération à partir de templates, recettes CLI). Les Skills gardent la logique métier proche de l’agent et évitent de pousser tout dans la couche d’intégration.

Exemple JSON-RPC (requête + réponse) :

{
  "jsonrpc": "2.0",
  "method": "github.createIssue",
  "params": {
    "repo": "org/project",         // string: repository full name
    "title": "Bug: login fail",    // string
    "body": "Steps to reproduce..." // string
  },
  "id": "req-42"
}
---
{
  "jsonrpc": "2.0",
  "result": {
    "issue_number": 123,           // integer
    "url": "https://github.com/org/project/issues/123"
  },
  "id": "req-42"
}

Exemple d’utilisation concret : L’assistant envoie la requête MCP pour créer une issue GitHub. MCP valide, gère l’auth et le format, puis renvoie le résultat. L’agent reçoit la réponse, stocke le lien et déclenche un Skill local pour notifier l’utilisateur via Slack ou via une synthèse vocale.

Sans MCP (N×M)	Cas d’usage: intégrations directes point à point. Avantages: latence minimale, contrôle total.	Limitations: maintenance O(N×M), duplication d’authentification, tests lourds.
Avec MCP	Cas d’usage: passerelle typée pour tous les backends. Avantages: réduction des connecteurs, typage, sécurité centralisée, chaînage d’appels.	Limitations: point central à dimensionner, latence ajoutée, dépendance au protocole.
Agent Skills	Cas d’usage: comportements locaux déclenchés (PDF, templates, CLI). Avantages: flexibilité, logique locale, testabilité.	Limitations: duplication possible si mal gouverné, pas conçu pour remplacer intégrations externes.

Quelle différence d’architecture entre service et filesystem

MCP est un service/processus backend isolé (service réseau, runtime dédié), tandis que les Agent Skills sont des dossiers locaux (SKILL.md, scripts/, examples/) faciles à modifier.

Un MCP comme service signifie un processus isolé qui peut être conteneurisé et exposer une API typée (par exemple HTTP/JSON ou gRPC). Un MCP gère authentification, logs et monitoring, et impose contraintes de sécurité et de scalabilité. Un MCP nécessite orchestration (Kubernetes ou équivalent), gestion des secrets et métriques (Prometheus, ELK).

Un Skill sur le filesystem est une unité locale composée d’un fichier descriptif et de scripts exécutables. Un Skill se modifie directement, s’exécute en local et facilite le prototypage. Exemple d’arborescence :

• skill-name/ contenant SKILL.md, scripts/run.py, examples/
• SKILL.md décrivant titre, description, inputs/outputs et exemples d’usage

Exemple minimal de SKILL.md :

title: Résumé texte
description: Résume un texte en sortie courte
inputs:
  - name: text
    type: string
outputs:
  - name: summary
    type: string
examples:
  - input: "Document long..."
    output: "Résumé court..."

Exemple de script d’invocation (Python) :

#!/usr/bin/env python3
import sys, json
data = json.load(sys.stdin)
text = data.get("text", "")
# Simple exemple de "résumé"
summary = text[:160] + ("…" if len(text)>160 else "")
print(json.dumps({"summary": summary}))

En termes de développement, les Skills permettent une itération très rapide (édition locale, test immédiat). En revanche, un MCP demande CI/CD strict, tests d’intégration, versioning API et déploiements automatisés. Les risques de régression en production sont plus élevés pour un MCP mal versionné.

Bonnes pratiques :

• Conventions de nommage: SKILL.md en racine, dossier scripts/ et examples/.
• Tests unitaires simples pour chaque script (pytest ou bash assertions).
• Documentation intégrée dans SKILL.md et exemples reproductibles.
• Versioning sémantique (SemVer) pour MCP et changelogs pour breaking changes.

Critère	Service (MCP)	Filesystem (Skill)
Isolation	Processus isolé, runtime dédié	Contexte local, partagé
Déploiement	Conteneurs, orchestrateur, CI/CD	Copier/commit, déployer fichier système
Itération	Plus lente (build/test/deploy)	Rapide (édition locale, test immédiat)
Maintenance	Monitoring, sécurité, versioning	Documentation légère, tests unitaires

Comment s’invoquent MCP et les Skills en pratique

MCP s’invoque via appels structurés (JSON-RPC/HTTP) avec typage et validation, alors que les Skills s’exécutent par des scripts locaux (bash, python) offrant flexibilité et rapidité.

Exemple complet JSON-RPC (requête HTTP)

POST /mcp/api HTTP/1.1
Host: mcp.example.com
Content-Type: application/json
Authorization: Bearer eyJ...

{
  "jsonrpc": "2.0",
  "method": "document.extractMetadata",
  "params": {
    "document_id": "doc-1234",
    "format": "pdf"
  },
  "id": "req-001"
}

Réponse attendue

{
  "jsonrpc": "2.0",
  "result": {
    "metadata": { "title": "Rapport", "pages": 12 },
    "token": "tok-9a8b"
  },
  "id": "req-001"
}

Les champs importants sont method (nom de l’opération), params (les paramètres typés), id (correspondance requête/réponse), result (résultat) et error (objet en cas d’échec avec code et message).

Chaining via MCP

Un appel A peut retourner un token que l’appel B consomme pour poursuivre un workflow sécurisé. Le typage évite erreurs de format en forçant par contrat (ex: schema JSON) que token soit string et metadata un objet.

Structure SKILL.md et invocation

# SKILL.md (extrait)
name: pdf_extract
version: 0.1
inputs:
  - file: path
outputs:
  - out: json

./skills/pdf_extract/run.sh --file doc.pdf --out out.json

Exemple Python pour lancer un Skill et parser la sortie JSON

import subprocess, json
proc = subprocess.run(['./skills/pdf_extract/run.sh','--file','doc.pdf','--out','-'],
                      stdout=subprocess.PIPE, check=False)
if proc.returncode != 0:
    raise RuntimeError(f"Skill failed: {proc.returncode}")
result = json.loads(proc.stdout.decode())
print(result['metadata'])

Gestion des erreurs

MCP renvoie réponses typées et erreurs JSON-RPC standard avec code/message/data. Les scripts de Skills doivent utiliser codes de sortie POSIX (0=ok) et écrire un JSON structuré sur stdout pour le parsing, ou un objet {error:{code,msg}} si échec.

Conventions d’interface

MCP peut fournir un hook ou un payload signé (HMAC) que le Skill vérifie avant exécution, ou un token temporaire passé en paramètre pour authentifier l’appel.

Invocation	JSON-RPC/HTTP pour MCP, exécution locale pour Skills
Validation	Typage/JSON Schema côté MCP, conventions de sortie JSON côté Skills
Flexibilité	Faible latence et rapide pour Skills, forte gouvernance pour MCP
Temps de développement	Plus long pour MCP (contrats), plus court pour Skills (scripts)

Quels compromis runtime et sécurité faut-il gérer

MCP tournant typiquement en conteneurs isolés offre meilleure séparation des secrets et sécurité, tandis que les Skills exécutés localement donnent accès direct aux outils mais exposent davantage l’environnement.

Pour clarifier les implications, voici les points clés à considérer avant d’architecturer le runtime.

• Isolation (MCP en conteneurs) : Les conteneurs fournissent un runtime dédié qui limite l’accès au noyau et au système hôte, réduisant la surface d’attaque.
• Gestion des secrets : Stocker les secrets hors du conteneur (Vault, KMS) évite la fuite via images ou logs.
• Pare-feu et réseau : Appliquer des règles réseau pour isoler les flux entrants/sortants du MCP et utiliser des ACL pour les APIs.
• RBAC et audit : RBAC signifie Role-Based Access Control, contrôle d’accès basé sur les rôles; activer l’audit pour tracer qui a demandé quel secret et quand.
• Scalabilité : Les conteneurs facilitent l’auto-scaling et la mise à jour sans toucher l’environnement hôte.

Exécution locale des Skills : avantages et risques.

• Avantages : Accès natif aux outils (CLI, sockets), latence plus faible, simplicité d’intégration.
• Risques : Fuite de secrets si le Skill lit des fichiers sensi­bles; conflits de dépendances entre skills; élévation de privilèges possible.

Recommandations pratiques : utiliser des conteneurs pour le MCP, stocker les secrets dans un vault (ex : HashiCorp Vault) ou secret manager cloud, mettre en place rotation régulière des clés (30–90 jours selon criticité), et chiffrer en transit (TLS) et au repos (AES-256).

Exemple minimal de Dockerfile et règle réseau basique :

FROM python:3.11-slim
WORKDIR /app
COPY . /app
RUN adduser --disabled-password --gecos '' mcpuser && chown -R mcpuser /app
USER mcpuser
EXPOSE 8080
CMD ["gunicorn","app:app","-b","0.0.0.0:8080"]

# Exemple simple iptables pour n'autoriser que les sorties vers l'API de secrets
# iptables -A OUTPUT -d 10.0.0.5 -p tcp --dport 8200 -j ACCEPT
# iptables -A OUTPUT -p tcp --dport 8200 -j DROP

Bonnes pratiques pour les scripts de Skills : exécuter en user non-root, valider et sanitiser tous les inputs, limiter permissions filesystem, et sandboxer (gVisor, Firecracker) quand c’est possible.

Stratégies hybrides : Exécuter les Skills dans des sandboxes contrôlées ou via des workers isolés déclenchés par le MCP pour combiner sécurité et latence.

	MCP (Conteneur)	Skill (Local)	Hybride
Isolation	Forte	Faible	Moyenne (sandboxes)
Sécurité des secrets	Élevée (Vault/KMS)	Faible si non protégé	Élevée si brokerisée
Accès aux ressources locales	Limité	Direct	Contrôlé
Temps de réponse	Bon	Optimal	Variable

Comment concevoir une architecture hybride efficace

La meilleure approche combine MCP (Model Control Plane) pour la plomberie et les intégrations à haute fréquence, et les Skills pour le comportement, les templates et les actions rapides. MCP désigne la couche centrale qui expose API, gère routage, sécurité et accès aux backends. Skill désigne un composant exécutable (template, script, action) qui implémente un comportement métier local ou sandboxé.

Voici plusieurs patterns d’intégration, expliqués et quand les choisir.

• Pattern 1 : MCP expose des API que les agents appellent et qui déclenchent des Skills via webhooks/queues. Idéal pour centraliser la logique et supporter fort trafic.
• Pattern 2 : Skills appellent MCP pour accéder à backends sécurisés. Utile quand le Skill doit lire écrit des données sensibles et respecter des quotas.
• Pattern 3 : Orchestrateur léger (queue/worker) pour exécuter Skills dans des sandboxes. Recommandé pour isolation et scalabilité raisonnable.

Flux détaillé pour la feature « création de rapport ».

• Étape 1 : L’utilisateur demande la création du rapport via l’agent (chat/UI).
• Étape 2 : L’agent appelle MCP pour agréger données depuis plusieurs backends (API internes, DB).
• Étape 3 : MCP renvoie un payload structuré (JSON) à l’agent.
• Étape 4 : L’agent déclenche un Skill local pour formatter et exporter (PDF/CSV).
• Étape 5 : Le Skill renvoie le résultat à MCP qui le stocke et notifie l’utilisateur.

curl -X POST https://mcp.example.com/rpc \
 -H "Content-Type: application/json" \
 -d '{"jsonrpc":"2.0","method":"aggregateData","params":{"range":"30d","filters":{}},"id":1}'

#!/bin/bash
# Skill minimal: lit JSON stdin, écrit JSON stdout
input=$(cat)
# Ici on formate (exemple simplifié)
echo "{\"status\":\"ok\",\"report\":\"$(echo \"$input\" | jq -r '.data | @base64')\"}"

# Orchestration simple via Redis PUB/SUB (pseudo)
# Publish
redis-cli PUBLISH tasks "{\"type\":\"generate_report\",\"payload\":{...}}"
# Worker subscribe (bash)
redis-cli SUBSCRIBE tasks | while read line; do handle; done

Checklist d’implémentation.

• Typage des API : définir schémas et contrats (OpenAPI/JSON Schema).
• Gestion des erreurs : codes, retry, idempotence.
• Monitoring : traces, métriques, alerting.
• Tests E2E : simuler flux agent→MCP→Skill.
• Rollbacks : versioning et feature flags.
• Sécurité : gestion des secrets, scopes et ACL.
• Versionning des Skills : compatibilité ascendante vérifiée.

Pattern	Cas d’usage recommandé	Points de vigilance
API-centric (MCP→Skills)	Haute fréquence, centralisation des politiques	Latence réseau, scalabilité MCP
Skill-initiated (Skills→MCP)	Accès direct à backends sécurisés	Gestion des credentials, audit
Orchestrateur léger	Isolation, traitements asynchrones	Complexité op, surveillance des queues

On combine MCP pour la plomberie et Skills pour le comportement ?

MCP et Agent Skills ne sont pas concurrents mais complémentaires. MCP résout l’intégration à grande échelle (N×M) avec des API typées et un runtime isolé, tandis que les Skills offrent des playbooks locaux souples et rapidement modifiables. En combinant les deux vous obtenez scalabilité, sécurité et agilité : MCP assure la fiabilité et la gestion des secrets, les Skills optimisent le comportement et l’itération. Bénéfice concret : déploiement plus sûr et évolutif avec des temps de livraison réduits pour les fonctionnalités métiers.

FAQ

• Qu’est-ce que MCP et à quoi sert-il ?
  MCP est un protocole/service client‑serveur qui centralise les intégrations entre agents et systèmes externes. Il expose des API typées (ex : JSON‑RPC) pour gérer authentification, format de données et chaining d’appels, évitant la multiplication des connecteurs point‑à‑point.
• Qu’est‑ce qu’un Agent Skill ?
  Un Skill est un playbook léger stocké localement (dossier SKILL.md, scripts, exemples) exécuté à la demande par l’agent. Idéal pour tâches rapides, templates, extraction, ou actions personnalisées directement dans l’environnement de l’agent.
• Quand privilégier MCP plutôt que les Skills ?
  Privilégier MCP pour les intégrations à haute fréquence, le besoin d’isolation, le contrôle des secrets, le typage et la fiabilité entre agents et backends (GitHub, Postgres, Stripe, Slack).
• Quels sont les risques à exécuter trop de Skills localement ?
  Exécution locale expose l’environnement : risque de fuite de secrets, conflits de dépendances, et surface d’attaque accrue. Prévoir sandboxing, validation d’inputs et bonnes pratiques d’accès aux secrets.
• Faut‑il choisir entre MCP et Skills ou les combiner ?
  Il ne faut pas choisir l’un ou l’autre. L’architecture la plus efficace combine MCP pour la plomberie/infrastructure et les Skills pour le comportement/raisonnement : scalabilité, sécurité et agilité gagnées.

 

 

A propos de l’auteur

Franck Scandolera — expert & formateur en Tracking avancé server-side, Analytics Engineering, Automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. 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 les entreprises => contactez moi.