Sorties structurées et contrats JSON

Pourquoi structurer les sorties d'un modèle de langage

Tant qu'un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire produit du texte destiné à un lecteur humain, la forme importe peu : un paragraphe bien tourné suffit. Dès qu'un système logiciel doit lire cette sortie — l'insérer dans une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, déclencher une action, l'afficher dans une interface — la forme devient une contrainte de premier ordre. Un champ manquant, une virgule mal placée ou un type de donnée inattendu suffisent à faire échouer un pipeline entier.

Ce chapitre traite des techniques qui transforment un modèle de langage en composant fiable d'une chaîne logicielle : contrats JSON, schémas de validation, modes de génération contrainte et stratégies de récupération d'erreur. Il s'adresse à un usage professionnel, où la sortie d'un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire alimente du code, pas seulement un lecteur humain.

Un prompt qui fonctionne neuf fois sur dix en démonstration mais échoue une fois sur dix en production n'est pas fiable — il est instable. La structuration des sorties vise précisément à réduire cette variance à un niveau exploitable industriellement.

Le problème du texte libre parsé

L'approche naïve consiste à demander au modèle de répondre « au format JSON » dans le corps du prompt, puis à parser la réponse avec un simple appel de désérialisation générique. Cette approche fonctionne dans la majorité des cas, ce qui la rend trompeuse : les cas d'échec sont rares mais réels, et ils se manifestent presque toujours au pire moment, sur une entrée inhabituelle.

Les modes de défaillance typiques du texte libre supposé JSON :

