Générez des schémas JSON structurés à partir de données d'exemple grâce à l'IA, avec autocorrection automatique et post-traitement intelligent.
La génération de schéma transforme des données d'entité brutes en un schéma JSON typé et annoté qui définit exactement quelles informations extraire lors de l'enrichissement. Au lieu d'écrire vos schémas manuellement, vous collez un exemple de JSON et laissez l'IA analyser la structure, inférer les types, attribuer les domaines d'expertise et suggérer des améliorations.
La génération n'est pas un seul gros prompt. C'est une suite de petits appels à préoccupation unique, exécutés pour la plupart en parallèle — c'est ce qui permet à des modèles petits et peu coûteux de produire un schéma exploitable, puisque chaque appel répond à une seule question étroite sur un matériau qu'il peut embrasser d'un seul regard.
"8.275 h" devient half_life_seconds: 29790), et une date qu'aucun type natif ne peut représenter devient une année entière. Chaque valeur observée doit confirmer la règle, sinon la propriété reste du texte. C'est l'échantillon réécrit qui est enregistré.{"en": "...", "fr": "..."}) sont réduits à une seule valeur multilingue.Chaque étape réessaie de son côté (3 tentatives) et ses réponses s'accumulent d'une tentative à l'autre : un modèle qui répond par fragments finit donc par converger. L'étape accepte ensuite ce qu'elle a obtenu et les manques sont comblés de façon déterministe — un modèle faible dégrade les descriptions plutôt que de faire échouer la génération. Seuls l'identité et le routage vers le domaine peuvent faire échouer toute l'exécution. Chaque appel est facturé et journalisé comme un prompt distinct : l'enregistrement montre ainsi exactement ce qui a été dépensé, et où.
Vous pouvez transmettre plusieurs échantillons du même type d'entité au lieu d'un seul — le schéma couvre alors l'union de leurs champs, tout ce qui manque dans un échantillon devient nullable, et les valeurs observées dans l'ensemble deviennent de véritables exemples. Les noms des champs doivent correspondre : les échantillons décrivant des types d'entité différents sont refusés, tout comme les objets d'un tableau qui ne partagent aucun champ, car il ne resterait rien pour identifier leurs lignes. L'éditeur d'échantillons signale toute différence de ce type avant que vous ne dépensiez une génération.
Les valeurs qui comportent leur propre unité sont converties en nombres avant la dérivation du schéma, car une colonne contenant "8.275 h" et "85 ms" ne peut être ni triée, ni filtrée par plage, ni agrégée. L'unité est reportée dans le nom de la propriété (half_life_seconds), un substitut non numérique comme "stable" devient null, et les dates antérieures à l'an 1 deviennent une année entière (négative pour les dates av. J.-C.), qu'aucun type de date ne peut stocker et que le texte trie incorrectement. Votre panneau d'exemple est mis à jour en conséquence, afin d'afficher toujours l'exemple décrit par le schéma. Tout ce que la conversion ne peut pas lire avec certitude est laissé exactement tel que vous l'avez saisi.
Comme chaque étape répond à une seule question précise, la correction peut l'être tout autant : le validateur d'une étape conserve tout ce qui est revenu exploitable et ne redemande que ce qui manque. Rien n'est régénéré de zéro : une réponse partiellement correcte est donc un progrès, et non une tentative perdue.
Les huit règles de validation s'appliquent toujours au schéma assemblé en guise de contrôle final — exactitude des types, attribution des domaines d'expertise, intégrité des références, exhaustivité. À ce stade, elles font office de filet de sécurité plutôt que de mécanisme de correction. Pour en savoir plus sur chaque règle, consultez le guide Règles de validation.
Un schéma généré est plus qu'une simple définition de types. Chaque propriété inclut des métadonnées qui guident le processus d'enrichissement :
Type de schéma JSON (string, number, integer, boolean, array, object)
Description contextuelle qui indique à l'IA quelles informations rechercher
Indique quel domaine d'expertise (financier, réglementaire, etc.) fournit cette valeur
Indique si ce champ fait partie de ce qui identifie l’instance. Les propriétés identifiantes remplissent deux rôles à la fois : elles recentrent le prompt d’enrichissement sur la bonne entité et ce sont elles sur lesquelles la fusion fait correspondre les éléments de tableau. Une propriété identifiante peut malgré tout être nullable — un qualificatif qui distingue des voisins très similaires reste identifiant même lorsque des familles entières en sont réellement dépourvues
Lorsque les valeurs d'une chaîne proviennent d'un petit ensemble conventionnel (statuts, notes, codes de classification), la génération propose les membres — orthographiés comme dans vos échantillons — sous forme de vocabulaire ouvert vers lequel l'enrichissement converge. Les valeurs observées en dehors de la liste apparaissent comme candidates dans l'éditeur, et vous fermez l'ensemble dès qu'il cesse de s'étoffer ; un ensemble fermé devient un contrat strict dont l'enrichissement ne peut pas dévier
Indique si le champ peut être nul — les champs non nullables sont requis pour l'admission en base de données
Indique si le champ doit être enrichi dans plusieurs langues
Indique s'il faut conserver la valeur d'origine inchangée pendant l'enrichissement
Des valeurs d'exemple réalistes qui guident l'IA vers le bon format
Forme vérifiable par la machine pour les valeurs de type chaîne : les réponses malformées sont rejetées puis relancées, et les valeurs stockées conservent la forme canonique. La génération ne revendique jamais qu'un format nommé (date, time, date-time, uuid, email, uri, ipv4, ipv6) prouvé par ses échantillons — un motif regex est une prédiction sur des valeurs que personne n'a encore vues, et un motif erroné fait échouer chaque enrichissement du champ ; c'est donc à vous de l'ajouter vous-même dans l'éditeur
L'IA regroupe les propriétés du schéma en domaines d'expertise selon leur signification sémantique. Par exemple, le schéma d'une entreprise pharmaceutique pourrait avoir des domaines comme « Analyste financier », « Expert réglementaire » et « Informations sur l'entreprise ». Ces domaines sont utilisés par la stratégie multi-expertise pour exécuter des appels LLM parallèles et spécialisés afin d'obtenir des résultats plus approfondis.
Le nombre de domaines d'expertise est automatiquement limité en fonction du nombre de propriétés de vos données afin d'éviter une fragmentation excessive :
Une fois les fragments assemblés, des étapes déterministes tranchent tout ce qui ne doit pas être laissé à un modèle — en s'appuyant sur vos données d'entrée réelles comme preuve :
Un champ absent ou null dans un échantillon quelconque devient nullable quelle qu'ait été la réponse du modèle : une valeur inconnue est ainsi une réponse acceptée plutôt qu'un défaut de qualité des données. Les échantillons ne peuvent qu'élargir : une poignée d'échantillons prouve la présence pour ces instances-là, jamais pour toutes les instances du type — d'où le vote accordé aussi au modèle, les deux étant combinés par un OU.
Les attributs qui ne peuvent pas coexister sont réconciliés par des règles plutôt qu'en vous redemandant : preserve l'emporte sur multilingual et nullable, un vocabulaire fermé conservé annule multilingual, et une propriété clé ne conserve jamais d'enum.
Chaque objet contenu dans un tableau possède obligatoirement au moins une propriété clé — c'est l'unité sur laquelle la fusion déduplique ; un élément de tableau sans clé rendrait impossible la fusion des réponses de deux modèles.
Tous les domaines d'expertise uniques sont extraits du schéma pour les métriques et la configuration des stratégies.
Un schéma se décrit lui-même dans une langue — noms de types, descriptions de propriétés, libellés d'expertise et suggestions. C'est autre chose que les langues vers lesquelles vous enrichissez. Indiquez-en une à la génération, ou omettez-la et c'est la langue des noms de propriétés de votre échantillon qui décide : un échantillon en français cesse de produire un schéma en anglais. Le choix est mémorisé, si bien que les modifications ultérieures par l'IA continuent d'écrire dans la même langue au lieu de revenir à l'anglais.
Pas besoin de données d'exemple pour commencer. Décrivez l'échantillon souhaité en langage courant — le type d'entité, les propriétés qu'il doit porter, sa taille ou sa profondeur — éventuellement avec des documents pour l'ancrer, ou une recherche web pour le confronter à la réalité — et la plateforme rédige les échantillons pour vous. Demandez-en plusieurs et vous obtenez plusieurs instances différentes, et non une même instance reformulée.
Dans le même appel, le premier échantillon détermine aussi sur qui porteront les suivants. Demander N fois indépendamment « un exemple » renvoie invariablement N fois la même instance célèbre ; c'est le fait de nommer d'emblée l'ensemble des sujets qui les rend distincts.
Les échantillons restants sont générés en parallèle à partir de la structure de l'échantillon 1 prise comme contrat, et pas seulement avec la consigne de s'y conformer — une variante ne peut donc ni renommer, ni ajouter, ni supprimer un champ. Ceux qui reviennent malgré tout en double ou mal formés sont redemandés dans une vague de nouvelles tentatives limitée, et si le nombre demandé n'est pas atteint, vous en êtes informé plutôt que d'en recevoir moins en silence.
Tout ce que contient votre requête est respecté — un budget de taille l'emporte sur la tendance du générateur à être exhaustif, une structure que vous demandez l'emporte sur celle par défaut — ou bien la réponse vous indique ce qui n'a pas pu être respecté et pourquoi, jamais d'abandon silencieux. Une seule chose n'est pas une demande : le nombre d'échantillons obtenus dépend du nombre d'échantillons demandé, et chaque échantillon correspond à exactement une instance — demander « trois échantillons » dans le texte ne produit jamais une liste enveloppée dans un seul objet. Lorsque la requête est réellement ambiguë (un type d'entité avec plusieurs lectures, deux périmètres incompatibles), le générateur vous interroge avant de dépenser la génération, plutôt que de deviner. La langue est réglée par défaut sur auto, déduite des mots de votre propre requête, puis de toute pièce jointe.
Lisez un nom de propriété dans le contexte de son objet parent et comptez les choses distinctes qu'il pourrait demander. Une seule : c'est clair. Deux ou plus : chaque modèle en retient une différente, et la colonne finit par mélanger des réponses à des questions différentes — annual_revenue pour une entreprise peut désigner le groupe ou l'entité, le brut ou le net, dans l'une de plusieurs devises. Aucune — un nom désignant quelque chose que ce parent n'a tout simplement pas — est pire : n'ayant rien à chercher, le modèle invente une valeur.
La génération lutte contre cela deux fois : le prompt lui-même exige des noms n'admettant qu'une seule lecture, et une passe finale sur le schéma terminé annote ceux qui n'y répondent toujours pas. À ce stade, le remède est un renommage — les descriptions ayant été générées à partir des noms, une description ne peut pas lever l'ambiguïté du nom dont elle est issue, et rien ne dépend encore du schéma. La génération d'exemple applique la même vérification à l'exemple et effectue les renommages avant même que vous ne le voyiez. La prose libre — une description, un résumé, des notes — n'est jamais signalée : la formulation varie, mais la question posée est claire.
Les propriétés signalées affichent un badge « ambigu » dans l'éditeur de workflow, avec la liste des lectures que le nom admet. Une fois le schéma en production, le remède devient une description réécrite, qui fixe un sens unique sans rompre le contrat de données. Consultez le guide Vérification d'ambiguïté pour la grille complète et ses remèdes.
Lors de la génération d'une entité d'exemple à partir d'une description, vous pouvez activer « Utiliser la recherche web » pour permettre au modèle de rechercher des informations actuelles sur le web plutôt que de s'appuyer uniquement sur ses données d'entraînement. Les valeurs d'exemple obtenues sont plus récentes et plus justes — en particulier pour les données qui évoluent vite, comme les prix, les effectifs ou les sorties récentes. L'option n'est disponible que pour les modèles dont le fournisseur prend en charge la recherche web intégrée, et les appels de recherche sont facturés par le fournisseur comme toute autre utilisation du modèle.
Après la génération, vous pouvez modifier les schémas à l'aide d'instructions en langage naturel. Saisissez une commande et l'IA applique la modification tout en préservant la structure existante de votre schéma. Chaque modification produit également 5 suggestions d'améliorations supplémentaires.
Ajouter un champ entier employee_countCréer un objet adresse imbriqué avec ville et paysAjouter des descriptions en français à tous les champs texteDéfinir une référence de société mère avec $defsMarquer le champ site web comme nullableLes modifications de l'IA sont validées à l'aide d'un sous-ensemble des règles de génération (vérification des types, intégrité des références, cohérence des expertises) sans comparaison avec les données d'entrée, car vous pouvez intentionnellement ajouter ou supprimer des champs.
La génération de schéma comme l'édition IA produisent 5 suggestions ciblées couvrant différentes catégories d'amélioration :
Les suggestions apparaissent sous forme de puces cliquables dans l'Éditeur de workflow — cliquez sur l'une d'elles pour renseigner automatiquement le champ d'édition IA et l'appliquer.