Compétences + MCP : les outils fournissent les moyens matériels, les compétences enseignent le flux de travail

Remarque : la conception « Compétences plutôt que MCP » présentée ici est expérimentale et en évolution. L’objectif est d’explorer cette direction, et non de prétendre disposer d’une norme MCP définitive.

MCP a permis aux agents d’accéder à des systèmes externes via un protocole commun, plutôt que par des intégrations spécifiques pour chaque agent. Les seules capacités ne suffisent pas : l’accès à un outil ne garantit pas une utilisation efficace de cet outil. Les compétences comblent cette lacune. Les équipes qui se contentent de dire « nous avons mis en place un serveur MCP » découvrent souvent que leurs agents, bien qu’ayant la possibilité d’appeler n’importe quel outil, choisissent mal sous pression.

MCP confère des capacités aux agents

Considérez MCP comme la couche de connexion. Un serveur peut exposer des outils tels que create_customer, get_order, send_email, create_invoice et search_documents. Les agents les découvrent et les invoquent grâce à un schéma commun.

Donnez un agent cinquante outils et il doit encore décider lesquels appeler, dans quel ordre, quels faits collecter en premier, comment réagir en cas d’échec d’une API, quand demander de l’aide à un humain, et quoi refuser. MCP fournit des capacités ; quelque chose d’autre doit fournir les connaissances opérationnelles. Sans ces connaissances, les listes d’outils deviennent des billets de loterie — parfois corrects, souvent gaspilleurs, occasionnellement nuisibles.

C’est là que les Skills interviennent

Un Skill regroupe des instructions réutilisables, du contexte et un flux de travail permettant à un agent d’accomplir une tâche concrète. Au lieu de ne présenter que :

create_invoice
send_email
get_customer

Définissez une compétence telle que Gérer la facturation des clients qui suit cette séquence : trouver le client, vérifier l’état de la facturation, valider le montant, créer la facture, demander l’approbation, l’envoyer et confirmer. Les outils MCP exécutent des actions ; la compétence fournit le raisonnement et l’ordre à suivre pour ces actions. La compétence peut également documenter les scénarios d’échec : que faire en cas de code 409, quand escalader le problème, quels champs sont fiables.

La compétence + MCP sont plus puissants l’un que l’autre pris séparément

MCP = ce que l’agent peut faire. Skill = la manière dont il doit le faire. Cette distinction devient de plus en plus importante à mesure que le nombre d’outils augmente. Un agent d’entreprise peut accéder à CRM, Stripe, GitHub, Slack, Drive, des API internes et des bases de données. MCP permet de mettre tout cela à disposition. Des centaines d’outils isolés créent souvent une surcharge de choix plutôt qu’une véritable compétence. Les Skills réduisent l’espace des décisions à un ensemble d’actions adaptées à chaque tâche, tout en utilisant des appels d’outils standardisés en sous-jacent.

Le problème de l’explosion des outils

Un seul serveur doté de cent outils alourdit déjà le modèle avec des descriptions, des paramètres et des relations. Cinq serveurs multiplient ce nombre. Faut-il charger chaque capacité à chaque tour ? Généralement non. Préférez la bonne capacité au bon moment. Les compétences organisent ce choix : pas « voici cinq cents outils — improvisez », mais « voici la tâche, voici les capacités et les instructions nécessaires ». Les fenêtres de contexte ainsi que l’attention bénéficient tous deux du fait que les outils irrelevants restent hors ligne jusqu’à ce qu’une compétence les active.

Les compétences peuvent également coder des règles de contrôle

Une description d’outil peut indiquer « créer un remboursement ». Une compétence peut exiger de vérifier la commande, d’examiner les politiques en vigueur, de confirmer les montants et de solliciter une approbation lorsque le montant dépasse un certain seuil avant que l’outil de remboursement ne s’exécute. Cela a des conséquences importantes : suppressions, remboursements, envois par e-mail, modifications en production, déploiements, changements de compte. Un accès sans règles est incomplet. Les mécanismes de contrôle doivent être intégrés au flux de travail, et non seulement présents dans une wiki de politiques lointaine que le modèle ne voit jamais.

MCP et compétences ne sont pas des concurrents

La configuration probable est compétences + MCP, et non compétences contre MCP. Il s’agit de couches différentes :

Agent
  ↓
Skill
  ↓
MCP
  ↓
Tools / APIs / Systems

La compétence décrit le flux de travail ; MCP standardise l’interface ; les systèmes sous-jacents effectuent le travail. L’architecture est encore en évolution et mérite d’être suivie à mesure que les écosystèmes se développent. Les débats qui présentent ce choix comme exclusif négligent leur complémentarité.

Le changement plus important

Les agents qui appellent des API ne sont pas une nouveauté. Le changement réside dans la découverte dynamique et la composition orientées vers des objectifs. MCP vise le problème de la connectivité ; les Skills visent le problème de l’exécution. À mesure que les agents se développent, il devient tout aussi important d’apprendre quand, pourquoi et comment utiliser des outils que de connecter davantage d’extrémités. Une connectivité sans connaissances en exécution entraîne des erreurs graves ; des connaissances en exécution sans connectivité ne permettent pas d’accéder aux systèmes réels.

Mettre cela en pratique

Les solutions développées en interne nécessitent encore des mécanismes d’authentification, d’hébergement, de tests, de surveillance, de gestion des versions, de suivi de l’utilisation et de gestion des changements de protocole. Les plateformes gérées qui transforment les spécifications OpenAPI en serveurs MCP, en fournissant des outils, des ressources, des prompts et des compétences — ainsi que des fonctionnalités d’analyse et une inscription dans un registre — peuvent gérer tout ce code générique afin que les équipes de développement se concentrent sur le comportement des agents. Quel que soit l’hébergeur, le slogan reste le même : MCP donne aux agents des mains ; les compétences leur apprennent à s’en servir. Commencez par associer une compétence pour un flux de travail à haut risque à un petit ensemble d’outils, mesurez le taux d’utilisation d’outils inadaptés, puis élargissez progressivement la couverture.

Liste de vérification pour l’intégration des compétences plutôt que des simples ensembles d’outils

1. Inventoriez les outils MCP et classez leur niveau de risque en termes d’effets secondaires (lecture, écriture, implications financières, irréversibilité).
2. Rédigez une compétence pour le flux de travail de support ou de facturation le plus important avant de dévoiler l’ensemble du catalogue.

Exiger des étapes de confirmation humaine au sein de la compétence pour les actions irréversibles dépassant les seuils définis.

Mesurer le taux d’utilisation d’outils inappropriés ainsi que les boucles de tentative pendant deux semaines ; ne pas élargir l’ensemble d’outils tant que ces indicateurs ne se stabilisent pas.

Gérer les versions des compétences comme des API : journal des modifications, période de dépréciation, et fichiers de test qui échouent aux tests d’intégration lorsque le flux de travail s’éloigne des outils prévus.

Ces étapes permettent de maintenir la transparence de la couche expérimentale des compétences sans attendre l’établissement d’une norme définitive.