Stack agents IA 2026 : comment GPT, Gemini, Claude, MCP, Function Calling et JSON Schema travaillent ensemble

En 2026, livrer un agent IA ne se joue plus sur « GPT, Gemini ou Claude ». La fiabilité vient de la façon dont les modèles émettent des Function Calling structurés, dont JSON Schema contraint les arguments, et dont MCP branche outils et contexte dans le runtime. Ces couches forment un stack auditable, versionné, où l’on peut changer de modèle.

Ce guide s’adresse aux équipes qui transforment un chatbot en agent exécutant : responsabilités, une boucle d’outils complète, et la frontière des builds sur un Mac cloud. Coûts : Claude / GPT / Gemini via OpenRouter ; isolation : systèmes de fichiers virtuels ; état inter-sessions : comparatif Agent Memory.

Couche modèles : GPT · Gemini · Claude, moteurs remplaçables

Couche contrat : Function Calling + JSON Schema

MCP

Couche slot : transport standard outils, ressources, prompts

Découper le stack : le modèle n’est pas le produit

Voir l’agent comme « un modèle qui parle » masque trois couches qui portent la fiabilité :

Moteur d’inférence : GPT, Gemini, Claude — planifier, choisir un outil, interpréter.
Contrat d’appel : Function Calling (tool use) plus JSON Schema — ce qui est appelable et la forme des arguments.
Slots runtime : le Model Context Protocol (MCP) rattache fichiers, dépôts, navigateur et API internes à l’hôte.

Consensus 2025–2026 : les modèles peuvent changer ; contrats et slots doivent rester stables. Ne figez pas le métier sur des noms de SDK propriétaires : concevez autour d’un catalogue d’outils, de schémas et d’un bac à sable.

Rôles de GPT, Gemini et Claude

Les trois gèrent les outils. Les écarts portent surtout sur le style par défaut, l’entrée multimodale, le long contexte et la prudence face aux appels risqués, pas sur l’existence du function calling.

GPT : documentation de boucle d’outils mature ; OpenAI Function Calling et un large écosystème Responses / Chat Completions — souvent orchestrateur ou backend de passerelle.
Gemini : multimodal et long contexte forts ; le function calling officiel convient aux agents qui chargent docs, captures et arborescence ensemble.
Claude : tool use solide en code / ordinateur ; Anthropic tool use convient aux éditions à fort risque, quand on veut refuser plus nettement les dépassements.

En production, on route plutôt qu’on ne croit en un seul modèle : inférence forte pour planifier, modèles moins chers pour l’extraction massive, palier conservateur plus confirmation pour les écritures sensibles. Coûts : comparatif multi-modèles.

Ingénieur branchant les appels d’outils GPT, Gemini et Claude et des serveurs MCP sur un même runtime d’agent — Parcours typique : intention → plan du modèle → appel d’outil validé par schéma → MCP ou exécuteur local → observation renvoyée au contexte

Function Calling : l’interface légitime vers le monde

Function Calling ne signifie pas « le modèle exécute la fonction ». Cela signifie une intention d’appel structurée, et l’hôte décide d’exécuter ou non.

Modèle : nom d’outil, arguments, replanification à partir des observations.
Hôte : auth, quotas, validation, I/O réel, résultats dans la liste de messages.

Les noms de champs varient (tools / function / input_schema), pas la boucle : déclarer → tool call → exécuter → tool result → raisonner à nouveau. Pas de chaînes shell comme « outil » : cela contourne le schéma et laisse l’injection au prompt.

Socle d’ingénierie

Noms stables, une classe d’effet de bord par outil.
Séparer lecture et écriture ; écriture par défaut avec confirmation ou bac à sable.
Conserver call_id pour audit et retry.

JSON Schema : le système de types des outils

Dans un stack agent, JSON Schema est typage à la compilation plus validation à l’exécution. Champs requis manquants, enums hors liste, propriétés en trop doivent échouer avant la logique métier ; le modèle voit l’erreur et retente.

Versionnez parameters / input_schema comme un vrai schéma (JSON Schema), pas une phrase de prompt « passez repo et branch ».

Contraintes à mettre dans le schéma

type, required, additionalProperties: false pour limiter les champs hallucinés.
Chemins, URL, enums via pattern / enum — pas de texte libre comme identifiant.
Gros journaux / diffs hors arguments : fichier d’espace de travail + chemin, aligné sur les lectures VFS à la demande.
Version dans le schéma ou le suffixe d’outil (deploy_v2) pour éviter un contrat flou partagé.

Valider après la sortie du modèle, avant les effets réels. « Émets du JSON » dans le prompt système n’est pas un contrôle de production.

MCP : un slot universel pour outils et contexte