• Le modèle encadre le JSON de texte explicatif (« Voici le JSON demandé : »).
• Le modèle utilise des apostrophes simples au lieu de guillemets doubles.
• Une virgule finale (trailing comma) invalide selon la norme JSON.
• La réponse est tronquée avant la fermeture de l'objet, faute d'espace dans la limite de tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire.
• Des balises Markdown (```json) entourent le contenu, sans que l'application s'y attende.

Corriger ces problèmes après coup, à coups d'expressions régulières et de nettoyage de chaînes, fonctionne temporairement mais reste fragile : chaque nouveau modèle, chaque changement de prompt peut introduire une variante inédite du même problème.

Les mécanismes natifs de sortie structurée

Les fournisseurs de modèles ont progressivement intégré des mécanismes qui déplacent la contrainte de format du prompt vers l'API elle-même.

Le mode JSON

Le mode JSON garantit que la sortie est un objet JSON syntaxiquement valide. Il ne garantit en revanche ni la présence des champs attendus, ni leur type, ni l'absence de champs supplémentaires inventés. C'est une garantie syntaxique, pas sémantique.

Le mode JSON avec schéma (structured outputs)

Une évolution plus récente permet de fournir un schéma JSON explicite que le modèle doit respecter au niveau du décodage : chaque token généré est contraint pour rester compatible avec la grammaire du schéma. Cette approche, parfois appelée génération contrainte ou decoding contraint, élimine une classe entière d'erreurs — un champ requis par le schéma est nécessairement présent, son type est nécessairement respecté.

Le function calling / tool use

Le mécanisme d'appel d'outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire permet de décrire une ou plusieurs fonctions disponibles, chacune avec une signature de paramètres au format JSON Schema. Le modèle ne génère pas une réponse en texte libre : il produit un appel de fonction avec des arguments structurés, que l'application intercepte avant toute exécution réelle. C'est aujourd'hui le mécanisme le plus robuste pour obtenir une sortie exploitable, et le socle de la plupart des architectures d'agentsagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire.

Un schéma respecté à la lettre n'empêche pas le modèle d'halluciner une valeur plausible mais fausse à l'intérieur d'un champ parfaitement bien typé. La structure garantit la forme, jamais le fond.

Concevoir un schéma JSON robuste

Un bon schéma pour le prompting professionnel partage les qualités d'un bon contrat d'interface logicielle : il est explicite, minimal, et anticipe les cas limites.

Champs obligatoires, champs optionnels

Chaque champ marqué comme obligatoire doit correspondre à une information que le modèle peut réellement produire à partir du contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire fourni. Rendre obligatoire un champ que le modèle ne peut pas déterminer avec certitude l'encourage à halluciner une valeur plutôt qu'à signaler une absence d'information.

Types stricts et énumérations

Préférer un type énuméré à une chaîne libre dès que l'ensemble des valeurs possibles est fini : un statut de commande, une catégorie de ticket, un niveau de priorité. Cela élimine la variabilité lexicale (« urgent », « Urgent », « URGENT », « haute priorité ») qui complique le traitement en aval.

Un exemple de schéma

{
  "type": "object",
  "properties": {
    "titre": { "type": "string" },
    "categorie": {
      "type": "string",
      "enum": ["facturation", "technique", "compte", "autre"]
    },
    "priorite": { "type": "integer", "minimum": 1, "maximum": 5 },
    "resume": { "type": "string", "maxLength": 280 },
    "necessite_escalade": { "type": "boolean" }
  },
  "required": ["titre", "categorie", "priorite", "resume", "necessite_escalade"],
  "additionalProperties": false
}

La propriété qui interdit les champs supplémentaires est souvent négligée alors qu'elle referme une source fréquente de dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire : sans elle, rien n'empêche le modèle d'ajouter des propriétés non prévues, que l'application ignorera silencieusement — ou pire, traitera par accident.

Formats et contraintes fines

Au-delà du type de base, JSON Schema permet d'exprimer des contraintes fines : un format de date au standard ISO 8601, un motif d'expression régulière pour un numéro de commande à la forme fixe, une longueur minimale ou maximale pour un champ texte. Ces contraintes ne sont pas toutes appliquées avec la même rigueur par le decoding contraint selon les fournisseurs — certaines sont vérifiées au niveau du modèle, d'autres restent purement documentaires et doivent être revérifiées côté application. Il ne faut jamais supposer qu'une contrainte présente dans le schéma est nécessairement appliquée par le modèle : la documentation du fournisseur précise, appel par appel, quelles clauses sont réellement contraignantes.

Guider la génération par le prompt

Même avec un schéma techniquement imposé par l'API, la qualité du contenu à l'intérieur de ce schéma dépend toujours du prompt.

Rappeler l'intention derrière chaque champ

Un nom de champ ne suffit pas toujours à lever l'ambiguïté. Une brève description associée à chaque propriété du schéma réduit les erreurs d'interprétation, en particulier pour les champs numériques (unité, échelle) ou les champs de texte (longueur attendue, registre).

Le few-shot structuré

Fournir un ou deux exemples complets de paire entrée/sortie reste l'un des leviers les plus efficaces, y compris en présence d'un schéma contraint. L'exemple montre non seulement la forme, mais le niveau de détail et le style attendus dans les champs textuels — deux dimensions qu'un schéma ne peut pas exprimer à lui seul.

Température et déterminisme

La génération structurée n'élimine pas la variabilité liée à la température. Un même schéma, appliqué deux fois à la même entrée avec une température élevée, peut produire deux catégorisations différentes pour un cas ambigu. Pour les tâches d'extraction ou de classification où la reproductibilité importe, une température basse complète utilement la contrainte de schéma : l'une garantit la forme, l'autre réduit la variance du contenu.

Placer le schéma et les instructions de format dans le message système, et réserver le message utilisateur au contenu à traiter. Cette séparation facilite la maintenance : le format évolue rarement, le contenu varie à chaque appel.

Valider et parser côté application

Aucun contrat de sortie, aussi bien conçu soit-il, ne dispense de valider la réponse côté application. La validation constitue la dernière ligne de défense avant qu'une donnée hallucinée ou mal formée n'atteigne un système en aval.

Bibliothèques de validation

Les bibliothèques de validation de schéma disponibles dans la plupart des langages permettent de définir un modèle de données une seule fois, et de l'utiliser à la fois pour générer le schéma JSON envoyé au modèle et pour valider la réponse reçue. Cette symétrie évite qu'un schéma de prompt et un schéma de validation divergent silencieusement au fil des évolutions du code.

Stratégie de nouvelle tentative

Lorsque la validation échoue, trois options existent, par ordre de coût croissant :

1. Réparation locale — corriger les erreurs mineures et déterministes (guillemets simples, virgule finale) sans repasser par le modèle.
2. Nouvelle tentative avec message d'erreur — renvoyer au modèle le JSON invalide accompagné du message d'erreur de validation, en lui demandant de corriger.
3. Nouvelle tentative complète — relancer la génération depuis le prompt initial, en abaissant éventuellement la température.

Dans la majorité des cas professionnels, la deuxième option offre le meilleur rapport entre fiabilité et coût : elle exploite la capacité du modèle à comprendre un message d'erreur structuré, sans repartir de zéro.

Un objet JSON bien formé peut contenir des valeurs sémantiquement absurdes : une date dans le futur pour un événement passé, un total qui ne correspond pas à la somme des lignes, un identifiant qui ne correspond à aucune entité connue. La validation de schéma vérifie la forme ; des règles métier complémentaires doivent vérifier la cohérence.

Pièges fréquents

Faire évoluer un schéma en production

Un schéma de sortie n'est pas figé : de nouveaux champs apparaissent, d'anciens deviennent obsolètes. Faire évoluer un schéma en production sans rupture suppose de traiter les anciennes réponses en cache ou en base comme un format versionné distinct, et d'ajouter les nouveaux champs comme optionnels avant de les rendre obligatoires, une fois le prompt et le code applicatif alignés. Un changement de schéma non coordonné entre le prompt et le code de validation est une source classique d'incidents silencieux : le modèle continue de répondre selon l'ancien format pendant que le code attend déjà le nouveau.

Un service de support reçoit des e-mails et doit en extraire un objet structuré (expéditeur, catégorie, urgence, résumé). Sans schéma contraint, environ 4 % des extractions produisaient un JSON invalide ou un champ d'urgence exprimé en texte libre (« assez urgent »). Le passage à un schéma avec valeurs énumérées pour l'urgence et une validation stricte a ramené le taux d'échec à moins de 0,5 %, le résidu étant traité par une nouvelle tentative automatique.

Cas d'usage professionnels

La sortie structurée trouve sa place dans quatre familles de scénarios récurrents :

• Extraction d'information — transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire un document, un e-mail ou une transcription en données exploitables par une base ou un tableau de bord.
• Classification — attribuer une catégorie, une priorité ou une étiquetteétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire parmi un ensemble fini de valeurs, avec un niveau de confiance associé.
• Orchestration d'agents — décrire une décision d'action (quel outil appeler, avec quels paramètres) dans les architectures où un modèle pilote des systèmes tiers via function callingappel d'outilsIAMécanisme par lequel un modèle produit un appel de fonction structuré que le code environnant décide d'exécuter. Le modèle n'a jamais d'accès direct : il propose, le code dispose.Voir dans le glossaire.
• Citation de sources — dans les systèmes de génération augmentée par la recherche, imposer un tableau de références structuré en complément de la réponse en texte libre, pour vérifier a posteriori qu'une affirmation s'appuie sur un document fourni plutôt que sur une paraphrase inventée.

Dans les quatre cas, la discipline est la même : définir le contrat avant d'écrire le prompt, pas après avoir constaté les premières erreurs de parsing.

Checklist avant mise en production

• Le schéma définit-il les champs obligatoires et interdit-il les champs supplémentaires ?
• Chaque champ ambigu porte-t-il une description explicite ?
• Le prompt contient-il au moins un exemple complet de sortie attendue ?
• La validation côté application est-elle indépendante du mode JSON de l'API ?
• Une stratégie de nouvelle tentative est-elle définie pour les échecs de validation ?
• Les échecs de parsing sont-ils journalisés avec l'entrée d'origine, pour analyse ultérieure ?
• Les champs numériques ou catégoriels critiques utilisent-ils un type contraint plutôt qu'une chaîne libre ?
• Une évolution du schéma est-elle accompagnée d'une période de transition côté validation ?

Conclusion

Structurer la sortie d'un modèle de langage revient à traiter le modèle comme un composant logiciel parmi d'autres : avec un contrat d'interface explicite, une validation systématique et une stratégie de gestion d'erreur. Les mécanismes natifs — mode JSON, decoding contraint, function calling — réduisent fortement la fréquence des erreurs de forme, mais ne dispensent jamais d'une validation applicative. Le chapitre suivant s'appuie sur ces contrats pour aborder l'enchaînement de plusieurs appels dans des chaînes de prompts.