Pourquoi ChatGPT, Gemini et Siri AI ont-ils besoin de données structurées ?

En 2026, on peut encore lire un français fluide dans une fenêtre de chat. Remettre ce texte au calendrier, à un ticket, à la facturation, ou à l'étape Agent suivante : les phrases ne suffisent plus. « Vers jeudi matin », « le client a l'air pressé », « réserve-moi ça » — l'humain complète, le parseur non. ChatGPT, Gemini, Siri AI ont besoin de données structurées, non parce que les accolades sont jolies, mais parce qu'ils doivent tous passer de « expliquer » à « exécuter ». Pour choisir un phare : Guerre des modèles 2026. Cet article n'écrit que la couche contrat déjà en production.

Trois produits, le même écart

En surface, ça n'a rien à voir. ChatGPT vend le chat et l'API Responses. Gemini vend le multimodal et GenerateContent. Siri AI vend « dites cette phrase à l'écran, le système s'en occupe ». L'écart est le même : le langage naturel n'a pas de type.

Champ obligatoire manquant, booléen écrit « oui », date écrite « mardi prochain » : en aval, il faut de la regex, des retries, un filet humain. Les trois ont rangé le problème dans le même genre d'interface : d'abord rendre un objet, puis autoriser à côté une phrase destinée à l'humain. Pourquoi l'objet choisit le JSON : Pourquoi l'IA aime le JSON. Cet article ajoute : ce qui a besoin de données structurées, ce n'est pas seulement le modèle cloud. C'est aussi l'assistant système et le runtime Agent.

Ce que sont vraiment les données structurées

À l'oral, « structuré » se résume souvent à « renvoyez du JSON ». En production, il y a trois couches. Les mélanger, et l'on a l'impression que « le modèle obéit parfois, parfois non ».

1. L'instance. Un objet concret : ce ticket, cet événement, cet appel d'outil. Il doit pouvoir parser.
2. Le contrat. Ce à quoi cet objet a le droit de ressembler : quelles clés sont obligatoires, quelles valeurs d'enum, s'il y a des bornes numériques. L'écriture courante du contrat, c'est le JSON Schema.
3. La boucle. L'Agent lit l'objet du pas précédent, choisit l'outil suivant, rend le prochain objet. Sans les deux premières couches, la troisième ne tient que si un humain surveille.

Les trois mots du titre collent à ces trois couches : JSON est l'écriture universelle de l'instance, JSON Schema est le contrat, AI Agent est la boucle qui ne tourne que grâce aux deux premières. Enlevez-en une : le reste dégénère en « renvoyez uniquement du JSON » dans le prompt — encore une démo en 2024, une dette en 2026.

JSON : le bus, pas une affaire de goût

Les données structurées n'exigent pas le JSON. Une base a des lignes, Protobuf des numéros de champ, Swift des types. Sur la ligne IA, ça converge quand même vers le JSON, parce que quatre choses tiennent en même temps :

1. Chaque runtime peut parser. Navigateur, Python, Swift, Go, fonction cloud : l'échec est une erreur de syntaxe, pas un « ça ne sonne pas juste ».
2. Ça s'imbrique. Objets, tableaux, booléens, nombres, null : assez pour les paramètres d'outil et les pièces métier.
3. Le corpus d'entraînement en est plein. Réponses d'API, logs, application/json dans les pages : le modèle a vu bien plus de JSON valide que de YAML ou d'XML valides.
4. Un Schema peut le surveiller. La même instance sert de sortie au modèle, et d'entrée au validateur, à Zod, à OpenAPI.

YAML craint l'indentation, XML a des balises lourdes, Markdown est pour l'humain. D'où les paramètres d'outil ChatGPT, le response_mime_type: application/json de Gemini, le JSON-RPC de MCP, et dans la doc Apple « @Generable se convertit en JSON Schema » — le bus, ce sont des objets ; l'écriture la plus courante en ligne, c'est le JSON. Format universel ne veut pas dire « n'importe quelles accolades ». Les règles restent : types figés, enums refermés, required listé en entier, additionalProperties: false.

JSON Schema : le contrat, pas une annexe

Avec seulement du JSON, le saut suivant mise encore. Le modèle peut omettre une clé, écrire un montant en chaîne, inventer un champ que votre parseur ne connaît pas. Le JSON Schema retire le pari :

• La forme. type, properties, items des tableaux.
• L'obligatoire. Listez tout required. Le mode strict des trois exige que vous listiez explicitement ; omettre, c'est autoriser le champ manquant.
• Refermer. Statut, priorité, canal : en enum. Le texte libre ne reste que pour les phrases vraiment destinées à l'affichage.
• Refuser les clés en trop. additionalProperties: false. Sinon le modèle « rend service » et ajoute un champ d'explication que vous n'avez pas déclaré.

