MCP ou Agent Skills : quelle solution pour vos agents ?

Privilégier une approche hybride : MCP pour l’infrastructure d’intégration et Skills pour le comportement et les tâches légères. Je détaille pourquoi, comment les architecturer et quand choisir l’un ou l’autre pour gagner en sécurité, maintenance et rapidité d’itération.

Comment résoudre l’explosion N×M d’intégrations ?

Le problème N×M survient quand chaque agent doit intégrer indépendamment chaque service externe, ce qui crée N multiplié par M connexions à maintenir. N représente le nombre d’agents et M le nombre de services/backends. Le coût de maintenance, les tests et les risques d’erreur croissent en O(N×M), rapidement ingérables.

La solution consiste à standardiser l’accès via un MCP (Middle‑Control‑Plane) et à utiliser des Skills comme déclencheurs locaux et légers. Le MCP joue le rôle de pont client‑serveur standardisé, centralisant l’authentification, la traduction de protocoles et les règles d’acheminement. Les Skills offrent des points d’extension locaux sur chaque agent pour déclencher des actions sans multiplier les intégrations directes.

• Diagramme texte : Agents → MCP → Multiples backends. Chaque agent parle un protocole unique au MCP, et le MCP s’occupe des M backends.
• Diagramme texte alternatif : Agents → Skills locaux → (Skills runtime → Backends). Les agents déclenchent des Skills locaux ; le runtime Skills gère les intégrations vers les services.

Exemple chiffré : Avec 10 agents (N=10) et 8 services (M=8), intégrations directes = 10×8 = 80 connexions. Avec un MCP on passe à N+M = 10+8 = 18 intégrations à maintenir (10 agents → MCP, 8 backends → MCP). Avec une approche Skills où chaque agent n’a qu’une interface de déclenchement unique vers un runtime partagé, on peut réduire à N×1 = 10 intégrations agent‑side, les intégrations backends étant gérées une seule fois côté runtime (total pratique ≈ 10+8 mais sans duplication agent‑side).

Encadré : JSON‑RPC est un protocole léger d’appel de procédure à distance utilisant JSON. Un protocole typé (schémas JSON Schema, Protobuf) permet de valider les messages en entrée/sortie, de détecter les régressions tôt et de réduire les erreurs d’interprétation des payloads.

Problème	Approche MCP	Approche Skills
Maintenabilité	Fortement améliorée : centralisation des connecteurs, mise à jour unique.	Bonne : agents restent simples, mais runtime Skills doit être bien géré.
Latence	Légère augmentation possible via relais MCP mais optimisable.	Variable : déclenchement local rapide, intégrations backend peuvent ajouter latence.
Complexité	Complexité centralisée dans le MCP (architecture maîtrisable).	Complexité répartie entre agents (faible) et runtime Skills (concentrée).

Quelle architecture pour MCP et Skills ?

Pour un déploiement robuste d’agents, il faut séparer le MCP (Master Control Process) des Skills et leur donner des responsabilités claires.

Le MCP doit être un service back‑end persistant et isolé, exécuté dans un conteneur ou sur un serveur dédié. Il gère une API stable (REST/HTTP ou gRPC), l’authentification et la gestion des credentials (rotation des clés, vault, scopes), la persistance des états nécessaires et l’observabilité (logs structurés, traces, métriques). Le processus séparé améliore la résilience en limitant l’impact d’un Skill défectueux, facilite l’audit en centralisant les accès et rend possible la rotation des clés sans redéployer les Skills.

Organisation d’un Skill sur le filesystem :

• Structure type : Chaque Skill reste léger et local, sous forme de dossier contenant metadata, scripts et tests.
• Exemple d’arborescence :
  • skill-name/
  • skill-name/SKILL.md
  • skill-name/scripts/
  • skill-name/examples/
  • skill-name/tests/

Exemple de contenu pour SKILL.md :

# Skill: Résumé d'actions
Description: Ce skill interroge le MCP pour récupérer un token, puis exécute une action métier simple.
Entrées: param1 (string), param2 (int)
Sorties: status (success|error), payload (json)

Exemple de script minimal (bash pseudo‑code) :

