Une fonctionnalité lit des factures et en extrait le montant. Pendant des semaines, le modèle renvoie un nombre. Un jour, il répond « Le montant semble être d'environ 1 200 euros ». Un humain comprend. Le logiciel, qui attendait un nombre, tombe en erreur. Dès qu'un programme utilise la réponse d'un modèle, le texte libre ne suffit plus.
Trois niveaux de contrôle
Le premier niveau est le texte libre : vous décrivez le format voulu dans les instructions. Le modèle le respecte souvent, pas toujours.
Le deuxième niveau est le mode JSON. JSON est un format de données qu'un programme sait lire. En octobre 2026, la documentation d'OpenAI précise que ce mode garantit un JSON valide, mais pas les champs attendus : la réponse se lit sans erreur, mais le montant peut quand même manquer.
Le troisième niveau est la sortie contrainte par un schéma : une réponse au format fixé d'avance. Le schéma décrit les champs de la réponse, leur type et les valeurs permises. L'API oblige le modèle à s'y conformer. En octobre 2026, selon leur documentation, Anthropic, OpenAI et Google proposent tous les trois ce mode.
Schéma : chaque champ est présent et typé, donc le bon montant et un mauvais montant au même format passent tous deux les contrôles de forme. Le schéma garantit la forme, pas la justesse : ce sont les évals qui la mesurent.
Concept clé
Une sortie structurée est un contrat : un schéma fixe les champs de la réponse, leur type et leurs valeurs permises. Ce contrat garantit la forme de la réponse, pas sa justesse. Le code vérifie la forme avant tout usage ; les évals (pour « évaluations ») mesurent la justesse.
Les outils reposent sur la même idée. Quand un modèle appelle un outil, par exemple pour créer un ticket ou consulter un stock, il remplit des paramètres décrits par un schéma. En octobre 2026, la documentation d'Anthropic indique qu'une option stricte garantit que ces appels respectent exactement le schéma. Elle prévient aussi qu'en l'absence d'une information, le modèle peut deviner une valeur que personne ne lui a fournie.
Ce que le schéma ne garantit pas
Un schéma ne rend pas la réponse vraie. Un montant au bon format peut être le mauvais montant, et une catégorie prise dans la liste peut être la mauvaise. En octobre 2026, la documentation de Google demande d'ailleurs de prévoir le cas de sorties conformes au schéma mais incorrectes sur le fond.
Il ne rend pas non plus fiable une note de confiance. Si le schéma demande au modèle d'évaluer sa confiance, vous obtenez un nombre bien formé, pas une probabilité calibrée. La page Les autres familles de modèles explique ce qu'est le calibrage.
Enfin, la garantie a des exceptions. En octobre 2026, les documentations d'Anthropic et d'OpenAI le précisent : un refus du modèle, ou une réponse coupée par la limite de longueur, peut sortir du schéma. Le code doit donc valider chaque réponse, même contrainte.
Le code valide chaque réponse avant tout usage, même une réponse contrainte par un schéma.
Laisser une place au « je ne sais pas »
Une liste fermée de valeurs, par exemple les cinq catégories de tickets de votre support, empêche le modèle d'inventer une sixième catégorie. C'est le premier usage du schéma contre les hallucinations.
Mais un champ obligatoire force aussi une réponse. Si la facture ne porte pas de numéro de commande et que le schéma en exige un, le modèle en écrira un quand même, quitte à l'inventer. Ajoutez donc une valeur « inconnu », ou autorisez un champ vide, partout où l'information peut manquer. Décidez ensuite ce que fait le produit dans ce cas : demander à l'utilisateur, passer la main à un humain ou laisser le champ vide.
Valeur « inconnu » permise : le champ dit inconnu, et le produit passe la main à un humain au lieu d'envoyer un numéro inventé à la comptabilité.
Ce que ça change pour vous
Pour les product managers
Écrivez le schéma dans la spécification, pas après : les champs, les valeurs permises et le comportement prévu quand la réponse est « inconnu ». C'est une décision produit, pas un détail technique. Ce schéma sert ensuite de base aux cas de test, que traite la leçon 4 du cours Cadrer une fonctionnalité IA.
Pour les tech leads
Validez chaque réponse dans le code, même avec une sortie typée garantie par l'API. Le schéma ne porte pas toutes vos règles métier : en octobre 2026, selon sa documentation, l'API d'Anthropic n'applique pas les bornes numériques, comme un montant minimum. En cas d'échec, relancez l'appel une fois en joignant l'erreur de validation. Si l'échec persiste, passez au comportement de repli et gardez une trace de l'incident. Versionnez le schéma comme une API.
Pour les fondateurs
La sortie structurée transforme une démo en fonctionnalité que l'on peut brancher sur votre CRM, votre facturation ou votre outil de support. Elle rend aussi la qualité mesurable sans relire chaque réponse. Quand un client grand compte demande comment vous contrôlez l'IA, un schéma vérifié à chaque réponse est un premier élément concret.
Pour aller plus loinNoter une sortie structurée
Une réponse en texte libre se note mal : il faut un humain, ou un modèle comme juge. Une sortie structurée se compare champ par champ au résultat attendu. Un script vérifie que la catégorie est la bonne, que le montant correspond et que le champ vaut bien « inconnu » quand l'information manque. La note devient automatique et peu coûteuse. Vous voyez aussi quel champ échoue. Les champs de texte libre, comme un résumé, demandent toujours une autre méthode. La page Les évaluations (évals) détaille ces méthodes.
L'erreur classique
fAIling RÈGLE VII
Le piège : Les hallucinations sont juste des suggestions créatives
Un schéma donne à une invention l'air d'une donnée. Un numéro de commande inventé, au bon format, passe tous les contrôles de forme et file jusqu'à la comptabilité. Un format valide n'est pas une réponse juste : vérifiez les valeurs, et laissez au modèle le droit de répondre « inconnu ».
Lire la règle VII du manifesteÀ essayer
Prenez vingt messages réels reçus par votre équipe : demandes clients, factures ou tickets. Choisissez trois informations à en extraire, avec leurs valeurs permises et une valeur « inconnu ». Remplissez le tableau à la main. Avant de confier ces messages à un assistant IA, retirez-en les noms, les adresses e-mail ou postales et les numéros de compte, ou utilisez un outil que votre entreprise a validé pour ces données. Demandez-lui ensuite de remplir le même tableau, et comparez champ par champ. Comptez surtout les cases où vous aviez mis « inconnu » et où l'assistant a donné une valeur.
Autour du sujet
Pour aller plus loinLes limites des schémas, relevées en octobre 2026
Aucun des trois fournisseurs n'applique toute la norme JSON Schema. Chez Anthropic, les bornes numériques et les longueurs de texte ne sont pas appliquées. Chez OpenAI, tous les champs doivent être obligatoires : une information facultative doit donc accepter une valeur vide. Google demande de vérifier côté application les contraintes que Gemini n'applique pas. Gardez des schémas simples, et placez les règles métier dans votre code.
Pour aller plus loinValider, c'est déjà un garde-fou
Vérifier une sortie avant de l'utiliser est un premier garde-fou : le format, mais aussi les valeurs, comme un montant plafonné ou un client qui existe dans votre base. Une sortie structurée rend ces contrôles simples à écrire. Elle ne dit pas lesquels écrire : cela dépend du coût d'une erreur.
Quoi en faire
Dès qu'un programme utilise la réponse, contraignez-la par un schéma : ses champs, leur type et leurs valeurs permises.
Validez chaque réponse dans le code ; en cas d'échec, réessayez une fois avec l'erreur jointe, puis passez au comportement de repli et gardez une trace de l'incident.
Prévoyez une valeur « inconnu » partout où l'information peut manquer : sinon, un champ obligatoire pousse le modèle à en inventer une.