Sorties structurées : le format garanti supprime une étape fragile

Une sortie structurée garantie est une réponse de modèle de langage contrainte à respecter un schéma fourni à l’avance, avec les champs, les types et les valeurs autorisées qu’il définit. Le modèle ne peut pas produire autre chose qu’un objet conforme.

La différence avec une simple consigne est de nature, pas de degré. Écrire dans le prompt « réponds en JSON avec les champs date et montant » augmente la probabilité d’obtenir le bon format. La garantie, elle, agit au moment de la génération : à chaque jeton, seuls les jetons compatibles avec le schéma restent possibles. Une accolade oubliée ou une phrase d’introduction deviennent impossibles, pas seulement improbables.

Le schéma s’écrit le plus souvent en JSON Schema : un objet, des propriétés nommées, un type pour chacune, une liste de champs obligatoires, éventuellement des énumérations. C’est un contrat lisible par un développeur, par un analyste métier et par le système qui consommera la sortie.

Un modèle qui produit du texte libre oblige à analyser ce texte pour en extraire des données, et cette analyse échoue régulièrement de façon imprévisible, ce que la garantie de format supprime. C’est une étape entière qui disparaît de la chaîne.

Le symptôme est connu de toute équipe ayant branché un modèle sur une chaîne automatisée. Le modèle produit un objet correct dans la grande majorité des cas, puis ajoute une phrase d’introduction, oublie une accolade, ou entoure sa réponse de balises de code. Chaque variante casse l’analyse.

La réponse habituelle consistait à empiler des rustines : nettoyer le texte, tenter plusieurs analyses, redemander au modèle en cas d’échec. Ce dispositif fonctionne, coûte des appels supplémentaires, et reste une source d’incidents. C’est l’un des cinq verrous qui empêchent de sortir du prototype : une chaîne qui casse sur une variante de forme n’est pas exploitable sans surveillance humaine.

Une sortie structurée garantit la forme de la réponse, c’est-à-dire les champs et leurs types, mais elle ne garantit jamais que le contenu de ces champs soit juste. C’est la distinction essentielle, et elle est fréquemment mal comprise.

Un modèle contraint produira toujours un objet valide, avec les champs demandés et les types demandés. Il ne garantit en rien que la date extraite soit la bonne date, ni que la catégorie choisie soit la bonne catégorie.

La conséquence est qu’on supprime une classe d’erreurs, les erreurs de forme, sans toucher à l’autre : les erreurs de fond. Le jeu de tests reste donc entièrement nécessaire, et il devient même plus lisible : puisque la sortie est structurée, la comparaison avec la réponse attendue devient automatisable champ par champ.

C’est un gain secondaire important. Une chaîne à sortie structurée est beaucoup plus facile à évaluer, ce qui rend praticable le dispositif décrit dans l’évaluation continue.

Trois niveaux de contrainte coexistent pour obtenir des données structurées d’un modèle : la consigne dans le prompt, le mode JSON et le format garanti par schéma. Seul le dernier dispense d’une couche de réparation.

Le mode JSON, proposé par plusieurs fournisseurs avant la garantie de schéma, assure une syntaxe valide mais pas la présence des bons champs : on obtient du JSON correct, pas forcément l’objet attendu.

La ligne « valeurs justes » est la même dans les trois colonnes. C’est elle qui justifie de garder un jeu de tests, quel que soit le niveau de contrainte retenu.

Migrer une chaîne existante vers un format garanti se fait en cinq étapes, de l’écriture du schéma jusqu’au retrait explicite du code de réparation devenu inutile. L’ordre compte : on ne retire rien avant d’avoir mesuré.

1. Écrire le schéma à partir de l’usage. Partir de ce que le système aval consomme réellement, champ par champ, et non de ce que le modèle sait produire.
2. Fermer et prévoir le doute. Remplacer chaque texte libre qui peut l’être par une énumération, et ajouter une valeur « indéterminé » partout où l’information peut manquer.
3. Rejouer le jeu de tests. Comparer l’ancienne chaîne et la nouvelle sur les mêmes cas, champ par champ. Le taux d’erreurs de forme doit tomber ; le taux d’erreurs de fond ne doit pas monter.
4. Inventorier la couche de fiabilisation. Lister chaque nettoyage, chaque reprise, chaque nouvelle tentative, avec l’incident qui l’a motivée quand on le retrouve.
5. Retirer, puis surveiller. Supprimer ce qui ne sert plus et garder uniquement les contrôles métier, par exemple une date d’échéance antérieure à la date de signature.

