Agent IA

Pourquoi les agents IA ont besoin de JSON : de Function Calling à MCP

Ordinateur portable affichant un éditeur de code et des journaux terminal, mains sur le clavier
Un bureau multi-écrans : les appels d’outils d’un agent aboutissent toujours dans un runtime réel.

Symptôme : l’agent discute, mais les arguments d’outil échouent à la validation, un nouvel essai double une commande, ou un serveur MCP tourne sans aucun outil visible.
Correction la plus rapide : traiter JSON comme le seul contrat entre le modèle et les outils : contraindre les entrées avec JSON Schema, renvoyer des résultats à champs stables, et n’utiliser MCP que pour rendre ce contrat découvrable entre processus.

Ce texte s’adresse aux développeurs, ingénieurs plateforme et architectes qui relient un modèle de langage à de vrais systèmes. La question utile n’est pas un mot à la mode, mais le chemin du même objet JSON dans Function Calling, Tool Calling et MCP, et le saut qui casse la chaîne.

Si vous choisissez encore un framework, lisez d’abord Comment choisir un framework d’agent IA. Pour l’isolation à l’exécution, voir AI Sandbox, Docker et système de fichiers virtuel.

Pourquoi un agent IA ne peut pas se passer de JSON

Les modèles produisent du langage. Les systèmes de production n’acceptent que des commandes structurées. Dès qu’un agent doit consulter un stock, modifier un ticket, lancer des tests ou piloter un navigateur, l’intention doit devenir une donnée validable, refusée et auditable. JSON se loge dans cette jointure : lisible, parseable, déjà présent dans HTTP, journaux, files et bases.

L’avantage réel est la vérifiabilité. La prose ne dit pas à une passerelle que order_id est une chaîne, amount un nombre positif et currency une énumération. JSON Schema le fait. Le guide Function Calling d’OpenAI définit les paramètres comme JSON Schema pour pousser l’échantillonnage vers une structure légale. Consulter le guide Function Calling OpenAI

Types, champs requis, énumérations et additionalProperties ne sont pas de la théorie. Ils forment la première barrière contre les champs inventés, les chaînes forcées dans des nombres et la clé d’idempotence oubliée. Consulter JSON Schema

  • Conversation : « passe la commande de l’entrepôt de Shanghai en express ».
  • Contrat : {"name":"update_order","arguments":{"order_id":"A938","priority":"expedited"}}.
  • Exécution : schéma, droits, API métier, JSON renvoyé au modèle.

Sans couche contrat, l’agent est une fenêtre de chat. Avec elle, il peut devenir un exécuteur gouverné.

⚠️ Règle de terrain : si les arguments sortent encore d’un « texte libre + regex », vous n’avez pas de protocole, seulement de la chance de prompt. Figez le schéma avant d’orchestrer.

Function Calling : le modèle apprend à remplir un formulaire

Function Calling signifie que le modèle peut, avant de répondre, choisir une fonction déclarée et émettre des arguments conformes au schéma. Le chemin heureux a cinq étapes, chacune peut perdre un champ.

  1. Enregistrer tools : name, description, parameters en JSON Schema.
  2. Décider d’appeler ou de répondre.
  3. Remplir tool_calls, arguments en chaîne JSON ou objet.
  4. Exécuter : parse, validation, autorisation, système réel.
  5. Réinjecter le résultat pour la réponse utilisateur.

Les descriptions sont des signaux de routage. « Météo » concurrencera « logistique ». « N’appeler que si un nom de ville est fourni ; jamais pour le climat historique » réduit les faux déclenchements. Les descriptions de champs dans le schéma sont aussi des prompts : « order_id est l’identifiant métier, pas l’intent de paiement » appartient au schéma.

Le mode strict et Structured Outputs transforment « ça ressemble à du JSON » en « ça respecte le schéma ». Le JSON mode ne promet que des accolades parsables. Valide pour le schéma n’est pas valide pour le métier. Montants négatifs, entrepôts inconnus, commandes hors droits doivent échouer dans votre code.

Un contrat minimal exécutable

