Qu'est-ce que le Structured Output IA ? Pourquoi GPT, Gemini et Claude commencent-ils à prendre en charge la sortie JSON structurée ?

En 2024, on tenait encore le modèle dans les accolades avec un prompt. En 2026, GPT-5.6, Claude Fable 5.1 et Gemini 3.8 Flash ont tous écrit Structured Output comme une interface officielle. Les gammes diffèrent, voir Guerre des modèles 2026, mais pour le saut remis à un programme, les trois prennent le même chemin : un objet parseable, plus un Schema. Ce n'est pas un interrupteur de plus dans la doc : le modèle passe de « il sait parler » à « le saut suivant peut le rattraper ».

Ce que c'est vraiment

Structured Output (sortie structurée) est une capacité d'interface fournie par les éditeurs de modèles : à l'appel, vous joignez un JSON Schema (ou une description de types équivalente), et toute la réponse du modèle doit être un objet JSON conforme à ce Schema. Champ manquant, type qui dérive, enum qui s'envole, clé inconnue en trop : bloqués à la génération, pas après votre JSON.parse.

Trois choses doivent tenir en même temps, sinon ce n'est pas du Structured Output :

1. La sortie est un objet, pas de la prose. L'explication destinée à l'humain peut être absente. Le programme reçoit un objet.
2. La forme est fixée par le Schema. type, enum, required, additionalProperties s'écrivent dans le contrat, pas dans le prompt.
3. La contrainte a lieu au décodage. Les tokens illégaux sont exclus à l'échantillonnage. C'est le décodage contraint (constrained decoding), pas un retry après coup.

L'écart avec « renvoyez du JSON »

Le prompt est une demande. L'interface est un contrat. Écrire « renvoyez uniquement du JSON, pas de markdown » dans le system prompt, et le modèle coopère le plus souvent — mais le mode d'échec est mou : une couche d'explication en trop, un nombre écrit en chaîne, un obligatoire oublié, une clé que votre parseur ne connaît pas. Il ne reste que le retry, la regex, le filet humain.

Structured Output déplace le contrat du langage naturel vers le décodeur. Le modèle ne « ressemble plus autant que possible à du JSON » : il « ne peut émettre que des tokens légaux ». L'échec devient une erreur d'interface ou un parse raté du SDK, pas un français qui a l'air d'être du JSON.

Les frontières avec JSON Mode et Function Calling

Dans un même produit, trois termes se mélangent facilement. Les mélanger, et l'on a l'impression que « le modèle obéit parfois, parfois non ».

JSON Mode est une forme faible de Structured Output ; il peut rester en démo. Function Calling est un autre contrat : le modèle dit « je vais appeler cet outil », les paramètres doivent pouvoir se valider. Claude écrit les deux avec la même forme ; OpenAI et Gemini séparent response_format / responseSchema et tools. Les champs se partagent ; ne recopiez pas la mauvaise enveloppe. Pour la boucle d'outils côté Agent, voir DevDay 2026 Agent.

Pourquoi les trois l'ont : pas un goût, la production

La fenêtre de chat peut parler. Un système de production, non. De 2024 à 2026, les trois ont fait de la même capacité un citoyen de première classe, parce que l'aval a changé.

1. L'Agent veut une boucle, pas de la prose. Paramètres d'outil, état intermédiaire, résultat de routage : tout doit parser. Un français fluide n'entre pas dans le saut suivant. Le chemin Agent après le DevDay : Comment le développement Agent va changer.
2. L'écriture et la facturation ne peuvent pas miser sur le retry. Facture, ticket, trace d'évaluation : un champ manquant, et c'est de la donnée sale. Un taux de réussite du prompt à 95 % est joli en démo ; pour écrire en base, ce n'est pas assez.
3. Le décodage contraint peut déjà entrer dans les phares. Autrefois, « générer strictement selon le Schema » était trop lent ou trop fragile. Après qu'OpenAI a poussé le Schema dans le décodeur en 2024, la voie s'est montrée vendable ; Claude et Gemini n'ont aucune raison de laisser les développeurs au prompt.
4. Le routage inter-modèles a besoin du même objet. Changer model_id ne doit pas changer les noms de champs. Le contrat est dans le Schema ; chacune peut écrire son enveloppe.

