MCP, Skills, Tools, Subagents : quelles différences, et que devient la stack agents IA en 2026 ?

En bref : Tools, MCP, Skills et Subagents ne sont pas quatre noms de produits interchangeables — ce sont quatre couches distinctes de la pile agent 2026. Les Tools sont les contrats appelables que voit le modèle (nom + JSON Schema). MCP est le protocole de découverte et d’invocation entre un Host et des processus d’outils externes. Les Skills sont des playbooks procéduraux chargés à la demande (comment faire le travail). Les Subagents sont des agents délégués avec leur propre contexte. Les fusionner en un seul buzzword, c’est déboguer la mauvaise couche.

Rédigé au 11 septembre 2026. Nous avons déjà couvert ce qu’est MCP, le flux de données JSON des agents et JSON Schema comme contrat. Ce texte répond seulement à : ce que possède chaque couche, comment elles s’empilent, et où converge la pile 2026.

Quatre couches en un coup d’œil

Quand on dit « ajouter un outil à l’agent », on vise souvent quatre choses différentes. Faites correspondre la phrase à ce tableau :

Une phrase : Tools = « ce qui peut être appelé » ; MCP = « d’où viennent les outils » ; Skills = « comment ce travail se fait » ; Subagents = « qui le fait, dans quel contexte ». JSON Schema traverse Tools et MCP ; Skills et Subagents gouvernent surtout prompts, politique et frontières de session.

Tools : le contrat d’appel devant le modèle

Un Tool (ou Function) est la plus petite unité appelable que voit le modèle. Les noms varient selon les fournisseurs — OpenAI Tools / Function Calling, Anthropic Tool Use, Gemini Function Declarations — mais la forme est la même : vous déclarez des tools ; le modèle renvoie des tool_calls structurés ; le Host les exécute et réécrit les résultats dans le chat.

Une définition d’outil ressemble en général à ceci :

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

Ce qui contraint vraiment le comportement, c’est JSON Schema : noms de champs, types, required, additionalProperties. Les modèles peuvent changer ; le Schema ne doit pas dériver avec eux. Voir pourquoi Tool Calling dépend de JSON Schema pour la discipline de validation. Ici, le point est simple : un blurb d’outil en langage naturel sans Schema n’est plus un contrat de production en 2026.

La frontière de la couche Tools est nette : elle ne décide pas si l’implémentation tourne in-process ou à distance, et elle ne décide pas comment découper un travail multi-étapes. Cela appartient à MCP et à Skills / Subagents.

MCP : la prise d’outils inter-processus

MCP (Model Context Protocol) répond à comment outils et contexte sont découverts et invoqués hors du processus Host. Les messages sont JSON-RPC 2.0 ; méthodes courantes : tools/list, tools/call, plus Resources / Prompts. Un MCP Client dans le Host (Cursor, VS Code, Claude Desktop, …) se connecte à un MCP Server et traduit les outils exposés en tableau Tools que le modèle comprend.

La pile correcte est :

1. Le MCP Server décrit chaque tool avec inputSchema (toujours JSON Schema) ;
2. Le Host appelle tools/list et mappe vers les déclarations Tools du modèle ;
3. Le modèle émet des tool_calls ;
4. Le Host envoie tools/call au Server et réécrit result dans le dialogue.

Appeler MCP « un autre Function Calling » est le contresens le plus fréquent de 2025–2026. Function Calling est à la frontière de l’API modèle ; MCP est à la frontière Host ↔ Server. La spécification actuelle est 2026-07-28 : pas de handshake de session ; les requêtes portent _meta. Détails : guide MCP et guide de migration.

Quand vous n’avez pas besoin de MCP : un processus, outils câblés dans le Host, pas de réutilisation cross-app — Tool Calling suffit. Quand oui : réutiliser le même Server entre IDEs / bureaux, isolation de processus, découverte dynamique d’outils.

Skills : playbooks how-to réutilisables

Un Skill n’est pas un autre tool — c’est une connaissance procédurale que l’agent peut charger à la demande : quand activer, quelles étapes, quoi vérifier, quels outils autoriser. En ingénierie, souvent un SKILL.md de dépôt (ou un pack de règles équivalent) : titre, conditions de déclenchement, checklist, interdits, chemins de scripts liés.

Face à Tools / MCP :

En 2026, les agents IDE traitent les Skills comme citoyens de premier rang : tâches courtes via built-ins ; flux longs, normes d’équipe et playbooks ops vivent dans les Skills pour ne pas coller tout le manuel dans le system prompt à chaque fois. Un Skill peut orienter quels Tools appeler et imposer des gates du type « valider le JSON avant submit » — mais ce n’est en général pas une méthode JSON-RPC.

Confusion fréquente : un script shell empaqueté appelé à la fois Skill et Tool. Règle simple — si le modèle l’appelle une fois via Schema et obtient un résultat structuré, c’est un Tool ; si un document dit à l’agent « suis ces cinq étapes, appelle des outils au besoin », c’est un Skill.

Subagents : délégation avec contexte isolé