Le schéma ci-dessous fige les énumérations et une clé d’idempotence. Le modèle peut refuser d’appeler, mais ne peut ni inventer de champs d’entrepôt ni omettre idempotency_key.

function schema (extrait)
{
  "type": "function",
  "name": "update_shipment",
  "description": "N’appeler que si l’utilisateur demande explicitement de changer la priorité de livraison.",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {"type": "string", "description": "Identifiant métier de commande"},
      "priority": {"type": "string", "enum": ["standard", "expedited"]},
      "idempotency_key": {"type": "string"}
    },
    "required": ["order_id", "priority", "idempotency_key"],
    "additionalProperties": false
  }
}

Ordre d’exécution : parse JSON → schéma → droits → table d’idempotence → API métier → {"ok":true,"shipment_id":"..."} ou {"ok":false,"error":"not_found"}. Jamais de pile ni de secret dans le tool result.

Tool Calling : d’une fonction à une surface d’outils

Les équipes ont vite eu besoin de plus que leurs fonctions : recherche, interpréteur de code, navigateur, usage ordinateur, fichiers. Les API sont passées de function_call à une surface unifiée tools / Tool Calling. Le nom a changé, le contrat JSON non.

Anthropic parle de Tool use et décrit input_schema en JSON Schema. Le modèle émet un bloc tool_use ; l’application répond par tool_result. Consulter la documentation Tool use Anthropic

  • Appels parallèles : lectures en parallèle, verrou de stock puis paiement en série.
  • Approbation : outils à risque renvoyant un JSON pending.
  • Observabilité : traces avec nom, résumé d’arguments, latence, code d’erreur.

Le modèle peut choisir le bon outil et cacher une charge dangereuse dans une chaîne. Le schéma attrape les types, pas la sémantique. Les outils dangereux exigent listes blanches, timeouts et bac à sable.

MCP : rendre le contrat JSON enfichable

Function et Tool Calling décrivent la conversation dans une requête API. MCP décrit la découverte, la réutilisation par plusieurs hôtes et l’exécution dans un processus séparé. La spécification utilise JSON-RPC 2.0. Consulter la spécification MCP

  1. L’hôte démarre en client MCP.
  2. Connexion stdio, SSE ou Streamable HTTP.
  3. initialize négocie version et capacités.
  4. tools/list renvoie encore un inputSchema JSON Schema.
  5. Le modèle reste en Tool Calling ; le client envoie tools/call avec du JSON.
  6. Le contenu serveur redevient tool result.

MCP ne remplace pas JSON. Il transforme un tableau tools codé en dur en catalogue d’exécution. Le même Git, la même automatisation navigateur, la même API tickets peuvent servir Cursor, Claude Desktop et votre agent.

« MCP installé, aucun outil » est presque toujours un bug de contrat : initialize, liste vide, schéma incompatible avec le mode strict, champ required manquant, ou prose à la place d’une erreur JSON-RPC.

Flux bout en bout : une phrase jusqu’à MCP

  1. L’utilisateur saisit du langage naturel.
  2. Le runtime assemble messages, outils locaux et tools/list MCP.
  3. Le modèle émet des arguments JSON.
  4. Routage : fonction locale ou JSON-RPC tools/call.
  5. Le JSON de résultat revient dans le dialogue.
  6. Nouvel appel, question, ou réponse finale.

Une frontière est oubliée : le modèle ne détient pas votre connexion base. Il n’émet que du JSON. Qui parse, quelle machine exécute, SSH/VNC, réseau sortant : politique de runtime. Un agent sur un Mac cloud parle le même protocole, avec un autre plan de droits.

CoucheRôle de JSONOù bloquer
Function CallingArguments d’une requêteSchéma, strict, contrôles métier
Tool CallingJournal d’appels sur une surface communeParallélisme, approbation, traces
MCPDécouverte inter-processusTransport, auth, erreurs list/call

Ignorez les noms produits. Si les outils ne servent qu’une application, Function/Tool Calling suffisent. S’ils doivent être partagés, un serveur MCP se justifie. Sans schéma, MCP déplace seulement le désordre.