Le Schema a un second métier : le décodage contraint. Les tokens illégaux sont bloqués à l'échantillonnage, pas regrettés après génération. Structured Outputs chez ChatGPT, responseSchema chez Gemini, Guided Generation chez Apple : c'est ça. Définition et étapes de recette : Générer un Structured Output depuis un échantillon.

AI Agent : la boucle ne mange pas de prose

Une question isolée peut se passer de contrat. Un Agent, non. Une boucle qui entre en production, c'est en général : comprendre l'objectif → choisir un outil ou un Intent → remplir les paramètres → clarifier si besoin → exécuter → rendre le résultat comme objet. Le chemin cloud DevDay : DevDay 2026 Agent. Siri / Shortcuts suivent le même genre de boucle sur le bus système ; le nom d'outil est juste écrit en Intent de domaine.

Dans la boucle, chaque saut doit pouvoir être rattrapé par une machine :

• Choisir l'outil est une énumération, pas un « je compte utiliser le calendrier ». Le nom doit coller au registre.
• Remplir les paramètres est un JSON (ou un objet mappable en JSON). Sans starts_on, l'API calendrier ne devine pas.
• Lire la valeur de retour est encore un objet. L'étape suivante veut event_id, status, pas « c'est bon, je t'ai réservé ça ».

MCP fige cette couche en JSON-RPC : nom d'outil, paramètres, valeur de retour sont des objets. La page MCP Tool de ce site écrit précisément ce contrat. Les évaluations aussi veulent un objet — un morceau de prose ne se compare pas automatiquement ; un JSON, avec la Comparaison JSON, montre si un champ a dérivé ou si un type a dérivé. Donc un Agent, ce n'est pas « un modèle qui discute mieux ». C'est une machine à états qui ne se referme que grâce aux données structurées.

Comment chacune « a besoin »

Ce qu'elles veulent, c'est le même objet, pas le même corps de requête. Écrivez l'enveloppe dans la doc, laissez les champs dans un fichier partagé.

1. ChatGPT : le Schema entre dans le décodeur

La fenêtre de chat est pour l'humain. Le chemin de production passe par l'API. Dans Chat Completions, Structured Outputs s'accroche à response_format, type json_schema ; en production, ouvrez strict: true. L'API Responses pose le même objet dans text.format. Coller les champs d'un ancien guide sur la nouvelle interface : souvent pas d'erreur jolie — ça cesse simplement de contraindre comme vous l'attendiez.

Côté Agent, c'est un autre contrat : les parameters de fonction sont aussi du JSON Schema. Le modèle ne « discute pas s'il faut créer un rappel » : il soumet des paramètres qui doivent pouvoir se valider. JSON Mode garantit seulement que les accolades parsent ; ça peut rester en démo, pas sur les chemins d'écriture et de facturation. Le .parse() du SDK referme encore une fois via Pydantic / Zod.

2. Gemini : mime type plus Schema

Gemini range JSON Mode et Structured Output sur une seule ligne : response_mime_type: application/json, puis accroche responseSchema / response_json_schema. C'est celui qui a l'air le plus « Schema natif », et le sous-ensemble le plus étroit : types de base, enum, format, bornes, required — OK ; polymorphisme profond, $ref récursif, arbres trop grands ou trop profonds : la doc dit clairement que ça peut refuser net.

Les déclarations d'outils sont aussi un Schema. Multimodal en entrée, objet en sortie : l'écriture de production la plus courante chez Gemini. Image ou long audio dans le modèle ; ce qui sort n'est pas une description, ce sont des champs de ticket. Pour le Structured Output à fort volume, on choisit encore souvent Gemini 3.8 Flash : choisir un modèle par tâche. Plafond de sortie 64K ; les pièces longues, on les découpe d'abord.

3. Siri AI : le bus système aussi veut un objet

L'ancien Siri, c'était une table de phrases. Le nouveau Siri (la doc développeur écrit Siri AI) mange du Schema. L'App enregistre entités et actions en App Intents : calendar_createEvent reçoit titre, heure de début, durée — pas « réserve-moi demain après-midi ». Le « ça » à l'écran doit aussi se lier à une entité, sinon la référence ne devient pas un paramètre. Le bit de confirmation utilisateur est un sas, pas de la politesse.

Les Foundation Models on-device prennent une autre enveloppe : ajoutez @Generable à la structure, le framework compile le type en JSON Schema, puis génère un objet Swift par échantillonnage contraint. Au quotidien, le développeur touche un type, pas des accolades. Dans les logs, la sync inter-environnements, vers votre propre backend : l'objet doit encore pouvoir être rattrapé par un parseur JSON et un JSON Schema. Le découpage : Qu'est-ce qu'Apple Intelligence.

Ce qui se partage : les champs — enum, obligatoires, booléens, formats de date, additionalProperties: false. Ce qui ne se partage pas : l'enveloppe. Générez le premier Schema depuis le même échantillon, puis branchez-le sur les trois interfaces et l'Intent système.

