Générer un JSON Schema à partir d'un exemple JSON

Comment ça marche

Un JSON Schema est un fichier de règles qui dit quels champs un document JSON doit contenir et de quel type ; on s'en sert pour valider les requêtes d'une API ou un fichier de configuration. Plutôt que de partir d'une page blanche, collez un exemple réel dans le panneau de gauche : un schéma avec type, properties, items et required remplis apparaît à droite. Dans l'exemple, l'objet « fournisseur » reçoit son propre bloc properties et le tableau « variantes » est décrit par items. Les enregistrements d'un tableau sont fusionnés : « promo » ne figure que dans la seconde variante, il n'entre donc pas dans required, alors que « diametre_cm » et « couleur », présents dans les deux, y entrent. 249.5 devient number et 12 integer ; un champ toujours null, comme « remarque », reçoit le type null. Quand une chaîne correspond exactement au format date-time ou email, un format est ajouté. Le résultat est un brouillon : les valeurs permises (enum), un minimum ou un motif (pattern) dépendent de vos données et sont à ajouter par vous.

Cet outil est aussi connu sous le nom de json to json schema, json schema generator.

Qu'est-ce que JSON Schema ?

JSON Schema est un langage de règles qui décrit la structure d'un document JSON en JSON lui-même : les champs à fournir (properties, required), leurs types (type), les éléments d'un tableau (items) et les limites de valeur (minimum, pattern, enum). Une bibliothèque de validation lit le schéma, compare les données reçues et signale chaque écart avec son chemin. Les documents OpenAPI et l'autocomplétion de nombreux éditeurs reposent dessus.

Qu'est-ce que required et null ?

Dans JSON Schema, required indique seulement qu'un champ doit exister dans l'objet ; il ne dit rien de sa valeur. Dans {"remarque": null}, le champ existe donc et satisfait required ; pour que la valeur null soit acceptée, son type doit en plus contenir null. Un champ absent et un champ à null sont deux cas différents, que cet outil marque séparément.

Quelle différence entre un JSON Schema et un exemple JSON ?

Un exemple JSON est une donnée unique : il montre une commande telle qu'elle est à un instant donné. Un JSON Schema écrit la règle que toutes les commandes doivent suivre : quels champs sont obligatoires, de quel type, dans quelle plage. Déduire un schéma d'un exemple donne le squelette de cette règle, mais l'outil ne peut pas connaître les cas absents de l'exemple (une autre devise, une liste vide, un nom très long). Une personne qui connaît les vraies règles doit donc relire le schéma généré et y ajouter les limites.

Comment le schéma est déduit : fusion, null et types mélangés

L'outil n'écrit que ce qu'il voit. Tous les enregistrements d'un tableau sont fusionnés en un seul schéma ; un champ présent dans chacun entre dans required, un champ absent ne serait-ce qu'une fois n'y entre pas. Un champ vu à null reste obligatoire mais null s'ajoute à son type : "type": ["string", "null"]. Si un champ montre deux types (un nombre ici, du texte là), le schéma accepte les deux avec anyOf. Si entiers et décimaux se mélangent, le type commun est number.

Un tableau vide ne dit rien de ses éléments, d'où items: {} : toute valeur est acceptée. Un format date, date-time ou email n'est ajouté que si toutes les valeurs du champ correspondent exactement ; un jour impossible comme 2026-02-30 n'en reçoit pas. En draft 2020-12, format n'est par défaut qu'une annotation : activez la vérification des formats dans votre validateur (ajv-formats avec Ajv, par exemple).

• {"a": 1} → "a": {"type": "integer"}, "required": ["a"]
• [1, "x"] → "items": {"anyOf": [{"type": "string"}, {"type": "integer"}]}
• [] → "items": {}
• {"t": "2026-09-27T10:30:00+01:00"} → "format": "date-time"

Quelle version choisir et où utiliser le schéma

Le draft 2020-12 est la version actuelle ; OpenAPI 3.1, la validation JSON de VS Code et les versions récentes d'Ajv et de jsonschema (Python) la prennent en charge. Si votre outil ne connaît que draft-07 (anciennes versions d'Ajv, certains générateurs de code), choisissez Draft-07. Ici les deux sorties ne diffèrent que par la ligne $schema, car les mots-clés utilisés (type, properties, items, required, anyOf, format) ont le même sens dans les deux.

Servez-vous du schéma pour valider les requêtes d'API côté serveur, pour donner à un fichier de configuration l'autocomplétion et le repérage d'erreurs dans l'éditeur, ou pour documenter la forme d'un fichier de données au sein de l'équipe. Une liste required vide donne un schéma souple qui tolère les champs absents, utile quand vous ne voulez contrôler que les types.

Questions fréquentes

Comment générer un JSON Schema à partir de JSON ?

Collez un exemple des données à valider dans le panneau de gauche de cette page. À droite apparaît un schéma avec type, properties, items et required remplis. Copiez-le ou téléchargez-le, puis ajoutez vous-même les règles propres à vos données, comme enum, minimum ou pattern.

Quels champs entrent dans la liste required ?

Ceux qui figurent dans chaque enregistrement de l'exemple. Un champ absent d'un seul enregistrement d'un tableau est considéré comme facultatif. Un champ dont la valeur est null reste dans required, mais null s'ajoute à son type. Si aucun champ ne doit être obligatoire, réglez l'option sur Laisser vide.

Quelle différence entre draft-07 et 2020-12 ?

2020-12 est plus récente et apporte par exemple prefixItems pour décrire un tableau position par position, et $defs. Cet outil n'utilise que des mots-clés qui fonctionnent pareil dans les deux, donc la sortie est identique hormis la ligne $schema ; choisissez la version que votre validateur prend en charge.

Le JSON collé est-il envoyé à un serveur ?

Non. Le schéma est déduit entièrement dans votre navigateur ; même un exemple contenant des données clients ou internes ne quitte pas cette page. Une fois chargée, la page fonctionne aussi hors connexion.