Développement IA

Qu'est-ce qu'un agent IA ? Guide 2026 : fonctionnement, Tool Calling, Function Calling et JSON

Environ 16 min

En 2026, chaque page produit IA écrit « Agent ». La plupart plient chatbot, modèle qui appelle des fonctions et runtime capable de finir un workflow multi-étapes en un seul mot. Cet article part de la définition : ce qu'est un agent IA, comment tourne la boucle, en quoi Tool Calling diffère de Function Calling, et pourquoi chaque couche atterrit sur JSON. À la fin, vous devez pouvoir tracer une chaîne d'appels débogable — pas un prompt plus long.

Aperçu rapide

Idée En une ligne Où atterrit le JSON
AI Agent Un runtime qui planifie, appelle des outils et passe le résultat État de workflow / handoff
Tool Calling Nom générique : le modèle veut une capacité externe tool_calls
Function Calling Implémentation dans l'API du fournisseur tools[] / arguments
JSON Seul objet stable et validable entre les étapes Schema / payload

Gardez les couches : l'agent est le runtime, Tool Calling la capacité, Function Calling le cadre API, JSON le contrat partagé.

Qu'est-ce qu'un agent IA ?

Un agent IA n'est pas « un modèle qui discute mieux ». Le modèle ne fait que générer du texte (ou un objet structuré). L'agent est le runtime qui place le modèle dans une boucle : observer l'état, planifier l'étape suivante, appeler un outil externe, digérer le résultat, puis continuer, transférer ou s'arrêter.

Un agent livrable en 2026 est en général un trio :

  • Le modèle : raisonner, choisir un outil, émettre des Structured Outputs.
  • L'hôte : parser l'intention d'appel, exécuter l'API / la base / le fichier, renvoyer le résultat, bloquer le JSON illégal.
  • Le contrat : paramètres d'outils, résultats, objets handoff, état de workflow — presque tout en JSON.

Sans hôte, le modèle ne peut que suggérer. Sans contrat, un flux multi-étapes traite un objet à moitié juste comme un fait. La frontière produit est côté hôte, pas sur la fiche modèle.

Quelle différence avec un chatbot ou un LLM nu ?

Trois étiquettes se collent sur une fonction. En production, il faut les séparer :

  • LLM nu : texte en entrée, texte en sortie. Pas d'outils, pas d'état entre étapes.
  • Chatbot : un LLM branché sur une UI de conversation. La sortie est pour un humain ; l'utilisateur relance en cas d'échec.
  • Agent IA : la sortie est exécutée par un programme. Résultats d'outils, routage et scores d'eval sont des objets, pas de la prose.

Test simple : si l'étape suivante doit être exécutée par du code — et non comprise par une personne — vous avez besoin d'un agent, pas d'un dialogue malin. L'exécution appartient à l'hôte ; le modèle ne propose que l'intention d'appel.

Comment un agent IA fonctionne-t-il en 2026 ?

La boucle reste observe → plan → act → observe. Ce qui a changé : chaque saut est typé, au lieu de « le modèle a parlé de remboursement ».

  1. Observe : message utilisateur, dernier résultat d'outil et état JSON courant dans le contexte.
  2. Plan : le modèle répond, appelle un outil, ou passe un objet à un autre agent.
  3. Act : l'hôte exécute tool_calls, ou change d'agent via le JSON de handoff.
  4. Observe again : les résultats reviennent en role: tool ; l'objet d'état est mis à jour avant le tour suivant.

L'hôte fait encore quatre choses que le modèle ne fera pas : injecter tools[], parser arguments une seconde fois, valider avec le Schema, et couper court en cas d'échec — pas « réessayer un prompt plus long ».

La pile de production a déjà convergé. L'Assistants API a été retirée le 26 août 2026 ; le nouveau code passe par Responses API + Agents SDK. prévisions DevDay 2026 décrit la même tendance en trois couches : Structured Outputs façonne l'objet, Function Calling exprime l'appel, le runtime d'agent orchestre les deux.

Ne demandez pas à l'historique de chat de « se souvenir » de l'avancement. Écrivez l'étape courante en JSON récupérable :

{
  "step": 2,
  "agent": "billing",
  "last_tool": "lookup_order",
  "state": {
    "order_id": "A-1042",
    "status": "paid",
    "amount": 99.00
  },
  "next": "create_refund"
}

