# Au-delà de « MCP vs skills » : composer une architecture d'agent à l'échelle

> MCP résout le problème de connectivité N×M. Les skills résolvent la saturation du contexte. La vraie opportunité n'est pas d'en choisir un : c'est de composer des skills au-dessus de MCP, organisés par contexte métier.

Language: fr · Category: engineering · Author: Nicolas Corod (Ingénierie) · Published: 2026-02-05

Cadrer le débat comme « MCP vs skills » passe à côté du sujet. Comme Kurtis Van Gent l'a [récemment défendu](https://kvg.dev/posts/20260125-skills-and-mcp/), ces deux approches répondent à des problèmes différents : [MCP](https://modelcontextprotocol.io/) s'attaque au problème d'intégration N×M, les skills répondent à la saturation du contexte. Exact. Mais la vraie opportunité, c'est de les composer dans une architecture unifiée.

Chez [skilder](https://www.skilder.ai), nous avons construit précisément cela : des skills qui composent des outils MCP en capacités cohérentes, organisés par contexte métier, et exposés via un serveur MCP unique avec une divulgation progressive intégrée au protocole.

## Deux problèmes, une seule architecture.

**Le problème d'intégration N×M.** Vous avez N agents (Claude Code, Cursor, votre SDK maison) et M sources de données (GitHub, Slack, Postgres). Sans standardisation, chaque paire agent-outil exige un connecteur sur mesure. MCP ramène cela à N+M avec un protocole universel.

**Le problème de saturation du contexte.** Votre agent a accès à 80 outils. Chaque schéma d'outil consomme des tokens. Chargez-les tous d'entrée et vous brûlez 30 000 tokens avant même que l'utilisateur ait dit bonjour. Pire, les modèles raisonnent moins bien lorsqu'ils doivent arbitrer entre des options non pertinentes. L'équipe ADK de Google parle de « signal degradation ».

Les agent skills résolvent cela par la divulgation progressive. L'agent voit d'abord des métadonnées légères. Les instructions complètes et les outils ne se chargent qu'à la demande.

## Là où chaque approche échoue, prise isolément.

**Le coût de contexte de MCP.** Chaque serveur MCP connecté déverse ses définitions d'outils dans votre fenêtre de contexte. Connectez-vous à GitHub, Slack, Postgres et un serveur CI/CD : des centaines de définitions d'outils chargées avant le moindre travail. Les recherches d'Anthropic ont elles-mêmes montré qu'un chargement à la demande faisait passer la consommation de 150 000 à 2 000 tokens dans un cas réel.

**Le problème d'isolation.** Un skill apprend à un agent à déployer du code. Mais atteindre le système de déploiement effectif suppose des scripts maison (dépendants de l'environnement, fragiles) ou un repli sur MCP (et la perte de l'efficacité contextuelle). Écrivez un skill sur macOS, partagez-le avec une collègue sur Windows, et il cassera.

**La prolifération multi-serveurs.** Les équipes se retrouvent avec cinq serveurs MCP connectés, une douzaine de skills éparpillés, et aucune relation claire entre les deux. L'agent doit deviner quel skill s'applique à quel serveur, quels outils appartiennent à quel workflow. La charge cognitive s'empile.

## La thèse de la composition.

Le correctif : les skills deviennent la couche de composition au-dessus de MCP.

Un skill regroupe des outils MCP liés en une unité cohérente, avec des instructions sur la façon de les utiliser ensemble. Un skill « deploy-to-staging » relie les outils précis dont il a besoin et guide l'agent dans le workflow. L'agent voit « deploy-to-staging » comme un concept unique. Il n'a pas besoin de savoir que GitHub et CircleCI existent comme systèmes distincts.

MCP gère la connectivité. Le skill gère la chorégraphie.

Chez [skilder](https://www.skilder.ai), nous exposons tout cela via un serveur MCP unique. Votre agent se connecte à un seul endpoint au lieu de cinq. La divulgation progressive est inscrite dans le protocole lui-même : l'agent démarre avec un catalogue léger des skills disponibles et ne charge les schémas d'outils complets que lorsque c'est nécessaire.

Résultat : au lieu de payer 20 000 tokens d'entrée pour 10 serveurs d'outils, vous payez environ 2 900 tokens, avec des capacités équivalentes chargées à la demande.

### Contexte métier, pas catalogue d'outils.

Une liste plate de skills crée son propre problème. Dans un environnement d'entreprise, des dizaines de skills couvrant plusieurs équipes recréent la même surcharge cognitive, un cran plus haut.

Nous organisons les skills en groupes de contexte métier : des collections nommées par rôle, domaine ou workflow. Un groupe « DevOps » réunit déploiement, monitoring et rollback. Un groupe « Customer Support » réunit recherche, facturation et escalade.

L'agent navigue des concepts métier plutôt que des catégories techniques. Cela fait le pont entre la façon dont les ingénieurs pensent (outils, API) et la façon dont les organisations pensent (rôles, processus, domaines).

### De la transparence à la délégation.

Tous les workflows n'exigent pas le même niveau d'implication de l'agent. Les regroupements d'outils simples ont besoin d'un contrôle total de l'agent. Les workflows complexes et éprouvés gagnent à être délégués.

[skilder](https://www.skilder.ai) couvre tout le spectre : de l'agent qui orchestre des outils individuels en pleine transparence, jusqu'à l'exécution en sous-agent où un processus autonome absorbe la complexité. Les organisations démarrent en mode transparent et font monter en délégation les workflows éprouvés, à mesure qu'ils prouvent leur fiabilité.

## Pourquoi cela passe à l'échelle.

**Efficacité du contexte.** Les agents paient pour ce qu'ils utilisent. Pas pour ce qu'ils pourraient utiliser.

**Charge cognitive réduite.** Des capacités pré-composées avec des instructions claires. Les erreurs de sélection d'outils chutent quand les agents travaillent avec des workflows cohérents plutôt qu'avec des schémas d'outils bruts.

**Point de connexion unique.** Un seul serveur MCP à connecter, configurer et sécuriser. Pas de prolifération d'identifiants.

**Gouvernance d'entreprise.** Chaque invocation de skill et chaque appel d'outil sont tracés. Les pistes d'audit complètes alimentent l'optimisation : skills inutilisés, patterns de timeout, points chauds d'échec. Les skills s'améliorent à partir des données d'usage au fil du temps.

**Suivi des dépendances.** Quand un serveur MCP sous-jacent change, les skills affectés sont identifiés automatiquement. Les mises à jour se propagent dans le système au lieu d'exiger des audits manuels.

## Compromis.

**Complexité d'écriture.** Créer des skills composés suppose de comprendre à la fois le workflow et les outils sous-jacents. Notre approche : la génération de skills assistée par IA. Décrivez un workflow en langage naturel. [skilder](https://www.skilder.ai) amorce la structure du skill.

**Complexité du débogage.** Les couches d'abstraction ajoutent de la complexité au débogage. Mitigation : une télémétrie structurée à chaque couche, avec un contexte de trace qui circule à travers toute la stack.

**Surcoût de découverte.** La divulgation progressive ajoute un aller-retour avant que l'agent n'utilise les outils. Les skills préchargés contournent cela pour les workflows connus. Pour la plupart des cas d'usage en entreprise, les économies de contexte dépassent largement ce coût.

## Pour démarrer.

1. **Identifiez les workflows à forte valeur.** Trouvez trois à cinq workflows où votre équipe coordonne régulièrement plusieurs outils. Ce sont vos premiers skills composés.
2. **Commencez simplement, montez vers la délégation.** Démarrez avec des skills qui regroupent des outils liés et de bonnes instructions. Promouvez les workflows stables vers plus d'automatisation à mesure qu'ils prouvent leur fiabilité.
3. **Organisez par contexte métier dès le départ.** Structurez les skills par rôle ou domaine dès le début. Imposer une structure plus tard est plus difficile.
4. **Exposez via une passerelle unique.** Connectez vos agents à travers un seul serveur MCP. Ajouter des skills n'augmente pas le coût de contexte de base.

## Perspectives.

La [proposition SEP-2076](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076) suggère d'ajouter les Agent Skills directement à la spécification [MCP](https://modelcontextprotocol.io/). Un support natif des skills composés, avec dépendances d'outils et divulgation progressive, ferait de ce pattern un standard plutôt qu'un montage maison.

Au-delà : les graphes de skills fédérés. Des organisations publient des collections de skills que d'autres consomment et étendent. Des graphes DevOps maintenus par la communauté, enrichis de workflows spécifiques à chaque entreprise. La composition à l'échelle de l'écosystème.

Le débat MCP vs skills est une fausse opposition. MCP résout la connectivité. Les skills résolvent l'efficacité du contexte. Le modèle que nous avons construit chez [skilder](https://www.skilder.ai) les compose : des skills au-dessus de MCP, organisés par contexte métier, exposés via un serveur unique avec divulgation progressive au niveau du protocole.

L'avenir de l'architecture d'agent, c'est des skills au-dessus de MCP, composés en un graphe de connaissances qui passe à l'échelle de votre organisation.