Pourquoi ce sujet compte maintenant
“On a déjà des Skills, pourquoi on parle encore de MCP?” Si vous vous posez la question, c’est normal: les deux sujets sont souvent vendus comme des “plugins”.
Mais techniquement, ce n’est pas la même couche. Et confondre les deux conduit à de mauvais choix d’architecture.
Ce qu’il faut comprendre en premier
On peut simplifier comme ça.
- Skills: paquet d’instructions/capacités orientées usage (comment l’agent agit dans un contexte donné).
- MCP: protocole standard pour connecter un agent à des outils et données externes.
Autrement dit, Skills traite surtout le comportement de l’agent; MCP traite surtout la connectivité et l’interopérabilité.
Analyse detaillee
Pourquoi cette distinction est importante pour une équipe dev?
-
Portabilité Si vous encodez toute votre logique métier dans une couche spécifique de skills, vous devenez dépendant d’un environnement. MCP, lui, vise une interface standard client/serveur pour réutiliser les mêmes connecteurs entre outils.
-
Gouvernance Les skills sont très efficaces pour “comment faire” (workflow, ton, étapes, garde-fous de tâche). MCP est plus utile pour “à quoi accéder” (sources de données, actions autorisées, outils exposés).
-
Sécurité opérationnelle Le risque n’est pas le même. Côté skills, le risque est surtout comportemental (mauvaise instruction, scope ambigu). Côté MCP, le risque principal est l’exposition d’actions et de données (prompt injection, exfiltration, write tools mal maîtrisés). OpenAI et Anthropic insistent tous deux sur ces précautions dans leur doc MCP.
-
Bon découplage pratique Le pattern qui marche en équipe:
- Skills pour la recette de travail (brief, format de rendu, contrôles qualité).
- MCP pour les connecteurs (Git, docs internes, tickets, BI, etc.).
- Une couche politique qui décide quels outils sont autorisés selon le contexte.
- Évolutivité Quand vous devez changer de modèle, d’IDE agentique, ou de fournisseur, un découplage net skills/protocole réduit le coût de migration.
Erreurs frequentes et limites
Il y a quand même deux pièges.
Premier piège: croire qu’un protocole standard règle automatiquement la qualité. MCP règle la plomberie, pas la stratégie. Si vos briefs sont flous, vos agents resteront flous.
Deuxième piège: croire qu’un skill bien écrit suffit côté sécurité. Faux. Sans contrôle strict des permissions et des actions write, vous augmentez rapidement la surface d’attaque.
Il faut aussi accepter que l’écosystème bouge vite. Les docs évoluent, les implémentations diffèrent, et certains serveurs tiers sont inégaux en maturité.
Ce que ça change pour les devs
Pour aller plus loin sans repartir de zero, regardez aussi notre playbook de cadrage des agents et notre guide QA en CI pour limiter les faux positifs.
Plan d’application concret sur 3 semaines: commencez par un perimeter restreint (une classe de tickets ou un service), definissez 2 indicateurs de resultat et 1 indicateur de risque, puis faites une revue courte hebdomadaire avec une action corrective obligatoire. Le but est d’eviter le mode “on teste un peu partout” qui donne beaucoup de bruit et peu d’apprentissage. Cette discipline simple permet de comparer les runs entre eux, de voir ce qui s’ameliore reellement, et de couper rapidement les usages qui degradent la qualite ou les delais.
Si vous etes en equipe mixte (seniors + profils moins experimentes), nommez un responsable de la coherence du cadre pour eviter que chacun redefine les criteres de qualite a sa facon. Sans ce role, l’agent peut produire du code exploitable, mais la review devient incoherente et la confiance baisse. Avec ce role, vous obtenez un cycle plus stable: cadrage plus net, feedback plus utile, et decisions plus rapides sur ce qu’il faut industrialiser ou abandonner.
Mon verdict: il ne faut pas choisir “Skills ou MCP”. Il faut les positionner correctement.
- MCP est le standard d’intégration.
- Skills est la couche d’orchestration comportementale.
- La sécurité doit être pilotée par des permissions explicites, pas par la confiance dans les prompts.
Le duo est puissant à condition de garder une séparation claire des responsabilités.
Verdict et prochaine etape
Dans la suite, on peut publier un schéma d’architecture prêt à implémenter: séparation des permissions, mapping des outils MCP par environnement (dev/staging/prod) et template de skill d’équipe.
Si vous voulez ce blueprint, abonnez-vous à la newsletter: on vous enverra la version check-listable pour équipe produit+infra.
Sources:
