Sorties structurées avec l’IA : comment valider les données avant de les enregistrer ou d’agir

Un format exploitable ne garantit pas des données correctes

Une sortie structurée est une réponse de modèle organisée de façon à ce qu’une application puisse l’interpréter de manière prévisible : par exemple, un objet JSON comportant des champs et des types définis. Elle peut servir à extraire des données de documents, à classer des demandes ou à préparer des informations destinées à un autre composant. Son principal avantage est de réduire l’ambiguïté du format ; à elle seule, elle ne transforme pas le contenu généré en fait vérifié.

Il est utile de distinguer quatre questions. La réponse peut-elle être analysée comme du JSON ? Contient-elle les champs et les types convenus ? Ses valeurs sont-elles cohérentes entre elles et avec les informations d’origine ? Est-il autorisé de l’utiliser aux fins prévues ? Une réponse peut passer les premières vérifications et échouer à l’une des suivantes. Le fait qu’un objet contienne une date au format attendu ne prouve pas que cette date figure dans le document ; la présence d’une catégorie valide ne prouve pas que la classification soit correcte.

Cette distinction aide aussi à choisir le mécanisme de sortie. Un mode JSON ou une génération contrainte par un schéma visent à produire une réponse finale d’une forme déterminée. À l’inverse, un appel d’outil présente des arguments que l’application peut examiner avant de décider d’exécuter une opération. Des arguments bien formés n’autorisent pas automatiquement cette opération : son exécution reste sous le contrôle du système qui intègre le modèle.

Ce guide porte sur le contrat de données à vérifier à chaque exécution. Il ne remplace pas la gestion des changements de modèles, de SDK ou d’outils, qui exige de contrôler la compatibilité entre les versions. Même si l’API n’a pas changé, une entrée ambiguë, un document incomplet ou une interprétation erronée peuvent produire un résultat qu’il ne faut pas enregistrer comme confirmé.

Définir le contrat avant de rédiger le prompt

Commencez par réfléchir à l’usage qui sera fait de la réponse, et non par dresser une liste de champs qui semblerait pratique pour le modèle. Si un autre système doit enregistrer le résultat, précisez ce que représente chaque champ, son type et ce que l’application en fera. Un contrat utile limite les divergences d’interprétation entre le système qui génère la réponse et celui qui la consomme.

Pour chaque champ, décidez s’il est obligatoire, facultatif ou s’il peut être nul. N’utilisez pas une chaîne vide, une valeur fictive ou le chiffre zéro comme substitut universel à « inconnu » : ces valeurs peuvent être prises pour des informations réelles. Définissez également les unités — par exemple, la devise dans laquelle un montant est exprimé —, les formats de date, les limites acceptables et les énumérations autorisées. S’il existe des catégories, expliquez ce que chacune signifie et ce qu’il faut faire si aucune ne convient.

Les règles métier vont souvent au-delà des types. Un schéma peut autoriser deux montants numériques, alors que l’application peut exiger que le total corresponde à la somme des lignes, avec une tolérance définie. Il peut autoriser une valeur numérique pour le niveau de confiance sans pour autant définir un seuil adapté à la confirmation d’une donnée. Énoncez explicitement ces règles au lieu de supposer que le modèle les appliquera systématiquement.

La norme JSON Schema permet de décrire des structures et des contraintes, mais chaque canal d’un fournisseur peut ne prendre en charge qu’un sous-ensemble de ses possibilités. Avant de vous appuyer sur un mot-clé particulier, vérifiez la documentation en vigueur pour le modèle et le mode de sortie choisis. Si une contrainte n’est pas prise en charge par ce canal, vérifiez-la dans l’application ; ne la supprimez pas silencieusement et ne supposez pas que le modèle la respectera simplement parce qu’elle figure dans le prompt.

Choisir le canal en fonction du résultat attendu

Une sortie structurée finale convient lorsque l’application doit recevoir des données organisées sous forme de réponse. Le mode JSON peut orienter la forme générale ; la génération contrainte par un schéma peut imposer des restrictions supplémentaires si le fournisseur, le modèle et le canal les prennent en charge. Il ne s’agit pas de garanties universelles de véracité, et cela ne supprime pas la nécessité de valider la réponse reçue.

L’appel d’outil sert à proposer des arguments destinés à une fonction connue de l’application. Le processus ne s’arrête pas à la réception de ces arguments : le système les examine, décide s’il peut les exécuter et, le cas échéant, réalise l’opération. Cette séparation doit rester visible dans la conception. Un champ tel que « envoyer_paiement » ne devrait pas déclencher une opération simplement parce que le modèle l’a produit.

Avant de mettre une intégration en production, vérifiez comment le canal représente les résultats normaux, les réponses incomplètes et les refus. Ces états ne doivent pas être traités comme des objets valides simplement parce qu’ils apparaissent pendant une transmission ou peuvent être partiellement convertis en texte. Lors d’une réponse transmise par fragments, attendez de disposer d’un résultat final identifiable avant de prendre une décision métier.

Si une contrainte du schéma n’est pas compatible, adoptez une solution de remplacement explicite : validez cette contrainte localement, simplifiez le contrat sans perdre le contrôle essentiel, ou choisissez un canal compatible. Consignez cette différence. Un contrat qui semble strict dans le prompt, mais que le canal n’applique pas, peut donner un faux sentiment de sécurité.

Valider par couches, et non au moyen d’une seule vérification

La première couche concerne l’état de la réponse : déterminez si vous avez reçu une réponse finale exploitable ou si le fournisseur a signalé un refus, une interruption ou un résultat incomplet. Si le résultat est tronqué ou n’est pas terminé, ne le transformez pas en acceptation partielle, sauf si votre produit a défini et testé expressément ce comportement.

