Validation de schéma JSON sans LLM

Le déterminisme est le produit

Lorsque je conçois un validateur, je me concentre sur la marche à travers l'arbre d'instances. Chaque étape produit un objet d'erreur qui contient un chemin de pointeur JSON, le mot-clé qui échoue et un message court. Puisque la marche suit le même algorithme pour les mêmes données, la liste d'erreurs est identique à chaque exécution. Cette reproductibilité permet aux équipes de traiter la validation comme une porte qui ne change jamais de verdict sans un changement réel dans le schéma ou les données d'entrée.

Les chemins de pointeur JSON sont directement mappés aux champs de formulaire ou aux clés de réponse de l'API. Un frontend peut prendre le pointeur /items/2/name et mettre en évidence le champ de nom du troisième élément sans aucune couche de traduction supplémentaire. Ce mappage est déterministe, donc le même pointeur pointe toujours à la même emplacement dans la même forme de document.

Dans CI, j'exécute le validateur contre la suite de tests et contre les fixtures générées. Si le validateur renvoie un tableau d'erreurs vide, la construction se poursuit ; tout tableau non vide échoue la construction et la charge d'erreur est publiée en tant qu'artefact. Puisque la sortie est lisible par machine, les étapes en aval peuvent compter les erreurs, les regrouper par pointeur ou publier un commentaire sur la demande de tirage qui affiche les chemins exacts qui échouent.

Là où un LLM gagne sa place

J'utilise un modèle de langage uniquement pour les tâches qui n'exigent pas un verdict vrai/faux. Le modèle ne décide jamais du passage ou de l'échec ; il ne produit que des suggestions que l'humain ou un outil peut examiner.

Étant donné une poignée de documents JSON d'exemple, je demande au modèle de générer un schéma Draft 2020-12 qui capture les types observés, les champs requis et les modèles de base. La sortie est un point de départ ; je le fais passer par le validateur pour voir s'il accepte les exemples, puis je resserre ou desserre manuellement les contraintes.

Lorsque le validateur renvoie un tableau d'erreurs, je nourris chaque objet d'erreur avec le modèle avec une demande de réécrire le message en langage clair. Le modèle peut transformer « échec du mot-clé « required » à l'indice /user/profile/age » en « Le profil utilisateur manque un champ d'âge, que votre service attend être un entier ». Cela aide les consommateurs d'API qui ne sont pas familiers avec les mots-clés JSON Schema.

En montrant au modèle une liste d'erreurs de validation fréquentes, je peux lui demander de proposer des contraintes supplémentaires, telles qu'une longueur de chaîne minimale ou un modèle pour un identifiant. J'examine chaque suggestion, j'ajoute celles qui ont du sens et je fais à nouveau passer le validateur pour confirmer que le nouveau schéma passe toujours les exemples connus comme bons.

Pour la sécurité, je garde le modèle derrière une API interne et je consigne chaque invite et réponse. Le journal me permet d'auditer si le modèle a déjà tenté d'influencer la limite de décision, ce qu'il ne peut pas faire car je ne passe jamais sa sortie au validateur en tant que règle.

Exécuter la validation dans CI et au niveau du périphérique

Le même schéma doit protéger le référentiel de code et le service en direct. J'exécute le validateur dans deux endroits :

L'exécution de la validation uniquement à un passerelle laisse le service interne exposé à la dérive ; si le schéma de la passerelle est mis à jour mais qu'un service en aval oublie de récupérer le changement, de mauvaises données peuvent passer inaperçues. En intégrant le validateur dans le service, je garantit que le contrat est appliqué où que vive le code.

Lorsque la validation échoue, je renvoie HTTP 400 avec un corps JSON qui contient un tableau d'objets d'erreur. Chaque objet d'erreur inclut :

Les clients peuvent analyser ce tableau et afficher des erreurs de formulaire inline, ce qui accélère le travail d'intégration par rapport à une chaîne générique « validation échouée ».

Puisque le validateur est sans état et déterministe, je peux utiliser le même binaire ou bibliothèque dans les deux endroits sans me soucier d'un état caché qui pourrait causer une divergence.

Génération de brouillon versus gouvernance

SchemaSafe sépare clairement les préoccupations :

Cette division maintient le contrat auditable. Je peux pointer vers un fichier de schéma spécifique dans le référentiel, noter la version du validateur, et montrer que la même entrée donne toujours le même résultat. La contribution du modèle vit dans des journaux séparés ou dans des commentaires attachés à la demande de tirage ; elle ne devient jamais partie de l'enregistrement de décision immuable.

Lorsque j'ai besoin de mettre à jour le schéma, je suis ces étapes :

Tout au long de ce flux, le validateur est le gardien ; le modèle n'a jamais le dernier mot.

Ce que ce n'est pas

Cette approche ne promet pas que chaque document invalide sera détecté avant d'atteindre un utilisateur. Si un développeur contourne délibérément le middleware ou si un bogue dans le validateur laisse passer une erreur, de mauvaises données peuvent toujours apparaître. Je ne prétends pas avoir une couverture de 100 % ; je ne prétends que la vérification est déterministe et reproductible.

Il ne s'agit pas d'un remplacement pour une conception d'API réfléchie. Un schéma peut décrire la forme et les contraintes de base, mais il ne peut pas exprimer les règles métier qui dépendent d'un état externe ou d'une logique complexe entre champs. Ces règles ont toujours besoin de tests unitaires ou de gardes de runtime.

Il ne s'agit pas d'une garantie que le LLM produira toujours des explications utiles. Le modèle peut occasionnellement manquer de nuance ou produire une réécriture trompeuse. Je traite sa sortie comme une suggestion que l'humain peut accepter, éditer ou rejeter.

Enfin, il ne s'agit pas d'un remède miracle pour la sécurité. Même si la validation des entrées réduit de nombreux risques d'injection, je suivrai toujours les conseils de l'OWASP sur l'injection de prompt ( https://genai.owasp.org/llmrisk/llm01-prompt-injection ) et sur l'hygiène des informations d'identification dans les CI/CD ( https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene ) pour maintenir la sécurité du pipeline environnant.

Références

https://genai.owasp.org/llmrisk/llm01-prompt-injection

https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene

https://ajv.js.org/json-schema.html

https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html

FAQ

La validation doit être reproductible : même entrée, même résultat. Le jugement d'un modèle peut varier entre les exécutions, ce qui est inacceptable pour un contrat qui contrôle un déploiement. Le validateur décide ; le modèle explique.

Élaborer un schéma à partir d'un exemple, réécrire une erreur de validation pour un humain ou suggérer pourquoi un champ a été omis. Ce sont des aides en plus d'un validateur réel, et non un substitut à celui-ci.

Non. Validez les requêtes entrantes dans le service que vous contrôlez afin que les messages d'erreur incluent le contexte de domaine. Exécutez le même schéma dans CI contre des fixtures et traitez les modifications de schéma comme des modifications potentiellement cassantes.

La version 2020-12 est la version stable prise en charge par les validateurs modernes tels que Ajv v8 et alignée sur OpenAPI 3.1. Épinglez l'URL du schéma dans chaque fichier afin que le comportement ne dévie pas.

Essayez le produit : SchemaSafe

2026-09-16 · sources primaires uniquement · pas de métriques de trafic fabriquées

Articles liés

Erreurs courantes lors de la rédaction de schémas JSON

Explorez la matrice complète des sujets de micro-SaaS IA →