Sorties structurées pour LLM

Vous extrayez une date, une catégorie et une liste d’actions depuis un message. Si le modèle répond en prose libre, le code doit deviner où se trouve chaque valeur. Une sortie structurée remplace cette convention fragile par un contrat lisible par le programme.

Une sortie structurée pour LLM décrit la forme attendue avec un schéma, souvent JSON Schema. Le schéma peut exiger des propriétés, des types, des listes ou des valeurs autorisées. JSON Schema sert à décrire la structure de données JSON et à appliquer des contraintes aux valeurs reçues. [S2]

Dans l’API OpenAI, Structured Outputs peut imposer le respect du schéma fourni. Cette garantie est plus forte qu’un mode JSON, qui garantit un JSON valide sans garantir la présence des bonnes propriétés ni les valeurs autorisées. [S1]

Quand utiliser un schéma ?

Utilisez une sortie structurée lorsque le résultat doit être consommé par un système :

• créer une interface à partir de champs connus ;
• extraire des informations depuis un texte ou un document ;
• classer une demande dans des catégories définies ;
• préparer les paramètres d’un outil ;
• comparer automatiquement le résultat à des critères ;
• enregistrer un résultat avec un contrat de données versionné.

Gardez une réponse en texte libre lorsque seule une personne doit la lire et qu’aucun traitement automatique ne dépend de sa structure. Un schéma trop détaillé peut aussi déplacer la complexité vers une longue définition difficile à maintenir.

Ce que le schéma garantit

Les contrôles forment plusieurs niveaux distincts.

Niveau	Question vérifiée	Exemple
JSON valide	Le résultat peut-il être analysé comme du JSON ?	Les guillemets et accolades sont corrects
Conformité au schéma	Les propriétés, types et valeurs autorisées sont-ils respectés ?	priority vaut low, medium ou high
Validation métier	Les valeurs sont-elles cohérentes pour ce cas ?	Une date de fin ne précède pas la date de début
Exactitude	Les valeurs correspondent-elles à la source ou au monde réel ?	Le montant extrait est bien celui du document
Autorisation	L’action décrite peut-elle être exécutée ?	La personne a le droit d’envoyer ou de supprimer

Pour une réponse complète qui n’est pas un refus, Structured Outputs impose la conformité au schéma pris en charge. Il rend également un refus de sécurité détectable par le programme. Une réponse peut toutefois être incomplète, notamment si la limite de sortie est atteinte, ou prendre la forme d’un refus qui doit être traité séparément. [S1]

Le schéma ne vérifie pas l’exactitude d’une valeur. Une chaîne conforme peut contenir un nom inventé. Un nombre valide peut provenir du mauvais passage. Ajoutez donc une validation sémantique ou métier après l’analyse du JSON.

Concevoir le contrat

1. Partez du consommateur. Listez seulement les champs dont le code ou la personne a besoin.
2. Nommez chaque propriété sans ambiguïté. Une description explique son sens, son unité et sa provenance attendue.
3. Utilisez des types et valeurs bornées. Préférez une énumération connue à une catégorie libre lorsque le domaine est fermé.
4. Rendez l’absence explicite. Choisissez entre une valeur nullable, un état unknown ou un refus de traiter. Ne laissez pas le modèle inventer pour remplir un champ obligatoire.
5. Refusez les propriétés inattendues lorsque le fournisseur le permet. Le contrat reste ainsi fermé aux champs que le consommateur ne connaît pas.
6. Vérifiez le sous-ensemble pris en charge. Un fournisseur peut n’accepter qu’une partie de JSON Schema ou imposer des règles supplémentaires. [S1]
7. Versionnez les changements incompatibles. Un champ renommé ou une valeur supprimée modifie le contrat avec le consommateur.

Traiter chaque résultat

Le chemin de traitement doit rester explicite :

1. vérifier l’état global de la réponse ;
2. détecter un refus ou une sortie incomplète ;
3. analyser les données selon le schéma ;
4. appliquer les règles métier déterministes ;
5. vérifier les valeurs décisives contre leur source lorsque c’est possible ;
6. demander une approbation avant un effet sensible ;
7. journaliser la version du schéma et le résultat du contrôle sans conserver inutilement de données sensibles.

Une sortie conforme ne doit jamais être exécutée aveuglément. Le code garde la responsabilité des autorisations, des limites de montant, des destinataires permis et des autres règles qui ne peuvent pas dépendre de l’interprétation du modèle.

Évaluer le contenu, pas seulement le JSON

Un test qui vérifie seulement que le JSON est valide mesure le contrat technique, pas la qualité de la fonction IA. Construisez des cas représentatifs avec les valeurs attendues, les absences, les ambiguïtés, les documents contradictoires et les entrées qui doivent produire un refus.

Définissez l’objectif, les données de test et les critères avant de comparer les résultats. Combinez les contrôles automatiques avec un jugement humain pour vérifier que les métriques mesurent bien le besoin réel. [S3]

Mesurez séparément :

• le taux de réponses analysables ;
• le respect des règles métier ;
• l’exactitude de chaque champ important ;
• les faux refus et les réponses qui auraient dû s’abstenir ;
• le coût, le délai et les changements après une nouvelle version du modèle ou du schéma.

Une sortie structurée est utile lorsqu’un système attend un contrat stable. Utilisez le schéma pour contrôler la forme, puis gardez le code, les évaluations et la revue humaine responsables du sens et des effets.