Qu’est-ce qu’un AI Agent ? Guide 2026 : fonctionnement, tool calling, function calling et JSON

Qu’est-ce qu’un AI Agent : chat et workflows

La définition minimale tient en trois points : un objectif (ce que l’utilisateur veut finir), une perception (contexte et reçus d’outils), une action (quel outil, quels arguments, ou la réponse finale). Le modèle choisit l’action à chaque pas ; le runtime exécute et réécrit l’observation. Pas de boucle, pas d’outils, pas de forme d’arguments vérifiable : ce n’est que du chat.

L’écart avec un chatbot n’est pas la marque, c’est la condition d’arrêt. Le chat peut s’arrêter après un tour. Un agent ne devrait pas déclarer la tâche finie avant les résultats d’outils — il peut chercher des factures, résumer, puis demander confirmation. L’écart avec un workflow classique, c’est qui trace les arêtes : les hops n8n / Temporal sont câblés par des humains ; le hop suivant d’un agent est choisi d’après l’observation JSON courante. Le workflow est prévisible et rejouable ; l’agent est souple et fait de « mauvais arguments » une panne de premier rang.

Formes 2026 : agents de code (fichiers, tests, rustines), agents support / ops (commandes, tickets), orchestration multi-agents (un planificateur délègue à des spécialistes). Le contrat est le même : frontières en JSON Schema ; arguments et results parseables. Apple peut exposer la même fonction aux App Intents et aux outils modèle — voir Apple AI Agent et JSON.

Fonctionnement 2026 : observer → décider → appeler → observer

Ôtez la vidéo démo : une boucle typique a cinq pas.

1. L’objectif utilisateur entre dans le contexte (langage naturel + contraintes système optionnelles).
2. Le runtime injecte le catalogue : name, description, JSON Schema (parameters / inputSchema).
3. Le modèle renvoie des tool_calls (fonction + arguments) ou un texte / Structured Output final.
4. Le runtime parse les arguments, exécute une fonction locale, HTTP ou MCP tools/call, et réécrit le result JSON dans les messages.
5. Le modèle relit le résultat et choisit l’outil suivant ou s’arrête. maxSteps, annulation ou échec Schema arrêtent aussi.

La forme de la boucle peut être de la config, pas de la magie de framework. Le JSON ci-dessous ne décrit que hops et arrêts — les champs métier vivent sur le Schema de chaque outil.

{
  "loop": "agent",
  "maxSteps": 8,
  "stopWhen": ["final_answer", "max_steps", "user_cancel", "schema_fail"],
  "hops": [
    { "kind": "model", "emits": "tool_calls | text" },
    { "kind": "runtime", "emits": "tool_result JSON" },
    { "kind": "model", "emits": "next_tool | final JSON" }
  ]
}

Les pannes se concentrent aux pas 3→4 : arguments chaîne traités comme objet, nombres en chaînes, required manquant, nom d’outil décalé d’un cache. Un modèle « plus malin » ne répare pas la dérive de contrat. Le MCP sans état attache des métadonnées par requête ; la forme dépend toujours du Schema fourni au modèle.

Tool calling et function calling : deux noms, un mécanisme

Côté ingénierie, c’est le même mécanisme : le modèle ne touche pas la base ; il émet une demande structurée « appelez cette fonction avec ces arguments », le runtime l’exécute. Les noms produit ont bougé de 2023 à 2026 :

OpenAI a ensuite plié functions dans tools et ajouté strict. Anthropic dit tool_use / input_schema. Gemini, function declarations. MCP, JSON-RPC tools/call. Les noms changent ; arguments reste un objet JSON. « Function calling est obsolète » est rarement une bonne raison de migrer — ce sont les anciens noms de champs qui ont vieilli, pas le mécanisme.

La même recherche de factures en outil OpenAI strict. Sous strict, chaque property doit être dans required, sinon le modèle peut omettre légalement un champ que vous croyiez par défaut :

{
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "description": "Search invoices by date range and status",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "startDate": { "type": "string", "format": "date" },
        "endDate": { "type": "string", "format": "date" },
        "status": {
          "type": "string",
          "enum": ["draft", "sent", "paid", "void"]
        }
      },
      "required": ["startDate", "endDate", "status"],
      "additionalProperties": false
    }
  }
}