La troisième étape est la plus souvent sautée. Elle est pourtant la seule qui permette d’affirmer que la migration n’a rien dégradé.

Demander vingt champs en un seul appel dégrade la qualité de chacun, alors que deux appels de dix champs coûtent à peine plus cher et produisent de meilleurs résultats. C’est le réglage que les équipes découvrent après coup.

Le mécanisme tient à l’attention du modèle : plus la sortie demandée est vaste, moins chaque champ reçoit de soin. Un schéma qui demande simultanément une classification, une extraction de dates, un résumé et une évaluation de risque produit les quatre médiocrement.

La règle empirique que j’applique : un appel, une intention. Extraire les données factuelles d’un côté, porter un jugement de l’autre. Cela double le nombre d’appels et améliore sensiblement les deux résultats.

Ce découpage a un second bénéfice : il permet d’envoyer chaque intention au palier de modèle qui lui convient. L’extraction part sur un petit modèle, le jugement sur un grand, ce qui compense largement le coût du second appel. C’est le raisonnement de Claude 3 : choisir le palier, que la baisse de prix des petits modèles rend encore plus rentable, comme le montre GPT-4o mini et les usages qui basculent.

Une sortie garantie rend un modèle branchable sur un système d’information sans couche de traduction, ce qui déplace le travail d’intégration de la rustine technique vers la spécification métier. C’est le changement structurel de fond.

Jusqu’ici, brancher un modèle sur un progiciel supposait une couche intermédiaire chargée de fiabiliser la sortie : nettoyage, validation, reprise sur erreur. Cette couche représentait souvent une part importante du code.

Elle disparaît en grande partie. Ce qui reste est le travail utile : décider quels champs sont nécessaires, quelles valeurs sont admissibles, que faire en cas de doute. Autrement dit, un travail de spécification métier plutôt qu’un travail de rustine technique.

C’est une bonne nouvelle pour la maintenabilité : une spécification se relit et se modifie, contrairement à une accumulation de correctifs dont personne ne se rappelle la raison.

La même logique vaut quand le modèle déclenche des actions. Un appel d’outil dont les arguments sont garantis conformes n’échoue plus sur une faute de syntaxe ; il peut encore échouer sur un mauvais choix, ce qui ramène à la question du périmètre à fixer avant l’autonomie d’un agent.

Le format garanti rend largement inutile la couche de fiabilisation de sortie, ce code de nettoyage et de reprise accumulé autour du modèle, qui pèse souvent lourd dans une chaîne existante. C’est un gain de maintenabilité rare.

Sur les systèmes que j’ai repris, cette couche représentait entre un cinquième et un tiers du code. C’est une observation sur un nombre limité de projets, pas une mesure générale : la proportion dépend de l’ancienneté de la chaîne et du nombre d’incidents qu’elle a traversés.

Ce code a une caractéristique commune : il s’est accumulé par incidents. Une exception un jour, un correctif ; une variante de format le mois suivant, un autre correctif. Au bout d’un an, personne ne sait plus quelles branches sont encore nécessaires, et personne n’ose les retirer.

La migration vers un format garanti offre l’occasion de nettoyer, à condition de le faire explicitement. Sans cette décision, la couche reste en place « au cas où » et continue d’être maintenue sans raison. Voir la dette technique d’un système d’IA.

Les erreurs les plus fréquentes avec les sorties structurées viennent d’une confiance excessive dans le format, qui pousse à oublier que le contenu reste faillible. Elles se repèrent toutes avant la mise en production.

• Rendre tous les champs obligatoires sans issue. Un champ obligatoire sans valeur « indéterminé » oblige le modèle à inventer quand l’information manque.
• Laisser des textes libres là où une liste suffit. Chaque champ libre est un champ qu’on ne peut pas vérifier automatiquement.
• Supprimer les tests avec la couche de réparation. Les tests de forme deviennent inutiles ; les tests de fond restent indispensables.
• Changer le schéma sans versionner. Le schéma est un contrat avec le système aval ; il se versionne et se documente comme le prompt système qui doit tenir six mois.
• Oublier les changements de modèle. Un modèle mis à jour respecte toujours le format, mais peut remplir les champs différemment ; seul le jeu de tests le détecte, comme le montre le jour où le modèle a changé sans prévenir.