Formatez ces objets localement avec formater et vérifier la syntaxe, puis JSON Diff contre la définition de la semaine dernière. Ne collez pas de réponses d'outils portant des données utilisateur ou des secrets sur un site JSON public.

Qu'est-ce que le Tool Calling ?

Tool Calling est le nom de couche capacité : au bon moment, le modèle émet un « j'ai besoin d'une capacité externe » lisible par une machine, au lieu de feindre en prose d'avoir déjà interrogé la base. Il n'est pas lié aux noms de champs d'un fournisseur.

Au moins trois implémentations 2026 s'appellent Tool Calling : Function Calling des API compatibles OpenAI, le Tool Use des fournisseurs (Anthropic et autres), et MCP avec tools/list + tools/call. MCP Tool Schema vs Function Calling a tracé la frontière : MCP fournit les outils entre hôtes ; le cadre API laisse le modèle exprimer l'intention de ce saut.

Pour un développeur, Tool Calling répond à « le modèle peut-il tendre la main ? ». Pas à « qui valide paramètres et résultats ensuite ? ». Cela relève du Schema et de l'hôte.

Qu'est-ce que le Function Calling ?

Function Calling (la doc OpenAI dit surtout tools) est la forme concrète du Tool Calling dans une API Chat / Responses de fournisseur. Vous injectez des définitions de fonctions ; si le modèle décide d'appeler, la réponse contient tool_calls.

Une définition typique style OpenAI ressemble à ceci. Notez que parameters est déjà un sous-ensemble de JSON Schema :

{
  "type": "function",
  "function": {
    "name": "lookup_order",
    "description": "Look up an order by ID",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {
          "type": "string",
          "description": "Order ID, e.g. A-1042"
        }
      },
      "required": ["order_id"],
      "additionalProperties": false
    }
  }
}

L'intention d'appel revient en général ainsi :

{
  "tool_calls": [{
    "id": "call_3c91",
    "type": "function",
    "function": {
      "name": "lookup_order",
      "arguments": "{\"order_id\":\"A-1042\"}"
    }
  }]
}

arguments reste du JSON stringifié. L'hôte doit refaire un JSON.parse et valider order_id contre le Schema. Sauter cette étape est l'incident de production le plus fréquent en 2026. Si l'imbrication devient illisible, formater et vérifier la syntaxe d'abord pour voir crochets et échappements.

Comment distinguer Tool Calling et Function Calling — et comment les empiler ?

Ce ne sont pas des produits concurrents. Ils occupent des couches différentes :

  • Tool Calling : l'idée. Tout « le modèle émet une intention, l'hôte exécute » compte.
  • Function Calling : le cadre API. Champs : tools[], tool_calls, role: tool.
  • MCP Tool Schema : le protocole d'approvisionnement. Champ : inputSchema, transmis en stdio / SSE vers un MCP Server.

Le bon empilement : un Schema dans le dépôt, exporté en parameters Function Calling et inputSchema MCP. Pas de troisième liste « presque identique » en prose dans le prompt. Détails dans MCP Tool Schema vs Function Calling et Pourquoi les agents IA ont désormais besoin de JSON Schema.

Pourquoi tout agent 2026 atterrit-il sur JSON ?

Le langage naturel parle aux utilisateurs. Chaque saut entre machines doit être validable, diffable et rejouable. JSON porte cinq sortes d'objets :

  1. Définitions d'outils : tools[] ou MCP inputSchema.
  2. Intention d'appel : nom de fonction + arguments dans tool_calls.
  3. Résultats d'outils : objets issus des requêtes, écritures et API externes. C'est la couche la plus souvent absente.
  4. Handoff d'agent : intention, confiance, destinataire. L'Agents SDK route sur cet objet, pas sur le mot « billing ».
  5. État de workflow et evals : checkpoints, traces, fixtures d'eval. Les longs jobs reprennent depuis du JSON ; ils ne devinent pas l'avancement dans le journal de chat.

JSON Schema est le diamètre de ces objets. Sans lui, Function Calling, MCP et A2A dérivent chacun vers une copie « qui se ressemble ». Pourquoi les agents IA ont désormais besoin de JSON Schema a fait du Schema une barrière d'exécution, plus une doc ; l'intro syntaxique est le tutoriel JSON Schema.

Un pipeline JSON complet