Donc « elles commencent toutes à le prendre en charge » n'est pas un rendez-vous pour aimer les accolades. Qui laisse d'abord les développeurs brancher le modèle sur un programme entre en production. Les raisons pour lesquelles le JSON a été choisi — ça parse, ça se valide, c'est partout dans l'entraînement — l'article précédent les a déjà écrites.

Où chacune a écrit la capacité

Ce qu'elles aiment, 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. GPT / OpenAI : le Schema entre dans le décodeur

Dans Chat Completions, Structured Outputs se raccroche à response_format, type json_schema ; en production, ouvrez strict: true. Responses API pose le même objet dans text.format. Coller les champs d'un ancien guide sur la nouvelle API ne produit souvent pas une belle erreur : ça cesse simplement de contraindre comme vous le pensiez. Le .parse() du SDK le reprend encore une fois via Pydantic / Zod.

JSON Mode (ça parse, c'est tout) peut rester en démo ; pas sur le chemin de facturation ni d'écriture. Côté outils, c'est un autre contrat : les parameters de la fonction sont aussi du JSON Schema.

2. Gemini : mime type plus Schema

Gemini rassemble JSON Mode et Structured Output en une seule ligne : response_mime_type: application/json, plus 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 passent ; polymorphisme profond, $ref récursifs, arbres trop grands ou trop profonds — la doc dit qu'elle peut refuser net.

Pour du Structured Output à haut volume, on choisit encore souvent Gemini 3.8 Flash, voir Choisir un modèle par tâche. Plafond de sortie 64K ; découpez d'abord les longs documents. Gemini 4 n'a pas de date de sortie ; le chemin de production s'écrit encore en 3.x, détail dans Quand sort Gemini 4.

3. Claude : la sortie et les outils, même forme

Anthropic écrit « donnez-moi un objet » et « allez appeler un outil » avec la même forme. Pour du JSON direct, Messages API : output_config.format (l'ancien nom output_format est déprécié). Sur le chemin Agent, on ajoute input_schema à l'outil, et on ouvre strict: true sur la définition d'outil — pas sur tool_choice.

Le Schema exige aussi additionalProperties: false et un required complet. En échange : l'outil que le modèle choisit a ses paramètres contraints à la génération. Le client.messages.parse() du SDK valide pour vous ; il ne livre pas la chaîne brute au métier.

Pourquoi ça apparaît en même temps

En surface, une course produit ; en dessous, la même voie technique et le même besoin développeur.

• La voie technique converge. Le décodage contraint compile le Schema en ensemble de tokens légaux. Qui en fait d'abord une interface stable transforme « renvoyez du JSON » en dette.
• L'écosystème est déjà bâti autour du JSON. SDK, navigateur, base, OpenAPI, Zod, JSON-RPC de MCP : le saut suivant mange des objets. Personne n'a intérêt à inventer un format qui ne marche que dans sa propre fenêtre de chat.
• Évaluations et conformité doivent pouvoir passer au Diff. Une prose ne se compare pas automatiquement ; un JSON montre si un champ a dérivé ou si un type a dérivé. La Comparaison JSON de ce site est faite pour ce saut.
• MCP écrit aussi le contrat d'outil en objet. Nom d'outil, paramètres, valeur de retour : du JSON. La page MCP Tool de ce site écrit le contrat, pas un prompt.

Les docs des trois n'emploient pas les mêmes mots ; l'expérience développeur converge : figer les champs d'abord, choisir l'enveloppe ensuite, changer model_id en dernier.

Ce que ça change pour les développeurs

Une fois la capacité devenue citoyenne de première classe, la façon de travailler doit changer : ce n'est pas une phrase de plus dans le prompt.

1. Écrivez d'abord l'échantillon, ensuite le Schema. Inversez types et obligatoires depuis un vrai JSON métier ; ne dessinez pas l'arbre dans le vide. Le tutoriel : Générer un Schema depuis un échantillon.
2. Un jeu de champs, trois enveloppes. Les corps de requête OpenAI / Claude / Gemini se génèrent depuis le même Schema. Recopier trois listes à la main, et ça dérive la semaine suivante.
3. Le mode strict est ouvert par défaut. strict: true, additionalProperties: false, required complet. Oublier une entrée, c'est autoriser un champ manquant.
4. Un second jeu de sorties réelles doit se revérifier. Le premier échantillon est toujours trop propre. Le Schema passe, le total peut encore être faux.
5. On change de modèle, pas de contrat. Figez les noms de champs et les types. Ce que l'on change, c'est l'enveloppe et model_id.

Le langage Schema de Gemini est un sous-ensemble OpenAPI. Partez de l'intersection : objet, tableau, string / number / integer / boolean, enum, required. Gardez oneOf, les références récursives et l'imbrication trop profonde pour plus tard, une fois que vous avez confirmé que la plateforme les avale.

Un échantillon minimal

Voici le JSON métier de « classer un ticket ». Ce n'est pas l'enveloppe de requête ; c'est l'objet que les trois modèles devraient produire. Énumérations en chaînes, confiance en number, besoin d'un humain en boolean.

{
  "ticket_id": "TCK-20260907-042",
  "intent": "billing",
  "priority": "high",
  "language": "zh-CN",
  "summary": "发票金额与订单不一致",
  "needs_human": true,
  "confidence": 0.81,
  "entities": [
    {
      "type": "invoice_id",
      "value": "INV-20260905-018"
    }
  ]
}

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 : le modèle ne « parle pas de ce ticket », il soumet une pièce qui doit pouvoir se valider.

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.
3. Passez un second vrai résultat de modèle dans la validation Schema. Le premier échantillon est toujours trop propre.
4. Au passage de GPT à Claude ou Gemini, 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

Quelle est la différence entre Structured Output et « renvoyez du JSON » ?

Le prompt n'est qu'une demande. Structured Output remet le Schema au décodeur. En production, on prend le second.

Pourquoi GPT, Gemini et Claude commencent-ils tous à le prendre en charge ?

Agent, facturation et écriture ne peuvent pas s'appuyer sur de la prose. Les trois doivent brancher le modèle sur un programme ; le décodage contraint est la même voie.

JSON Mode peut-il remplacer Structured Output ?

Pas comme contrat de production. JSON Mode garantit seulement que ça parse, pas les champs ni les types.

Structured Output et Function Calling, c'est la même chose ?

Non. L'un contraint toute la réponse, l'autre les paramètres d'outil. Les champs se partagent ; ne recopiez pas la mauvaise enveloppe.

Un Schema valide, est-ce que ça veut dire que le métier est juste ?

Non. La forme peut coller, le total peut encore être faux. Un second jeu de sorties réelles doit se revérifier.

En résumé

Le Structured Output IA est une interface, pas un tour de prompt. Vous remettez un Schema, le décodeur garantit la forme, le programme reçoit un objet. GPT, Gemini et Claude le prennent en charge parce qu'un système de production — Agent, écriture en base, évaluations, routage — ne peut pas s'appuyer sur un bon article. Les trois enveloppes diffèrent : response_format / text.format, responseSchema, output_config / input_schema. Ce qui se partage : les champs, les types, les obligatoires, et « pas de clé en trop ». JSON Mode reste en démo. Un seul échantillon fait pousser le contrat ; validation, Zod et OpenAPI le suivent.

Outils liés