Agent Skills vs MCP : choisir la bonne interface
Agent skills et MCP expliqués : comparez les instructions, les connexions aux outils, les limites de sécurité, le versioning et les situations où les combiner pour obtenir des agents IA fiables.
Le choix entre agent skills et MCP est souvent présenté comme une compétition entre deux façons de « donner des outils à une IA ». Cette vision est incomplète. Une skill et un serveur Model Context Protocol répondent à des niveaux différents du problème : l’une apprend à un agent à opérer dans un domaine, tandis que l’autre expose des capacités et du contexte via une connexion standardisée.
Dockup utilise un SKILL.md parce que son interface principale est un outil en ligne de commande existant. La skill apprend à Claude Code et Codex à utiliser cette CLI en toute sécurité : toujours demander du JSON, s’authentifier sans interaction, résoudre les cibles exactes, attendre les états terminaux d’un déploiement et s’arrêter avant toute opération destructive.
Qu’est-ce qu’une agent skill et pourquoi SKILL.md est-il important ?
Une agent skill est un répertoire contenant des instructions d’utilisation et des références complémentaires qu’un agent peut charger lorsqu’une tâche correspond à son objectif. SKILL.md en est le point d’entrée : son frontmatter décrit la capacité, tandis que son corps explique les workflows, les contraintes, les exemples et les règles de décision.
Une skill est particulièrement utile lorsque l’interface exécutable existe déjà. L’agent n’a pas besoin d’un nouvel adaptateur de protocole pour exécuter une CLI bien conçue. Il a besoin de connaissances précises sur les points suivants :
- Quelles commandes font autorité.
- Quels flags sont nécessaires pour une utilisation automatisée.
- Comment fonctionne l’authentification dans un sandbox.
- Quels outputs prouvent la réussite.
- Quelles actions nécessitent l’intervention d’un humain.
- Où des secrets peuvent apparaître.
- Comment diagnostiquer les erreurs courantes.
L’installation de Dockup est volontairement simple :
npm install -g dockup-cli
dockup skill install
dockup skill status --json
Une copie canonique est écrite dans ~/.agents/skills/dockup/ et liée à Claude Code et Codex. La skill est incluse dans le package de la CLI, et dockup update les actualise ensemble. Ce choix de packaging évite un problème fréquent : des instructions qui décrivent des commandes absentes du binaire installé.
La skill n’est pas le moteur de déploiement. La CLI exécute les opérations, émet du JSON et renvoie des codes de sortie. La skill est le manuel d’utilisation que suit l’agent.
Qu’est-ce que le Model Context Protocol ?
Le Model Context Protocol, couramment appelé MCP, est un protocole ouvert qui permet de connecter une application d’IA à des outils, des ressources et des prompts externes via une architecture client-serveur. Un serveur MCP peut exposer des tools appelables, des resources lisibles et des prompts réutilisables. Un client MCP intégré à l’hôte de l’agent découvre et invoque ces capacités.
MCP est utile lorsqu’un système a besoin d’une frontière de protocole durable plutôt que d’une exécution locale via le shell. Voici quelques exemples :
- Une API SaaS distante qui doit exposer des opérations soigneusement typées.
- Une source de données qui fournit des resources navigables.
- Une application desktop qui souhaite permettre la découverte d’outils sans distribuer de CLI.
- Un service central utilisé par de nombreux hôtes d’agents et systèmes d’exploitation.
- Une intégration dans laquelle le serveur doit gérer les identifiants et les règles de sécurité.
Le serveur contrôle l’implémentation derrière chaque outil. L’hôte de l’agent voit le nom déclaré, la description, le schéma d’entrée et l’output. Le transport, le cycle de vie et l’autorisation dépendent de la configuration MCP choisie.
MCP ne fournit pas automatiquement le discernement propre au domaine. Un serveur peut exposer delete_service, mais l’agent a toujours besoin d’une règle lui indiquant dans quels cas la suppression est appropriée. À l’inverse, une skill peut expliquer un workflow, mais elle ne peut pas créer des capacités absentes de la CLI ou de l’API sous-jacente.
En pratique, quelles sont les différences entre agent skills et MCP ?
La comparaison la plus claire consiste à examiner les responsabilités :
| Dimension | Agent skill / SKILL.md | Serveur MCP |
|---|---|---|
| Mission principale | Enseigner les workflows et les contraintes | Exposer des outils, des resources et des prompts |
| Exécution | Utilise des CLI, fichiers, API ou applications existants | Le serveur implémente les capacités appelables |
| Découverte | L’agent charge les instructions de la skill correspondante | Le client découvre les capacités du serveur |
| Déploiement | Souvent un dossier installé avec un package | Un processus serveur local ou distant |
| Risque de version | Les instructions peuvent diverger de l’outil | Le schéma du serveur peut diverger du comportement du backend |
| Cas d’usage idéal | Une interface existante a besoin de consignes expertes | Une capacité nécessite une frontière de protocole standardisée |
| Enjeu de sécurité | Règles comportementales et sécurité des commandes | Connexion, confiance accordée au serveur, scopes et autorisation des outils |
| Utilisation hors ligne/locale | Excellente avec des CLI locales | Possible avec un serveur MCP local |
| Réutilisation avec plusieurs clients | Copier ou packager la skill pour chaque hôte | Un serveur peut prendre en charge plusieurs clients compatibles |
Aucune des deux approches n’est intrinsèquement plus « agentique ». La fiabilité dépend de l’adéquation entre l’interface et le système.
Pour Dockup, la CLI dispose déjà de 135 commandes, d’un JSON structuré, de vrais codes de sortie, d’un timeout de déploiement par défaut de 900 secondes, du masquage des secrets et de protections par confirmation. Envelopper chaque commande dans un autre serveur local ajouterait une couche de traduction sans modifier la réalité du déploiement sous-jacent. Une skill est parfaitement adaptée, car elle apprend à l’agent à utiliser le contrat exécutable déjà en place.
Une plateforme distante sans CLI pourrait parvenir à la conclusion inverse. Un serveur MCP peut fournir la surface d’outils typés manquante et garder les identifiants d’API en dehors de l’environnement shell de l’agent.
Quand utiliser une skill, MCP ou les deux ?
Utilisez uniquement une skill lorsque toutes les conditions suivantes sont réunies :
- Une CLI mature ou une application locale expose déjà la capacité requise.
- L’hôte de l’agent est autorisé à l’exécuter.
- Les outputs lisibles par machine et la sémantique des codes de sortie sont suffisants.
- Le principal manque concerne les connaissances procédurales, pas la connectivité.
- Le packaging permet de maintenir les instructions alignées sur l’exécutable.
Utilisez uniquement MCP lorsque l’agent a besoin d’une connexion native au protocole et que le serveur peut lui-même fournir suffisamment de contexte pour une utilisation sûre. C’est fréquent pour l’accès à des données principalement en lecture, les services distants et les applications qui souhaitent une interface d’outils stable entre plusieurs clients.
Utilisez les deux lorsque les outils du protocole ont besoin d’un playbook d’utilisation plus riche. Un serveur MCP peut exposer des primitives sûres et typées, tandis qu’une skill explique le workflow métier en plusieurs étapes, les règles d’escalade et les critères de validation. La skill peut indiquer à l’agent quand et pourquoi appeler chaque outil MCP.
Une architecture combinée peut ressembler à ceci :
Demande utilisateur
↓
Skill : workflow, règles, critères de validation
↓
Client MCP : découvre les capacités typées
↓
Serveur MCP : s’authentifie et exécute
↓
Système externe
Une architecture centrée sur une CLI est plus simple :
Demande utilisateur
↓
Skill : workflow, règles, critères de validation
↓
CLI : output JSON + code de sortie + sémantique d’attente
↓
API de la plateforme
La complexité doit être justifiée par une frontière qu’elle améliore. Ajouter MCP uniquement parce que c’est à la mode peut créer un processus supplémentaire à déployer, authentifier, superviser et versionner.
Exemples de décisions
| Situation | Meilleur point de départ | Raison |
|---|---|---|
| CLI de déploiement locale avec output JSON | Skill | La connectivité existe déjà |
| Base de connaissances d’entreprise avec resources structurées | MCP | La découverte des resources est centrale |
| API d’administration de base de données sans CLI | MCP | Les opérations distantes typées sont utiles |
| Runbook de release complexe entre plusieurs outils existants | Skill | La procédure interoutils est le besoin principal |
| Opérations distantes réglementées avec règles détaillées | Les deux | Le serveur applique le scope ; la skill guide le comportement |
| Automatisation personnelle ponctuelle | Skill ou CLI directe | Frais opérationnels minimaux |
La bonne réponse peut évoluer avec le temps. Une équipe peut commencer par une skill autour d’une CLI, puis ajouter un serveur MCP lorsque l’accès distant depuis plusieurs clients ou la gestion centralisée des identifiants deviennent importants.
Comment comparer les limites de sécurité et de confiance ?
Les skills sont des instructions ; leur risque en matière de confiance ressemble donc à celui d’une documentation technique ayant une influence opérationnelle. Une skill malveillante ou négligente peut demander à un agent d’exposer des secrets, de désactiver des protections ou d’exécuter des commandes destructives. Examinez l’intégralité du répertoire, pas seulement son titre.
Lors de l’examen d’une skill, posez-vous notamment les questions suivantes :
- Qui l’a publiée ?
- Invoque-t-elle des commandes sans rapport avec son objectif déclaré ?
- Demande-t-elle à l’agent d’afficher des tokens ou des identifiants ?
- Contourne-t-elle les confirmations ?
- Les exemples de commandes correspondent-ils à la version installée ?
- Les mises à jour peuvent-elles remplacer la skill sans vérification ?
- La skill définit-elle un processus borné de découverte des cibles ?
MCP introduit une frontière de confiance au niveau du serveur. Le client doit savoir à quel serveur il se connecte, quels outils celui-ci expose, quelles données quittent la machine et comment l’autorisation est limitée. Un serveur peut modifier son comportement derrière un nom d’outil stable ; la provenance du déploiement et le versioning du serveur sont donc importants.
Lors de l’examen d’un serveur MCP, posez-vous notamment les questions suivantes :
- Le serveur est-il local ou distant ?
- Qui l’exploite ?
- Comment les identifiants sont-ils stockés et renouvelés ?
- Quels appels d’outils peuvent modifier ou supprimer des données ?
- Les entrées des outils sont-elles validées côté serveur ?
- Les outputs sont-ils traités comme du contenu non fiable ?
- Chaque appel est-il auditable ?
- Le client peut-il restreindre les outils disponibles ?
L’hôte de l’agent ne doit pas assimiler « découvert via MCP » à « sûr ». La standardisation du protocole améliore l’interopérabilité, pas la fiabilité de chaque serveur.
La skill de Dockup encode plusieurs règles de sécurité : utiliser DOCKUP_TOKEN plutôt qu’une connexion interactive, ne jamais afficher les identifiants, découvrir les cibles avec dockup services --json, utiliser --wait et s’arrêter sur needs_confirm. La CLI renforce ces instructions en masquant les secrets et en refusant les opérations destructives sans approbation explicite. Ce modèle de défense en profondeur est décrit dans l’article production guardrails for AI agents.
Comment gérer le versioning et la récupération après erreur ?
Le version drift est possible dans les deux approches, mais il se manifeste différemment.
Une skill peut devenir obsolète lorsque la commande documentée change. La meilleure mesure d’atténuation consiste à packager la skill avec l’exécutable et à les mettre à jour via un processus de release unique. Dockup suit ce modèle. L’agent peut vérifier la skill installée avec :
dockup skill status --json
Une mise à jour actualise la CLI et la skill incluse simultanément :
dockup update
Un client MCP peut découvrir les schémas d’outils actuels du serveur, mais la compatibilité des schémas ne garantit pas la compatibilité sémantique. Un outil peut conserver les mêmes entrées tout en modifiant son autorisation, ses effets de bord, sa latence ou l’interprétation de ses outputs. Le serveur devrait publier ses versions, préserver la compatibilité ascendante dans la mesure du possible et renvoyer des erreurs structurées.
La gestion des erreurs diffère également. Une CLI fournit naturellement des codes de sortie de processus. Un appel d’outil MCP doit offrir un résultat au niveau applicatif tout aussi explicite. Dans les deux cas, l’agent ne doit pas déduire la réussite d’un simple accusé de réception au niveau du transport.
Voici une checklist de fiabilité utile :
| Exigence | Implémentation skill + CLI | Implémentation MCP |
|---|---|---|
| Découverte des capacités | Schéma de la CLI | Liste des outils du serveur |
| Output structuré | JSON/NDJSON | Résultat d’outil typé |
| Signal d’échec | Code de sortie non nul + code | Résultat d’erreur explicite |
| Opération longue | --wait / stream documenté | Protocole de progression ou d’achèvement |
| Protection des secrets | Masquage et discipline de stderr | Redaction côté serveur |
| Approbation destructive | Protection par confirmation de la CLI | Règle du serveur ou confirmation du client |
| Audit | Journal d’audit de la plateforme | Journaux d’audit du serveur et du backend |
| Vérification de version | Statut de la skill et du binaire | Métadonnées et schémas du serveur |
L’interface doit rendre plus difficile la déclaration erronée d’un échec que celle d’une réussite.
Quelle architecture une équipe de production doit-elle choisir ?
Commencez par identifier le manque réel.
Choisissez une architecture skill-first lorsque l’équipe fait déjà confiance à une CLI et l’exploite. Investissez dans son contrat machine : JSON, vrais codes de sortie, codes d’erreur stables, instructions alignées sur la version et confirmation. Packgez ensuite la skill avec l’outil. C’est le chemin le plus court pour le déploiement avec Claude Code et le déploiement avec Codex via Dockup.
Choisissez une architecture MCP-first lorsque la capacité est naturellement distante, orientée resources ou partagée entre de nombreux clients. Traitez le serveur comme un logiciel de production : authentifiez-le, limitez ses scopes, supervisez-le et examinez chaque mutation.
Choisissez les deux lorsque les règles et la connectivité sont indépendamment complexes. Définissez clairement les responsabilités. La skill ne doit pas dupliquer l’implémentation du serveur, et la description du serveur ne doit pas devenir un manuel d’utilisation tentaculaire.
Un atelier d’évaluation pratique
Réalisez un petit proof of concept avec une opération de lecture, une écriture réversible, une opération longue et une opération destructive qui doit être bloquée. Évaluez chaque conception selon les critères suivants :
- La manière dont l’agent découvre l’opération.
- La manière dont les identifiants sont fournis.
- La manière dont la réussite est prouvée.
- La manière dont l’échec est catégorisé.
- La manière dont un humain approuve les actions dangereuses.
- La manière dont les logs et les preuves d’audit sont récupérés.
- La manière dont les versions restent alignées.
- La manière dont l’intégration est supprimée proprement.
Ne prenez pas votre décision à partir d’un diagramme uniquement. Observez les chemins d’échec. Une conception élégante sur le happy path peut devenir ambiguë lorsqu’un déploiement expire, qu’un serveur se déconnecte ou qu’un fichier d’instructions a une release de retard.
La référence de la CLI Dockup fournit un exemple concret de contrat de CLI reposant sur une skill. L’article plus général sur le développement assisté par l’IA explique pourquoi ces interfaces deviennent importantes à mesure que les agents prennent en charge une part croissante du cycle de développement.
Tenez compte de la responsabilité opérationnelle
Le responsable de l’intégration compte autant que son architecture. Une skill appuyée sur une CLI hérite généralement des processus d’installation, de release et de support de cette CLI. L’équipe qui publie le binaire peut fournir les instructions correspondantes et les tester ensemble.
Un serveur MCP crée un composant de production distinct. Quelqu’un doit prendre en charge l’hébergement, les certificats ou le démarrage du processus local, l’authentification, la supervision, la réponse aux incidents, la compatibilité des schémas et les mises à jour des dépendances. Cet investissement peut être pertinent lorsque le serveur constitue une véritable frontière partagée. Il devient une surcharge inutile lorsqu’il ne fait que relayer des appels locaux vers un exécutable déjà suffisant.
Pendant l’évaluation, notez qui est responsable de chaque couche :
| Couche | Responsable dans une approche skill-first | Responsable dans une approche MCP-first |
|---|---|---|
| Instructions métier | Éditeur de la skill | Prompt du client ou skill associée |
| Comportement exécutable | Éditeur de la CLI | Équipe du serveur MCP |
| Gestion des identifiants | CLI et environnement d’exécution | Serveur et connexion du client |
| Disponibilité | Exécutable local et API de la plateforme | Processus serveur, transport et backend |
| Compatibilité des schémas | Processus de release de la CLI | Processus de release du serveur MCP |
| Éléments utiles en cas d’incident | Output de la CLI et audit de la plateforme | Logs du client, logs du serveur et audit du backend |
Ce tableau des responsabilités permet souvent de trancher le débat agent skills vs MCP plus clairement qu’une simple checklist de fonctionnalités.
Évaluez la latence et les surfaces d’échec
Un appel réalisé par une skill et une CLI locales suit un chemin court : hôte de l’agent, processus, API de la plateforme. Un chemin MCP peut ajouter le démarrage du serveur, la négociation du transport, le routage distant et une couche d’authentification supplémentaire. Ces ajouts ne sont pas nécessairement problématiques, mais chacun crée une nouvelle surface d’échec distincte.
Testez les déconnexions, l’expiration des identifiants, les entrées mal formées, les opérations longues partielles et les mises à niveau du serveur. L’agent doit pouvoir indiquer si l’échec s’est produit au niveau de l’hôte, de la connexion au protocole, du serveur ou de la plateforme externe. Un résultat générique du type « l’outil a échoué » ne suffit pas en production.
Pour les déploiements longs, l’interface doit préserver la sémantique de l’état terminal. Que l’appel soit une opération CLI --wait ou un outil MCP avec progression, l’agent ne doit pas transformer un accusé de réception en réussite. Le choix entre agent skills et MCP ne supprime pas cette exigence.
Préparez la portabilité sans sacrifier la vérité
MCP peut améliorer la portabilité entre les clients compatibles, car un même serveur annonce ses outils via un protocole partagé. Les skills peuvent également être portables lorsque plusieurs agents prennent en charge le même répertoire et les mêmes conventions SKILL.md, comme Claude Code et Codex pour le modèle d’installation de Dockup.
La portabilité n’est utile que si la sémantique reste précise. Un outil appelé deploy doit définir s’il renvoie la main lorsque l’opération est mise en file d’attente ou lorsque le service est healthy. Une instruction de skill qui dit « déployer et vérifier » doit pointer vers une commande capable de fournir réellement cette preuve.
La meilleure conception conserve la vérité métier au plus près de la couche exécutable et utilise la couche supérieure pour expliquer l’intention. Dans la comparaison agent skills vs MCP, ni un protocole standardisé ni un fichier d’instructions bien rédigé ne compensent une opération backend ambiguë.
Mettez le workflow en production
Utilisez l’architecture la plus simple qui crée une frontière digne de confiance. Pour Dockup, installez la skill packagée et laissez la CLI rester la source exécutable de vérité pour les déploiements.
npm install -g dockup-cli
dockup skill install
La première commande installe la CLI. La seconde installe la skill Dockup correspondante pour Claude Code et Codex. Commencez gratuitement sur app.dockup.ai.
FAQ
Les agent skills et MCP sont-ils la même chose ?
Non. Une skill fournit principalement des instructions et des connaissances opérationnelles. MCP fournit un protocole permettant d’exposer des outils, des resources et des prompts via une connexion client-serveur.
Un fichier SKILL.md exécute-t-il lui-même des commandes ?
Non. Il indique à l’agent comment utiliser les capacités sous-jacentes, telles qu’une CLI, des fichiers, des API ou des outils MCP. C’est l’interface exécutable qui réalise l’action.
Quand une skill est-elle préférable à MCP ?
Une skill est souvent le choix le plus simple lorsqu’une CLI locale mature fournit déjà des opérations sûres et lisibles par machine, et que le principal manque concerne les consignes de workflow.
Un agent peut-il utiliser une skill et MCP ensemble ?
Oui. Une skill peut décrire un workflow en plusieurs étapes et les règles associées, tandis qu’un serveur MCP expose les outils typés et les resources utilisés par ce workflow.
Pourquoi Dockup fournit-il sa skill dans le package de la CLI ?
Les packager ensemble permet à dockup update d’actualiser l’exécutable et ses instructions en une seule opération, ce qui réduit le risque que la skill décrive une autre version des commandes.