Tutoriel

Pourquoi les agents IA passent de Tool Calling à Skills + Plugins : changement d’architecture 2026 et flux JSON

Tool Calling n’est pas obsolète. Ce qui l’est, c’est de fourrer tous les schémas d’outils et tout le manuel dans une seule requête.

Nous avons déjà écrit ce qu’est la boucle agent, comment ce hop MCP valide les arguments et comment choisir Skills / MCP / Plugin. On ne les refait pas. En revue, la phrase est autre : « On a déjà Tool Calling — pourquoi Skills et Plugins ? » C’est de l’architecture, pas du remplissage de champs. Les raisons sont concrètes. Trop d’outils, et la table entière de schémas mange la fenêtre. Processus trop long, et la SOP du prompt système est coupée. On change de client, le brief et la main divergent. Agent Skills réduit la découverte à name + description par divulgation progressive. Agent Plugins 1.0.0 spécifie la boîte, pas l’appel. Google le dit aussi : un skill, un MCP, un client n’ont pas besoin de boîte. Ce texte pose l’ancienne requête à côté de la nouvelle trace en JSON.

L’appel tient ; la surface de découverte non

Tool Calling reste le hop où le modèle choisit un nom de fonction et des arguments. Personne ne l’a retiré en 2026. Ce qui a disparu, c’est une habitude d’emballage : au démarrage, verser cinquante inputSchema dans tools[], puis coller « d’abord le projet, puis la facturation, le résumé hebdo comme la finance » dans system. Dix outils, ça va. Un troisième domaine plus tard, la requête elle-même devient un JSON géant que personne ne diff. Un mauvais outil ressemble à une hallucination. La racine habituelle : surface trop large, brief coupé. Le hop d’appel n’est pas cassé. Vous lui avez demandé de faire aussi la découverte.

La fenêtre n’est que le premier coup. Le deuxième est le changement. La finance réordonne les sections, et vous éditez le prompt système, un wiki interne et trois collages d’IDE. Sans SKILL.md diffable, le changement n’entre jamais dans une PR. Le troisième coup est inter-clients : dialecte MCP de Cursor, répertoire de skills de Claude Code, layout plugin d’Antigravity — trois enveloppes. Les outils sont les mêmes ; les boîtes divergent d’abord. La douleur n’est pas l’enveloppe tools/call. C’est la couche dehors : quand s’en servir, et quoi emmener.

« Aller vers Skills + Plugins » n’est donc pas un échange de slogans. On tire découverte et emballage hors de la requête d’appel. Le hop d’appel reste — voir MCP et JSON Schema. La boucle agent reste — voir le texte de définition. Aujourd’hui on regarde seulement comment le JSON circule après la scission. Ce que le client tient après install, c’est le Manifeste Plugin en pratique — cinq hops. Ici : pourquoi ces cinq hops sont apparus.

Cette couche Ancienne habitude Habitude 2026
Quand utiliser un processusUn long paragraphe dans le prompt systèmedescription de skill (~100 tokens)
Quelles mains existentLe tools[] entier dans la requêtetools/list après install Plugin ou connexion MCP
L’appel réelArguments modèle → runtimeInchangé : toujours parse + Schema

Pas un remplacement : la couche d’appel reste, une couche s’ajoute

Appeler Skills « le prochain Tool Calling » et vous déboguerez la mauvaise couche dans les logs. Un Skill n’a pas de tools/call. C’est un brief. Le démarrage n’injecte que des métadonnées. Le modèle recoupe un déclencheur, puis lit le corps et scripts/. MCP est la main. Un Plugin est un répertoire. Les trois siègent au-dessus de l’appel ; ils ne remplacent pas le hop arguments. Une trace honnête montre encore un tools/call légal. S’il manque, la découverte a bloqué le modèle — la couche d’appel n’a pas été effacée.

La divulgation progressive est le cœur de la spec Agent Skills, pas un adjectif marketing. name max 64, description max 1024, troisième personne, quoi et quand. Un nom de code interne ou un slogan à la première personne annule la surface — les outils sont là, le modèle ne les choisit jamais. Charger le corps à la demande empêche le runbook et cinquante schémas de se battre pour la même fenêtre. Les scripts restent argv, pas des outils de premier rang issus de tools/list. Un JSON d’entrée stable, c’est encore MCP.

Un Plugin est plus mince. Il n’inline pas une liste d’outils et ne met pas une SOP en tête de plugin.json. La boîte dit si ce brief et cette main sont là. L’appel dit si les arguments de ce hop sont légaux. Deux JSON, deux métiers. Les quatre questions sont dans l’article de choix ; les cinq hops après install dans l’article Manifeste. Aujourd’hui on dessine seulement comment le flux est passé de plat à épais.