Quand JSON casse, toute la chaîne agent casse

  • JSON invalide : strict off, « explique d’abord », barrière Markdown. Canal d’outil structuré uniquement.
  • Parse OK, schéma KO : required, enum, propriétés en trop. Renvoyer l’erreur, plafonner les essais.
  • Schéma OK, métier KO : commande inconnue, stock, droits. Code d’erreur stable, pas une page 500.
  • Retry en double écriture : timeout puis second appel. idempotency_key et déduplication.
  • list et call divergent : nom ou schéma changé après rechargement. Versionner le hash, ré-initialize.
  • Secrets dans les logs JSON : arguments complets dans une trace partagée. Noms de champs et hachages, masquer jetons et données perso.

Transformez timeout, échec de schéma et refus de droits en un seul scénario d’acceptation. Si l’agent boucle ou mute les arguments au hasard, il ne doit pas toucher paiement, expédition ou base de production.

Checklist contrat JSON avant mise en production

  • [ ] Chaque outil a name, description, JSON Schema, additionalProperties: false.
  • [ ] Champs à risque en enum / format / longueur max.
  • [ ] Écritures avec clé d’idempotence ; timeout et retry dans le runtime.
  • [ ] Résultats ok / error / data, jamais de pile brute.
  • [ ] Appels parallèles groupés par effet de bord ; paiement, e-mail, suppression en série.
  • [ ] MCP initialize / list / call avec timeout, auth, codes d’erreur.
  • [ ] Les hôtes rechargent le schéma après changement de catalogue.
  • [ ] Les traces reconstruisent la chaîne, pas les secrets.
  • [ ] Une invite figée atteint le même nom d’outil et le même ensemble de champs requis.

Ensuite seulement, graphes multi-agents ou workflows lourds. Un protocole instable ne fait que copier plus vite du JSON cassé.

FAQ

Pourquoi ne pas laisser le programme parser le langage naturel ?

Pas de champs requis ni de types. « Rends ça urgent » ne se mappe pas de façon stable à une énumération. JSON Schema transforme le parsing en validation.

Tool Calling diffère-t-il vraiment de Function Calling ?

Pour l’application, le cœur est identique : formulaire JSON, votre code exécute. Tool Calling élargit la surface : outils d’hôte, appels parallèles, canal de résultat unifié. À la migration, alignez d’abord schémas et rôles de messages.

Quand MCP plutôt qu’un tableau tools en dur ?

Quand les mêmes outils doivent servir plusieurs hôtes, s’isoler dans un processus, ou être publiés par une autre équipe. Si l’outil vit et meurt avec un service interne, Function/Tool Calling reste plus simple.

JSON parfois invalide : réessayer ou changer de protocole ?

Activez la sortie structurée stricte et arrêtez d’extraire les arguments de la prose. Si le taux reste élevé, inspectez la profondeur du schéma, les descriptions contradictoires et le nombre d’outils. MCP ne change pas le fait que les arguments restent du JSON.

Sur un portable partagé, les tests de schéma cassent dès que l’environnement dérive, et les processus MCP se battent pour les ports de développement. Un hôte Mac bare-metal Kvmjet conserve une image macOS fixe pour reproduire la même panne Tool Calling ou MCP en SSH ou VNC. La facturation publique va du jour au trimestre, assez pour stabiliser le contrat JSON avant un engagement long.

Emportez la checklist vers le centre d’aide Kvmjet, vérifiez le fonctionnement continu, l’isolation des droits et l’accès distant, puis décidez si le serveur MCP reste sur le portable, en baie ou sur un Mac cloud.

Exécuter Tool Calling et MCP sur un Mac stable

Schéma, idempotence et serveur MCP exigent une machine reproductible. Un portable partagé fait dériver répertoires et ports.

Les Mac M4 bare-metal Kvmjet offrent macOS réel, bande passante dédiée et SSH/VNC pour rejouer le même tools/call en échec.

Voir les offres →

Offre spéciale