MCP, au-dessus du Function Calling, traite découverte et transport : les outils n’ont pas à être figés dans l’app ; un serveur MCP liste tools, resources, prompts. Les hôtes (Claude Code, agents d’IDE, orchestrateurs maison) relient plusieurs serveurs via un protocole.

Face à un SDK plugin par éditeur :

Outils enfichables : Git, navigateur, tickets en serveurs séparés ; l’hôte garde connexions et politique.
Contexte adressable : URI de ressources pour ne pas coller des fichiers entiers dans le prompt.
Découplage modèle : le même catalogue MCP alimente GPT, Gemini ou Claude.

Il faut encore mapper les outils MCP vers des déclarations Function Calling avec JSON Schema et des listes blanches de chemins côté hôte. MCP est une prise standard, pas la frontière de sécurité ; bac à sable, secrets et audit restent chez l’hôte.

Une boucle complète : de l’intention au résultat

Exemple : « ouvrir une PR de correctif depuis un log de build iOS en échec ». Ordre typique :

Intention utilisateur ; l’hôte injecte la politique (pas de certificats, pas de secrets prod).
Le modèle lit le catalogue (registre statique ou MCP list_tools).
Appel fetch_ci_log ; arguments validés par JSON Schema.
L’exécuteur récupère les logs en bac à sable ou sur un Mac cloud ; le trop-plein va au VFS.
Résultat renvoyé ; le modèle peut appeler apply_patch avec confirmation ou diff en lecture seule.
Les faits du type « profil expiré la dernière fois » vont en Memory, pas dans le schéma. Voir options Memory.

Les échecs doivent être structurés (validation, permission, timeout), sinon les retries deviennent du hasard.

Tableau et choix

Couche	Possède	Ne possède pas	Choix typique 2026
GPT / Gemini / Claude	Plan, choix d’outil, explication des observations	I/O réel, autorisation	Router par tâche, rester interchangeable
Function Calling	Intention en requête d’outil avec id	Modèle de droits métier	Tool use vendeur, un adaptateur hôte
JSON Schema	Forme des arguments, requis, enums	Effets de bord runtime	Schéma versionné, valider avant exécuter
MCP	Découvrir outils/ressources, transport	Remplacer bac à sable et coffre à secrets	Un serveur par système + politique hôte

Production : validation, droits, repli

Avant mise en ligne, au moins quatre portes :

Tests adverses de schéma : champs manquants / en trop, enums faux — l’hôte refuse, le modèle corrige depuis l’erreur.
Outils hors droits : noms inconnus, serveur MCP périmé, call_id forgé doivent échouer.
Isolation des effets : build, signature, déploiement hors du processus de chat ; pas de credentials prod par défaut.
Observabilité : nom d’outil, version de schéma, latence, succès / échec validation / échec auth.

OWASP classe sur-autorisation et injection de prompt parmi les risques centraux. « Le modèle a demandé, donc on a exécuté » n’est pas une politique. Ancre : OWASP LLM Top 10.

Exécuter la chaîne d’outils sur un Mac cloud

Pour iOS / cross-platform, les catalogues MCP incluent souvent xcodebuild, simulateurs et outils liés aux certificats. Ils sont liés à macOS et à la chaîne Apple et n’ont rien à faire dans un bac à sable Linux générique.

Découpage pragmatique :

Dialogue et planification : GPT / Gemini / Claude n’importe où dans le cloud.
I/O dépôt : VFS ou filesystem MCP avec listes blanches de chemins.
Builds et appareils réels : serveur MCP contrôlé ou job CI sur un Mac cloud Zilmac, secrets restant sur la machine de build.

Le stack modèles peut changer ; schémas et catalogues MCP restent ; les effets Apple atterrissent dans des sessions Mac cloud recyclables, pas sur un portable.

FAQ

Function Calling et MCP font-ils doublon ?

Non. Function Calling est la façon dont le modèle émet une requête d’outil. MCP est la façon dont l’hôte découvre et connecte outils et ressources. Chaque outil MCP se mappe encore en déclaration Function Calling.

Faut-il brancher les trois familles de modèles ?

Non. Stabilisez contrat et MCP chez un éditeur, puis routez un second modèle avec les mêmes schémas. Brancher trois vendeurs « pour l’éval » n’élargit que la surface d’outils non validée.

Le JSON Schema peut-il vivre seulement dans le prompt système ?

Pas comme seul contrôle. Le prompt aide à remplir ; refuser des arguments illégaux appartient au validateur hôte. Sinon injection ou dérive frappent le backend.

Comment éviter le lock-in sur une API vendeur ?

Forme interne : nom d’outil + JSON Schema + résultat d’exécution. GPT / Gemini / Claude sont des adaptateurs. Les serveurs MCP exposent un catalogue à l’hôte ; facturation et bascule sont sur la passerelle.