Ancien flux : un énorme tableau tools

L’ancienne requête ressemble à un menu plus le règlement. Chaque entrée tools porte un inputSchema complet. system tient le processus. Une phrase utilisateur, et le modèle commande sur tout le menu. Un menu court est rapide. Quand le menu devient factures + notes + IAM + deploy + doc, commander échoue d’abord : outils proches se marchent dessus, la SOP est coupée après « ne commitez jamais de secrets… ». Le ticket dit que le modèle a déraillé. Un diff dit que le corps de requête a déraillé d’abord.

Ce JSON a un coût caché : le runtime l’a assemblé, il n’entre souvent jamais dans le dépôt. Quelqu’un ajoute send_slack et aucune PR ne montre la croissance des schémas. La revue reste coincée avec ce corps énorme dans les logs. Pas de budget, pas de signal pour extraire la découverte. Une architecture plate n’est pas une faute morale. C’est une croissance sans compteur.

Ci-dessous une ancienne fixture aplatie. La prod est plus longue. Faites-la parser, puis posez un budget CI sur tools.length et les octets de requête. Dépasser le budget, ce n’est pas « encore une ligne de prompt ». C’est sortir la SOP et les schémas complets de la requête de démarrage.

{
  "era": "flat-tool-calling",
  "system": "Always check the billing project first. Never commit secrets. Write the weekly invoice summary the finance team actually reads.",
  "tools": [
    {
      "name": "query_invoices",
      "inputSchema": {
        "type": "object",
        "required": ["week"],
        "properties": {
          "week": { "type": "string", "pattern": "^[0-9]{4}-W[0-9]{2}$" },
          "status": { "type": "string", "enum": ["open", "paid", "overdue"] }
        }
      }
    },
    {
      "name": "export_csv",
      "inputSchema": {
        "type": "object",
        "required": ["week"],
        "properties": { "week": { "type": "string" } }
      }
    },
    {
      "name": "send_slack",
      "inputSchema": {
        "type": "object",
        "required": ["channel", "text"],
        "properties": {
          "channel": { "type": "string" },
          "text": { "type": "string" }
        }
      }
    }
  ]
}

Nouveau flux : métadonnées → corps → contrat d’outil

La nouvelle trace s’épaissit à la demande. Démarrage : seulement les métadonnées de skill (plus l’identité plugin si une boîte est installée). Correspondance : alors lire le corps de SKILL.md. Besoin d’une main : alors mettre l’inputSchema de ce tour, issu de tools/list, dans la fenêtre. Appel : les arguments passent encore le même contrôle de schéma. Ce qui siège à la fois passe de « menu entier + règlement entier » à « un index + le livre ouvert ». Les tokens quittent la facture de démarrage pour une facture de correspondance.

tools[] n’a pas disparu. Il a reculé. Reculer coûte une poignée de plus et une façon de plus de rater la correspondance. description faible, le modèle n’atteint jamais le hop trois ; les utilisateurs disent « on a installé un Plugin et ça ne sait toujours pas ». Bug de découverte, pas un retour de Tool Calling. L’inverse — la trace a déjà inputSchema et on verse encore le runbook dans system — c’est la nouvelle architecture qui recule. La facture fenêtre revient.

Ci-dessous la nouvelle fixture de la même tâche. Ce n’est pas un fichier de spec. C’est une trace de revue. Différenciez-la de l’ancienne requête : la SOP a quitté system pour skills[].description ; les schémas ont quitté le démarrage pour afterMatch.tools. Le contrat query_invoices de la couche d’appel reste un schéma canonique. N’inventez pas un second jeu de champs « pour la nouvelle architecture ».

{
  "era": "skills-plus-plugins",
  "startup": {
    "plugin": "invoice-ops",
    "skills": [
      {
        "name": "write-weekly-summary",
        "description": "Turn invoice query results into the weekly summary finance reads. Use when the user asks for a week-end report.",
        "loaded": "metadata"
      }
    ]
  },
  "afterMatch": {
    "skillBodyLoaded": true,
    "tools": [
      {
        "name": "query_invoices",
        "source": "mcp:invoice-tools",
        "inputSchema": {
          "type": "object",
          "required": ["week"],
          "properties": {
            "week": { "type": "string", "pattern": "^[0-9]{4}-W[0-9]{2}$" },
            "status": { "type": "string", "enum": ["open", "paid", "overdue"] }
          }
        }
      }
    ]
  }
}

Pourquoi un Plugin encore : le brief et la main doivent voyager ensemble