Un Subagent est une session enfant à laquelle le parent délègue : en général sa propre fenêtre de contexte, un system prompt plus étroit, une allowlist d’outils plus stricte, et un résumé renvoyé au parent. Il n’ajoute pas « une fonction de plus » ; il combat la pollution de contexte et permet l’exploration parallèle.

Usages typiques :

• Récupération isolée — l’enfant fouille le dépôt ou les logs ; le parent ne garde que la conclusion.
• Travail parallèle — changements frontend, tests et traduction de copy tournent sans se battre pour un seul contexte.
• Rôles étroits — revue sécurité, exploration de code, diagnostic CI ont chacun leur prompt et leurs outils.

En pratique, un Subagent est souvent exposé au parent comme un Tool spécial (ex. Task / spawn_agent) : les arguments sont la description et le type de tâche ; le retour est la réponse finale de l’enfant. Cela ne veut pas dire Subagent = Tool. Le Tool est la surface d’appel ; le Subagent est une autre boucle de raisonnement stateful.

Face aux Skills : un Skill dit « comment » ; un Subagent décide « ouvrir une autre session pour le faire ». Un Skill peut exiger « un triage complexe doit démarrer le Subagent CI » ; ce Subagent charge ensuite ses propres Skills et Tools.

Comment les quatre couches s’empilent

Une tâche réelle utilise souvent les quatre. Exemple : « écrire un billet de blog et déployer » (illustratif, pas le protocole privé de ce site) :

1. Le parent charge un Skill — « checklist de publication blog » : corps, locales, sitemap, IndexNow.
2. Le parent appelle un Subagent pour explorer les templates d’articles historiques afin que des dizaines de fichiers HTML n’entrent jamais dans le contexte principal.
3. La session principale édite le frontend via Tools (lecture/écriture de fichiers, shell) ; si les outils vivent hors processus, découverte et appels passent par MCP.
4. Dès qu’apparaissent des paramètres structurés, JSON Schema fixe encore les champs — surtout pour tout ce qui quitte la machine.

Flux de données en une ligne :

User → Host / parent agent
      → Skills (pick the workflow)
      → Subagents (optional delegation)
      → Tool declarations (for the model)
      → optional MCP Client ↔ MCP Server
      → results written back into the dialogue

Aide-mémoire de debug : le modèle appelle le mauvais outil → Tools / Schema ; le processus d’outil ne se connecte pas → MCP ; des étapes sont sautées → Skill ; le contexte explose ou se contamine → Subagent.

Ce qui change dans la pile agent 2026

Par rapport au « fourrer des fonctions dans le prompt » de 2024, 2026 se condense en cinq glissements :

Un autre fil est la fusion des sorties structurées avec les arguments d’outils : JSON métier, arguments d’outils et MCP inputSchema partagent la même discipline Schema. Voir ce qu’est le structured output et la comparaison OpenAI vs Gemini.

Côté produit, les agents IDE ne sont plus seulement « chat + autocomplete » : la pile par défaut inclut tool calling, connecteurs MCP, un répertoire Skills et des subagents spawnables. Pour les builders, cela signifie livrer plus qu’une API — outils découvrables (MCP/Tools) + workflows suivables (Skills) + rôles déléguables au besoin (Subagents).

Quoi choisir et écrire maintenant

• Écrivez le Schema avant d’exposer le tool. Mettez additionalProperties: false, remplissez required ; validez des arguments d’exemple dans le navigateur avec les outils de ce site.
• Emballez un MCP Server seulement si les outils doivent être réutilisés entre apps. Un script unique embarqué dans un Host n’a pas besoin de MCP.
• Encodez les workflows d’équipe répétés en Skills. Publish, migration, triage, revue sécurité — si les étapes sont stables, arrêtez de compter sur « penser à rappeler au modèle ».
• Découpez un Subagent quand le contexte s’allonge. Préférez déléguer le travail exploratoire, en lecture seule, à fort bruit ; gardez décisions et patches finaux chez le parent.
• Ne remplacez pas Schema par un Skill, ni MCP par un Subagent. Processus ≠ contrat ≠ transport. Les mélanger produit « la doc dit de valider » alors que la prod ne lance jamais le check.

Pour les contrôles JSON locaux, enregistrez inputSchema, des échantillons d’arguments du modèle et des résultats MCP tools/call, puis utilisez le validateur JSON et le JSON Diff. Rien ne quitte le navigateur — le même réflexe privacy on-device-first.

FAQ

Résumé

Tools définissent ce que le modèle peut appeler ; MCP définit comment les outils sont découverts et invoqués depuis des processus externes ; Skills définissent comment le travail est fait selon le playbook ; Subagents définissent comment le contexte est isolé et délégué. La pile agent 2026 converge de « une boîte de chat + des fonctions ad hoc » vers ces quatre couches plus une ceinture de contrat JSON Schema.

Faites croître la pile de l’intérieur vers l’extérieur. Schema et Tools d’abord ; puis MCP, Skills ou Subagents sous la pression de la réutilisation, du process ou du contexte. Validez les échantillons localement avant de shipper — les modèles peuvent changer ; les noms de champs et required ne devraient pas.