Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 11 novembre 2026.
En bref
Un fichier correctement structuré peut contenir des valeurs incompatibles avec les données de référence ou les règles du métier. Avant de produire un document, il faut aussi contrôler les informations attendues et leur cohérence avec ces références. TW3 recommande de préciser les anomalies qui doivent arrêter la fabrication du document. Chaque refus doit indiquer la règle en échec et la personne chargée de la correction. Cette organisation donne au décideur un périmètre de contrôle explicite avant d’autoriser l’utilisation du document.
1. Que prouve un JSON lisible ?
Un JSON lisible atteste d’abord que le logiciel peut interpréter la représentation reçue. Le JSON est un format textuel d’échange de données structurées. Le RFC 8259 de l’IETF, décembre 2017 décrit un analyseur qui transforme le texte JSON en une autre représentation ; il autorise aussi les analyseurs à accepter des extensions. Pour un contrôle de conformité, il est donc utile de préciser le comportement attendu du logiciel de lecture utilisé.
La documentation Object de JSON Schema, sans date de publication indiquée, définit un objet comme une association de clés et de valeurs. Les clés sont des chaînes de caractères. Cette organisation permet de nommer les champs, mais leur seule présence ne définit ni leur fonction dans le document ni leur relation avec un référentiel métier.
Un schéma de sortie désigne ici l’ensemble des contraintes déclarées sur les données que recevra le logiciel de fabrication du document. Il constitue le niveau de contrôle suivant : après la lecture viennent les types, les champs requis et les valeurs admises. Les rapprochements avec le registre des faits interviennent ensuite.
Pour concevoir cette chaîne, partir de la décision finale : quelles données le rendu doit-il pouvoir utiliser ? Associer à chaque champ son usage prévu, puis distinguer les erreurs de lecture des refus de structure et des incohérences métier. Cette séparation, proposée comme méthode de conception, permet d’adresser la correction à l’étape concernée et de préciser ce qu’un résultat « valide » signifie.
2. Que vérifie le schéma de sortie ?
Le schéma vérifie les contraintes effectivement déclarées sur les champs. La page Object de JSON Schema, sans date de publication indiquée, précise que properties associe chaque propriété nommée à un schéma qui contrôle sa valeur. Déclarer une propriété ne la rend toutefois pas obligatoire : required remplit cette fonction.
Pour la sortie d’un agent rédacteur, définir séparément le type attendu et l’obligation de présence. Une chaîne de caractères destinée à un titre et une collection de références n’ont pas le même usage. Lorsque les valeurs possibles sont connues, enum les limite à une liste fermée, selon la page Enumerated values de JSON Schema, sans date de publication indiquée.
Le traitement des champs supplémentaires mérite une décision explicite. Ils sont acceptés par défaut ; additionalProperties réglé sur false permet de les refuser dans le périmètre concerné. Attention aux schémas composés : ce mot-clé reconnaît les propriétés déclarées dans le même sous-schéma. La documentation présente unevaluatedProperties pour tenir compte de propriétés déclarées dans des sous-schémas.
Enfin, null et absence sont distincts. Une propriété présente avec la valeur null satisfait l’exigence de présence, mais peut échouer au contrôle du type. Pour le document, décider si une donnée manquante entraîne un refus ou un état explicitement autorisé. Formaliser ce choix avec le responsable métier évite de laisser au logiciel de rendu le soin d’interpréter un blanc. Chaque champ obligatoire doit correspondre à un besoin de ce logiciel ou à une exigence de contrôle identifiée.
3. Comment exprimer des obligations conditionnelles ?
Une obligation conditionnelle dépend soit de la présence d’un champ, soit du contenu de l’objet. La documentation Conditional schema validation de JSON Schema, sans date de publication indiquée, distingue ces mécanismes.
dependentRequired exige certaines propriétés lorsqu’une autre est présente. La dépendance est orientée : imposer une référence quand une valeur existe n’impose pas automatiquement une valeur quand une référence existe. Si la règle métier exige les deux sens, il faut les écrire. Cette distinction compte pour concevoir les états incomplets qu’un agent peut transmettre.
dependentSchemas applique un sous-schéma à l’objet lorsqu’une propriété donnée est présente. Le schéma initial et le sous-schéma s’appliquent indépendamment. Ce mécanisme permet de réunir plusieurs exigences déclenchées par une même présence.
Pour une condition portant sur le contenu, if, then et else sélectionnent les contraintes applicables selon le résultat d’un schéma de condition. Une hypothèse de conception consiste à faire dépendre les champs exigés du type de page demandé ou du statut de disponibilité d’une donnée. Le métier doit définir les états admis avant leur traduction dans le schéma.
La condition doit aussi traiter l’absence de son champ déclencheur. La documentation montre qu’un if qui contrôle une propriété sans la rendre obligatoire peut réussir lorsque cette propriété manque. Inclure required dans la condition rend cette intention explicite. Relire chaque branche avec le métier, y compris le cas où le déclencheur est absent, permet de vérifier que les obligations choisies correspondent bien aux documents autorisés.
4. Quelles règles demandent un contexte externe ?
Les contrôles qui comparent la sortie à un registre de faits ont besoin d’informations extérieures à l’objet produit. La documentation Validators de Pydantic, sans date de publication indiquée, décrit des validateurs personnalisés au niveau d’un champ ou du modèle entier. Ici, « modèle » désigne la structure de données contrôlée par Pydantic. Un validateur portant sur l’ensemble peut examiner les relations entre champs.
Pydantic permet de transmettre un objet de contexte aux méthodes de validation et d’y accéder dans le validateur. Sur cette base, notre recommandation est de fournir explicitement le registre autorisé, son origine et sa version. Le contrôle peut alors rechercher les identifiants de faits utilisés et comparer les informations associées, selon les règles programmées. Un contexte absent ou incompatible doit faire l’objet d’un refus prévu par la conception.
Cet usage est une proposition de méthode. Dans la prépublication de Gibert, Despujols et Rochet déposée sur arXiv le 30 septembre 2026, la description du système TW3 mentionne un registre typé de faits comprenant valeur, unité, période et classe de provenance. Elle décrit aussi le rejet, après génération, de nombres littéraux non étayés. Ces éléments fournissent un ancrage au contrôle des références ; ils n’attribuent pas Pydantic au système décrit.
Pour la mise en œuvre proposée, conserver le contexte utilisé avec le résultat de validation. Une vérification ultérieure pourra ainsi porter sur la même version du registre. Faire valider par le métier les incompatibilités qui bloquent le rendu, notamment les références introuvables et les relations interdites entre champs.
5. Quels comportements de validation peuvent surprendre ?
La validation peut transformer une valeur avant de l’accepter. La documentation Validators de Pydantic, sans date de publication indiquée, explique qu’un validateur personnalisé peut vérifier des conditions et modifier la valeur reçue. Il faut donc examiner à la fois les règles de refus et les transformations autorisées.
Les validateurs before interviennent avant l’analyse et la validation internes de Pydantic. Ils reçoivent une entrée brute ; la valeur qu’ils renvoient est ensuite contrôlée selon le type déclaré. Les validateurs after interviennent après la validation interne. Pour une règle métier, choisir le moment du contrôle revient à choisir la représentation sur laquelle elle porte.
L’ordre des contrôles compte également. Avec les annotations, les validateurs before et wrap s’exécutent de droite à gauche, puis les after de gauche à droite. Les champs, eux, sont validés dans leur ordre de définition : un contrôle de champ doit éviter d’accéder à un champ ultérieur encore non validé. Un contrôle global du modèle peut servir à regrouper les relations entre champs.
Autre point à relire : les valeurs par défaut des champs ne sont pas validées, sauf configuration explicite en ce sens. Les validateurs de champ personnalisés ne leur sont alors pas appliqués non plus.
Dans la méthode proposée, consigner les transformations admissibles et conserver la valeur reçue lorsque cette transformation mérite une trace. Le responsable métier doit pouvoir distinguer une normalisation autorisée d’un changement qui altère le sens. Tester également le chemin des valeurs par défaut : une valeur ajoutée par le logiciel doit répondre aux exigences décidées pour le document.
6. Comment organiser les diagnostics ?
Un diagnostic exploitable identifie la règle en échec et l’étape chargée de corriger la sortie. La page Validators de Pydantic, sans date de publication indiquée, présente notamment ValueError et PydanticCustomError pour signaler une erreur de validation. Elle avertit que les assertions Python peuvent être ignorées lorsque l’optimisation est activée. Un contrôle bloquant mérite donc un mécanisme dont l’exécution est assurée dans la configuration retenue.
La carte suivante est une proposition d’organisation du cabinet. Les responsabilités restent à attribuer dans chaque projet.
| Niveau | Contrôle proposé | Portée du résultat | Responsable proposé |
|---|---|---|---|
| Syntaxe | Lire la représentation JSON selon le comportement retenu | Texte interprétable | Équipe d’intégration |
| Schéma | Contrôler types, présence, valeurs admises et conditions | Contraintes déclarées satisfaites | Responsable du contrat de sortie |
| Cohérence | Appliquer les relations métier entre champs | Règles programmées satisfaites | Direction métier |
| Références | Rapprocher les clés du registre autorisé et de sa version | Références résolues dans ce contexte | Responsable des données |
Associer au refus le champ concerné, la règle violée, le contexte utilisé et la destination de correction. Prévoir également la trace du contrôle réussi. La vérification des sources qui alimentent le registre reste une tâche distincte, à documenter avec les données.
L’annexe consacrée au pipeline d’origine dans la prépublication de Gibert, Despujols et Rochet déposée sur arXiv le 30 septembre 2026 prévoit des sorties structurées et une vérification bloquante des nombres cités. Elle prévoit aussi la correction à l’étape d’origine, suivie de la régénération des documents. Cette description concerne le pipeline d’origine, distinct du système hybride étudié dans le corps du texte. La prépublication n’isole pas l’effet de chaque composant ; aucun gain propre à la validation ne peut donc en être déduit.
FAQ
Un JSON valide suffit-il ?
Sa lisibilité permet au logiciel d’interpréter les données. Pour autoriser le rendu, définir aussi les contraintes de structure, les relations métier et les contrôles de références. Le résultat doit indiquer quel périmètre a effectivement été vérifié.
Que contrôle required ?
Dans JSON Schema, required exige la présence des propriétés désignées. Le type et les autres contraintes de leur valeur relèvent de règles supplémentaires. Une propriété présente avec null demande ainsi un examen distinct de sa seule présence.
Pourquoi transmettre un contexte au validateur ?
Le contexte donne accès aux informations extérieures nécessaires au contrôle, comme le registre autorisé. Pydantic permet de le passer aux méthodes de validation. Dans la méthode proposée ici, identifier son origine et sa version permet de conserver la référence exacte du contrôle réalisé.
Les valeurs par défaut sont-elles toujours validées ?
Pydantic indique que les valeurs par défaut des champs ne le sont pas sans configuration prévue à cet effet. Relire ce paramétrage avant d’utiliser une valeur par défaut dans un document soumis à validation. Vérifier aussi les validateurs de champ personnalisés qui doivent lui être appliqués.
La validation prouve-t-elle la source ?
Son résultat dépend des règles exécutées et des données utilisées pour les contrôler. Une référence résolue dans un registre doit rester associée à la vérification de la source correspondante. Conserver séparément ces traces permet au relecteur de savoir ce qui a été établi avant le rendu.
Pour aller plus loin
- Contrat de données d’un agent : fixer ce que la rédaction reçoit et peut utiliser.
- Nombres sans source et clés orphelines : construire un contrôle bloquant de sortie.
- Décodage contraint ou validation après génération : où faire respecter les règles ?.
Sources
- IETF, RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format, décembre 2017, consulté le 9 octobre 2026.
- JSON Schema, Object, sans date de publication indiquée, consulté le 9 octobre 2026.
- JSON Schema, Enumerated values, sans date de publication indiquée, consulté le 9 octobre 2026.
- JSON Schema, Conditional schema validation, sans date de publication indiquée, consulté le 9 octobre 2026.
- Pydantic, Validators, sans date de publication indiquée, consulté le 9 octobre 2026.
- Gibert, Despujols et Rochet, Better Deck or Different Judge? Evaluating Agentic Harness Gains in Corporate and Investment Banking, prépublication déposée sur arXiv le 30 septembre 2026, consultée le 9 octobre 2026. Texte intégral HTML.