Prenez « consulter une commande → rembourser ». Une chaîne 2026 conservative et testable :

  1. L'hôte injecte les Schemas de lookup_order / create_refund dans tools[] et active strict: true.
  2. Le modèle renvoie tool_calls ; arguments est encore une chaîne.
  3. L'hôte fait JSON.parse et valide contre le même Schema ; en échec, il coupe et ne touche pas à la facturation.
  4. La vraie requête s'exécute et renvoie un objet commande.
  5. Retour en role: tool — de préférence du JSON valide au Schema, pas un paragraphe.
  6. Le modèle appelle un autre outil ou émet un Structured Output pour l'utilisateur ou un agent aval.
  7. Pour changer d'agent, il écrit un objet handoff au lieu de « demandez à billing ».

Un objet handoff doit rester aussi stable :

{
  "handoff": {
    "from": "triage",
    "to": "billing_agent",
    "intent": "refund",
    "order_id": "A-1042",
    "confidence": 0.91
  }
}

Quand plusieurs agents doivent se découvrir, A2A Extensions place les capacités sur l'Agent Card et négocie avec des en-têtes d'extension. Cela ne remplace pas le pipeline ci-dessus ; cela ne fait que dispatcher entre agents.

Que choisir en 2026 ?

  • Une appli unique, une boucle interne fermée, moins de dix outils : Function Calling suffit. Mettez d'abord Schema et strict: true dans la CI.
  • IDE / plateforme / outils tiers à brancher : MCP fournit ; la couche API utilise encore Function Calling pour ce saut.
  • Des agents hétérogènes doivent se découvrir et négocier des extensions : ajoutez A2A, n'inventez pas une autre enveloppe privée.
  • Sur chaque chemin : écrivez paramètres, résultats et handoffs en JSON Schema, puis exportez des adaptateurs.

N'attendez pas qu'une keynote « unifie le protocole ». Le geste stable de 2026, ce sont les couches, pas un pari sur un gagnant.

Pièges fréquents

  • Prendre l'agent pour un ChatGPT bavard. Un dialogue démontre ; la production a besoin d'une machine à états récupérable.
  • Voir Tool Calling et Function Calling comme des rivaux. L'un est l'idée, l'autre le cadre API. MCP est une troisième couche d'approvisionnement.
  • Ne pas valider arguments. JSON stringifié, nombres en chaînes, champs en trop dans la facturation : tout se joue sur ce saut.
  • Résultats d'outils en texte libre. Le saut suivant traitera « on dirait que ça a marché » comme statut de commande.
  • Enfoncer 50 outils dans une requête. Les gros schemas coûtent cher et se trompent de cible. Au-delà de dix, ajoutez routage ou retrieval.

FAQ

Un agent doit-il utiliser Function Calling ?

Non. Function Calling est le cadre API le plus courant, mais MCP Tool Use et le Tool Use des fournisseurs restent du Tool Calling. Ce qui compte, c'est l'exécution hôte plus la validation Schema — pas que le champ s'appelle tools ou inputSchema.

Tool Calling n'est-il que le nouveau nom de Function Calling ?

Certains docs mélangent les deux. Plus propre : Tool Calling est le terme parapluie ; Function Calling est la forme tools / tool_calls compatible OpenAI. Dessinez deux boîtes et la plupart des débats disparaissent.

Le JSON mode sans Schema suffit-il ?

Le JSON mode garantit seulement « ça ressemble à du JSON », pas des champs, types ou enums légaux. Les Structured Outputs 2026 fixent le diamètre avec json_schema + strict. Sur un agent multi-étapes, le JSON mode échoue le jeu d'eval.

Faut-il attendre le DevDay 2026 ?

Non. Le 29 septembre peut approfondir Structured Outputs et les plans d'appel. Cela ne change pas « écrire le Schema d'abord ». Mettez outils et handoffs dans git maintenant ; après la keynote, vous ne changez que les adaptateurs.

Comment déboguer le JSON des outils et handoffs ?

Formatez-le dans le navigateur, cherchez le required manquant, puis Diff contre la version précédente. JSONSort tourne en local et n'uploade rien. Ne collez pas de réponses d'outils secrètes sur un site public.

Conclusion

Un agent IA est un runtime avec outils et état, pas un modèle qui parle mieux. Tool Calling lui permet de tendre la main, Function Calling est la forme API la plus courante de cette main, JSON est l'objet qui doit coller à chaque saut.

Commencez aujourd'hui par schemas/tools/lookup_order.json, pas par un prompt plus long. Les modèles changeront, les protocoles se multiplieront. Stabilisez d'abord le diamètre.

Pour aller plus loin

Journal : première publication