Aller au contenu
Fondamentaux des LLM

Sorties structurées (JSON Schema)

Quand une réponse doit être lue par du code, on demande au modèle un JSON conforme à un schéma plutôt que du texte libre, puis on le valide côté application avant de s'en servir.

  • json
  • json schema
  • structured output
  • sortie structurée
  • validation
  • pydantic
  • zod

Syntaxe

Modèle
Schéma :{  "type": "object",  "properties": {    "categorie":   {"type": "string", "enum": ["facture", "devis", "relance"]},    "montant_ttc": {"type": "number"},    "date":        {"type": "string", "format": "date"}  },  "required": ["categorie", "montant_ttc", "date"]}API  : mode « sortie structurée » ou schéma imposé, quand le fournisseur le proposeCode : parser → valider (Pydantic, Zod, jsonschema) → sinon réessayer ou rejeter

Exemple

Exemple concret
Entrée : « Facture n° 2026-118 du 14/10/2026, total 1 260,00 € TTC »Sortie attendue : {"categorie": "facture", "montant_ttc": 1260.0, "date": "2026-10-14"}Contrôles métier côté code : montant_ttc > 0 et date antérieure à aujourd'huiRésultat attendu : document accepté et rangé dans les factures d'octobre.

À retenir

  1. Un schéma imposé par l'API garantit la forme (clés, types), pas la justesse des valeurs : un montant mal lu reste un nombre valide.
  2. Prévoyez une valeur explicite pour « inconnu » (null autorisé ou valeur « non_trouve ») : sans elle, le modèle invente pour remplir un champ obligatoire.
  3. Gardez le schéma court et nommez les champs clairement : les noms et descriptions de champs servent aussi de consignes au modèle.
  4. Piège : extraire le JSON avec une expression régulière ou l'utiliser sans validation. Une virgule décimale française, un champ manquant ou du texte autour du JSON suffit à casser la chaîne en production.

Voir aussi