Quand le modèle appelle, un tool_calls typique ressemble à ceci. arguments est encore une chaîne : parser, puis valider. Un JSON.parse raté n’est pas automatiquement « le modèle est cassé » — séparez syntaxe et Schema. Taxonomie : guide des erreurs JSON IA.

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "arguments": "{\"startDate\":\"2026-01-01\",\"endDate\":\"2026-01-31\",\"status\":\"paid\"}"
  }
}

Pourquoi JSON est le langage de contrat de l’agent

Une pipeline agent porte au moins trois JSON qui devraient venir d’un même Schema canonique :

1. Définition d’outil : name / description / parameters (ou MCP inputSchema).
2. Arguments modèle : clés choisies, souvent en chaîne dans tool_calls.
3. Résultat d’outil : ok / result ou enveloppe d’erreur, pour le hop suivant.

Un quatrième est optionnel : Structured Output de la réponse finale. Ce fichier décrit la réponse à l’utilisateur ou au système aval — pas ce dont searchInvoices a besoin. Même syntaxe, autre sémantique ; fichiers et versions séparés. Voir tutoriel Structured Output.

Après un outil réussi, renvoyez une enveloppe stable au lieu de jeter le HTTP brut au modèle. Le result ci-dessous n’expose que les champs métier ; le brut va aux logs. Une forme stable rend retries et synthèses prévisibles :

{
  "toolCallId": "call_8f3a",
  "name": "searchInvoices",
  "ok": true,
  "result": {
    "count": 2,
    "items": [
      { "id": "INV-1042", "total": 1280.5, "currency": "USD" },
      { "id": "INV-1048", "total": 640.0, "currency": "USD" }
    ]
  }
}

Piles 2026 : OpenAI, Anthropic, Gemini, MCP

Pas de Schema universel, mais les structures de tool calling convergent : arguments est un objet JSON ; le contrat est un sous-ensemble JSON Schema.

MCP est découverte et transport, pas un système de types. inputSchema déclare la forme ; le serveur parse et valide encore. Mapping et un Schema sur trois surfaces : MCP et JSON Schema. Les passages multi-agents passent par A2A message/send ; les skills portent aussi un Schema — agent vers agent, pas modèle vers outil. Comparer A2A vs MCP.

Le MCP sans état s’étend mieux une fois la session hors protocole ; il ne répare pas les arguments. Un cache tools/list périmé écrit la mauvaise forme. Détails : guide Stateless MCP.

Validation terrain et JSONVue

Chaque hop : parse → Schema → règles métier. Un modèle habile ne remplace pas ces trois pas.

1. Chaîne arguments : JSON.parse ; en échec, journaliser raw + id et renvoyer une enveloppe retryable.
2. Valider contre parameters / inputSchema (Draft 2020-12) ; émettre path et keyword.
3. Porte métier : plage de dates, enum vs droits, clés étrangères. Puis seulement l’API aval.

Alignez trois blobs : arguments modèle, body envoyé à MCP ou HTTP, objet réellement utilisé. Un écart est presque toujours l’adaptateur. Dans le navigateur : formateur JSON pour le parse ; Validateur JSON Schema pour arguments vs fichier Schema ; JSON Diff pour arguments vs body aval. Partagez les fixtures valid / missing-field / wrong-enum en CI et au debug manuel.

À lire : MCP et JSON Schema, Structured Output, erreurs JSON IA, A2A vs MCP.

FAQ

Synthèse et suite

Un agent IA 2026 : le modèle choisit des actions en boucle, le runtime exécute les outils, JSON Schema décrit chaque hop. Tool calling et function calling sont des noms produit d’un même mécanisme. MCP, A2A et Structured Output gouvernent des hops différents — un seul fichier ne doit pas tout couvrir.

Ensuite : listez les trois JSON (définition, arguments, result) et vérifiez qu’ils partagent un Schema ; rejouez valid / champ manquant / mauvais enum dans JSONVue. Protocole dans l’article MCP ; forme de réponse dans Structured Output ; couches d’échec dans le guide d’erreurs JSON.