Ranger la SOP en Skill et l’API en MCP amincit déjà la requête. Un second client, et le layout plus le dialecte MCP recommencent à diverger. Un Plugin gagne sa place quand le brief et la main doivent voyager ensemble. Le Google Cloud Developer Plugin emballe le skill garde-fou gcloud avec le MCP Developer Knowledge pour ça — pas parce que Tool Calling était trop faible. La boîte n’exécute aucun outil. Elle empêche le chemin de découverte de forker entre Antigravity, Claude Code et Cursor.

Un client, un serveur : gardez la config MCP native. Livrer un Plugin « pour être moderne » n’est qu’un Manifeste de plus. Les questions trois et quatre de l’article de décision tiennent. Le basculement n’est pas « tout le monde passe Plugin ». C’est « couche d’appel stable ; découverte et emballage là où ça fait mal ». Pas de second client, le brief ne dépend pas de la main : s’arrêter à un Skill ou un MCP natif est une architecture 2026 correcte.

La ligne A2A encore. Comment un autre agent est trouvé, c’est une Agent Card, pas cet agent dans tools[]. L’autre explosion du Tool Calling plat : traiter un agent distant comme une fonction. Ça fait éclater la forme des arguments. La délégation horizontale n’est pas le flux du jour. Aujourd’hui : comment cet agent-ci porte moins de menu et plus d’index.

Symptôme Bouger cette couche d’abord À ne pas faire
Requête 200 Ko, 40 entrées dans toolsDécouverte : métadonnées de skill + schémas à la demandeAllonger encore le prompt système
Après changement d’IDE, brief et main ne s’accordent plusEmballage : répertoire PluginCopier encore un dialecte client
Bon outil, résumé hebdo encore fauxBrief : corps de SKILL.mdAjouter un outil format_report vide

Différencier les deux fixtures côte à côte

Au moins trois fixtures de revue : l’ancienne requête ci-dessus, la nouvelle trace, un vrai objet arguments query_invoices. Les deux premières portent « quelle couche a rendu le gras ». La troisième prouve que la couche d’appel n’a pas été réécrite — inputSchema est toujours le canonique. Copier le name du Plugin dans les arguments d’outil, ou inputSchema dans plugin.json, se voit tout de suite au diff.

Deux négatifs : une nouvelle trace aux skills vides qui affirme encore era = skills-plus-plugins ; une ancienne requête hors budget sur tools.length sans trace de scission. La première attrape un slogan sans changement de découverte. La seconde attrape « allongeons le prompt ». Aucun secret dans une fixture commitée.

Ça se fait dans le navigateur :Formateur JSONpour parser l’ancienne requête et la nouvelle trace ;Validateur JSON Schemapour inputSchema et arguments ;JSON Diffpour poser l’ancien system / tools à côté des nouveaux skills / afterMatch. Rien ne quitte la machine. Pour aller plus loin :MCP et JSON Schema, l’article de choix et les cinq hops Manifeste.

Liens : Qu’est-ce qu’un AI Agent, MCP et JSON Schema, Skills vs MCP vs Plugins, Manifeste Plugin en pratique.

FAQ

Faut-il supprimer Tool Calling ?

Non. Le modèle choisit encore un nom de fonction et des arguments ; le runtime envoie encore tools/call. Vous retirez le menu entier au démarrage, pas le hop d’appel. Si la trace n’a pas d’appel légal, voyez d’abord la découverte, puis le runtime.

Skill seul, sans Plugin — est-ce la nouvelle architecture ?

C’est la couche de découverte. La SOP a quitté le prompt système et charge à la demande ; la requête maigrit. Ce n’est pas la couche d’emballage. Un client suffit : arrêtez-vous. Un second apparaît, le brief doit voyager avec la main : alors un Plugin.

Laisser tous les schémas dans la requête de démarrage n’est-il pas plus rapide ?

Menu court, outils stables, un client — oui, et plus simple. Au-delà du budget, en nombre ou en octets, les mauvais choix d’outils mangent la latence gagnée. Posez le budget avant de croire le feeling.

Est-ce en conflit avec Programmatic Tool Calling ?

Non. Programmatic Tool Calling est de la structure sur la couche d’appel : le modèle enchaîne les outils exprès. Skills + Plugins sont découverte et emballage : quel brief lire, quelle main connecter. L’index d’abord, puis la chaîne.

À retenir et suite

En 2026, « de Tool Calling à Skills + Plugins » tient en une ligne : le hop d’appel reste ; découverte et emballage quittent la requête géante. Le modèle commande encore. Tout le menu n’est plus sur la table à l’asseoir.

Livrer dans cet ordre : budgéter tools.length et les octets de l’ancienne requête ; plier la SOP en description ; reculer les schémas complets après la correspondance ; ajouter plugin.json au second client. Poser l’ancienne requête et la nouvelle trace côte à côte dans JSONVue. La boucle : article Agent. Les arguments : article MCP. Emballer ou non : article de décision.