Pourquoi les applications d’IA ont-elles besoin de sorties structurées ?
Les applications d’IA ont besoin de sorties structurées, car un logiciel ne peut pas interpréter de manière fiable un paragraphe rédigé sur un ton convivial : il lui faut les mêmes champs, avec les mêmes noms et les mêmes types, à chaque fois. Une phrase en trop ou un champ manquant peut bloquer l’étape suivante de votre application.
Imaginez une jeune entreprise fictive de logistique de 12 personnes, Parcelwise. Sa développeuse, Sana, crée un outil qui lit les e-mails des clients et remplit un formulaire de modification de livraison : référence de commande, date souhaitée, nouvelle adresse et éventuelle demande de remboursement. Voici un e-mail typique : 'Bonjour, commande PW-88213, je ne serai pas là jeudi, vous pouvez livrer samedi à la place ? Ou laisser au n° 14. Sinon annulez et remboursez svp.' Sa première version demande au modèle de 'répondre en JSON'. La plupart des réponses peuvent être analysées, mais certaines commencent par 'Bien sûr, voici le JSON', d’autres nomment le champ 'date' au lieu de 'requested_date', et l’une renvoie la date sous la forme 'samedi'.
Qu’est-ce qu’un schéma JSON et en quoi est-il utile ?
Un schéma JSON décrit formellement les données attendues : les champs présents, ceux qui sont obligatoires, le type de chacun et les valeurs autorisées. Fournir un schéma au modèle transforme la demande 'veuillez répondre en JSON' en un contrat que votre code peut vérifier.
Pour Sana, le schéma précise que : order_reference est une chaîne de caractères obligatoire ; requested_date est une chaîne de caractères obligatoire au format date, ou null si aucune date n’a été fournie ; new_address est une chaîne de caractères ou null ; refund_requested est un booléen obligatoire ; et aucun autre champ n’est autorisé. Cette dernière règle empêche le modèle d’ajouter des champs de commentaire.
Comment les API des modèles permettent-elles d’obtenir des sorties structurées ?
Les API des principaux modèles vous permettent de joindre un schéma JSON à la requête, et la sortie du modèle est contrainte de le respecter.
OpenAI
La fonctionnalité de sorties structurées d’OpenAI impose aux réponses de respecter un schéma JSON fourni lorsque le mode strict est activé. Sa documentation la distingue de l’ancien mode JSON, qui garantit uniquement un JSON valide, sans garantir le respect de votre schéma, et recommande les sorties structurées lorsqu’elles sont disponibles.
Anthropic
L’API de Claude propose des sorties JSON conformes au schéma que vous fournissez, ainsi qu’une option stricte dans les définitions d’outils pour valider les données d’entrée de chaque outil par rapport à son schéma. Sa documentation indique quelles fonctionnalités de schéma sont prises en charge et lesquelles renvoient une erreur.
L’API Gemini accepte un schéma JSON pour les réponses et prend en charge un sous-ensemble défini de mots-clés de schéma. Sa documentation indique que, même si la sortie est un JSON syntaxiquement correct, vous devez tout de même valider les valeurs dans votre application.
Pourquoi avez-vous toujours besoin de valider les résultats et de prévoir de nouvelles tentatives ?
La validation reste nécessaire, car un schéma contrôle la structure des données, pas l’exactitude des valeurs. Une réponse parfaitement structurée peut tout de même contenir une date erronée, une référence de commande inventée ou une indication de remboursement que le client n’a jamais demandé.
Validez à deux niveaux. Vérifiez d’abord la structure avec une bibliothèque de schémas, comme Pydantic en Python ou Zod en JavaScript, que les documentations d’OpenAI, d’Anthropic et de Google présentent toutes dans leurs exemples. Vérifiez ensuite les règles métier : la référence de commande respecte-t-elle le format attendu et existe-t-elle dans le système, la date est-elle à venir et correspond-elle à un jour de livraison, et l’adresse se trouve-t-elle dans une zone de livraison ? Gérez également les cas documentés par les fournisseurs : un refus, qui peut ne pas respecter votre schéma, et une réponse interrompue par la limite maximale de jetons, qui laisse un JSON incomplet.
Relancez avec précaution. Si une vérification échoue, effectuez une nouvelle tentative en précisant l’erreur, par exemple 'requested_date doit être une date ; l’e-mail indique samedi, et la date de la commande est le 14 October'. Limitez les nouvelles tentatives à une ou deux, puis transmettez l’e-mail à une personne.
À quoi ressemble une sortie structurée fragile ou robuste ?
Version peu fiable : l’instruction dit « Extrayez les détails et répondez au format JSON. » L’application lit tout ce qu’elle reçoit. Pour l’e-mail ci-dessus, elle reçoit des champs nommés order et date, une date dont la valeur est « samedi » et une valeur de remboursement définie sur true, car le modèle a interprété « sinon, annulez simplement » comme une demande ferme. Le formulaire est mal rempli et le client reçoit un remboursement qu’il ne souhaitait pas.
Version robuste : la requête inclut le schéma de Sana en mode strict, et l’instruction explique chaque champ, notamment 'refund_requested vaut true uniquement si le client demande un remboursement sans condition'. Le modèle renvoie order_reference avec la valeur PW-88213, requested_date avec la date du samedi suivant, new_address avec la valeur null, refund_requested avec la valeur false et conditional_request, un champ que Sana a ajouté au schéma précisément pour ce cas, avec la valeur 'rembourser si la livraison le samedi ou chez un voisin est impossible'. La validation confirme que la commande existe et que le samedi est un jour de livraison. Comme l’e-mail contient une demande conditionnelle, les règles le transmettent à une personne pour la décision finale.
Quelles sont les erreurs courantes avec les sorties structurées ?
L’erreur la plus courante est de considérer qu’un JSON valide contient nécessairement des données correctes. Autres erreurs : s’appuyer uniquement sur les consignes alors que l’API permet d’imposer un schéma, utiliser des noms de champs vagues sans description, forcer une valeur alors que la réponse honnête est null, ignorer les refus et les réponses tronquées et réessayer sans indiquer au modèle ce qui n’allait pas.
Quelle place les sorties structurées occupent-elles dans le catalogue Tosheo.ai ?
La sortie structurée est une leçon de programmation du cours de création d’applications d’IA, dans la catégorie Création d’applications d’IA. La version pratique complète avec du code, où vous définissez un schéma, appelez une API, validez les réponses et ajoutez une nouvelle tentative, est accessible dans le parcours Programmation après inscription. Chaque étape fait l’objet d’un retour fondé sur une grille d’évaluation.