Aller au contenu principal

Sortie structurée

Intermédiaire
What you'll learn
  • Expliquer pourquoi une sortie contrainte par un schéma vaut mieux que demander du JSON en espérant
  • Fournir un JSON Schema et analyser la réponse en un objet typé (Pydantic / Zod)
  • Distinguer la sortie structurée de l'utilisation d'outils par l'intention, pas par le mécanisme
  • Appliquer les quatre conseils pour des schémas serrés et fiables
  • Choisir le bon outil avec une règle empirique à une question

Quand la sortie de Claude alimente d'autres logiciels, il vous faut une structure fiable — du JSON valide correspondant à une forme connue, à chaque fois. Ne comptez pas sur « réponds en JSON » en espérant ; utilisez la prise en charge de la sortie structurée de la plateforme.

Cette leçon vous mène de pourquoi le « prie pour que ça marche » échoue à comment appliquer un schéma et l'analyser en un objet typé — et comment distinguer la sortie structurée de l'utilisation d'outils quand elles semblent identiques. Parcourez-la de haut en bas, puis testez-vous avec le quiz vers la fin.

La méthode fiable​

Fournissez un JSON Schema pour la sortie et laissez l'API/le SDK l'appliquer, puis analysez-la en un objet typé (p. ex. Pydantic en Python, Zod en TypeScript). Les assistants d'analyse du SDK vous rendent un résultat typé au lieu d'une chaîne que vous devez JSON.parse et valider vous-même.

Guided walkthrough1 of 3
  1. Modélisez la sortie dont vous avez besoin comme un JSON Schema — en Python via un BaseModel Pydantic, en TypeScript via un schéma Zod.
# Conceptual shape — see the official docs for the current API surface.
from pydantic import BaseModel

class Ticket(BaseModel):
    title: str
    priority: str   # "low" | "medium" | "high"
    tags: list[str]

# Request the model to return data conforming to Ticket's JSON schema,
# then parse the response into a Ticket instance.

Vous voulez une requête concrète à adapter ? Voici la forme de ce que vous confiez au modèle — remplacez le modèle par votre propre schéma.

Demander une sortie conforme au schéma

Return the data conforming to this JSON Schema:

{
"title": "string",
"priority": "low | medium | high",
"tags": ["string"]
}

Do not include any prose outside the JSON.

Pourquoi ne pas simplement demander du JSON ?​

Vous pouvez demander du JSON dans le prompt, et pour les cas simples ça marche — mais ça peut dériver : de la prose parasite, une virgule finale, un champ manquant. La sortie contrainte par un schéma supprime cette classe de bugs, ce qui compte dès qu'un système en aval en dépend.

Watch out
  • Le JSON demandé au prompt marche dans les démos et casse en production : la panne n'apparaît que lorsqu'un système en aval l'analyse.
  • Trois dérives classiques à surveiller : de la prose parasite autour du JSON, une virgule finale, un champ requis manquant.

Sortie structurée vs. utilisation d'outils​

Les deux fonctionnalités confient au modèle un JSON Schema, elles se ressemblent donc — et les gens choisissent la mauvaise. La différence est l'intention, pas le mécanisme :

Sortie structuréeUtilisation d'outils
Ce que vous voulezLa réponse finale, dans une forme fixeQue le modèle invoque une capacité (appeler une fonction, récupérer des données, effectuer une action)
Qui la consommeVotre code, directementVotre code exécute l'outil, puis renvoie le résultat au modèle
Forme du tourUne réponse, terminéUne boucle : le modèle demande, vous exécutez, le modèle continue
Usage typiqueExtraction, classification, analyseAgents, recherches en direct, effets de bord

Une règle empirique rapide :

Si le JSON est le livrable, utilisez la sortie structurée. Si le JSON est le modèle qui demande à votre code de faire quelque chose, c'est de l'utilisation d'outils. Les agents utilisent souvent les deux : des outils pour agir, une sortie structurée pour renvoyer un résultat final propre.

Conseils​

Pro tip
  • Gardez les schémas serrés — utilisez des enums pour les choix fixes ; marquez les champs requis.
  • Décrivez les champs — les descriptions de champs guident le modèle comme des mini-prompts.
  • Validez quand même à la frontière — l'analyse défensive est une assurance bon marché.
  • Pour les tâches d'extraction, une sortie structurée + un schéma clair vaut mieux que le format libre à chaque fois.
Key takeaways
  • Confiez à l'API/au SDK un JSON Schema et analysez-le en un objet typé — ne priez pas pour que ça marche.
  • Demander du JSON au prompt peut dériver (prose parasite, virgule finale, champ manquant) ; l'application d'un schéma supprime cette classe de bugs.
  • Sortie structurée vs. utilisation d'outils diffèrent par l'intention : le JSON EST la réponse vs. le JSON demande une action.
  • Des schémas serrés, des champs décrits et une validation à la frontière rendent l'extraction et la classification fiables.

Ancrez les termes​

Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 5

Testez-vous

0/4
  1. Quelle est la méthode fiable pour obtenir du JSON structuré de Claude ?
  2. Pourquoi demander du JSON au prompt est-il risqué dès qu'un système en aval en dépend ?
  3. Qu'est-ce qui distingue réellement la sortie structurée de l'utilisation d'outils ?
  4. Quel est un bon conseil pour concevoir des schémas ?

Ensuite​