Un échantillon Agent qui marche chez les trois

Ce n'est le corps de requête privé d'aucune des trois. C'est l'objet métier que les paramètres d'outil ChatGPT, le Structured Output Gemini et l'Intent calendrier Siri devraient aligner quand « l'Agent doit réserver un rappel client ». Énumérations en chaînes, durée en number, confirmation en boolean.

{
  "run_id": "agt-20260910-07",
  "surface": "siri",
  "step": "act",
  "intent": {
    "name": "schedule_callback",
    "domain": "calendar",
    "confirmed": false
  },
  "ticket": {
    "id": "TCK-8841",
    "priority": "high",
    "channel": "phone"
  },
  "slot": {
    "starts_on": "2026-09-11",
    "starts_at": "10:30",
    "duration_min": 20,
    "timezone": "Asia/Shanghai"
  },
  "customer": {
    "name": "Example Labs",
    "phone_last4": "4821"
  },
  "confidence": 0.84,
  "needs_confirmation": true
}

Selon les règles d'inférence actuelles du site, cet échantillon donne :

Échantillon prêt : ouvrez Structured Output pour générer les trois enveloppes OpenAI / Claude / Gemini, puis relisez à la main required et additionalProperties. Le même objet peut aussi devenir un outil, via Function Calling ou MCP Tool : le modèle ne « parle pas d'un rappel », il soumet une action Agent qui doit pouvoir se valider. Côté Siri : intent.name sur le Schema de domaine, slot sur les paramètres calendrier, needs_confirmation sur la confirmation système.

Recetter dans la Boîte à outils JSON

1. Collez l'échantillon ci-dessus dans le formatage JSON, pour confirmer que ça parse.
2. Générez le brouillon avec Structured Output ou JSON → Schema. C'est l'étape que @Generable on-device fait à la compilation, juste dans une autre langue.
3. Un second jeu de sorties réelles — le modèle écrit « jeudi » en date relative, la priorité en « un peu urgent » — passe en validation Schema. Le premier échantillon est toujours trop propre.
4. Quand vous passez d'une trace ChatGPT à Gemini ou Siri, utilisez la Comparaison JSON pour voir si un champ a disparu ou si un type a dérivé.
5. Validation front : Zod ; doc d'API si besoin : OpenAPI 3.1.

Tout se traite dans le navigateur, rien n'est envoyé au serveur.

FAQ

Pourquoi ChatGPT, Gemini et Siri AI ont-ils tous besoin de données structurées ?

Pour l'humain, des phrases suffisent. Écrire dans le calendrier, appeler un outil, ou passer le résultat au saut Agent suivant, exige un objet typé. Les trois entrées diffèrent ; un champ manquant, un type qui dérive, ou un enum qui s'envole, et la boucle s'arrête.

Quelle est la différence entre JSON et JSON Schema ?

Le JSON est une instance : des clés et des valeurs. Le JSON Schema est le contrat : types, enum, required, additionalProperties. Avec seulement une instance, le saut suivant mise. Avec un Schema, on peut contraindre le décodage, et revérifier.

Un AI Agent peut-il tourner sans Schema ?

En démo, oui. En boucle de production, non. Un Agent doit choisir un outil, remplir les paramètres, lire la valeur de retour, et décider la suite. Ces trois pas sont des objets. La prose ne se compare pas automatiquement, et on ne peut pas l'écrire en sécurité.

Les trois peuvent-elles partager un même Schema ?

Le contrat de champs se partage. L'enveloppe, non : OpenAI passe par response_format ou text.format, Gemini par responseSchema, Siri par App Intents ou @Generable. Faites-le pousser depuis le même échantillon ; ne recopiez pas les champs à la main trois fois.

Les données structurées de Siri, c'est la même chose que celles de ChatGPT ?

Le même genre de problème, pas le même corps de requête. ChatGPT / Gemini mettent le JSON Schema dans HTTP ; Siri compile un Schema de domaine et des types Swift en objets. Dans les logs, les évaluations, et vers votre propre backend, ça doit encore pouvoir être rattrapé par JSON et JSON Schema.

En résumé

ChatGPT, Gemini, Siri AI ont besoin de données structurées parce que le programme et l'Agent doivent rattraper le modèle ; on ne peut pas s'appuyer sur un bon texte. JSON est le bus, JSON Schema le contrat, la boucle Agent mange des objets. Les enveloppes des trois diffèrent : response_format / text.format, responseSchema, App Intents / @Generable. Ce qui se partage : les champs, les types, l'obligatoire, et « pas de clé en trop ». Ce qui survit au renouvellement de la semaine suivante, c'est l'échantillon et le Schema, pas le « renvoyez du JSON » dans le prompt. Un seul échantillon fait pousser le contrat ; validation, Zod, OpenAPI, et le type Swift que vous mapperez, le suivent.

Outils liés