Demander « réponds uniquement en JSON » ne garantit pas un objet exploitable. Le modèle peut ajouter du texte, oublier un champ ou produire un type incorrect. Une sortie structurée fiable combine une capacité native du fournisseur, un schéma précis et une validation applicative.
Trois niveaux de fiabilité
Le mode JSON garantit généralement une syntaxe JSON mais pas le respect exact d’un schéma. Le tool calling demande des arguments structurés pour un outil. Les structured outputs contraints par JSON Schema offrent le contrat le plus fort lorsqu’ils sont disponibles. Les noms et niveaux de prise en charge varient selon les fournisseurs et modèles.
Concevoir le schéma
Définissez objets, types, champs obligatoires, enums, formats et limites. Préférez plusieurs petits schémas à un objet universel rempli de champs facultatifs. Les descriptions doivent expliquer la signification métier, pas seulement répéter le nom. Versionnez le schéma comme une API dès que les objets sont persistés ou consommés ailleurs.
Valider après le modèle
Parsez et validez toujours côté serveur. Appliquez ensuite les règles métier : plage d’un montant, existence d’un identifiant, droit d’accès. Un JSON conforme peut contenir des données fausses ou dangereuses. Pour une erreur récupérable, renvoyez au modèle la violation avec une limite stricte de tentatives.
Cas limites
Testez champs manquants, caractères Unicode, très grands tableaux, valeurs nulles, refus du modèle, sortie tronquée et incompatibilité du fournisseur. Ne réutilisez pas partiellement un objet invalide pour une action externe. Journalisez le type d’erreur sans exposer les données sensibles.
FAQ
JSON Schema garantit-il la vérité ?
Non. Il contraint la forme, pas l’exactitude des valeurs.
Faut-il utiliser un outil fictif pour obtenir du JSON ?
Cela peut fonctionner, mais préférez la sortie structurée native lorsqu’elle existe.
Comment changer de fournisseur ?
Gardez un schéma interne et une couche d’adaptation, puis testez les différences de support.
Exemple : schéma strict avec Pydantic
Le schéma doit être validé par l’API ou le SDK, pas seulement décrit dans le prompt.
~~~python from pydantic import BaseModel, Field from openai import OpenAI
class Ticket(BaseModel): category: str priority: int = Field(ge=1, le=3) summary: str = Field(max_length=160)
client = OpenAI() response = client.responses.parse( model="gpt-4.1-mini", input="Le paiement a été débité deux fois.", text_format=Ticket, ) ticket = response.output_parsed print(ticket.model_dump()) ~~~
Prévoyez le cas où output_parsed est absent : refus du modèle, interruption ou réponse incomplète. Conservez le JSON brut pour le diagnostic, mais ne l’injectez pas directement dans une base. Validez aussi les contraintes métier après le parsing : un JSON syntaxiquement correct peut contenir une catégorie inconnue ou un identifiant inaccessible à l’utilisateur.