#!/bin/bash
# Récupérer token depuis MCP
TOKEN=$(curl -s -X POST https://mcp.example.com/auth -d '{"id":"skill"}')
# Appeler une API protégée via le MCP
curl -s -H "Authorization: Bearer $TOKEN" https://mcp.example.com/perform?param=1

Points d’attention opérationnels :

• Déploiement : Déployer le MCP via CI/CD dans des conteneurs orchestrés (Kubernetes) et versionner ses API pour éviter les ruptures.
• Versionning des Skills : Utiliser SemVer pour les Skills et inclure un manifest indiquant la compatibilité API du MCP.
• Tests : Faire des tests unitaires locaux en mockant le MCP et des tests d’intégration contre un MCP de staging. Prévoir des tests de non‑régression et des tests de charge côté MCP.
• Sécurité & Opérations : Externaliser les secrets (Vault), surveiller les quotas, prévoir la rotation des clés et les journaux d’audit.

Composant	Hébergement	Persistance	Déploiement
MCP	Conteneur/Serveur isolé	Base persistante ou store d’état	CI/CD, versions d’API
Skills	Dossiers locaux légers	Stateless ou stockage externe via MCP	Packages/versioning léger, déployés avec l’app

Comment s’invoquent MCP et Skills ?

Les deux approches s’invoquent très différemment et cela guide le design et la sécurité de vos agents. MCP (Micro-Command Protocol) passe par des appels JSON-RPC typés et structurés. Skills s’exécutent comme des scripts shell ou des programmes interprétés fournis localement.

Pourquoi des schémas typés réduisent les erreurs. Les schémas JSON (JSON Schema) décrivent la forme attendue des données : types (string, integer, object), champs obligatoires vs optionnels, formats (date, email), contraintes (min/max). La validation avant exécution empêche les erreurs runtime courantes (champ manquant, type incorrect). La typage facilite l’orchestration : un orchestrateur sait quelles sorties consommer et quels paramètres transmettre, ce qui réduit les cas d’échec dans des workflows automatisés.

Exemple minimal JSON-RPC

{
  "jsonrpc": "2.0",
  "id": "req-123",
  "method": "file.search",
  "params": {
    "query": "rapport",
    "max_results": 10
  }
}

Chaque champ expliqué : jsonrpc indique la version du protocole. Id corrèle la réponse à la requête. Method nomme la procédure à appeler. Params contient les paramètres structurés ; ici query est requis, max_results est optionnel et typé integer.

Exemple de SKILL.md et invocation

name: search-local
description: Cherche des fichiers contenant un motif
entrypoint: ./search.py
usage: bash run_skill.sh "rapport"

# run_skill.sh
#!/bin/bash
python3 ./search.py "$1"

Agent charge et valide un Skill en lisant le manifest (SKILL.md), vérifiant la présence et les permissions de l’entrypoint, contrôlant les dépendances déclarées et, si présent, validant une signature ou un checksum. Des sandboxs ou environnements isolés limitent la portée avant exécution.

Compromis : Les Skills offrent rapidité d’itération et liberté (modification locale, tests rapides). MCP impose plus de rigueur et sécurité grâce au typage, à la validation et à la traçabilité des appels.

Aspect	MCP	Skills
Invocation	JSON-RPC typé	Script / shell
Validation	Schéma + runtime strict	Manifest + permissions
Flexibilité	Modérée (contrats)	Elevée (scripts libres)
Sécurité	Haute (validation, audit)	Variable (dépend de sandbox)

Où s’exécutent-ils et quelles implications sécurité ?

Où s’exécutent les composants et quelles conséquences sur la sécurité sont essentielles pour choisir entre MCP (Model Control Plane) et des Skills/agents locaux.

Je distingue d’emblée deux architectures. MCP s’exécute isolé, souvent dans des conteneurs, des sidecars ou des runtimes séparés hébergés sur des serveurs dédiés. Ces patterns permettent de centraliser le contrôle, d’isoler les processus et d’appliquer des politiques réseau et OS différentes pour chaque instance.

Les MCP cachent et gèrent les credentials via des mécanismes centralisés : vaults (HashiCorp Vault, AWS Secrets Manager), volumes montés en mémoire ou agents de sidecar qui injectent des secrets éphémères. Ces solutions permettent la rotation automatique des clés, l’audit des accès et l’application de RBAC (Role-Based Access Control) pour limiter qui peut appeler quel modèle ou quelle API.

Les Skills locaux s’exécutent dans l’environnement même de l’agent (sur poste, VM ou container utilisateur). Ces Skills peuvent accéder au filesystem, lancer des commandes shell et, en cas de faille, provoquer une élévation de privilèges. Le risque principal réside dans la confiance portée au code tiers et la difficulté à appliquer des contrôles centralisés.

Bonnes pratiques pour les Skills : sandboxing (containers, gVisor, Firecracker), principe du Moindre Privilège (limiter les permissions système et réseau), signature et vérification cryptographique des bundles de Skills, et pipelines de tests automatisés (SAST/DAST) avant déploiement.

• Checklist opérationnelle : Rotation régulière des clés via un vault.
• Checklist opérationnelle : Journalisation et logs d’audit centralisés pour chaque exécution.
• Checklist opérationnelle : Quotas et limites de ressources (CPU, mémoire, I/O).
• Checklist opérationnelle : Scan statique des scripts et dépendances (SCA) avant mise en prod.
• Checklist opérationnelle : Sandbox par défaut et élévation explicite via workflow validé.

Comparatif	Isolation	Gestion des credentials	Audit
MCP	Conteneurs/sidecars, runtime séparé	Vaults, secrets éphémères, RBAC	Logs centralisés, traçabilité
Skills	Exécution locale, dépend des protections de l’hôte	Souvent embarquée ou locale, plus risquée	Audit plus dispersé, besoin d’agent local

Pour réduire les risques privilégiez MCP quand vous avez besoin de contrôle, appliquez vaults et RBAC, et si vous utilisez des Skills locaux imposer sandboxing, signatures, tests et monitoring continu.

# Exemple minimal : Pod Kubernetes avec sidecar de secrets (schématique)
apiVersion: v1
kind: Pod
metadata:
  name: mcp-example
spec:
  containers:
  - name: mcp
    image: my-mcp:latest
  - name: secret-sidecar
    image: secret-agent:latest
    volumeMounts:
    - name: secrets
      mountPath: /run/secrets
  volumes:
  - name: secrets
    emptyDir: {}

Quand privilégier MCP ou Skills dans vos cas d’usage ?

Choix pragmatique entre MCP (Manager of Connector/Proxy) et Skills : privilégier MCP pour les intégrations critiques, fréquentes et à faible latence ; privilégier Skills pour les tâches légères, d’expérimentation ou locales. MCP signifie une couche centralisée et sécurisée pour gérer les connexions externes. Skills désigne des modules locaux, rapides à déployer, souvent sans orchestration centralisée.

Règles simples :

• Si la fréquence est élevée (par exemple >1000 opérations/jour), la latence critique (<100 ms) ou la sécurité stricte est requise → utiliser MCP.
• Si l’objectif est d’expérimenter, d’exécuter des tâches locales, de produire des templates ou des recettes en ligne de commande → utiliser Skills.
• Si l’intégration nécessite audit, contrôle d’accès centralisé ou résilience transversale → MCP.
• Si la tâche est itérative, non critique et change souvent → Skills pour itérations rapides.

6 cas concrets :

• Synchronisation Postgres : MCP recommandé. Raison : Cohérence, transactions et faible latence sur réplication ou CDC.
• Paiement Stripe : MCP recommandé. Raison : Exigences PCI, journalisation centralisée et gestion des erreurs critique.
• Extraction PDF (OCR ponctuel) : Skills recommandé. Raison : Traitement local par lot, expérimentations d’OCR et consommation CPU variable.
• Génération de templates e-mail : Skills recommandé. Raison : Variantes fréquentes, rapidité d’itération et faible impact sécurité.
• Notifications Slack : Skills recommandé pour usages légers ; MCP si volume élevé ou besoin d’ordonnancement garanti.
• Transformation CSV / ETL volumineux : MCP recommandé. Raison : Observabilité, scalabilité et contrôle de backpressure.

Plan de migration hybride en 4 étapes :

• Inventaire : Identifier flux, poids, fréquence et contraintes de sécurité.
• Isoler services via MCP : Migrer intégrations critiques et à haute fréquence vers MCP.
• Factoriser Skills : Extraire templates, scripts et transformations légères en Skills réutilisables.
• Monitorer : Mettre en place métriques (latence, erreurs, débit) et ajuster selon SLA.

Cas	Fréquence	Solution recommandée	Raison
Synchronisation Postgres	Élevée	MCP	Transactions, cohérence et faible latence
Paiement Stripe	Variable	MCP	Sécurité et audit
Extraction PDF	Basse/ponctuelle	Skills	Expérimentation et charge CPU locale
Génération de templates	Variable	Skills	Itération rapide et simplicité
Notifications Slack	Basse à moyenne	Skills (ou MCP si volume)	Simplicité vs scalabilité
Transformation CSV	Élevée	MCP	Scalabilité et observabilité

Prêt à combiner MCP et Skills pour rendre vos agents plus fiables et agiles ?

La bonne pratique consiste à ne pas opposer MCP et Agent Skills mais à les combiner. MCP apporte une interface stable, sécurisée et opérable pour les intégrations critiques et à fort volume ; les Skills offrent vitesse d’itération et contrôle local pour le comportement et les recettes. En appliquant une architecture hybride vous réduisez la dette d’intégration, améliorez la sécurité des credentials et conservez la flexibilité nécessaire pour innover rapidement. Bénéfice clair pour vous : moins de maintenance, plus de sécurité et des agents plus utiles et agiles.

FAQ

• Qu’est-ce que MCP ?
  MCP est un protocole client‑serveur et une infrastructure d’intégration qui standardise l’accès des agents à des services externes (APIs, bases de données, outils), évitant l’explosion N×M d’intégrations.
• Qu’est-ce qu’un Agent Skill ?
  Un Skill est un dossier local contenant un SKILL.md, scripts et exemples : un playbook léger, déclenché à la demande pour définir le comportement ou une tâche spécifique de l’agent.
• Quand choisir MCP plutôt que Skills ?
  Privilégiez MCP pour intégrations critiques, fréquentes ou sensibles (paiements, bases de données, notifications d’entreprise) où la sécurité, la stabilité et l’observabilité sont essentielles.
• Les Skills posent-ils des risques de sécurité ?
  Oui si mal gérés : exécution de scripts, accès filesystem ou commandes shell. Mitigation : sandboxing, principe de least privilege, signature des Skills et audits réguliers.
• Comment commencer une approche hybride ?
  Commencez par inventorier intégrations et tâches, externalisez les intégrations critiques vers un MCP, transformer ensuite les recettes et comportements en Skills testés localement. Monitorer et itérer.

 

 

A propos de l’auteur

Franck Scandolera — expert & formateur en tracking server-side, analytics engineering, automatisation No/Low Code (n8n) et intégration d’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. Disponible pour aider les entreprises => contactez-moi.