Ce qu’il faut retenir
- Un schéma contrôle la forme et certaines contraintes. Il ne certifie pas que les valeurs correspondent au document ou au monde réel.
- Absence, ambiguïté et erreur de traitement doivent avoir des états distincts dans la sortie.
- La validation doit progresser du format aux règles métier, puis à la preuve et à l’autorisation d’agir.
Références techniques consultées le 1er octobre 2026. Les capacités de génération contrainte varient selon le moteur utilisé.
Le modèle retourne un objet parfaitement analysable : une date, un montant et une référence. Toutes les clés sont présentes, le montant est positif et la date respecte le format attendu. Le document d’origine ne contient pourtant aucune date d’échéance. Pour satisfaire la consigne, le système a rempli une valeur plausible. L’intégration est robuste au format et fragile à la vérité.
Ce que valide réellement JSON Schema
JSON Schema décrit des contraintes sur un document JSON. Il permet notamment d’indiquer types, propriétés attendues, champs obligatoires et valeurs autorisées. La documentation officielle sur les objets précise que déclarer des propriétés ne les rend pas obligatoires et que les propriétés supplémentaires sont autorisées par défaut, sauf contrainte explicite.
Ces détails comptent pour un contrat d’API. Un objet vide peut être valide si le schéma ne requiert aucune propriété. Une clé inconnue peut traverser la validation si elle n’est pas interdite. À l’inverse, un schéma trop fermé peut casser une évolution légitime. Le contrat doit correspondre à la version comprise par le consommateur et aux capacités du validateur choisi.
La génération contrainte peut réduire les réponses non conformes, mais elle ne remplace pas une validation côté application. Un fournisseur peut prendre en charge un sous-ensemble de la spécification. Les refus, erreurs, interruptions et résultats incomplets appartiennent aussi au contrat d’échange ; ils ne doivent pas être forcés dans l’objet d’une réussite.
Quatre étages de validation
| Étage | Ce qu’il établit | Ce qu’il ne prouve pas |
|---|---|---|
| Syntaxe | Le JSON peut être analysé | Les champs utiles sont présents |
| Schéma | Types et contraintes déclarées sont respectés | Les valeurs sont fidèles à la source |
| Métier | Relations et règles du processus sont cohérentes | La donnée de départ est vraie |
| Preuve et autorisation | Valeur soutenue, objet et action contrôlés | Toutes les situations futures seront correctes |
Une somme positive appartient au schéma. La cohérence entre plusieurs montants peut appartenir au code métier. Le fait que le montant soit bien celui à payer exige la lecture de son origine. Le droit de l’utiliser pour une action exige une autorisation. Ces contrôles répondent à des questions différentes et doivent avoir des erreurs distinctes.
Le dossier sur les intégrations API donne le contexte de ce contrat. Une sortie structurée est utile quand le logiciel suivant sait traiter ses états, ses versions et ses erreurs. Remplacer une réponse en prose par du JSON sans adapter le consommateur ne règle pas le problème de confiance.
Rendre l’absence représentable
Un champ obligatoire peut décrire un état sans exiger une valeur inventée. Par exemple, chaque élément contient un statut parmi « présent », « absent », « ambigu » et « illisible », une valeur lorsque le statut le permet, ainsi qu’une référence de preuve. Les relations entre état et valeur doivent être vérifiées par le schéma ou par un contrôle complémentaire explicite.
La valeur null n’est pas équivalente à une propriété absente, comme le rappelle la documentation JSON Schema. Sa signification métier doit être définie. « Pas trouvé » et « non applicable » entraînent souvent des actions différentes. Une chaîne vide ne constitue pas un langage de statuts acceptable si chaque consommateur l’interprète à sa façon.
Conserver le texte brut utile à la vérification, avec l’emplacement ou l’identifiant de source. Cette preuve ne doit pas devenir une copie illimitée de la pièce. Elle respecte le périmètre d’accès et la durée prévue. Pour une donnée tirée de plusieurs passages, l’origine doit montrer ces passages plutôt qu’un lien vague vers le document entier.
Une extraction qui se trompe tout en respectant le contrat
Scénario hypothétique. Une application prépare une fiche fournisseur depuis un PDF. Le schéma exige un nom, une référence et un montant. Le document contient deux références, l’une pour le client et l’autre pour la facture. Le modèle choisit la première. La sortie respecte chaque type, mais la fiche ne peut pas être rapprochée correctement.
La recette ajoute des pièces avec références voisines, champs absents et mises en page variables. Chaque valeur exige une origine relisible. Un contrôle compare le libellé et l’emplacement à la règle métier. Si le choix reste ambigu, la fiche rejoint une file humaine au lieu de produire silencieusement un identifiant plausible.
La sortie validée prépare une opération ; elle n’autorise pas à modifier une fiche existante sur la base d’un rapprochement incertain. Une deuxième étape contrôle l’objet exact et le droit de mise à jour. Pour des coordonnées bancaires, une validation documentaire ne remplace pas le circuit de vérification prévu par l’entreprise.
Mesurer les bonnes erreurs
- Tester le schéma avec des cas négatifs. Types incorrects, clés absentes, propriétés supplémentaires et incompatibilités entre statuts et valeurs.
- Tester les données sur un lot annoté. Champs corrects, absents, ambigus et confusions de libellés.
- Tester les règles métier. Relations entre champs, formats normalisés et critères de rapprochement.
- Tester le consommateur. Vérifier qu’il n’utilise pas une valeur ambiguë et ne transforme pas un refus en réussite vide.
- Rejouer après changement. Conserver versions du schéma, du modèle et de la normalisation pour expliquer les régressions.
Le tableau de suivi distingue JSON analysable, schéma valide, champs fidèles et tâches acceptées. Un taux de conformité de format élevé ne doit pas être présenté comme taux d’exactitude. Les erreurs critiques restent visibles par famille et champ. La documentation scikit-learn sur les métriques fournit les définitions utiles lorsque l’on mesure repérage, précision et rappel.
Les sorties abandonnées, interrompues ou refusées entrent dans le bilan. Une chaîne qui ne produit que les cas faciles peut afficher une bonne précision sur sa sortie tout en couvrant peu de demandes. Mesurer la couverture et les corrections humaines permet de juger le résultat opérationnel.
Retenter sans fabriquer une vérité
Un nouvel essai peut réparer un objet tronqué ou une erreur transitoire. Il ne doit pas forcer une valeur absente. Une consigne de réparation qui dit « remplis tous les champs » peut accroître le taux de schéma valide et dégrader la fidélité documentaire. La réparation doit conserver le droit de signaler l’absence.
Limiter le nombre de tentatives et enregistrer leur cause. Les reprises contribuent au coût réel d’une application IA. Le coût par objet conforme n’est utile que si les objets conformes sont ensuite acceptables pour la tâche. La comparaison doit inclure contrôle, rejet et temps de correction.
Un agent utilisant des outils MCP peut convertir un objet structuré en appel. Le service d’exécution vérifie les paramètres, la ressource et l’autorisation indépendamment du modèle. La forme attendue rend l’appel plus facile à analyser ; elle ne lui donne pas une légitimité.
Un schéma n’est pas une barrière universelle
Un champ de texte peut contenir une instruction malveillante, du HTML ou une valeur destinée à influencer un autre modèle. Une URL peut viser une destination interdite. Les étapes suivantes appliquent leurs propres règles de rendu et de sécurité. L’article sur la cybersécurité des agents rappelle pourquoi le contrôle doit suivre les effets possibles.
Une valeur issue de génération reste une donnée à vérifier. Elle ne devient pas du code de confiance parce qu’un objet valide l’enveloppe. Préférer des opérations limitées, des paramètres explicitement contrôlés et des erreurs compréhensibles par le consommateur évite de déplacer le risque dans le logiciel suivant.
Le contrat utile garde une place au doute
Un bon schéma montre les informations présentes et ce que le système n’a pas pu établir. Il permet au produit d’orienter la demande vers correction, clarification ou validation. L’équipe peut alors automatiser les cas maîtrisés et mesurer précisément les autres.
Avant de déclarer une extraction prête, confronter quelques sorties parfaitement valides aux documents d’origine. Les différences trouvées donnent les contrôles à ajouter. La réussite finale est une tâche fidèle, autorisée et traçable ; la validité du JSON est une étape nécessaire lorsque le contrat l’exige.
Sources et références
Sources primaires consultées le 1er octobre 2026 : JSON Schema, objets et propriétés ; scikit-learn, métriques d’évaluation. Le contrat d’états et le scénario fournisseur sont des recommandations de conception.