La deuxième couche porte sur l’analyse syntaxique et la structure. Vérifiez que le texte peut être interprété dans le format attendu, que l’objet racine possède le type convenu et que les champs, les types, les valeurs autorisées et les contraintes applicables sont valides. Ne négligez pas la gestion des erreurs d’analyse et ne convertissez pas automatiquement des valeurs au moyen d’une coercition ambiguë — du texte en nombre, par exemple — sans règle documentée.

La troisième couche examine le sens et les relations entre les champs. Vérifiez les plages, la cohérence, les combinaisons incompatibles et les conditions métier. La quatrième compare la proposition à l’entrée d’origine : une facture, un ticket ou une demande. Dans la mesure du possible, confirmez les données pertinentes à partir du document ou d’un registre autorisé. La cinquième détermine si l’utilisation est permise : afficher une suggestion n’a pas les mêmes conséquences que modifier un compte ou déclencher une opération externe.

Distinguez toujours la valeur proposée de la valeur confirmée. Si un champ nécessite une vérification, l’interface et le stockage doivent permettre de le représenter comme en attente ou non vérifié. Remplacer la preuve d’origine par une extraction incertaine rend l’erreur plus difficile à corriger et complique la reconstitution des raisons qui ont motivé une décision.

Trois parcours pratiques

Les exemples ci-dessous montrent comment une même conception distingue la forme de la réponse de son acceptation. Les champs sont donnés à titre d’illustration : une implémentation réelle doit les adapter aux documents, aux règles comptables, à la taxonomie et aux contrôles d’accès concernés.

blocks

Réagir aux échecs de manière contrôlée

Tous les échecs n’appellent pas la même réponse. Une erreur de format peut justifier une nouvelle génération assortie d’une instruction plus ciblée. Une réponse incomplète peut nécessiter une nouvelle demande ou l’arrêt du processus. Une contradiction avec la source peut exiger une vérification humaine. Une absence d’autorisation doit bloquer l’action, et non déclencher une nouvelle tentative destinée à obtenir une réponse plus commode.

Définissez à l’avance les situations dans lesquelles la réponse est acceptée, relancée, mise en quarantaine ou rejetée. Limitez les nouvelles tentatives et conservez le résultat qui a échoué afin de pouvoir comprendre ce qui s’est passé. Si le système effectue une nouvelle tentative, n’accumulez pas des réponses incompatibles et ne choisissez pas simplement celle qui semble la plus complète. Chaque tentative doit répondre à un objectif précis — corriger un champ manquant, par exemple — puis être soumise à nouveau aux mêmes validations.

Évitez les corrections silencieuses qui peuvent transformer un échec visible en donnée apparemment fiable. La normalisation des espaces ou d’une représentation dépourvue d’ambiguïté peut être sans risque si elle est documentée ; inventer un champ manquant, choisir entre deux montants contradictoires ou modifier une catégorie pour qu’elle satisfasse une règle ne l’est pas. Conservez assez d’informations pour distinguer la valeur d’origine de la valeur normalisée.

Tester et consigner l’ensemble du processus

Un test utile comprend des exemples ordinaires et des cas limites : champs absents, valeurs nulles, valeurs hors plage, documents flous ou contradictoires, catégories inadaptées, réponses incomplètes et demandes dépassant les permissions disponibles. Testez également chaque étape séparément. Vous pourrez ainsi distinguer une défaillance du canal de génération d’une erreur du validateur ou d’une règle métier trop restrictive.

Mesurez la proportion de réponses utilisables sans intervention, les erreurs par champ, les contradictions détectées, les refus, les nouvelles tentatives et les cas transmis pour vérification. Un taux élevé de conformité au schéma n’équivaut pas à un taux élevé d’exactitude sémantique. Suivez ces indicateurs séparément et examinez un échantillon des résultats acceptés en les comparant à la source d’origine.

Pour faciliter le débogage sans conserver de données superflues, gardez la version du schéma, l’identification du canal et du modèle lorsqu’elle est pertinente, l’état final de la réponse, le résultat de chaque couche de validation et la décision prise ensuite. N’enregistrez l’entrée ou une référence sécurisée à celle-ci que si la politique relative aux données l’autorise. Évitez de conserver par défaut des informations sensibles lorsqu’une référence, un résumé technique ou un indicateur d’erreur suffit.

Versionnez le contrat et classez ses modifications. Ajouter un champ facultatif peut être compatible avec des consommateurs capables de l’ignorer ; modifier le type d’un champ, changer le sens d’une catégorie ou rendre obligatoire un champ qui ne l’était pas peut les perturber. Testez les consommateurs et les migrations avant de déployer les changements, et conservez assez de traces pour savoir quelle version a produit chaque donnée.

Critère final : n’accepter que ce qui a été vérifié pour l’usage prévu

La décision d’accepter une sortie dépend de sa destination. Un brouillon présenté à une personne peut tolérer une certaine incertitude s’il est clairement signalé comme tel ; une donnée comptable confirmée ou une opération externe nécessite des contrôles plus stricts. Un schéma unique ne suffit pas à résoudre ces différences : le contrat décrit la forme, les règles métier vérifient le sens et les permissions encadrent l’action.

Avant de mettre le processus en service, assurez-vous de pouvoir répondre aux questions suivantes : qu’est-ce qui est validé, où cette validation a-t-elle lieu, quels éléments étayent chaque valeur, que se passe-t-il si une vérification échoue et qui peut autoriser l’étape suivante ? Si l’application ne distingue pas une proposition, une donnée vérifiée et une action approuvée, elle n’est pas encore prête à faire confiance à la sortie.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.